Stream: implementers
Topic: immunization
Grahame Grieve (Oct 23 2018 at 14:39):
@Craig Newman I am looking at Immunization again for a project that is using it. Immunization.protocolApplied.targetDisease is still 1..1... why? In most u I've seen, you have a doseSequence, and maybe a series, and no specified target disease. We've already discussed this - it should be optional. @diego kaminker - please ask locals to chime on this one
Craig Newman (Oct 23 2018 at 15:18):
I believe our thinking was that because protocolApplied itself was 0..*, that we only needed a single targetDisease per protocol. A given administration might satisfy multiple protocols - for example Twinrix contains both HepA and HepB and so a dose of Twinrix would satisfy both Hepatitis A and Hepatitis B protocols but that each protocol would be distinct and apply to a single disease.
Under what circumstances would a target disease not be known/relevant for a protocol? It seemed like it was core to the protocol and therefore we required it. What is the purpose of the protocol if not to provide protection to at least a single disease.
We actually have a similar gForge ticket #17773 for ImmunizationRecommendation.recommendation.targetDisease asking it to be changed to 0..*. We'll likely find that persuasive for the case where a particular vaccine is indivisible. For example the MMR vaccine is against measles, mumps and rubella and individual vaccines are not available. Would this logic also apply here?
@Joginder Madra can add his two cents as well.
Joginder Madra (Oct 23 2018 at 20:05):
Not much to add other than have things within ProtocolApplied be 0..1 would allow for being very granular with information - e.g. this is dose 1 for measles, but dose 2 for mumps and dose 1 for rubella. The question is do need to communicate like that.
Grahame Grieve (Oct 23 2018 at 20:41):
The issue is that all the survellience programs I've seen - national ones - routinely collected doseSequence, and not target disease. That is considered to be implied by the protocol, not not cared about. If R4 forces you to have targetDisease if you want dose sequence, and implementers don't know the targetDisease ,what do they do?
- don't use FHIR
- use an extension for doseSequence (non-conformant)
- make up a pretent targetDisease (bad)
- leave targetDisease out (non conformant)
I hope you don't prefer that the answer be #1: FHIR is not suitable for national immunization reporting.
Grahame Grieve (Oct 23 2018 at 20:42):
Please fix this for R4 (which means: ASAP). @Craig Newman @Joginder Madra to me this feels like best practice desire running into the reality that target disease is usually considered implied
Craig Newman (Oct 23 2018 at 21:56):
I agree that #1 is not the right answer
@Grahame Grieve the protocol being followed is indicated by Immunization.protocolApplied.series right? If so, it doesn't seem ideal to have to infer a coded concept like a targetDisease from a string element like series. If a target disease is implied by the protocol, how much of a burden is it to declare it explicitly in a coded fashion?
Grahame Grieve (Oct 23 2018 at 22:12):
it's an incredible burden for most users, since they are writing adapters that take existing messages and databases that do not have the target disease and converting to FHIR. Further, the protocol is not published in a computable form, and even if it were, the implication is something that specialists can do, sometimes only by hand. Even if it were possible to infer it computably, the provision of the data element is not believed to have any value, and it might cost many millions to (a) populate it correctly and (b) check that all implementations are populating it correctly.
THe principle should be clear in FHIR: if some existing implementations are not populating the element, committees should not make it mandatory except in the most compelling circumstance (no matter how much they think it's a good idea or best practice)
Craig Newman (Oct 23 2018 at 22:18):
Is there a gForge ticket necessary for this sort of change? I might need a bit of help as I've not successfully applied a change yet with TortoiseGit yet. I think I've got it all set up but haven't had the guts (or time) yet to pull the trigger.
Grahame Grieve (Oct 23 2018 at 22:19):
I can make a gForge ticket for it. I will now. GitHub questions - take them up on https://chat.fhir.org/#narrow/stream/138-committers.2Fgit-help
Craig Newman (Oct 23 2018 at 22:21):
Sounds good.
Grahame Grieve (Oct 23 2018 at 22:24):
Richard Townley-O'Neill (Oct 24 2018 at 00:56):
A STU3 implementation could use {"system":"http://hl7.org/fhir/v3/NullFlavor","code":"NAVU","display":"Not available"} for target disease.
Richard Townley-O'Neill (Oct 24 2018 at 01:00):
Optional is better.
Lloyd McKenzie (Oct 24 2018 at 03:27):
Any time systems use "not available" and a receiving system has a hope of successfully processing the instance, it means the design of the resource is broken. If it's not information that must exist for the instance to be useable in any of its possible use-cases, the min cardinality should be 0 - regardless of expected or desired practice. (Good practice is covered by "good practice" invariants.)
Craig Newman (Oct 25 2018 at 20:25):
@Grahame Grieve - please confirm you are looking for the targetDisease cardinality to be 0..1 (or do you prefer 0..*)
Grahame Grieve (Oct 26 2018 at 13:13):
I don't have any sense of what the upper cardinality should be.
Grahame Grieve (Oct 26 2018 at 13:13):
Just that the lower one should be 0
Craig Newman (Oct 26 2018 at 14:44):
@Grahame Grieve I applied the change (https://github.com/HL7/fhir/pull/149) to Immunization.protocolApplied.targetDisease. Please take a look and make sure it meets your needs. Thanks.
Grahame Grieve (Oct 26 2018 at 14:44):
ok thanks.
Grahame Grieve (Oct 26 2018 at 14:50):
yes looks good to me. I see that we still have the split between integer/string - is that landed yet?
Craig Newman (Oct 26 2018 at 14:53):
We didn't have a chance to get to that on yesterday's Public Health call (It was tough to squeeze in the targetDisease discussion). How critical do you think the integer/string issue is? Does that need to be in R4? I'm assuming changing the data type would be substantive but would removing the search parameter (which we've already done for Immunization and ImmunizationEvaluation) be something we could do in early November?
Grahame Grieve (Oct 26 2018 at 14:56):
it's a subtantive change, yes. So it should be done this week.
Grahame Grieve (Oct 26 2018 at 14:56):
but I'd rather have it done late than not done, I think
Craig Newman (Oct 26 2018 at 14:57):
I will see if we can address it on the Nov 1 PH call. If so, I should be able to make whatever change is required next Friday (Nov 2)
Grahame Grieve (Oct 26 2018 at 14:58):
that would be good, thanks
Vishak OS (Mar 15 2019 at 16:50):
I'm working on generating the FHIR Immunization Resource (STU3) from a CCDA 2.1.
I have trouble mapping the
1. Path: Immunization - Site in FHIR STU3: For populating this path from a CCDA 2.1, i'm planning to get this information from the approachSiteCode .
The codes that I get from this approachSiteCode is different from the one that's listed in the FHIR value set.
CCDA Path : (Immunization -> entry -> Substance Administration -> approachsiteCode)
FHIR Value Set : Immunization Site:- http://hl7.org/fhir/STU3/valueset-immunization-site.html
CCDA Value Set: It's for Body Site
( http://ccda.art-decor.org/ccda-html-20150727T182455/voc-2.16.840.1.113883.3.88.12.3221.8.9-2013-01-31T000000.html )
Can someone shed some light on this scenario to map the Immunization.Site from CCDA 2.1.
Grahame Grieve (Mar 15 2019 at 18:49):
the FHIR codes arean example binding. We can't specify the snomed binding that CCDA does internationally.
Grahame Grieve (Mar 15 2019 at 18:53):
any US profile of immunization will. except I see that https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-immunization.html doesn't - @Eric Haas
Dongtu (Nov 27 2019 at 15:37):
Hi everyone!
There are some infomations:
- Number of shots tetanus vaccinated by the mother
- Babies have neonatal tetanus protection ?
- Is the child fully immunized?
How present them in fhir ? mapping to Resource ?
Thanks all
Craig Newman (Nov 27 2019 at 19:54):
Please make sure you look at the guidelines for asking questions at https://wiki.hl7.org/index.php?title=FHIR_Rules_for_asking_questions
Should look at the immunization related resources (Immunization, ImmunizationRecommendation and ImmunizationEvaluation (this one is only in R4). These should answer most of your questions.
The hardest one is "is the child fully immunized?". The answer to this will depend on which guidelines you go by (the recommendations for the US may be different than those in Russia or India, etc. This determination is typically done by a clinical decision support engine and then the "recommendations" represented in an ImmunizationRecommendation. This sort of evaluation and recommendation is usually done only as needed because the answer varies as the patient ages, guidelines change, etc
Jose Costa Teixeira (May 12 2020 at 21:26):
More questions about immunization:
- Suppose that protocol mandates 3 doses, but patient has skipped #2. By the time the patient should take 3rd dose, it's their second. What is the value of doseNumber? I presume it's 3, and we must create an immunization instance for #2 with status not-done - correct?
Jose Costa Teixeira (May 12 2020 at 21:27):
- How does the doseNumber look like, when the schedule is "when pregnant"?
Jose Costa Teixeira (May 12 2020 at 21:32):
- Can we have Location as a CodeableReference like CarePlan.activity.detail.location?
Same rationale: Concepts like "at the patient's home" would deserve a code
John Silva (May 13 2020 at 00:44):
Isn't there something like 'N/A' (Not Administered - Completion Status) that can be used to indicate an admin was not given (and there a place to put reason why?)
Lloyd McKenzie (May 13 2020 at 00:53):
There's a "not-done" status
Craig Newman (May 13 2020 at 13:36):
The dose number is always tricky because it can be interpreted different ways. There is simply a count of the number of doses of a given vaccine but that's nothing more than a count of Immunization resources (although this gets tricky because different vaccines have different formulations (eg, a patient gets a dose of HepB and then a dose of Twinrix (HepA/HepB) so what dose number is Twinrix??).
Peter Muir (May 13 2020 at 13:39):
In your scenario, clinically and from patient point of view it would be considered dose 2 with dose 3 still outstanding. There is risk it it being considered as dose 3. P Muir MD
Craig Newman (May 13 2020 at 13:41):
More frequently, the "dose number" is relative to a set of guidelines produced by someone. These (in my experience in the US) are rarely discrete, machine computable guidelines (although the CDC's CDSi project does a really good job at making them so). But a given Immunization resource has a variable dose number depending on what set of guidelines it's compared to which is why we have ImmunizationEvaluation as a resource). For example, an infant gets vaccinated with MMR at 10 months, 12 months and 18 months. Technically, there are 3 doses, but when compared to the CDC's recommendations there is only one valid dose (the dose at 12 months is "dose 1 in the MMR series) because the first one was to early for recommended dose 1 and the last one was too early for recommended dose 2. But compared to the "infant travelling internationally before the age of 1 year" recommendation, the first dose may in fact be valid for that recommendation (but still invalid for the standard series).
Craig Newman (May 13 2020 at 13:43):
In your specific example, I don't think you'd want to document a missed dose unless it was offered and refused for some reason. Often the recommendations offer multiple paths to presumed immunity and it doesn't really matter which path is taken (although the one that gets the patient to presumed immunity the fastest is typically the favored one).
Craig Newman (May 13 2020 at 13:44):
I would expect the "not-done" status to primarily be used for instances where the dose is offered and refused (either the patient says no or there is some clinical precaution or contraindication that makes it best to wait)
Craig Newman (May 13 2020 at 13:47):
Some doses also don't have a dose number. The most common examples are boosters (tetanus, meningitis, etc) and yearly vaccines (influenza). Here there is no upper limit to the number of doses (you don't know how long someone will live). This is why the dose number element allows string to be captured. Pregnancy is a little different, I tend to think of it as a one dose series and so it's dose 1 but the patient may be recommended for that one dose series multiple times over her lifetime (once per pregnancy). It gets a bit grey.
Craig Newman (May 13 2020 at 13:48):
Your suggestion for .location seems reasonable. Feel free to write up a Jira ticket and we'll put it on the list to consider.
Nathan Bunker (May 13 2020 at 13:57):
Just to concur what Craig and Peter have said. There is no clinical concept of "missing" a second dose, rather the patient is just late in receiving the second dose. The concept of "missing" might be used in a retrospective analysis of patient administrations in general to note that patients who appeared in clinic are not receiving doses on time, but this would not be applied to the patient record. Analysis of "up-to-date" on immunizations does not use the dose number but rather the dates when each vaccination was given. The idea of doses being in a series, and having dose numbers, is really just an organizational concept that the clinician and patient can readily understand and simplify the schedule. The real schedule depends on the actual dates given.
Jose Costa Teixeira (May 13 2020 at 14:02):
thank you
Jose Costa Teixeira (May 13 2020 at 14:42):
Just a minor remark: The immunization route value set is
http://build.fhir.org/valueset-immunization-route.html
but for medication and allergyIntolerance, another different set is used - with SCT codfes.
http://build.fhir.org/valueset-route-codes.html
I know these are just examples and the value sets will be different - but would be interesting to keep consistency in our examples
Jose Costa Teixeira (May 13 2020 at 14:43):
BTW, @Grahame Grieve
http://build.fhir.org/valueset-route-codes.html is also used in a datatype (Dosage.route) but the "magic" that populates "This value set is used in the following places" is not picking that up
Jose Costa Teixeira (May 13 2020 at 16:22):
Craig Newman said:
In your specific example, I don't think you'd want to document a missed dose unless it was offered and refused for some reason. Often the recommendations offer multiple paths to presumed immunity and it doesn't really matter which path is taken (although the one that gets the patient to presumed immunity the fastest is typically the favored one).
Or scheduled but not possible to give - the "not done" reasons here are the same as we have (likely taken from the FHIR value set)
Jose Costa Teixeira (May 13 2020 at 16:24):
And those I would like to register
Jose Costa Teixeira (May 13 2020 at 16:25):
http://build.fhir.org/valueset-immunization-status-reason.html
Jose Costa Teixeira (May 13 2020 at 16:26):
I do find this strange (possibly a cultural thing):
vaccine safety concerns:The patient or their guardian objects to receiving the vaccine because of concerns over its safety.
Jose Costa Teixeira (May 13 2020 at 16:26):
is this "I read on the internet"?
Jose Costa Teixeira (May 13 2020 at 16:27):
Specifically, this is a) Patient objection (whatever reasons, i.e. please spare the nurse or physician about mercury and autism)
Jose Costa Teixeira (May 13 2020 at 16:27):
or b) someone - not specifically patient or guardian - has some concerns about safety.
Jose Costa Teixeira (May 13 2020 at 16:31):
if this is
- "you are going to a danger zone, we cannot give you this vaccine less than a month before departure" - it is contraindication
- "this vaccine has some issues because I (the real doctor) got a call from the supplier or my colleagues - then it is contraindication(?)
- "i (the doctor) am unsure about safety, so I put it to you as a patient who must decide" - and then the patient can object or not.
Jose Costa Teixeira (May 13 2020 at 16:31):
Am I missing the reason behind that last value?
Craig Newman (May 13 2020 at 18:14):
We did skinny down the immunization route value set because there are fewer ways to give a vaccine and we thought it best, even in an example value set, not to set a potentially wrong example by including routes that wouldn't be appropriate for a vaccine.
Jose Costa Teixeira (May 13 2020 at 19:05):
I agree with it being subset, the thing that triggered me is that the values are different - one uses SNOMED codes, the other uses a different set of codes
Nathan Bunker (May 15 2020 at 17:42):
I don't know the http://build.fhir.org/valueset-immunization-status-reason.html code set, but I can speak to what the meaning of the codes might be. All of the codes that have a definition that starts with "The patient or their guardian objects..." are an overlapping set of concepts that simply indicate that the patient/parent object to receiving a vaccination that the patient is indicated for and thus should receive now. The distinctions between these are subtle semantics with little impact on the logic of giving vaccinations. Where they have the biggest impact is on local legislation for school entry. US states will define rules to exempt students from receiving vaccinations for various reasons. These concepts then are a loose set of concepts collectively drawn from these regulations. But in the end, no matter the reason for not administering it, the patient is still not protected from the disease. IIS systems may receive this information but will continue to recommend the patient receive their next needed doses.
Here are my responses to the scenarios you give above:
"you are going to a danger zone, we cannot give you this vaccine less than a month before departure" - it is contraindication
Normally would expect to not receive any information on vaccination history, it would simply show the vaccination not given. No need to record the contraindication.
"this vaccine has some issues because I (the real doctor) got a call from the supplier or my colleagues - then it is contraindication(?)
If the vaccine itself was bad, then it would be disposed out of the stock and not be available for administration. Then if patient's came in for vaccinations there might be an out-of-stock situation. The patient might be referred to another location, or told to reschedule, or stock might be borrowed from somewhere else. In the end, if no vaccination was given, then no information would be recorded on the patient's record. The status of bad vaccine becomes more relevant on the patient record when patient has already received the vaccination but later information indicates that that vaccine was damaged/compromised. So the patient needs to be immunized with that dose again. This dose can then be marked as not valid and so recommendations can be made again for additional doses.
"i (the doctor) am unsure about safety, so I put it to you as a patient who must decide" - and then the patient can object or not.
I haven't seen coding for indicating that the doctor was concerned about the safety of vaccinations. Even if a doctor was concerned, I don't think that would be recorded. A vaccination given assumes that the clinician and the patient/guardian agreed that the vaccination was appropriate to be given at this time. If the doctor had concerns about giving a specific vaccine to a specific patient then this would simply not be given and not recorded on the record. Other medical conditions that might lead to this decision might be recorded on the record, but do not need to be tied to a non-immunizing event.
Jose Costa Teixeira (May 15 2020 at 18:30):
thanks. So "The patient or their guardian objects to receiving the vaccine because of concerns over its safety" is not really a clinical thing but a social thing? I can understand that, I was just assuming that "patient refuses" does not need to be detailed because I don't see the impact behind that (my starting point was that the patient's or guardian's opinions about a vaccine safety is usually not really relevant).
Jose Costa Teixeira (May 15 2020 at 18:30):
(but I may be missing something. So it's ok, i just won't use these codes)
Erin Daves (Jun 02 2020 at 19:14):
We are working on mapping Immunization flat file into FHIR. The flat file can either contain a CVX code OR a CPT code. We are mapping the CVX code to Immunization.vaccineCode & we’re going to reference our to Procedure through Encounter for the CPT code. If we don’t get a CVX code, is it appropriate to go directly to the Procedure resource rather than through the Immunization. These CPT codes are vaccine codes which is why we want to use the immunization resource. Is there a best practice for this scenario?
Lloyd McKenzie (Jun 02 2020 at 19:22):
It's not wrong to put both the CVX and CPT code in .vaccineCode (and if you have both, just create two codings)
Erin Daves (Jun 02 2020 at 19:30):
Thank you Lloyd! Couple things I should mention....
1) we could get both & .vaccineCode is 1..1
2) we have 3 dates in total (if we get Both) we need to Map all 3.
3) if we get the CPT only we have 2 dates- that we need to map, which is one of the reasons we used encounter & procedure to begin with. Immunization.occurrence only allows for 1..1 as well.
Appreciate your quick response!
Rob Hausam (Jun 02 2020 at 19:39):
Immuniation.vaccineCode being 1..1 isn't a problem, because the CodeableConcept data type allows for multiple Codings, as long as the code in each Coding instance is intended generally to mean the same thing (allowing for differences in granularity between different code systems) - e.g. the CVX and CPT codes for the same vaccine administration. I'm not seeing why if you have both codes you have an additional date that you need to map (if that is what you mean)? As I mentioned, both codes should be referring to the same vaccine administration event. Maybe you can clarify that?
Erin Daves (Jun 02 2020 at 20:13):
Thanks Rob!!
Part of the reason why we cannot translate is because these codes are not sent all the time.We have a file that can have three dates and two codes coming in or it can be just a code and one or two dates. When the cpt codes are sent, we have a service date and a from date. When the cvx code are sent, they send an admit date. We have a need to accommodate all three dates when both codes are sent in the file. We proposed having an immunization resource which has the occurence date to capture the admit date and cvx code and to have an encounter and procedure resources to capture the from date, cpt code and service date.
Craig Newman (Jun 02 2020 at 20:41):
Immunization.occurrence should be the date the vaccine was administered. The exact date of administration is important for evaluating the validity of the dose and forecasting when the next dose is recommended. It seems like something like an admit date could be some number of days prior to the actual administration date which wouldn't be good. If you have other types of dates (admit date, "from" date (not sure what that is), etc) then would an extension on Immunization be appropriate (presuming you are creating Procedure and Encounter primarily to hold those other date types)?
Craig Newman (Jun 02 2020 at 20:44):
I'll also mention that the CDC maintains a translation from CPT to CVX (but in this direction only) if it makes more sense to convert your CPT to a CVX and consistently send a CVX code. Sometimes granularity is lost (multiple CPTs map to a single CVX code) but if it's better to send a consistent type of code, it may be an option provided that it's not critical to maintain a record of the original CPT code.
https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cpt - if you use this, be sure to read and understand the intent of the table at the top of the page and make sure it is consistent with your needs.
Erin Daves (Jun 02 2020 at 20:52):
Thank you! We will look at using the extensions.
Appreciate all the feedback, new to this so appreciate patience & clear explanations.
Lloyd McKenzie (Jun 02 2020 at 21:04):
That's what this community is for - hard to cover all the nuances in the core spec
Jose Costa Teixeira (Aug 04 2020 at 12:32):
ImmunizationRecommendation.forecastStatus is mandatory.
What would be the code for a recommendation for "this patient should get their flu vaccine this year" ?
Is "due" the right code? since the flu vaccine is optional, and people will get the recommendation before flu season...
Last updated: Apr 12 2022 at 19:14 UTC
