Stream: terminology
Topic: Validation of expired bindings
Alexander Henket (Oct 01 2018 at 11:36):
When you have a profile that binds to a ValueSet with a limited resource-effectivePeriod specified (standard extension).
What is the validator to do outside that period? Warn against a code that it is unable to validate because the binding expired? Skip validation silently because without binding the element is just CodeableConcept/Coding?
What if the element was used in slicing? If the binding expires, the basis for the slicing might too. E.g. an expired binding on Observation.component.code might leave your profile without discriminator
Grahame Grieve (Oct 01 2018 at 11:56):
so this is a question about $validate-code. What should the operation do when passed a date outside the range of resource-effectivePeriod?
Grahame Grieve (Oct 01 2018 at 11:58):
my take is that bindings are not time limited, the value set is. So a profile that binds to a value set that is time limited can only be used during that time period. It's a validation error if the date is outside the specified time range. And date defaults to now()
Alexander Henket (Oct 01 2018 at 12:52):
Is it possible to support the case that Rob/Carol seem to have where a certain expansion is valid for a year and needs a refresh after that time. So the binding could be to an intention but supported by an expansion X for a year, followed up by expansion Y after that?
Grahame Grieve (Oct 01 2018 at 12:53):
I don't understand the profile looking in to the future like that?
Lloyd McKenzie (Oct 01 2018 at 12:54):
It sort of ties into the use-case of "how often do applications need to check for updates?" That's not so much a "looking into the future" but more "policy for application behavior around terminology management"
Alexander Henket (Oct 01 2018 at 12:55):
I was trying to wrap my head around Rob/Carols case here. What does a profile look like when certain ValueSets get a yearly expansion update. Does it affect the profile version too? Or is the binding dynamic in some sense? I think Lloyd rephrased my question correctly.
Robert McClure (Oct 01 2018 at 14:07):
Let me explain the a case around this we currently have in the USA: Twice a year, some of the value set content that is loosely bound within the eCQM HQMF used for quality measures are updated. In the HQMF, the element identifies the value set OID and no other "binding semantic." Within that spec, there is no indication of which expansion is to be used, therefore the spec - technically - tells implementers to use the currently available expansion.
We actually do not do that. What we do, (something like this is actually pretty common I believe,) is separately publish a document, called the binding parameter specification (BPS), that documents the specific parameters used to generate the expansions to be used for each value set-HQMF “data element” pair for a specified release. This release-specific BPS is defined for use during a specific reporting time period. While there is a interesting issue related to data capture versus data analysis time shifting here, I’m not highlighting that. The point is that we specifically do not place the binding specifics, including “effective period” within the specification. Instead we manage this in a separate document. In particular it allows us to point to a static HQMF for which this binding specification pertains, and change the BPS with every “release.”
I think this is a better option then working hard to push the details into the FHIR artifact binding itself. I’m not saying we could not also do that, but I’d like to work towards a standards-based representation of this sort of change-over-time requirement documentation within a different artifact.
Grahame Grieve (Oct 01 2018 at 14:12):
ok. This seems like an R5 thing.
Last updated: Apr 12 2022 at 19:14 UTC
