I would like to find out if there has been any work/design to building clinical decision support into OpenMRS
For UgandaEMR we are using a combination of patient flags, data validation rules, reports, and the clinician facing dashboard to implement this.
However I would like to hear if there is a more coherent strategy around this, road map or additional thinking over and above my common sense
@dkayiwa I don’t think so. @ssmusoke references in-app decision support.
For instance it could be about introducing useful UI changes to a patient file to which special attention should be given because of abnormal values (whatever they are.)
@jdick, maybe something to discuss with Ciaran?
My impression was that the in-app is going to feed on the analytics engine’s data for some user interface data displays.
@mksd Exactly and not only abnormal values, but rather points of interest on the patient
Awesome to hear about the interest in this. Yes, @dkayiwa is right; we planned for this work to end up being housed in the Analytics Engine Squad (not necessarily saying it has to happen this way, and we’d hope to see more people join that squad specifically with CDS interests). Idea was that we’d be able to feed on live-time data from the Analytics Engine which would run in parallel to the frontend (@burke @akimaina @bashir anything to add about that idea?). But ideas are just ideas… so next steps…
@jennifer was thinking we could kick this off with a Lightning Talk soon - @ssmusoke would you be interested in that, and in demo-ing how your team is handling CDS so far? We could use that as our kick-off to start clearly laying out the requirements and next steps.
Your timing is awesome @ssmusoke because both @ddesimone and @paulamendola have recently expressed interest in demo-ing how they are handling Decision Support. Probably would be helpful to see how AMPATH handles it as well in the backend (@jdick) - I think there’s a whole combo happening throughout the OMRS community of custom-build rule building tools and mostly hard-coded rules.
Also @ssmusoke you may want to check out the recent conversation in the Bahmni community - @tejakancherla presented to their Product Architecture Team just recently; they’re looking to build a CDS rule-builder GUI to drive alerts/notifications. Here’s that post and here’s their requirements and mockups document.
Out of nerdy curiosity - @ssmusoke has your team looked at using CDS Hooks? (https://cds-hooks.org/) I’ve been hearing this term used in the context of “one day it would be nice to…” so I’m just curious.
@grace we have nothing yet, just in the initial exploratory phases.
Thanks for the links to the CDS rule builder, I will take a look and follow their work
CDS Hooks is definitely in the “one day…” category. It seems like a fundamentally solid architecture, but AFAICT, hasn’t really been implemented anywhere and really only has one well-defined “hook” (
Looks like we need to chunk the roadmap here.
- Where/how to define CDS rules?
Is CDS-Hooks a standard, is there any other standards?
- On which data to run the CDS rules: within OpenMRS itself (looks like that’s the Bahmni approach), or on transformed data out there in the analytics engine?
- If the latter, how does the analytics engine feed its outcome back to OpenMRS in a timely and robust way?
- Where exactly to feed the outcome in OpenMRS?
- How to display usefully the outcome alert/notification on the UI?
- How to silence/acknowledge/… the outcome alert/notification?
Hi. There are lots of things to talk about and lots that can be done, including complete solutions that are very complex and more practical starter solutions that are pretty simple. I’d be happy to co-facilitate a couple of discussions or threads to make this happen. A few notes:
- In-app CDS includes alerts (to stop errors, such as bad dosing), reminders (to let you know of missing items, like a vaccination that’s due), order sets, smart input forms that reconfigure themselves for the current patient, intelligent data summaries, and a few others. It’s going to be most useful and easiest to start with alerts and reminders – they have similar UIs (pop-ups for the most urgent, and notification lists for the rest).
- There’s a small number of triggers (places in the data workflow where you need to check rules) that will cover most use cases. Triggering on new orders, new lab results, new ADT events, and chart open (for reminders) goes a long way.
- Similarly, a small number of logic ‘primitives’ (compare result or observation to value, check if patient is on med, check if patient has a particular condition, check if patient has had a particular treatment) will cover most needs. There’s only about 10 or 12 main types, and it’s fairly easy to design a usable rule builder if you build around these building blocks. I haven’t seen the Analytic Engine, so I don’t know if that’s intended to be a rule builder.
- CDS Hooks is nice for connecting different types of systems together, and can be used as an underlying framework, but doesn’t add much to basic functionality. If you want a standard more appropriate for rule building, the current favorite is Clinical Quality Language (CQL), although we may not need to go into all of its detail at the start.
@ssmusoke, @paulamendola, @tejakancherla, @ddesimone – this might be a good topic for a design meeting or two.
Happy to see more people in our community interested in building CDS. I would be happy to part of the design and product development discussions.
I am very interested in getting the CDS discussions started. Please loop me in whenever we are ready to start.
Agreeing with @jteich here. My team has been doing a lot of CDS in US-based systems of late, and I think we would be better off in OpenMRS to aim for adoption of an appropriate CQL engine and use CQL for doing CDS. We could bring Bryn Rhodes into this discussion with his work that he is doing to turn the WHO clinical guidelines into machine readable guidelines for ingesting into tooling like OpenMRS.
Example of a CQL engine we could look at (used here in the states by AHRQ and CDC apps): https://github.com/cqframework/cql-execution/blob/master/OVERVIEW.md
If we can get some kind of discussion around CQL going with Bryn Rhodes, I think that could be quite valuable to the community. We’ve discussed CQL a bit on the analytics engine calls, but there are some questions about the performance characteristics of CQL relative to the volume of data we need to execute it against.
@grace, why don’t you and I get together by phone and set up some agenda items and times to get this group together at a design meeting or two, and see if we can make some headway as a group on a common and effective CDS capability. Separately, we can bring in Bryn for CQL conversation.
Hey @jteich! I thought that I’d give @grace a hand with organizing a Lightning Talk or a Design Forum around this. Since those sessions each have a slightly different purpose, I’ve started picking @grace’s and @ibacher’s brains about what they’d like to see come out of each. And it sounds like @janflowers has a good sense of what Bryn has presented in the past and what could be particularly valuable for us. I’d love to hear your ideas. Why don’t we try to connect later this week?
Happy to join the planning conversations as needed. Really appreciate your help @jennifer and your expertise @jteich!
Will do. Switching to email. Back to this page after we get some arrangements and a Doodle poll going.