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:

Automatically notify clinicians when ordered lab tests are ready, so they stop manually tracking pending tests and patients don’t wait unnecessarily.

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

1. Problem

When a clinicians order laboratory tests during a consultation, they have no automated way to know when results become available. This absence places the burden on clinicians rather than on the system, leaving patients in limbo. Without this feature, clinicians must:

Manually track which patients have pending lab orders
Periodically check the system for new results
Have no way to distinguish urgent results from routine results without manually reviewing each one
Interrupt current patient consultations to check on the previous patient’s results
Delay reviewing results and providing subsequent patient care
Risk missing follow-up on the tests ordered, especially during busy clinic sessions

Meanwhile, patients who have completed their lab tests experience uncertainty and delays:

Don't know when their results are ready
Experience anxiety about being forgotten in the system
Make difficult decisions about whether to wait at the facility or leave
Face extended wait times as clinicians juggle manual tracking
Experience delayed diagnosis and treatment when results are time-sensitive

The fundamental problem: Clinicians want to focus on delivering patient care, not on tracking status updates. Yet the current system forces them to do both.

Simply sending notifications for every lab result may create a different problem….notification overload

Important results may be buried in the noise
Clinicians may end up ignoring notifications due to alert fatigue
Critical alerts may be missed because clinicians become desensitized to constant notifications
Defeats the entire purpose of the notification system

The Right Solution: Notification Filtering

What clinicians actually need is an intelligent "push" model that automatically notifies them when priority results become available, while keeping routine results accessible without causing interruption.

Smart Notification Filtering Based on Clinical Priority:

✅ DO Notify (Requires Attention)

STAT/URGENT Orders → Always notify
- Reason: Clinician is actively waiting for the result/s to make treatment decisions
Critical/Dangerous Values → Immediate notification
- Reason: Life-threatening findings require immediate action

❌ DON’T Notify (Can Wait)

Routine Normal Results → No interruption needed
Slightly Abnormal Results → No interruption needed
Expected Abnormal Results → → No interruption needed. For example, a patient with kidney disease always has elevated creatinine.

2. User Stories

USE CASE 1: Lab Results Notification

Scenario: Clinician orders lab tests and receives notification only when laboratory results require immediate clinical attention.

Dr. Smith orders a lab test for patient John Doe, specifying the order priority (e.g., STAT vs. Routine).
The EMR transmits the order to the laboratory queue.
The lab technician processes the sample and publishes the final results back to the EMR.
Before triggering any alerts, the system intercepts the result and applies a Clinical Priority Filter.
1. High-Priority Trigger: IF the original order was marked STAT/Urgent, OR IF the result contains a Critical Value (e.g., life-threatening), THEN the system executes an Immediate Push Notification to Dr. Smith..
2. Routine-Priority Trigger: IF the order was Routine, AND IF the results are Normal or only Slightly Abnormal (within non-critical thresholds), THEN the system Silently Updates the patient’s chart. No push notification is generated.
Dr. Smith manages her workflow based on the filtered output:
- For High-Priority Alerts: She receives an intrusive notification (e.g., “⚠️ CRITICAL: John Doe - Potassium 2.2”) and clicks it to immediately initiate a life-saving intervention.
- For Routine Results: She reviews the updated chart during her scheduled rounding or administrative time, ensuring her current patient care is not disrupted by non-urgent data.

User Story:

As a Clinician, I want to receive immediate 'push' notifications only for critical or STAT results, so that I can intervene on life-threatening findings instantly while reviewing routine results at a more appropriate time without interruption.
As a Lab Technician, I want the EMR to intelligently categorize the results I enter, so that urgent clinical findings are escalated to the provider immediately, ensuring that my technical work leads to the fastest possible clinical response.
As a Patient, I want the system to prioritize my doctor’s attention toward my most urgent health data, so that I receive immediate care for critical issues while knowing my routine results are being managed safely in the background.

USE CASE 2: Prescription Changes

Scenario: Patient arrives at pharmacy with prescription that requires modification.

The patient presents a prescription to the pharmacy.
The pharmacist identifies an issue with Jane Doe’s prescription (Metformin 1000mg) and requests a modification through the system. (e.g., dosage concern, drug interaction, or out-of-stock)
1. IF Reason = "Drug Interaction Detected" or "Allergy Conflict" or Dosage concern, THEN the system Trigger Immediate Push Notification.
  - Alert: "⚠️ SAFETY ALERT: Jane Doe - Metformin interaction with [New Med]. Action required."
The system immediately sends a notification alert to the prescribing clinician. Dr. Smith sees the pop-up immediately, reviews the interaction, and sends a safe alternative to the pharmacy in real-time.
1. Message: Prescription modification requested by Pharmacy for Jane Doe - Metformin 1000mg. Reason: Drug interaction detected.
2. Approves modification → System notifies pharmacy immediately
3. Rejects/modifies differently → System sends alternative prescription to pharmacy

User Story:

As a Pharmacist, I want the system to automatically escalate (notify the clinician immediately) high-priority safety concerns (like drug interactions or allergies) to the prescribing clinician so that I can resolve medication safety issues quickly and reduce patient wait time at the pharmacy.
As a Clinician, I want the EMR to interrupt me for clinical safety risks or urgent medication changes, so that I can prevent medical errors, ensuring my patient receives safe and appropriate medication without delay.
As a Patient, I want the most urgent issues with my medication to be prioritized for my doctor's immediate attention, so that I am protected from dangerous drug conflicts.
As a Pharmacist, I want to be notified when a clinician has resolved a pending modification, so that I can finalize the dispensing process as soon as the clinical 'block' is removed.

3. Market Analysis

System	Features	Remarks

System	Features	Remarks
Prognosis: PrognoCIS EMR Suite - Primary Care - 2017		Message details Message sender Patient name Message type Date message received Message subject/details Action Pagination ~ with configurable page size
OpenMEMR: OpenEMR Login (admin/pass)		Message details Message type (Referral, Lab results, Pharmacy, etc)) Message recipient Message content (Typing space) Message actions (Add new, Delete) Date message last updated Message status (new) Patient name Patient context: Where messaging appears in the patient chart Message centre → envelope icon in the top-right corner
DrChrono: Training: DrChrono Charts and Clinical Notes \| eRx and Refill Requests Direct Messaging in DrChrono // EHR - Practice Management \| drchrono
CharmHealth EHR - Lab Result Notifier		Once the results get added to the system, this feature evaluates the result values against the configured notification criteria. The configured Members will receive notification(s) if the values uploaded in the system match the criteria. The system automatically evaluates lab result values against pre-configured notification criteria Notifications are only triggered when values match the criteria (not for every result) Timestamp shown (date + time) Patient identifier included

4. Technical Considerations & Dependencies

Notification trigger mechanism → Should this be via event module?
- Check events ~ Lab result created
- Intercepts the event, checks the STAT flag or Critical Value thresholds, and determines the "Acuity Level
Notification storage → is this needed?
- Audit trail of who was notified, when, and if they took action?
WHEN to notify? → Backend trigger ~ notification hook ~ detects the event?
HOW to notify? → Delivery mechanism ~ Push notifications ~ Frontend ~ doctors get to see the message ~ client side
Notification UI component → Notification Center/Inbox for New/Unreviewed messages (basic inbox UI for MVP)
Notification recipients →
REST API for fetching notifications? → Pagination
Notification status → Ability to mark the message as reviewed (mark notification as read/reviewed)
Performance considerations ???

5. Sketches

Clinician Facing	Lab Facing

Clinician Facing

Lab Facing

Order with STAT Priority

Notification when the STAT order returns a critical value

Notification Details

Lab order received

Lab order processing and result entry completed in the Lab

Smart Notification Feature