Category Archives: Background

Vonk 0.3: subscriptions and more

TL;DR;

Recently we released an upgrade of the enterprise FHIR Server named Vonk. This release 0.3 contains features like custom search parameters, subscriptions and an Administration API. For a complete overview of new features, see the release notes. You can try for yourself at http://vonk.furore.com or download a trial version on http://simplifier.net.

Remember my bike?

It is strong, durable and simple. But if you are going to take a long ride, you need stuff. Hot coffee, raincoat and of course binoculars to check all the birds. Thaortlieb-back-roller-black-n-white-pannier-pair-white-black-EV229664-9085-9.jpgt means hanging a back roller to it. And that is what we did with Vonk as well: add a back roller full of new features.

Protection from the elements

What a raincoat is to a cyclist, validation can be to Vonk. Just bare validation was already possible (and still is, on /<resourcetype>/$validate), but now you can also protect your data by validating of all resources that are created or updated. And if they fail validation, they are rejected.

That is nice, but you probably have made your own custom profiles (in the form of StructureDefinitions). Of course hosted on http://simplifier.net šŸ™‚ Previously you had to send these to /StructureDefinition/yourSD to make Vonk use it for validation.Ā You can now feed them to Vonk through the new Administration API, still by doing a FHIR update interaction.

Finally, you can specify a list of profiles in the settings so that Vonk will only allow resources conforming to any of those profiles.

Subscriptions

2017-09-19 11.38.51Although a subscription to fresh coffee while riding is not really feasible, you now can subscribe to resource changes in Vonk. How this works is described in the FHIR specification, but the gist of it is that you post a Subscription resource to the Vonk Administration API. The resource specifies criteria for which resources you would like to receive notifications, and a channel through which you want to get those notifications.

Current limitations are that you can only specify a channel of type rest-hook, and changes on referenced resources do not ‘bubble up’. And although subscriptions are evaluated asynchronously, we did not yet build it for large numbers of subscriptions. See the documentation for details.

Find more

If you search for birds, you need binoculars (or better: a telescope). If you look for img-20170919-wa0013.jpgresources, you need as many features as possible. So we introduced custom search parameters. You can specify several sources (the .Net API, a zip file, a directory) with custom search parameters at startup. After that, new or updated resources will be indexed for these new parameters, and you can use them in your search interactions. Existing resources can be re-indexed through the Administration API, in order to find them on the new parameters as well.

Besides that, we implemented support for _list, _has, _elements, _type and _revinclude. And we improved on :missing, :exact and datetime handling. Finally, we moved to using the FHIRpath Expression in the SearchParameter resource to extract the indexed data, meaning we can now handle all the search parameters in the spec (and probably all your custom ones as well). A full list of improvements is provided in the release notes.

Go faster

I made my bike slightly faster by making it lighter: I removed the fixed dynamo and headlamp as I use a much better LED lamp if I have to. We also made Vonk faster, but by adding things: indexes! Both the SQL and MongoDb database implementations could use a few extra indexes, since reading and searching is used a lot more then update and create.

Have your partner make lunch

Do you know the happy feeling when you find a nice lunch in your bag, readymade by your partner? You can now pre-load Vonk with a set of resources as well, and make the users as happy. This is particularly useful if Vonk is used as a reference server for testing between communication partners. You use it by posting a zipfile with resources through the Administration API (/administration/preload). This interface is not meant for bulk loading really large sets of resources.

Start your ride easier

We have had a lot of positive feedback on the ease of deployment of Vonk. But we felt it could still be easier. So we removed the step of creating your SQL database yourself. If you allow Vonk to do so, it will automatically create databases for both the regular operations and the Administration API. For MongoDb this already happened, and for the Memory implementation this is obviously not an issue.

Beware if you have a database for the previous version of Vonk (0.2.*). It cannot be automatically updated. We will contact customers with professional support to upgrade their databases. You can check your version of Vonk in the CapabilityStatement.

License

You need a license to run Vonk. On Simplifier.net you can download an evaluation license. This will grant you usage of Vonk during 30 days, and it requires you to restart Vonk every 12 hours. If you need more evaluation time, you can simple download a renewed evaluation license. If you need to test without the 12 hour limit, please contact us.

Pricing

If youā€™re interested in using Vonk for production purposes, visit our pricing pages. We are still working towards a usage based pricing model and in the meantime you can enroll in our Launching Customer Program. Early customers are rewarded with the choice to stay in this pricing model once we have implemented the usage based pricing model.

Advertisements

Whatā€™s new in Simplifier 16.5?

By Lilian Minne

The latest Simplifier release includes a couple of pretty nice improvements in implementation guides, workflows and GitHub Webhook. We also added the ability to directly edit resources in XML from Simplifier. In this article we will tell you all about the latest release.

Implementation guides

Letā€™s start with the implementation guides. While Simplifier was originally designed for uploading and downloading publications, the idea of working with projects and organizations followed later. IGā€™s were treated as separate parts, which were not linked to a specific project. In this new release, IGā€™s are always part of a project. A new tab is visible at each project where you can find the projectā€™s IG, as shown in the screen picture below. The old IGā€™s will still be available, however new IGā€™s cannot be created outside a project any longer.

ImplementationGuide in Project
Implementation Guides of a project.

Moreover, we introduced a new storage system for IGā€™s. Your IG is now stored as separate mark down files in your project. This has a lot of advantages. It is now possible to access them as separate resources, add issues to them and check version history (more on this later). In addition, your IGā€™s will now be available in your GitHub repository and can be downloaded in a ZIP file together with the other files of your project.

 

IG tree example

IG tree in the IG editor.

To illustrate how this works, see the screen picture of an example IG containing two chapters called ā€˜First partā€™ andĀ Ā ā€˜Second partā€™. The First part also contains a childĀ called ā€˜Child of first partā€™.

The different parts of the IG are now accessible fromĀ theĀ Resources tab in your project as well as from the search engine. Two categories called Text and Image are added. To search for IG parts, just check the Texts box.

New Test resources

Resources inside a project.

The IG parts can be accessed in the same way as a Resource. From the Issues tab you can create new issues that specifically address this IG part. From the History tab you can access its version history. In this way you can go back to an earlier version and directly edit it from here. It is even possible to compare two different versions by selecting the boxes of the versions you want to compare.

Version history

Version history of a resource.

Custom workflow

In addition to the improvements on IGā€™s, we enhanced the custom workflow. With custom workflow you can add additional statuses besides the standard FHIR statuses. For example, if you want to be able to explicitly state that your resource is ready for review, you could add a Review status. In the new release, it is possible to click on the status of a resource to see all possible statuses and their explanations, as shown in the screen pictures below.

Resource tab - custom workflow

Resource tab inside a project.

Custom workflow overview

Custom workflow overview.

GitHub Webhook

The last big improvement to an existing feature goes for the GitHub Webhook. The Webhook is now one of the most used additional features of Simplifier. Overtime, some users have reported issues with complex merges. To address these reports, we have refactored the whole GitHub Webhook functionality in Simplifier, which is pretty complex stuff. We now use a Git engine to calculate the differences, which results in much more reliable updates of projects that contain a lot of branches and complex merges. These changes significantly improved the reliability and predictability of GitHub Webhook.

Edit resources and copy code to clipboard

My personal favorite is the new feature that enables you to directly edit your resources within Simplifier by editing the XML code. Just click Update and choose the Edit option to open a ā€œsimplifiedā€ XML-editor. Pretty cool, right?

Edit resources by copy&paste

Update a resource.

Edit xml

Edit the XML of a resource directly in Simplifier.

From the download button it is also possible to copy the complete XML or JSON code of a resource to your clipboard.

Work in progress

Work in progress, user profile

Personal menu.

We are working on something we like to call Facebookification. From your personal menu you can now access your User Profile. This profile is public, so other users can access it as well. In the future, we plan to add more functionality for personalizing your profile. Also new from this menu is that you can access a separate Invites page which shows your pending invites for Simplifier projects.

The way forward

To give you a taste of the cool stuff that we are planning for the future (no guarantees of course), here are some of our ideas:

  • Import and export of IG resources
  • Add intelligence in the IG editor (e.g. placeholders)
  • Comparison of history of pages of IGā€™s
  • Internal references to images in the same project (note that external references are already possible)

Of course we are always open to new ideas as well, so donā€™t hesitate to use the feedback link on Simplifier.

Element Identifiers in FHIR

In this article, we’ll take a closer look at element identifiers in FHIR, the relevant changes introduced by STU3 and the reasons that motivated that change.

FHIR has supported element identifiers since DSTU1. They are intended to specify unique identifiers for the elements within an individual resource. The official definition from the STU3 specification states: “The id property of the element is defined to allow implementers to build implementation functionality that makes use of internal references inside the resource. This specification does not use the internal id on the element in any way.

Element ids are particularly convenient to identify the individual ElementDefinitions inside of a StructureDefinition. In a basic StructureDefinition without slicing, each element definition has a unique path. However when a profile introduces slicing constraints, element paths are no longer unique, as the following example demonstrates:

Element name Slice name Element path
Patient Patient
identifier Patient.identifier
identifier ssn Patient.identifier
system Patient.identifier.system
identifier ehr Patient.identifier
system Patient.identifier.system

Clearly, the element path itself is not sufficient to uniquely identify individual element definitions, as we also require information about slice name(s). But if we would also include the slice name(s) in the expression, then the resulting value is no longer ambiguous and becomes a unique identifier:

Element name Slice name Element identifier
Patient Patient
identifier Patient.identifier
identifier ssn Patient.identifier:ssn
system Patient.identifier:ssn.system
identifier ehr Patient.identifier:ehr
system Patient.identifier:ehr.system

In order to support this, FHIR STU3 introduces some changes in the definition of element ids. The following table compares the specification of element ids in different FHIR versions:

FHIR version data type max length
DSTU 1 id 36 characters
DSTU 2 id 64 characters
STU 3 string 1MB

In STU3, the element identifier datatype has changed from id to string, effectively removing the maximum length constraint. Also, STU3 allows any string value that does not contain spaces, whereas in earlier versions, the set of valid characters was limited to A-Z | a-z| 0-9 | - | .

FHIR does not specify a mandatory format for element identifiers. In STU3, any unique non-empty string value without spaces is considered to be a valid identifier. However STU3 does introduce a preferred format for the identifiers of ElementDefinitions in a StructureDefinition resource:

"elementName[:sliceName].elementName[:sliceName]..."

Similar to the element path, the preferred identifier format specifies a number of path segments, separated by a dot “.” character. Each segment represents an individual element in the hierarchy and starts with the element name, optionally followed by a semicolon “:” character and the associated slice name (if not empty).

The preferred element identifier value only depends on the position of the element in the element tree. Different available representations of a specific ElementDefinition in both the differential and the snapshot component share the exact same identifier value. As the astute reader may have already noticed, this implies that element identifiers in the preferred format are actually not fully unique within the context of the containing StructureDefinition resource. Also, if we include multiple StructureDefinitions in a Bundle resource, then ElementDefinition identifiers of are not guaranteed to be unique within the context of the containing Bundle resource.

Note: When a FHIR resource is serialized to the XML representation, FHIR element identifiers are expressed as xml:id attributes. According to the W3C specification, “the [identifier] value is unique within the XML document”. So in fact, the FHIR specification violates the W3C XML specification… However in practical situations, this idiosyncrasy of FHIR shouldn’t pose an issue.

In general, software cannot assume that FHIR element identifiers follow the preferred format. The FHIR specification itself does not use the internal id on the element in any way (1). For ElementDefinitions contained in a StructureDefinition resource, the element name and the slice name remain to be the leading identifying attributes for processing logic to act on. This also implies that a sparse differential component should always include parent elements with a non-empty slice name, even if they are unconstrained. In theory, processing logic could reconstruct the parent element hierarchy by parsing the element identifiers in the differential component, provided that all identifiers are specified in the preferred format. However as the preferred identifier format is not required, generic logic cannot rely on this information.

Nonetheless, the standard open source Java and the .NET libraries for FHIR STU3 both provide implementations of a snapshot generator that can generate element ids in the preferred format. So within a clearly defined use context that guarantees standardized element identifiers to be present, e.g. because all snapshots are always (re-)generated by a standard FHIR library, it becomes possible to implement processing logic that acts on the standard identifiers.

Forge, the FHIR profile editor, introduced preliminary support for element identifiers as part of the initial STU3 release from May 2017. Initially, Forge allowed users to specify custom identifiers, however this feature has been deprecated since. As of release 16.4 for STU3, Forge will automatically generate element identifiers in the preferred format on all ElementDefinitions in both the differential and snapshot components. Users can not manually edit the generated identifiers.

1. ^ As Grahame points out in his comment, the FHIR standard actually does use element id’s as the target of content references. However these references do not rely on the format of the identifier.

Simplifier on STU3


by Martijn Harthoorn

As of today Simplifier supports FHIR STU3.Ā Our team has been working hard to give you a FHIR registry that can read, write, listen and speak FHIR STU3 resources. Now you can start uploading STU3 resources.

The change in the FHIR specification from DSTU2 to STU3 itself is not all that big. And had Simplifier been an offline tool, it would have been an overseeable load to upgrade to the new version.

But we have been on a bigger journey. Because we have thousands of profiles and other resources from the whole FHIR community and from over the whole world that are all DSTU2.

And so we didn’t just upgrade Simplifier to STU3, but rather made Simplifier multilingual. Simplifier now supports both DSTU2 and STU3.

Upgrading
From the beginning of January, right after the San Antonio connectathon,Ā  until the end of March, our team has been busy upgrading Simplifier to a new framework (ASP.NET core) to make it more stable and much faster (pages resolve up to 20 times faster!). ThisĀ allowed us to take the next step: to be able to host multiple FHIR engines inside.

All features are now able to switch the FHIR engine from under their seat depending on the version of the resource they are dealing with.Ā This includes uploading, downloading, the GitHub webhook, the history compare, the FHIR endpoints.

Whats the difference for you?
Each project and each resource now has a FHIR version. In the past we kept numbers like 0.50 (which is actually DSTU1) and 1.0.2 (which is DSTU2). And we only used these numbers for resources. These numbers were set by the version of the internal FHIR engine we used. All these number have now been replaced by “DSTU1”, “DSTU2”, or “STU3”.

Plus, the versions are no longer set by Simplifier, but by you. You can set your project to a FHIR version. And all resources you upload will be read as belonging to that version. You can always switch the FHIR version of your project and nothing will happen to your resources. They will keep the version they already had.

In the near future we will make it possible for you to manually change the FHIR version for the resource too. This goes for all users, whether you have a free account or a paid account.

Simplifier as a FHIR server
As of today the Simplifier FHIR endpoints speak STU3. Both the public endpoint:

https://stu3.simplifier.net/open/StructureDefinition

and the project endpoint:

https://stu3.simplifier.net/ [project]

This also means that you can only connect with client tools that speak STU3.

Validation

A feature that a lot of our users have been asking for is validation. All example STU3 resources will now have a Validation button. We will be adding new features to validation soon, like bulk validation, validation through the FHIR endpoint and validation in Gist.

Are we done?

Probably not. Making a platform ready for multiple versions of a standardĀ is a tricky business. So we expect to mend a few bugs and make some improvements over the weeks to come. Use the feedback button if you think we can do better.

As FHIR registry builders, we are in the business of canonical URLS. Yours to be specific. Since all the base resources in the FHIR spec have the exact same URL in STU3 as they had in DSTU2, you can imagine that we had to practically have to build a wall between the DSTU2 and STU3 resources, to make sure they don’t start referencing to each other. Imagine validating or creating a snapshot using a base profile from the wrong version of the standard. You’re right. It can’t be done. So when you deal with STU3 we will filter out everything DSTU2.

Staying at DSTU2.
Of course you can stay inĀ DSTU2 as long as you like. Simplifier will support DSTU2 for years to come. But remember that the FHIR spec moves forward and so will all of our new features. So if you can migrate to STU3, you probably should.

Moving your resources to STU3
The community has several tools to help you migrate your resources to STU3. Migrating your profiles is slightly more difficult, but there are options, besides doing it manually. And remember, before you upload STU3 resources, make sure you set your Simplifier project to STU3 first!

Happy profiling!

Vonk FHIR Server in public Beta

Take a ride

Furore has built a new FHIR Server named Vonk. In keywords: enterprise grade, support available, SQL Server and MongoDB, FHIR Facade, cross-platform, Dockerized, .Net Core, STU3. As of now it is in public Beta. Try it at http://vonk.furore.com or download a trial at Simplifier.

Inspiration

FietsCK-01

This is my bike. After being a simple city bike for the first 25 years, I decided to keep the good parts and improve the rest. Now it suits all my many bike needs. It is clean. No gears, no cables, no chain cover, just the items that I really need. It is strong but not heavy. Steel frame, steel carrier, able to carry my wife on a romantic trip and it doesn’t break on the many potholes and loose tiles in the city. It is versatile. It can ride both dirt- and tarmac roads. Run lightly on my way to work, carry all the groceries for a week on Friday. It has the right size. Large enough for my 1.95m length, but it still easily fits in a bicycle rack. It never gets in my way in the shed. Maybe the best part is the carbon belt drive that I had mounted recently. Unbreakable and yet free of maintenance. And now that the bike is 27 years old and still my daily commuting bike I can faithfully say that it’s proven technology. And my inspiration for developing Vonk.

The old bike

Back in 2012 when FHIR had just started, Furore started implementing the server part of the specification in .Net, and we called it Spark. A reference implementation to test the spec and provide the world with a real FHIR server to develop and test against. It has gained a lot of attraction, well beyond these purposes. Many requests for e.g. production use, SQL Server, STU3 and company support reached us.

The new bike

So we decided to respond with a new incarnation of Spark that would be able to serve as a very versatile yet production ready FHIR server. And it deserved it’s own name: Vonk. Vonk packs together our extensive experience with FHIR, the HL7 FHIR .Net library and Spark in a fully new solution based on Microsoft .Net Core.

fietsck-03.jpg

New, robust technology

Several of you may have seen my talk on building a FHIR Server (> 19:30) at FHIR DevDays last November. By now we have realized many of the ideas that I presented in that talk. As of today we present the official Beta release of Vonk.

Ready to ride

My bike is always ready to ride. For a quick schoolrun or an extended birdwatching ride – it will just run. Vonk FHIR Server is the same. Install and run. It is a stand alone FHIR server with MongoDB storage. Or SQL Server and then truly support transactions. Or run a few quick tests on the in-memory store. The storage API that we created to accommodate these very different storage engines enables us to add other other back ends easily, either with or without support of Entity Framework.

Change the wheels

A few weeks ago my birdwatching buddy lured me into a dirt road. Dirt became mud and then deep mud. Even my bike has limits. It meant I had to continue walking. But with Vonk you just change the wheels! With Vonk FHIR Facade you can leverage the power of the storage API to plug it on top of your existing database. Thus Vonk acts as a FHIR REST facade on top of your (legacy) system. And although Vonk is enterprise grade, it is not heavy. So you can unleash your systems small and large all in the same way. All you need to do is create an implementation of the storage abstraction for your use case. We already did so ourselves: the Simplifier.net platform runs on Vonk. The same abstraction even allows you to address other (web) services for retrieving or storing the actual data, thereby using Vonk as a hub, possibly backed by other Vonk instances that are facades to your internal systems. When creating a facade you program the new wheels in .Net, with all the power that comes with that. On the roadmap is creating facades by configuration.

Assemble your own

No gears, no handbrakes, clean as can be. But a bit too clean if you need to climb a hill. In the Netherlands we don’t do hills, but Vonk can be used around the globe. Vonk FHIR Components gives you all the good parts of Vonk, for you to assemble your own perfect FHIR Server. Or integrate it into a larger web server. Or turn it into a hometrainer. Just add and leave out parts as you like. Vonk FHIR Components will become available as NuGet packages.

Run all the tasks you need

From groceries to commuting: even my bike is not as versatile as Vonk. In this beta release it will do STU3 and DSTU2, JSON and XML, and most of the regular FHIR interactions plus a few bonus ones:

  • capability statement (metadata)
  • create, read, update, delete
  • search on all specified parameters, also chained, choices, multiple resource types, include related resources
  • full resource version management, enabling history on resource, resource type and system level
  • process batches of interactions, in a transaction if you wish (requires transactional storage)
  • validate a resource against the spec or a custom profile
  • extensible to custom operation (‘$your-operation’)

The road ahead

More features are on their way. Priority is volatile and can be influenced by customer requests.

  • support for several more options, e.g. _summary, _elements and conditional operations
  • subscriptions
  • documents ($document)
  • proper support for ‘Binary’ resources

Lock it

fietsck-06.jpg

Security in Amsterdam is not about riding with a helmet, but putting at least two solid locks on your bike. We know a thing or two about not letting your bike get stolen. Or your data. So Vonk runs on https, can be fronted by a reverse proxy (e.g. Apache or NGINX) and exposes just the FHIR RESTful API endpoints. But a fully locked bike brings you nowhere. You need access, but limited access if needed. Therefore Vonk can participate in an OAuth2 single sign-on environment. Access to resources can be based on the claims in the OAuth2 access token. You can use the preconfigured scopes and launch contexts as defined by SMART-on-FHIR, or configure your own.

Ride anywhere

Although my bike won’t ride on water (in Amsterdam we have canalbikes for that) or deep mud, just about any other surface will do. And Vonk is no different: it runs on Windows, Linux, OSX, as an executable or in a Docker container, on premise or in the cloud, as an Azure App Service – you choose.

Ride fast

When my colleague Marco showed me Vonk running on Docker I was so thrilled I even overtook e-bikes at 30 km/h on my way home. With Vonk we also made performance a number one priority. Using the newest Microsoft ASP.Net technology and proven storage solutions we managed to implement a very performant FHIR Server. Being lightweight and fully asynchronous you can scale out or up as you see fit.

Be in control

In the Netherlands there is wind. Usually in your face. You need to lie low. So my first upgrade was the handlebar that allows me to lie comfortably on it and still keep control over the bike. Extensive semantic logging to just about any target and a connection to Microsoft Application Insights allows you to control Vonk just as well. Integrated validation can be used as a gatekeeper to accept only compliant resources. On the roadmap is also an extensible management API to:

FietsCK-05

  • add profiles, or restrict to specific profiles
  • add or restrict the search parameters
  • enable or disable operations

Where is the blueprint?

I’d be happy to tell you how I built this bike. But Vonk is not open source. Vonk is a commercial product based on license fees and paid support. Nevertheless we want to continue to support the FHIR community as we already do with the FHIR .Net API and Forge. In short it is possible to use Vonk for free if you support the FHIR community in any way with that usage. Just contact us to see if you’re proposed usage fits this goal.

What happens to the old parts?

I kept them in my shed as spares. As for Spark: This is up to the community. Furore has put a lot of effort in Spark and provides all of this effort to the community. Itā€™s open source, available on GitHub. But Furore will neither port Spark to STU3 nor provide support for DSTU2.

Name

I never gave my bike a name. But ‘Vonk’ means two things. First, it is the Dutch word for Spark. After struggling with our company name Furore we thought the FHIR community was up for the next Dutch challenge. Second it reminds us of our dear collegue Hans Vonkeman who has passed away far too young and thus it is a kind of a tribute.

And now I’ve been at the keyboard long enough. Off for a ride. Do you ride along? Visit the getting started to see how you can get a trial Vonk FHIR Server as binaries or in a Docker container.

Prefer to ride along face to face? I’ll be at the HL7 WGM in Madrid next week, albeit not by bike. Or visit the FHIR DevDays here in Amsterdam in November. There I will be by bike.

Cheers, Christiaan
FietsCK-07

Simplifier and Forge Migration to STU3

by Martijn Harthoorn

TL;DR
Simplifier, Forge, and Vonk (the successorĀ of Spark) will be migrated to STU3 before the Madrid WGM in May.

The week after March 20th, the next version of the FHIR specification STU3 will go live. This will be the first STU. Notice the D is gone? You can find out why here.

As the tools that we provide to the FHIR community are quite popular and heavily used, we need a very good plan to migrate to STU3. Of course we want to bring you STU3 as soon as possible. But we are not going to drop DSTU2 support just like that. Looking at several of our customers, we expect some companies will remain dependent on DSTU2 for a while. Here’s what we’ll do with our tooling.

Forge

Forge has gathered a significant user base. And since Forge is distributed via a ClickOnce installer, we will create a separate side-by-side releaseĀ for STU3. This means that you will be able to install and run both the currentĀ DSTU2 and STU3 Forge releases on the same machine. We will not distribute the STU3 release as an auto-update of the current DSTU2 release; otherwise existing Forge users would no longer be able to manageĀ any DSTU2 profiles. We will announce the STU3 release via the Furore news feed on Simplifier and also on the FHIR chat groups on Zulip.

Forge depends heavily on the FHIR .NET API, which we are currently upgrading to STU3. STU3 brings changes in some of the core resourcesĀ and datatypes. STU3 also introducesĀ someĀ important changes in the meta data. Therefore DSTU2 and STU3 profiles are not directly interchangeable.

Simplifier

The migration of Simplifier is more complex. In addition to introducing support for STU3, we are also migrating Simplifier to a newer technology stack (ASP.NET core for anyone who’s interested). An additional complication is that Simplifier needs to be able to host both DSTU2 profiles and STU3 profiles at the same time. We will make a strong push towards STU3 after march 20th, but that does not imply that we will abandon DSTU2.

We will make projects on Simplifier FHIR version specific to help you, and our tooling,Ā  figure out how and what we should render. Of course, it makes no sense to try and render a DSTU2 profile with a STU3 render engine. It would just fail.

The strategy that we will follow is what we call a graceful fallback strategy. This means that we will move all our internal Simplifier tooling to STU3. And we will move all the rendering logic to STU3. But we will make it possible to still host and even upload DSTU2 profiles. This is not as simple as it may seem. After careful consideration, we decided to implementĀ FHIR validation as a separate step, instead of being tightly integrated as a mandatory step to the import. Currently you are not able to upload DSTU1 or STU3 resources, because the FHIR engine in SimplifierĀ  considers it to be invalid input (does not conform to FHIR DSTU2). We are going to change the upload procedure, so that the server will accept invalid FHIR input. And instead of rejecting invalid input, Simplifier will inform you that it is not valid STU3 FHIR.

But this is where our graceful fallback strategy comes into play: we can’t keep everything live for all versions of FHIR. We think it’s not beneficial for the standard either. Whenever you can migrateĀ to STU3, you should. But we will make an effort to do what we can to keep DSTU2 working for you. We keep the existing tool set for DSTU2 alive. And the more we manage to do, the better your DSTU2 experience you will be.

Schedule

This is our schedule

February 13th – API
We started work on our libraries and packages on NuGet to be as ready as we can for STU3. This includes the model (base resources) parsing and serialization, validation, snapshot generation.

March 20th – FHIR
FHIR STU3 is live.

April 1st – Simplifier
This is not a precise date yet, but around this time we expect our first internal release for BETA STU3 . This is also when we start working on making Simplifier still support DSTU2.

April 17th – Simplifier & Forge
Around this time Simplifier and Forge for will go live with STU3 BETA for the daredevils.

May 6th – Simplifier
Before this date, a week before the Madrid WGM starts, Simplifier and Forge will be battle tested for STU3 and you should be ready to use them.

When something goes live, we’ll tweet about it.

Migration of your profiles

Whether you manage your profiles on Simplifier or on your local disk, migrating structure definitions automatically is no task that can be done without human supervision. But there are several tools in the community to help you. And of course our consultancy team can offer to help you with that too. They have helped a wide range of customers around the globe with migrating their profiles to STU3.

 

 

 

Profile versioning

by Martijn Harthoorn

In the Simplifier team we think a lot about Profiles. We try to think of the places where they will be used and how they will be used. I will share with you one recent discussion we had about versioning of profiles.

The discussion started after a comment in the FHIR community from Lloyd McKenzie of the FHIR core team that a lot of profiles have references to other profiles (profiled references), that when updated, cause cascading updates. Let’s explore this. Assume we are working with a profile on Patient for our Hospital X. Let’s give the first published version of this profile the following canonical URI:
http://hospitalx/Patient-V1 (and lets abbreviate it to P1)

Now let’s assume we also have DiagnosticReports in our hospital, so we create a profile for those, and we give it this canonical URI:
http://hospitalx/DiagnosticReport-V1. (abbreviating it to D1)

As you might know a DiagnosticReport references a Patient. It’s not unlikely to assume here that we want our DiagnosticReports to only refer toĀ Patient resources from our own hospital. For that FHIR allows you to profileĀ the reference to Patient: a constrained reference. In your profile you tell that whatever patient your diagnostic report is about, that patient has be conformant to a Patient profile with the given canonical URI. In our case, the profile on DiagnosticReport (D1) will have a reference to Patient constrained to only allow P1.

This might seem a logical thing to do, but it turns out that it can be quite a burden on the authors of these profiles. If you publish a new version of your Patient profile (let’s call it P2), your existing diagnostic report profiles (D1) won’t allow referencing it because they have the reference definition constrained to only accept references to patients profiled on P1.

profileonpatientchanged

If you would update the DiagnosticReport profile, references to Patients of the P1 profile are not allowed either.

2017-01-05-13_43_40-drawing1-visio-professional

In some situations, this can cascade to an update of 50 profiles with a breaking change.

To be more precise: the problem that profile authors face is that they have to update the canonical URIĀ in all profiles with a constrained reference. It also means that they want to be able to republish their profiles at once as a batch. You don’t want to have your other profiles reference an older version.

For these two steps, changing the references and republishing, it is possible to build tooling that can do most of the work automatically. We’re working hard on getting such capability within Simplifier for you.

But our discussion brought two other interesting versioning challenges to light.

The first challenge concerns authoring and deployment collaboration. Let’s say that the central administration of our hospital X upgrades their patient profile. But the lab creates their own DiagnosticReport profiles, and these DiagnosticReport profiles (of course) constrain the reference to Patient to only allow patients from withinĀ the hospital. Again D1 references P1. Now after the upgrade of the central administration for Patient from P1 to P2, the lab won’t be able to accept new P2 patients that are sent from within their own hospital, unless they upgraded their servers at the exact same time. This might be a good thing, because a breaking change is a breaking change for a reason. Note here that a breaking change is the only reason to change your canonical URI. But our presumption is that in a lot of cases, the profiled reference is not a matter of exact conformity. The lab doesn’t care about the all the exact fields of the patient. The only reason why the Patient reference was profiled, was to be sure they would not send or receive Patient data from outside the hospital. For example: they possibly only cared that the Patients they receive all have an identity given out by the central administration. For this likely scenario, aĀ  canonical URL change creates a huge unnecessary burden that might trigger a very expensive cascade of downstream updates in profiles.

There are solutions here. For example: the hospital could start of with a profile “Patient Zero” (P0) that only has the hospital identity field. Then, have the ‘real’ profiles (P1 and P2) be derived profiles from “Patient zero”. This is not very obvious and of course requires a forward thinking profile author that had the smarts to take this step as his first action of business. It won’t be easy fix afterwards.

The second challenge that surfaced in our discussion is about our own tool Simplifier.net and possibly any FHIR registry. Once you have published one of your profiles in Simplifier, you have assigned it a unique canonical URI, you marked it as [Active] and by that you made a promise to your profile consumers that you won’t introduce any breaking changes for that profile. But of course at some point you are going to have to change something. Whether or not you are introducing a small update or a breaking change, you would like to continue working with that same profile. In the case of your Simplifier project, you don’t want to lose your version history, issue tracking and activity log. However you also don’t want to change the status of your published resource from “active” back to “draft”. Currently, you will have to create a new resource and work from there. That’s something we realized we have to change as creators of the tool.

For now our plan for the future is to allow creating draft versions of a resource even after it’s been published, instead of making you create a new resource. This will also require registering a canonical URI for each published version of your resource instead of how it is now: just once, which is automatically the latest version.

Your feedback here is appreciated as always. There is a feedback button on the top of the page in Simplifier.net. Our support team always reads it and responds to it.

Happy new year and happy profiling to everyone.