Stream: IG creation
Topic: Does R5 backport Extension work?
Eric Haas (Nov 10 2021 at 03:02):
I tried to add an R5 element to an R4 element using this backport extension...
# ...
element:
- id: DiagnosticReport
path: DiagnosticReport
short: US Core Diagnostic Report Profile for Report and Note exchange
definition: >-
Clinical Testing and Imaging tests performed on a patient that results in structured or unstructured (narrative) findings specific to the patient.
alias:
- Imaging Report
- Radiology Report
- Clinical Test Report
mustSupport: false
#=========== R5 extension for R5 media element ==============
- id: 'DiagnosticReport.extension:r5media'
path: DiagnosticReport.extension
sliceName: r5media
min: 0
max: '1'
type:
- code: Extension
profile:
- 'http://hl7.org/fhir/4.6.0/StructureDefinition/extension-DiagnosticReport.media'
mustSupport: true
#===============================
#etc
and not working getting this error. and ugly output
StructureDefinition.snapshot.element[8].type[0].profile[0] error Canonical URL 'http://hl7.org/fhir/4.6.0/StructureDefinition/extension-DiagnosticReport.media' does not resolve
Grahame Grieve (Nov 10 2021 at 03:37):
must be /5.0/ not /4.6.0/
Eric Haas (Nov 10 2021 at 06:06):
Using http://hl7.org/fhir/5.0/StructureDefinition/extension-DiagnosticReport.media I get this invalid extension error
Stack Dump (for debugging): (01:20.0758)
java.lang.Exception: Error generating snapshot for /Users/ehaas/Documents/FHIR/Healthedata1-Sandbox/input/resources/StructureDefinition-uscdiv2-diagnosticreport(us-core-diagnosticreport-note): Unable to generate snapshot for http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note in /Users/ehaas/Documents/FHIR/Healthedata1-Sandbox/input/resources/StructureDefinition-uscdiv2-diagnosticreport
at org.hl7.fhir.igtools.publisher.Publisher.generateSnapshots(Publisher.java:4692)
at org.hl7.fhir.igtools.publisher.Publisher.loadConformance(Publisher.java:3976)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:901)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:753)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:8766)
Caused by: org.hl7.fhir.exceptions.FHIRException: Unable to generate snapshot for http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note in /Users/ehaas/Documents/FHIR/Healthedata1-Sandbox/input/resources/StructureDefinition-uscdiv2-diagnosticreport
at org.hl7.fhir.igtools.publisher.Publisher.generateSnapshot(Publisher.java:4741)
at org.hl7.fhir.igtools.publisher.Publisher.generateSnapshots(Publisher.java:4690)
... 4 more
Caused by: org.hl7.fhir.exceptions.FHIRException: Reference to invalid extension http://hl7.org/fhir/5.0/StructureDefinition/extension-DiagnosticReport.media
at org.hl7.fhir.r5.conformance.ProfileUtilities.processPaths(ProfileUtilities.java:1161)
at org.hl7.fhir.r5.conformance.ProfileUtilities.processPaths(ProfileUtilities.java:1528)
at org.hl7.fhir.r5.conformance.ProfileUtilities.generateSnapshot(ProfileUtilities.java:653)
at org.hl7.fhir.igtools.publisher.Publisher.generateSnapshot(Publisher.java:4739)
... 5 more
Grahame Grieve (Nov 10 2021 at 06:19):
guess I'll have to debug - how can I do that?
Eric Haas (Nov 10 2021 at 15:31):
I'll create a test branch that works this time and let you know.
Josh Mandel (Nov 12 2021 at 17:53):
Is there a story for complex element backports? Like a new complex element in R5... what do the (implicit?) backport extensions) look like?
Chris Moesel (Nov 12 2021 at 18:46):
IIRC, it's basically a complex extension w/ sub-extensions defined inline w/ relative paths. We had to implement something in SUSHI that basically synthesized these extensions when someone used them. At the time, the doc lacked a lot of details, but I filed a Jira issue to fill out some of the gaps. The resolution provides some of the guidance that will be added to the spec: https://jira.hl7.org/browse/FHIR-31721
Chris Moesel (Nov 12 2021 at 18:47):
BTW -- we've not yet integrated (into SUSHI) the newer information from the resolution. So some of what SUSHI does may be out of alignment w/ this new guidance. But I think that's outside the scope of this particular conversation anyway.
Gino Canessa (Nov 15 2021 at 15:54):
General question on this - since R5 isn't published yet, what happens to extensions linked this way if the path/type/cardinality/etc. changes?
Lloyd McKenzie (Nov 15 2021 at 16:54):
@Grahame Grieve
Grahame Grieve (Nov 15 2021 at 19:12):
then they have to change
Gino Canessa (Nov 15 2021 at 20:18):
How? If someone publishes an IG with an extension today, it will have a definition. If the extension is arbitrarily broken in an update to R5, does that mean the IG needs to be updated? Does the old version stop working? Does the IG automatically refer to the new version? If the change is to type/cardinality, don't we now have two definitions on the same URL with different type info, or does the implicit definition include some versioning info I missed?
Sorry if this is a lot, I'm just trying to understand how you can safely link to unpublished content.. so far, my understanding has been that you can't. I'm trying to figure out if I'm missing something, since it appears that people are doing exactly that.
Chris Moesel (Nov 15 2021 at 20:28):
It seems to me that using extensions that reference types from a future version of FHIR should be accompanied by a big fat "use at your own risk" warning. I think it's a valid question to ask if stable versions of IGs should be allowed to reference unstable versions of FHIR. In fact, since the backport extension URLs don't specify any minor version components, it's not even necessarily linked to a specific ballot version -- which makes it pretty difficult to reproduce the build.
Grahame Grieve (Nov 15 2021 at 21:05):
right. it's not entirely use at own risk. if you are publishing a guide that uses an R5 extension in advance of the publication of R5, you can at least let the committee know and expect that they'll keep this in mind doing reconciliation but if they don't... well, validation will start failing once a different extension definition is published (I update the R5 definitions each time I publish a R5 candidate).
Gino Canessa (Nov 15 2021 at 21:13):
Right. Well, I'll say this hasn't changed my mind on the topic - I feel like it's handing users a loaded gun with an extra-heavy barrel and hoping they don't shoot themselves in the foot.
I'd recommend a warning stronger than "use at your own risk". Something more like "only use this if you are absolutely sure you know what you are doing, and even then you should probably check twice".
Grahame Grieve (Nov 15 2021 at 21:16):
my point isn't about the strength of the warning, but that it's not entirely user level risk. It's committee/editor risk as well
Gino Canessa (Nov 15 2021 at 21:40):
If you're arguing that we shouldn't have the ability to link to unpublished content, you're not going to get an argument from me =). In fact, I would happily put forward the argument that this should not be allowed.
For me, the main reason is a whole set of undefined behavior areas that I don't think we can get around. E.g., if a ballot/publication happens with links to content that isn't stable, which then changes, what's the state of a published IG? The definition used when it was balloted/published is no longer available, and the extension it points to may or may not even exist.
You will have things like R4 implementations that work one day and are incompatible with ones made the next day - against the same version of the same published document.
I don't think there's a process that avoids that, other than locking down anything that gets referenced (but that invalidates the whole FMM process).
Vassil Peytchev (Nov 15 2021 at 21:59):
Isn't that why we have the STU status for IGs? The backport extensions are only allowed in IGs, and IGs can't be normative with backport extensions that are not against a published version. If that is not a current rule, is should be :grinning_face_with_smiling_eyes:
This way the capability is useful, and still allows for the flexibility of STU.
Gino Canessa (Nov 15 2021 at 22:00):
Sure, but they still break. Making IG authors define the extension in the IG is an extra step, but ensures that none of these problems happen.
Lloyd McKenzie (Nov 15 2021 at 22:26):
STU shouldn't mean that validation will arbitrarily stop working for a published release. That's a bit more precarious than typical STU. It might not be a bad idea to highlight the risk in the IG text. We had talked about the possibility of propagating a copy of the pre-adopted extension into the IG package which would have avoided the validator breaking problem, but Grahame nixed that.
Gino Canessa (Nov 15 2021 at 22:47):
I'm not particularly fussed about validation so much as actual usage - I don't know how to resolve some of the states. For a concrete example: if a IG-A uses an element in R5 that is a 0..1, string when it ballots, then the element moves 0..*, Backbone in R5 and IG-B ballots, what happens?
First is just in IG-A: the name of the value[x] is wrong, and it is the wrong structure.
But, say these were two related IGs that just happen to have been balloted in different cycles. Now they have the same extension URL with different, incompatible, definitions.
What is the expectation on using that value in IG-A? Is it still the single value, even though the 'official' definition for that extension is an array now? The two IGs were expecting to interoperate, but because of a publication timeline they don't.. does IG-A need to re-publish (noting that it may be months before the next publication window, at the very least missing the next connectathon)?
I'm using that as an example, but at the end of the day I see linking to unpublished content as extremely fragile. Given the opportunity for problems, wouldn't it be easier to limit it to published content and give guidance on how to define a similar extension, in your IG, for unpublished content?
Grahame Grieve (Nov 16 2021 at 00:21):
well, in the future, IG QA pages will call out any reference to R5 so that we're more aware of it. but there's no simple solution to this
Gino Canessa (Nov 16 2021 at 15:09):
Or, we could say that with implementer experience this feature was deemed unsafe and have it start throwing errors moving forward.
edit: for clarification, I mean referring to unpublished content
Last updated: Apr 12 2022 at 19:14 UTC
