Is your feature request related to a problem? Please describe.
In PDEX US Drug Formulary 1.1.0, the following extension values have changed from type string to type uri:
To further complicate matters, the code display names in many of the CodeSystems have changed as well:
These CodeSystem are referenced from http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-DrugTierDefinition-extension and some are required.
These breaking changes mean that a valid 1.0.1 instance will be invalid in version 1.1.0 and, because we check extensions separate from profile validation, such instances will fail our validation just by having the 1.1.0 versions in the registry.
Describe the solution you'd like
Two different ideas:
A. Instead of just using the version url to look up the extension definition in the registry, look for all versions of the extension definition and consider the instance valid if its conformant to at least one of those. Optionally, we could add an additional constraint to check conformance against a specific version of the extension that is required by the profile.
B. Add some smarts to the Validator so that it only adds a conformTo constraint when that particular element doesn't already have one from the profile.
In either case, we'd benefit from adding a conformsTo call in a constraint that comes back from ConstraintGenerator.generateExtensionConstraint. For option A, this would only make sense to add if the profile called for a specific version of the extension. For option B, it could be done either way (either all the time or just when a specific version is mentioned by the profile).
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Acceptance Criteria
- GIVEN [a precondition]
AND [another precondition]
WHEN [test step]
AND [test step]
THEN [verification step]
AND [verification step]
Additional context
Relates to issue #3654. As mentioned there:
As an aside, I wish that extension URLs in instance data could be versioned.
I've mentioned that on chat.fhir.org a few times, most recently at https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Extension.20with.20multiple.20versions/near/273818766
However, I've not actually submitted a tracker for it...pretty sure it would get rejected.
Is your feature request related to a problem? Please describe.
In PDEX US Drug Formulary 1.1.0, the following extension values have changed from type string to type uri:
To further complicate matters, the code display names in many of the CodeSystems have changed as well:
These CodeSystem are referenced from http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-DrugTierDefinition-extension and some are required.
These breaking changes mean that a valid 1.0.1 instance will be invalid in version 1.1.0 and, because we check extensions separate from profile validation, such instances will fail our validation just by having the 1.1.0 versions in the registry.
Describe the solution you'd like
Two different ideas:
A. Instead of just using the version url to look up the extension definition in the registry, look for all versions of the extension definition and consider the instance valid if its conformant to at least one of those. Optionally, we could add an additional constraint to check conformance against a specific version of the extension that is required by the profile.
B. Add some smarts to the Validator so that it only adds a
conformToconstraint when that particular element doesn't already have one from the profile.In either case, we'd benefit from adding a
conformsTocall in a constraint that comes back from ConstraintGenerator.generateExtensionConstraint. For option A, this would only make sense to add if the profile called for a specific version of the extension. For option B, it could be done either way (either all the time or just when a specific version is mentioned by the profile).Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Acceptance Criteria
AND [another precondition]
WHEN [test step]
AND [test step]
THEN [verification step]
AND [verification step]
Additional context
Relates to issue #3654. As mentioned there: