Can we have the FHIRversion as a (optional) displayed element on the artifact page

[bvdh]

FHIRcast is turning into a multi-FHIR version IG. As such it is required to have the FHIRversion as a field in the table on top of the artifact pages. Is this possible? If so how? If not, can that be added?

A further request would be to have separate pages for each FHIR version or separate them on the page.

[lmckenzi]

Right now, we haven't figured out how to handle multi-version IGs at all, other than having the metadata in the IG resource. Getting a multi-version IG to actually work is not a small effort and is unlikely to happen in the next year.

[grahamegrieve]

Is unlikely to happen ever

[lmckenzi]

@bvdh, can you describe exactly what you're trying to do? We can then help with what the appropriate path forward is from a publishing/maintenance perspective.

[bvdh]

FHIRcast is used in R4 deployments (UScore) and R5 (IHE rad profiles). This requires profiles for each FHIR version as some of the critical fields have changed in R5.

What we did was to add a preprocessing step that runs a sushi compile for each of the FHIR versions. We added a preprocessing step to sushi that injects/removes the FHIRversion specific elements (based on search/replace) to make this easier.

The resulting resources are copied in the input/resources directory. The IG sushi-config.yaml holds all the supported FHIR versions.

This code is on the following FHIRcast branch: https://github.com/HL7/fhircast-docs/tree/FHIR41504

This results in an artifact page that holds the resources from all FHIR versions. Each resource title starts with the FHIR version which provides a minimal set of sorting.

We would like to improve on that.

The first step would be to display the FHIRversion when displaying the profiles.
An additional step would be to sort the resources per version, or to have a separate artifact page per version. E.g. by integrating the artifact page from the preprocessing step.

It would be ideal if we can skip the preprocessing step and are able to have each sushi run integrated in the build process.

[lmckenzi]

Does the Java publisher actually run when the resources are based on a mix of versions?

[grahamegrieve]

it'll just autoconvert them, if the versioning is set up correctly. Else you'll just get errors somewhere

[bvdh]

I checked the output (see also https://chat.fhir.org/#narrow/stream/179271-FHIRcast/topic/Multi-FHIR-version-IG) - the html page reflects the resources in the different FHIR versions. The package output converts them to R4. The ImplementationGuide correctly states the different FHIR versions.
Can we disable that conversion? Why would it be an issue when a npm package holds FHIR resources from multiple versions? You can refer to them using the FHIR version specific canonical so usage should not be an issue (I think).

[lmckenzi]

https://confluence.hl7.org/display/FHIRI/FHIR+IG+version+support

[lmckenzi]

Will discuss Tuesday evening in Phoenix

[lmckenzi]

Tuesday discussion suggested there may be a path forward related to inter-version extensions. @grahamegrieve is investigating