CDS on FHIR

Yesterday I attended a meeting containing a blue ribbon panel of EHR and CDS standards geeks in a packed room at Children's Hospital, hosted by Josh Mandel, and attended by head FHIR chief Grahame Grieve.  Josh is probably the best example of a FHIR chief that we have in this country. His work on SMART is already being adopted by EHR systems and healthcare entities in this country. We talked about a new way to integrate clinical decision support into the EHR, which I'll describe below.

Essentially the idea is to have applications register with an EHR their desire to be notified at particular points in the provider workflow, and to request specific information be provided to them. Associated with the application registration are:

1. The service URL to invoke: [base]/$cds-hook
2. The identifier for the trigger event (e.g., medication-prescribe)
3. An optional pre-fetch template to obtain data to pass to the service URL in addition to the resource associated with the trigger event.

The service will pass back zero or more "action cards" which can be used to tell the EHR the advice given by the CDS service.  The EHR can decide on how to integrate that advice into the physician workflow.  You can find more details on Josh's wiki for the project.

This is quite cool, and works well with existing patterns of CDS use.  

1. Information action cards provide sort of an extended InfoButton capability.
2. Other action cards fit well within patterns established by FHIR Care Provision (e.g., ReferralRequest and ProcedureRequest), MedicationOrder, and Workflow (e.g., Order, DeviceUseRequest, SupplyRequest, etc.).
3. Still other action cards can integrate with a cloud-based or locally hosted HTTP service to provide additional user interaction, and be integrated into the EHR ala SMART kinds of interfaces.
4. Yet other action cards (discussed in the meeting, but not yet described on Josh's wiki) might support other capabilities within the workflow, perhaps to address the CDS integration itself. One example of this we discussed at the meeting was that when a service is not covered by a payer (as determined by one service), going into another service that looks at determining medical necessity might not be needful).

A couple of comments come to my mind when looking at this:

1. I'll bet I can find hundreds of trigger events and associated contexts for CDS from HL7 Version 2, Version 3, InfoButton, HITSP, IHE and other specifications.  This is more of a data mining exercise for trigger events than anything else.
2. Separately, each trigger event may want to be associated with one or more principle resources that describe the data associated with the trigger event.  For example, for the medication-prescribe event listed above, the likely candidate would be MedicationOrder.
3. The way that the pre-fetch template works is a quite generalizable mechanism that supports many different integrations.  

That last comment deserves a lot more expansion, because I think it is the keystone to advancement in many standards.

This mechanism generalizes specific templates for sending data for an integration.  For example, this is how IHE had previously integrated forms based data capture in the Request Form for Data Capture (RFD) profile, with the needs for specific data as described in the Clincial Research Document (CRD) profile.  A similar mechanism has been used by CDS implementors by providing recommendations based on the content of a Virtual Medical Records (VMR) delivered through a CCD document.  It would also work quite well to specify the data requirements for a quality measure. By "registering" the pre-fetch bundle with the EHR, the CDS system allows the "question" to come to the data (as we did for Query Health), and the EHR to decide (based on the policies of its organization) how to respond to this query.  

Fortunately, this meeting came at a time when both CDS and Clincial Quality Measures in FHIR are currently being discussed in HL7, and can so impact both of those activities prior to them becoming DSTUs.  I'll very likely be making this point next week at the working group meeting in Atlanta, but if I don't I can count on many of the luminaries in the room yesterday to also do so.

I was thrilled to be invited to this event, and am really grateful for Josh's continuing his past outstanding work.  He is clearly no "one-shot" wonder, and I look forward to his future contributions to the world of standards.

   Keith

P.S. One of the values we have in the "slow-down" of ONC on the development of standards is the luxury of time to do things right, instead of against an arbitrary deadline.  That makes me hopeful that CDS, instead of being the unfindable Holy Grail of EHR integration, would instead become a commonplace mechanism for building the best EHR system one could imagine.