Stream: committers
Topic: Allergy intolerance status codes
Grahame Grieve (Nov 03 2018 at 20:44):
Why have these elements had their type changed to CodeableConcept while still having a required binding? @Michelle (Moseman) Miller
Lloyd McKenzie (Nov 03 2018 at 23:15):
We allow required bindings with CodeableConcept if we feel most systems are going to need to convey additional codes beyond the fixed binding. (Not sure whether/why that would be the case here.)
Rob Hausam (Nov 04 2018 at 03:26):
The request came from the VA - GF#17743.
Rob Hausam (Nov 04 2018 at 03:31):
And basically the same for Condition - GF#16193. They want to also be able to use SNOMED CT.
Grahame Grieve (Nov 04 2018 at 04:01):
Va’s desire to use Snomed ct does not justify imposing codeable concept on everyone. They can use an extension if they really want to use Snomed, or they can use mappings - which is the infrastructure we’ve been working on.
Grahame Grieve (Nov 04 2018 at 04:51):
nor can I be happy with the code systems urls for both of them
Rob Hausam (Nov 04 2018 at 05:50):
If PCWG decides to agree with you, can it be changed back at this point? Maybe you would approve this substantive change?
Grahame Grieve (Nov 04 2018 at 12:23):
I think I would approve this, though I'd need to be convinced that the process had integrity
Rob Hausam (Nov 04 2018 at 14:42):
Makes sense.
Lloyd McKenzie (Nov 04 2018 at 15:15):
There's a challenge with changing a resolution to a negative ballot after we've agreed to withdrawals - though I also question whether this is something that would be supported by the majority of systems.
Rob Hausam (Nov 04 2018 at 22:45):
Yes, that is somewhat of a challenge. I guess we need to decide if it's worth it to take it on.
Michelle (Moseman) Miller (Nov 05 2018 at 13:57):
Rob had the correct trackers: GF#17743 (for Allergy) and GF#16193 (for Condition). In addition to preferring use of SNOMED, there was an acknowledgement that these statuses (for both allergy and condition) had some clinical judgment involved, such that there may need to be more specificity than what the FHIR value set allows. For example, GF#16193 had the scenario where FHIR only has remission in its value set whereas SNOMED allows distinction between partial remission vs full remission. Changing the data type to CodeableConcept allows for the extra nuanced codings without sacrificing the interoperability (keeping a required binding).
Michelle (Moseman) Miller (Nov 05 2018 at 13:58):
What are the recommended next steps here? Both of the trackers were ballot comments flagged as In Person requests.
Lloyd McKenzie (Nov 05 2018 at 14:35):
Is PC confident that sending multiple codes and/or original text falls within the 80%? If so, no further action is needed.
Grahame Grieve (Nov 05 2018 at 20:29):
Ok. Can i ask that the documentation for the 2 elements be updated to reflect what @Michelle (Moseman) Miller has said?
Michelle (Moseman) Miller (Nov 07 2018 at 02:28):
Sure, I can work with PC on Thursday to draft some notes to add to the spec to explain the rationale for CodeableConcept and will plan to apply the non-substantive text updates on Thurs night or Fri morning
Grahame Grieve (Nov 07 2018 at 06:36):
thanks
Eric Haas (Nov 07 2018 at 16:58):
I think status as codeable sets a precedent for unnecessary complexity and am fixin' to submit a tracker to go back to the easy peasy code and as Lloyd suggests use an extension if you need to.
Lloyd McKenzie (Nov 07 2018 at 17:00):
Feel free to submit a tracker, but at this point it's probably going to have to be an R5 tracker.
Michelle (Moseman) Miller (Nov 08 2018 at 14:57):
@Eric Haas Allergy and Condition are already different from all other resources since we split apart status into clinicalStatus vs verificationStatus. For most other resources, I think the status is more black and white and doesn't take the same subjectivity and clinical judgment to assess status like Allergy and Condition do.
Eric Haas (Nov 08 2018 at 16:49):
My concern is that it is getting "overmodelled" and are systems supporting all these nuances?
Michelle (Moseman) Miller (Nov 08 2018 at 17:07):
As an implementer, I can add that our system has some nuanced differences. At times, many local codes map to the same FHIR code. For example for Condition.verificationStatus, we have local codes for probable, provisional, possible whereas FHIR has provisional only
David Hay (Nov 08 2018 at 21:44):
just out of interest - how to you manage that? Use 'provisional' with an extension?
Michelle (Moseman) Miller (Nov 08 2018 at 21:58):
Today, we just map our (multiple) local codes to a single FHIR code and the nuance is lost. With the change in R4 to use CodeableConcept, we can begin exposing our local code, FHIR code, and text (and/or decide whether we also want to include a SNOMED translation of our local code)
Last updated: Apr 12 2022 at 19:14 UTC
