FHIR Chat · Extending a Required ValueSet BInding

Stream: terminology

Topic: Extending a Required ValueSet BInding

Peter Jordan (Feb 24 2021 at 20:48):

This possibility was news to me - is it actual permitted and, if so, good practice?...

https://fhirblog.com/2017/01/10/extending-a-required-valueset-binding/

Chris Moesel (Feb 24 2021 at 21:29):

I would think that as long as the code in the extension is a more specific representation of the required code, then it's fine (and maybe even good). But if the code in the extension really represents something different than the selected required code, that would be problematic -- as systems that don't understand the extension may act on the non-extension code.

Rob Hausam (Feb 24 2021 at 21:35):

Overall, I think this makes sense and is what I would expect. Maybe I missed it, but I don't see the actual extension definition, though. And you will need that to understand that in the instance the valueCode of 'stopped' is from the "http://hl7.org/fhir/ValueSet/example-inline" value set (in the STU3 example) and ultimately from the code system "http://fhir.hl7.org.nz/CodeSystem/ms-code". I would also think that the examples would be clearer if the value set canonical url was the same in both the STU2 and STU3 examples (and also remove the extraneous trailing spaces in the urls in a couple of places). And I agree with Chris's concern - but that's mostly a mapping issue, and when you have to make a mapping (which you are doing in this case even if it's not explicit) you should always follow the rule that you make the most accurate (closest) mapping that you can. @David Hay

David Hay (Feb 24 2021 at 21:45):

In this case the intent is to represent the 'identifier' of a user in a message exchange system that is very widely used in NZ. Here's the current SD: http://build.fhir.org/ig/HL7NZ/nzbase/branches/master/StructureDefinition-edi-address.html. Note that the context is currently on the root - the question we're debating is whether it is better suited against .telecom elements (like Practitioner.telecom) as it's not unlike using email / fax / etc to communicating with the recipient (though better of course :)

The actual value we'd be 'overriding' is likely to be 'other'. (if the proposal is accepted)

David Hay (Feb 24 2021 at 21:56):

Just to be clear - the post was written over 3 years ago - it isn't what we're currently considering...

Lloyd McKenzie (Feb 24 2021 at 23:17):

I wouldn't frame this as "extending". You're still using the base value set. You're just choosing to send a translation for a 'code' element. (If the 'required' binding was on a CodeableConcept, you could just send another coding. There's certainly no issue with sending extensions or sending additional Codings, but with a 'required' binding, you MUST pick a code from the value set in order to have the element.

Rob Hausam (Feb 24 2021 at 23:36):

Agree.

Peter Jordan (Feb 24 2021 at 23:56):

Seems like quite an opaque solution and I'm not sure if it's possible to do this in the C# library where codes used in required bindings are implemented as enumerated types. @Brian Postlethwaite ?

Brian Postlethwaite (Feb 25 2021 at 00:27):

Yes you can still do it, as there's always the pair property with the fhir datatype
Address.UseElement.GetExtension(...)

David Hay (Feb 25 2021 at 00:44):

How about 'refining' a binding?

Peter Jordan (Feb 25 2021 at 00:45):

So how would the extension look if added to this telecom element?

David Hay (Feb 25 2021 at 01:04):

deleted

David Hay (Feb 25 2021 at 01:05):

(deleted)

David Hay (Feb 25 2021 at 01:20):

how about:

    <telecom>
        <system value="other">
            <extension url="http://hl7.org.nz/fhir/StructureDefinition/edi-address">
                <valueCode value="edi-number"/>
            </extension>
        </system>
        <value value="someedi"/>
    </telecom>

Peter Jordan (Feb 25 2021 at 01:31):

Validator didn't complain. :grinning:
Will see how easy it is to fish out of an instance. Rather looks, and smells, like another form of extensible binding to me.

David Hay (Feb 25 2021 at 02:44):

well, I'm far from qualified to argue the minutiae of terminology, but I would suggest that it is more like specialization - in oo terms anyway...

Grahame Grieve (Feb 25 2021 at 03:21):

it shouldn't be too surprising that an extension can look like an extensible binding

Lloyd McKenzie (Feb 25 2021 at 03:50):

Main difference is that with an extensible binding, you don't have to include a code from the base value set if none of them apply. With a required binding, if none of them apply, you can't send the element at all (let alone with an extension on it).

Robert McClure (Feb 25 2021 at 04:07):

Well this is not how "extending" a required binding was allowed when VSAC chose to use new codes for the filter operator value set, per @Grahame Grieve when I just asked earlier this week. Seems to me that any value set can be "extended" whenever a user wants to do so. Look at the example VSAC just included in the announcement for support of intensional includes: https://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.11.20.9.46. So how in any way would this align with the discussion so far? Bottom line is there is little computable control on terminology in FHIR.

Grahame Grieve (Feb 25 2021 at 04:11):

the problem with the VSAC case was that none of the underlying codes were appropriate, so I didn't suggest this approach. I certainly thought about it

Robert McClure (Feb 25 2021 at 04:20):

Actually, one fo the "extensions" was flat out incorrect and is ==is-a. The other should also not be allowed given there is a known transformation for child-of so don't make up something that exists. Instead do the accepted allowed transform and work to add the concepts as we are doing. That is what we have always said to do but FHIR makes doing the incorrect thing possible, so others will always choose that easy solution.

Lloyd McKenzie (Feb 25 2021 at 04:22):

We're not talking about revising the base value set, we're talking about a derived profile wanting to extend the set of codes available. And that's not allowed. If the binding is required, you're stuck with the defined value set and can't introduce new codes except as translations (and MUST have one of the approved codes to include the element at all).

Robert McClure (Feb 25 2021 at 04:25):

lloyd, if people keep giving alternative solutions "thumb-up" and the validator allows it, then it's never going to be a real restriction. And that leads to the situation that VSAC followed, which also passes validation.

Lloyd McKenzie (Feb 25 2021 at 04:28):

The validator won't allow a coded element with a required binding that doesn't have a code from the value set. David's solution lets you send an extra code. It doesn't allow bypassing the need to send a code from the base value set. I don't know what VSAC did, but if you didn't send one of the allowed codes, then you couldn't have sent the element at all. (Which is fine, if it's not a mandatory element.)

Peter Jordan (Mar 02 2021 at 03:55):

Brian Postlethwaite said: