Prototype a Patient Scheduling System

Introduction

30 Second Summary

You know the frustration of calling a doctor's office, waiting on hold for ten minutes, only to find out the slot you wanted is already taken. Now imagine you're the hospital trying to fix that problem. Before anyone writes a line of code, someone has to figure out exactly what the new system needs to do, who it affects, and what legal rules it must follow.

In this project, you will step into the role of a Business Analyst at a hospital replacing its manual, phone-based appointment booking with a digital system. You'll produce the same deliverables a real healthtech BA creates on the job, then build a working prototype that proves your requirements are implementable.

What You'll Build

By the end, you'll fill out a booking form in your browser, hit submit, and see a confirmation screen that automatically masks patient information to meet HIPAA privacy rules. You'll have a full set of BA documentation backing that prototype, ready to show an interviewer or hand off to a dev team.

By the end of this project, you'll have:

• A stakeholder map and As-Is process flow diagram that expose exactly who is affected by the system change and where the current manual workflow breaks down.
• A Business Requirements Document with functional requirements and HIPAA-compliant non-functional requirements that a development team could build from.
• A set of user stories with testable acceptance criteria, plus a working HTML/CSS/JavaScript prototype that masks patient PHI on the confirmation screen.
• Secret Mission: Build a Requirements Traceability Matrix linking every requirement to its implementation, plus a To-Be process flow showing the complete digital workflow.

Are there any prerequisites?

You'll need a basic understanding of healthcare industry concepts (what a patient appointment looks like, what front desk staff do) and comfort with HTML, CSS, and JavaScript. No frameworks or backend knowledge required.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

You're about to produce the core deliverables of a healthtech Business Analyst: documentation that translates a hospital's pain points into actionable requirements, plus a working prototype that proves those requirements are implementable.

Set Up Your BA Toolkit

Before you can analyze the hospital's scheduling problem, you need your tools ready. Professional healthtech BAs use three categories of tools: diagramming, documentation, and code editors.

In this step, you will set up the same free, browser-based toolkit. You will use draw.io for process flow diagrams, VS Code for building a prototype later, and Google Docs for your requirements documentation.

In this step, get ready to:

• Set up draw.io for process flow diagramming.
• Create your project folder and files in VS Code.
• Create your BRD document in Google Docs.

Open draw.io and create a blank diagram

draw.io is a free, open-source diagramming tool that runs entirely in your browser. You will use it to build your stakeholder map and As-Is process flow in the next step.

• Open your web browser and navigate to https://app.diagrams.net.
• A storage location dialog appears. Select Device to save your diagram files locally on your computer.
• Click Create New Diagram.
• In the template manager, type stakeholder-map in the filename field.
• Ensure Blank Diagram is selected, then click Create.

You should now see the draw.io editor with a blank canvas in the center and shape libraries on the left.

What is draw.io?

draw.io (also called diagrams.net) is free online diagram software that supports BPMN, flowcharts, UML, and more. It requires no account to use and stores files wherever you choose.

Professional BAs use tools like Visio or Lucidchart for the same purpose, but draw.io gives you identical diagramming capability at zero cost.

Don't see the storage dialog?

If draw.io opens directly to a canvas (it remembered a previous session), click File in the menu bar, then New to start a fresh diagram. You can change storage by clicking the storage icon or selecting File then Save as and choosing Device.

help me set up draw.io with Device storage

Create your project folder and files in VS Code

VS Code is where you will build your HTML/CSS/JavaScript prototype later in the project. For now, you just need the folder structure ready.

• Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
• Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.
• Move to your Desktop by running this command:

cd ~/Desktop

• Create your project folder by running this command:

mkdir appointment-scheduler

• Confirm the folder exists by running:

ls

You should see appointment-scheduler listed in the output.

• Now open VS Code. Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
• Type Visual Studio Code and press Enter to open it.
• In VS Code, click File in the top menu bar.
• Click Open Folder.
• Navigate to your Desktop, select the appointment-scheduler folder, and click Open.

You should see the Explorer view on the left showing the folder name appointment-scheduler.

• In the Explorer sidebar on the left, click the New File... button (the page icon with a plus sign).
• Type index.html and press Enter.
• Click the New File... button again, type style.css, and press Enter.
• Click the New File... button once more, type script.js, and press Enter.

Your Explorer sidebar should now show all three files: index.html, style.css, and script.js.

Don't see the New File button?

Make sure the Explorer view is open by clicking the top icon in the Activity Bar on the left (it looks like two stacked documents). If you still do not see the button, hover over the folder name in the sidebar and the file/folder action icons will appear.

help me create new files in VS Code Explorer

Create your BRD document in Google Docs

Google Docs will hold your Business Requirements Document. This mirrors how many healthtech teams collaborate on requirements using shared cloud documents.

• In your browser, navigate to https://docs.google.com and sign in with your Google account.
• Click the Blank option (or the + icon) to create a new document.
• Click on Untitled document at the top left and rename it to Patient Appointment Scheduling System - BRD.
• In the document body, type Business Requirements Document and format it as Heading 1 using the styles dropdown in the toolbar.

You should now have a Google Doc with the title in the browser tab and a bold heading at the top of the page.

Why Google Docs for a BRD?

In industry, BAs often use Confluence, SharePoint, or Google Docs for living requirements documents. Google Docs is free, easy to share with stakeholders, and supports real-time collaboration.

Before you continue, take a moment to predict: how many tools do you now have open, and what will each one be used for in the rest of this project?

You should have three: draw.io for diagrams, VS Code for your prototype code, and Google Docs for your BRD.

Your BA toolkit is ready. Next up, you will use draw.io to map the hospital's stakeholders and document the current broken appointment process.

Map Stakeholders and the As-Is Process

Your BA toolkit is set up and ready to go. Now the real analysis begins.

You cannot fix what you do not understand. Before proposing any digital solution, a healthtech BA maps who is affected by the change and how the current process actually works. This reveals where the real pain points are, not where you assume they are.

In this step, get ready to:

• Create a stakeholder map identifying all 5 actors and their concerns.
• Draw an As-Is process flow diagram exposing pain points in the current manual booking workflow.
• Review your deliverables for completeness from a developer's perspective.

Create the stakeholder map

A stakeholder map identifies every person or role affected by the system you are analyzing. For a hospital replacing its phone-based booking process, there are five key actors, each with a different concern.

• Switch to your draw.io tab in your browser. You should see the blank canvas of your stakeholder-map.drawio file.
• Drag a rectangle shape from the shape panel on the left onto the canvas.
• Double-click the rectangle to edit its text. Type Patient as the label.
• Drag a second shape (a text box or smaller rectangle) near the Patient rectangle. Double-click it and type the Patient's primary concern: Long hold times on phone, no visibility into available slots.
• Repeat this pattern for the remaining four stakeholders, spacing them evenly across the canvas:

• Front Desk Staff - concern: Manual calendar checks, double-bookings, phone tag.
• Doctor - concern: Overbooking, no-shows, schedule not visible until morning.
• IT Administrator - concern: No data, no audit trail, no system to maintain.
• Compliance Officer - concern: Paper records risk, no access control, PHI on sticky notes.

• Save your diagram by pressing Cmd+S (macOS) or Ctrl+S (Windows).

You should now see 5 labeled rectangles on your canvas, each paired with a text note describing that stakeholder's concern.

What is a stakeholder map?

A stakeholder map is a visual summary of every person or role affected by a system change. It forces you to think beyond the obvious users (patients) and consider secondary actors (IT, compliance) whose needs often get missed.

In healthtech, forgetting the Compliance Officer is a common mistake that surfaces as a HIPAA violation months into development.

Shapes not appearing on the canvas?

Make sure you are dragging from the shapes panel on the left, not just clicking. Click and hold on a shape, then drag it onto the white canvas area and release.

If you do not see the shapes panel, click View in the menu bar and ensure Shapes is enabled.

Help me fix my draw.io shapes panel

Create the As-Is process flow

Now you will map the current manual booking workflow as an As-Is process flow. This diagram uses BPMN swim lanes to show which role is responsible for each step.

• Add a new page to your diagram by clicking the + symbol in the page tab bar at the bottom of the canvas.
• Right-click the new page tab at the bottom, select Rename, and name it As-Is Process Flow.
• Insert a swimlane diagram by clicking Arrange in the top menu, then Insert, then Template.
• In the template library, select the Basic category on the left. Choose the Swimlane Diagram template and click Insert.

Why use a swimlane template?

The swimlane template gives you a pre-built pool with horizontal lanes. Each lane represents a role (Patient, Front Desk). You can add or remove lanes using the Arrange tab in the format panel on the right.

• Modify the swimlane template to have two lanes. Label the top lane Patient and the bottom lane Front Desk Staff. Double-click the lane label text to edit it.
• In the Patient lane, add rounded rectangle shapes for: Calls hospital, Selects slot, and Shows up (or forgets).
• In the Front Desk Staff lane, add shapes for: Answers (or voicemail), Checks paper calendar, Proposes time slots verbally, Writes appointment in calendar, and Gives verbal confirmation.
• Connect the shapes with arrows to show the flow. Hover over a shape until you see the blue arrow handles appear, then drag from one shape to the next.

You should now have a connected flow of 8 steps across the two swim lanes.

• Now annotate the pain points. Add a text box near the Calls hospital step and type: Patient waits on hold 5-10 min.
• Select this text box. In the format panel on the right, click the font color button (in the Text tab or Style tab) and change it to red.
• Add a second red annotation near Checks paper calendar: Double-bookings when two staff check same calendar.
• Add a third red annotation near Gives verbal confirmation: No confirmation sent - high no-show rate.
• Save your diagram by pressing Cmd+S (macOS) or Ctrl+S (Windows).

Your second page should now show a complete swim-lane process flow with 8 steps and 3 red pain-point annotations.

What do the red annotations tell us?

Each red annotation marks a place where the current manual process causes measurable harm: wasted patient time, scheduling errors, or missed appointments. These are the problems your digital solution must solve.

Without these annotations, a stakeholder reading the diagram might assume the process works fine. The red text makes the pain undeniable.

Cannot find the swimlane template?

If the template library does not show a Swimlane Diagram under Basic, try looking in the Flowcharts category instead. There are more complex swimlane templates available there.

Alternatively, you can draw your own swim lanes manually by dragging two large rectangles onto the canvas, labeling each with a role name, and placing your workflow shapes inside them.

Help me set up swimlanes in draw.io

Review your deliverables

Before moving on, step back and evaluate what you have created. The test of a good BA deliverable is whether someone joining the project cold could understand the problem without asking you questions.

• Click through both pages of your diagram (use the page tabs at the bottom of the canvas).
• Ask yourself: if a developer joined this project today, could they understand the current problem from these two diagrams alone?
• If you spot gaps, add more detail now. Common things to add: connector labels describing what information passes between steps, or an additional annotation where you know a delay happens.

Before you check your work, predict what a developer would notice first about the As-Is flow. Which pain point would they find most alarming?

Now look at your diagram. You should see a stakeholder map on Page 1 with 5 stakeholders and their concerns, and an As-Is process flow on Page 2 showing 6 or more steps with at least 3 pain points annotated in red.

Why this review matters

In professional BA work, deliverables are reviewed by multiple teams. A developer who cannot parse your diagram will build the wrong thing. A compliance officer who does not see their concerns on the stakeholder map will flag issues late in the project.

You now have the foundation of your analysis: you know who is affected and exactly where the current process breaks down. Next, you will translate these pain points into a formal Business Requirements Document that the development team can build from.

Write the Business Requirements Document

Your stakeholder map and As-Is process flow tell the story of what is broken. Now you need to write down what "fixed" looks like in a way that developers can actually build from.

That document is the Business Requirements Document (BRD). In healthtech, the BRD carries extra weight. Every system handling patient data has legal obligations around Protected Health Information (PHI) under HIPAA. Your BRD must capture these compliance constraints alongside the functional requirements.

In this step, get ready to:

• Write the executive summary, business objective, and scope sections.
• Define five functional requirements (FR-001 through FR-005).
• Add three non-functional requirements including HIPAA PHI constraints.

Write the executive summary, business objective, and scope

The top of a BRD orients anyone reading it. The executive summary explains what the system does in plain language. The business objective states why it is needed. The scope draws a clear line around what is included and what is not.

• Return to your Google Doc titled "Patient Appointment Scheduling System - BRD".
• Below the Business Requirements Document heading, add the following text:

Executive Summary
Greenfield Medical Center currently relies on a manual, phone-based process for scheduling patient appointments. This system will replace that workflow with a digital booking platform that allows patients to self-schedule, reduces double-bookings, and sends automated confirmations to decrease no-show rates.

Business Objective
Replace the manual phone-based appointment scheduling process with a digital system to reduce no-shows, eliminate double-bookings, and improve patient access.

Scope
In-scope:
- Online appointment booking for patients
- Doctor schedule management
- Automated appointment confirmations

Out-of-scope:
- Billing integration
- Telemedicine
- Mobile app

What does each section do?

The Executive Summary gives any reader (developer, manager, compliance officer) a 30-second understanding of the project. The Business Objective is your measurable success criteria. The Scope section prevents scope creep by explicitly listing what the team will NOT build.

• Confirm the three sections are visible in your Google Doc. Google Docs saves automatically, so no manual save is needed.

Define the functional requirements

Functional requirements describe what the system must do. Each one is a specific, testable capability. Numbering them (FR-001, FR-002, etc.) creates a reference system you will use later when writing user stories and tracing requirements to the prototype.

• Below the Scope section in your Google Doc, add a new heading "Functional Requirements" and then add the following:

Functional Requirements

FR-001: The system shall allow patients to view available appointment slots by doctor and date.

FR-002: The system shall prevent double-booking the same time slot.

FR-003: The system shall send a confirmation to the patient after booking.

FR-004: The system shall allow front desk staff to view all appointments for a given day.

FR-005: The system shall allow patients to cancel or reschedule an existing appointment.

Why "shall" instead of "should" or "will"?

In requirements engineering, "shall" indicates a mandatory requirement. "Should" means desirable but optional. "Will" is ambiguous. Using "shall" consistently makes it clear to developers that every FR must be implemented for the project to be considered complete.

• Review your five functional requirements. Each one traces back to a pain point from your As-Is process flow. FR-002 (prevent double-booking) directly addresses the red annotation about two staff checking the same calendar.

Add non-functional requirements with HIPAA constraints

Non-functional requirements describe how the system must behave, not what it does. In healthtech, this is where HIPAA compliance lives. Under HIPAA, names and dates of birth are among the 18 protected identifiers that constitute PHI when linked to health information.

What is the HIPAA minimum necessary standard?

Covered entities must make reasonable efforts to limit use, disclosure of, and requests for PHI to the minimum necessary to accomplish the intended purpose. For your appointment system, this means a confirmation screen should show only what the patient needs to verify their booking. It should not display their full name and date of birth together.

The 18 HIPAA identifiers include names, dates (except year), phone numbers, email addresses, Social Security numbers, medical record numbers, and more. Combining even two of these (like full name plus date of birth) creates PHI that triggers compliance obligations.

• Below the Functional Requirements section in your Google Doc, add a new heading "Non-Functional Requirements" and then add the following:

Non-Functional Requirements

NFR-001: The system shall not display full patient name and date of birth together on any confirmation or summary screen (PHI minimum necessary principle - only display the minimum information needed).

NFR-002: The system shall implement role-based access so that only authorized staff can view patient appointment details.

NFR-003: The system shall log all access to patient records for audit purposes.

Note: Under HIPAA, names and dates of birth are among the 18 protected identifiers that constitute PHI when linked to health information.

Why do NFRs matter for prototyping?

NFR-001 is especially important because it directly affects the user interface. When you build your prototype in a later step, you will need to mask patient data on the confirmation screen. Documenting this constraint now means you have a testable criterion to validate against later.

• Scroll through your complete BRD from top to bottom.

Before you review, ask yourself: does this BRD cover both what the system should do AND what it legally must comply with? Scroll through now and check.

You should see a document with five distinct sections: Executive Summary, Business Objective, Scope, Functional Requirements (FR-001 through FR-005), and Non-Functional Requirements (NFR-001 through NFR-003). The NFRs reference HIPAA and the minimum necessary principle.

Missing a section or requirement?

If your BRD has fewer than 5 functional requirements or fewer than 3 non-functional requirements, scroll back through the text blocks above and confirm you copied everything. Each requirement should start with its ID (e.g., FR-001 or NFR-001).

If your formatting looks off, make sure each section has its own heading in Google Docs. Use Heading 2 for section titles and plain text for the requirement descriptions.

Help me structure my BRD correctly in Google Docs.

Your BRD is now the contract between you and any development team. Next up, you will translate these requirements into bite-sized user stories with testable acceptance criteria that a developer can build from.

Write User Stories with Acceptance Criteria

Your BRD captures what the system must do at a high level. But a development team cannot build from broad requirement statements alone.

User stories translate those requirements into bite-sized, testable chunks. Each story represents one interaction from one actor's perspective, with acceptance criteria that define exactly when the story is "done". This is how healthtech BAs hand work off to engineering.

In this step, get ready to:

• Write user stories for each primary actor using the standard format.
• Add testable acceptance criteria to each story.
• Cross-reference your user stories back to the BRD for traceability.

Write user stories for each primary actor

A user story follows a specific template: "As a [role], I want [goal] so that [benefit]." This forces you to think about who needs the feature, what they need, and why it matters to them.

• Switch back to your Google Doc titled "Patient Appointment Scheduling System - BRD".
• Scroll below the Non-Functional Requirements section you wrote in the previous step.
• Add a new heading titled "User Stories" and type the following four user stories:

## User Stories

US-001: As a patient, I want to book an appointment online so that I do not have to wait on hold.

US-002: As a doctor, I want to see my daily schedule so that I can prepare for upcoming patients.

US-003: As front desk staff, I want to see all appointments for today so that I can manage patient flow.

US-004: As a compliance officer, I want patient PHI to be masked on summary screens so that the system meets HIPAA minimum necessary requirements.

What does this format do?

Each story maps to one of the stakeholders from your stakeholder map. The "so that" clause connects the feature to the actor's real motivation.

Notice US-004 belongs to the Compliance Officer. This is the story that will drive your HIPAA masking requirement into the prototype later.

You should see four numbered user stories in your Google Doc, each with a clear role, goal, and benefit.

Add acceptance criteria to US-001 and US-002

Acceptance criteria define the exact conditions under which a story is considered "done". Without them, a developer has no way to know if their implementation satisfies the requirement.

• Directly below US-001 in your Google Doc, add the following acceptance criteria:

US-001 Acceptance Criteria:
- AC1: Patient can select a doctor from a dropdown.
- AC2: Patient can select an available date and time.
- AC3: After booking, a confirmation screen displays showing appointment details.
- AC4: The confirmation screen does NOT display the patient's full date of birth (only year) to comply with NFR-001.

• Below US-002, add:

US-002 Acceptance Criteria:
- AC1: Doctor can view appointments filtered by date.
- AC2: Doctor can see patient name and reason for visit for each appointment.

What makes acceptance criteria testable?

Each criterion uses concrete, observable language. "Patient can select a doctor from a dropdown" is testable because a QA engineer can click the dropdown and verify it works. Vague criteria like "system is user-friendly" are not testable.

Notice AC4 in US-001 explicitly references NFR-001 from your BRD. This links the user story directly back to the HIPAA compliance constraint.

Your first two user stories now have specific, measurable conditions for completion.

Add acceptance criteria to US-003 and US-004

US-004 is the most important story for this project. Its acceptance criteria define the exact masking rules that protect patient PHI. These are the criteria you will test your prototype against in the next step.

• Below US-003 in your Google Doc, add:

US-003 Acceptance Criteria:
- AC1: Staff can view all appointments for a selected date.
- AC2: Each appointment shows the assigned doctor and time.

• Below US-004, add the HIPAA-specific acceptance criteria:

US-004 Acceptance Criteria:
- AC1: Confirmation screen shows first initial and last name only (e.g., "J. Smith" not "John Smith").
- AC2: Date of birth is displayed as "**/**/YYYY" format on any non-clinical screen.

Why are these masking rules so specific?

Under HIPAA, names and dates of birth are among the 18 protected identifiers that constitute PHI when linked to health information. The minimum necessary standard requires that covered entities limit disclosure to only what is needed for the intended purpose.

A confirmation screen only needs to reassure the patient their booking went through. It does not need their full name or complete date of birth to do that. The masking format in AC1 and AC2 implements this principle directly.

All four user stories now have testable acceptance criteria. Your Google Doc should show each story followed immediately by its numbered criteria.

Cross-reference your user stories back to the BRD

Traceability means confirming that every requirement has at least one user story covering it. If a functional requirement has no story, it will never get built.

• Scroll up to your Functional Requirements section (FR-001 through FR-005).
• For each requirement, identify which user story covers it.
• Below your User Stories section, add a traceability note with the following mappings:

## Traceability

- FR-001 (view available slots) -> US-001 (AC1, AC2)
- FR-002 (prevent double-booking) -> US-001 (AC2 - system enforces availability)
- FR-003 (send confirmation) -> US-001 (AC3)
- FR-004 (staff view appointments) -> US-003 (AC1, AC2)
- FR-005 (cancel/reschedule) -> US-001 (future AC - extend story)
- NFR-001 (PHI masking) -> US-004 (AC1, AC2)

What is traceability?

Traceability is how BAs prove nothing was missed. By mapping every requirement to at least one user story, you confirm the development team has a clear path to implementing every item in the BRD.

Notice FR-005 (cancel/reschedule) maps to US-001 but would need an additional acceptance criterion to fully cover it. In a real project, you would add that criterion or create a separate story. For now, noting it shows you are thinking about coverage gaps.

Before you review your full document, think about this: do all five functional requirements have at least one user story covering them?

• Scroll through your Google Doc from top to bottom.
• Confirm you have the BRD sections at the top, followed by four user stories with acceptance criteria, followed by the traceability mapping.

You should see a complete document with your BRD, four user stories in the "As a... I want... So that..." format, each with 2 or more acceptance criteria, and a traceability section mapping every FR to its story.

Missing a mapping for one of your requirements?

If you find an FR that has no matching user story, write an additional story for it now. Coverage gaps at this stage turn into missing features in the final product.

If you are unsure whether a story fully covers a requirement, check whether at least one acceptance criterion directly addresses the requirement's core behavior.

Help me check if my user stories fully cover all my functional requirements.

Your BA documentation is now complete. You have a stakeholder map, As-Is process flow, BRD, and user stories with testable acceptance criteria. Next up, you will build a working prototype and test it against the very criteria you just wrote.

Build and Validate the Prototype

You have a complete set of requirements documentation. Now it is time to prove those requirements are actually implementable by building a working prototype.

Here is the real lesson of this step: when you run your prototype against your own acceptance criteria, you will discover that your initial version violates the HIPAA requirements you documented. This is exactly what happens in real healthtech projects, and fixing it is how BAs prove their value.

In this step, get ready to:

• Build an HTML/CSS appointment booking form with a confirmation screen.
• Write JavaScript that submits the form and displays patient details.
• Validate the prototype against your acceptance criteria and fix a HIPAA compliance gap.

Build the appointment booking form

Your prototype needs an HTML form that collects patient and appointment details, plus a hidden confirmation section that appears after submission.

• Switch back to VS Code with your appointment-scheduler folder open.
• Open index.html and paste this code to create the page structure and the first four form fields:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Patient Appointment Scheduling</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <div class="container">
        <header>
            <h1>Book an Appointment</h1>
            <p>Greenfield Medical Center - Patient Scheduling</p>
        </header>

        <form id="booking-form">
            <div class="form-group">
                <label for="first-name">First Name</label>
                <input type="text" id="first-name" name="firstName" required>
            </div>

            <div class="form-group">
                <label for="last-name">Last Name</label>
                <input type="text" id="last-name" name="lastName" required>
            </div>

            <div class="form-group">
                <label for="dob">Date of Birth</label>
                <input type="date" id="dob" name="dob" required>
            </div>

What does this code do?

• The <link rel="stylesheet" href="style.css"> line connects your CSS file so styles will apply when you add them.
• Each form-group div wraps a label and input pair, giving you a consistent structure to style later.
• The required attribute on each input prevents the form from submitting with empty fields.

• Directly below the Date of Birth form group, add the remaining form fields for phone, doctor selection, appointment date, and appointment time:

            <div class="form-group">
                <label for="phone">Phone Number</label>
                <input type="tel" id="phone" name="phone" required>
            </div>

            <div class="form-group">
                <label for="doctor">Select Doctor</label>
                <select id="doctor" name="doctor" required>
                    <option value="">-- Choose a Doctor --</option>
                    <option value="Dr. Patel - Cardiology">Dr. Patel - Cardiology</option>
                    <option value="Dr. Chen - General Practice">Dr. Chen - General Practice</option>
                    <option value="Dr. Williams - Orthopedics">Dr. Williams - Orthopedics</option>
                </select>
            </div>

            <div class="form-group">
                <label for="appt-date">Appointment Date</label>
                <input type="date" id="appt-date" name="appointmentDate" required>
            </div>

            <div class="form-group">
                <label for="appt-time">Appointment Time</label>
                <select id="appt-time" name="appointmentTime" required>
                    <option value="">-- Select Time --</option>
                    <option value="09:00 AM">09:00 AM</option>
                    <option value="09:30 AM">09:30 AM</option>
                    <option value="10:00 AM">10:00 AM</option>
                    <option value="10:30 AM">10:30 AM</option>

What does this code do?

• The doctor <select> dropdown maps to FR-001 from your BRD (view available slots by doctor).
• The type="tel" on phone triggers a numeric keypad on mobile devices.
• The type="date" input gives patients a native date picker instead of typing dates manually.

• Save index.html.
• Open index.html in your browser by right-clicking the file in VS Code's Explorer sidebar and selecting Reveal in Finder (macOS) or Reveal in File Explorer (Windows), then double-clicking the file.
• You should see an unstyled form with labels and input fields for First Name, Last Name, Date of Birth, and Phone Number. The time slots are cut off because we have not added the rest yet.

Seeing a blank page?

• Check that you pasted the code at the very top of index.html starting with <!DOCTYPE html>.
• Make sure you saved the file (Cmd+S on macOS or Ctrl+S on Windows).
• Confirm the browser opened the file, not a web URL. The address bar should start with file://.

Help me troubleshoot why my index.html is showing a blank page in the browser.

• Return to index.html in VS Code. Directly below the last <option> you pasted, add the remaining time slots, the reason field, the submit button, and the confirmation section:

                    <option value="11:00 AM">11:00 AM</option>
                    <option value="11:30 AM">11:30 AM</option>
                    <option value="02:00 PM">02:00 PM</option>
                    <option value="02:30 PM">02:30 PM</option>
                    <option value="03:00 PM">03:00 PM</option>
                    <option value="03:30 PM">03:30 PM</option>
                </select>
            </div>

            <div class="form-group">
                <label for="reason">Reason for Visit</label>
                <textarea id="reason" name="reason" rows="3" required></textarea>
            </div>

            <button type="submit" class="btn-submit">Book Appointment</button>
        </form>

        <div id="confirmation" class="confirmation hidden">
            <div class="confirmation-icon">&#10003;</div>
            <h2>Appointment Confirmed</h2>
            <div class="confirmation-details">
                <p><strong>Patient:</strong> <span id="conf-patient"></span></p>
                <p><strong>Date of Birth:</strong> <span id="conf-dob"></span></p>
                <p><strong>Doctor:</strong> <span id="conf-doctor"></span></p>
                <p><strong>Date:</strong> <span id="conf-date"></span></p>
                <p><strong>Time:</strong> <span id="conf-time"></span></p>
                <p><strong>Reason:</strong> <span id="conf-reason"></span></p>
            </div>

• Immediately below that confirmation-details div, add the HIPAA notice, the reset button, and the closing tags:

            <p class="hipaa-notice">Patient information displayed per HIPAA minimum necessary standard. Full details available to authorized clinical staff only.</p>
            <button class="btn-new" onclick="resetForm()">Book Another Appointment</button>
        </div>
    </div>

    <script src="script.js"></script>
</body>
</html>

What is the confirmation section for?

The confirmation div starts with the class hidden, so it is invisible when the page first loads. Your JavaScript will reveal it after form submission and populate the <span> elements with appointment details.

The hipaa-notice paragraph tells clinical users that full details are only available through authorized access. This maps directly to NFR-001 in your BRD.

• Save index.html and refresh your browser.
• You should now see the complete form with all fields: First Name, Last Name, Date of Birth, Phone, Select Doctor dropdown, Appointment Date, Appointment Time dropdown, Reason for Visit textarea, and a Book Appointment button. The confirmation section is hidden.

The form works structurally but looks unstyled. Open style.css to add a professional healthcare look.

• Paste this base styling into style.css to reset browser defaults and create the card container:

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

body {
    font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
    background-color: #f0f4f8;
    color: #1a202c;
    line-height: 1.6;
    padding: 2rem;
}

.container {
    max-width: 600px;
    margin: 0 auto;
    background: white;
    border-radius: 12px;
    box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
    padding: 2.5rem;
}

What does this code do?

• The * reset removes inconsistent browser spacing so your layout is predictable across Chrome, Firefox, and Safari.
• The .container creates a centered white card against the light blue background, giving the form a clean clinical appearance.

• Below the container styles, add the header and form field label styling:

header {
    text-align: center;
    margin-bottom: 2rem;
    padding-bottom: 1.5rem;
    border-bottom: 2px solid #e2e8f0;
}

header h1 {
    color: #2b6cb0;
    font-size: 1.75rem;
    margin-bottom: 0.25rem;
}

header p {
    color: #718096;
    font-size: 0.9rem;
}

.form-group {
    margin-bottom: 1.25rem;
}

.form-group label {
    display: block;
    font-weight: 600;
    margin-bottom: 0.4rem;
    color: #2d3748;
    font-size: 0.9rem;
}

• Save style.css and refresh your browser.
• You should see the form centered in a white card with a blue "Book an Appointment" header, a subtle divider below it, and bold labels above each field.

• Back in style.css, add the input field and submit button styles below your existing code:

.form-group input,
.form-group select,
.form-group textarea {
    width: 100%;
    padding: 0.7rem 1rem;
    border: 1px solid #cbd5e0;
    border-radius: 6px;
    font-size: 1rem;
    transition: border-color 0.2s;
}

.form-group input:focus,
.form-group select:focus,
.form-group textarea:focus {
    outline: none;
    border-color: #2b6cb0;
    box-shadow: 0 0 0 3px rgba(43, 108, 176, 0.1);
}

.btn-submit {
    width: 100%;
    padding: 0.9rem;
    background-color: #2b6cb0;
    color: white;
    border: none;
    border-radius: 6px;
    font-size: 1.1rem;
    font-weight: 600;
    cursor: pointer;
    margin-top: 1rem;
    transition: background-color 0.2s;
}

.btn-submit:hover {
    background-color: #2c5282;
}

What does this code do?

• The grouped selector .form-group input, .form-group select, .form-group textarea applies consistent sizing and borders to all three input types at once.
• The :focus styles add a blue glow when a field is active, giving patients clear visual feedback.
• The .btn-submit uses the same blue as the header for brand consistency.

• Add the confirmation screen styles below the button styles:

.confirmation {
    text-align: center;
}

.confirmation-icon {
    width: 60px;
    height: 60px;
    background-color: #48bb78;
    color: white;
    border-radius: 50%;
    display: flex;
    align-items: center;
    justify-content: center;
    font-size: 2rem;
    margin: 0 auto 1rem;
}

.confirmation h2 {
    color: #2b6cb0;
    margin-bottom: 1.5rem;
}

.confirmation-details {
    text-align: left;
    background: #f7fafc;
    padding: 1.5rem;
    border-radius: 8px;
    margin-bottom: 1.5rem;
}

.confirmation-details p {
    margin-bottom: 0.6rem;
    font-size: 0.95rem;
}

• Save style.css and refresh your browser.
• Your form should now look polished: rounded input fields with consistent spacing, a full-width blue submit button, and clean typography. Click into a field and you should see the blue focus glow.

• Add the final styles for the HIPAA notice, the "Book Another" button, and the hidden utility class:

.hipaa-notice {
    font-size: 0.8rem;
    color: #718096;
    font-style: italic;
    margin-bottom: 1.5rem;
    padding: 0.75rem;
    background: #fff5f5;
    border-radius: 4px;
    border-left: 3px solid #fc8181;
}

.btn-new {
    padding: 0.7rem 1.5rem;
    background-color: #e2e8f0;
    color: #2d3748;
    border: none;
    border-radius: 6px;
    font-size: 1rem;
    cursor: pointer;
    transition: background-color 0.2s;
}

.btn-new:hover {
    background-color: #cbd5e0;
}

.hidden {
    display: none;
}

What is the .hidden class for?

The .hidden class sets display: none on any element that uses it. Your JavaScript will add and remove this class to toggle between the form and the confirmation screen.

• Save style.css and refresh your browser.
• The form should look identical to before (the confirmation section is still hidden). Your complete booking form is styled and ready for JavaScript logic.

Form looks unstyled or broken?

• Confirm the <link rel="stylesheet" href="style.css"> line is in your HTML <head> section.
• Check that style.css is in the same folder as index.html. The filename must match exactly, including lowercase.
• Open your browser's DevTools (Cmd+Option+I on macOS or F12 on Windows) and check the Console tab for a 404 error on style.css.

Help me debug why my CSS is not applying to my HTML form.

Add the form submission logic

The form looks good, but clicking the button does nothing yet. You need JavaScript to capture the form data and display it on the confirmation screen.

• Open script.js in VS Code and paste this event listener that collects the form values and displays them on the confirmation screen:

// Listen for form submission
document.getElementById('booking-form').addEventListener('submit', function(event) {
    event.preventDefault();

    // Collect form values
    var firstName = document.getElementById('first-name').value;
    var lastName = document.getElementById('last-name').value;
    var dob = document.getElementById('dob').value;
    var doctor = document.getElementById('doctor').value;
    var apptDate = document.getElementById('appt-date').value;
    var apptTime = document.getElementById('appt-time').value;
    var reason = document.getElementById('reason').value;

    // Display full patient info on the confirmation screen
    document.getElementById('conf-patient').textContent = firstName + ' ' + lastName;
    document.getElementById('conf-dob').textContent = dob;
    document.getElementById('conf-doctor').textContent = doctor;
    document.getElementById('conf-date').textContent = apptDate;
    document.getElementById('conf-time').textContent = apptTime;
    document.getElementById('conf-reason').textContent = reason;

    // Show confirmation, hide form
    document.getElementById('booking-form').classList.add('hidden');
    document.getElementById('confirmation').classList.remove('hidden');
});

What does this code do?

• The event.preventDefault() stops the browser from refreshing the page on submit, so you stay on the same page.
• Each .value call grabs what the patient typed into that field.
• The last two lines toggle the hidden class to swap the form out and the confirmation in.

• Save script.js and refresh your browser.

Before you test, think about this: what do you expect to see on the confirmation screen when you enter a patient name like "John Smith" with a date of birth of 1990-05-15?

• Fill out the form with test data. Enter John as the first name, Smith as the last name, and select any date of birth (e.g. 1990-05-15).
• Select a doctor, pick a date and time, type a reason, and click Book Appointment.

The confirmation screen appears showing your appointment details. Look at the Patient line and Date of Birth line. You should see the full name "John Smith" and the full date of birth "1990-05-15" displayed in plain text.

Now go back to your BRD in Google Docs and check US-004's acceptance criteria. AC1 says the confirmation screen should show first initial and last name only (e.g. "J. Smith"). AC2 says date of birth should display as "**/**/YYYY". Your prototype is showing FULL patient information. It violates NFR-001, your own HIPAA minimum necessary requirement.

Your prototype fails its own acceptance criteria

This is the designed obstacle. Under HIPAA, names and dates of birth are among the 18 protected identifiers that constitute PHI when linked to health information. Displaying them together on a non-clinical screen violates the minimum necessary principle.

This is exactly what happens in real healthtech projects. A BA writes correct requirements, a developer builds the feature, and only at validation time does the compliance gap surface. Catching and fixing it here is the BA's job.

Fix the HIPAA violation

You need to mask patient data on the confirmation screen so it meets your own acceptance criteria. The fix uses two helper functions: one to show only the first initial and last name, and another to hide the month and day of the date of birth.

• In script.js, find these three lines inside the event listener:

    // Display full patient info on the confirmation screen
    document.getElementById('conf-patient').textContent = firstName + ' ' + lastName;
    document.getElementById('conf-dob').textContent = dob;
    document.getElementById('conf-doctor').textContent = doctor;
    document.getElementById('conf-date').textContent = apptDate;

• Replace those four lines with this version that uses masking and formatting functions:

    // Mask PHI before displaying (HIPAA minimum necessary)
    var maskedName = maskPatientName(firstName, lastName);
    var maskedDob = maskDateOfBirth(dob);
    var formattedDate = formatAppointmentDate(apptDate);

    document.getElementById('conf-patient').textContent = maskedName;
    document.getElementById('conf-dob').textContent = maskedDob;
    document.getElementById('conf-doctor').textContent = doctor;
    document.getElementById('conf-date').textContent = formattedDate;

What changed?

Instead of displaying raw values, the code now passes patient data through masking functions before showing it. The functions do not exist yet, so you will add them next.

• Below the closing }); of the event listener, add the three helper functions and the form reset function:

// Show only first initial + last name (e.g. "J. Smith")
function maskPatientName(firstName, lastName) {
    var firstInitial = firstName.charAt(0).toUpperCase();
    return firstInitial + '. ' + lastName;
}

// Hide month and day, show only year (e.g. "**/**/1990")
function maskDateOfBirth(dob) {
    var year = dob.split('-')[0];
    return '**/**/' + year;
}

// Convert YYYY-MM-DD to MM/DD/YYYY for readability
function formatAppointmentDate(dateString) {
    var parts = dateString.split('-');
    return parts[1] + '/' + parts[2] + '/' + parts[0];
}

// Reset form to allow a new booking
function resetForm() {
    document.getElementById('booking-form').reset();
    document.getElementById('booking-form').classList.remove('hidden');
    document.getElementById('confirmation').classList.add('hidden');
}

How do the masking functions work?

• The maskPatientName() function takes the first character of the first name, uppercases it, and appends ". " plus the full last name. "John Smith" becomes "J. Smith".
• The maskDateOfBirth() function extracts only the year from the date string and hides the month/day with asterisks. "1990-05-15" becomes "**/**/1990".
• The resetForm() function clears the form fields, hides the confirmation, and shows the form again so the user can book another appointment.

• Save script.js and refresh your browser.

Before you test again, what do you expect to see this time when you enter "John Smith" with DOB 1990-05-15?

• Fill out the form again with the same test data: John as first name, Smith as last name, DOB of 1990-05-15.
• Select any doctor, date, and time. Click Book Appointment.

The confirmation screen now shows "J. Smith" for the patient name and "**/**/1990" for the date of birth. The full name and birth date are no longer exposed together on a non-clinical screen.

• Check US-004 AC1: confirmation shows first initial and last name only. "J. Smith" passes.
• Check US-004 AC2: date of birth displayed as "**/**/YYYY". "**/**/1990" passes.
• Click Book Another Appointment to confirm the reset button works and the form reappears.

Why does this matter?

You just experienced the BA-to-implementation feedback loop. You wrote correct requirements (NFR-001, US-004), built a prototype that initially violated them, caught the gap by validating against your own acceptance criteria, and fixed it. This cycle catches compliance issues before they reach production.

Still seeing full name or full date on confirmation?

• Make sure you replaced the old display lines (firstName + ' ' + lastName) with the new masked versions (maskedName).
• Confirm the maskPatientName() and maskDateOfBirth() functions are placed OUTSIDE the event listener, after its closing });.
• Open DevTools Console (F12) and check for red error messages. A typo in a function name will show as "is not defined".

Help me debug why my patient masking is not working on the confirmation screen.

✔️ Awesome, I've got everything!

Great. Confirm you have saved all three files before moving on.

ⓧ I'd like to double check the full code

Scroll up and confirm each code chunk is present in your files, in order:

• index.html: page structure and header, first four form fields (first-name, last-name, dob, phone), doctor dropdown and time slots, reason field and confirmation section with HIPAA notice.
• style.css: reset and container, header and form-group labels, input focus and submit button, confirmation icon and details, HIPAA notice and hidden class.
• script.js: event listener with masked display logic (using maskPatientName(), maskDateOfBirth(), formatAppointmentDate()), then the four function definitions (maskPatientName, maskDateOfBirth, formatAppointmentDate, resetForm).

Secret mission

Requirements Traceability Matrix and To-Be Process Flow

You have the BRD, user stories, and a working prototype. But how do you prove that every single requirement has been addressed? And how do you show stakeholders what the future digital workflow looks like compared to the painful manual process? Build the two deliverables that separate a junior BA from one ready for a healthtech role.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely locally and uses free tools. All your files are saved on your Desktop and in Google Drive, so there are no ongoing costs.

Decide whether to keep your resources to continue building on them, pause to come back later, or delete them entirely.

Resources you used:

• Local appointment-scheduler folder on your Desktop (contains index.html, style.css, script.js).
• Local stakeholder-map.drawio file (saved to your device from draw.io).
• Google Doc titled "Patient Appointment Scheduling System - BRD" (stored in Google Drive).
• Google Sheet titled "Requirements Traceability Matrix" (stored in Google Drive).

Keep everything running

No action needed. Choose this if you plan to continue building on these deliverables or want to reference them for future projects.

• Your appointment-scheduler folder stays on your Desktop.
• Your stakeholder-map.drawio file stays wherever your browser saved it.
• Your Google Doc and Google Sheet remain in Google Drive.
• VS Code remains installed on your machine.

Pause - I'll come back to this later

Since all tools are free and files are saved locally or in Google Drive, pausing is the same as keeping everything. There are no running processes or paid services to stop.

• Close the draw.io browser tab.
• Close VS Code.
• Close your Google Docs and Google Sheets tabs.
• Everything stays saved and ready for when you return.

Delete - I don't want to use this again

Remove all project files from your machine and Google Drive.

• Delete the local project folder by running this command in your terminal:

macOS

rm -rf ~/Desktop/appointment-scheduler

Windows

rmdir /s /q %USERPROFILE%\Desktop\appointment-scheduler

• Delete the stakeholder-map.drawio file from wherever your browser saved it (check your Downloads folder or Desktop).
• Open Google Drive at drive.google.com.
• Find the document titled "Patient Appointment Scheduling System - BRD", right-click it, and select Move to trash.
• Find the spreadsheet titled "Requirements Traceability Matrix", right-click it, and select Move to trash.

Nice Work!

Nice Work!

You just completed the full lifecycle of a healthtech Business Analyst project. You mapped stakeholders, documented requirements with HIPAA constraints, built a working prototype, and caught a compliance violation before it could reach production.

You've learned how to:

• Produce a complete set of BA deliverables (stakeholder map, As-Is process flow, BRD with HIPAA constraints, and user stories with acceptance criteria) for a healthcare appointment scheduling system.
• Build a working HTML/CSS/JavaScript prototype that demonstrates a proposed solution and validates whether your requirements are implementable.
• Discover and fix a HIPAA compliance violation (PHI exposure on a confirmation screen) by validating the prototype against your own acceptance criteria, experiencing the BA-to-implementation feedback loop firsthand.
• Secret Mission: Created a Requirements Traceability Matrix linking every requirement to its implementation, plus a To-Be process flow showing the improved digital workflow.

Ready to quiz yourself?