Stream: workflow
Topic: Immunization CDS workflow
Craig Newman (Jan 03 2019 at 16:14):
Immunization recommendations for a given patient are typically based on immunization history and other patient related data (allergies, medical history etc). Immunization clinical decision support engines usually have access to the immunization history but often don't know about the patient's allergies, problems, occupation, etc. I'm trying to figure out how we could use FHIR to allow these CDS engines to access this type of information without having to store it long term in the local immunization registry. Based on my basic understanding of the workflow and communication patterns documented on the FHIR website, it seems like RESTFUL queries for conditions, allergies, etc would work. Furthermore, the US Core profiles seem like a good place to start. I'm hoping to get some input on the following questions/assumptions:
1) Has anyone implemented something like for immunization forecasting (or something similar)?
2) Is RESTFUL the best workflow pattern?
3) Given that US Core has created profiles we can probably reuse, what sort of documentation could we put together that would be useful for implementers? Is an IG warranted or is there some other way to document guidance in this area?
4) The CDS engine is usually creating the forecast in response to a specific query an EHR makes (using a v2 query message), but it seems like the CDS engine could query any system (like a local HIE) for patient related data. Does that seem reasonable?
Thanks in advance for any insight you can provide. I hope to attend Monday's FHIR workflow call if it's easier to have a discussion there (and there is time to address it)
Lloyd McKenzie (Jan 03 2019 at 16:18):
Happy to discuss on the Monday call. One question is what's the trigger for creating a new forecast?
Craig Newman (Jan 03 2019 at 17:14):
Typically a provider (doctor, pharmacy, etc) will send a v2 query message to the local Immunization Information System (IIS) when they see a patient. The IIS typically houses the CDS engine which then generates the forecast to send back in the v2 response message.
Lloyd McKenzie (Jan 03 2019 at 17:38):
So the trigger is "user wants to know the forecast"?
Craig Newman (Jan 03 2019 at 17:42):
yes. In theory, I guess it could be that forecasts could be generated for whole populations (eg. all children in the jurisdiction that are ready to start school in the fall) but the typical trigger is "provider wants a forecast for patient X"
Lloyd McKenzie (Jan 03 2019 at 17:47):
The key is that it's not a state transition in some other object - it's a user decision. That means that CDS Hooks isn't likely going to be a good fit as that leverages specific workflow points in an EHR, and this doesn't sound like it has such an injection point.
Craig Newman (Jan 03 2019 at 18:54):
I agree that CDS Hooks probably isn't appropriate (for a number of reasons).
Lloyd McKenzie (Jan 03 2019 at 21:35):
I'm curious what the other reasons would be.
Craig Newman (Jan 04 2019 at 12:47):
This part is pretty far removed from the provider workflow. It's largely something that happens within the IIS and so presenting a card back to the provider entails a lot more than just querying for clinical data to provide a more accurate forecast. There are similar discussions going on with the CDS WG regarding a different immunization forecasting IG that was balloted back in January. As well, the immunization community is very committed to the existing v2 workflows (and with good reason as they are well established and work well for their use cases). I want to be careful about how we start looking at how FHIR can complement existing v2 messaging and make sure it's clear that we aren't looking to replace their v2 interfaces. Starting to talk about CDS hooks and presenting data to providers could be seen as starting to encroach on the existing v2 query workflows and that may not get us off on the best foot.
Lloyd McKenzie (Jan 04 2019 at 14:48):
I always start with a default assumption of "FHIR everything". If the intent is to use v2 for some pieces, that's fine.
Last updated: Apr 12 2022 at 19:14 UTC
