Across the hall, several ONC funded Clinical Decision support project teams were meeting to discuss what was needed to standardize CDS for the 2016 Standards and Certification Criteria (which as Doug Fridsma reminds us, is really only 18 months away). There was quite a bit of back and forth at this session, led by Jacob Reider, and I certainly stirred up the pot in the afternoon session. But then again, I think they know what they were getting when I walked into the room.
Jacob had a great slide he was dynamically updating during the presentation that identified the various components of clinical decision support for which standards would need to be selected. Surrounding the various boxes in which the components were listed was a box which described the scope of this particular ONC (and soon to be S&I) effort with respect to standards. That box shrank and grew (and shrank again) as the discussion went on.
Blackford Middleton described five different kinds of CDS Interventions:
- Alerts
Think of this as the typical black-box or question/answer approach that most people not really familiar with CDS go to first. An alert is a notification that something is needed, not needed, appropriate, inappropriate, et cetera, based on some set of clinical data. It need not be a pop-up (in fact, shouldn't be in most cases). - Order Sets
A way to represent common things that need to be done under particular circumstances. - Info Buttons
Places where someone can ask for more information about a particular data item (or set of data items) being accessed. - Data Display A way to represent information that provides value (e.g., overlaying a plot of weight vs. Blood pressure)
- Documents
"Smart forms" is how Blackford describes this. Templates appropriate to a particular type of encounter or activity is a way that I might describe this.
In my thinking, the first three items are where we should focus our attention for Stage 3/2016 Standards and Certification Criteria. There's a lot more work done on these three than on the latter two, and given that we have only 18 months, we need to bite off a useful and meaningful chunk (pun intended), without trying to solve every last CDS problem there is. After all, anything left over we can address in stage 4 (only half joking here -- there's enough talk about stage 4 in policy circles that it could happen).
A lot of input to the discussions happened in the morning, and I missed most of it. Thankfully, I might add. In part, it was because most of what they discussed fell "above the line" on Jacob's chart (outside of scope). The chunk above the line talked about standards important to implement a modular, standards-based clinical decision support service, but did not standards that would be used to integrated that with an EHR.
My thoughts on this are very strong: I really don't care what language you use to represent knowledge, or how you implement your clinical decision support rules. What I want to know are three (or maybe four) things:
- At what points the CDS intervention wants to be triggered,
- What the gozinta's are (what data it wants to see),
- What the gozouta's are (how do I interpret what it sends back),
- What the (XML) format is for communicating items 2 and 3 above.
Gozinta and Gozouta refers to a previous post I made about process improvement and building measurement into a process, and its intricately tied into my thinking in this space. If you can tell me in a machine readable way (and NO, I do not mean an Excel spreadsheet), what data elements you are interested in, and how to represent that, then I can automate the outbound interface to the CDS service.
If you can tell me when to trigger it, then I can generate the message at the appropriate time. Finally, if you can tell me the list of different kinds of responses (proposals for or against this screening, diagnostic test, diagnoses, treatment, or suggested care, ask these additional questions), how they are to be interpreted, and the format in which they are represented, then I can provide appropriate feedback in an EHR.
If you can tell me when to trigger it, then I can generate the message at the appropriate time. Finally, if you can tell me the list of different kinds of responses (proposals for or against this screening, diagnostic test, diagnoses, treatment, or suggested care, ask these additional questions), how they are to be interpreted, and the format in which they are represented, then I can provide appropriate feedback in an EHR.
One of the cooler things that HL7 implemented in the HQMF standard was the data criteria section. As currently being implemented in the Query Health project, this section identifies just the data elements of interest for a query. In this context, it is a machine readable representation of a list of those data elements that could either be returned by the query, or used to identify specific items of interest.
In Query Health, we have a way to represent a description of problems, medications, allergies, encounters, procedures, demographics, et cetera, where we can specify the data element, and the specific code or value set, or range of relevant values associated with it. It is only those elements that are later used to evaluate the query.
I strongly recommended the content of the HQMF DataCriteria section to this CDS workgroup as being the way to represent the information requested in an exchange. In fact, I've even asked for the CCD requirements for the Partners CDS service that they are developing so that I can show them how to represent those requirements in a machine readable, unambiguous fashion.
I would also strongly recommend coordination with the other ONC S&I Framework efforts, including the Clinical Element Data Dictionary (CEDD or is it HDD now?) efforts coming out of Transitions of Care, Query Health and other workgroups.
Finally, just as IHE applied CCD templates to HL7 Version 3 messages, I would apply the Consolidated CDA templates to those data elements in a VMR implementation (presently a UML model in HL7) that used the HL7 Care Record messages as a concrete representation for exchange (now being reballoted as a standard).
On the gozouta side, I need to dig up the past work IHE did on Request for Clinical Guidance. Essentially what we did is describe how you would make suggestions in the Care Plan. So gozinta is essentially a message representation of the machine readable data in a Consolidated CDA document, gozouta is the same thing back, with suggested additions in the Care Plan (e.g., as suggested options for screening, treatment or diagnosis).
This could readily address both "Alerts" and "Order Sets", as the care plan could describe "alert" type responses, or suggested things that could be ordered. It simply depends on how the EHR expects to use those things as to whether the CDS intervention becomes an "Alert", or an "Order Set", as described in Blackford's classification above.
In the InfoButton space, IHE is already working on a profile. Join up, let's not duplicate effort.
This meeting was quite an interesting diversion for me. I might have to find a way to get to AMIA this year, just so I can be a fly in the ointment again.
-- Keith
P.S. Reminder to self: Finish reading Jerry's book on CDS and write a review.
I assigned myself an experiment after while the first part of this post this afternoon. How would I use the data criteria section of HQMF to represent a data set used for Clinical Decision Support. While I had asked someone to supply me with a set of data elements, and was going to follow up on this post, I realized about two hours ago (it's Oh-dark-thirty or so now) that it just so happens that I have a ready made list of data elements already created in this post (on what the summary care record should be for Meaningful Use Stage 2).
Here's the list of data elements:
(b) Standards When supplied in an electronic form, the summary care record shall be formatted according to the standards specified in §170.205(a)(3).
(1) Race and ethnicity. The standard specified in § 170.207(f)
(2) Preferred language. The standard specified in § 170.207(j)
(3) Smoking status. The standard specified in § 170.207(l)
(4) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3)
(5) Encounter diagnoses. The standard specified in § 170.207(m)
(6) Medications. At a minimum, the version of the standard specified in § 170.207(h); and
(7) Reserved (For Allergies)
(8) Procedures. The standard specified in § 170.207(b)(2) or § 170.207(b)(3)
(9) Immunizations. The standard specified in § 170.207(i)
(9) Laboratory test(s). At a minimum, the version of the standard specified in § 170.207(g)
Now, let's represent that list in a data criteria section. This first chunk defines model elements which will be referenced later. These model elements are simply handles onto different kinds of data, such as demographics, problems, allergies, et cetera. No matter what the Data Criteria, these definitions are the same and could readily be replaced by one line of XML directing you to a publicly available resource that could be "inserted" at that point using <xi:include>.
<dataCriteriaSection
xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="POQM_MT000001UV.DataCriteriaSection"
>
<code codeSystem="2.16.840.1.113883.6.1" code="57025-9"/>
<title>Data Criteria Section</title>
<text>This section describes the data criteria.</text>
<definition>
<observationDefinition>
<id extension="Demographics"
root="2.16.840.1.113883.3.1619.5148.1"/>
</observationDefinition>
</definition>
<definition>
<encounterDefinition>
<id extension="Encounters" root="2.16.840.1.113883.3.1619.5148.1"
/>
</encounterDefinition>
</definition>
<definition>
<observationDefinition>
<id extension="Problems" root="2.16.840.1.113883.3.1619.5148.1"/>
</observationDefinition>
</definition>
<definition>
<observationDefinition>
<id extension="SocialHistory" root="2.16.840.1.113883.3.1619.5148.1"/>
</observationDefinition>
</definition>
<definition>
<observationDefinition>
<id extension="Allergies" root="2.16.840.1.113883.3.1619.5148.1"/>
</observationDefinition>
</definition>
<definition>
<procedureDefinition>
<id extension="Procedures" root="2.16.840.1.113883.3.1619.5148.1"
/>
</procedureDefinition>
</definition>
<definition>
<observationDefinition>
<id extension="Results" root="2.16.840.1.113883.3.1619.5148.1"/>
</observationDefinition>
</definition>
<definition>
<observationDefinition>
<id extension="Vitals" root="2.16.840.1.113883.3.1619.5148.1"/>
</observationDefinition>
</definition>
<definition>
<substanceAdministrationDefinition>
<id extension="Medications" root="2.16.840.1.113883.3.1619.5148.1"
/>
</substanceAdministrationDefinition>
</definition>
<definition>
<substanceAdministrationDefinition>
<id extension="Immunizations" root="2.16.840.1.113883.3.1619.5148.1"
/>
</substanceAdministrationDefinition>
</definition>
<definition>
<supplyDefinition>
<id extension="RX" root="2.16.840.1.113883.3.1619.5148.1"/>
</supplyDefinition>
</definition>
OK, so now we have some demographics that we are interested in. I show how we'd specify that we are interested in the race, ethnicity, and preferred language of the patient, which are listed in my data set of things I need to know in order to perform some kind of CDS. Arguably, preferred language is not useful in this context, but age or gender might be. Take it as a given that I have SNOMED CT codes that allow you to specify those as well.
<entry>
<localVariableName>Race</localVariableName>
<observationCriteria>
<id extension="Race"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
<code displayName="Race"
codeSystem="2.16.840.1.113883.6.96" code="103579009"/>
<value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.6'/>
<definition>
<observationReference moodCode="DEF">
<id extension="Demographics"
root="2.16.840.1.113883.3.1619.5148.1"/>
</observationReference>
</definition>
</observationCriteria>
</entry>
<entry>
<localVariableName>Ethnicity</localVariableName>
<observationCriteria>
<id extension="Ethnicity"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
<code displayName="Ethnic Group"
codeSystem="2.16.840.1.113883.6.96" code="364699009"/>
<value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.6'/>
<definition>
<observationReference moodCode="DEF">
<id extension="Demographics"
root="2.16.840.1.113883.3.1619.5148.1"/>
</observationReference>
</definition>
</observationCriteria>
</entry>
<entry>
<localVariableName>PreferredLanguage</localVariableName>
<observationCriteria>
<id extension="PreferredLanguage"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
<code displayName="Language Finding"
codeSystem="2.16.840.1.113883.6.96" code="106133000"/>
<value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.10'/>
<definition>
<observationReference moodCode="DEF">
<id extension="Demographics"
root="2.16.840.1.113883.3.1619.5148.1"/>
</observationReference>
</definition>
</observationCriteria>
</entry>
This next criterion says that I'm interested in smoking status, and that it comes from the Social History part of the model.
<entry>
<localVariableName>SmokingStatus</localVariableName>
<observationCriteria>
<id extension="SmokingStatus"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
<code displayName="tobacco smoking behavior - finding"
codeSystem="2.16.840.1.113883.6.96" code="365981007"/>
<value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.12'/>
<definition>
<observationReference moodCode="DEF">
<id extension="SocialHistory"
root="2.16.840.1.113883.3.1619.5148.1"/>
</observationReference>
</definition>
</observationCriteria>
</entry>
This next criterion says that I'm interested in problems, and that it comes from the Problems part of the model.
<entry>
<localVariableName>Problems</localVariableName>
<observationCriteria>
<id extension="Problems"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
<value valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.1.3' xsi:type="CD"/>
<definition>
<observationReference moodCode="DEF">
<id extension="Problems"
root="2.16.840.1.113883.3.1619.5148.1"/>
</observationReference>
</definition>
</observationCriteria>
</entry>
I'll handle medications and immunizations together. The next part says that I'm interested in these and that they come from the medications and immunizations part of the model.
<entry>
<localVariableName>Medications</localVariableName>
<substanceAdministrationCriteria>
<id extension="Medications"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226984"/>
<participant typeCode="CSM">
<roleParticipant classCode="THER">
<code valueSet="2.16.840.1.113883.3.1619.5148.11.45.170.314.207.8"/>
</roleParticipant>
</participant>
<definition>
<substanceAdministrationReference moodCode="DEF">
<id extension="Medications" root="2.16.840.1.113883.3.1619.5148.1"
/>
</substanceAdministrationReference>
</definition>
</substanceAdministrationCriteria>
</entry>
<entry>
<localVariableName>Immunizations</localVariableName>
<substanceAdministrationCriteria>
<id extension="Immunizations"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226984"/>
<participant typeCode="CSM">
<roleParticipant classCode="THER">
<code valueSet="2.16.840.1.113883.3.1619.5148.11.45.170.314.207.9"/>
</roleParticipant>
</participant>
<definition>
<substanceAdministrationReference moodCode="DEF">
<id extension="Immunizations" root="2.16.840.1.113883.3.1619.5148.1"
/>
</substanceAdministrationReference>
</definition>
</substanceAdministrationCriteria>
</entry>
Now procedures:
<entry>
<localVariableName>Procedures</localVariableName>
<procedureCriteria>
<id extension="Procedures"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226985"/>
<code valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.2'/>
<definition>
<procedureReference moodCode="DEF">
<id extension="Procedures"
root="2.16.840.1.113883.3.1619.5148.1"/>
</procedureReference>
</definition>
</procedureCriteria>
</entry>
And labs:
<entry>
<localVariableName>LabResults</localVariableName>
<observationCriteria>
<id extension="LabResults"
root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
<code valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.7'/>
<definition>
<observationReference moodCode="DEF">
<id extension="Results" root="2.16.840.1.113883.3.1619.5148.1"
/>
</observationReference>
</definition>
</observationCriteria>
</entry>
</dataCriteriaSection>
This XML took me all of 15 minutes to craft (the remaining time has been spend writing the rest of this post). One of the reasons it went so fast is that there's a lot of repetition in this content, given the breadth of what stage 2 asks for in a summary record. So, while it's clear than for this data set you could simplify the XML, you may want the expressive power that I didn't show in this example for other CDS use cases (e.g., to limit the data element to the first/last of a series of identical measures, or within a given date range, et cetera).
Long time readers probably get it that I've already shown these data criteria as being sufficient to execute queries against a patient population in query health to compute counts of patients matching the measure criteria (another section of HQMF). Given a population of ONE patient this data criteria identifies the clinical data that a CDS system needs to compute with, and can be used by the EHR to locate it.
Once we've located the data, it's (as a former colleague liked to say), a simple matter of code to turn it into an XML message in some format. For CDS, I happen to like the HL7 Version 3 Care Provision message. In the HL7 V3 world these are almost equivalent to CDA documents (and I've even got a specification for how to transform from one to the other and back), except that they usually contain no narrative. So now I have a standard message format, a way to dynamically tell a system how to determine what goes in it, and from there, how to populate the content in the message.
What I've just described is a way, given a list of standardized data elements, to automate interface generation to a specialized CDS system, because it tells me (in that list of data criteria), how the interface should look.
What should I get back?
Well, I'd really like to see some proposals for screening, further diagnostics, new diagnoses, treatment that might be suggested, and references to the evidence supporting any of those. I use the term proposal quite advisedly. CDS systems propose, and depending on the implementation, either a provider or the systems decides what to do with this proposals. Proposal is a special mood in HL7 Version 3. Identifying something as a proposal is as easy as setting moodCode='PRP' on the acts returned by the CDS system. So, anything that shows up as PRP on output is what the CDS system proposes for the patient in response to the given data inputs.
There is something else that's pretty interesting that could be done. You could take the data in that message format, and the type of encounter, pick the appropriate document type from the CDA Consolidation guide, and populate it.
Oh my.
0 comments:
Post a Comment