Introducing Forge for STU3

Today marks the community release of Forge for FHIR STU3. A joyful moment, right after our national Dutch King’s day and just in time for the upcoming HL7 WGM in Madrid.

Hoera! Hoera! Hoera!

You can download Forge, the FHIR profile editor, for free from the FHIR profile registry at simplifier.net. In this article we’ll introduce you to the new release and try to answer some common questions about migration to STU3.

Side by side installation

The new Forge for STU3 ClickOnce installer package has a new application identity that allows side by side installation. This means that you can install and use Forge for STU3 next to an existing installation of Forge for DSTU2 on the same machine. Each release will use it’s own version of the FHIR core resource definitions and manage it’s own application configuration settings separately.

Side by side installation

As of now, future application updates will target the Forge STU3 release. You can still use Forge for DSTU2 and remain to keep using it for as long as you need. But from now on, the Forge DSTU2 branch will no longer be actively developed as our development efforts are now focused on the STU3 branch. We will remain to provide support for the final Forge DSTU2 release to our commercial customers until they have migrated to STU3.

Profiling changes in STU3

FHIR STU3 introduces a lot of updated and new resources and datatypes. Changes to the conformance resources have the largest impact on profiling. Fortunately, the main FHIR conformance resources are relatively mature and haven’t changed drastically, with one notable exception in the terminology space: CodeSystem has been separated from ValueSet. However this change has no impact on Forge.

You will notice some relatively minor changes to the StructureDefinition resource and the ElementDefinition datatype. Some properties have been renamed and there are a couple of new properties, e.g. to define FHIRPath expressions.

One of the more notable changes involves ElementDefinition.type.profile. In DSTU2, an element type can define multiple profiles. However there are some complications with this approach:

Multiple type profiles pose a problem for dynamic code generation, UI input form generation etc.
Note that although Forge for DSTU2 (secretly…) supports specifying multiple profiles per type, all known FHIR DSTU2 implementations actually only consider the primary type profile. Practical use of this technique has been actively discouraged by the FHIR infrastructure group. We are not aware of any customers to rely on profiles having multiple type profiles.

When an element has type ResourceReference, we would like to be able to express constraints on the reference target. However ElementDefinition.type.profile expresses constraints on the ResourceReference itself.

FHIR STU3 solves these problems by:

Introducing ElementDefinition.type.targetprofile wich applies when the type code equals ResourceReference and expresses a constraint on the reference target. As before, you can use ElementDefinition.type.profile to constrain the ResourceReference datatype itself.

FHIR STU3 also introduces a lot of changes to the other (clinical) resources and data types. Forge for STU3 includes a new STU3-specific version of specification.zip that contains updated definitions for all the existing and newly introduced resources and data types in STU3.

Migration to STU3

As FHIR STU3 introduces breaking changes to StructureDefinition and ElementDefinition, Forge for STU3 is not compatible with existing DSTU2 profiles.

It is possible to automatically convert existing DSTU2 StructureDefinition resources to the new STU3 format. However an automatic conversion tool can only update the meta information in the profile. It cannot safely convert the actual profiling constraints. Because STU3 introduces changes to many of the resources, some of the constraints in a DSTU2 profile will no longer be valid when converted to STU3. For example, when a DSTU2 profile constrains an element that has been renamed/removed in the corresponding STU3 resource. Therefore migrating profiles from DSTU2 to STU3 will usually require manual review and corrections.

We have a team of experienced consultants with a track record in FHIR profiling who can assist and support you with smooth profile conversion to STU3. Feel free to contact us for a quote or if you want to learn more about our professional FHIR consultancy services.

Dutch royal family is said to be “super excited” about FHIR STU3

Looking back

We’ve come a long way since the first release of Forge. The initial Forge DSTU1 release attempted to provide a reference implementation of the FHIR standard. Our team tried to demonstrate that the basic FHIR (profiling) principles could indeed be implemented and put to use. Forge was originally designed to hide the user from the complexity of the underlying XML/JSON wire representation. The novel UI design quickly drew a small but growing user base and succeeded to stimulate both the adoption as well as the development of the FHIR standard itself.

After updating Forge to DSTU2, we focused our efforts on improving the quality of the generated differential and snapshot components. Implementing a proper and fully capable snapshot generator in the .NET FHIR API library proved to be a (royal pain in the ***) challenging and time consuming undertaking that claimed a great deal of development time during 2016. But those efforts eventually drove the implementation of some very powerful profiling features in Forge, such as support for derived profiles, deep inline constraints on complex extensions and dynamic expansion of choice type elements and properties. It took a fair bit of time and effort to stabilize some of the more complex features. But thanks to feedback from our users and from the FHIR profiling community, we managed to solve most of the reported issues.

Moving from DSTU2 to STU3, we have noticed a clear trend in Forge issue reports where they slowly but steadily involve more and more complex and rare profiling use cases. This indicates that basic FHIR profiling features have indeed matured and stabilized and that our users are starting to apply more advanced profiling techniques. And while these newly reported issues may not always be easy to solve, generally they do seem to confirm that FHIR profiling is proving to be effective and productive!

Looking forward

Now that we have updated our full tooling stack to STU3 (The official FHIR .NET API library; Forge, the FHIR profile editor; simplifier.net, the FHIR profile registry; and last but not least Vonk, our new enterprise-grade FHIR server), we are looking forward to unleash them onto the FHIR community, starting at the upcoming HL7 WGM in Madrid.

Our simplifier.net platform now supports STU3, but will also remain to serve existing DSTU2 profiles. We will cooperate with our Simplifier users in order to provide migration strategies to update existing DSTU2 projects to STU3. Under the hood, our team has updated the simplifier.net environment to the new Microsoft .NET Core platform, which brings a significant performance increase, improved response times and higher scalability. We are experimenting with the new Microsoft Orleans platform, an exciting new cloud-based technology, in order to implement scalable validation support and initial results are quite promising. This will allow our simplifier.net platform to provide computationally intensive features to an ever increasing and demanding user base.

As Forge has been updated to STU3 and most of the underlying complex profiling logic is finished and maturing, we can now focus our development efforts towards improving the user experience, file management, online simplifier integration and profiling workflow support. We have received a lot of great suggestions from the community about possible improvements and new features that will allow us to further improve the application. Your feedback remains very valuable to us, so please don’t hesitate to submit issue reports and/or feature requests! Should you have a need for commercial support, then you may benefit from one of our simplifier.net account plans.

Last but not least, our brand new Vonk server is now ready for STU3. Vonk is a modular and highly scalable FHIR server based on the new Microsoft .NET core platform. Aside from performance improvements, the new platform also enables some surprising new applications, as recently one of our bright engineers successfully managed to spin up a Docker image of Vonk server running .Net core on Linux. The new flexible options for host operating systems ensure that our Vonk server will smoothly integrate into any existing customer infrastructure.

Final thoughts

Millions join the Forge STU3 release party, Amsterdam 2017

We hope that you enjoy the new Forge STU3 release, as well as all our other FHIR tools. Firely celebrated this important milestone in Amsterdam on our King’s birthday, which traditionally involves orange outfits, DJ-powered canal boat rides and abundant substance abuse. And now that the orange smoke has cleared up, we’re back making FHIR even simpler.