Stream: argonaut
Topic: Extensible+Max
Josh Mandel (Aug 21 2019 at 15:31):
Reading the current definition:
For this IG, we have defined the Extensible + Max-ValueSet binding to allow for either a code from the defined value set or text if the code is not available. (for example, legacy data). This means, unlike a FHIR extensible binding, alternate code(s) are not permitted and a text value SHALL be supplied if the code is not available.
I am confused. Can we add an example of how this "Extensible + Max" would be used in a best-practice way? Like, a legacy system that maintains coded data but does not have a mapping into the bound valueset? What would they write to convey (as losslessly as possible) the codes the do have?
Josh Mandel (Aug 21 2019 at 15:32):
(Also, are there validation rules formalized for checking conformance to the "Extensible + Max" binding? Do any of the validators know how to implement these rules?)
Josh Mandel (Aug 21 2019 at 15:33):
Reading the definitions at http://hl7.org/fhir/R4/extension-elementdefinition-maxvalueset.html, I'm not sure what the semantics are of binding a single element to the CVX valueset with binding strength "extensible" and then again with "max". Since it's the CVX valueset in both cases, the "max" seems redundant.
Josh Mandel (Aug 21 2019 at 15:34):
So I'm not sure what https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-immunization-definitions.html#Immunization.vaccineCode is intended to accomplish.
Lloyd McKenzie (Aug 21 2019 at 15:44):
If there's an extensible + max binding, a legacy system has no choice but to map their codes to the 'max' value set. If they can't map, they can't populate the element and be conformant.
Josh Mandel (Aug 21 2019 at 16:03):
But what does it mean that "alternate code(s) are not permitted.... However, multiple codings (translations) are allowed" ?
Josh Mandel (Aug 21 2019 at 16:03):
Can't a "translation" coding be used to supply an "alternate code"?
Jenni Syed (Aug 21 2019 at 16:26):
The goal in an example: to return problems in a coded manner, must return SNOMED. Can also return translations if you have them. If you have a "freetext" problem, then just populate the text and no coded value
Jenni Syed (Aug 21 2019 at 16:26):
I know there's been all kinds of discussion around this mess
Jenni Syed (Aug 21 2019 at 16:26):
the freetext issue was the main reason we couldn't just do a required binding
Rob Hausam (Aug 21 2019 at 16:47):
The "alternate code(s) are not permitted" means that "alternate codes" that would be used instead of a code from the bound value set are not permitted. But alternate codes that are sent in addition to one of the codes in the bound value set (i.e. "translations") are definitely allowed.
Lloyd McKenzie (Aug 21 2019 at 16:56):
"alternate code" means no code from the max value set but some other code instead.
As an example, if your extensible binding was "common UCUM codes" and your max binding was "all UCUM codes", then it's not allowed to send just text or send just a CDISC code - you must have a valid UCUM code, but it's ok if the code that you send isn't in the "common UCUM codes" value set.
Lloyd McKenzie (Aug 21 2019 at 16:57):
If you have a max binding, required binding or extensible binding, implementations must be able to translate from whatever codes they have. If they can't, they can't support the element.
Eric Haas (Aug 21 2019 at 17:29):
like Jenni said is a "use this code or Free text" binding. we hashed this out several times I proposed changing the name "required or free text only , but decided that only issue ever comes up is here in a very small hl7 insider communitye and not with implementers. to drop it for now. Other prriorities
Jenni Syed (Aug 21 2019 at 17:31):
I think our issue will end up being the validators that are expecting to never see a free text or uncoded Resource and failing it
Jenni Syed (Aug 21 2019 at 17:32):
I know we get flagged in our FHIR server for this, but we literally can't code the free text things a practitioner or patient would type in
Jenni Syed (Aug 21 2019 at 17:32):
and not returning them at all isn't an option
Eric Haas (Aug 21 2019 at 17:33):
but the business need still exists and we don't have the time to be making changes now.
Eric Haas (Aug 21 2019 at 17:34):
you can point to the spec and say "look here" and this is what is means...
Rob Hausam (Aug 21 2019 at 17:57):
@Lloyd McKenzie As far as I can recall we haven't said anywhere that declaring a max value set binding precludes the possibility of sending only text (CodeableConcept.text, with no Codings) - which I think is what you are saying. If we have that clearly documented, you can point me to it. The closest that I see is in the description of the maxValueSet extension where it says that "This defines a 'required' binding over the top of the extensible binding". The problem I think with that is that it's not really clear exactly what that means. It has 'required' in quotes with no link to the discussion of the required binding strength in the Using Codes in Resources page, as we do elsewhere in the spec. So does this mention of 'required' here mean that all of the rules that are stated for a required binding must also apply in the case of the max binding, including "at least one Coding element SHALL be present", even though the extensible (min) binding doesn't require that? Either way, there's huge room for confusion here.
Lloyd McKenzie (Aug 21 2019 at 18:01):
Right now, max binding says it acts as a 'required' binding - and required bindings prohibit text only. If we want to allow text only, we need to change the description of 'max' not not refer to 'required'.
Josh Mandel (Aug 21 2019 at 18:04):
From an introperability perspective I can't understand why choosing extensible and maximum is better than just choosing extensible
Josh Mandel (Aug 21 2019 at 18:04):
maybe if the bindings were to two different value sets, but if the same valueset is being used in both bindings, what is the point?
Josh Mandel (Aug 21 2019 at 18:09):
And practically, from the validator's perspective, how does a validator tell which coding is "the one matching the extensible/max" binding, and which is a translation? Just... look for the one with only text, and call that "the one"? (What is the point of this?)
Lloyd McKenzie (Aug 21 2019 at 18:11):
It would make no sense for the value set to be the same. The use-case is always that the extensible binding is to a small (enumerable) value set that is a proper subset of the large (typically non-enumerable) value set that is the max.
Josh Mandel (Aug 21 2019 at 18:12):
But that's what we're seeing at http://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-immunization-definitions.html#Immunization.vaccineCode
Lloyd McKenzie (Aug 21 2019 at 18:12):
The validator just checks all of the codings and sees if at least one of them falls within the value set.
Lloyd McKenzie (Aug 21 2019 at 18:12):
Yeah, the us-core model makes no sense
Lloyd McKenzie (Aug 21 2019 at 18:12):
(for that one binding! :))
Josh Mandel (Aug 21 2019 at 18:13):
Lloyd McKenzie (Aug 21 2019 at 18:14):
I think that was done because there was a belief that allowed you to say "one of these codes, or just text" - but that's not what it currently says.
Lloyd McKenzie (Aug 21 2019 at 18:15):
I think the best (only?) way to say "text or this required binding" is to have an invariant.
Josh Mandel (Aug 21 2019 at 18:19):
And even if we did get the invariants right, what would be the rationale for saying "one of these codes, or just text" ?
Rob Hausam (Aug 21 2019 at 18:19):
Right. That was the purpose. I take it that what I said about "what it currently says" wasn't persuasive. But obviously the Argonaut group either missed or ignored that mention of 'required', or didn't understand how it was intended to be applied in this different context.
Lloyd McKenzie (Aug 21 2019 at 18:20):
The rationale is that some of the systems don't have codes. And they need to be able to send what they've got. However, if they have coded data at all, they're expected to create a translation to the official code system.
Lloyd McKenzie (Aug 21 2019 at 18:22):
"Extensible" clearly prohibits sending just text if the text content is representable by the extensible value set, so an extensible binding wouldn't have met the desired intent, regardless of how max value set was defined.
Josh Mandel (Aug 21 2019 at 18:35):
But the real-world challenge is that some of the systems don't have standardized code mappings (whether the source is free text or a local code).
Josh Mandel (Aug 21 2019 at 18:36):
Why stop them from sharing the info they do have (whether text, or text + local code)? What purpose does this serve?
Rob Hausam (Aug 21 2019 at 18:45):
Yes, that was their point - they want to be able to send what they have, even if it's only text - and if it is sent as coded, then they want to require that one of the codes must be from the bound value set. They were not intending to send only text in a case where the text content is representable by the bound (extensible) value set.
Josh Mandel (Aug 21 2019 at 18:48):
But that's what "extensible" already means, isn't it? What's the gap?
Lloyd McKenzie (Aug 21 2019 at 18:48):
@Josh Mandel I think the rationale is the belief that if the systems have codes that they'll always be able to map and that it's reasonable to expect them to do so. (And that forcing the mapping dramatically increases the interoperability/computability of the data.) If we left the binding open, implementers would just send whatever they had, wouldn't bother with translation and there'd be no interoperability.
Brett Marquard (Aug 21 2019 at 18:48):
Extensible allowing text only would solve our goofy binding name...
Brett Marquard (Aug 21 2019 at 18:49):
well, folks are telling us that the belief that systems always having codes isn't the case!
Josh Mandel (Aug 21 2019 at 18:49):
If we left the binding open, implementers would just send whatever they had
But we're currently saying that they should just drop the codes they have and send text instead. How is that better?
Rob Hausam (Aug 21 2019 at 18:49):
I think you mean "required allowing text only", Brett?
Brett Marquard (Aug 21 2019 at 18:50):
thanks Rob, correct.
Josh Mandel (Aug 21 2019 at 18:52):
Basically we're offering a validation escape-hatch: "omit your codes and just pass your text along". Can someone explain how this is better than the escape-hatch of "pass your text along, and your codes if you have any"?
Josh Mandel (Aug 21 2019 at 18:52):
(The latter wouldn't need any special new binding types, and would allow servers to express themselves more completely.)
Josh Mandel (Aug 21 2019 at 18:53):
Sorry if I'm just repeating myself here; I'm really trying to understand the argument for making bindings still more complex than they already are.
Rob Hausam (Aug 21 2019 at 18:56):
if I can interpret, I think what is actually wanted is "if you can code the data from this value set, then you must - but if the meaning of your data isn't covered by the codes included in this value set then you can send only text"
Eric Haas (Aug 21 2019 at 19:06):
I disagree and have disagreed with Lloyd and Rob's interpretation of max value extension all along and still do. The binding is extensible which allows free text only and the extension says you can't use any other codes. So them repeating the same f$#%^#$%^ thing over and over does not in my opinion make it so.
Rob Hausam (Aug 21 2019 at 19:08):
I don't think that Lloyd's and Rob's interpretation are entirely the same here (unless I'm confused) - are you able to be a little bit more specific?
Eric Haas (Aug 21 2019 at 19:09):
the extension is changing the binding rules to required
Rob Hausam (Aug 21 2019 at 19:10):
I think that's what I just disagreed with Lloyd about
Jean Duteau (Aug 21 2019 at 19:11):
umm, but doesn't the extension explicitly say that: "This defines a 'required' binding over the top of the extensible binding."
Eric Haas (Aug 21 2019 at 19:11):
Oh my apologies. leave to terminology to get my dander u p
Jenni Syed (Aug 21 2019 at 19:12):
@Josh Mandel The challenge was also around validation of extensible. We really did expect the system to be able to bind any coded value to the value set. And then there's data that truly isn't coded
Jenni Syed (Aug 21 2019 at 19:13):
I'm almost to the point of "i give up" here. We were trying to encode ONC requirements around standards, and allow for "free text" (things that are literally a string in the local system)
Rob Hausam (Aug 21 2019 at 19:14):
That phrase seems to be the sticking point, @Jean Duteau. For some reason 'required' is stated in quotes but extensible following it a few words later is not - and for both of them there is no hyperlink to the relevant documentation, which would have made it clearer if that was the intent.
Jenni Syed (Aug 21 2019 at 19:14):
Argonaut did a ton of discussion with FHIR-I to come up with the max binding as a solution (with a lot of that conversation likely here or in older conversation groups). It apparently didn't do what we thought it did, though I remember Grahame very much not likely that we were blocking proprietary codes if we don't have the SNOMED (for example)
Eric Haas (Aug 21 2019 at 19:15):
in R3 = "
The maximum allowable value set, for use when the binding strength is 'extensible'. This value set is the value set from which extensions can be taken from."
in R4 changed to "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."
Rob Hausam (Aug 21 2019 at 19:15):
Not sure I follow about "blocking proprietary codes"?
Jenni Syed (Aug 21 2019 at 19:15):
Not allowing systems to send the local code
Jenni Syed (Aug 21 2019 at 19:15):
if they don't have the standard
Eric Haas (Aug 21 2019 at 19:16):
so I am unhappy with that change as what does 'requried' ( in quotes) mean that a required ( no quotes) binding does not?
Eric Haas (Aug 21 2019 at 19:18):
I you want a binding to be required then change the binding and no need for the extension?
Jean Duteau (Aug 21 2019 at 19:21):
umm, @Eric Haas those are the same thing, so I think you have a copy and paste error above. :)
The use case that makes sense to me and validates the use of maxValueSet: I suggest you try and use this small set of codes to codify your data but if you really can't, then here is the larger value set that you are restricted to. We have this in presenting Indications for prescribing - we just want the high-level codes in ICD-10, but if you want to be ultra-specific, then we'll let you.
Rob Hausam (Aug 21 2019 at 19:21):
Apologies - I didn't go back to check what it said in STU3, which is what the Argonaut interpretation initially was based on (or DSTU2, which is the same). The third sentence of "This defines a 'required' binding over the top of the extensible binding." was added in R4.
Eric Haas (Aug 21 2019 at 19:21):
@Jean Duteau yes I updated
Eric Haas (Aug 21 2019 at 19:25):
There is currently no other way to say "only these codes or text." and because the max-valueset is now all balled up it seems useless to me for anything else either
Rob Hausam (Aug 21 2019 at 19:29):
Is the validator now enforcing all of the required binding rules when the maxValueSet extension is used (I haven't checked)?
Jean Duteau (Aug 21 2019 at 19:30):
I don't even know what "The maximum allowable value set, for use when the binding strength is 'extensible'. This value set is the value set from which extensions can be taken from." means. "...from which extensions can be taken from"???
Eric Haas (Aug 21 2019 at 19:30):
Well need to understand what required in quotes actually means that is still open to interpretation - is it required-like?
Eric Haas (Aug 21 2019 at 19:33):
@Jean Duteau this extension is in the context of a valueset in ElementDefinition the "extensions" are the extra concepts you are allowed to use
Jean Duteau (Aug 21 2019 at 19:34):
Put a set of quotes around the last 'extensible' and it seems to make perfect sense to me: 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.
Jean Duteau (Aug 21 2019 at 19:34):
I do agree that it does not accomplish what you wanted it to accomplish. If you want a binding that says "use one of these codes or just use text", we don't have a binding for that.
Eric Haas (Aug 21 2019 at 19:35):
Which binding rules rule? extensible ( can have text only? ) or required ( can't have text only)
Eric Haas (Aug 21 2019 at 19:37):
If it means make the binding required for all the codes - its useless
Eric Haas (Aug 21 2019 at 19:37):
Major Fail IMO
Jean Duteau (Aug 21 2019 at 19:38):
I would say that if you have a coded element with an 'extensible' or 'preferred' binding and then add a maxValueSet, that you have effectively created a 'required' binding to the larger value set, while indicating a preference for using the smaller value set.
Eric Haas (Aug 21 2019 at 19:40):
can't spell argonaut without Arrrrggghhh
Jean Duteau (Aug 21 2019 at 19:41):
but I'm not sure what it meant in STU3 because that language isn't clear to me.
Leaving all of this aside, it appears from you and Jenni, that you wanted to be able to say "if you are going to send a code, it must be one of these codes, otherwise just send plain text". Is that correct?
Eric Haas (Aug 21 2019 at 19:41):
that is what we have been saying - yes
Brett Marquard (Aug 21 2019 at 19:46):
Per Jean
I do agree that it does not accomplish what you wanted it to accomplish. If you want a binding that says "use one of these codes or just use text", we don't have a binding for that
Seems to sum it all up
Eric Haas (Aug 21 2019 at 19:47):
we had one until R4 - ggrrrrr
Jean Duteau (Aug 21 2019 at 19:47):
no you didn't. maxValueSet never solved your problem. The description of that extension in STU3 made no sense.
Eric Haas (Aug 21 2019 at 19:48):
I respectfully disagree
Brett Marquard (Aug 21 2019 at 19:49):
maybe we should add a 99999 to all value sets for vendors to then share their free text....(kidding)
Josh Mandel (Aug 21 2019 at 19:50):
I think we should have an extensible binding and be done with it. An extensible binding already prohibits use of proprietary codes that could map to standard values (it's just impossible to validate this automatically -- which is the situation we're in with free text anyway, so it's no worse).
Jean Duteau (Aug 21 2019 at 19:51):
I believe that you intended the maxValueSet extension to limit the codes that could be used to the value set listed in the extension without adding any further constraints on the binding. But I don't see how it really limits anything. I agree with Josh that you probably should have just stuck to an Extensible binding.
Grahame Grieve (Aug 21 2019 at 19:52):
so, catching up.... several points:
- the definition of the extension in R3 might have been what you wanted (Eric) but it wasn't consistent with the overall methodology and other uses
- it isn't what you want now
- Josh is right that it's an odd thing to do: one of these codes, or just text with no code (why no code in this case? just send the codes and text you have)
- there is a use case for max value set, and it is used a lot in snomed. But it's not bringing value here
Josh Mandel (Aug 21 2019 at 19:55):
I agree with Grahame (both the part where he said I'm right :wink: and the part where he says "there is a use case for max value set... But it's not... here")
Eric Haas (Aug 21 2019 at 19:56):
I'm not the one with the business requirements. @Jenni Syed ?
Grahame Grieve (Aug 21 2019 at 19:57):
oh - also - I'm not sure where the validator is on this. It knows the max value set extension, and checks that. But the text question... I'd have to test it
Eric Haas (Aug 21 2019 at 20:01):
Not sure wihy is so complicated if you want to say all these codes are required but we like this subset more then have any extension on required binding for preferred valueset. why change extensible to required?
Josh Mandel (Aug 21 2019 at 20:05):
(I didn't follow that.)
Eric Haas (Aug 21 2019 at 20:08):
using and extension to change a binding from extensible to required jsut so you can have a preferrred subset of codes seems like a rounsda bout way of doing it. just indicate that a subset is preferred.
Grahame Grieve (Aug 21 2019 at 20:14):
where we use maxValueSet on contentType and language, it might be simplier just to have a required binding, and a suggested common set as an extension. But there are other cases where max value set is clearly appropriate. But not this case, I think
Jean Duteau (Aug 21 2019 at 20:15):
we do have the minValueSet extension, so it seems like you can go either way - extensible/preferred + max or required + min - to express the same thing
Jenni Syed (Aug 21 2019 at 20:18):
I give up on validator hopes :) The use case we had was literally "there is NO possible code here without using NLP" - If you all say no option but go extensible, I'm fine as long as I'm still able to return free text
Jenni Syed (Aug 21 2019 at 20:19):
I don't think we were the only system with free text data in the system
Grahame Grieve (Aug 21 2019 at 20:20):
sure. we understand freetext. That's an extensible binding... what's going on here that's extra is this idea that you shouldn't codes if don't have a valid code
Grahame Grieve (Aug 21 2019 at 20:20):
required+min would be something completely different
Lloyd McKenzie (Aug 21 2019 at 20:32):
The use-case for extensible + max value set (which we do in two places in the core spec) is as follows:
- we have a single value set we expect all data to come from. However that value set is "big"/unlimited. As a result, we define a narrower set of codes that are common and suitable for a dropdown. Our expectation is that there will always be a code from the 'big' value set.
That's behavior we need in the core spec - and is now normative. It covers language and units of measure. We can't mess with it now (and don't want to).
If we want to allow text that could say anything (because we have no clue what it might say) or a code from a defined value set, then we define no binding or a preferred binding on the element overall, then define an invariant that says text.exists() or coding.in('some valueset URL').exists()
If we want to allow text only if it doesn't express something that's in our defined value set, but want to ensure that if there's a code, that at least one of the codes comes from our value set, then we define an extensible binding on the element and then define the same invariant as above. I agree with @Josh Mandel though that prohibiting a custom code from accompanying the text doesn't make much sense and is generally a bad practice.
Lloyd McKenzie (Aug 21 2019 at 20:34):
Extensible isn't something that's automatically validatable. That's life. Imposing a requirement that prohibits local codes doesn't mean you're doing proper validation because you're still not checking that the text isn't something that could have been expressed using the value set - and if you don't do that, you can't tell if the instance is valid.
Grahame Grieve (Aug 21 2019 at 20:35):
We can't mess with it now (and don't want to).
We can change the way we describe it as long as it doesn't change the meaning to implementers
Lloyd McKenzie (Aug 21 2019 at 20:38):
Right - but allowing text would be changing the meaning to implementers.
Grahame Grieve (Aug 21 2019 at 20:39):
well, wouldn't apply in the normative cases since they are code only.
Grahame Grieve (Aug 21 2019 at 20:41):
anyway, it seems to me that there are 3 outstanding issues:
- does argonaut really want to prohibit other codes if no proper code is available? (why not just use extensible?)
- if there really is a reason, what is the right way to express it
- does the validator support whatever is expressed
Grahame Grieve (Aug 21 2019 at 20:41):
the last one is a strictly process issue. The first should be decided here, and the second... maybe over on terminology track?
Josh Mandel (Aug 21 2019 at 20:43):
/poll does argonaut really want to prohibit other codes if no proper code is available?
Lloyd McKenzie (Aug 21 2019 at 20:47):
I'm assuming vote is intended to be for Argonaut members/participants?
Josh Mandel (Aug 21 2019 at 20:48):
I mean, this is fair game for anyone. Especially since it seems to be informing the US Core guidance...
Josh Mandel (Aug 21 2019 at 20:48):
(http://build.fhir.org/ig/HL7/US-Core-R4/profiles.html)
Grahame Grieve (Aug 21 2019 at 20:49):
I'm not having an opinion on this. But this won't be picked up by most of the argonaut participants who matter.... should move discussion on this to the argonaut email list?
Josh Mandel (Aug 21 2019 at 20:50):
What argonaut e-mail list? We could point people here to GitHub, but it shouldn't be private.
Grahame Grieve (Aug 21 2019 at 20:50):
the argonaut email list is not closed, though only participants can join (anyone can sign up)
Josh Mandel (Aug 21 2019 at 20:52):
What's the email list?
Eric Haas (Aug 21 2019 at 22:40):
We can discuss on the next call but most of the people who contributed to this notion are here. I am not a big fan of open polling/group think 10 days before publishing the spec either. This is way over the head of 90+ % anyway. What we tried to do was balance the needs of implementers with the regulatory requirements surrounding terminology bindings. We wanted to avoid getting polluted with local codes since cheating on standard codes using extensible bindings is easy to do since there is no way to check and allow for the free text situation with legacy data etc. So this was the compromise we chose and there were haters ever since and did what any standards org would do and changed the standard so we could not do it anymore. Moving forward the sensible thing to do is make extensible since required is too strict for implementation and live with the dilution of the standard terminology.
Josh Mandel (Aug 21 2019 at 22:43):
I think this requires further discussion; the current state makes no sense to me and It is not clear to me who is advocating for it.
Eric Haas (Aug 21 2019 at 22:44):
the current state is now extensible ?
Josh Mandel (Aug 21 2019 at 22:44):
The current state is "extensible +max" -- meaning that text is okay but local codes are forbidden -- right? That's what I think does not make sense.
Rob Hausam (Aug 21 2019 at 22:45):
Do you have specific examples of the regulatory requirements surrounding terminology bindings that you were trying to comply with? In general I don't think that regulators are usually very clear about such things and their statements are subject to (differing) interpretations.
Eric Haas (Aug 21 2019 at 22:45):
well that is no longer tenable since the extension changed
Eric Haas (Aug 21 2019 at 22:47):
reason.: the regulations named terminology and implementers had real world limitations hence get the regulated terminology and meet the industry needs.
Jean Duteau (Aug 21 2019 at 22:48):
well that is no longer tenable since the extension changed
even if the extension was what you wanted, Josh and others are questioning that since it doesn't make sense.
Eric Haas (Aug 21 2019 at 22:49):
I feel like my compentence being questioned.
Eric Haas (Aug 21 2019 at 22:49):
go read the regs yourself
Jean Duteau (Aug 21 2019 at 22:50):
we are trying to navigate a way forward for this and Grahame's first two points made real sense to me:
does argonaut really want to prohibit other codes if no proper code is available? (why not just use extensible?)
if there really is a reason, what is the right way to express it
Right now, we're discussing if #1 is really what Argonaut wanted since it does seem strange.
Eric Haas (Aug 21 2019 at 22:51):
I explained it. what is important to me is moving forward.
Jean Duteau (Aug 21 2019 at 22:52):
okay, so you are adamant that the requirement "only codes from this value set or free text" is correct. Then that is the answer to #1 and we can all try to determine how to make that expressible in the specification.
Jean Duteau (Aug 21 2019 at 22:54):
why do you think an extensible binding plus the invariant text.exists() or coding.in('some valueset URL').exists() isn't the way forward?
Eric Haas (Aug 22 2019 at 00:23):
Extensible+Max Summary
Here is a summary of the 4 place we used Extensible+Max bindings in Argo-R4/US Core and the applicable regulations:
When these were introduced it was felt in each of these cases there was need to constrain the vocab due to regulations but still allow for legacy data as strings. (The case of CareTeam the rational is not known). If they are made required then they are not strictly in line with the regulations, but cause pain for implementers dealing with real world data. If they are made extensible then there is no way to validate regulatory compliance.
https://github.com/argonautproject/R4/wiki/Max-Binding-Summary
Eric Haas (Aug 22 2019 at 00:30):
I am not adamant about it but trying to negotiate between to competing requirements and the choice is to :
- go with required
- go with extensible
- Invariant + Extensible ( invariant looks challenging to implement though)
Rob Hausam (Aug 22 2019 at 01:22):
That's a great summary. I think the issue becomes more the conformance testing expectations rather than the details of the regulations themselves. And, as you said, an extensible binding alone doesn't really give you anything that you can validate computably (which has been a longstanding issue). And the extensible binding doesn't actually help much (if at all) with legacy data that's coded, as in order to be conformant if the coded data is covered by the bound value set but the codes from the value set aren't there you would still need to strip out the legacy codes and send it as a string (as you're doing in the current approach).
Lloyd McKenzie (Aug 22 2019 at 02:04):
What I'm hearing is:
a) legacy data as strings must still be allowed
b) there's no way to computably tell whether legacy strings could have/should have been encoded using the 'approved' terminology
c) we don't want to allow local codes because there's no way to computabily tell if they could have/should have been encoded using the 'approved' terminology
Josh and I are not understanding the rationale for the difference in expectations between (b) and (c). Both are just as non-testable without a human in the loop. Both are clearly testable with a human in the loop. There's greater value in having a local code than text in cases where it truly is an extensible use-case because at least there's a chance for translation in the future.
Lloyd McKenzie (Aug 22 2019 at 02:05):
Not really understanding why the invariant is hard to implement. If the EHR doesn't have FHIRPath support, it'll have to hard-code the rules, but the rules are straightforward and clearly do what you say you want. (Though it's still unclear why you want it :>)
Eric Haas (Aug 22 2019 at 14:34):
There's greater value in having a local code than text in cases where it truly is an extensible use-case because at least there's a chance for translation in the future.
In a ideal world the intent was for the binding to be required and all the translations to occur before being transacted. The question is how much teeth does the invariant have to force the proper behavior and is it worth it (and yes we all recognize you could cram local codes into text as a cheat if allowed )?
Unless I get information to the contrary it will be rewritten as extensible.
Lloyd McKenzie (Aug 22 2019 at 15:30):
Extensible says you can only have text if the concept is not covered by a code in the value set. That means that if you have legacy data that's text only, a user must look at the text and code it in the correct code system if at all possible and only if no coding is possible would the text be sent. Is that the behavior you want?
Jenni Syed (Aug 22 2019 at 15:52):
Why are we calling this "legacy" ? :)
Jenni Syed (Aug 22 2019 at 15:55):
As much as we would like practitioners (and other systems integrating) to always have codified data, it's not always possible
Jenni Syed (Aug 22 2019 at 15:55):
it's not always a legacy data issue
Lloyd McKenzie (Aug 22 2019 at 16:04):
If it's not possible - i.e the code system can't express the concept, then extensible makes sense. If it's just that the system doesn't know how to do coded data, then that's "legacy" in that the system isn't meeting current regulatory requirements.
Lloyd McKenzie (Aug 22 2019 at 16:05):
And for things like diagnosis, it's pretty hard to not have an appropriate code, given that you can use SNOMED to say things like "disease of the liver" or other highly abstract/all-encompassing terms when you encounter something weird/essoteric.
Grahame Grieve (Aug 22 2019 at 19:37):
reading this, and thinking about what is being said... the challenge is that we really want 2 incompatible things:
- we want to push systems hard to use the right codes, but we know that there's circumstances where users don't want to comply
- we think that if we don't have automated validation, then whatever we say has no teeth and will be ignored
Lloyd McKenzie (Aug 22 2019 at 19:45):
"don't want to" is a bit prejudicial. I'd re-frame as "don't feel they can comply in all cases for reasonable cost". (I don't think any of the EHR vendors "don't want to" always send SNOMED codes. But they can't realistically have someone wade through all their existing historical free-text data at all of their hospitals and appropriately code it.
Lloyd McKenzie (Aug 22 2019 at 19:48):
In the case of "extensible", we have partially-automated validation. We have warnings spit out whenever something doesn't meet the binding. However, there is a need for a human to look at each warning and evaluate whether the warning should be treated as an error (system is non-conformant) or should be ignored (exception is appropriate). Whether there are teeth behind that is really a question of how much energy the oversight body is willing to invest. If the oversight body checks all of the warnings (or even a random percentage of them), then you've absolutely still got real teeth. If the oversight body ignores all warnings, then you've got the teeth you paid for.
Grahame Grieve (Aug 22 2019 at 19:50):
I do believe that there's no effective oversight body here right now. Hence where we are
Lloyd McKenzie (Aug 22 2019 at 19:59):
If there's no oversight at all, then even a required binding that spits out errors doesn't much matter.
Lloyd McKenzie (Aug 22 2019 at 20:02):
If we're depending on self-governance, then we need to rely - at least somewhat - on the purity of intent of the participants. If we believe that the participants (in general) want to do the right thing, then the difference between error and warning is in whether we can make the warning sufficiently clear that someone of good intention can look at it and determine whether they're in violation or not. I, personally, think the messages around extensible aren't too bad, but we could potentially make them better.
Rob Hausam (Aug 23 2019 at 23:13):
I think there's an issue with the use of an extensible binding and sending the "legacy" data that I'm not sure that we've sufficiently addressed. Validating of any of it will require human review, as Lloyd has described. But with the extensible binding it would not be conformant to send only free text if the meaning of that text was covered by a code that was in the bound value set (which is likely to be true in most instances of sending legacy data). That's what it says for the extensible binding:
To be conformant, codes in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated.
Note that it's the "concept being communicated", not the "concept that is coded". So if you are not able or willing to additionally code the legacy data (free text or coded) with the applicable code from the bound value set then in order to be able to send the data and be conformant the binding will have to be either preferred or example.
Josh Mandel (Aug 23 2019 at 23:31):
I agree with this assessment, but I'm not sure which buying we should use. Is the consensus that it is okay to provide free text even in the case when a serviceable standard code exists? And we think this meets the regulatory intent?
Lloyd McKenzie (Aug 24 2019 at 00:39):
I guess one question is in circumstances where the choice is to expose text or expose nothing, is the regulatory intent to expose nothing. (I expect that's how the regulation is written, but if that's not the intent, hopefully that's not how it'll be enforced.)
Agree that extensible doesn't fit if the usecase is "if all you have is text, send that". The same question goes to legacy local codes - though in some cases one could argue that it's practical to map and translate those, depending on volume.
Eric Haas (Aug 26 2019 at 16:34):
The intent of the regulation is to use standard codes instead of proprietary codes to enhance interoperability. I don't think we can dowse these nuances here. It is a blunt instrument and will break down in some real world use cases. A pragmatic solution is to make it extensible for now and discuss our approach with regulators.
Lloyd McKenzie (Aug 27 2019 at 03:33):
"extensible" means that if you send plain text for a diagnosis, you're non-conformant. Because you're only allowed to send text without a code if you can't find a code in the code system - and it's pretty much impossible to come up with a diagnosis that you can't code at some level of abstraction with SNOMED. In short - I don't think "extensible" is meeting your need. What I'm hearing is that there's a need to send text in cases where all you've got is text and there's no hope of getting it coded. It's not as clear what the expectation is where you've got local codes - but those local codes vary for every single hospital and thus are a huge pain to try to translate. My general leaning on the pragmatic side would be to say that for any condition that has an onset after Jan 1 2018 (or pick an alternate appropriate date) or something like that, treat the element as a required binding. Prior to that date, treat it as a preferred binding. That allows for legacy data to be a mess, but imposes no wiggle-room on new data. And it seems like something that should be manageable.
Rob Hausam (Aug 28 2019 at 03:11):
I was thinking of something similar. If it's possible to do so, handle the legacy data separately (using a preferred binding), and then use a required binding (likely the same as the current max binding) if that's what is needed to meet the regulations and ensure and test the desired level of conformance.
Josh Mandel (Aug 28 2019 at 13:18):
Does FHIR provide a way to express that bindings for one element (e.g. vaccine code) are dependent on values in the another (e.g., date)? Would you make two different profiles altogether (Old Vaccine profile & Recent Vaccine Profile), and enforce different date constraints in each?
Eric Haas (Aug 28 2019 at 15:32):
Does FHIR provide a way to express that bindings for one element (e.g. vaccine code) are dependent on values in the another (e.g., date)?
yes through invariants, but I don't see the point
Lloyd McKenzie (Aug 28 2019 at 17:17):
The point is to clearly define conformance expectations. If we want to have looser rules for "legacy" data than for "current" data (which is what I think I'm hearing the use-case is), then the only way to do that is with invariants based on dates. Extensible doesn't really support the 'looser rules for legacy data' use-case.
Eric Haas (Aug 28 2019 at 17:21):
If we want to have looser rules for "legacy" data than for "current" data (which is what I think I'm hearing the use-case is)
I did not hear that. is not a date based thing
Eric Haas (Aug 28 2019 at 17:21):
is a user based thing
Lloyd McKenzie (Aug 28 2019 at 17:52):
Presumably from a regulation perspective, the expectation is that all users need to comply starting at some date. Free text isn't going to be an option any more. If that's not the case, then not clear how we can make any conformance assertions at all.
Richard Townley-O'Neill (Aug 29 2019 at 03:43):
You can have two profiles: a tight one and a loose one. Then say "All instances SHALL conform to the loose profile (the legacy one), instances that conform to the tight profile get a gold star and bragging rights".
:stuck_out_tongue_wink:
Michele Mottini (Aug 29 2019 at 13:06):
(this is something that I actually even proposed to the ONC years back: instead of certifying conformance in a binary way give stars or colors
depending on how complete / well implemented the API is)
John Moehrke (Aug 29 2019 at 13:09):
it recognizes capability to be very compliant, while also being a realistic system. Reality is not compliant.
John Moehrke (Aug 29 2019 at 13:10):
This is well known in the Interop space going back to beginning of TCP/IP as Postel's Law
Grahame Grieve (Sep 02 2019 at 01:29):
ok I'm testing extensible+max in the validator test cases now. The validator allows just text if there's a max binding. for now
Rob Hausam (Sep 02 2019 at 04:09):
We voted on the SDWG call on Thursday to change these bindings for US Core to only extensible (without the max value set) as per GF#23773.
Rob Hausam (Sep 02 2019 at 04:12):
So I think we could keep the behavior as documented, consistent with a required binding (text only not allowed)?
Richard Townley-O'Neill (Sep 02 2019 at 04:17):
Is this a reasonable summary:
1/ when the nominated value set has a suitable code, use it,
2/ when it does not have a suitable code, use a code from a different value set or use text,
3/ using a code from a different value set or text, when the nominated value set does have a value is an error, but the error is not tested for.
Rob Hausam (Sep 02 2019 at 04:30):
@Richard Townley-O'Neill Yes, I think that's a reasonable summary for extensible (if that's what you were thinking of). But it isn't completely correct for extensible + max (either with the full required binding behavior or as Grahame has just modified it), as with the max binding when you use a code then the code (or at least one of the Codings in a CodeableConcept) must come from the max value set.
Grahame Grieve (Sep 02 2019 at 06:04):
ok I changed the validator then
Lloyd McKenzie (Sep 02 2019 at 14:26):
@Grahame Grieve changed the validator how?
Grahame Grieve (Sep 02 2019 at 19:29):
if there's only text (and no codes) and there's a max value set, then that produces an error
Rob Hausam (Sep 02 2019 at 22:50):
@Grahame Grieve So is the validator producing an error if there is only text with a max value set binding, or is it now the way you said above as "The validator allows just text if there's a max binding"?
Lloyd McKenzie (Sep 02 2019 at 23:06):
Based on the current definition of 'max binding', it should be raising an error if there isn't a code from the max value set.
Grahame Grieve (Sep 03 2019 at 02:07):
raising an error if there isn't a code from the max value set
That's what it's doing now
Yunwei Wang (Sep 03 2019 at 21:30):
So I think we could keep the behavior as documented, consistent with a required binding (text only not allowed)?
@Rob Hausam Do you mean the behavior of "max" binding?
Rob Hausam (Sep 03 2019 at 21:54):
@Yunwei Wang Yes, I meant the behavior of "max" binding, which is described as being a 'required' binding (so presumably it should behave according to the rules that are documented for required bindings).
Eric Haas (Sep 04 2019 at 01:44):
think of it this way....Max binding extension will change extensible to required if the valuesets are the same.
Yunwei Wang (Sep 04 2019 at 16:13):
If the valueset are the same, why not just change the binding strength to required.
Eric Haas (Sep 04 2019 at 16:17):
That case is formalism to illustrate what the extension does to the binding. in real life your max binding valueset is a superset. see for example here: http://build.fhir.org/patient-definitions.html#Patient.communication.language
Last updated: Apr 12 2022 at 19:14 UTC
