4 Must-Do’s

1. Problem Description: Have you clearly defined the user problem(s) you intend to solve, and what value this creates? Write down a story, user insight, or quote about this problem (this is important because (1) this will motivate your team, and (2) without this your problem might not actually be a big problem for the users themselves).

2. User Stories: Have you clearly written at least 3 user stories and use cases?

3. Market Analysis: Have you surveyed what the market is doing here (e.g. comparison to other EMRs, or paper approaches; and don’t forget about learning from historic/existing OMRS instances)? Have you written down any possible gaps in your understanding of your users or their workflows? Have you reviewed the topic in FHIR to see what requirements or fields the global community references? (Eg if working on insurance, should look here)

4. Technical Considerations & Dependencies: Have you outlined what you need from cross-functional areas for success of the feature? E.g. do you need the platform to support a new API call? Have you explained how you’ve addressed dev concerns, such as designs that may not be feasible, or will be extra time-intensive to implement?

Optional/Encouraged

Sketches: Have you added a drawing or description of how the feature could work to solve the problem at hand? (Pictures of sketches are ok!)

Project Management: Have you created the Epic and JIRA tasks so you can share work clearly? Roll-out plan: Do you have an idea whether this will be an experiment, gradual roll out, and when? Have you added this to the timeline view? Have you planned how you will promote and/or work with communications folks in order to help this feature reach the widest audience and have the biggest impact it can?

Later but should do

QA Plan: Have you mentioned the plan for QA, such as how you will discover and address edge cases? Does your team/squad have a plan for automated tests to be added to new components (unit tests) or workflows (e2e tests)?

Safety & Tech Risks: Is there any reason you could regret rolling out this feature? (e.g. possible patient harm, heavy tech debt like introducing an unsupported library) Have you thought through the risks for this particular solution? And, how to reduce/address those?

This checklist was inspired by this article. Additional Business Analyst Resources here.

Status: Requirements In Progress ready for Work In Progress Done

Technical Complexity: Easy Medium Hard / Complex

Summary:

Key point 1
Key point 2

Picture showing what this project is about (e.g. a key mockup, drawing; anything visual)

1. Problem

Research consistently shows that EHR use accounts for a disproportionate share of physician time — time that could otherwise be spent with patients. A study by the American Medical Association and Dartmouth-Hitchcock found that physicians spent 49% of their working day on EHRs and desk work, compared to just 27% in direct face time with patients, with an additional 1–2 hours of data entry after hours (Source). Supporting findings from separate studies estimate that physicians spend nearly 45% of their time on the EHR overall (Source), and approximately 4.5 hours per day on documentation alone (Source).
This administrative burden has a direct impact on the quality of care. Every patient visit generates significant documentation overhead, forcing clinicians to act as both caregivers and data entry operators simultaneously — splitting their attention between the patient in front of them and the screen and keyboard. The result is reduced face time, divided focus, and a clinical environment where the demands of the system compete directly with the needs of the patient.

Desired State:

In the desired state, clinicians are freed from the burden of real-time documentation, allowing them to focus entirely on the patient in front of them. Rather than dividing their attention between the conversation and the keyboard, doctors can maintain eye contact, build rapport, and engage fully in the clinical encounter.
In the background, an AI system listens to the consultation, transcribes the conversation, and automatically structures the relevant information into a clinical note. Once the visit is complete, the clinician simply reviews the generated note and approves it — reducing documentation time to a fraction of what it is today, without compromising accuracy or completeness.

2. User Stories

As a clinician, I want to maintain full eye contact and engagement with my patient during a consultation so that I can build trust and deliver better care without being distracted by documentation.
- I want the consultation to be automatically transcribed so that I no longer need to type during patient visits.
- I want the AI to structure the transcription into a clinical note so that I do not have to manually organise or format documentation after the visit.
- I want to review and approve an AI-generated note so that I can confirm accuracy and make any corrections before it is saved to the patient record.
As a patient, I want my clinician to be fully present and attentive during my visit so that I feel heard and receive a higher quality of care.

3. Market Analysis

Solutions	Visuals	Key Features

Solutions	Visuals	Key Features
OpenEMR: 5 AI Tools to Revolutionize Your Medical Practice		Freed AI “listens” to the conversation between the doctor and the patient in real-time The tool synthesizes the dialogue into a structured SOAP note, including the Subjective, Objective, Assessment, and Plan sections Instead of writing the note from scratch, the clinician reviews the generated chart note for accuracy After review, push to the EMR and SOAP note sections are updated
Nabla Ambient Clinical Voice: Nabla Ambient Clinical Voice Demo at HIMSS		The tool "listens" to the natural conversation between a clinician and patient using a mobile or desktop device. The generated note is considered a draft. Clinicians can review and edit it using text, their own voice, or a specialized "Magic Edit" feature Nabla generates an "After-Visit Summary" in patient-friendly terms
Oracle Clinical AI Assistant: Oracle Health Registration, Scheduling, and Clinical Digital Assistant Demo \| Oracle Health Conf 23		The system records the natural conversation The doctor can ask for specific data points (e.g., "Hey Oracle, show me her vitals" or "Read her blood pressure history") without touching a keyboard. While speaking to the patient, the doctor can ask the assistant to display data on his mobile device (e.g., "Show me Julie’s last three A1c’s") to facilitate the conversation Once recording stops, the AI generates a structured draft SOAP note and proposes orders based on the conversation. The doctor reviews the proposed actions and uses voice to refine them (e.g., "Change the dispense to 90 and refills to three") and then says "Sign it" to finalize the encounter.
Oracle Health Clinical AI Assistant: Oracle TV at HIMSS 2024: AI-Powered Clinical Digital Assistant Oracle Health Clinical AI Agent, Clinical Note Helps UK Doctors Spend More Time on Patient Care		Captures natural dialogue between provider and patient Produces high-quality clinical drafts/SOAP notes Allows voice navigation and data entry into the EHR Suggests orders and detects missing record data
Generating SOAP Notes with AI: Generating SOAP Notes with AI: Enhancing Clinical Documentation Efficiency		How medical Large Language Models (LLMs) can automate the creation of SOAP notes—a standardized clinical documentation format (Subjective, Objective, Assessment, and Plan) Integrated AI Agents and Orchestration Accepts raw audio or transcripts of doctor-patient conversations The AI agent identifies the required form fields (e.g., date, duration, patient findings) and populates a PDF or digital record. Trained specifically on medical papers and doctor’s notes to provide medically accurate answers based on the context provided. Includes built-in annotators to censor or anonymize confidential patient data automatically
Athena Voice to Text: 3_athenaOne® Top Hits \| athenaOne Education Session

Market Opportunity for OpenMRS

OpenMRS serves the healthcare system primarily in low-to middle-income countries (LMICS) where:
- Clinician-to-patient ratios are significantly high
- Documentation burden is proportionately higher with fewer support staff

4. Technical Considerations & Dependencies

Choice of transcription engine (Speech-to-Text)
Selection of the AI/LLM model responsible for structuring the transcription into a clinical note
Ability to map transcribed content to standard clinical note formats (e.g. SOAP notes)
Mapping AI-generated content to the correct fields, concepts, and data structures within the EMR
Handling of structured data (e.g. diagnoses, medications, orders) vs. free text
Patient consent mechanisms before recording begins
Where data is processed and stored — on-device, or in the cloud etc
User interface for reviewing, editing, and approving generated notes
Ability to make corrections and have the AI learn from feedback over time
Reliable internet connectivity requirements, particularly in low-resource settings
- Offline or low-bandwidth fallback options
Support for multiple languages and local dialects, particularly relevant for diverse or low-resource settings

Voice Transcription Feature

1. Problem

2. User Stories

3. Market Analysis

4. Technical Considerations & Dependencies

5. Sketches