Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Expand
titleBA's or Feature Leader's checklist
Tip

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? 
Info

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?
Note

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.

Info

Summary:

  • OpenMRS needs a solution for:

    • (1) a CDS Engine,

    • (2) Authoring that's Clinician-friendly,

    • (3) a way to test rules, and;

    • (4) sources of content that are trustworthy, free, and actively maintained.

Contents:

Table of Contents
stylenone
image-20250220-143419.png

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.

  • 2024 GSOC: Patient Flags module upgrade

  • Old CDS hooks initiative: Supporting Clinical Decision Support using CDS Hooks

  • 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?

    2. User Stories

    3. Market Analysis

    Info

    Helpful links & resources from previous CDS initiatives:

  • CDS-related Roadmap Items: https://openmrs.atlassian.net/jira/polaris/projects/OMRS/ideas/view/6314977

    • Image Removed
  • SMART Guidelines & CQL (Clinical Quality Language):

  • Miro: Brainstorming / mind-map about CDS for OpenMRS, and notes from CDS session in 2024: https://miro.com/app/board/uXjVKcNhIQ8=/

  • Talk: O3 & CDS: A way forward for Clinical Decision Support must-haves https://talk.openmrs.org/t/o3-cds-a-way-forward-for-clinical-decision-support-must-haves/43089

  • Learning from Bahmni’s CDS efforts & SNOMED CT project:

    • 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)

    OpenMRS NoviGuide Module Demo.mov

    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:

    Image Added

    Dynamic Widget:

    https://
    drivegoogle.com/file/d/1i3oTZIRu81sExDp8Qf_K7e6Ygx2l1gOr/view

    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.

    image-20250220-141704.png
    image-20250220-141629.pngimage-20250220-141651.png

    Learning from Bahmni

    Info

    Other historic links & resources from previous CDS initiatives:


    4. Technical Considerations & Dependencies


    5. QA Plan:

    Panel
    panelIconIdatlassian-warning
    panelIcon:warning:
    bgColor#FFEBE6

    SAFER Guide for CDS: Safety checklist

    The US HealthIT program’s “SAFER Guides” offer a checklist to review to ensure you minimize CDS risks in your EMR. It’s designed for hospital administrators to double-check their implementation, but we can use some of the Recommended Practices to guide us.

    We will rely heavily on this guideline: (link/source)

    View file
    namesafer_cpoe_2016.pdf

    Note

    Additional SAFER Guides to review for CDS-relevant Safety insights

    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