Stream: implementers
Topic: immunisation not given
Amir Mehrkar (Dec 05 2018 at 23:11):
In the UK we now have some use case requirements to share information about immunisations that were “not given”:
We’ve proposed a combination of UK SNOMEDCT procedures codes to identify the stages in the imms schedule via an extension (https://fhir.hl7.org.uk/STU3/StructureDefinition/Extension-CareConnect-VaccinationProcedure-1) PLUS using the vaccineCode for the actual imms.
However, there is a debate on how to safely capture negated procedures for a given vaccine.
So child attends, but is unwell for procedure X of vaccine Y:
1a) VaccineCode = Y
1b) Extension-...- VaccineProcedure = X (snomedCT Concept of procedure only)
1c) notGiven = True
OR
2a) VaccineCode = Y
2b) Extensions -...-VaccineProcedure = X (POST COORDINATED SNOMEDCT EXPRESSION DEFINING PROCEDURE NOT GIVEN.)
2c) notGiven = True
Some contend that option 1 is sufficient and safe for negation to be derived from the notGiven modifier element alone.
others say option 2 is the safer and reflects proper use of snomed: ie if you carry a procedure code that isn’t negated via postcoordination, then by definition that means the procedure did happen. And if the procedure is then taken out of context from the FHIR message, there is a clinical risk of interpreting that procedure did actually take place when it didn’t.
Thoughts?
Rik Smithies (Dec 05 2018 at 23:22):
what's the downside of 2b? Extra complexity of post coordination? Presumably the number of vaccines is fairly small, and this could be more or less hard coded - rather than needing a full SNOMED post-coordination engine to work out the meaning.
Amir Mehrkar (Dec 05 2018 at 23:47):
Thanks @Rik Smithies - I think there may be some concern that implementers may struggle (both send and receive) for postcoordinated, but we have said for all snomed terms (+post coordianated) the human readable display would always be transmitted if recipient was not able to process post cord.
Generally for child health the number of procedures is small and wouldn’t massively expand over time so there is a degree of hard coding that could be established.
I think part of this is about philosophy of snomed use and ensuring unambiguous meaning is preserved safely when the content is taken out of the message and stored natively. There is also the issue that folk say the modifier element for option 1 is intended to convey notGiven too.
Rik Smithies (Dec 06 2018 at 00:53):
From an implementation point of view it is effectively a pre-coordinated list of "+given" and "+not given" for each code.
But what's the reason that the vaccination stage code can't just go in the Procedure.code?
Jim Steel (Dec 06 2018 at 00:59):
Presumably the question of what downstream tools will make of the postcoordinated codes will be relevant
Richard Townley-O'Neill (Dec 06 2018 at 01:40):
Taking content out of a resource is always dangerous. If the vaccineCode is take out of context there is no way to know whether it was administered or not. That requires the context of the resource.
Do you want to carry the intended procedure or the actual procedure? If it is the intended procedure, then saying "not done" with post coordination is strange, but you know the value before the attempt to administer the vaccine. If it is the actual procedure, post coordinated "not done" makes more sense, but you will not know the value until after the attempt.
Grahame Grieve (Dec 06 2018 at 01:43):
I don't mind between 1 and 2 but from a FHIR pov,
option 2 is safer and reflects proper use of snomed: ie if you carry a procedure code that isn’t negated via postcoordination, then by definition that means the procedure did happen.
Grahame Grieve (Dec 06 2018 at 01:44):
that's not true. If the resource is notGiven = true, then you can't pluck something out of the resource and say that it has meaning irrespective of it's context. (more generally, this is true about SCT use)
Grahame Grieve (Dec 06 2018 at 01:45):
if you define the extension as "SCT summary code for resource' and document that it must be safe to extract and take out of context... then option 2 is clearly the safe option.
Grahame Grieve (Dec 06 2018 at 01:47):
if you define the extension as 'the procedure code for the vaccine whose outcome is recorded' then option 2 is actually wrong, since you would now saying: "vaccine A was not given by not giving it' .... urr?
Grahame Grieve (Dec 06 2018 at 01:47):
irrespective, definitions matter (foreign to SCT I know) and you have to consult them
Robert McClure (Dec 06 2018 at 02:07):
@Jay Lyle You may want to weigh in here
Neill Jones (Dec 06 2018 at 08:59):
I have a major problem with both proposals. While it is true that "You" dis not do a planned procedure "You" cannot correctly assert that the procedure has not been done especially if the person did not attend which is also part of the use case.
I would argue that it is safe to state that a planned procedure did not happen.. That is the plan was not carried out this is always perfectly safe as the vaccination code is not used so there is no risk that it is separated.
Ian McNicoll (Dec 06 2018 at 09:50):
Thanks Amir. I think it is important that we bottom out this issue as I think it does raise some safety concerns but not those originally discussed.
I agree with Grahame that we cannot be responsible for those who wish to extract aspects of the data e.g just the immunisation procedure name, ignoring any critical supporting context provided by the information model - this is not about the message, it is about that message being based on a coherent information model, with critical attributes that cannot be ignored. So, I think the original concern is spurious - in this world, the information model is king and terminology supportive. That is contentious but ultimately that is how it is intended to work .
However .....
For me more significantly, there is an issue around searching/filtering querying, for which I think there are some broad use cases.
a. Find me a patient(s) who have been given immunisation X (Given = True)
b. Find me patient(s) who have not been given immunisation X (Given = False)
c. Show me the immunisation status for patient X (Given = true/false)
The main risk I can see is (1) where there is a risk that 'naive' developers will simply search on procedure code and fail to apply the closely associated 'Given' parameter, with a risk of inadvertently picking up 'not given's.
So, I agree that (1) is problematic, though for different reasons than those originally suggested. We have similar issues in some openEHR models, and something we have been looking at is whether we could apply some sensible, safe default query constraints. In this context, I guess I am suggesting that we either force people to always supply the NotGivemn search parameter, or apply defaults such that if not supplied, it defaults to 'where given'.
This may be technically unfeasible/ inadvisable but if it could be acheived it would solve a lot of problems. As I say, we are looking it how this might be done in openEHR AQL.
The suggestion to use post-coordination fills me with dread. It has been hard enough to get SNOMED CT adoption over the line in the UK without introducing this level of complexity. If we do go down this road, I would advocate creating some pre-coorrdinated, but fully-defined codes - though this is not scalable for other procedures.
Important discussion - some very practical issues, as well as important points of principle.
Grahame Grieve (Dec 06 2018 at 09:56):
our experience with default values for search parameters is that they are very difficult and we strongly recommend that people don't do this. Our default for a search parameter is 'no effect on return values" and changing that introduces subtle and serious downstream issues.
Grahame Grieve (Dec 06 2018 at 09:57):
if you must do something, I strongly recommend that you require a search parameter and require servers to return an error if it is not present.
Ian McNicoll (Dec 06 2018 at 10:06):
Thanks Grahame. Interesting, of course I understand there are risks/challenges. I would only want to do this where there is a very clear. safe default, and a contrary high risk of mis-querying. So the alternative is to force the given/not given parameter to be supplied- is that technically feasible?
Ian McNicoll (Dec 06 2018 at 10:14):
If that is technically feasible, it solves the problem for me. I do not think we can be responsible for consumers of a FHIR data instance, shredding that incorrectly, whether the downstream target is a post-coordinated SNOMED CT expression, an openEHR model, or a proprietary system model.
Grahame Grieve (Dec 06 2018 at 10:15):
you can make that policy, absolutely. Whether you can make it stick..... you probably don't have enough closure around the eco-system to make it stick completely. And I doubt we could make that stick on everyone either. We could consider identifying some search parameters for special attention...
Ian McNicoll (Dec 06 2018 at 11:10):
@Grahame Grieve so this is not technically enforceable?
Grahame Grieve (Dec 06 2018 at 11:43):
I’m not sure what you mean by “technically enforceable”. You can make a rule: all searches on AllergyIntolerance that have a code parameter SHALL also have a given parameter.
Grahame Grieve (Dec 06 2018 at 11:44):
You cannot quite say that in a capability statement right now, so that’s a limitation
Grahame Grieve (Dec 06 2018 at 11:45):
You can construct test cases, using a TestScript resource, or some other testing infrastructure, that tests that a server that gets a code parameter without a given parameter returns an error not a result
Grahame Grieve (Dec 06 2018 at 11:45):
You can then require a set of test cases to be passed before a server is considered suitable for use in some context
Grahame Grieve (Dec 06 2018 at 11:46):
Is that technical enforcement? If it’s not, what would you call ‘technical enforcement’?
Grahame Grieve (Dec 06 2018 at 11:46):
The key here is “what context”
Grahame Grieve (Dec 06 2018 at 11:47):
My contention is that this is the most difficult thing because very few systems are going to live in a closed context that doesn’t leak into the wide world eventually (though slowly)
Munish Jokhani (Dec 06 2018 at 12:19):
The challenge here is that if we are not expecting the receiving systems to use FHIR for storage/persistence, so they are supposed to suck it in their database automated/semi-automated and once a SNOMED Code of procedure is in the record with implicit context of it being done , storing somewhere else that it was not done and maintaining that linkage and then enforcing that in any kind of query results consistently. I think it will be much easier not to record the procedure code and just record that it was not done and technically you could do a delta on a patient cohort and look for positives and assume that for rest of them it wasn't done.
Jay Lyle (Dec 06 2018 at 13:23):
You can't rely on assertions of absence or acts not done for clinical purposes; any such assertion could be out of date, even if correct when made. This is true for any model and you can't fix it. For safety protocols, always ask; for quality measures, do the best you can.
What's different here is the redundant information - the model impedance. To Grahame's point, it has to make sense as FHIR, and if you add new ways to say the same thing, you're going to have problems.
What is the requirement this extensions supports?
1. The value set mixes axes, so we can't be doing this for a strict "downstream tool"
2. The coordinated values are already in FHIR - vaccine, provider type, route -- wait, there's an intent . . .
Rik Smithies (Dec 06 2018 at 14:10):
hi @Munish Jokhani, but wouldn't the persistence only be a factor if the context was ignored during the export? We don't want to make it hard, but it is never ok to just suck out the codes.
Grahame Grieve (Dec 06 2018 at 14:34):
To Munish's point: we do not say anything about storage. So systems may choose to persist using fhir if they want. And many do. But however you do store, you need to be able to know/reassemble the context and information correctly. But we've never thought that that's saying much, since that would be true irrespective of the interface and the persistence choices
Munish Jokhani (Dec 06 2018 at 16:46):
@Rik Smithies Agree ; we have take into consideration limited maturity of some of the receivers to handle distributed context in a FHIR information model especially when its context modification e.g. negation . @Grahame Grieve agree with the principle and its about trying to help implementation so that receivers don't have to re-design systems immediately.
Ian McNicoll (Dec 06 2018 at 18:53):
@Munish Jokhani are these theoretical concerns or based on known high value recipients who can only accept a single attribute.? If that truly is the case I think I would help write them their adaptor. What do they do now? Of course we don't want to hamper implementation but folks are going to step up I'm afraid. If they can't handle negation they probably only need positive records.
Ian McNicoll (Dec 06 2018 at 18:54):
@Grahame Grieve by techinicaaly enforceable I just meant some sort of server error. Ie it is simply not possible to omit that parameter. Server will say no.
Amir Mehrkar (Dec 06 2018 at 22:16):
Thank you for everyone's insights.
1. Is it really an expected standard for the recipient to be able to demonstrate reassembly of the message for audit / safety purposes? Or once you've parsed and done with the data what you need, can you reasonably discard and not have to reassemble etc...
2. reading spec, it appears procedure resource cannot be used: "The Procedure resource should not be used to capture an event if a more specific resource already exists - i.e. immunizations"
So, our architecture is PUB/SUB FHIR events model (each event being a bundle of resources that applies to a use case - here vaccination).
A key requirement is being able to search at population level for child cohorts for whom a part of the schedule DID NOT HAPPEN. And to search simply. ONLY 4 “DID NOT HAPPEN” reasons are needed: Not attended; refused; Contraindication; unwell.
Evolving thoughts (keeping implementation & end point maturity in mind) for DID NOT HAPPEN:
A]
-
Imms.Extension.Procedure = pre-coordinated snomedCT code: Meningitis C vaccine Refused, MenC vaccine Contraindicated, etc etc
-
VaccineCode = null value = NI (No information)
- NotGiven = True
B]
-
Imms.Extension.Procedure = pre-coordinated snomedCT codes: MenC Vacc did not happen, DPT 1 did not happen etc etc
-
VaccineCode = null value = NI
- NotGiven = True
- ReasonNotGiven =
Refused; Unwell; Contraindicated; Not attended
This way, if there is data leak, the precoordinated procedure code is unambiguously clear the vaccination procedure didn't happen plus there is NO vaccine code sent for something that didn't get given.
Search query is simple= via extension.procedure and/or ReasonNotGiven.
In the actual business workflow: staff would need to have forms (or a mechanism) to pick for the procedure one of the reasons it didn’t happen. However, there is no need to identify a vaccine product. Thus such vaccine information doesn’t unnecessarily transmit around the system.
Reasonable? better? :)
Grahame Grieve (Dec 07 2018 at 00:45):
@Ian McNicoll yes the server can return an error from the search
Grahame Grieve (Dec 07 2018 at 00:48):
@Amir Mehrkar 1. not just because. Generally, an application needs to do this one way or another or functional purposes. I've never seen it specified that an application has to do it merely to demonstrate that it can, and we never say that
2. you could use procedure to describe the process of the immunization, but not as a substitute for immunization itself
3. I'm not actually following the grounds for the extension. your use case appears to be covered by vaccine code + not given + reason?
Amir Mehrkar (Dec 07 2018 at 09:11):
Thanks @Grahame Grieve
2. The FHIR spec on procedure has been interpreted (...wrongly it seems...) that we shouldn't use it around events to do with immunisation. How would we link the procedure via a reference to imms. I couldn't see a mechanism. Procedure.Partof doesnt seem to allow.
3. We do not think it is safe to exchange information about a specific vaccine we didn't end up giving. ie. we dont want to say, the specific MMR vaccine was NOT GIVEN due to data leak safety issues and the capabilities of receiving systems to store (handle) such negated concepts that are not precoordinated. Also, the sending system (or clinician) would need to choose the vaccine the clinician did not give before sending. So, we feel it is better to explicitly use a precoordinated SNOMED code to say the "PROCEDURE of MMR DID NOT HAPPEN", leave the vaccineCode = NI. Then there is no risk to find a code of an MMR vaccine code (which wasnt given) that might be unambiguous when assimilated into the receiving system.
The set of precoordinated SNOMED CT codes saying "procedure of MMR (X schedule) DID NOT HAPPEN" would need creation but there are not too many. The imms.extension.procedure was created because we didnt think we could use the Procedure resource as per part 2.
Rob Hausam (Dec 07 2018 at 11:34):
To me that seems like a reasonable (and safe) approach. As you say, the number of additional pre-coordinated codes (whether SNOMED CT or otherwise) should be relatively limited. We adopted a similar approach in the International Patient Summary (IPS) IG for representing “known absent” and “not known” information. In that case, rather than attempting to get these codes added to SNOMED CT and made available for use at no cost globally, we created our own code system for it in IPS.
Amir Mehrkar (Dec 07 2018 at 12:59):
Thanks @Rob Hausam looks like we've tackled it in similar principle yes. What did you think about the issue of 2 - using Procedure. Did you use that and link to Imms resource or do an extension in imms?
Pete Salisbury (Dec 07 2018 at 13:15):
@Grahame Grieve in answer to your question and to give a bit of background,
3. I'm not actually following the grounds for the extension. your use case appears to be covered by vaccine code + not given + reason?
In the uk the GP clinical systems all store immunisations as procedure codes rather than as the actual code of the substance that was administered. However in some projects in the UK are looking to use the vaccineCode to record immunisations which is how we have ended up with an extension.
Dave Barnet did ask a question about it previously here, see link below, but there has been further use cases introduced since that point.
https://chat.fhir.org/#narrow/stream/4-implementers/topic/vaccineCode.20being.20a.20vaccineCode
Grahame Grieve (Dec 07 2018 at 20:45):
I'm still not following where the extension comes from
Grahame Grieve (Dec 07 2018 at 20:47):
I think, from what you've said, that source systems are storing a SCT code that is from the procedure heirarchy that pre-coordinates the vaccine code
Grahame Grieve (Dec 07 2018 at 20:48):
I'm still not clear where they are storing this. As part of a general medical history? Or a specific immunization history?
Grahame Grieve (Dec 07 2018 at 20:51):
There is no explicit link between immunization and procedure; the immunization resource folds in some of the procedural aspects, but you could have an extension for others. However, what's not clear to me is why this a reason not to use vaccineCode?
Amir Mehrkar (Dec 11 2018 at 15:16):
However, what's not clear to me is why this a reason not to use vaccineCode?
@Grahame Grieve - do you mean why we can't use vaccineCode to store the vaccine we DID NOT Given? Is that correct?
I think one argument you have made is the FHIR spec is its own data model and if developers choose to move data out of the FHIR resource (out of context), then they are using the standards inappropriately. Correct?
Do you think this is a valid clinical risk we need to mitigate or it's more about vendors "using the spec correctly."
Amir Mehrkar (Dec 11 2018 at 15:22):
Or are you saying, "why don't you just put the precoordinated SCT Code procedural code in the VaccineCode" instead of the extension you are proposing? I think this is what you are suggesting....
Grahame Grieve (Dec 11 2018 at 19:49):
yes that is what I was suggesting.
Grahame Grieve (Dec 12 2018 at 00:44):
ok: "why don't you just put the precoordinated SCT Code procedural code in the VaccineCode" is what I suggesting
WeiDing (Dec 12 2018 at 01:29):
Hello, could you please tell me if I can insert many records at one time? If there is a large amount of data.What do I do？
Grahame Grieve (Dec 12 2018 at 01:31):
read http://hl7.org/fhir/http.html#transaction and also http://wiki.hl7.org/index.php?title=FHIR_Rules_for_asking_questions
WeiDing (Dec 12 2018 at 02:23):
Yes, I could, thanks! I'm sorry
Kevin Mayfield (Dec 21 2018 at 12:24):
@Pete Salisbury why isn't procedure the correct thing to use here? If I'm doing a series of immunisations (as part of a immunisation workflow), then I'm tasked with performing immunisations (i.e. it's a planned order aka procedure).
I worked on one the first imms extracts from EMIS and it was procedures, I've also worked in child health and it was procedures here (plus I recall batch numbers). Neither used what would be called in FHIR, immunisation.
Kevin Mayfield (Dec 21 2018 at 12:26):
I'll take that back (it should be Immunization).... I'm just confused what's being asked here?
Kevin Mayfield (Dec 21 2018 at 12:39):
on reading this again. Agree with @Grahame Grieve last point. Why not use precoordinated SCT Code in vaccineCode?
Last updated: Apr 12 2022 at 19:14 UTC
