CDS Hooks for FHIR is about hooking a trigger event, such as the creation of a prescription or other order. When I thought about this, I was reminded of event driven programming models in the early days of window-based application development. Anyone who has ever written user interface code for Windows, the Mac, or X-Windows is familiar with the ever pervasive event loop. In fact, many UI development models today still have an event loop somewhere in their midst, it's just better hidden.
So, what events would we want to hook? Josh is incredibly focused on reality, and so has limited his examples to three common events. I was a bit more curious, because CDS is NOT the only thing that may want to hook into the EHR system. In HL7, we have a plethora "trigger events" and associated payloads already specified in the HL7 Version 2 and Version 3 standards.
HL7 Version 2 describes a trigger event as something that "... creates the need for data to flow among systems." (see section 2.3.1 of HL7 Version 2.8.2).
In HL7 Version 3: "A trigger event is an explicit set of conditions that initiate the transfer of information between system components (application roles). It is a real-world event such as the placing of a laboratory order or drug order. The trigger event must be systematically recognizable by an automated system." (See Section 3.4 of the HL7 Version 3 Guide).
The 2015 Normative edition of Version 3 describes more than 700 trigger events across some 60 separate specifications from nearly two dozen working groups. While you might expect to find a complete listing of these in the HL7 V3 code system Trigger Event ID, you won't. Instead, you'll have to search across all the specs. You can find an XSL Transform that will grab the essential data here. It may not be perfect, but it gets quite a bit from the Normative edition. The same thing should also work from any downloadable V3 collection, including a ballot draft. Associated with the trigger events are some 60 odd "Message Types" which focus on a RIM class related to the message.
HL7 Version 2.8.2 defines some 300+ trigger events, 200+ message structures, and around 150 message types. You can find these in Chapter 2C - Control Code Tables, in tables 0003 Event Type, 0354 Message Structure and 0076 Message Type.
The HL7 EHR Functional model also describes some functions that could be useful for identifying trigger events. Essentially any verb/object pair in the EHR FM could identify a trigger event and the associated payload. IHE specifications also identify trigger events, but a clever person might recognize that since these are almost all based on HL7 or DICOM messages or services, that a complete list from those sources would cover the IHE work.
Getting the same information out of DICOM is perhaps a bit more challenging (for me at least). I'm sure it's there (because DICOM has some very well structured specifications), but I don't really know where to look. SOP Classes seemed like a good start since they combine a service with an information object definition, but I don't really know how to read those definitions, and there may be a better way to mine trigger events from DICOM. Hopefully a DICOM expert might chime in on this.
As a result of my data mining, I've got over 1000 trigger events to look at, each associated with a data structure that I can map (in most cases) to one or more principal FHIR resources. For example, A01 Admit/visit notification clearly associates with Encounter. There are some messages that don't have a good mapping to a FHIR resource, often because those resources don't exist yet in DSTU 2 (e.g., Consent).
I'm still in the analysis process with this data, when I get it a little bit further along, I'll share more. For now, you at least know where to find it, and can follow along if you'd like.
-- Keith
So, what events would we want to hook? Josh is incredibly focused on reality, and so has limited his examples to three common events. I was a bit more curious, because CDS is NOT the only thing that may want to hook into the EHR system. In HL7, we have a plethora "trigger events" and associated payloads already specified in the HL7 Version 2 and Version 3 standards.
HL7 Version 2 describes a trigger event as something that "... creates the need for data to flow among systems." (see section 2.3.1 of HL7 Version 2.8.2).
In HL7 Version 3: "A trigger event is an explicit set of conditions that initiate the transfer of information between system components (application roles). It is a real-world event such as the placing of a laboratory order or drug order. The trigger event must be systematically recognizable by an automated system." (See Section 3.4 of the HL7 Version 3 Guide).
The 2015 Normative edition of Version 3 describes more than 700 trigger events across some 60 separate specifications from nearly two dozen working groups. While you might expect to find a complete listing of these in the HL7 V3 code system Trigger Event ID, you won't. Instead, you'll have to search across all the specs. You can find an XSL Transform that will grab the essential data here. It may not be perfect, but it gets quite a bit from the Normative edition. The same thing should also work from any downloadable V3 collection, including a ballot draft. Associated with the trigger events are some 60 odd "Message Types" which focus on a RIM class related to the message.
HL7 Version 2.8.2 defines some 300+ trigger events, 200+ message structures, and around 150 message types. You can find these in Chapter 2C - Control Code Tables, in tables 0003 Event Type, 0354 Message Structure and 0076 Message Type.
The HL7 EHR Functional model also describes some functions that could be useful for identifying trigger events. Essentially any verb/object pair in the EHR FM could identify a trigger event and the associated payload. IHE specifications also identify trigger events, but a clever person might recognize that since these are almost all based on HL7 or DICOM messages or services, that a complete list from those sources would cover the IHE work.
Getting the same information out of DICOM is perhaps a bit more challenging (for me at least). I'm sure it's there (because DICOM has some very well structured specifications), but I don't really know where to look. SOP Classes seemed like a good start since they combine a service with an information object definition, but I don't really know how to read those definitions, and there may be a better way to mine trigger events from DICOM. Hopefully a DICOM expert might chime in on this.
As a result of my data mining, I've got over 1000 trigger events to look at, each associated with a data structure that I can map (in most cases) to one or more principal FHIR resources. For example, A01 Admit/visit notification clearly associates with Encounter. There are some messages that don't have a good mapping to a FHIR resource, often because those resources don't exist yet in DSTU 2 (e.g., Consent).
I'm still in the analysis process with this data, when I get it a little bit further along, I'll share more. For now, you at least know where to find it, and can follow along if you'd like.
-- Keith
I've updated the colors and fonts to make the blog easier to read. Let me know if you like the new scheme.
I like the new scheme; choices for colors and fonts DOES make the blog easier to read. Content remains top shelf. Thank you and keep going strong!
ReplyDelete