Today we released Simplifier's public package server. The package functionality is in public beta and not yet in use in our official toolchain. It is, however, already build into our technical tool Torinox. A command line tool with a broad range of FHIR utilities. In this news post, I will explain how packages can be used and demonstrate this with Torinox.
Since this week, Torinox is a FHIR package client. This means that it can download and install packages for you. That doesn't sound very complex, but behind the curtain a lot of stuff happens. Most of the complexity is hidden. But since you're interested, we'll go into a bit more detail!
Let's look at the use case where you are working on a FHIR profile project. You want to derive from a profile in your regional infrastructure. In the past, you would have to download each profile, extension, valueset and more separately, or you would get a zip and put them inside your project. That is already cumbersome, but it gets worse if a new version of those profiles is published. It is even more hassle if those regional profiles in turn are based on a national infrastructure that may be changed.
This is something tools should fix for you without you having to worry about the logistics. Just tell the tool to upgrade your package and everything is updated automatically. If there is an updated reference to the national infrastructure in that package, it will be resolved as well.
One of those tools can be Torinox: our command line tool. We implemented a package client in Torinox. Eventually, we will make sure that all our tools work with packages. We even expect that most, if not all, tooling in the FHIR ecosystem will work based on packages. For a start, a command line tool is a good way to prove the concept. To install Torinox, follow these instructions.
Let's say you are working in a folder with FHIR profile files, which you can see as a FHIR profile project. If you need other profiles, you can install a package with Torinox. This will download and install a specific version, that you choose, on your computer. It will store the package in a global FHIR package cache.
It will also create a
package.json file in your current folder that keeps track of all the dependencies of your project.
If you already have a
package.json, a new reference will be added. The name of this file was chosen carefully: it's also
the file name of a package manifest. It means that your folder is ready to become a package itself.
Just installing a package is often not enough. Because an installed package might very well have dependencies on its own. Torinox will install these dependencies as well. There is an extra step: calculate all the direct and indirect dependencies in your project. This is what we call 'restoring'.
Restoring creates an extra file that holds a complete list of all dependencies. It makes sure that each reference is only there once, and it checks if each dependency is installed once. This is especially handy if you get a project from someone else. You just have this small 'package.json' file with the references you put in, and the restore will install everything and make sure all dependencies are accessible in your project. Now you are ready to use packages for snapshot generation and validation.
Watch this console demo to see how installing and restoring packages work. It makes it easier to try it out yourself! Perhaps we will even see a package that you created in Simplifier in the next few days. You can see the latest packages here: https://simplifier.net/packages.
Since the FHIR core packages are still work in progress, we created a temporary set of core packages:
Simplifier.Core.STU3.DataTypes Simplifier.Core.STU3.ValueSets Simplifier.Core.STU3.CodeSystems Simplifier.Core.STU3.Extensions Simplifier.Core.STU3.Profiles
And a meta package that contains them all, so you only need 1 reference in your project:
You can use this package to get a reference to the STU3 specification.
To give you something to try out for yourself, we created two demo projects with a package in Simplifier.
The first project is
Demo.National.PatientCare. This package has a dependency on the FHIR core profiles.
Here you can see the dependencies.
We copied one Patient Profile in it from the German base profile set.
The second project is the
Demo.Regional.PatientCare package. This one has one dependency on
But you can see it has also inherited a bunch of indirect dependencies.
In this project package, we put one Patient Profile from the nNGM project.
If you install this package on your computer and then do a restore,
> fhir install demo.regional.patientcare > fhir restore
you will also have the Demo.National.PatientCare package installed and all core packages mentioned above.
If you would now try to validate a Patient from the Koeln project, you will see it resolves all the relevant Patient Profiles.
> fhir get https://stu3.simplifier.net/open/Patient/484c4d0e-53f2-4e19-a5dd-09f9dcf74ae6 > fhir validate
In the end, the validation will not be successful because we did not bring in all the other profiles, like for example the national regional humanname profile, into the demo project packages. Once the main projects on Simplifier have their own packages, you can try it more realistically with those packages!