Validate extensions against the version referenced in a profile instead of the latest version #3661
Assignees
Labels
enhancement
New feature or request
Comments
lmsurpre
added a commit
that referenced
this issue
May 23, 2022
1. Added a FHIRTermService.lookup overload which allows the caller to pass the specific version of the CodeSystem to use. Previously, I found that we were passing a CodeSystem to validateCode but this method delegated to lookup which fetched its own CodeSystem. This was problematic when the Coding didn't specify a particular CodeSystem version when the underlying profile constraint did. 2. Moved logic for generating `conformsTo` constraints (generated-ext-1) for each extension in the resource instance. Now it will be grouped with the rest of the constraints and we can introspect those other constraints to shape the constraint generation. - To implement this, I introduced a new "PathAwareCollectingVisitor" although alternatively I could have executed a FHIRPath like `descendents(extension)` - Instead of a constraint like `conformTo(url)` which will only validate against the latest version of this extension in the registry, we now generate an expression like `conformTo(url|1) or conformTo(url|2) or conformTo(url|3)` ...one clause for each version in the registry. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 23, 2022
1. Added a FHIRTermService.lookup overload which allows the caller to pass the specific version of the CodeSystem to use. Previously, I found that we were passing a CodeSystem to validateCode but this method delegated to lookup which fetched its own CodeSystem. This was problematic when the Coding didn't specify a particular CodeSystem version when the underlying profile constraint did. 2. Moved logic for generating `conformsTo` constraints (generated-ext-1) for each extension in the resource instance. Now it will be grouped with the rest of the constraints and we can introspect those other constraints to shape the constraint generation. - To implement this, I introduced a new "PathAwareCollectingVisitor" although alternatively I could have executed a FHIRPath like `descendents(extension)` - Instead of a constraint like `conformTo(url)` which will only validate against the latest version of this extension in the registry, we now generate an expression like `conformTo(url|1) or conformTo(url|2) or conformTo(url|3)` ...one clause for each version in the registry. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 23, 2022
1. Added a FHIRTermService.lookup overload which allows the caller to pass the specific version of the CodeSystem to use. Previously, I found that we were passing a CodeSystem to validateCode but this method delegated to lookup which fetched its own CodeSystem. This was problematic when the Coding didn't specify a particular CodeSystem version when the underlying profile constraint did. 2. Moved logic for generating `conformsTo` constraints (generated-ext-1) for each extension in the resource instance. Now it will be grouped with the rest of the constraints and we can introspect those other constraints to shape the constraint generation. - To implement this, I introduced a new "PathAwareCollectingVisitor" although alternatively I could have executed a FHIRPath like `descendents(extension)` - Instead of a constraint like `conformTo(url)` which will only validate against the latest version of this extension in the registry, we now generate an expression like `conformTo(url|1) or conformTo(url|2) or conformTo(url|3)` ...one clause for each version in the registry. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 23, 2022
1. Added a FHIRTermService.lookup overload which allows the caller to pass the specific version of the CodeSystem to use. Previously, I found that we were passing a CodeSystem to validateCode but this method delegated to lookup which fetched its own CodeSystem. This was problematic when the Coding didn't specify a particular CodeSystem version when the underlying profile constraint did. 2. Moved logic for generating `conformsTo` constraints (generated-ext-1) for each extension in the resource instance. Now it will be grouped with the rest of the constraints and we can introspect those other constraints to shape the constraint generation. - To implement this, I introduced a new "PathAwareCollectingVisitor" although alternatively I could have executed a FHIRPath like `descendents(extension)` - Instead of a constraint like `conformTo(url)` which will only validate against the latest version of this extension in the registry, we now generate an expression like `conformTo(url|1) or conformTo(url|2) or conformTo(url|3)` ...one clause for each version in the registry. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 24, 2022
1. Added a FHIRTermService.lookup overload which allows the caller to pass the specific version of the CodeSystem to use. Previously, I found that we were passing a CodeSystem to validateCode but this method delegated to lookup which fetched its own CodeSystem. This was problematic when the Coding didn't specify a particular CodeSystem version when the underlying profile constraint did. 2. Moved logic for generating `conformsTo` constraints (generated-ext-1) for each extension in the resource instance. Now it will be grouped with the rest of the constraints and we can introspect those other constraints to shape the constraint generation. - To implement this, I introduced a new "PathAwareCollectingVisitor" although alternatively I could have executed a FHIRPath like `descendents(extension)` - Instead of a constraint like `conformTo(url)` which will only validate against the latest version of this extension in the registry, we now generate an expression like `conformTo(url|1) or conformTo(url|2) or conformTo(url|3)` ...one clause for each version in the registry. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 24, 2022
1. Added a FHIRTermService.lookup overload which allows the caller to pass the specific version of the CodeSystem to use. Previously, I found that we were passing a CodeSystem to validateCode but this method delegated to lookup which fetched its own CodeSystem. This was problematic when the Coding didn't specify a particular CodeSystem version when the underlying profile constraint did. 2. Moved logic for generating `conformsTo` constraints (generated-ext-1) for each extension in the resource instance. Now it will be grouped with the rest of the constraints and we can introspect those other constraints to shape the constraint generation. - To implement this, I introduced a new "PathAwareCollectingVisitor" although alternatively I could have executed a FHIRPath like `descendents(extension)` - Instead of a constraint like `conformTo(url)` which will only validate against the latest version of this extension in the registry, we now generate an expression like `conformTo(url|1) or conformTo(url|2) or conformTo(url|3)` ...one clause for each version in the registry. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 24, 2022
1. Added a FHIRTermService.lookup overload which allows the caller to pass the specific version of the CodeSystem to use. Previously, I found that we were passing a CodeSystem to validateCode but this method delegated to lookup which fetched its own CodeSystem. This was problematic when the Coding didn't specify a particular CodeSystem version when the underlying profile constraint did. 2. Moved logic for generating `conformsTo` constraints (generated-ext-1) for each extension in the resource instance. Now it will be grouped with the rest of the constraints and we can introspect those other constraints to shape the constraint generation. - To implement this, I introduced a new "PathAwareCollectingVisitor" although alternatively I could have executed a FHIRPath like `descendents(extension)` - Instead of a constraint like `conformTo(url)` which will only validate against the latest version of this extension in the registry, we now generate an expression like `conformTo(url|1) or conformTo(url|2) or conformTo(url|3)` ...one clause for each version in the registry. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 24, 2022
1. Added a FHIRTermService.lookup overload which allows the caller to pass the specific version of the CodeSystem to use. Previously, I found that we were passing a CodeSystem to validateCode but this method delegated to lookup which fetched its own CodeSystem. This was problematic when the Coding didn't specify a particular CodeSystem version when the underlying profile constraint did. 2. Moved logic for generating `conformsTo` constraints (generated-ext-1) for each extension in the resource instance. Now it will be grouped with the rest of the constraints and we can introspect those other constraints to shape the constraint generation. - To implement this, I introduced a new "PathAwareCollectingVisitor" although alternatively I could have executed a FHIRPath like `descendents(extension)` - Instead of a constraint like `conformTo(url)` which will only validate against the latest version of this extension in the registry, we now generate an expression like `conformTo(url|1) or conformTo(url|2) or conformTo(url|3)` ...one clause for each version in the registry. Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 25, 2022
1. ConstraintGenerator.generateExtensionConstraint will now include a `conformsTo` clause on all extension constraints 2. ConstraintGenerator.generate will assign such extension constraints a special constraint id that uses the form: `prefix~path<url>` 3. FHIRValidator will look for these special constraints and avoid generating instance-specific extension constraints if they overlap with an existing profile constraint Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 25, 2022
1. ConstraintGenerator.generateExtensionConstraint will now include a `conformsTo` clause on all extension constraints 2. ConstraintGenerator.generate will assign such extension constraints a special constraint id that uses the form: `prefix~path<url>` 3. FHIRValidator will look for these special constraints and avoid generating instance-specific extension constraints if they overlap with an existing profile constraint Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
May 25, 2022
Removed comments, split some logic into private helpers (for readability), and fixed logic error in ConstraintGenerator.generateExtensionConstraint Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
|
We stepped through validation of the CounselorRole1 example from PlanNet 1.0.0. Our ConstraintGenerator generates constraints for PlanNetPractitionerRole include these three:
Because the network-reference constraint already exists from the ConstraintGenerator, the code properly avoids adding a new constraint for the latest version of this extension. |
|
Also confirmed that when we add a new extension to this instance (one not defined in the profile), it does generate a constraint based on the "latest" definition of this extension from the registry: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
The text was updated successfully, but these errors were encountered: