Stream: methodology
Topic: Multiple Bindings
Grahame Grieve (Oct 29 2019 at 22:36):
This is a continuation of https://chat.fhir.org/#narrow/stream/179202-terminology/topic/multiple.20bindings. Should we define multiple bindings?
Grahame Grieve (Oct 29 2019 at 22:36):
And also it's in reference to https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/US.20Core.3AExtensible.20and.20Required.20bindings.20for.20historical.20data
Grahame Grieve (Oct 29 2019 at 22:46):
the idea is that while we have a single binding: the set of codes from which one of the codings must come for conformance purposes, we could add the ability to have other bindings:
- min (not happy with the name)
- max (not entirely happy with the name)
- common-subset (usually for if required is intensional)
- regulated (a subset with a date, required for data created from that date)
- additional (means that the translations must include something from this subset)
- language/jurisdiction variant (use this for this context, must be a subset / sameset)
Lloyd McKenzie (Oct 30 2019 at 02:17):
I don't think that the notion of 'regulated' being tied to just a date is going to have sufficient nuance. Regulation can apply to how data is sourced, when it was sourced, how it was transmitted, where it's being shared to and various other factors.
Grahame Grieve (Oct 30 2019 at 03:17):
even the date part is tricky in practice
Eric Haas (Oct 31 2019 at 01:17):
What is the advantage of a proliferation of bindings vs a set of origin/exception codes for the existing bindings either as an extensions or a new element on coding? e.g. this code is historical this one is regulatory and this one is payor, and this one is crap which we inherited from the source.
Richard Townley-O'Neill (Oct 31 2019 at 01:56):
@Eric Haas
Where do you want the complexity? More distinct types of binding, each of which behaves the same for all instances of coding; or fewer types of binding that have behaviour that depends upon properties of the coding?
Eric Haas (Oct 31 2019 at 02:55):
that is my question. What are the advantages shifting it one way or the other?
Richard Townley-O'Neill (Oct 31 2019 at 03:22):
I prefer more types of binding each with a simple semantics. I think that it will reduce unexpected misunderstanding.
Lloyd McKenzie (Oct 31 2019 at 03:26):
The meaning of the current binding types are normative. They can't be changed and their meaning can't be altered except by modifier extensions - which wouldn't be a great option. If we have a need for additional types of conformance expectations for bindings, the cleanest and most logical way to do that is with new binding codes
Eric Haas (Oct 31 2019 at 16:06):
I am not convinced that we are solving a problem or potentially creating new ones.
Lloyd McKenzie (Oct 31 2019 at 16:29):
The problem is that specifications are wanting to declare something the current binding types don't allow you to say. That's the problem we're trying to address. It's certainly possible that some of the solutions we might consider will introduce new issues. But the only binding we have that would not result in false "non-compliance" determinations for US Core right now would be "preferred". Neither Required nor Extensible do what the implementation space seems to require. And "Preferred" is softer than is wanted for conformance expectations.
John Moehrke (Oct 31 2019 at 17:01):
what is wrong with preferred? is it what we should be using?
Lloyd McKenzie (Oct 31 2019 at 17:15):
Preferred is fine if what we want to say is "it'd be nice if you used this, but there are no conformance expectations at all that anyone will do so"
Lloyd McKenzie (Oct 31 2019 at 17:15):
My impression is that we wanted to say something stronger than that
John Moehrke (Oct 31 2019 at 17:18):
it seems we are tending more toward an understanding that we really mean preferred... Not clear to me what could possibly between
Lloyd McKenzie (Oct 31 2019 at 17:25):
If we were going to do a new "regulatory" binding, my recommendation for a definition would be:
"There are regulatory expectations around the use of this value set. Refer to documentation associated with the profile to determine in what circumstances codes must be drawn from this value set".
Validator behavior would be to throw a warning if the value set doesn't come from the specified value set. (I don't think the validator does anything for preferred bindings.)
John Moehrke (Oct 31 2019 at 19:50):
ah, the warning vs none... that is useful, right? Although I would think warnings could be thrown on preferred binding too. That is to say I am struggling with understanding why preferred is not exactly what we are looking for
John Moehrke (Oct 31 2019 at 19:50):
I would expect no warnings to be thrown if the binding was example
Lloyd McKenzie (Oct 31 2019 at 19:55):
I think warnings on preferred is a bit over the top. maybe a best-practice warning? My take on validator messages is as follows:
- errors: instance is non-conformant. No debate/nuance involved.
- warnings: you may be non-conformant. Human or other inspection more sophisticated/capable than the validator code can achieve is required to determine
- best practice: you're fully conformant, but not adhering to recommended/best practice. (These might not even show up, depending on how the validator is set)
- information messages: Information about how the validation process was executed, but no relevance to conformance or to what systems must/should do
Richard Townley-O'Neill (Nov 01 2019 at 00:02):
The igPublisher gives an information message when codes are not in the preferred binding.
Richard Townley-O'Neill (Nov 01 2019 at 00:09):
So:
Failure on
- required binding gives error
- extensible binding gives warning
- preferred binding gives not best practice
- example binding gives no message
Not best practice seems a variation on information
Lloyd McKenzie (Nov 01 2019 at 00:25):
Extensible gives one type of warning. It would be a different warning - and a different type of verification from a "regulation" binding.
Not best practice can be turned off.
Grahame Grieve (Nov 05 2019 at 03:59):
And also this one please, if we have time. I do not expect to close this out, but to lay out a process
Grahame Grieve (Nov 05 2019 at 22:50):
ok decisions after discussion:
- I'll blog about the issues around extensible as a policy practice vs temporal and process dislocations
- we'll prepare a proposal to go to vocabulary for dsicussion
- we'll work up a proposal using a google document
Eric Haas (Nov 07 2019 at 03:09):
We are running into an analogous issue with reference types. Constrained types for certification testing creates too tight a constraint for reuse. Yet allowing all types create a problem for certification. see this question. https://chat.fhir.org/#narrow/stream/179177-conformance/topic/How.20to.20express.20min.20and.20max.20types.20for.20reference
Last updated: Apr 12 2022 at 19:14 UTC
