Clinical Decision Support on FHIR
Last year, I wrote about the federal (US) Health eDecisions (HeD) initiative, which resulted in various standards for clinical decision support (CDS), including an XML schema for representing a “knowledge artifact” and a Virtual Medical Record (VMR) for representing patient data. In HeD, knowledge artifacts can be event-condition-action rules, order sets, or documentation templates. Since that time, a new federal initiative has been underway called the Clinical Quality Framework (CQF). This initiative seeks to harmonize standards for CDS and clinical quality measurement (CQM). With respect to patient data models, the CDS domain has the VMR, but the quality domain has something called the Quality Data Model (QDM). One of the goals of CQF is to harmonize VMR and QDM into a single model called Quality Improvement and Clinical Knowledge (QUICK).
OK, now stay with me – it gets complicated. In parallel to all this activity, HL7 has been developing a new standard for representing healthcare data called Fast Health Interoperable Resources (FHIR – pronounced like FIRE). FHIR contains conceptually simple resources, which can be represented in XML and exchanged using RESTful services. For example, there are resources for Condition, Medication, and Procedure. FHIR is currently a Draft Standard for Trial Use (DSTU).
At the HL7 meeting in Chicago, much of the discussion at the CDS working group was about the relationship between QUICK and FHIR. For example, why not just use FHIR directly and forget about QUICK? The consensus appeared to be that QUICK should be considered as a “view” of FHIR, in the sense that relational databases can have views to expose their underlying tables in ways that are useful for certain types of queries. For example, QUICK has a hierarchical structure, whereas the FHIR model is flat. Similarly, some QUICK classes have attributes that make certain queries easier to express, especially around dates, times, durations, and intervals. The thought is that if QUICK is optimized for inclusion in logical expressions, then as long as it can be mapped to FHIR in a deterministic manner, there’s no need to require CDS and CQM authors to write expressions against FHIR directly. FHIR could still be used to send patient data to a decision support service, but the execution engine would then do the necessary mapping in order to evaluate the QUICK-based CDS or CQM logic against the incoming FHIR data.
That’s the situation as I currently see it. I will try to keep you updated on this rapidly evolving discussion. We also had another ballot – Clinical Quality Language – but I will save that discussion for a future post. Hint: it’s a cool new language for writing logical expressions – if you’re the type of person who finds new computer languages cool!
You may also like:
Change can mean innovation and growth. But change can also mean disruption, high costs, and breakdowns in processes. For healthcare organizations that are looking to not just survive but thrive in the new economy, we took a loo...
The new health economy is here. Do you have the right knowledge resources in place? The rapid pace of innovation, the rise of consumerism, an aging population, and movement toward price transparency are placing sign...
Filter by Type
Sign up to receive the latest news and information!