FHIR Chat · Extension for additional bindings

Stream: terminology

Topic: Extension for additional bindings

Grahame Grieve (Feb 03 2022 at 21:04):

I would like to define an extension on ElementDefinition.binding that specifies additional bindings.

ElementDefinition.binding is the conformance binding: what the validator enforces - and there can only be one. But in addition, designers will be able to specify additional bindings.

Extension
purpose: code - defines how the binding is used
usage : UsageContext - defines the contexts in which this binding is used for it's purpose
valueSet : canonical(ValueSet)
documentation : markdown

draft set of the codes for purpose property:

conformance - this value set replaces the overall conformance value set in a particular usage context
required: this value set is required by (this specification | external regulation) for new records. It's a subset of what is allowed because the full conformance binding allows for legacy records
recommended: this value set is the list of codes that are recommended for the user to choose from
- UI: this value set is provided to user look up in a given context* starter: this value set is a good set of codes to start with when designing your system
component: this value set is a component of the base value set (this allows different documentation for different parts of the overall value set, e.g. by code system)
minimum: systems SHALL support at least this value set (per the definition of must-support)
maximum: this replaces the existing maxvalue set extension (though the tooling would continue to accept either)

The IG publisher will publish these additional bindings, but they'll be ignored by the validator. (for now, though I'd look at enforcing extra conformance value sets if the validator can process the usageContext)

This would impact on revisions of the current specifications in two ways:

in a few places we use extensible+max we mostly really want a base value set with a recommended value set
in a few places we use extensible, and we really want a fairly large base value set with a required - this is what legislation wants for new records

Lloyd McKenzie (Feb 03 2022 at 21:11):

I don't understand what some of these mean.

conformance: you can tighten, but you can't replace the base binding if the base binding is 'required' or 'extensible'. And it would seem this could happen just by tightening the base value set, no need for an extension?
required - I'd prefer a name of "new data". 'required' is a misleading name
recommended - does this mean we'd ditch the UCUM binding and turn the max binding into the base binding and use this new extension for the UCUM binding?
component - explain the use-case?

I'm also not thrilled with the notion of usage context. Generally, if rules are different for different contexts, then you have different profiles. If we want to embed context-specific rules inline within a profile, value set isn't the only thing we'd need. And we'd need to have a way to render the variations.

Grahame Grieve (Feb 03 2022 at 21:24):

conformance - it would have an invariant that if the purpose = conformance, then you must have a usage context, because it's about being more specific in a specific context
required - I don't care about the name
recommended - which UCUM binding, but we'd certainly talk about doing that, yes
component - this is trying to capture one of the underlying reasons for the oft-repeated question, "I want multiple bindings": I have different value sets and having a combining value set loses information and documentation associated with the multiple value sets

As for usage context, it's no service to users to have myriad profiles that differ only by usage context and some bindings. Obviously there are scenarios where that's exactly what you should do, but also, there are scenarios where that's exactly what should not do. Agree that we need to render this properly. As for usage context... maybe we want to put a usage context extension on invariants and mappings too, but we don't need to talk about that here

Lloyd McKenzie (Feb 04 2022 at 00:04):

conformance - ok. Your original description didn't say "more specific" - which I'm interpreting as "valid constraint"
component - so this would an alternative to slicing coding?
usage context - I don't see why value sets would matter, but cardinality, mustSupport, minValue/maxValue, etc. wouldn't. My leaning would be for us to have a complex extension that allows you to list all of the 'constraint'/documentation elements. I don't see value in a binding-specific or element-by-element solution.

Rob Hausam (Feb 04 2022 at 03:29):

I agree that it looks like this can be a replacement for slicing on CodeableConcept.coding (or on CodeableConcept directly, as in IPS). Presumably you can specify multiple conformance bindings. And I assume that in the case of a preferred base binding, being a "valid constraint" still means that the specified conformance bindings could be, but would not need to be, a subset of or even have any overlap at all with the base binding. Assuming that's all true, then when can we start using this in IPS?

Rob Hausam (Feb 04 2022 at 03:50):

Will the additional binding also have a binding strength - or will that behavior be fixed based on the value of 'purpose'? It seems like 'purpose' should be sufficient - and having a binding strength in addition would make it too complex and far more confusing. But it would be good to be clear about what you have in mind. @Grahame Grieve?

Lloyd McKenzie (Feb 04 2022 at 03:50):

We'd have to enforce that the slicing replacement was only allowed on CodeableConcept, not on Coding or code. (Even if the Coding was x..*, the bindings would all apply to each repetition.)

Rob Hausam (Feb 04 2022 at 04:04):

Yes, I think that's correct. It doesn't seem that having this as an option for use on CodeableConcept.coding would be useful or sensible. But it could and likely would be used to replace many current instances where slicing on CodeableConcept.coding has been used, by instead using this extension on the CodeableConcept element itself.

Grahame Grieve (Feb 04 2022 at 05:28):

I'm not sure about slicing. what are you trying to achieve, and then I'll describe how it might make a difference. if you're wanting to say, 'one code from this value set, and one code from that value set', then this isn't it

Grahame Grieve (Feb 04 2022 at 05:28):

there's no binding strength, because binding strength is a property of the conformance binding. But maybe there'd need to be a binding strength on the context specific bindings?

Grahame Grieve (Feb 04 2022 at 05:29):

You can start using this in IPS now, but it won't render. So it would be experimental and I won't start coding it until we have some degree of consensus - not sure how much

Grahame Grieve (Feb 04 2022 at 05:32):

component - so this would an alternative to slicing coding?

that depends what was trying to be done by slicing. Some of what's trying to be done by slicing is convey the alteranative purposes, but sometimes, it's additional conformance rules.

usage context - I don't see why value sets would matter, but cardinality, mustSupport, minValue/maxValue, etc. wouldn't. My leaning would be for us to have a complex extension that allows you to list all of the 'constraint'/documentation elements. I don't see value in a binding-specific or element-by-element solution.

well, that would be a whole lot more difficult to present, and is less common. at least, it would be less common to want to have a single profile that did this rather than being right to have multiple profiles

Lloyd McKenzie (Feb 04 2022 at 06:04):

If this isn't "one code from X, one code from Y", can you explain what it is?

Rob Hausam (Feb 04 2022 at 06:31):

Thanks, @Grahame Grieve Of course we need it to render. And of course that takes time and effort (hopefully not too much!). But it's probably worth beginning the experiment with it now. And I'm not sure if there is a need for binding strength on the context specific bindings - probably that's part of the experiment.