Dear Community, While CDS (Clinical Decision Support) is a huge topic with many related features, nuances, and risks, this is a notable current gap in O3 which we’d love to fix together.
What to Focus On Now
I believe these are the top-priority areas for O3 to get right first. None of these involve complex rule-builders or analytics engines, yet are possibly our biggest “bang for the buck” in terms of safety and basic CDS.
- Age-Based Ranges in Vitals and Labs
- Flags Module stabilized in the O3 RefApp (distro-emr)
- Drug Safety Checks
Rationale and Next steps for each:
Age-Based Ranges in Vitals and Labs:
- Why: Since O3 is increasingly used for OPD care where pediatric (children) and geriatric (elderly) care is a daily reality, it is critical for patient safety and care that Vital Sign range alerts and Lab range alerts can reflect age-appropriate ranges. For example, a heart rate of 60 is healthy-normal in an adult, but dangerously low in a young infant.
- Next Step: Dev Work Needed. This is currently being discussed here and I’m hoping we can resolve this within the next few months, including with support from Support Team members like @dkayiwa and @isaiahmuli .
Flags Module stabilized in O3 RefApp:
- Why: Many O2 implementers frequently use the Flags Module for any number of SQL-driven rules, and the vast majority of current CDS use cases I’ve seen in OpenMRS-system site visits leverage this module. However for a variety of reasons the community version of the Flags Module is not yet ready for O3 RefApp bundling, and also needs more thorough testing. This is a big “O3 vs O2” parity need. Palladium-Kenya uses a custom version of the module.
- Next Step: Dev work ongoing; Testing needed. Much of the technical debt and updates needed are being addressed by @manojll 's GSOC project, “Validating and Updating the Patient Flags Module”, with mentorship from @dkayiwa and @wikumc (thank you all!). However we still will need rigorous testing of the module by implementers who plan to use it - it would be great to see if we could get community testing support from groups like @mseaton’s, @caseynth2 & @janflowers, and @mmwanje’s (DIGI, PIH, and METS, just to name only a few; more/others welcome!!).
Drug Safety Checks:
- What: This includes things like:
- Drug-Allergy checks (“Don’t order that, she’s allergic!”)
- Drug-Condition Interaction check (“You shouldn’t order that for a patient with asthma!”)
- Drug-Drug interaction checks (“These 2 drugs together will cause risky side-effects”)
- Drug-Age interaction check (“This drug should not be used on the elderly”)
- Why: This is one of the most key safety elements of EMRs, and our gap here became painfully clear in our master’s-student study this past year (more on that below). It’s been inspiring to see the Bahmni community’s progress with this via the SNOMED grant work (demo video here).
- Next Step: Other than the obvious design needs that this raises (CC @pauladams & @cduffy), the huge question this raises is: content - where does the logic come from? @akanter and @jteich and @ibacher I think have thoughts on this.
- I would propose we work on Allergy contraindications first, since this is the most basic and generally expected safety feature in an EMR, and does not require a pre-validated or external data source. The logic is basically, “If marked allergic to that, show warning.” All the other Drug Safety Checks from there get more logically complex in terms of how much information is needed - a standard drug-drug interaction checker index will have thousands of rules!! Entire massive businesses in High-Income-Countries are based solely on providing and updating this kind of content, since guidelines are always being updated with the latest risks & discoveries.
- Once we have Drug-Allergy checking in place, then maybe we consider some kind of csv-based decision logic importing for the high-value warnings, like the really big “do not combine this drug with that Condition or that Medication” warnings. The risk there is that this will never be complete nor perfectly up to date, and humans have a tendancy to assume that a computer system doing a little bit of CDS is actually doing a lot of CDS, which can cause odd behaviors (such as ordering drugs without thinking about safety profiles, because they expect “the system will check for me”).
- What: This includes things like:
So - what are you most interested in, from those 3?
- Age-Based Ranges in Vitals and Labs
- Flags Module stabilized in O3
- Drug Safety Checks
- Something else which I’ll post in this thread
Where did this come from?
In addition to the rationale listed above, over the last 2 years we’ve actually been testing out 2 hypotheses about CDS for OpenMRS - these were our 2 experiments, and these are what led me to simplifying the focus areas above:
-
Experiment #1: Could the CQL Engine recommended by the WHO SMART Guidelines sub-community be an ideal 3rd-party tool to enable stronger CDS for OpenMRS? Daniel, Suruchi, and I worked hard on this during a Digital Square grant last year (you might remember from this showcase). Our final answer was - not yet. At the moment both the underlying technology and the CQL space is going through enough practical change that it’s not yet ready for general O3 Reference App adoption. Though there are certainly community orgs doing further work and experimentation, so we’ll see how that space matures. For now it would simply not accelerate our progress on the 3 priority areas above and honestly the specialization required to just author and edit CQL syntax adds further complexity. (I think CDS-Hooks also falls into a similar category for now where it is too complicated to be directly relevant to the 3 above priority areas.)
-
Experiment #2: Review of O3 using the SAFER Order Entry Safety Checklist. We were really lucky over the last ~8 months to have an ICU Nurse doing a Masters Degree in Clinical Informatics who embarked with me and @janflowers to do her practicum on comparing O3 to the SAFER Guide for CPOE (this is a tool that helps EMR implementers and vendors compare their features against known EMR safety risks). Overall she found our biggest areas for improvement are in the area of risk alerts related to things like Drug-Allergy checks.
Now, please don’t get me wrong; it’s not that I’m against fancier CDS models: I actually have personal work experience using FHIR careplans to drive Clinical Decision Support rules, and I’ve led both developer and clinician teams in the past to build, maintain, and improve rule authoring tools which ended up used for ~10 million people. But together the priorities and experiences above have taught me that for OpenMRS specifically, we should focus on those 3 priority areas before trying to get something like a rule-builder GUI or a perfect-fhir-ized architecture sorted out.
What do you think? We’d love to hear from people with advice or who want to move any of these 3 priorities forwards, even starting in the next few weeks or sooner!