Stream: argonaut
Topic: CodeableConcepts with required bindings
Michelle (Moseman) Miller (Mar 27 2019 at 13:42):
Need a refresher on whether DAR can be used on CodeableConcepts with required bindings.
Specifically, http://build.fhir.org/terminologies.html#required says
at least one Coding element SHALL be present
one of the Coding values SHALL be from the specified value set
Anytime the CodeableConcept has a Required binding (such as US Core's DocumentReference.type), do the above SHALL statements prevent us from sharing the local code and/or text when we weren't able to map our local code to a code in the required value set? Using a data absent reason (DAR) extension doesn't seem to satisfy the SHALL statements. Can you help me understand whether the local code and/or text can be shared without a coding from the specified value set? Or, do we need to reconsider loosening the binding strength to Extensible instead?
Eric Haas (Mar 27 2019 at 14:30):
We used the max binding to allow text only
Eric Haas (Mar 27 2019 at 14:31):
Or only these codes
Eric Haas (Mar 27 2019 at 14:32):
Not an answer to your question
Eric Haas (Mar 27 2019 at 14:37):
Short answer is we say you can use DAR on the code element. But I’m not sure if it will pass validation
Eric Haas (Mar 27 2019 at 14:37):
Pass
Eric Haas (Mar 27 2019 at 14:38):
Thé validator may be looking for the code
Brett Marquard (Mar 27 2019 at 14:45):
Have there been any recent conversations to rename the 'max' binding? It seems about every few months we get a question!
Eric Haas (Mar 27 2019 at 14:57):
we can name it anything we want. required + text?
Eric Haas (Mar 27 2019 at 14:57):
required or text?
Lloyd McKenzie (Mar 27 2019 at 15:23):
If an element has a 'required' binding, that element can only be present if it includes a coding from the bound value set. It can't be present if it only contains text, extensions or anything else that doesn't also include a coding from the bound value set.
Lloyd McKenzie (Mar 27 2019 at 15:24):
A 'max' required binding doesn't allow text only. If you want text-only, the binding strength needs to be 'extensible'.
Brett Marquard (Mar 27 2019 at 15:34):
see, even Lloyd doesn't get what we did :)
Brett Marquard (Mar 27 2019 at 15:36):
see Extensible + Max-ValueSet binding for CodeableConcept Datatype
Lloyd McKenzie (Mar 27 2019 at 15:42):
If that's what's happening, then the definition of the max-valueSet extension is broken. Because it says "This defines a 'required' binding over the top of the extensible binding.". And a required binding doesn't allow a 'text' element unless there's a coding from the specified value set.
Lloyd McKenzie (Mar 27 2019 at 15:44):
You're going to need to revamp the definition of the max-valueSet to explicitly allow free-text. (and if you didn't have that exception, there'd be no need for the max-valueSet extension because you'd just slice and declare both your extensible/preferred and your required binding.
Eric Haas (Mar 27 2019 at 16:00):
I have no idea what you said in that last part.
Eric Haas (Mar 27 2019 at 16:02):
first of all there are like 5 people who know what what the min and max binding do.
Eric Haas (Mar 27 2019 at 16:04):
and we limit ourselves to basically 3 bindings ( since preferred == example)
Eric Haas (Mar 27 2019 at 16:05):
shockingly in the real world things are not that simple
Eric Haas (Mar 27 2019 at 16:06):
so we wanted required without the heavy handed constraint of no text only
Eric Haas (Mar 27 2019 at 16:07):
the way I read it is take the extensible with its text only option and lose the extensible code part
Eric Haas (Mar 27 2019 at 16:11):
a 'required' binding over the top of the extensible binding."
Means to me just that, take the extensible binding and restrict the code set so you can't add on to it.
Eric Haas (Mar 27 2019 at 16:12):
(deleted)
Eric Haas (Mar 27 2019 at 16:16):
the caveat here is the max binding == regular extensible binding
Eric Haas (Mar 27 2019 at 16:17):
Otherwise is no different than a required binding
Eric Haas (Mar 27 2019 at 16:22):
I agree the definition could be be improved by striking out the entire second sentence in
The maximum allowable value set, for use when the binding strength is 'extensible' or 'preferred'. This value set is the value set from which additional codes can be taken from. This defines a 'required' binding over the top of the extensible binding.
Lloyd McKenzie (Mar 27 2019 at 16:54):
I understand what you want. (required + text). I'm just saying that, with its current definition, maxValueSet isn't giving you that. So make a change request to update the description of maxValueSet to what it needs to be.
Jenni Syed (Mar 27 2019 at 17:54):
So let's step back to Michelle's original question. As it stands today, US Core has several required value sets. The stance is that NO data can be provided if you don't map to the actual value set? DAR for code does not work so that you can provide other translations, and display (text) also can't be provided.
Jenni Syed (Mar 27 2019 at 17:54):
I think the argo max value set issue probably needs to be dug into, I thought we did this on guidance from previous threads :)
Lloyd McKenzie (Mar 27 2019 at 18:45):
It's weird to allow text but not other codes. And if you allow text + other codes, then you're essentially extensible.
Jenni Syed (Mar 27 2019 at 18:53):
I think this got more strange when some PC concepts moved their statuses (things that are commonly required bindings) to codeableConcepts.
Jenni Syed (Mar 27 2019 at 18:53):
clincial and verification statuses
Jenni Syed (Mar 27 2019 at 18:53):
But DocType is another good example
Eric Haas (Mar 27 2019 at 18:59):
(deleted)
Eric Haas (Mar 27 2019 at 19:07):
so now I see the issue. what used to be a code where DAR works cleanly is now A codeableConcept. too many options?
Eric Haas (Mar 27 2019 at 19:07):
@Jenni Syed what do you want the answer to be?
Eric Haas (Mar 27 2019 at 19:08):
we coould profile them back to code. ;-)
Yunwei Wang (Mar 27 2019 at 19:14):
we coould profile them back to code. ;-)
Is that allowed?
Eric Haas (Mar 27 2019 at 19:23):
by allowed yes it is possible by constraining all but a single code, whether a good idea is another question because it would wreck interop
Lloyd McKenzie (Mar 27 2019 at 19:31):
The equivalent of 'code' is just a required binding. "You must have a code from this value set if the element is present" - no plain text, no just extensions. (As an aside, technically you can't send a regular 'code' element with an extension in place of a value either because that would violate the required binding.)
Jenni Syed (Mar 27 2019 at 20:21):
Found the old conversation: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/missing.20required.20field
Jenni Syed (Mar 27 2019 at 20:21):
It sounds like "required" with a required binding means DAR isn't useful anymore
Jenni Syed (Mar 27 2019 at 20:22):
I don't think that was understood
Jenni Syed (Mar 27 2019 at 20:22):
Also, most required fields in FHIR are code fields (statuses) at least in core
Jenni Syed (Mar 27 2019 at 20:23):
So I know some of this may also be resolved now that "unknown" is in most statuses. Which relegates this back to IGs and profiles?
Lloyd McKenzie (Mar 27 2019 at 20:26):
If you've got an "unknown" you're relatively ok
Eric Haas (Mar 27 2019 at 20:28):
that solves codes, what about codeables without "unknown" are there any of those?
Eric Haas (Mar 27 2019 at 20:29):
I will need to review the DAR bit in US Core. (I would prefer if DAR wiped out the binding too. that is a modifier.)
Eric Haas (Mar 27 2019 at 20:31):
I guess we could tack on unknowns to the valuesets if we needed to.
Lloyd McKenzie (Mar 27 2019 at 20:31):
Modifiers change interpretation of data, they don't change model constraints
Eric Haas (Mar 27 2019 at 20:33):
OK a magic extension then
Lloyd McKenzie (Mar 27 2019 at 20:34):
Any magic would be new methodology which would change the behavior of binding strength of required, which is now normative, so it'd have to be magic indeed...
Brett Marquard (Mar 28 2019 at 01:50):
Isn't the point of DAR to safely handle a 1..1 required?
Brett Marquard (Mar 28 2019 at 01:53):
Thinking about US Core/Argonaut, a simple response would be to make everything we can 0..1 'Must Support' which doesn't feel right.
Lloyd McKenzie (Mar 28 2019 at 04:20):
There's a difference between 1..1 element and a 'required' binding.
Lloyd McKenzie (Mar 28 2019 at 04:22):
You can absolutely use DAR with a non-coded element. You can also use with 1..1 coded elements that don't have required bindings. If it's got a required binding and it's 1..1, you have to pick one of the approved codes or not send the instance. If you don't think the set of codes covers the use-cases, then you need to propose an addition and, for prior releases, you've got a choice of not sending data or picking what's closest/safest.
Michelle (Moseman) Miller (Mar 28 2019 at 13:04):
Going back to my initial question, it seems we have consensus that a CodeableConcept with 1..1 cardinality and required binding (and no unknown in the value set) is problematic when we don't have a value at all or want to allow text and/or local codes that couldn't be mapped to a code in the required value set. I think there are 5 specific elements that applies to:
- DocumentReference.type
- AllergyIntolerance.clinicalStatus (invariant makes cardinality required most of the time)
- AllergyIntolerance.verificationStatus
- Condition.clinicalStatus (invariant makes cardinality required for non-In Error problems)
- Condition.verificationStatus
For Condition and AllergyIntolerance clinicalStatus, our profiles are at the mercy of the base spec. FYI - The data type change from code to CodeableConcept was made to allow SNOMED codes as translations.
For the others, I think Argonaut (and US Core) do have some choices to make in R4. I recommend the following changes (and I can log a tracker if there is general agreement here):
- DocumentReference.type -- change to extensible binding
- AllergyIntolerance.verificationStatus -- change to 0..1
- Condition.verificationStatus -- change to 0..1
Lloyd McKenzie (Mar 28 2019 at 14:24):
Thanks for the summary Michelle. I don't understand how the transition from code to CodeableConcept made any difference. The cardinalities are what matter in terms of narrative-only. If the cardinalities are over-tight for Condition and AllergyIntolerance, the correct solution is to loosen the constraints. I recognize that doesn't fix things for published releases, but it's absolutely the correct thing to do going forward. Cardinality in the base resource is never supposed to be about what "should" happen, it's about what we're confident will always exist.
Michelle (Moseman) Miller (Mar 28 2019 at 15:03):
<edited> I was recalling GF#18833 incorrectly. In this past discussion, when Patient Care was presented with use cases where clinicalStatus didn't exist, PC updated the invariant to not require clinicalStatus for diagnosis
Lloyd McKenzie (Mar 28 2019 at 15:06):
You shouldn't have been able to use a DAR with a code data type. If you could, that's a tooling error.
Michelle (Moseman) Miller (Mar 28 2019 at 15:33):
I edited my comments to clarify. I forgot that Patient Care also edited the Condition invariant, such that clinicalStatus isn't required for encounter-diagnoses (only problems) now.
Jenni Syed (Mar 28 2019 at 16:33):
@Lloyd McKenzie Why can't it be used with code?
Jenni Syed (Mar 28 2019 at 16:33):
or are you saying it couldn't be used for a required code binding?
Eric Haas (Mar 28 2019 at 16:59):
Yes Lloyd is saying both since code is usually required binding. Lloyd's assertion requires further discussion since ramifications are deeply disruptive to implementation behavior.
Lloyd McKenzie (Mar 28 2019 at 18:30):
If something has a type of 'code', it always has a required binding.
Eric Haas (Apr 02 2019 at 19:17):
Here is a summary of the binding for US Core R4. We will have to look at all of them.
https://github.com/HL7/US-Core-R4/wiki/Survey-of-Required-Coded-Elements
Eric Haas (Apr 03 2019 at 02:36):
here is a summary of the required status element bindings in the the Currrent FHIR build for comparison: https://github.com/Healthedata1/MyNotebooks/wiki/Summary-of-required-status-element-with-required-binding
Eric Haas (Apr 04 2019 at 23:36):
I don't understand the rationale behind the invariant and switch to codeable for Condition and Allergy clinicalStatus. I think it worthwhile discussing whether there are use cases where the status is not known and whether to log a tracker to remove the invariants. Statuses being codeable is a clear outlier and annoying.
So is here is my list ( including some Michelle missed):
- DocumentReference.type -- - we actually voted against "change to extensible binding" for this in US Core ballot GF#19914 can we update the valueset to "all LOINC values whose SCALE is DOC in the LOINC database." and include an unknown? @Brett Marquard
- AllergyIntolerance.verificationStatus -- change to 0..1 Must Support
- Condition.verificationStatus -- change to 0..1 Must Support
- CareTeam.status -- change to 0..1 Must Support
- Immunization.status -- FHIR core binding and cardinality, Discuss whether there are use cases where the status is not known in and whether the resource has any worth if status is absent or unknown. Then if warranted log a FHIR Tracker to PHER
- DocumentReference.status -- FHIR core binding and cardinality, Discuss whether there are use cases where the status is not known in and whether the resource has any worth if status is absent or unknown. Then if warranted log a FHIR Tracker to SDWG
- CarePlan.text.status -- FHIR core binding and cardinality, Discuss whether there are use cases where this status is not known and whether the resource has any worth if status is absent or unknown. Then decide what to do :-)
- Goal.lifecycleStatus - -- FHIR core binding and cardinality, Discuss whether there are use cases where the status is not known and whether the resource has any worth if status is absent or unknown. Then if warranted log a FHIR Tracker to PC
Brett Marquard (Apr 05 2019 at 12:40):
I find it interesting that instead of using Data Absent Reason, we are going to start pushing unknown into our Implementation Guide value sets. Seems like we are pushing a real problem around - @Grahame Grieve @Lloyd McKenzie is this the preferred approach of FHIR-I?
Grahame Grieve (Apr 05 2019 at 12:43):
I think it’s better to put the code in the value set itself
John Moehrke (Apr 05 2019 at 13:15):
Many of these should be recommended to be changed in R5. Because of the lockstep movement, the IG might need to hack the constraint into your IG, while the IG documents that it is tracking a CR targeting R5. This is a common governance process that IHE uses. In this way when R5 comes around, you have reminders of what hacks could now be removed. Rather than relying on humans to remember.
Brett Marquard (Apr 05 2019 at 13:24):
although I am reminded when the base is 0..1 required that's not possible.
Eric Haas (Apr 05 2019 at 22:37):
Tracker to correct GF#20696
Eric Haas (Apr 05 2019 at 22:40):
We can't hack a constraint for a 1..1 required binding element. Based on the conformance and profiling rules that is as tight as it get and you can't loosen it.
Eric Haas (Apr 05 2019 at 22:40):
is a one way street.
Grahame Grieve (Apr 06 2019 at 22:29):
when the base has a required binding.... the committee is asserting that all relevant use cases are core committee business. You have to take any issues to them
Eric Haas (Apr 07 2019 at 03:28):
and we will
Jay Lyle (Apr 12 2019 at 16:22):
I'm hearing this:
1. required binding = no DAR. If you might not have a valid value, cardinality should allow omission. If it doesn't, and you're implementing DSTU2, you are stuck. Perhaps you could use an extension to modify the meaning of the selected code. You certainly need to educate recipients on the limitations of the code. Going forward, an 'unknown' value may be adopted in these cases. (Though maybe "unassigned" or "NI" would be better than "unknown.")
2. Max may or may not require work, but if it doesn't then the US Core binding Brett pointed to does.
Re the CC type change:
SNOMED was the example, but we're hitting the issue far in advance of that. The issue is that we have status values that are not in FHIR, and that are not bijective with FHIR. At the same time, interoperability requires core-defined codes. CC supports both requirements, and I'm not sure I see what the problem is with this approach. I gather that some would prefer simply to use cardinality on the FHIR code and to let implementers add whatever extensions they need for more refined status values. I prefer using a single element, as the two values are, or should be, representing the same meaning, which shouldn't be repeated in separate elements. That way the more precise value is directly associated with the mapped value.
Brett Marquard (Apr 12 2019 at 16:55):
see GF#20696
Brett Marquard (Apr 12 2019 at 16:56):
for US Core based on R4 we plan to update cardinality to 0..1 in places we are stuck
Eric Haas (Apr 12 2019 at 22:21):
If you have extra status then as you use extensions. That is the stance I am taking. I think what PC did was a mistake and would like to see the codeables return to code for R5.
Grahame Grieve (Apr 13 2019 at 01:00):
we have status values that are not in FHIR
In which case, you need to take it up with the committee - they've asserted it's under control
Michelle (Moseman) Miller (Apr 15 2019 at 19:52):
If something has a type of 'code', it always has a required binding.
@Lloyd McKenzie There are a couple cases where I see a preferred binding strength with a code data type (e.g. Attachment.language). Should that be a required binding since the data type is code?
Lloyd McKenzie (Apr 15 2019 at 21:47):
Yes. Can you please submit a change request? (That's a candidate for an R4 patch)
Michele Mottini (Apr 15 2019 at 21:50):
Wouldn't that be a breaking change to a normative data type?
Grahame Grieve (Apr 15 2019 at 21:51):
that's not a justified change. that's a carefully chosen binding and an example of one of the special cases for preferred or extensible bindings on a code attribute. Note that it has a max binding
Grahame Grieve (Apr 15 2019 at 21:53):
it arises because there's a grammar with unlimited possible values in the code element, even if it has a max (=required) binding to a single value set
Lloyd McKenzie (Apr 16 2019 at 01:38):
Ah. If there's a max, we're fine.
Last updated: Apr 12 2022 at 19:14 UTC
