Stream: implementers
Topic: Vocabulary WG survey on FHIR extensible binding strength
Reuben Daniels (Feb 02 2022 at 10:35):
Hi Implementers
The Vocabulary WG is interested in how implementers of the FHIR core specification and FHIR implementation guides have interpreted and implemented the FHIR extensible binding strength (see here — https://www.hl7.org/fhir/terminologies.html#strength — for R4).
To assist us, we would like you to consider the following example scenario and answer the questions which follow.
Scenario
- Code system CS1 is defined as follows:
| Code | Description | Subsumed By |
|---|---|---|
| A | Carbuncle on the knee | |
| B | Carbuncle on the thigh | |
| B1 | Carbuncle on the left thigh | B |
| C | Carbuncle on the calf | |
| D | Carbuncle on the neck |
- All concepts in code system CS1 have unique meanings.
- A profile of the Condition resource extensibly binds the Condition.code CodeableConcept data element (https://www.hl7.org/fhir/condition-definitions.html#Condition.code) to value set VS1 which is defined as a composition of only codes A, B and C from code system CS1.
Questions
-
Question 1: Assuming you wish to populate Condition.code with value B1 (Carbuncle on the left thigh) which is not in the expansion of extensibly bound value set VS1.
(a) are your implementations such that the Condition.code data element will contain two Coding elements – specifically, one for B1 and one for B (Carbuncle on the thigh) ?
(b) If your answer to Question 1(a) is yes, how do you make clear to receiving systems (which may not be able to determine that B1 is subsumed by B) that B1 is the more specific and intended value?
(c) If your answer to Question 1(a) is no, do your implementations have only a single Coding element (with value B1) for Condition.code?
-
Question 2: Assuming you wish to populate Condition.code with value D (Carbuncle on the neck) which is also not in the expansion of extensibly bound value set VS1.
(a) are your implementations such that the Condition.code data element will contain only one Coding element - specifically value D ?
(b) are your implementations such that the Condition.code data element will contain two or more Coding elements – specifically D and one or more from A, B and C ?
(c) if your answer to Question 2(b) is yes, how are those values determined ?
For those who wish to participate in this survey, please provide your answers to the questions by in this Zulip channel or directly to the Vocabulary WG co-chairs via listserv email to vocab-cc@lists.hl7.org .
Your participation is appreciated.
Thank you,
Reuben (on behalf of the Vocabulary WG co-chairs)
Lloyd McKenzie (Feb 02 2022 at 17:48):
- a) This is the only way to be compliant (and that can't change)
b) There's no mechanism to communicate which codes are more specific than other codes. You can indicate which was the selected code, but that's it
c) Doing this would be non-conformant (and that can't change)
2 a) You could have more than one, but A, B and C wouldn't make sense
b) This would be nonsensical unless the patient has really interesting anatomy or someone is conveying two problems with one element
Elliot Silver (Feb 02 2022 at 18:26):
Reuben Daniels said:
(a) are your implementations such that the Condition.code data element will contain two Coding elements – specifically, one for B1 and one for B (Carbuncle on the thigh) ?
Lloyd McKenzie said:
- a) This is the only way to be compliant (and that can't change)
That means all the IGs and profiles that have an extensible valueset, and have the common slicing pattern of restricting to one value from the corresponding code system will be unable to represent the more specific B1.
Lloyd McKenzie (Feb 02 2022 at 19:27):
No. They're free to send B1. They just have to send B too. What they can't do is send B1 by itself.
Rob Hausam (Feb 02 2022 at 19:31):
@Elliot Silver Do you have examples of the "common slicing pattern of restricting to one value from the corresponding code system" in mind? I think that pattern is not one that normally should be expected or desired. As Lloyd said, normally they should be free to include multiple Codings in a CodableConcept data type with different codes from the same code system, as there are certainly situations (particularly with extensible bindings) where that is useful and necessary.
Elliot Silver (Feb 02 2022 at 19:39):
Maybe I'm misreading it--I was specifically thinking of slicing like in IPS Immunization.vaccinationCode. I recognize that this isn't extensible, but the slicing I was thinking about is there.
... Now I'm pretty sure I was misunderstanding it -- Iet's continue on a separate thread.
Grahame Grieve (Feb 02 2022 at 20:22):
I agree with Lloyd in principle, and have advised IG authors about this many times. But there's a clear interpretational issue around subsumption. B1 might be subsumed by B, and therefore using B and not B1 is the intention of the author of the profile + value set, but users sometimes use concepts orthogonally, and would not regard B as an acceptable substitute at all for B1 (though it sounds unlikely in this case).
I will be interested to see if there's specific answers from system vendors.
Lloyd McKenzie (Feb 02 2022 at 23:40):
"acceptable substitute" isn't the question. The question is "does a code from the value set apply?". If it applies, it must be used. If it's not an acceptable substitute, then send your code too.
Lloyd McKenzie (Feb 02 2022 at 23:41):
Nothing stops you from conveying whatever precision you wish, but you must convey the level of precision in the extensible value set if you can. Interoperability depends on being able to ask "did they send any of the codes from the valueset?" and, if the answer is "no", being able to infer "then the concept is definitely NOT in the space covered by the value set".
Michael Lawley (Feb 03 2022 at 05:40):
As I see it there's a couple of issues here -- if, as in the example, you have a CodeableConcept and thus the ability to send multiple codes then things are relatively simple. What's harder (or forces more thought) is when you have an extensible binding to a code or Coding so you can only provide a single value.
In terms of subsumption and the constraint "...if any of the codes within the value set can apply to the concept being communicated", it's pretty straightforward for the B and B1 codes here. But, it may be that the semantic distance between B1 and B is much greater than just laterality. In this case I would expect that a subsumed code could (and perhaps should) be used on its own. Additionally, whether the difference between B1 and B is significant or not is going to depend on context of usage; it's going to need a human to make the call.
Lloyd McKenzie (Feb 03 2022 at 05:58):
You cannot have an extensible binding for 'code'. All code elements must have a required binding.
Extensible bindings for Coding elements would need to be used with extreme caution. However, they're also extremely rare. They're used for things like ElementDefinition.code or Questionnaire.item.code where multiple repetitions are essentially already translations, so the logic works the same.
Lloyd McKenzie (Feb 03 2022 at 05:59):
Extensible pretty much always requires a human to make the call unless there's an explicit subsumption relationship between the transmitted code and one of the codes in the value set.
Cooper Thompson (Feb 03 2022 at 15:01):
In some cases, this many not be a question for implementers of the FHIR spec. Implementers of the FHIR spec don't always have control over what codes are available for a record.
Based on the specific data, the person making the decision about codes could be:
1) the implementer of the FHIR spec (e.g. an EHR)
2) the administrators of the EHR (e.g. the IT staff at a healthcare organization)
3) the end users entering data in the system (e.g. a nurse)
Very often, when it comes to mappings codes like in your example, either end users or IT admins are the decision makers. You could argue that the EHRs or other FHIR implementers should force health system administrators and end users to only be able to enter FHIR-compliant data (according to Lloyd's interpretation of extensible). But that going to be is a non-starter (and you have the legacy data challenge that I'm sure folks are tired of me bringing up). There might be levers out there to drive data quality improvements, but the FHIR spec is not one of those levers.
In my experience, neither end users nor IT admins at health systems have the time or inclination to understand the intricacies of value set subsumption and the nuance of extensible binding strength, so the answer to your question is probably "you'll get what you get", and it can vary widely, even within a single implementation.
Lloyd McKenzie (Feb 03 2022 at 16:27):
That's a slightly different issue. It's a problem with enforcing vocabulary constraints at all - be they required bindings or extensible bindings. If you don't have control over the data you've got, then you can't really comply with profiles that demand that data be coded in specific ways - and the data therefore has limitations in how well decision support, search, etc. can rely on it.
If you've got an extensible binding with a specific code for hypertension, the expectation is that if you do a search using that code and you get no hits, you can safely presume that "there are no matching records that have hypertension". If the system can't reliably promise that, then it can't claim to adhere to the binding.
So the real challenge is "Some systems want there to be tight control over terminology to support reliable search/decision support/etc. However, real-world systems often have minimal control over terminology." The issue isn't "Extensible is too firm". The issue is "profiles are asserting 'extensible' (for good reason), we can't meet that requirement, and we're being told we have to.
It's certainly possible for implementers, administrators and even end users who are given a profile and need to 'extend' the value set to adhere to the rules if the rules are explained to them and they understand the ramifications of getting it wrong. But it's exponentially harder the larger the value set and the larger the set of folks who have authority to introduce net new codes to do it 'right' - which means the reliability that search and decision support count on isn't always achievable.
If regulation is saying "thou shalt" and the implementation community is saying "but, practically, we can't", then something needs to budge. You could make it "thou should". You could make it "thou shall differentiate 'compliant' from 'non-compliant'" and tag the data that's search/CDS-safe. But we don't want to soften the definition for 'extensible' - because "can we safely search/use decision support" depends on it meaning what it means.
John Moehrke (Feb 03 2022 at 16:32):
The IETF published an RFC-6919 (on April 1st 2018) that has the normative word for that
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER",
"REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO",
"COULD", "POSSIBLE", and "MIGHT"
;-D
Grahame Grieve (Feb 03 2022 at 20:48):
You cannot have an extensible binding for 'code'
Not true. We have a few cases where we do that.
Grahame Grieve (Feb 03 2022 at 20:51):
in general, though, this makes it clear that extensible bindings should only be used for workflow related categorization, or where the semantic space is fairly clean with little subsumption, or the value sets are anchored clearly in regulation and bounded by e.g. code system
I know that we've had places where extensible bindings are used to set 'expectations' of correct behavior. @Cooper Thompson is squarely addressing these. I don't think that's appropriate. I've been meaning to define a different way to do this - I really should get to and do it. so....
Lloyd McKenzie (Feb 03 2022 at 21:00):
Where do we have an extensible binding for code? We have code bindings that aren't expandable value sets, but they're still fixed bindings...
Grahame Grieve (Feb 03 2022 at 21:05):
see https://chat.fhir.org/#narrow/stream/179202-terminology/topic/Extension.20for.20additional.20bindings for doing something about this
Grahame Grieve (Feb 03 2022 at 21:05):
Where do we have an extensible binding for code?
Where the code itself contains a grammar specified by an external authority e.g. language, media type
Lloyd McKenzie (Feb 03 2022 at 21:13):
That's still a required binding
Lloyd McKenzie (Feb 03 2022 at 21:14):
The grammar is part of the code system the value set draws from. You can't make up your own local codes in some other code system if the code system doesn't cover what you need.
Grahame Grieve (Feb 03 2022 at 21:19):
- http://hl7.org/fhir/resource-definitions.html#Resource.language - though this has been changed from extensible to preferred
- also http://hl7.org/fhir/datatypes-definitions.html#Attachment.language
- http://hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.type.code
Lloyd McKenzie (Feb 03 2022 at 21:23):
Yes, but the first two have a max value set, so that's the real binding. type.code actually needs fixing. I believe the intention is that there's a required binding to a union of the HL7 type code system and the "any URI" 'code system'. If you send something that's not a URI and not a defined HL7 type, that's an error. (And if we were to allow it, it would be unsafe.)
Robert McClure (Feb 07 2022 at 16:42):
@Grahame Grieve said:
I know that we've had places where extensible bindings are used to set 'expectations' of correct behavior. @Cooper Thompson is squarely addressing these. I don't think that's appropriate. I've been meaning to define a different way to do this - I really should get to and do it. so....
If by this you mean we need another binding type, I think I agree. We could then work to limit the existing extensible bindings to those that actually work the way we want - very few should remain. Meaning the rest are something else. Perhaps a binding that combines a small required set and either a max, or a preferred?
Lloyd McKenzie (Feb 07 2022 at 18:20):
This wouldn't be a new binding type. This would be supplemental extensions that define other things.
I disagree that very few extensible binding would remain. They'll exist in spades for IGs focused on decision support and reasoning where you're defining the rules for "what data can this logic be used against?" You won't see extensible bindings in specs defining expectations for real systems that don't have control over their own codes.
Grahame Grieve (Feb 07 2022 at 18:50):
it will reduce the number of extensible bindings but it probably won't be very few
Reuben Daniels (Feb 09 2022 at 23:28):
This is a brief reminder to those who still wish to respond that the survey closes in just under 1 week ( ).
Lloyd McKenzie (Feb 09 2022 at 23:58):
What is the objective of the survey @Reuben Daniels? The definition of 'extensible' is normative and can't be changed.
Reuben Daniels (Feb 10 2022 at 00:33):
Lloyd McKenzie said:
What is the objective of the survey Reuben Daniels? The definition of 'extensible' is normative and can't be changed.
Thanks for the question Lloyd. The objective is not to change the definition. Two of the objectives are:
-
To get an idea of how the community of implementers have interpreted the definition and have implemented extensible bindings.
-
Based on 1, and if necessary (and I suggest that it might be) and helpful, propose additional text and examples for inclusion in the specification to clarify the definition and correct usage.
Reuben Daniels (Feb 16 2022 at 13:15):
This is my last reminder for anyone still wishing to provide a response or comment on this survey. The deadline is: . Thank you.
Last updated: Apr 12 2022 at 19:14 UTC
