5.2 Requirements Gathering, Systems Analysis & Workflow Mapping

5.2 Requirements Gathering, Systems Analysis & Workflow Mapping

The Critical Role of Systems Analysis

Systems analysis acts as the vital translation bridge between clinical practice and technical architecture. In health IT, technical systems rarely fail due to bad code; they fail because the system was built without a deep understanding of actual clinical workflows. When software forces clinicians into cumbersome data entry patterns, clinicians create unsafe workarounds, experience cognitive burnout, and suffer reduced productivity.

The primary objective of systems analysis is to elicit, analyze, document, and validate what a new system must accomplish to support clinical care, administrative operations, and regulatory mandates.

---

Requirements Elicitation Techniques

Gathering requirements from diverse healthcare stakeholders—physicians, staff nurses, pharmacists, revenue cycle managers, and compliance officers—requires a combination of elicitation methods:

1. One-on-One Interviews

Structured or semi-structured interviews with domain experts provide in-depth qualitative insights into specific departmental challenges. While time-intensive, interviews build trust and uncover detailed nuances that broad surveys miss.

2. Focus Groups and Joint Application Development (JAD) Workshops

JAD sessions bring cross-functional stakeholders into facilitated, highly structured workshops. Bringing nurses, physicians, pharmacists, and IT analysts together into a single room accelerates consensus building and resolves conflicting departmental priorities (such as medication order formatting between pharmacy and nursing).

3. Direct Clinical Observation (Shadowing)

Analysts directly shadow clinicians during active shifts to observe real-world workflows in emergency departments, intensive care units, or outpatient clinics. Shadowing reveals hidden workarounds, paper shadow records, and informal communication channels that users forget to mention during verbal interviews.

4. Surveys and Questionnaires

Distributing standardized questionnaires allows analysts to gather quantitative data across large, geographically dispersed user populations. Surveys are efficient for capturing high-level satisfaction metrics and feature preference ratings.

5. Document and Artifact Analysis

Reviewing legacy policy manuals, paper charts, order sets, audit logs, and existing incident reports provides empirical background data regarding baseline operational volume and error rates.

---

Healthcare Requirement Types

Requirements must be precisely categorized to guide system architects, procurement officers, and testing teams.

Functional Requirements

Functional requirements specify what the system must do—the operational actions, inputs, outputs, and automated behaviors.

• Example: "The system must automatically calculate patient body surface area (BSA) upon entry of height and weight."
• Example: "The system must generate an electronic prescription and transmit it via Surescripts network."

Non-Functional Requirements

Non-Functional requirements specify how well the system must perform—quality attributes, technical performance, and system constraints.

• Performance: "Medication interaction alerts must display within 1.0 second of order entry."
• Availability: "The system must maintain 99.99% operational uptime 24/7/365."
• Security: "Data at rest must be encrypted using FIPS 140-2 validated AES-256 standards."

Clinical Requirements

Clinical requirements focus on patient safety, decision support, and clinical quality metrics.

• Example: "The system must display hard-stop clinical decision support alerts when ordering duplicate anticoagulant therapy."

Regulatory Requirements

Regulatory requirements mandate compliance with legal, accreditation, and government standards.

• Example: "The system must maintain immutable audit logs recording every access to protected health information (PHI) as required by HIPAA Security Rule 45 CFR § 164.312."
• Example: "The system must conform to ONC Health IT 2015 Edition Cures Update certification criteria."

---

Requirement Types Comparison Matrix

---

Clinical Workflow Analysis & Swimlane Mapping

Workflow analysis evaluates how clinical tasks, information, and patients move through healthcare delivery pathways. The process follows two main stages:

1. Current State ("As-Is") Mapping: Visualizing the existing operational process, including bottlenecks, manual handoffs, and workarounds.
2. Future State ("To-Be") Mapping: Designing the optimized workflow after technological integration, eliminating redundant steps.

Business Process Model and Notation (BPMN) & Swimlanes

Complex clinical processes involve multiple roles. Swimlane diagrams organize process steps into parallel lanes representing specific departments or job roles (e.g., Patient, Nurse, Physician, Pharmacist, EHR System).

+-----------------------------------------------------------------------------------+
| PATIENT     : [ Arrives at Clinic ] ---> [ Provides ID & Insurance ]              |
+-----------------------------------------------------------------------------------+
| TRIAGE NURSE: [ Captures Vital Signs ] ---> [ Enters Chief Complaint in EHR ]     |
+-----------------------------------------------------------------------------------+
| PHYSICIAN   : [ Reviews Chart ] ---> [ Conducts Exam ] ---> [ Orders CPOE Med ]  |
+-----------------------------------------------------------------------------------+
| PHARMACIST  : [ Receives Electronic Order ] ---> [ Verifies Dose ] ---> [ Dispenses]|
+-----------------------------------------------------------------------------------+

Standard Flowchart Mapping Symbols

• Oval (Terminator): Represents start and end points of a clinical workflow.
• Rectangle (Process): Represents a discrete operational step or action (e.g., "Administer IV push").
• Diamond (Decision): Represents a branching point with conditional logic (e.g., "Is Patient Allergic to Penicillin? Yes/No").
• Document Symbol: Indicates physical paper forms, printouts, or generated report outputs.
• Flow Arrow: Indicates the direction of process execution and information transfer.

---

Gap Analysis Methodology

A Gap Analysis compares the current operational state ("where we are") against the desired future state ("where we need to be"). It explicitly identifies the missing elements—software features, network infrastructure, staff skills, or policy revisions—required to achieve organizational objectives.

4-Step Gap Analysis Process

1. Define Target Future State: Document specific performance benchmarks, clinical capabilities, or regulatory targets.
2. Analyze Current State: Measure baseline metrics, current system features, and existing workflow limitations.
3. Identify Gaps: Highlight missing capabilities (e.g., current EHR lacks barcoded medication administration support).
4. Formulate Action Plan: Develop prioritized initiatives, technology acquisitions, and training programs to close identified gaps.

---

Gap Analysis Matrix Example

---

Requirements Prioritization (MoSCoW Method)

Not all user requests are equally critical. Project teams employ the MoSCoW framework to prioritize requirements and defend against scope creep:

• M - Must Have: Non-negotiable requirements essential for go-live (e.g., e-prescribing compliance, basic billing generation).
• S - Should Have: Important features that add significant value but can be temporarily delayed with manual workarounds.
• C - Could Have: Desirable "nice-to-have" features implemented only if time and budget permit.
• W - Won't Have (This Time): Stakeholder requests explicitly out of scope for the current release but saved for future phases.