Stream: committers
Topic: AllergyIntolerance design problem
Grahame Grieve (Feb 25 2017 at 00:05):
@Michelle (Moseman) Miller @Lloyd McKenzie @Rob Hausam AllergyIntolerance has changed from a code to a CodeableConcept with a required binding. Why?
Lloyd McKenzie (Feb 25 2017 at 01:00):
Not sure. I suspect to support translations?
Rob Hausam (Feb 25 2017 at 05:23):
It's to support multiple values for category. The data type was changed to CodeableConcept due to trying to follow QA rules. The overall issue arose when biologic was added. At first we had it in a hierarchy, with biologic under medicstion, but not everyone agreed with that and the hierarchy was removed. So now we can have biologics which are medications (thus needing multiple category values), and also some biologics potentiallly which are not considered to be medications. I tried to argue against making the change this way, but lost. I did second the resolution, but I still think that overall this turned out somewhat strange, including having the value set remain as required. This is from GF#11352.
Rob Hausam (Feb 25 2017 at 05:29):
And the changes to 'biologic' are in GF#11351.
Michelle (Moseman) Miller (Feb 25 2017 at 13:22):
Rob H. is correct. I will elaborate by saying it was the FHIR GA guidelines 4e that talks about the "code" data type, “ensure all codes are mutually exclusive or are defined in a proper hierarchy where siblings are mutually exclusive”. Even without biologic in the mix, there may have been questions about whether bee pollen is food or medicine. @Robert McClure logged both trackers and was most vocal during our discussions. As chair, I was unable to vote, but I did try to ask implementers if their system supported multiple distinct categories -- and I recall Epic and Allscripts both saying they did support multiple categories (whereas Cerner only supports a single category).
Grahame Grieve (Feb 25 2017 at 16:31):
but my question is not about the cardinality. It's about the change to codeable concept. If you think that the value set is not a proper set of values, then the data type should not be code, and the binding should not be required.
Grahame Grieve (Feb 25 2017 at 16:33):
It's stupid if we right QA rules that are over optimistic, and then produce dumb designs. There's a weird edge case why the build allows required binding on codeable concept, but I think it should not allow it
Grahame Grieve (Feb 25 2017 at 16:35):
nor do I follow this sentence: " since the value set binding is required and cardinality is 0..*, the value set is neither mutually exclusive, nor defined in a proper hierarchy"
Grahame Grieve (Feb 25 2017 at 16:36):
somehow this seems to imply that cardinality is related to mutually exclusiveness which is related to data type?
Grahame Grieve (Feb 25 2017 at 16:45):
and @Lloyd McKenzie it is a problem that the qa criteria say nothing about required bindings
Rob Hausam (Feb 25 2017 at 17:36):
Sounds like we agree there is an issue, but it's not entirely clear to me at the moment based on this discussion what we should do (presumably in the future) to resolve it.
Grahame Grieve (Feb 25 2017 at 17:40):
sigh. I guess it's too late. it's just that we shouldn't have required bindings to CodeableConcepts
Michelle (Moseman) Miller (Feb 25 2017 at 19:57):
Yes, it started with cardinality (changing to 0..*), which then implied that the codes weren't mutually exclusive if a given allergen/substance could fall into multiple categories defined in the value set. We didn't think we could use the code data type due to the QA 4e (mutual exclusivity is required when using codes).
I don't mind revisiting this, but I'd like to confirm all of the following options are acceptable....
A) 0..1 code data type with required binding (like DSTU2)
B) 0..* CodeableConcept with preferred binding (relax binding)
C) 0..* code data type with required binding (assuming QA 4e is updated)
Lloyd McKenzie (Feb 25 2017 at 20:10):
It's legitimate to have a required binding for a CodeableConcept - it means that translations are expected/necessary but it's reasonable to expect the world to at least send a single code.
Lloyd McKenzie (Feb 25 2017 at 20:11):
If we wanted to allow multiples, the correct solution here would be to make it 0..* code
Lloyd McKenzie (Feb 25 2017 at 20:11):
It's not legitimate to say that Biological and Drug are two translations of the same category.
Michelle (Moseman) Miller (Feb 25 2017 at 20:29):
Side note: I believe Argonaut profiles have required bindings for CodeableConcept elements (e.g. Patient.martialStatus) - albeit 0..1.
I think the current intent with 0..* CodeableConcept with required binding was to allow bee pollen (for example) to have 2 distinct categories, such that the first CodeableConcept could have translations/codings for both SNOMED Food and the FHIR defined food code and then the second CodeableConcept could have translations/codings for both SNOMED Drug and the FHIR defined medication code.
Grahame Grieve (Feb 25 2017 at 20:29):
I think that 'mutually exclusive' is misleading then. we have other places code 0..*, and that makes sense. Clearly differentiated might be a better thing to say
Grahame Grieve (Feb 25 2017 at 20:30):
options a-c are all ok
Grahame Grieve (Feb 25 2017 at 20:31):
I think that Lloyd's case for a required binding for CodeableConcept is very much a corner case. I cannot understand why a committee would decide that translations would be expected or necessary, and also decide that a binding would also be required.
Grahame Grieve (Feb 25 2017 at 20:32):
required bindings on codeable concepts in profiles are inevitable and make sense
Grahame Grieve (Feb 25 2017 at 20:32):
I don't think that it makes sense to have a required binding, and to cater for snomed codes as well; it would be better to map the fixed codes to snomed, so that the snomed codes are known, but not explicit.
Grahame Grieve (Feb 25 2017 at 20:33):
if it turns that there are multiple snomed codes for each of the categories... I don't think that make sense at all then
Michelle (Moseman) Miller (Feb 25 2017 at 20:38):
I can take that feedback back to PC. I think the desire with having the required binding to FHIR-defined codes was due to the common use case to search by category (e.g. get all medication allergies). I can recommend option C (i.e. 0..* code required binding) and we'll see if there is anyone who advocates they want/need the SNOMED translations. I'll keep you posted.
Grahame Grieve (Feb 25 2017 at 20:39):
ok thanks
Rob Hausam (Feb 25 2017 at 20:44):
I'm not sure if the SNOMED CT translations are especially useful, but I am curious if there are implementers that are happy with (and prefer) using that particular set of codes for category - and no others.
Michelle (Moseman) Miller (Feb 25 2017 at 20:46):
We discussed this live in one of our Jan WGM quarters, and I thought there were some supporters for using SNOMED (possibly from VA if I remember correctly?)
Rob Hausam (Feb 25 2017 at 20:51):
I probably wasn't there for that discussion - I definitely missed the allergy quarter on Wed. Q4 when I was teaching.
Grahame Grieve (Feb 25 2017 at 21:06):
the question is whether the justification for using SCT directly - rather than by mapping - is enough to impose the costs of dealing with multiple codes etc on all implementers.
Rob Hausam (Feb 25 2017 at 21:06):
Looks like the discussion and vote on GF#11351 was Tues. Q4 (which I also wasn't there for). It's interesting that the minutes document "Recommendation that this should be relaxed from being a required valueSet", whereas the resolution for 11351 documented in the tracker says otherwise (that it should remain as required).
Grahame Grieve (Feb 25 2017 at 21:07):
and, in fact, if you're wanting to use SCT only, and you change from code to CodeableConcept, you just increased your own costs as well as everyone else
Grahame Grieve (Feb 25 2017 at 21:07):
that was an option, not the actual recommendation. Fooled me first time I read it too
Rob Hausam (Feb 25 2017 at 21:09):
in the minutes, that's all of the text that is there (maybe the minutes are just incomplete?)
the tracker has it listed as one of the options, as you said
Grahame Grieve (Feb 25 2017 at 21:10):
ah ok
Michelle (Moseman) Miller (Feb 25 2017 at 21:31):
Correct. The wiki minutes are severely lacking (probably since the scribe knew I was projecting and taking minutes within the tracker item directly).
Michelle (Moseman) Miller (Mar 02 2017 at 23:35):
@Grahame Grieve PC voted on GF#12942 to change the AllergyIntolerance.category back to a code data type (keeping it 0..* and required binding). The million dollar question is whether you would like that change applied during the STU3 QA period or wait until R4?
CC: @Lloyd McKenzie , @Rob Hausam
Grahame Grieve (Mar 02 2017 at 23:39):
I'd like it applied for STU 3
Rob Hausam (Mar 03 2017 at 04:26):
So it is OK to go ahead and apply this now?
Grahame Grieve (Mar 03 2017 at 04:55):
well, same process as for any other substantiative change right now - send me a patch. I'm going to make a round of substantiative changes on sunday evening
Grahame Grieve (Mar 03 2017 at 04:55):
I think
Rob Hausam (Mar 03 2017 at 04:56):
ok - right
Grahame Grieve (Mar 03 2017 at 04:56):
and it needs FMG approval too, I think
Michelle (Moseman) Miller (Mar 03 2017 at 10:53):
FYI, I sent FMG the email last night.
Last updated: Apr 12 2022 at 19:14 UTC
