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.

Contents:

1 1. Problem
2 2. User Stories
3 3. Market Analysis
4 4. Technical Considerations & Dependencies
5 5. QA Plan:
6 6. Safety & Tech Risks

CDS is about more than pop-up alerts! You wouldn’t put a bunch of alerts in front of an F1 driver - so why would you put them in front of a busy clinician making health decisions?

1. Problem

A Recipe for CDS

CDS is a massive topical field. It helps to think about it as a “Recipe” with some key “Ingredients” (components). We need a solution for each of these.

A Recipe for CDS

A Recipe for CDS
Ingredient	Notes	How we plan to solve this
🧠 Brain / CDS Engine	A brain/engine the software uses to calculate rules Examples include: CQL Engine/cql-framework	Drools
Authoring that’s Clinician- and BA-Friendly	BA-friendly way to represent and write rules, content Way to safely QA / review rules that is Clinician- or BA-friendly.	DMN (graph/chart), BPMN (), decision tables
Way of collecting required data	E.g. Forms, other data collection points where we learn info about patients and groups
Way to test rules	This is usually overlooked.
Content	Examples include: RxNorm Lexicomp SNOMED CT UpToDate	GAP. Need to find: Are there public datasets out there?
Metadata (Medical coding / Terminology)	Attached to content, but separated here because not all terminology sets include CDS connections.
UI: A way to inform end-users of the result	Examples include: Flags, Tasks, Modals (limit popups as much as possible though)	CDS-related UI Design Patterns: Flags : https://zeroheight.com/23a080e38/p/851fea-patient-flags Tasks (vision is that some tasks are generated automatically based on certain criteria): https://zeroheight.com/23a080e38/p/6226bc-task-management Orders (specifically, showing allergies at the point of ordering): https://zeroheight.com/23a080e38/p/71ad91-order-basket Clinical Views (showing just what you think a clinician would want to know is technically a form of CDS, even if it’s static / manual-config-driven): https://zeroheight.com/23a080e38/p/77d3d3-clinical-views

2. User Stories

Backlog of CDS-related Roadmap Items / use cases for OpenMRS: https://openmrs.atlassian.net/jira/polaris/projects/OMRS/ideas/view/6314977

Static Image:

As of Feb 20, 2025

Dynamic Widget:

https://openmrs.atlassian.net/jira/polaris/projects/OMRS/ideas/view/6314977

3. Market Analysis

SMART Guidelines & CQL “101”

https://www.youtube.com/watch?v=w_wuUoFAp7I&ab_channel=OpenMRS

Explaining our approach to SMART Guidelines & CQL Engine in 2023.

SMART Guidelines & CQL (Clinical Quality Language):
- Analysis of Categories of ANC WHO CDS Rules https://docs.google.com/spreadsheets/d/14sTL6D7ZcuYPMJ3IkBRgpWFTDk2x6EU9LhcKosOynn4/edit?gid=0#gid=0
- Docs about what we set up: Implementing SMART Guideline Indicators and CDS in OpenMRS
- Sample ANC Maternity CDS rules in spreadsheet format: https://docs.google.com/spreadsheets/d/1lRXhJg7JQboYl9sGif8Tslc3HYK17jG2/edit?gid=206805698#gid=206805698
- Sample HIV CDS rules in spreadsheet format: https://docs.google.com/spreadsheets/d/117bKXdJ1GnAuQgR5JdftFOlPY7EOpTZT/edit?gid=1103435742#gid=1103435742

Learning from Bahmni

Learning from Bahmni’s CDS efforts & SNOMED CT project:
- CDS in Bahmni 2023: Screenshots and video demo
- CDSS alert notification in Bahmni for drug-diagnosis interaction using SNOMED CT https://www.youtube.com/watch?v=P7BRsMra6_M&ab_channel=BahmniCommunity
- Bahmni CDSS Demo and E2E automation testing https://www.youtube.com/watch?v=PAkgaq6Qjuk&ab_channel=BahmniCommunity
Licensing Constraints: SNOMED-CT → comprehensive → $$$ license; vs. SNOMED-GPS → global, free license, but far less comprehensive
Technical approach: Global prop → fhir terminology server. Running a CDS server that supports FHIR CDS Hooks; more enterprise approach.

4. Technical Considerations & Dependencies

5. QA Plan:

TBC: The plan for QA, such as how we will discover and address edge cases

TBC: Plan for automated tests to be added to new components (unit tests) or workflows (e2e tests)

6. Safety & Tech Risks

TBC: Is there any reason you could regret rolling out this feature? (e.g. possible patient harm, heavy tech debt like introducing an unsupported library)

TBC: Have you thought through the risks for this particular solution? And, how to reduce/address those?

Mappings can be wrong → means CDS calculation can be very wrong

Projects

CDS Support in O3: Engine & more

Analytics