Stream: implementers
Topic: Extensions on Required Codes
Stephen Royce (Sep 28 2016 at 00:21):
I need to know how to extend a required value set. The particular case in mind is AllergyIntolerance.type whose bound value set has only 2 values. We are currently using a much more sophisticated set of values such as Allergic reaction, Drug interaction, Food intolerance, Hypersensitivity reaction, Medication side-effect and including levels of immuno-responses &c.
We have 2 problems:
1. clearly we carry categories of reactions which cannot be described using either value in the required value set (allergy, intolerance); and
2. while the value set provides suitable categories for several of our codes, we want to attach finer-grained codes.
Stephen Royce (Sep 28 2016 at 00:28):
I'm not too worried about the first problem -- at least, not at this stage -- but I urgently need to know how to add finer-grained codes to the data. I have thought of 2 options:
1. Add an extension to the AllergyIntolerance.type element inside the code data type.
2. Add an extension to the AllergyIntolerance resource as a whole.
The first seems the better option to me, but I have a further question regarding that: is it legal, if my fine-grained code cannot be satisfactorily categorised by the 2 current values of the value set, to just leave out the actual code value and carry only the extension? (I suspect not, but if it was, that would solve my first problem too!)
Stephen Royce (Sep 28 2016 at 00:35):
P.S. I assume that there must be something about this in the FHIR documentation. An, admittedly light, scan of the documentation didn't turn anything up, but if it exists, just point me at it and I'll take it from there myself. 
Eric Haas (Sep 28 2016 at 01:06):
I would use an extension on the AllergyIntolerance resource... sm like Extension "moretypes" 0..1 type "code" and bind it to your codes.
Stephen Royce (Sep 28 2016 at 03:12):
This seems to be an easy answer, but the simple truth is that, if we do this, AllergyIntolerance.type will never get populated -- not in practice -- so the extension effectively becomes "we're ignoring your type and using our own" which is really bad for interoperability. 
Lloyd McKenzie (Sep 28 2016 at 03:28):
Good practice is to map the codes that you have to the corresponding FHIR attribute and also send the extension. That's what your profile should enforce to ensure maximum interoperability. You can't extend required value sets.
Stephen Royce (Sep 28 2016 at 03:30):
By "you can't extend required value sets" do you mean we can't add additional values to the set (which I get) or we can't even add an extension on the data type?
Lloyd McKenzie (Sep 28 2016 at 03:31):
You can't add to the value set. You can add an extension on the code data type
Stephen Royce (Sep 28 2016 at 03:45):
Right. So is an extension on the code data type the way to go, or should we just add an extension to the AllergyIntolerance resource?
Lloyd McKenzie (Sep 28 2016 at 03:53):
In general, nesting extensions beneath the element they're most closely tied to is best practice - they're less likely to get wiped due to another change that way.
Stephen Royce (Sep 28 2016 at 05:55):
Right so inside the code data type then. However, here's the rub, what about codes that cannot be properly classified as either "allergy" or "intolerance"? Can I send the code with just the extension and without the actual code?
Pascal Pfiffner (Sep 28 2016 at 08:41):
Out of curiosity, which code can you not properly classify as allergy or intolerance? Would that be the drug-drug interaction? I'm wondering whether the AllergyIntolerance resource is the right choice for interactions?
Lloyd McKenzie (Sep 28 2016 at 20:28):
I'd be curious about what concepts you're trying to convey because the expectation is those two choices are exhaustive for the intended use of the resource.
Rob Hausam (Sep 28 2016 at 21:22):
I'm curious about that, as well. Since it's the AllergyIntolerance resource, the intent is to classify the type as either "allergy" or "intolerance", and if you are unable to determine that or otherwise choose not to state that, then you omit the element.
Stephen Royce (Sep 28 2016 at 22:58):
Hmmm ...
So our current model is a model for future propensity of an adverse reaction, so we include items like idiosyncratic drug-drug interactions. We also include temporary reactions such as while the patient is taking warfarin they are "allergic" to aspirin.
Grahame Grieve (Sep 29 2016 at 02:45):
this is defined as not part of an AllergyIntolerance, for purposes of consistency with OpenEHR - consult the scope.
Grahame Grieve (Sep 29 2016 at 02:45):
that's why you don't find a matching code
Stephen Royce (Sep 29 2016 at 04:11):
Okay. So where would such data go?
Grahame Grieve (Sep 29 2016 at 04:32):
don't know
Pascal Pfiffner (Sep 29 2016 at 09:02):
It's interesting though. In general, should we be able to express consequences of one resource with another resource? So if there is a MedicationOrder for warfarin, is there a need to be able to describe an implication for aspirin (and x and y and z and ...)? Typing these words it seems to me that that's Pandora's box and better left to CDS, but that's just me thinking about one use case.
Eric Haas (Sep 29 2016 at 14:35):
See DetectedIssue
Last updated: Apr 12 2022 at 19:14 UTC
