Stream: terminology
Topic: Required binding when all you got is text
Eric Haas (Nov 08 2016 at 23:26):
On the Argonaut call today we reviewed this issue from an earlier Zulip chat for how to deal with the use case when all you got is a bit of free text for a required CodeableConcept element. I summarized thes data elements this affects for Argonaut profiles here. @Grahame Grieve was interested in use cases and the basic use case is when your system has only text and no code and the element has a required binding. We are exploring options including :
1. proposing changes/clarification to spec for Required with CodeableConcept
2. proposing a new binding strength to specification.
3. Move everything in Argonaut profiles to extensible...
Since the consensus is this is not just an Argonaut problem we want to revisit it here.
Lloyd McKenzie (Nov 09 2016 at 00:22):
So if you have text and no code, how is that not an "Extensible" circumstance? Are you dealing with unencoded data? I.e. the concept in the text could be expressed with one of the required codes, but the sending system wasn't smart enough to do so?
Grahame Grieve (Nov 09 2016 at 02:10):
yes it sounds like extensible to me
Brett Marquard (Nov 09 2016 at 03:37):
Our struggle in Argonaut is that for almost every element we are hearing that in certain circumstances, systems may only have text -- does that mean all bindings should be extensible?
Lloyd McKenzie (Nov 09 2016 at 04:03):
They only have text because they can't map it to one of the codes, or they only have text because they don't know how to translate the text to the appropriate matching code?
Lloyd McKenzie (Nov 09 2016 at 04:03):
If the former, it's definitely extensible. If the latter, then it's a bit tougher to say.
Grahame Grieve (Nov 09 2016 at 04:10):
what's the resistance to making them extensible?
Brett Marquard (Nov 09 2016 at 04:13):
@Lloyd McKenzie it's more often the latter
Brett Marquard (Nov 09 2016 at 04:14):
One concern is ability to perform conformance testing -- with extensible, any local would be allowed...yes, I know that's not intent of extensible...
Grahame Grieve (Nov 09 2016 at 04:15):
I'm not sure that I follow. If you allow text, why not allow any local code?
Lloyd McKenzie (Nov 09 2016 at 04:16):
Alternative is to make the elements optional - provide a proper code or don't send them.
Lloyd McKenzie (Nov 09 2016 at 04:17):
Agree there's no difference between text and a local code
Brett Marquard (Nov 09 2016 at 04:17):
text you can display.
Lloyd McKenzie (Nov 09 2016 at 04:18):
You can display the "display" for a local code too.
Brett Marquard (Nov 09 2016 at 04:18):
yes, you could include text with local code which might be best solution
Grahame Grieve (Nov 09 2016 at 04:18):
text should be present anyway whatever
Rob Hausam (Nov 09 2016 at 21:51):
I agree - seems like extensible
Eric Haas (Nov 10 2016 at 01:12):
Why bother defining vocabulary at all extensible is as good as example to conformance testing. The local code is useless but the text is useful for human displayt and the use case I heard is that sometimes through translations the system may only have text (no codes)_ for a coded field with required binding.
Eric Haas (Nov 10 2016 at 01:16):
besides the Required binding instances are based on regulatory requirements which say use this. That doesn't sound like substitutions are OK.
Grahame Grieve (Nov 10 2016 at 03:53):
so when is just text ok?
Robert McClure (Nov 10 2016 at 19:09):
@Lloyd McKenzie Help me understand what you mean by saying that allowing text only (a local code = text) when there is a required binding to a value set is an "Extensible circumstance"? Do you mean create an extension to the resource/profile or do you mean change the binding, or do you mean that the value set "is extensable" so people can send anything they want in the value slot as long as they pinky-swear that they honestly really tried to translate before giving up so 'supposedly' the text does not have a meaning equal to one of the required codes?
Grahame Grieve (Nov 10 2016 at 19:15):
Lloyd is saying that if you allowed to send text instead of a code, then the binding should be extensible, since 'sir, I really did try to use a code instead of a text' is actually much less likely to be true than 'sir, I really did try to use the recommended code instead of a local code' (one use user behaviour, the other is system behaviour)
Grahame Grieve (Nov 10 2016 at 19:16):
What we're trying to understand is why the Argonaut participants think that there's a problem with an extensible binding, and want to use a required binding when they can't
Lloyd McKenzie (Nov 10 2016 at 20:29):
My understanding of the problem with Argonaut - in v3 terms - is one of UNC (unencoded), not OTH (other). I.e. the concept maps to one of the approved codes - as is required by legislation. But the concept has been captured as text and the software isn't smart enough to figure out what code is applicable. In which case, you're not really "extending" the value set. And we don't have a good solution for that use-case other than making the coded element optional and sending the text in a parallel extension.
Eric Haas (Nov 10 2016 at 20:33):
Our problem with extensible is that its too easy to "cheat". The only reason to use it is to allow for the text only option. (and yes the point on text only not following the regs is well taken) But the text can be read by the provider/patent at least. The local code is useless for that. The implementers problem with required is you can't just have text which in some cases is all they got. We could throw a DAR extension in there but they are cold to that idea.
Lloyd McKenzie (Nov 10 2016 at 21:14):
It's not really a question of cheating. Required can be validated automatically. Extensible requires human validation. But a human can easily determine whether you're compliant or not
Grahame Grieve (Nov 10 2016 at 21:25):
it's wrong to think that there's no value in a local code. Many vendors could use their own codes even if other vendors can't.
Grahame Grieve (Nov 10 2016 at 21:25):
just because the local code is not useful to everyone does not mean it is useful for nothing
Grahame Grieve (Nov 10 2016 at 21:26):
obviously a proper code is better than a local code, but if you're going to allow just text, why not allow a local code?
Grahame Grieve (Nov 10 2016 at 21:26):
and if you're going to allow just text, cheating got even easier
Eric Haas (Nov 10 2016 at 21:34):
But you are assuming there is a local code when the use case I'm describing its just text. any way it seems like the consensus here is extensible bindings. And one step down a slippery slope. @Jenni Syed and @Michelle (Moseman) Miller and @Danielle Friend have you been following this chat?
Peter Jordan (Nov 10 2016 at 21:36):
User and vendor defined codes have proved to be problematic in NZ from an HIE perspective as many of these codes don't pass RegEx tests in standards (e.g. spaces aren't permitted by HL7 v3 and CDA). While I agree that they may be useful from the viewpoint of the facility where they are created and used they are, almost by definition, not inter-operable and need to be accompanied (or replaced) by text when exchanged.
Grahame Grieve (Nov 10 2016 at 21:47):
in Australia, must of the vendors have common codes across sites. And we rescinded the space issue in FHIR because of that problem
Grahame Grieve (Nov 10 2016 at 21:47):
but agree that text should always be present
Grahame Grieve (Nov 10 2016 at 21:49):
Eric, we are not assuming that there's a local code. There should always be text. but if you allow just text, then what is the benefit of saying that you can't provide a local code?
Grahame Grieve (Nov 10 2016 at 21:54):
btw, you can do this with a requried binding if you really want - in the profile, walk into the CodeableConcept, set text to min cardinality = 1, and then coding to 0..1, with a required binding to whatever value set. Then you have said
- you have to provide text
- if you can, you provide a code from the recommended value set
Richard Townley-O'Neill (Nov 11 2016 at 04:56):
I read the definition of Extensible at http://hl7.org/fhir/2016Sep/terminologies.html in a way that does not fit this discussion.
To be conformant, instances of this element must include a code from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (from different code systems, including local ones) or (data type allowing) text) may be included instead.
I read this as saying that one uses an approved code unless nothing has the right meaning.
But this discussion assumes that Extensible means one uses an approved code if one is able.
Which is correct? Does the definition of Extensible need clarifying?
Grahame Grieve (Nov 11 2016 at 05:03):
I think that the definitions is carefully chosen and correct. There's some potential confusion about whether you aren't able to have the right code because you aren't able or because the code system isn't able to - it can be hard, operationally, to separate those
Grahame Grieve (Nov 11 2016 at 05:05):
in the end, the determination of whether there is a correct code available that wasn't used can only be done by a human. It sounds like the argonaut group wanted more certainty than that, but you can't have more certainty if you're going to allow text only
Richard Townley-O'Neill (Nov 11 2016 at 06:19):
I guess "any of the codes within the value set can apply to the concept being communicated." is to be interpreted as something like "any of the codes within the value set can be applied by the authoring system to the concept being communicated."
I think that reading is useful, but it is not obvious to me.
Lloyd McKenzie (Nov 11 2016 at 14:12):
@Grahame Grieve Right now, required binding prohibits bare text. The validation rule is "if the element is present, it must have a code from the specified value set". I.e. You can't send just text, just extensions or anything else unless you've code a coding from the value set.
John Moehrke (Nov 11 2016 at 15:03):
Seems we need to call upon the extended set of Normative words defined on April 1st 2013 in IETF RFC 6919 https://tools.ietf.org/html/rfc6919 --- 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"
:-)
Robert McClure (Nov 11 2016 at 15:53):
Perhaps we've with good intension linked two things that need to be separated: 1) the desire for an encoding to be from a specified interoperable value set, and 2) the the value of sending text humans can use to deliver care. BTW, I agree with Graham that a local code is simply a specific kind of "text" and I see no reason to not send it if you have it as long as it's clear that it is the local code and not something else. What I don't think we should allow is to consider that code as an interoperable code from a required value set.
In the binding semantics project (http://wiki.hl7.org/index.php?title=Binding_Syntax#Current_Working_Material) we can support this although "text' is not discussed specifically. This would be a binding to the "required" value set that has a strength of CEA (Coding extensions allowed) and a conformance verb of FIXED (it could be something else but since we are implementing on this binding, it's not important.) The point here is that with CEA you can send something that is NOT in the required value set as long as you flag it as "An Exception" in some way. Seems we could adopt something like this in FHIR that would allow text, +/- a local code as the exception transmission. @Ted Klein - do you agree?
Grahame Grieve (Nov 11 2016 at 20:28):
no I still don't agree with the logic of flagging that your exception to the rules is an exception to the rules. This achieves nothing than duplication and confusion.
Grahame Grieve (Nov 11 2016 at 20:28):
Lloyd, I think you need to read what I wrote again - your comment suggests you didn't understand it
Lloyd McKenzie (Nov 12 2016 at 13:56):
@Grahame Grieve You're right. I'd missed that you were doing the binding at the Coding level rather than the CodeableConcept level. That would work. (Though you'd still have to have a binding of some sort at the CodeableConcept level too.)
Last updated: Apr 12 2022 at 19:14 UTC
