Stream: implementers
Topic: Release4 CodeableConcepts
Dave Barnet (Jun 26 2019 at 15:34):
Why have many of the codes in STU3 changed to CodeableConcepts in R4 - especially around Required valueSets (for example Condition.clinicalStatus, Condition.verificationStatus etc.) - as this does introduce a set of <coding> tags at the very least?
Lloyd McKenzie (Jun 26 2019 at 15:59):
The change came about because of feedback from the implementation community, though the change is not without controversy
Eric Haas (Jun 26 2019 at 22:21):
I plan to make a GForge comments on those two. Unless you beat me to the punch
Eric Haas (Jun 26 2019 at 22:23):
to stay in line with the rest of the spec and be code. One place where the pattern should trump semantic purity.
Grahame Grieve (Jun 27 2019 at 11:43):
I will also be discussing this with the community. but the change wasn't made without reasons
Lloyd McKenzie (Jun 27 2019 at 20:15):
It really comes down to "how common is it for implementers to share (and need to share) alternate codings for these elements?" In most places (gender, all other statuses), we've said that few systems support that and that if you need it, extensions are fine. It's not totally clear why these elements are exceptions. But agree that there was a lot of discussion before things landed where they did. It was primarily driven by a desire by certain large US governmental organizations that wanted to be able to send SNOMED CT.
Dave Barnet (Jul 01 2019 at 10:37):
OK - I see - so you MUST send the required code, and you're allowing the sending of alternate codes (and systems) as well by using CodeableConcept. Something like
<clinicalStatus>
<!--mandatory Required code-->
<coding>
<system value="http://terminology.hl7.org/CodeSystem/condition-clinical"/>
<code value="remission"/>
</coding>
<!--Some "preferred" code-->
<coding>
<system value="http://snomed.info/sct"/>
<code value="277022003"/>
<display value="Remission phase"/>
<userSelected value="true"/>
</coding>
</clinicalStatus>
Lloyd McKenzie (Jul 01 2019 at 14:20):
Right. And more specifically, we're saying we believe that most applications support receiving and storing the additional coded representations. (If that wasn't the case, we would have defined the element as 'code' and implementers could have used extensions to convey additional coded representations.)
Grahame Grieve (Jul 03 2019 at 23:27):
yes
Yunwei Wang (Jul 05 2019 at 13:43):
we're saying we believe that most applications support receiving and storing the additional coded representations.
I have seen systems that reject the whole resource because there were additional codings in a codeableConcept.
Lloyd McKenzie (Jul 05 2019 at 14:16):
Systems are allowed to create business rules like that, but whoever created such business rules should be given a stern talking-to. Filtering data and ignoring data is cheap/free for the receiver. However, on the sender side, creating, testing and maintaining custom interfaces for a particular recipient that strips out the things they don't want to ignore is very costly.
Eric Haas (Jul 06 2019 at 01:34):
we believe that most applications support receiving and storing the additional coded representations.
I believe this statement is just a fhir standards formalism. In the real world, I think its really costly and unnecessary overhead to have to
implement and support the statuses as Codeableconcept instead of using code. Even though I assume the many data sources do map their local statuses to FHIR statuses in the backend, If this was critical for allergies and condition , why not for the rest of the clinical resources which currently use code?
Lloyd McKenzie (Jul 06 2019 at 02:19):
In making the statement, I was actually phrasing what the responsible work group is asserting - not necessarily what I personally believe. I agree that this couple of exceptions is problematic.
Last updated: Apr 12 2022 at 19:14 UTC
