Stream: implementers
Topic: AllergyIntolerance verificationStatus
Gerhard Andreassen (Sep 22 2017 at 10:27):
1. AllergyIntolerance contains a new required field as of STU3, AllergyIntolerance.verificationStatus. We plan to migrate our service from DSTU2 to STU3, but we don't have any source for this required field. What is best practice if there are required fields that cannot be mapped to an existing source of information ?
2. The field verificationStatus has a required binding to a valueset (allergy-verification-status). How do we interpret this ? The binding is required, but not that particular value-set ? Can we substitute the value-set for something else ? The same is relevant for AllergyIntolerance.criticaly with required binding to (allergy-intolerance-criticality). In DSTU2 we solved this using an extension. But is it not possible to rather use the original element and then substitute the referenced valueset ?
Yunwei Wang (Sep 22 2017 at 13:21):
1. This is a breaking change. So you have to change business logic based on server's requirement.
Yunwei Wang (Sep 22 2017 at 13:22):
2. No you cannot substitute a required value set binding. Here is what specified in FHIR spec:
Yunwei Wang (Sep 22 2017 at 13:22):
The following rules apply when required bindings are used with the code data type:
Where the value set is defined by FHIR, the list of allowed codes will be fixed in the XML schema
Comparison between codes is always case sensitive unless the codes are selected by reference (e.g. ValueSet.compose), and the referenced specification clearly states otherwise
The list of codes that can be used can only be extended in subsequent releases of the FHIR specification
Lloyd McKenzie (Sep 22 2017 at 17:32):
If you had populated the status attribute in STU2, you can move that information to verificationStatus. If you didn't have a status, then I'd probably go with "unconfirmed" as that's the safest
David Hay (Sep 26 2017 at 19:45):
You can extend the element if that helps: https://fhirblog.com/2017/01/10/extending-a-required-valueset-binding/
Lloyd McKenzie (Sep 26 2017 at 20:34):
That works if one of the codes applies and you want to provide more nuance. It's going to confuse the heck out of other systems if none of the codes applies.
Robert McClure (Sep 27 2017 at 20:39):
@David Hay I just looked at this blog post and I'm confused as heck already. Is the example saying you are sending "status"="completed" but what are you "extending" with:
"_status": {
"extension" : [
{
"url": "http://fhir.hl7.org.nz/dstu2/StructureDefinition/ms-status",
"valueString": "stopped"
}
]
}
Is it the value set? How can you extend a value set resource from within an instance of another resource? You don't even reference the value set you are extending. That seems very confusing to a receiver.
Why not simply do a conceptMap?
Lloyd McKenzie (Sep 27 2017 at 21:11):
@Robert McClure You're sending a single code from a fixed value set. You're also sending an additional data element that conveys a more nuanced code. Certainly you might have a ConceptMap that tells you what "official" code should be sent for a given nuanced code. But on the wire, you'll need to send the official code and want to send the more nuanced code.
Robert McClure (Sep 27 2017 at 21:22):
@Lloyd McKenzie I agree with the need, and understand that solving it for a single instance may not benefit from a map, but given this overall situation I'd assume all the various verificationStatus codes in use in NZ are going to be regularly used, so wouldn't a ConceptMap make sense then?
Also, Am I right that since this is a code, not coding, translations are not allowed?
Rob Hausam (Sep 27 2017 at 22:15):
@Robert McClure Yes, since it's a 'code' data type and a required binding, only the codes in the bound value set can be sent and translations are not allowed - unless you use an extension to carry the additional code, as David's post describes (I haven't read all of it yet).
David Hay (Sep 28 2017 at 00:12):
Alway happy to be corrected :) - but my understanding is that whether this particular new value ('stopped') is used elsewhere doesn't change the fact that you have to include the original (as Lloyd & Rob have said). Not sure how the ConceptMap would help here - can you use it to define a specific value of the extension for use by others?
Also - though I believe it is technically legit that the extension is of type 'string' - 'code' would be more consistent - in fact I suspect that in this scenario the type of the extension should be the same as the type that it is extending... I'll update the post
Abbie Watson (Oct 10 2017 at 22:18):
1. AllergyIntolerance contains a new required field as of STU3, AllergyIntolerance.verificationStatus. We plan to migrate our service from DSTU2 to STU3, but we don't have any source for this required field. What is best practice if there are required fields that cannot be mapped to an existing source of information ?
2. The field verificationStatus has a required binding to a valueset (allergy-verification-status). How do we interpret this ? The binding is required, but not that particular value-set ? Can we substitute the value-set for something else ? The same is relevant for AllergyIntolerance.criticaly with required binding to (allergy-intolerance-criticality). In DSTU2 we solved this using an extension. But is it not possible to rather use the original element and then substitute the referenced valueset ?
It might be a bit premature to suggest this as a complete solution, but Symptomatic/Meteor-on-FHIR recently completed most all of the resources for the Argonaut project and CCD on FHIR. So, we're able to start offering FHIR routing services.
Because of the way Meteor on FHIR is built, each FHIR Resource is implemented as a separate simple-schema, with .validate(), .clean(), and other functions. Long story short... with a little work, it could be set up as a relay or worker bot that validates and cleans up DTSU2 to DTSU3, adding default values and fields, and otherwise performing schema migrations.
Eric Haas (Oct 10 2017 at 22:33):
what about this: http://hl7.org/fhir/extensibility.html#2.5.0.2.2 ?
Michelle (Moseman) Miller (Oct 11 2017 at 20:56):
FYI - Patient Care just approved GF#13997, which will relax cardinality of AllergyIntolerance.verificationStatus to be 0..1 in the next release.
Dave Barnet (Oct 24 2017 at 08:43):
VerificationStatus: This issue is begining to bite us in the UK as well. [Some] systems don't categorise allergies in the way VerificationStatus wants them classified, and our clinical leads think that VerificationStatus implies meaning about the allergy statement that is imposiible to ascertain from the source data.
There's been a lot of chat on this post about extending the value set to add nuance to the required values. Is this the Internationally recommended way forward? What I'm picking up is where you cannot be sure of a VerificationStatus from the source data, you have a main code of "unconfirmed" then use an extension to nuance this with something like "unable to verify from patient record" (or something similar).
Is this a reasonable summary of the discussion? Is this the recommended way forward?
Grahame Grieve (Oct 24 2017 at 08:47):
what values do you have?
Dave Barnet (Oct 24 2017 at 08:50):
VerificationStatus isn't a concept in the source systems - they just state an allergy, but not whether it's confirmed or not.
Grahame Grieve (Oct 24 2017 at 08:56):
so this is unconfirmed then.
Grahame Grieve (Oct 24 2017 at 08:56):
it's not refuted
Grahame Grieve (Oct 24 2017 at 08:56):
I suppose the issue is that it might be confirmed or not
Dave Barnet (Oct 24 2017 at 09:05):
That is the issue, we don't know whether the allergy is confirmed or unconfirmed. If we had a verificationStatus of "Unknown" (like the value list on Condition - which is optional) we would be OK. I would like a suggested way that we can all follow for representing an allergy that is neither confirmed or unconfirmed.
Grahame Grieve (Oct 24 2017 at 09:06):
well, I think that's a good task to create - seems like a very common situation. Either verification status should be 0..1 or it should contain unknown
Dave Barnet (Oct 24 2017 at 09:11):
As @Michelle (Moseman) Miller points out (earlier in this thread), the problem has been recognised. GF#13997 will relax the cardinality of verificationStatus to 0..1 in the next FHIR release. I'm after an interim fix for an unknown verificationStatus we can all follow.
Rob Hausam (Oct 24 2017 at 09:12):
Michelle did mention that GF#13997 will relax the cardinality of AllergyIntolerance.verificationStatus to 0..1 in R4 (and I hadn’t seen Dave’s last post before I posted mine!).
Grahame Grieve (Oct 24 2017 at 09:15):
interim fix:
<verificationStatus>
<extension url="http://hl7.org/fhir/StructureDefinition/data-absent-reason">
<valueCode value="unknown"/>
</extension>
</verificationStatus>
Rob Hausam (Oct 24 2017 at 09:15):
yes
Dave Barnet (Oct 24 2017 at 09:40):
OK, I've just run this as an example against the schema, and it works, so thanks for the XML. Just to confirm that we are OK to take a mandatory element (verificationStatus), with a Required valueSet and end up without putting in a code from the Required valueSet, but a code from the extension. And this is seen as a valid thing to do in terms of FHIR.
Last updated: Apr 12 2022 at 19:14 UTC
