clinFHIR Package Viewer

When an Implementation Guide is built by the IG Publisher (and presumably other build applications like simplifier), one of the outputs is a zipped package (actually a tarball)  that contains all the FHIR resources defined by the Implementation guide – profiles, extension definitions, terminology and conformance resources and such like. It’s based on the NPM package scheme as described on the HL7 Confluence page.

This package can then be saved in the International FHIR registry so that it can be discovered and downloaded by implementers. There’s a description of the registry on the HL7 confluence site, as well as from the registry itself.

While the package doesn’t contain the textual part of the IG, it does have all the computable artefacts that an implementer might need, as well as a manifest file (package.json) which contains a number of goodies about the IG – such as the canonical url, which can be used to view the full IG.

This post is to introduce a new clinFHIR module that can display the contents of a package. It works by downloading a copy of the package from the FHIR registry and saving it on the clinFHIR server.  Subsequently, the contents can be displayed to the user. The download only needs to happen once, as a particular version of a package is immutable – it is guaranteed not to change.

The package viewer is located at http://clinfhir.com/packageViewer.html. The front page looks like this (note that the module is being actively enhanced at the moment so may well change over time).

The viewer defaults to loading the IPS (International Patient Summary) package – just so the display has something to show (and it’s an important IG). The image above has the AllergyIntolerance profile selected.

To select another package, there are 2 options.

  • The drop down list has all the packages that have previously been downloaded from the FHIR registry. Simply select the package you wish to view.
  • If the package you want isn’t in the list, then click the icon alongside the dropdown, and enter the package name and version you are after. Assuming it exists on the registry, then it will be downloaded and displayed. There’s a link to the registry search page on the dialog to make it easier to find.

There’s actually a 3rd option – the viewer can be invoked with the package details, which will cause the package to be displayed immediately (it will be downloaded from the registry if necessary). This ability is used by the Connectathon Manager application to allow Connectathon attendees easy access to the Viewer for an Implementation Guide.

The Viewer has the following layout.

  • The top navbar has the name of the currently selected package, as well as links to the package in the registry and the Implementation Guide itself. The latter link uses the package.json ‘canonical’ url to determine the location of the IG, so will always be the most recent version (even if an earlier version is being viewed). However, most IG’s have a list of previous versions, so they can be located if needed.
  • To the left is an ‘accordion’ that is grouped by the resource type. Selecting an accordion group will show the actual resource instances, and selecting an instance will display the details of that instance to the right.

The actual detail shown will depend on the resource type. The ‘raw json’ of the resource is always shown, but some types have specific functionality. These are described in the remainder of this post.

Implementation Guide

This contains the ImplementationGuide resource, as well as the package.json file.

Resource Profile

Profiles on resource types are represented by StructureDefinition resources (as are extension definitions). There are a number of sub-tabs available:

  • A tree view of the profile elements. Selecting an element will display a summary of that element, as well as the ElementDefinition that describes it in detail. Any extensions are included in the tree.
  • A graph view that shows the other resources that a profile can refer to. These can be individually selected and include:
    • ValueSet bindings for coded elements
    • Extensions referenced by the profile
    • Other resources referenced by the profile
  • A table containing all the coded elements with their bindings. Clicking on the ValueSet url will allow the contents to be filtered and displayed. This uses the Ontoserver Terminology server. If the ValueSet is not present on the Terminology server, then the expansion will fail. In this case, there is a link that will upload the ValueSet resource from the package. There may still be issues if the actual code systems needed by the ValueSet are not present, but there’s a good chance that it will work.
  • A list of all elements marked as ‘Must Support’ (This is also shown in the detail page of the tree view when an element is selected)
  • A tab with required elements.
  • A tab with all of the extensions referenced by the profile.
  • A tab with the StructureDefinition.snapshot.
  • Finally, the json representation of the StructureDefinition resource.

Extension definition

Also described by a StructureDefinition, this has a summary tab of the extension, as well as the snapshot tab and raw StructureDefinition json

ValueSet

All ValueSets defined in the package. Contains tabs to explore the ValueSet contents (similar to that provided for coded elements in the profile) as well as the ValueSet json. Like the view from the profile, it is possible to upload the ValueSet to the Terminology server so that the expansion can work. Note that you may also need to upload any CodeSystems that the ValueSet uses (see next section)

CodeSystem

A list of the contents of the CodeSystem, and the resource Json. Like the ValueSet there is also the option to upload a CodeSystem to the Terminology server if it isn’t already there.

ConceptMap

A table with the translations, and the resource Json

CapabilityStatement, OperationDefinition and SearchParameter

Groupings for each of these types. Some have specialized tabs – all have the resource Json. The CapabilityStatement is borrowed from the clinFHIR Server query module.

DataType profile

As well as profiling a resource type, it’s also possible to profile a datatype – for example to add additional elements to an address or name, or to constrain existing elements. There is a tree view of the profiled DataType as well as the raw json.

Miscellaneous

Resources in the package other than those mentioned above.

Examples

The examples group is slightly different to the others. Within the accordion is a list of the resource types for which there is at least one example. When that is selected, a list of all the examples of that type is shown to the right – selecting one will display the example. All examples are in Json.

As always, use the FHIR Chat if you have issues or suggestions for this module.

About David Hay
I'm an independent contractor working with organizations like Lyniate, CSIRO in Australia and the New Zealand Ministry Of Health. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

One Response to clinFHIR Package Viewer

  1. Pingback: Dew Drop – May 11, 2021 (#3440) – Morning Dew by Alvin Ashcraft

Leave a Reply

%d bloggers like this: