Stream: argonaut
Topic: Required CodeableConcepts
Eric Haas (Dec 20 2016 at 22:36):
Argonaut Decision was to: allow for text only for the CodeableConcepts elements with Required bindings. We had discussed applying an invariant to say “either the code from the required valueset or text”. But applying the invariant is not straightforward ( the specifying a code from a value set part in particular) So I elected to fall back to other option of requiring text in all cases. See this example here. I will be updating the guidance to explain this more clearly.
Grahame Grieve (Dec 20 2016 at 23:04):
so you know that the validator won't support this?
Eric Haas (Dec 21 2016 at 00:05):
what do mean by 'this' - the binding on coding?
Eric Haas (Dec 21 2016 at 00:19):
hmmm .... I need to slice this in order to have it work.
Lloyd McKenzie (Dec 21 2016 at 01:25):
You mean put your required binding on a slice? Because Grahame's right - if the required binding is on the codeable concept, the validator won't let you have text without also having a coding from the value set.
Grahame Grieve (Dec 21 2016 at 01:36):
I still don't know why you need slicing here. This is a stanard extensible binding, so far as we have discussed. I'm failing to grasp what the resistance to this simple solution is
Eric Haas (Dec 21 2016 at 17:40):
Just to refresh your collective memory . We have already discussed this a couple of times.
- https://chat.fhir.org/#narrow/stream/terminology/topic/Required.20binding.20when.20all.20you.20got.20is.20text
- https://chat.fhir.org/#narrow/stream/implementers/topic/Definition.20Problem
Neither required nor extensible bindings work here. The need is for a non-extensible binding which allows free text. ( ie only codes from the value set or if all you got is text then text.)
Eric Haas (Dec 21 2016 at 17:43):
OK I see that it collapses into extensible binding and I see that. What I don't see is how you can say " we don't have a standard code but we got this alternate code we want to send anyway as a translation (and it may even come from the same codesytem) but be clear it not the standard code. Do we need to pull out the valueset extension and slice on that?
Eric Haas (Dec 21 2016 at 18:15):
and for context. The regulations say you need to use valueset X and the vendors are saying sometimes all we got is a bit of text.
Lloyd McKenzie (Dec 21 2016 at 18:34):
Reality and regulations don't necessarily go well together. But you've got to decide which of the two the specification is going to reflect. Required in FHIR says you must send one of the approved codes if you send the element at all.
Lloyd McKenzie (Dec 21 2016 at 18:34):
To do what you want - can send text, but if you send a coding, one of them must be from the specified value set is *hard*. You'd essentially have to use an invariant
Eric Haas (Dec 21 2016 at 18:45):
How do you slice by valueset?
It says here:
"When a constraining structure designates one or more discriminators, it SHALL fix the value of the element for each discriminator for each slice (using ElementDefinition.fixed[x]), or if the element has a terminology binding, it SHALL be associated with a complete binding with a required Value Set that enumerates the list of possible codes in the value set. "
and I had alway assumed the discriminator would be code but now I'm thinking maybe its by extension.url? would that work? and then keep the required binding on code with a card of 0..1
so a slice: Unordered, Open, by url?
Eric Haas (Dec 21 2016 at 18:57):
We can revisit the all-I-got-is-a-bit-0-text extension on code ? which = http://hl7.org/fhir/extension-data-absent-reason.html Which is where the argonaut discussions started...
Lloyd McKenzie (Dec 21 2016 at 19:00):
You can slice by profile, but not by value set. But slicing wouldn't meet your need because you don't want a mandatory slice, but want to require that if anything's present, at least one slice matches your value set. There's no way to do that by slicing.
Eric Haas (Dec 21 2016 at 19:05):
- So a question about the spec? Is the discriminator code if the element has a terminology binding? ( there are no examples that show this - only a bunch of fixed values)
Lloyd McKenzie (Dec 21 2016 at 19:17):
I'm not following the question
Eric Haas (Dec 21 2016 at 19:26):
when " the element has a terminology binding, it SHALL be associated with a complete binding with a required Value Set that enumerates the list of possible codes in the value set. " is the discriminator code?
Lloyd McKenzie (Dec 21 2016 at 19:34):
I'm afraid I don't know how to slice by value set. But even if it were possible, slicing wouldn't meet your needs. A 0..1 slice would say it's fine to have any coding you like and a 1..1 slice would say the coding always has to be present. In order to say "must have a coding that matches this value set *or* text", you need an invariant.
Eric Haas (Dec 21 2016 at 19:55):
OK - thanks for the answer on slicing by value set.
I have a couple place where I do slice by valueset and I would think there is a need for that generally ( e.g first coding is the standard answer list and second is the local answer list etc ). but like you said you could use an invariant instead.
To use an invariant I may need the valueset extension.
Back to the binding and using a data-absent-reason extension on code. Do you know if that will validate? I'll check that out too.
Grahame Grieve (Dec 21 2016 at 20:06):
so what you realy want is a variant of extensible that says 'if you don't provide one of the correct codes, you have to provide text only, not an alternate code' . I don't think that's a useful rule, personally, But if you really want to make it, there's 3 different ways to go about it:
- use a required binding on the code.coding, and no binding on the code itself
- use an extensible binding on the code, with a fhirpath constraint that either fixes coding.system or the value set (coding in '[url'])
- define a max value set using the max value set extension which is the same as the main value set
Eric Haas (Dec 21 2016 at 20:22):
- use a required binding on the code.coding, and no binding on the code itself is what I did here and you pointed out I won't validate.
Lloyd McKenzie (Dec 21 2016 at 20:26):
Required binding on code.coding would prevent translations
Grahame Grieve (Dec 21 2016 at 20:27):
as I understand it, preventing translations is the goal.
Grahame Grieve (Dec 21 2016 at 20:28):
I don't recall saying that wouldn't validate. Perhaps I misunderstood
Eric Haas (Dec 21 2016 at 20:31):
Thanks for the suggestions and I'll take another stab at this.
Eric Haas (Dec 21 2016 at 20:31):
Very helpful BTW
Lloyd McKenzie (Dec 21 2016 at 21:23):
Why would you want to avoid translations? Obviously you want the primary code to be there if data is coded, but not allowing translations is generally a bad thing.
Grahame Grieve (Dec 21 2016 at 21:24):
I agree, but that that's the whole sticking point of extensibility here
Jenni Syed (Dec 21 2016 at 22:32):
@Grahame Grieve It's not preventing translations. It's allowing for truely freetext and uncodified fields. What we want to say is you MUST provide a LOINC (and, as required allows, you can additionally provide more translations). But you can also have a "freetext" value
Jenni Syed (Dec 21 2016 at 22:33):
that will never have a code - proprietary or other - the backing data is truely a string typed in by the practitioner
Jenni Syed (Dec 21 2016 at 22:33):
LOINC being the example, but this applies pretty broadly to the "code" concept in many resources
Grahame Grieve (Dec 21 2016 at 22:34):
so that's just a straight extensible binding.
Jenni Syed (Dec 21 2016 at 22:34):
No, because then you can provide any other code than LOINC, not be able to be validated/failed, and still meet the profile
Grahame Grieve (Dec 21 2016 at 22:35):
but that's what you described
Jenni Syed (Dec 21 2016 at 22:35):
No, there is *no* codeable in my example at all. Only freetext. and only rarely. Most values will have a code meeting the required.
Jenni Syed (Dec 21 2016 at 22:36):
If we losened to extensible, it's valid for someone to choose, say, SNOMED or some other code and be in compliance/validated against the profile
Grahame Grieve (Dec 21 2016 at 22:36):
so you're saying that if it's coded, it *has* to be coded in the specified value set?
Jenni Syed (Dec 21 2016 at 22:36):
Correct
Jenni Syed (Dec 21 2016 at 22:36):
which matches with regulation as well
Grahame Grieve (Dec 21 2016 at 22:36):
that goes against all our existing practice as demanded by implementers, because the value sets and code systems can never keep up
Jenni Syed (Dec 21 2016 at 22:37):
So far, Argonaut implementers have been in agreement as this also meets required regulation for CCDS by the ONC
Grahame Grieve (Dec 21 2016 at 22:38):
well, this is an extensible binding with a max value set = the extensible value set
Jenni Syed (Dec 21 2016 at 22:38):
Yes, when we've discussed previously, we thought it would be easier to define this with a different or special binding, but there didn't seem to be any appetite for that (and it wouldn't fix the DSTU 2 issue)
Jenni Syed (Dec 21 2016 at 22:40):
I assume, as the profile goes through ballot, we'll see how/what comments come in as more eyes look at this. But for now, this was the compromise/proposal to try to get as close to regulation as possible
Grahame Grieve (Dec 21 2016 at 22:40):
well, Eric, that's how to do this correctly - an extensible binding with a max value set, and the validator supports that (or will, if it doesn't now)
Robert McClure (Dec 21 2016 at 23:16):
I'll weigh in here and say that I thnk the described binding needed is clear and I want to make sure I'm following how @Grahame Grieve says an extensable binding will work for this. If you make the binding REQUIRED, EXTENSABLE and MAX VALUE SET = the set of ALL acceptable LOINC codes (for example) then are you saying that extensable will still allow text only and NO codable concept?
Grahame Grieve (Dec 21 2016 at 23:28):
no, not required.
Grahame Grieve (Dec 21 2016 at 23:28):
extensible = use one of these codes, or if you can't, text, or another code
Grahame Grieve (Dec 21 2016 at 23:28):
max binding provided as well as extensible = if you use codes outside the extensible value set, it must be one of these codes
Grahame Grieve (Dec 21 2016 at 23:29):
outcome = use one of these codes, or if you can't, text
Eric Haas (Dec 21 2016 at 23:31):
I think a simpler and more consistent accross the board approach is using a data abent extension on code + invariant. Would work for both code and codeable. We discussed this and wanted to try something else. I'm creating an example now so you all can shoot it down. :-)
Grahame Grieve (Dec 21 2016 at 23:31):
ok, we'll enjoy doing that
Eric Haas (Dec 22 2016 at 00:07):
here is an example using careteam provider.role in us-core where the binding is required the invarient requires a code or DAR extension + provider.role.text. Will that work? We have already discussed and documented using the DAR for code....
Eric Haas (Dec 22 2016 at 00:07):
Screen-Shot-2016-12-21-at-4.00.27-PM.png
Eric Haas (Dec 22 2016 at 00:08):
checking to see if the validation works right now...
Grahame Grieve (Dec 22 2016 at 00:23):
that seems very clunky for the requirement - forcing an extension. why not just use max-value set?
Eric Haas (Dec 22 2016 at 00:43):
I agree that max value set is a better approach. Still stuck on the idea that a translation coding will make this look just like a regular extensible binding in the end. Since the code system is SCT or CPT for some required bindings, there will not be a way to differentiate standard codes from a translaction code without a terminology server -although that is kind of true anyway.
Eric Haas (Dec 22 2016 at 00:44):
can I do it with spreadsheets or do I need to go into the SD directly?
Grahame Grieve (Dec 22 2016 at 00:45):
I don't think it will; translations may be present, but something in there must come from the max value set
Grahame Grieve (Dec 22 2016 at 00:46):
make me a task for getting it to work in a spreadsheet.
Grahame Grieve (Dec 22 2016 at 00:46):
and for your other issues - else I'll miss them. Nearly finished what I'm doing....
Eric Haas (Dec 22 2016 at 00:47):
gforge tasks?
Grahame Grieve (Dec 22 2016 at 00:47):
yes
Eric Haas (Dec 22 2016 at 00:47):
got it
Grahame Grieve (Dec 22 2016 at 00:54):
though maybe I should take up the notion of an extension on ElementDefinition.binding that modulates extensible with vocab:
- allow either other code or text
- allow only other code
- allow only text
Grahame Grieve (Dec 22 2016 at 00:54):
we've mentioned the 2nd before, but not executed on it
Grahame Grieve (Dec 22 2016 at 00:54):
@Robert McClure what does the binding spec have as options here?
Robert McClure (Dec 22 2016 at 20:10):
We need to revisit the allowance for use of TEXT instead of a concept ID, but we do allow for it based on or original review of this.
In the second section of the Binding Semantics work (http://wiki.hl7.org/index.php?title=Binding_Syntax#SHALL_specify_one_of_the_following_Binding_Strengths_to_describe_Expected_behaviors_for_Sending.2Foriginating_data_Receiving.2Fconsuming_data) we say that when a "Binding Strength" of CEA (Coding with Exceptions Allowed) is specified, this means that:
The Sending perspective:
1) SHALL send from expansion if idea is in the expansion
2) MAY send something not in expansion if idea is not in the expansion
1) SHALL Flag the instance in some way to clearly identify that the concept sent is not in the expansion set
1) Send a code and an identification of code system (can be local)
2) Send text and no code
So this would mean we’d align with your #1 I think
Robert McClure (Dec 23 2016 at 17:36):
btw, if it turns out FHIR wants to closely tune extensable/CEA to say specifically code or text, code only, text only, I'd see that as three flavors of what we call CEA. We can add that to the binding semantics material if the decision is to be that specific.
Grahame Grieve (Dec 23 2016 at 19:12):
I think it would make sense to add to the binding semantics if it turns out that there is a implementer to do that
Last updated: Apr 12 2022 at 19:14 UTC
