FHIR Chat · Use 5.0 Extension · shorthand

Stream: shorthand

Topic: Use 5.0 Extension

Barbro Vessman (Feb 18 2021 at 13:46):

Hello,

In a profile of the Observation resource I need to use the ValueAttachment extension: http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.valueAttachment

However I struggle with getting this to work. I have tried some different things

Alias: VALUE_ATTACHMENT_EXTENSION = http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.valueAttachment

* component.value.extension[VALUE_ATTACHMENT_EXTENSION].contentType = "RTF"'
* component.extension[VALUE_ATTACHMENT_EXTENSION].contentType = "RTF" ´´´

Both above give this error: No element found at path component...[VALUE_ATTACHMENT_EXTENSION].contentType for..

* extension contains http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.valueAttachment named ValueAttachment

Gives this error: Cannot create ValueAttachment extension; unable to locate extension definition for…

Adding the url above as a dependency in sushi-config.yaml gives this error:

Failed to add 0:h to ImplementationGuide instance because SUSHI could not find the IG URL in the dependency IG. To specify the IG URL in your sushi-config.yaml, use the dependency details format:

What am I doing wrong or missing?

ryan moehrke (Feb 18 2021 at 17:30):

where are you getting that url from? it doesn't look right to me but I'm not sure what you are trying to reference so it might be right..

Chris Moesel (Feb 18 2021 at 18:12):

I think there are actual issues w/ those paths too. For example, this path:

* component.value.extension[VALUE_ATTACHMENT_EXTENSION].contentType = "RTF"'

• There is a stray ' at the end of the rule. But that might just be a typo when entering it here (also the stray ``` at the end of the second rule).
• component.value needs to be component.value[x] (only valid in a profile definition) or a specific type like component.valueQuantity (valid in profiles or instances). But just component.value does not work (unlike in FHIRPath).
• extension[VALUE_ATTACHMENT_EXTENSION].contentType is not valid because extension[VALUE_ATTACHMENT_EXTENSION] refers to an Extension, and contentType is not an element on Extension. I think you really want extension[VALUE_ATTACHMENT_EXTENSION].valueAttachment.contentType.

I noticed your VALUE_ATTACHMENT_EXTENSION URL actually ends with .valueAttachment -- is that really a part of the ID, or were you trying to reference the valueAttachment element in the extension?

Last, as @ryan moehrke noted, it would definitely help to know where that extension is defined (in what IG). You would need to add a reference to the dependency IG itself to the sushi-config.yaml dependencies. If you've supplied the right IG id and version and still get the error about not finding the IG URL, you may need to use the longer form dependency format so you can provide the uri (docs).

Lloyd McKenzie (Feb 18 2021 at 20:32):

That extension isn't formally defined in an IG. It's using the 'implied' extension inter-version format described here: https://build.fhir.org/versions.html#extensions

Lloyd McKenzie (Feb 18 2021 at 20:32):

Essentially you can reference anything in a future (or past) FHIR version as an extension.

ryan moehrke (Feb 18 2021 at 20:55):

would Observation.valueAttachment be the correct path in that paradigm then? if it's a value[x] of type Attachment?
I'm assuming since the spec says it should be elementDefinition.id it should be Observation.component.value[x] <element id="Observation.component.value[x]">
also what is the context that the extension should be in the instance? I assume as far in the path as possible, but in this case where value[x] exists just doesn't allow the needed datatypes would you ignore the existing value[x]?
so then should it read:

Alias: VALUE_ATTACHMENT_EXTENSION = http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.component.value[x]

* component.extension[VALUE_ATTACHMENT_EXTENSION].valueAttachment.contentType = "RTF"

And the obvious other follow-up, does Sushi support this extension at all? was the complaining just about the path not using extension.value[x] and/or is there an override for extensions you don't expect/can't tell sushi about?

Gino Canessa (Feb 18 2021 at 21:01):

I thought you couldn't link (in an IG) to future things since they haven't been published (though would be happy to be corrected).

Specifically, I thought it wasn't acceptable to try and link 'SomeNewResourceInR5', since neither the contents nor the link itself are stable until it has been published.

Lloyd McKenzie (Feb 18 2021 at 21:05):

Pointing to R5 things is risky - because if R5 changes, you'll break. So it's a buyer beware thing. (Some stuff is pretty safe to point at though.)

Lloyd McKenzie (Feb 18 2021 at 21:06):

My understanding was that "valueAttachment" wasn't allowed in FHIRPath - that it was always "value". But I'm not an expert.

Chris Moesel (Feb 18 2021 at 21:59):

SUSHI currently expects to be able to resolve all extension references to an actual StructureDefinition included in an IG package or FHIR core package. So... it does not (yet) support "implied" extensions. We'll have to put this on our list -- but until we support it, I wouldn't expect extensions like this to work in SUSHI.

ryan moehrke (Feb 19 2021 at 00:12):

Lloyd, the wording of the spec you linked to doesn't say fhirpath it explicitly says ElementDefinition.id and looking further here https://www.hl7.org/fhir/elementdefinition.html#id
it seems your extension url would have to be "http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.component.value[x]:valueAttachment"
which wow is quite verbose

Lloyd McKenzie (Feb 19 2021 at 00:15):

The extension URL would indeed include be the id, but I don't think it allows you to drill down into type slices. The extension would just be to Observation.component.value. You'd then have a valueAttachment in the extension. I believe a URL that said "extension-Observation.component.value[x]:valueAttachment" wouldn't be a legal URL.

Lloyd McKenzie (Feb 19 2021 at 00:16):

@Grahame Grieve?

ryan moehrke (Feb 19 2021 at 00:21):

"For type choice elements, the id reflects the type slice. e.g. For path = Patient.deceasedBoolean, the id is Patient.deceased[x]:deceasedBoolean"
is what the spec on ElementDefinition.id says, which is where I got that from. If that means this extension is implicitly illegal that's another thing I can't speak on

Lloyd McKenzie (Feb 19 2021 at 01:02):

I agree, that's the id. But I don't think we can do that in the auto-extension mechanism.

Barbro Vessman (Feb 19 2021 at 07:27):

Thanks a lot for all answers. I really appreciate them all! Yes there were some typos in the example, sorry. MD issues.

I found the url of the extension via Cerners documentation (https://fhir.cerner.com/millennium/r4/diagnostic/observation/#extensions). ValueAttachment is mentioned here: https://www.hl7.org/fhir/extensibility.html but no url.

My conclusion of your answers is that use of this extension is not recommended. And it is not supported when using sushi for creating documentation, since the extension does not exist in an IG.

The extension is already used to be able to include large content in the Observation resource. Maybe there are other ways? This is how the extension looks in the instance, if that might help:

          ],
                "component": [
                    {
                        "extension": [
                            {
                                "url": "http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.valueAttachment",
                                "valueAttachment": {
                                    "contentType": "RTF",
                                    "data": "e1xydGYxXGFkZWZsYW........"

Thanks again

Chris Moesel (Feb 19 2021 at 13:50):

@Lloyd McKenzie - Although http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.component.value[x]:valueAttachment is likely invalid, might http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.component.valueAttachment be valid? This is the style that Cerner uses in their example, which technically is a valid id in a differential since choice type renaming is allowed there.

@Barbro Vessman - I don't see any existing extensions in R4 core that would allow you to put an attachment on an Observation. If you need something that will work today with SUSHI, I think you have three choices:

1) You can likely still get SUSHI to output something like this; you just have to do it in a more manual way. The exact approach depends on if you're looking to use the extension in an instance or to specify the extension in a profile. It also depends on the conversation above regarding whether or not the extension can directly target the valueAttachment. For now, we'll assume it can as long as it follows the Cerner approach.

1a) To use the extension in an instance, you could do something like this:

// Fake system because I'm too lazy to find a clinically correct example
Alias: FOO = http://foo.org/codes

Instance: MyObservation
InstanceOf: Observation
* code = FOO#bar
* status = #final
* component.code = FOO#baz
* component.extension.url = "http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.component.valueAttachment"
* component.extension.valueAttachment.contentType = #RTF
* component.extension.valueAttachment.data = "Tm90IHJlYWxseSBSVEY="

FSH Online Permalink

1b) To explicitly specify that it can be used in a profile, you can use ^ rules to do so. This produces the right FHIR w/ a few caveats: (a) SUSHI will complain because it thinks you're trying to define an "inline" extension in a profile, (b) if you try to constrain anything within the extension, it won't have the extension definition available, so it will be using the base Extension definition to create the differential elements. So... this is probably not advised, but for educational purposes:

Profile: MyObservationProfile
Parent: Observation
* component.extension contains valueAttachment 0..1
* component.extension[valueAttachment] ^type.profile = "http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.component.valueAttachment"

FSH Online Permalink

Both of the above approaches work because you're explicitly not using the standard FSH approach w/ extensions. By spelling them out property by property, you're basically using a backdoor past some of the validation and telling SUSHI, "Don't worry, I got this!"

2) You can trick SUSHI by basically creating an imposter of that extension yourself in SUSHI -- even going so far as to give it that exact URL. Then SUSHI will know what it is and can use it. For example:

// Fake system because I'm too lazy to find a clinically correct example
Alias: FOO = http://foo.org/codes

// Trick SUSHI by creating an imposter extension
Extension: ObsComponentAttachment
Id: extension-Observation.component.valueAttachment
* ^url = "http://hl7.org/fhir/5.0/StructureDefinition/extension-Observation.component.valueAttachment"
* value[x] only Attachment

// Instance using extension
Instance: MyObservation
InstanceOf: Observation
* code = FOO#bar
* status = #final
* component.code = FOO#baz
* component.extension[ObsComponentAttachment].valueAttachment.contentType = #RTF
* component.extension[ObsComponentAttachment].valueAttachment.data = "Tm90IHJlYWxseSBSVEY="

// Profile using extension
Profile: MyObservationProfile
Parent: Observation
* component.extension contains ObsComponentAttachment named valueAttachment 0..1

FSH Online Permalink

The issue w/ this one is that if you try to run the SUSHI imposter definition through the IG Publisher, I'm not sure what will happen.

3) You can just create your own extension (w/ its own name, id, url, etc). The obvious downside here is that any system processing your instances would need to know what this extension is:

Extension: ObsComponentAttachment
* value[x] only Attachment

Barbro Vessman (Feb 19 2021 at 14:16):

Thank you very much @Chris Moesel for those options! At the moment my purpose with this is to specify the extension in the profile to be able to create documentation, so I think I will try option 2 and see how that works.

Lloyd McKenzie (Feb 19 2021 at 14:21):

I think we need to improve the documentation in the spec. .component.valueAttachment doesn't show up in the id anymore, so if that's the expectation, we need to make it clear. In practice, I'd expect the "valueAttachment" to show up in the extension, not the path.

Lloyd McKenzie (Feb 19 2021 at 14:22):

Can someone file a change request so we can land this?

Chris Moesel (Feb 19 2021 at 15:43):

Sure, I'll try to file something.

Chris Moesel (Feb 19 2021 at 16:10):

@Firely Bot issue show FHIR-31348

Firely Bot (Feb 19 2021 at 16:11):

FHIR-31348 Clarify allowable Extension URLs for converting between versions
Status: Submitted, Type: Change Request

Chris Moesel (Mar 15 2021 at 22:09):

The extensions for converting between versions documentation indicates that there are packages for these special versioned extensions, but it also contains this note:

Note for balloters: these packages will be created when R4 is finalized. Until then, these are broken links.

R4 was finalized quite a while ago, but the links it refers to are still broken -- and I'm having trouble finding those extension packages in the registry. Do they actually exist? If so, are they in the package registry (and under what package ids)? It would be much easier for me to support this in SUSHI if I can just rely on existing packages rather than having to materialize these virtual extensions myself.

Chris Moesel (Mar 15 2021 at 22:12):

If I do have to materialize them myself, then I have some follow-up questions. ;-)

Chris Moesel (Mar 16 2021 at 20:35):

@Lloyd McKenzie -- Do you have any insight regarding the existence (or lack thereof) of these implied extension packages?

Lloyd McKenzie (Mar 16 2021 at 20:53):

As far as I know, this is all validator magic. No packages are defined. (If they were defined, they'd theoretically have to be updated (for R5 anyhow) every time someone pushed a commit to the CI build, which doesn't seem super practical, though I suppose it's possible. @Grahame Grieve

Chris Moesel (Mar 16 2021 at 21:09):

OK. If that's the way it's intended to be then I can submit a change request to remove that verbiage from the documentation. But I'll wait for Grahame's confirmation first.

Chris Moesel (Mar 16 2021 at 21:10):

To save people the click, this is what I'm referring to:
image.png

Chris Moesel (Apr 01 2021 at 21:58):

(deleted)

Chris Moesel (Apr 01 2021 at 22:03):

(deleted)

Chris Moesel (Apr 01 2021 at 22:07):

(deleted)

Chris Moesel (Apr 01 2021 at 22:09):

(deleted)

Chris Moesel (Apr 01 2021 at 22:11):

The above deleted posts were all just me talking to myself and eventually figuring out that:

• For implied extensions, the cardinality of the target element should be reflected in the root element of the implied extension
• For implied extensions that are complex, the cardinality of the child paths should be reflected in the sub-extension elements

It makes sense when you think about it. But I had to think through it a few times before I figured out no other approach (e.g., putting the cardinalities on value[x]) could possibly work.

Chris Moesel (Apr 02 2021 at 00:04):

OK. Here is a different question. The spec says:

Where complex data types have no equivalent in an earlier version, use a complex extension...

I think that means that if I am in R4 and use an implied extension to reference an R5 element with CodeableReference type, the implied extension will be a complex extension with concept and reference sub-extensions.

But... what if I use an implied extension to reference an R5 element that is a choice of CodeableReference and something else (for example, CodeableReference or string)? I can't use a simple extension because value[x] in R4 can't hold CodeableReference (nor a complex extension representing CodeableReference). But if I represent the element w/ a complex extension, there is no obvious way to represent that choice between CodeableReference and string (without complicated invariants). Or is this just a hypothetical problem that is unlikely to actually occur?

Chris Moesel (Apr 02 2021 at 00:54):

And two more questions:

1. Should we also be replacing old types w/ new types where applicable? For example, if a DSTU2 element has a type that is Reference(MedicationOrder) should we change that to Reference(MedicationRequest) in the implied extension?

2. What do we do if a DSTU2 element is a reference to a resource that no longer exists in R4? For example, how would we represent an element whose type is Reference(ImagingObjectSelection) using an implied extension in R4? We can represent ImagingObjectSelection as a complex extension, but we can't create a Reference to an extension -- so we lose the "referential" aspect of it.

Chris Moesel (Apr 07 2021 at 14:52):

And one more question: Should implied extensions carry over extensions in the source element from the other version of FHIR? For example, the implied extensions documentation uses http://hl7.org/fhir/3.0/StructureDefinition/extension-Patient.animal.species as an example. If you look at that element in STU3, it actually contains a binding with an extension:

"binding": {
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName",
      "valueString": "AnimalSpecies"
    }
  ],
  "strength": "example",
  "description": "The species of an animal.",
  "valueSetReference": {
    "reference": "http://hl7.org/fhir/ValueSet/animal-species"
  }
}

So... should the implied extension also specify that source extension in the binding on Extension.value[x]? I'm not sure because there is a possibility that the original extension is no longer valid in the version of FHIR you're bringing it into.

Chris Moesel (Apr 07 2021 at 14:53):

@Lloyd McKenzie -- do you have any insight into any of the questions I've asked above? The specification is not very thorough in its explanation regarding how all of this should work in practice.

Lloyd McKenzie (Apr 07 2021 at 15:35):

I don't think we've thought about polymophics that include net new data types for this mechanism. You can submit a change request for us to come up with guidance here

1. I think so, though that can get messy if there aren't nice correlations. A change request to clarify would be good

2. I don't think you could meaningfully adopt that in R4 in that situation? Again, clarification by change request would be good

I don't think there's a requirement to bring across unrecognized extensions. This particular extension is not one that would need to be propagated, though I'm not clear it's wrong to propagate it.

Chris Moesel (Apr 07 2021 at 15:55):

What is more helpful? One change request to cover all things needing clarification re: implied extensions? Or specific change requests for each thing needing clarification?

Lloyd McKenzie (Apr 07 2021 at 17:59):

I think one for the set is fine. The gist is "we need more clarification here"

Chris Moesel (Apr 07 2021 at 19:29):

@Firely Bot issue show FHIR-31721

Firely Bot (Apr 07 2021 at 19:30):

FHIR-31721 Clarify details in "Extensions for converting between versions" (a.k.a. implied extensions)
Status: Submitted, Type: Change Request

Last updated: Apr 12 2022 at 19:14 UTC