Stream: implementers
Topic: Extensions and Cardinality/Flag Changes
Saul Kravitz (Aug 13 2019 at 17:59):
Given an extension E that is incorporated into a profile P.
Assume E has a field F that has:
cardinality
flags (e.g., no Must support)
Can the profile P constrain a published extension with a different (compatible) cardinality and a MS?
Or, is an extension, an extension, and is incorporated as-is.
For a concrete example, imagine an IG that is supposed to incorporate this extension: http://hl7.org/fhir/uv/vhdir/2018Sep/StructureDefinition-contactpoint-availabletime.html
Here is the extension:
image-2.png
Is it compatible with this specification when embedded in a profile (this is for davinci-plan-net):
image-3.png
Thanks,
Saul
Eric Haas (Aug 13 2019 at 18:25):
you have two choices:
1. constrain a defined extension by profiling it.
2. Make your own custom extension
I never done the first and don't know if the tooling supports this
Lloyd McKenzie (Aug 20 2019 at 16:55):
It's definitely possible to profile an existing extension defining additional constraints (including mustSupport). The fixed URL for the extension remains the same (because the semantics are the same), but you'd reference the canonical URL of the "profiled" extension in your profile to ensure that your constraints/expectations are enforced. This works in the Java validator for sure (because I helped make the fixes when it initially didn't :>)
Saul Kravitz (Dec 26 2019 at 22:31):
Hi Lloyd McKenzie -- since the extensions are incorporated by reference, I'm not sure what this would look like. Can you point me to an example where somebody has done this? The current use cases (from Plan-Net) include:
- taking an extension with a reference to a VhDir type https://build.fhir.org/ig/HL7/VhDir//StructureDefinition-location-reference.html, and making it refer to a Plan-Net type https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/StructureDefinition-plannet-Location-reference-extension.html (Plan-Net is a first cousin to VhDir, not a descendant)
- taking an extension with an 'example' binding to a VS and making the binding 'extensible' https://build.fhir.org/ig/HL7/VhDir//StructureDefinition-endpoint-usecase.html
Lloyd McKenzie (Dec 26 2019 at 22:41):
I don't know off the top of my head where this has been done that I can point you too. You can profile an extension definition in the same way as you can profile a resource. The derived profile won't changed the fixed URL declared in the original extension definition, but can tighten up whatever else you need to. You point to the derived extension profile rather than the original.
Halina Labikova (Jan 29 2020 at 16:51):
@Saul Kravitz - have you solved this since then? I'm dealing with a similar issue - I need to create a derived profile, where the valueSet used by its standard extension is constrained to a subset. A resource conforming to this derived profile needs to also conform to the parent profile. Since, as you said, the extension is incorporated by reference, deriving the extension itself won't work in this case. How have you approached this at the end?
Saul Kravitz (Jan 29 2020 at 17:05):
In theory, you could profile the extension. The structure definition used for extensions and profiles is basically the same.
With the tooling I used for my IG (CIMPL), this wasn't supported. With FSH/Sushi it is easily done, but there is currently no direct path to a publishable IG.
What I did was just "clone" the extension within the IG I was developing, and impose constraints there. IN my case, I needed to change a reference type. YOu can see the original here: https://build.fhir.org/ig/HL7/VhDir//StructureDefinition-newpatients.html and the 'clone' here https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/StructureDefinition-plannet-NewPatients-extension.html
From the perspective of the consumer of the data, they will have to deal with a different extension (uri is different) either way, so I don't think my solution is that bad.
Halina Labikova (Jan 29 2020 at 17:57):
@Saul Kravitz
With FSH/Sushi it is easily done, but there is currently no direct path to a publishable IG.
From my understanding, fsh output is missing only the build file and the ig file for it to be ready to be consumed by the publisher scripts - both are easily generated manually, so tooling is not really an issue.
From the perspective of the consumer of the data, they will have to deal with a different extension (uri is different) either way, so I don't think my solution is that bad.
I guess this is my issue - I was hoping to find a way to impose constraints on an extension when used in a context of a specific profile, but without changing the referenced url (for conformance purposes).
To give a specific example: I'm currently investigating whether using mCODE's PrimaryCancerCondition would cover all of our usecases. Let's say I need a derived profile to capture Mucosal Melanoma: I need to restrict the acceptable values in the onco-core-HistologyMorphologyBehavior-extension. If I do that by profiling the extension itself, the resource instance that will be conformant to my MM profile will no longer be conformant to the PrimaryCancerCondition profile.
Jose Costa Teixeira (Jan 29 2020 at 19:00):
From my understanding, fsh output is missing only the build file and the ig file for it to be ready to be consumed by the publisher scripts - both are easily generated manually, so tooling is not really an issue.
for very simple and orthodox IGs, without pages, perhaps. but we're not there yet
Saul Kravitz (Jan 29 2020 at 19:04):
@Halina Labikova I think your conformance concern is accurate. I did not face that since my IG (Plan-Net) is not derived from the IG I was borrowing extensions from (VhDir). I might try to generate a profile of the mCode extension using Sushi, and then figure out how to slip it into your IG.
Last updated: Apr 12 2022 at 19:14 UTC
