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.

Summary:

Clinicians need information at their fingertips. A Chart Search feature will help clinicians quickly find what they need.
One expected outcome of solving this problem is that we will gain experience using Generative AI in the OpenMRS EMR.

1. Problem

Clinicians need information fast, and easy-to-find. Overburdened health workers often face complex EMR navigation and data synthesis workflows that impede their understanding of patient context and data, and result in slowing patient care.
- Not Enough Time: Regions with the poorest health outcomes have the fewest health workers:
  - Clinicians using OpenMRS often see 100s of patients daily with only 90 seconds to diagnose, document, and treat.
  - Even in the USA, within a given clinical encounter, healthcare workers spend approximately 40% of a visit’s time in data management activities, including correcting for errors.
- Hard-to-Find Info: Some information is hard to find:
  - Due to the Size of the Chart: e.g. if a patient’s chart has many years-worth of info, and many, many pages of widgets throughout their chart
  - Due to Patient Factors: if the patient can’t remember something, can’t speak the language.
  - It’s especially hard to find data from unstructured records (e.g. photos of past paper forms; free text fields).
Instead of forcing Clinicians to click-click-click through the EMR, a Chart Search feature will help clinicians quickly find what they need.
- Preliminary results of similar chart-search-approaches show a 10-20% improvement in clinician search time and information retrieval accuracy. (Source: ______________)

Our Hypotheses:

“Chart Search” will improve Clinician’s EMR experience by measurably reducing clicks and time spent searching for information about a patient.
A prompt-based GenAI approach to Chart Search and Search Results is especially effective to help with Chart Search.

2. User Stories

e.g. Does she have an IUD? When was his last Tetanus shot?

3. Market Analysis

Notes and findings here:

EMR or Solution to Learn from	Screenshots	Notes

EMR or Solution to Learn from

Screenshots

Notes

Oracle’s next EHR

Source. Video was clear that these are new designs only for demo purposes; not actually implemented that we know of.

Cerner’s Chart Search

https://www.youtube.com/watch?v=Z4tqSjQISfA&ab_channel=LouisKrennMD

Source. Not AI-driven, that we know of.

Can search both structured and unstructured data (eg dictated notes), but not images.

Example search: Results included search term Amlodipine and a related term, Norvasc.

Can filter results.

4. Technical Considerations & Dependencies

Must assume Network Connection & Computing Power are LOW. OpenMRS is often implemented in resource-poor clinical settings. While tools that improve efficiency are especially important in these settings, network connectivity and local computing power is often challenging. As such, we’d like to explore either local and/or low bandwidth approaches to Generative AI integration.

5. Sketches

Search Workflow: In a patient chart, clinicians will ask questions about the patient’s health or background by typing, into a special search bar, targeted questions - such as, “Allergies?” or “Cancer history?”.

Results Review: Then, relevant information is displayed, such as “Patient_Name shows no known history of malignancy, though a previous biopsy was completed…”. This will include source citations for the information, as well as, a UI for clinicians to indicate satisfaction or concern with the answer.

Initial Sketches by @Burke Mamlin (Source file here)

Architecture Proposal:

Users will interact with OpenMRS as they currently do: by using a browser on their desktop, laptop, or tablet. Users enter requests into the web application, the frontend AI module sends this to the backend AI module, which adds any necessary front matter and sends a request to the LLM service. The LLM transforms the request into a response and this is returned to the backend module. The backend module parses the transformed data, returning data and/or instructions to the frontend module to provide the user with a suitable response or application behavior.
The OpenMRS AI functionality will follow the OpenMRS architecture, with a frontend javascript-based module running in the browser and a java-based module running on a backend server. An LLM service will be hosted alongside the OpenMRS server and the backend module will communicate with this LLM service via its web API. OpenMRS frontend modules follow the ECMAScript module standard and are written with React and TypeScript. The AI frontend module, like all other frontend modules, will communicate with an instance of the OpenMRS platform using its web service API. A backend AI module running within the OpenMRS platform will be coded in Java according to the OpenMRS module specification. The backend module will use the OpenMRS API to access clinical data and persist any new data. It will connect to a locally hosted LLM service through a web service API. While it’s possible that country’s could provide in-country, secure, cloud-hosted LLMs, given the patient privacy requirements for clinical data, limited options for in-country cloud services, and connectivity issues in resource-constrained environments, we expect that the LLM service will need to be hosted locally.

Safety & Tech Risks

Risk of Misleading / Blatantly Wrong Information “invented” by LLM: Aka “hallucination” or “lying”, it is well known that GenAI/LLMs are very prone to inventing information, as (1) they are literally a language prediction model, meaning their greatest skill set is in predicting what words are likely to come after each other.
1. Situation: Imagine a situation where the prompt response invents medical information that is not actually accurate or true for a patient, leading the clinician to create a different, suboptimal or event harmful course of treatment for that patient. Example: An example of blatantly wrong/made up or erroneous conclusions was easily demonstrated in this simple community prototype example of using GenAI to generate a patient history summary.
2. Patient Safety Risk: High.
3. Mitigation: This project must consider a way to test for / identify / prevent hallucinations.
Patient Privacy: Patient data must not be sent to an outside service, such as a SaaS offering like ChatGPT, as this violates many country’s health data privacy laws and/or may breach patient consent.

Chart Search (aka ChartSearchAI)