Fix cannonical error

[declankieran-nhsd]

Hi, this fixes the canonical error (below) for the UK Core resource in the build. It was mentioned to me that the lack of snapshots in the UK Core profiles was thought to be causing this error, but it appears to be just a canonical mismatch. Adding snapshots wouldn't have resolved this error, unless there is another one? I just ran a build of what is currently in master.

To fix this at a package level you'd need to add uk-core-access into the canonicals of the profiles.

[Dunmail]

Thanks for looking at this.

At present the repository includes the snapshot definition of UKCore-Patient so that it can be referenced from UKCoreAccessPatientIndexPatient.

To reproduce the problem, remove input/resources/UKCore-Patient.json so that the build process uses the public repositories to pull the snapshot and then execute $ npm run compile. Sushi reports an error: Structure Definition https://fhir.hl7.org.uk/StructureDefinition/UKCore-Patient is missing a snapshot. Snapshot is required for import. File: /Users/Dunmail/Documents/Development/UK-Core-Access/input/fsh/profiles/PatientIndexPatient.fsh

I've tested the proposed fix and unfortunately the problem remains.

Ideally, this IG would reference definitions directly from the UKCore package so that we can guarantee to be using the correct version.

[Dunmail]

I've added this as issue #30 so that it can be tracked.

[KevinMayfield]

Can you use https://simplifier.net/downloads/firely-terminal to generate the snapshot?

Internally we use HAPI/HL7 libs for generating snapshots. Code that does that is in this project.

https://github.com/NHSDigital/IOPS-FHIR-Utility/blob/main/src/main/kotlin/uk/nhs/england/fhir/utility/provider/ImplementationGuideProvider.kt#L108

[declankieran-nhsd]

Firely terminal seems like a good option, but I was also thinking I could just run the publisher with --no-sushi first in the build script, which inflates the profile and then copy that to the local cache before running it again with sushi. I've tried it with --no-sushi and it runs fine.

It inflates it as xml by default and the package is in json, so could be cleaner using firely terminal, although maybe there is an option in the publisher to inflate as json.

It's bit a of hack, but until sushi fully supports sorting out it's own snapshot on the fly, it seems like a good option as it would be easily removed from the build script later, and then the profiles can remain agnostic to how the snapshots are generated with whatever tooling.

Going to have a play with it now and see if I can recreate the error Dunmail described and if I have any success I'll do another PR.

[Dunmail]

At present there is no build process specific to the UK Core Access repo. Instead, commits to master trigger a build in the standard FHIR ig publication tools.

You're correct that firely-terminal can be used to generate the snapshot - this is how the workaround copy of UKCore-Patient was generated within the repo.

[declankieran-nhsd]

Ah, sorry I see all the conversation has already been had! https://github.com/FHIR/sushi/issues/795

I was thinking along the same lines as Chris Moesel

I was initially thinking that the publisher could possibly be ran to inflate the referenced profile, although checking there the --no-sushi option in the publisher still appears to run sushi, so fails as you described when running sushi directly.

If your CI server is linux, it's very straightfoward to script the install of the dotnet sdk and firely terminal. I haven't attempted to script the install of dotnet on a windows machine, but I imagine it isn't must more painful in a batch script.

Then it would just be case of using the terminal to inflate the UKCore profiles, something like (not tested!)

cd ~/.fhir/packages/fhir.r4.ukcore.stu1#1.0.0/package/
fhir push UKCore-*
fhir snapshot
for profile in ./UKCore-*; do fhir save $profile; done

Given snapshots are generated slightly differently with differently tooling, I think this highlights the issue of having generated snapshots in the profiles, as the question is then which tooling is used to generate the snapsnots.

Since the snapshots are implicit in the profiles (via reference to a base) with just differentials, having snapshots in the profiles seems to be a case of repeating things unnecessarily, so going against DRY which is a good principle for avoiding issues where the same version of something, but either used in different contexts and/or with small differences, causes development pain in terms of maintenance or extension.