Healthcare Business Analyst Foundations: HL7-FHIR Case Study

A quick preview of Module 1: why healthcare interoperability is a business problem, not just an IT one, and the six lessons that take you from that problem statement to three real project artifacts.

Explain why fragmented healthcare data is a measurable patient-safety and financial problem, and translate that business pain into a fundable project.

Describe your case-study client NVHS — its internal systems and external partners — and explain the Business Analyst's role across this engagement.

Diagnose NVHS's four compounding business problems — data silos, a protocol mismatch, no security model, zero AI readiness — into one project.

Identify all seven NVHS project stakeholders and build a Stakeholder Matrix documenting each one's role type and primary interest.

Write a Scope Statement defining what NVHS's project will and won't deliver, and respond professionally to a scope-creep request.

Build an Interface Inventory documenting all seven NVHS system connections, completing Module 1's three-artifact deliverable set.

Module 1 is complete. This closes it out: a recap of the three artifacts you built — Stakeholder Matrix, Scope Statement, and Interface Inventory — and how each one feeds directly into Module 2, where you'll turn them into context diagrams and data-flow diagrams for NVHS's Interoperability Gateway.

This handout is your take-home reference for Module 1: the business case for NVHS's Interoperability Gateway, your case-study client, and all three artifacts you built — the Stakeholder Matrix, Scope Statement, and Interface Inventory. Download it below; Module 2 builds its architecture diagrams directly from the Interface Inventory inside it, so it's worth keeping handy.

You walked out of Module 1 with three discovery artifacts and leadership sign-off. This intro previews the six lessons ahead — from documenting NVHS's system landscape to building a System Context Diagram and tracing real data flows through the Gateway — so you know exactly where Module 2 is headed before Lesson 1 begins.

See why architecture work starts with the Business Analyst's documented system landscape, not an engineering team's blank whiteboard. You'll learn the three core vocabulary terms — system context, trust boundary, and data flow — and see exactly how your Module 1 artifacts feed directly into this module's three deliverables.

Walk through NVHS's six internal systems — EHR, LIS, PACS, Pharmacy, Billing, and Patient Portal — and build a validated Application Inventory capturing each one's owner, data domain, protocol, and criticality. You'll see why validating with real system owners, not assumptions, is what surfaces gaps like NVHS's undocumented reporting feed.

Step outside NVHS's walls to the six external partners the Gateway has to connect to, and learn the concept that governs every security review for the rest of this course: the trust boundary. You'll see exactly where NVHS's control ends and a partner's begins, for every single connection.

Turn twelve validated connection points into NVHS's first formal architecture artifact. You'll learn the four elements every context diagram needs, walk through five construction steps, and run the finished diagram against the same quality checks a senior BA would.

The Context Diagram shows who connects to whom — this lesson shows what happens to the data in between. Trace a real cardiology referral step by step through the Gateway, and see the same five-step pattern — receive, validate, transform, route, acknowledge — repeat across lab results and patient admissions.

Finalize the twelve-system Application Inventory and see how every artifact you built this module — inventory, context diagram, and data flow diagrams — gets reused directly in Modules 3 through 7, not archived.

A recap of everything Module 2 delivered: a validated Application Inventory, a System Context Diagram, and a full set of Data Flow Diagrams covering all twelve of NVHS's systems and partners. See how these three artifacts set up Module 3's work inside NVHS's actual HL7 v2 messages.

A downloadable study guide covering everything from Module 2's six lessons, including the full boundary-profile table for all six external partners, the five-step construction process for the Context Diagram, and the finalized twelve-system Application Inventory — plus five self-check questions before you move to Module 3.

Module 2 gave you the map of NVHS's systems. This intro previews the six lessons ahead — from reading a raw HL7 v2 message field by field to tracing ADT, ORM, and ORU messages and producing both of this module's named artifacts — so you know exactly where Module 3 is headed before Lesson 1 begins.

Open up a raw HL7 v2 message and learn to read it: the segment structure, the five delimiters that carry the entire grammar of the format, and how to translate an unreadable wall of pipes into a segment map anyone on the project can understand.

Trace ADT — admit, discharge, transfer — the highest-volume message family on NVHS's interface engine. Follow one admission from the registration desk through structure validation to routing across the EHR, lab, and billing systems.

Follow the order-to-result lifecycle: an ORM message carries a lab order out, and an ORU carries the result back — sometimes days later — linked the entire way by a single order control number.

Learn the three ACK codes that carry the verdict of every message exchange, the routing logic that reacts to each one, and why an ACK that never arrives at all is its own distinct failure mode.

Learn why no two systems speak HL7 exactly alike, walk through the four-stage transformation pipeline, and build the HL7 Mapping Document — one of this module's two named artifacts.

Zoom out from field-level mappings to the full Interface Specification — the document that assembles every message type, transport detail, and mapping reference into something a vendor can build against.

A recap of everything Module 3 delivered: reading raw HL7 v2, tracing ADT/ORM/ORU messages and the ACK layer, and producing both the HL7 Mapping Document and the Interface Specification. See how this HL7 v2 foundation sets up Module 4's move to FHIR.

Deepen your understanding of Module 3 with this companion study guide. Review HL7 v2 message structure, ADT/ORM/ORU message families, ACK processing, routing logic, the HL7 Mapping Document, and the Interface Specification. Use this handout as a reference throughout the remainder of the course, especially as you transition into FHIR and interoperability topics.

Module 3 gave you HL7 v2, the format that still carries NVHS's internal traffic. This intro previews the six lessons ahead — from the FHIR resource model to a full API Specification — before Lesson 1 begins.

FHIR trades HL7 v2's flat message stack for named, addressable resources like Patient and Observation. See what a Patient resource looks like, and the regulatory pressure that made FHIR the default answer.

Every FHIR exchange runs on REST. Learn the four verbs that move a resource, walk a successful request and a failed one side by side, and see why idempotency is a real API requirements concern.

An open API is only safe if you can prove who's asking. Walk the SMART on FHIR authorization flow end to end, from patient login and consent through the three gates every API call has to pass.

NVHS's HL7 v2 systems aren't going anywhere soon. Learn to translate PID fields into FHIR resources field by field, and build the Resource Mapping Matrix — this module's first named artifact.

A vendor's developers will build against this document without ever talking to you. Assemble the six-section API Specification — this module's second named artifact — and see where specs go wrong.

Zoom out from individual fields and endpoints to see the entire bridge between NVHS's legacy HL7 backbone and its modern FHIR-facing world, then preview Module 5's access-control thread.

A recap of everything Module 4 delivered: the FHIR resource model, REST mechanics, SMART on FHIR security, and both the Resource Mapping Matrix and API Specification. See what Module 5 builds next.

Module 4 gave NVHS a translation layer that can move clinical data anywhere it's asked — and that power cuts both ways. In this module, you learn every control that keeps the wrong person from getting that same access: authentication (MFA, JWTs, SSO), authorization and Role-Based Access Control, encryption at rest and in transit, and audit logging. You leave with three real deliverables — an RBAC Matrix, Audit Requirements, and a Security Requirements document — precise enough to defend NVHS's entire identity and security program.

The same APIs that let a smartphone app read a chart can let the wrong person read it too. See the real cost of a healthcare breach, the CIA triad, NVHS's actual threat landscape, and the HIPAA Security Rule's three safeguard categories.

Before a system decides what someone can do, it has to know who's asking. Walk a full MFA login sequence hop by hop, open up the anatomy of a JWT, and see why SSO trades many small risks for one concentrated one.

Authentication proves who you are; authorization decides what you're allowed to do. Learn least privilege, build the RBAC Matrix — this module's first named artifact — and see why access creep is one of the most common audit findings.

RBAC controls who's allowed to ask for data — encryption is the safety net underneath. Cover encryption at rest and in transit, defense in depth, the plaintext-to-ciphertext pipeline, and symmetric vs. asymmetric encryption.

Every other control tries to prevent something bad from happening. Audit logging assumes prevention will sometimes fail, and builds the trail that reconstructs who did what. Build the Audit Requirements artifact — this module's second named deliverable.

Pull every control from this module into one document. Learn functional vs. non-functional requirements and assemble the Security Requirements document — this module's third and final named artifact.

A recap of everything Module 5 delivered: authentication, RBAC, encryption, and audit logging, plus all three named artifacts — the RBAC Matrix, Audit Requirements, and Security Requirements document. See what Module 6 builds next.

A downloadable study guide covering Module 5's six lessons, including the CIA triad, a full MFA sequence, the RBAC Matrix, the encryption pipeline, an audit log entry, and five self-check questions before Module 6.

Modules 4 and 5 gave NVHS a translation layer and a security model. Now a new kind of requester has shown up: AI. This intro previews the six-lesson arc — from the stakes of clinical AI already live in hospitals today, through ambient documentation and data quality gates, to the two artifacts you'll build: the Data Validation & Anonymization Workflow and the AI Functional Requirements document.

Clinical AI isn't a future-state pilot — it's already inside the documentation workflow at most hospitals. This lesson sets the stakes with the real adoption numbers, defines the three terms you'll use all module (ambient documentation, NLP extraction, hallucination), walks the "allergy that wasn't there" case, and maps the governance frameworks — NIST AI RMF, FDA SaMD, ONC, HIPAA, and state law — NVHS operates under.

Follow one patient encounter from spoken word to signed note to structured FHIR resource, and see exactly where a BA's requirements either catch a problem or let it through. This lesson covers what NLP extraction is reliable at versus where it still needs a human, and walks five real failure modes — from mis-transcription to silent extraction drift.

Garbage in, hallucination out. This lesson covers the six dimensions of data quality every BA should require, the FHIR validation rule types that enforce them, why structured fields fail loudly while free text fails quietly, and the five-stage data quality pipeline that has to run before any AI model touches NVHS data.

Training or running an AI model on PHI without de-identifying it first isn't just a quality risk — it's a HIPAA violation. This lesson covers four de-identification methods, the 18 HIPAA identifiers grouped into six families, the re-identification risk check for quasi-identifiers, and walks you through building this module's first named artifact: the Data Validation & Anonymization Workflow.

Clean data and a solid spec still aren't the end of the story — someone has to decide which AI tools NVHS deploys and catch a model that starts treating patient populations unevenly. This lesson covers NVHS's governance layers, the AI output confidence gate that routes low-confidence or high-risk suggestions to a human, and six ways bias and drift creep into a model that never once logs an error.

Everything this module taught assembles into one document here. This lesson covers the six-section anatomy of an AI Functional Requirements document, the difference between vague and precise requirements a vendor can actually build against, and the validation loop that keeps the spec current after every model update — culminating in this module's final named artifact.

A recap of both artifacts built in Module 6 — the Data Validation & Anonymization Workflow and the AI Functional Requirements document — and how they turn everything this module taught into one governed, trustworthy AI pipeline. Closes with a preview of Module 7: Business Continuity & System Resilience.

A downloadable study guide covering all six lessons: the ambient documentation pipeline, six dimensions of data quality, the 18 HIPAA identifiers, the AI output confidence gate, and the full anatomy of both named artifacts — with fact-checked sourcing on every headline statistic from the deck.

Module 6 built an AI-ready interoperability pipeline. Now the question shifts: what happens when any part of it goes down? This intro previews the six-lesson arc — from the real stakes of a healthcare IT outage, through failover architecture and downtime procedures, to the three artifacts you'll build: the Downtime Operations Guide, the Business Continuity Plan, and the Non-Functional Requirements document.

Healthcare IT outages carry direct patient safety risk — this isn't an IT-only concern. This lesson defines RTO, RPO, and downtime procedures, walks NVHS's four-tier system model, traces a silent interface failure that let a clinician order an unnecessary duplicate lab panel, and maps a BA's three core responsibilities to this module's three named artifacts.

Lesson 1 defined the targets; this lesson covers the technical patterns that make them achievable — active-passive failover, active-active clustering, message queuing, and database replication. Includes the "backup that wasn't tested" scenario, where an unpersisted queue and an untested failover cost NVHS 147 messages and a 6-hour outage.

Downtime will happen anyway — clinical staff need pre-approved, pre-rehearsed procedures, not improvisation. This lesson covers the five required elements of a downtime procedure, walks a medication-safety scenario caused by a missing shift-change handoff requirement, and builds this module's second named artifact: the Downtime Operations Guide.

Downtime procedures activate after a failure is known — this lesson is about finding the failure first. Covers the reactive-vs-proactive distinction, five monitoring rules with real NFR language, the P1-P4 alert severity matrix, and why synthetic transaction monitoring is the only technique that catches a silent authentication failure before a real message is lost.

Lessons 2 through 4 built the components; this lesson assembles them into the Business Continuity Plan — this module's primary named artifact and the document a BA delivers to governance for sign-off. Covers the seven-section BCP structure, weak-vs-strong BCP statements, testing requirements, cross-functional sign-off, and six real BCP failure patterns.

The final lesson assembles this module's third named artifact — the Non-Functional Requirements document — and closes the loop connecting it to the BCP and Downtime Operations Guide. Covers the four attributes of an enforceable NFR, how all three Module 7 artifacts interconnect, and a five-point NFR review checklist before sign-off.

A recap of all three Module 7 artifacts — the Downtime Operations Guide, the Business Continuity Plan, and the Non-Functional Requirements document — and how together they tell NVHS exactly what happens when a system fails. Closes with a preview of Module 8: Requirements Finalization & Go-Live.

A downloadable study guide covering all six lessons: the four-tier system model, failover and replication patterns, the five required elements of a downtime procedure, the five monitoring rules and alert severity matrix, the seven-section BCP structure, and the four attributes of an enforceable NFR — with fact-checked sourcing on every headline statistic from the deck.

Seven modules of technical depth, stakeholder analysis, and artifact delivery converge here. This intro previews the six-lesson arc of the course's final module — from what "done" means for a healthcare BA, through the Business Requirements Document, UAT test scripts, and the Traceability Matrix, to the capstone: go-live cutover planning and project close. By the end, you'll have taken the NVHS Interoperability Gateway from a two-paragraph problem statement to a production-ready system.

Most projects declare done when the system goes live. A BA declares done when requirements are proven met. This lesson sets the stage for the entire module: the four-phase model of what "done" means (Requirements Finalization, UAT Execution, Defect Resolution & Sign-Off, Go-Live Cutover), and the four artifacts — the BRD, UAT Test Scripts, Traceability Matrix, and Go-Live Cutover Checklist — that prove it, each mapped to the governance question it answers.

The BRD is not a new type of document — it's the consolidation artifact. Everything from Modules 1-7 feeds it, so a BA who has completed all previous modules already has 80% of it written. This lesson covers the eight-section BRD structure, three failure modes that produce BRD defects (unverifiable, assumed, and untraceable requirements), the sign-off matrix, and a real gap where a HIPAA consent-revocation requirement existed in regulation but was never elicited, written, or tested.

The BRD defines what the system must do; a UAT test script proves it — and it is not a developer test case. It's a document a nurse, physician, or registration clerk can execute independently and reach an unambiguous pass or fail. This lesson covers the five-element anatomy of a strong test script, a weak-vs-strong comparison, coverage across eight NVHS requirement categories, and a test that passed but shouldn't have because its pre-condition was written too narrowly.

The Traceability Matrix is the document that closes the requirement loop: every requirement maps to a test case, every test case maps to a result, every result maps to a sign-off. This lesson covers the matrix's eight columns, the three statuses that matter (Pass, Fail, Deferred) and the danger each one carries, and the five pre-go-live health-check metrics a BA verifies before authorizing cutover.

The BRD is signed, UAT is complete, the matrix is closed — now comes the most operationally dangerous moment of the project: the live transition. This lesson covers the four cutover phases (Pre-Cutover Prep, Cutover Execution, Post-Cutover Monitoring, Handoff & Stabilization), the binary go/no-go decision gate, and a real rollback scenario where a BA held the gate on a single failed interface channel — and was right to.

The final lesson of Module 8 — and of HCBA Series 5. This lesson closes the project (all four artifacts signed or complete), traces the full NVHS Gateway arc from Module 1's problem statement through Module 8's live system, and defines what an elite Healthcare Business Analyst actually does: translates complexity, owns the specification, closes every loop, holds the quality gate, and delivers a portfolio — 21 production-grade deliverables across eight modules.

A recap of all four Module 8 artifacts — the Business Requirements Document, UAT Test Scripts, Traceability Matrix, and Go-Live Cutover Checklist — and how together they prove the NVHS Interoperability Gateway was built, tested, and safely deployed. This is also the closing recap of the entire course: eight modules, one gateway, twenty-one production-grade deliverables. You didn't take a course — you delivered a project.

A downloadable study guide covering all six lessons and all four Module 8 artifacts: the eight-section BRD structure and its three failure modes, the anatomy of a strong UAT test script, the eight-column Traceability Matrix and its health-check metrics, the four-phase cutover plan and go/no-go gate, and the full course-closing summary. This is the final handout in HCBA Series 5 — designed to be kept alongside the other seven as a complete reference library.