I thought I’d add a couple of notes here as there was a highly relevant call in the OpenHIE Terminology Services group yesterday. In particular, this call had presentations from Garret Mehl at the WHO and Mike Gehron at PEPFAR. The full notes and recordings for this call can be found here.
Some key points from my perspective:
The WHO is basing their “Smart Guidelines” work on CQL. The “Smart Guidelines” are envisioned to be machine-readable and potentially executable versions of the WHO clinical guidelines. For more on that project, see this presentation.
PEPFAR are also keen to use CQL to standarise their indicator calculations, though they aren’t there yet. Their main focus has been on providing infrastructure to allow standarised calculations of indicators based on patient level data. This is the work that has been variously referred to as “Patient Level Indicator Report”, “Patient Level Monitoring”, and Digital Square’s “Notice D”.
Much of this work depends on OCL for harmonising across different concepts stored in different systems, and while that work is obviously of less use to individual implementors, it is something worth tracking to enable OpenMRS to develop reusable CDS components.
While the PEPFAR component of this is less directly relevant to CDS, it seemed important to highlight that support for CQL in various components of OpenMRS is likely something we should be thinking about.
@ibacher, thanks for the links above. I do see some groundswell of support for CQL, between what you have shown, NCQA guidelines in the USA, and one or two others.
Having been the one who first mentioned it in this thread, I do worry about the complexity of CQL (it’s a little bit of perfect being the enemy of good) and the fact that it’s about the fifth such standard for CDS logic to rise up in my career, and the other four have fallen aside. So, I’m still in support of working with Bryn and others to see how to make something reusable and configurable, which is what the rest of the WHO presentation was all about. I may still want to make a case that using a few, well-defined, easy-to-understand logic building blocks for test results, medications, patient characteristics, etc., may give us a lot more usable results faster. But we can explore that in the discussions to come – maybe there’s a way to use them as a front end to CQL (I was a small part of CDS Connect which did just that).
We’re trying to schedule a “CDS Showcase session” in the next couple of weeks and then a separate session on what is happening with CDS generally, where we can bring Bryn and others in.
Let me know what your availability is like by taking this Doodle poll:
I’m very interested in helping in a strategy for CDS for OpenMRS.
I’m not able to access the form.
Agree wholeheartedly. The most powerful and sophisticated CDS I’ve seen was Clem’s G-CARE, where the output of logic was coerced into the same form as an observation (i.e., time & value pairs). That approach allowed “observations” like CARDIAC RISK SCORE to be treated just like SERUM CREATININE and increasingly complex calculations to be layered in a very intuitive way (e.g., you could define LAST PLATELET COUNT and LAST LIVER TRANSAMINASES and then use those to calculate a FIBROSIS INDEX). This ingenious design also cleanly separated the logic from the actions, biasing me against CDS approaches that create tight coupling between knowledge and a specific action.
I also pray that we can avoid the all too common mistake of equating decision support with interruptive user interfaces (e.g., pop-up alerts) that disrupt users after a decision is made instead of supporting them during decision-making. For example, knowing an action is potentially dangerous and decorating the choice to deter selection is much better than waiting for the choice to made and then telling the user why they shouldn’t have selected it. Would you want to find out which parachute wasn’t inspected before or after you’ve chosen one?
I’ll be on holiday next week, so will look forward to watching a recording of the CDS showcase.
I love this approach and it makes so much sense as it allows varied analysis over time, and can help in the retrospective sense for case followup even where point of care is not used.
The decoupling also means that not only CQL but other mechanisms/tools can also be used to build the decision support analysis
