Client
Confidential Healthcare Client
Deliverables
Business Process Analysis Stakeholder & Role Analysis Requirements Engineering Clinical Workflow Mapping Information & Data Flow Analysis Functional & Non-functional Requirements Business Rules & Acceptance Criteria AS-IS / TO-BE Process Mapping
Year
2025
Role
Business Analyst
Business analysis for a digital healthcare environment focused on improving how clinical cases, diagnostic data and decisions move across roles, systems and workflow stages. The project involved analysing the end-to-end diagnostic process, identifying information gaps, role dependencies and critical decision points, and translating clinical and operational needs into structured requirements. The goal was to define a clearer and more reliable workflow while maintaining data integrity, traceability and appropriate control over clinically relevant information.
Outcome
The analysis created a structured model of the diagnostic workflow across clinical roles, systems and information sources.
Mapping the complete case lifecycle clarified where information was created, reviewed and approved, which roles were responsible at each stage and where missing or inconsistent data could prevent a case from progressing.
Clinical and operational needs were translated into functional and non-functional requirements covering workflow behaviour, case status, role-based access, traceability and data integrity.
The resulting TO-BE model provided a shared foundation for product, clinical and technical teams to align on how the future workflow should operate before implementation decisions were made.
Key results
Key Analysis Outcomes
The analysis showed that workflow reliability depended not only on access to diagnostic information, but on understanding its status, origin, ownership and clinical relevance.
Five areas became central to the target process:
Clear case ownership - responsibility for each stage needed to be explicit across clinical and operational roles
Information completeness - users needed to know whether all required information was available before progressing a case
Clinical traceability - clinically relevant actions and changes required clear attribution and history
Controlled decision states - preliminary information needed to remain distinguishable from reviewed or confirmed findings
Role-appropriate access - each role needed the information and actions relevant to its responsibility without exposing unnecessary clinical data
Challenges
Diagnostic workflows involve more than moving information from one screen to another. A single clinical case may pass through several people, systems and decision stages before a final result can be produced.
Information may originate from patient records, diagnostic devices, clinical software and specialist assessments. Different roles create, review and act on that information at different points in the process.
The challenge was therefore to understand not only what information was required, but who needed it, when it became clinically relevant, who was allowed to change it and what should happen when information was missing or inconsistent.
Key questions included:
Which role is responsible for each stage of a diagnostic case?
What information is required before a case can progress?
Which data is generated automatically and which requires human input?
How should preliminary and confirmed findings be distinguished?
Who can review, modify or approve clinically relevant information?
What happens when required information is incomplete or inconsistent?
Which actions must remain traceable?
How should the system communicate that a case requires attention?
Which information should be available to each user role?
Objectives
The objective was to define a reliable end-to-end workflow for managing diagnostic cases and translate clinical and operational needs into actionable system requirements.
The analysis aimed to:
understand the complete AS-IS diagnostic workflow
identify clinical and operational stakeholders
map responsibilities across workflow stages
identify required information and system dependencies
uncover gaps, unclear ownership and workflow interruptions
define functional and non-functional requirements
establish rules governing case progression and clinical review
define alternative and exception scenarios
design a clearer TO-BE workflow
maintain traceability between business needs and system requirements
Process
UNDERSTANDING THE CLINICAL WORKFLOW
The analysis started with the complete lifecycle of a diagnostic case rather than individual system features.
A case could move through preparation, examination, data acquisition, analysis, clinical review and reporting. Each stage introduced different actors, information requirements and responsibilities.
Mapping these stages together revealed dependencies that were difficult to see when looking at individual interfaces or systems. Information created at one point could determine whether another role was able to continue the case later.
The first step was therefore to establish a shared view of the workflow: who performs each activity, what information they need, what the system needs to know and what condition allows the case to progress.
STAKEHOLDERS & RESPONSIBILITIES
Different roles interacted with the same clinical case for different reasons.
Administrative users needed enough information to coordinate the process without necessarily accessing detailed clinical findings. Technical staff required examination and acquisition information. Specialists needed diagnostic data and context for analysis, while authorised clinicians were responsible for reviewing or confirming clinically relevant outcomes.
Stakeholder analysis therefore focused not only on user needs, but on responsibility, information ownership and decision authority.
This helped distinguish actions that could be available broadly from those requiring specific roles or permissions.
Workflow | Admin | Technician | Specialist | Clinician |
|---|---|---|---|---|
Case preparation | ● | ○ | – | – |
Examination | – | ● | ○ | – |
Analysis | – | ○ | ● | ○ |
Clinical review | – | – | ○ | ● |
Completion | ○ | – | ○ | ● |
● Responsible○ Involved
AS-IS PROCESS ANALYSIS
The current-state workflow was analysed across activities, roles, systems and information handovers.
Particular attention was given to transitions between stages. These were critical because the completion of one activity did not necessarily mean that the next user had everything required to continue.
Missing information, unclear case status or unresolved findings could create interruptions that were difficult to recognise from an isolated system view.
The AS-IS analysis therefore captured both the standard diagnostic path and situations in which a case could not progress normally.
Examples:
Missing examination dataIncomplete patient informationData requires additional reviewFinding not yet confirmedCase returned for clarification
INFORMATION FLOW ANALYSIS
Understanding the process required mapping information alongside activities.
For each workflow stage, the analysis considered where information originated, which role created or reviewed it, whether it could be modified and which downstream activities depended on it.
This revealed an important distinction between data availability and data readiness. Information could technically exist in the system while still being incomplete, preliminary or awaiting clinical review.
The requirements therefore needed to represent not only the data itself, but also its status and context.
FROM WORKFLOW GAPS TO REQUIREMENTS
WHAT WE FOUND | WHAT IT MEANT |
|---|---|
Case ownership changed across stages | Define responsibility by workflow state |
Available data was not always ready for use | Represent completeness and review status |
Clinical decisions required clear authority | Introduce role-based actions and permissions |
Missing information could block progression | Define explicit exception and resolution paths |
Relevant changes needed accountability | Maintain traceable clinical history |
Findings from the workflow and information analysis were translated into structured requirements.
Requirements were separated into functional and non-functional categories to distinguish system behaviour from qualities that needed to apply across the complete solution.
Particular attention was given to traceability, access control and data integrity because these requirements affected multiple workflow stages rather than individual features.
REQUIREMENTS ENGINEERING
Each requirement was connected to an identified clinical or operational need and, where relevant, to a specific workflow stage and responsible role.
This created traceability between the original problem and the expected system behaviour.
FUNCTIONAL REQUIREMENTS
FR-01 - Case status
The system must represent the current workflow state of each diagnostic case
FR-02 - Required information
The system must identify whether information required for the next workflow stage is complete
FR-03 - Clinical review
The system must distinguish between preliminary findings and findings reviewed by an authorised clinical user
FR-04 - Workflow exceptions
The system must prevent progression when mandatory clinical information is missing and identify the required resolution
FR-05 - Responsibility
The system must identify the role responsible for the next required action
NON-FUNCTIONAL REQUIREMENTS
NFR-01 - Traceability
Clinically relevant changes must be attributable to the responsible user and recorded with a timestamp
NFR-02 - Access control
Access to clinical information and actions must correspond to the user's authorised role
NFR-03 - Data integrity
Clinically relevant information must remain consistent throughout the case lifecycle
NFR-04 - Auditability
The system must maintain a history of relevant workflow and information changes
NFR-05 - Availability
Information required for clinical decision-making must be accessible to authorised users when needed within the workflow
BUSINESS RULES
Clinical workflow progression depended on explicit conditions rather than a simple sequence of screens.
Business rules were therefore used to define when a case could progress, when additional action was required and which roles could perform clinically significant actions.
RULE-01 - Case progression
A case cannot progress to clinical review until all mandatory diagnostic information is available
RULE-02 - Preliminary findings
Preliminary findings must remain distinguishable from clinically reviewed findings
RULE-03 - Clinical confirmation
Only an authorised clinical role can confirm a clinically relevant finding
RULE-04 - Missing information
If mandatory information is missing, the case must remain in an actionable state and identify what is required before progression
RULE-05 - Modification
Changes to clinically relevant information after review must remain traceable
TO-BE WORKFLOW
The target workflow introduced clearer case states, responsibilities and progression criteria.
Instead of treating the diagnostic process as a sequence of loosely connected activities, the TO-BE model defined what needed to be true before each transition could occur.
Each stage had a responsible role, required information and expected outcome. Cases that could not continue followed explicit resolution paths rather than remaining in ambiguous states.
This created a workflow in which users could understand not only where a case was, but also whether it was ready to progress, what was preventing progression and who was responsible for the next action.
VALIDATION
Requirements were validated against realistic workflow scenarios rather than reviewed only as isolated statements.
Scenario walkthroughs followed a case across roles and workflow states to verify that required information, permissions, transitions and exception behaviour remained consistent.
This was particularly useful for identifying situations in which individual requirements appeared correct but created gaps when combined into an end-to-end process.
Validation scenarios included:
complete standard diagnostic workflow
mandatory information missing before examination
incomplete diagnostic data
finding requiring additional review
case returned for clarification
attempted progression without required approval
modification of information after review
REQUIREMENTS TRACEABILITY
Business Need | Requirement | Rule | Validation Scenario |
|---|---|---|---|
Clear case status | FR-01 | RULE-01 | Standard workflow |
Complete information | FR-02 | RULE-04 | Missing data |
Controlled clinical decisions | FR-03 | RULE-03 | Clinical review |
Accountability | NFR-01 | RULE-05 | Post-review change |
Appropriate access | NFR-02 | RULE-03 | Restricted action |
Maintaining traceability between business needs, requirements, rules and validation scenarios helped ensure that requirements remained connected to actual workflow problems rather than becoming an isolated feature list.
Final thoughts
Clinical systems need to do more than make information available. They need to make its context, status, ownership and reliability understandable throughout the workflow.
The analysis showed that many critical requirements existed between individual features: in handovers between roles, progression criteria, information states and the rules governing clinical decisions.
In a complex clinical workflow, clarity is not only about what information is available - it is about knowing whether it is complete, who is responsible for it and what can safely happen next.