FHIR Chat · Simplifier and forge v. 4.0.1 · implementers

Stream: implementers

Topic: Simplifier and forge v. 4.0.1

Irene Zuschlag (Mar 18 2020 at 10:24):

Are there any of you that that is informed regarding when the Simplifier.org server is going to support FHIR profiles v. 4.0.1 ?

Patrick Werner (Mar 18 2020 at 11:32):

likely next week

Alexander Zautke (Mar 18 2020 at 12:03):

CC @Ward Weistra

Ward Weistra (Mar 18 2020 at 12:10):

Hi @Irene Zuschlag, @Patrick Werner is right, we're working on it (including the .NET FHIR API 1.5/6 and Vonk 3.3/4 in Simplifier.net) this sprint and expect to make it available to the public by next week.
Forge with support for (3.0.2 and) 4.0.1 has been released yesterday, as you might have already noticed, so feel free to start building and upgrading those profiles!

Overview of supported FHIR versions and known issues posted here: https://simplifier.net/docs/Forge/Knownissues

Ward Weistra (Mar 31 2020 at 13:29):

@Irene Zuschlag @Patrick Werner Hi all, just wanted to let you know Simplifier has been updated with full support for FHIR (3.0.2 and) 4.0.1 today!
Please let me know if there are any issues.

Irene Zuschlag (Mar 31 2020 at 15:27):

(deleted)

Irene Zuschlag (Apr 01 2020 at 06:59):

Hi
We do have some issues with Simplifier but properly not related to the 4.0.1 update. All our files for our project is placed in git hub, even our markdown files. When we synchronize GitHub and Simplifier, the markdown files are left unchanged on Simplifier, even if changed in git. Is this a feature or a fail ?

Ward Weistra (Apr 01 2020 at 08:26):

Hi @Irene Zuschlag, that doesn't sound like how it should be. Are the project and Github repo public, or would you be able to add me to them (ward@fire.ly on both)?

Just to be sure, markdown files or the specific folder are not excluded on your sync? http://docs.simplifier.net/simplifier/simplifierGithub.html#github-include-exclude
Any ideas what happened before they stopped being updated (if they ever were)? Did the get renamed, moved to a different folder, any force pushes on the repository?

If nothing else works you can always empty the Simplifier project (Project page > Manage > File manager) and reimport from Github (Project page > Github > Reimport). But let's troubleshoot first.

Irene Zuschlag (Apr 01 2020 at 14:54):

Hi @Ward Weistra - Cannot reproduce the problem regarding the markdown files on our test server, with the same setting . Seems like git is synchronizing as expected after all.. But doing the testing some minor problems occurred that are related to Simplifier. Firstly the log shows time, I guess, zulu time, but It would be nice if the local view could have a setting that showed the local time,- it is quite minor. Another observation is, that I miss the full timestamp of last update of a file - not just the date..

Ward Weistra (Apr 01 2020 at 16:05):

Thanks @Irene Zuschlag, I've noted them for solving!

Irene Zuschlag (Apr 07 2020 at 14:26):

Hi @Ward Weistra Just found a problem when upgrading project FHIR files to 4.0.1 in Simplifier - when validating a profile following error occurs: CodeInvalid : Code '4.0.1' from system '' does not exist in valueset 'http://hl7.org/fhir/ValueSet/FHIR-version' . I have changed the profiles back to 4.0.0 in our test environment.

Ward Weistra (Apr 07 2020 at 14:31):

Hi @Irene Zuschlag, please update the dependencies in your project from the simplifier.core.r4 to hl7.fhir.r4.core 4.0.1. This is now finally possible with support for FHIR 4.0.1 and our recent synchronization with all the HL7 FHIR packages. Does that resolve it?

Irene Zuschlag (Apr 07 2020 at 14:49):

Hi @Ward Weistra Well - I think I did not explain the problem detailed enough..It is not when validating a resource but when validating my Simplifier profile - for example image.png image.jpeg

Sorry for the duplicates..

Ward Weistra (Apr 07 2020 at 16:23):

@Irene Zuschlag Yes! When validating a resource in your project it will look in your project's dependencies for the canonical URLs you are referring to.

Your project's dependencies currently include, directly and indirectly: hl7.fhir.dk-core.r4 0.9.0-beta-1 and simplifier.core.r4 4.0.1 (and its dependencies again). The latter is our old mirrored version of the core FHIR spec, which somewhere has the old ValueSet/CodeSystem which doesn't include 4.0.1 yet.

To make sure Simplifier will find the version of the ValueSet/CodeSystem that is the most recent and includes 4.0.1 we need to point to the latest and official core FHIR spec package hl7.fhir.r4.core 4.0.1. So we'll need to update the dependencies of both the hl7.fhir.dk-core.r4 package and your project.

Please:

• Update the dependencies of https://simplifier.net/dk-core/~dependencies: Remove simplifier.core.r4 and add the latest version of hl7.fhir.r4.core.
• Create a new package from that project for hl7.fhir.dk-core.r4 which will reflect those changed dependencies.
• In your own project change the dependencies to that new version of hl7.fhir.dk-core.r4. If you have direct dependencies on simplifier.core.r4 there you can just remove them and optionally replace it with the latest version of hl7.fhir.r4.core too (since it will already be an indirect dependency).

Please let me know if that helps!

Irene Zuschlag (Apr 08 2020 at 06:56):

Hi @Ward Weistra Thanks for the reply - the package-dependency hieracy is quite like a jungle.. First off all - I 'll try to get approval from the danish hl7 affiliate for updating the Simplifier dk-core project.
I did not realize that the impact of fhir version 4.0.0 and 4.0.1 had this great impact. In all my profiles the referenced versions codes are 4.0.0 - for instance
" <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-normative-version">
<valueCode value="4.0.0" />" so why is valueCode not following the version 4.0.1 ? Is it a problem that I always refer to 4.0.0 if a version 4.0.1 actually exits for the value set ? Or shall all value sets reference the same version because of the dependencies ?

Ward Weistra (Apr 08 2020 at 07:11):

Hi @Irene Zuschlag, I'm sorry it's giving you trouble. There two compounding factors here: the switch from 4.0.0 to 4.0.1, and the switch to using the official HL7 FHIR packages.

Actually the value of extension http://hl7.org/fhir/StructureDefinition/structuredefinition-normative-version refers to "This structure definition/element/etc. has been normative since FHIR version x.x.x". So this could very well (and will in most cases right now) rightfully continue to refer to 4.0.0.

If you are referring to specific versions of ValueSets, I think generally they were indeed updated to version number 4.0.1 (see the version numbers here: https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/~files).
However, having packages, I think you can now generally refrain from referring to specific versions of value sets. Within your project or package's dependencies there will only be one version of, say, http://hl7.org/fhir/ValueSet/gender-identity. So no need to specify the version number. I think that is the upside of using packages and will make sure you don't have to continue to keep those versions in sync manually.

Patrick Werner (Apr 08 2020 at 14:53):

What if i'm leaving the package context? It would be nice if the version specific reference could be auto generated from the package information

Patrick Werner (Apr 08 2020 at 14:54):

If i send a resource A->B i can't express the package this resource came from, and therefore i'm loosing all the version context.

Ward Weistra (May 08 2020 at 14:21):

@Patrick Werner Never leave the package context! ;)
I think conformance resources should always be shared in package context. Don't share your database table definitions individually, they are one coherent group.
However, claiming conformance on a FHIR instance indeed is likely to happen outside of package context. I guess it would be good if they would actually claim conformance to a canonical + scope (package context) :thinking: We are redesigning our infrastructure everywhere to follow that logic (like the Simplifier.net resolve, validation, snippet page, project and package dependencies.).

Ward Weistra (May 08 2020 at 14:25):

Perhaps we should repurpose the version field for scope specification, only for communication outside of package context?

    <meta>
        <profile value="https://fake-acme.org/fhir/StructureDefinition/ACME-base-patient|acme.base@0.0.4" />
    </meta>

Grahame Grieve (May 08 2020 at 19:37):

that's a pretty big change to introduce on the sly

Ward Weistra (May 08 2020 at 21:17):

@Patrick Werner I was pointed by @Alexander Zautke to a blog post where @Ewout Kramer pointed this out back in 2017: https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/

But I saved the most impactful consequence for last:
You can no longer interpret canonical references present in conformance resources or instances outside of the context of a package.

Let me reiterate that: any authoring tool, validator, renderer or whatever system that uses StructureDefinitions to do its work will need to know this context. Those who have carefully studied the current ImplementationGuide resource (especially ImplementationGuide.global) realize this is already the case now, but most are blissfully unaware of this hidden feature.

For systems working with conformance resources (like instance validators), it’s likely they have this context: if you’re dealing with a StructureDefinition, you probably got it from a package in the first place (it becomes a different matter entirely if a resource can be distributed in different packages. Well, let’s not diverge.)

For servers exchanging instances however – we’d need to assume they know the context out of band. But this won’t do for partners exchanging outside of such a controlled environment.

He goes on there to suggest a possible solution with Resource.implicitRules, but I haven't heard his current thinking on it yet.

Ewout Kramer (May 11 2020 at 08:59):

This is the kind of thing that you write down to get it out of your way until someone else thinks its important enough to continue to work on ;-)

Last updated: Apr 12 2022 at 19:14 UTC