Stream: implementers
Topic: STU3 Immunization Status
Samantha Mater (Feb 05 2019 at 17:26):
In STU3, Immunization has only "completed" and "entered-in-error" as allowed statuses. In DSTU2, there were more options ("in-progress, on-hold" etc) and it looks like in R4 there is an additional option "not-done". I'm working on implementing STU3 and I've got immunizations that are intended for future administration, or deferred -- so they're not completed, but they're also not errors. We also record when a patient refuses an administration -- also not completed, but also not an error.
How have others represented this data in STU3?
Lloyd McKenzie (Feb 05 2019 at 17:28):
@Craig Newman
Craig Newman (Feb 05 2019 at 20:13):
The Immunization resource documents the vaccination event itself which probably explains why "in-progress" was removed. An immunization event is essentially instantaneous and probably doesn't have a state of being partially done.
In STU3, Immunization. notGiven exists to indicate that the vaccination was not given. Presumably Immunization.status=complete and Immunization.notGiven=True would indicate a refused attempt at vaccination (hopefully with Immunization.explanation.reasonNotGiven populated).
In R4, we tried to align with the Event pattern and removed notGiven and added "not-done" to Immunization.status
One thing that we are discussing is how to document immunization orders. There are several gForge tickets on this topic and we discussed it in San Antonio. The current recommendation seems to be heading in the direction of using MedicationRequest to indicate the desire/intent to immunize and then enhancing Immunization in R5 to point back to MedicationRequest (or ImmunizationRecommendation). The MedicationRequest would be the only FHIR resource until the event actually happened at which point it would be documented with an Immunization resource.
At least within the immunization community in the US, most centralized registries (who receive data from providers, pharmacies, etc) don't like to get immunization data before the event actually happens (too often providers document "intent" to immunize like an actual immunization event and then never go back and fill in the details (or worse yet, don't indicate when that intent is never fulfilled)). This probably contributes to the idea that Immunization is about an event which happened (or didn't happen) rather than an intent.
@Joginder Madra may have more to add.
Lloyd McKenzie (Feb 05 2019 at 20:16):
Planned immunizations wouldn't be represented using Immunization - they'd use MedicationRequest.
Joginder Madra (Feb 05 2019 at 20:24):
The approach Craig describes is fairly typical for the immunization reporting that I'm most familiar with in Canada
Joginder Madra (Feb 05 2019 at 20:25):
..also patient refusals are considered to be "complete"
Craig Newman (Feb 05 2019 at 20:58):
There is probably a subtle distinction between "refused" vaccinations and "deferred" vaccinations. A deferral is typically a short term delay (the patient has a fever and so the vaccination is delayed until they feel better) where a refusal is likely something that would prevent a vaccination at any point in the future (medical exemption, religious exemption, etc). There is probably a fair bit of variation in how systems treat these. I've seen some systems that don't really distinguish between them (to these systems, the event didn't happen and it doesn't really matter why (although the why is often documented)). Presumably some system do distinguish between these.
Samantha Mater (Feb 06 2019 at 20:05):
What about immunizations that are only partially administered (such as if a child only receives a partial dose due to knocking the needle loose or some other interruption)?
Craig Newman (Feb 06 2019 at 20:31):
I'm not sure there is a good way to do it in STU3.
In R4, there is the isSubpotent element to indicate that a dose was given but may not be fully effective an the subpotentReason element to indicate why it's subpotent (partial dose, cold chain break, etc).
Lloyd McKenzie (Feb 06 2019 at 20:31):
In STU3 you'll probably need an extension
Craig Newman (Feb 06 2019 at 20:32):
I'm assuming the best practice would be to base the STU3 extension on what R4 looks like. Is that true?
Lloyd McKenzie (Feb 06 2019 at 20:33):
Yes. In fact, I belive there's an intention to define all of those. @Grahame Grieve ?
Last updated: Apr 12 2022 at 19:14 UTC
