Author Archives: Martijn Harthoorn

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.

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:

and the project endpoint: [project]

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


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!

Simplifier and Forge Migration to STU3

by Martijn Harthoorn

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 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.


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.


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.


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


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 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 Our support team always reads it and responds to it.

Happy new year and happy profiling to everyone.

FHIR DevDays 2016 in Amsterdam

by Martijn Harthoorn

Whenever I am at the FHIR DevDays in Amsterdam, I always get this vibrant feeling that this is where it happens. And it’s true: significant things happen. For those who could not attend, here are the highlights.

Developments in the FHIR standard

We are not that far away from publishing STU3. And STU4 is on the horizon. It will not be long until parts of the FHIR specification will go normative. But we have also seen at the DevDays that there are still many initiatives to expand the possibilities of FHIR. There are quite a number of proposals of adding domain specific languages. The most obvious one is FhirPath, which will come in STU3. Ewout has provided an extensive look into it with a Birds of a Feather session. There is now sufficient tooling and API’s available to get you up and running.

There have been discussions to extend FHIR to Swagger or RAML, for which Nicolai Ryzhikov of Health Samurai has done some excellent research (see more below). Grahame spoke about a new language, intended for mapping between different standards.  This mapping language is now part of the proposed STU3 specification. And of course, there is a new resource for it: StructureMap. Bryn Rhodes showed a very mature implementation of CQL for decision support, which could be a candidate for the FHIR specification too.

A small change with a big impact: at the DevDays we broke the data type HumanName. Family will get a cardinality of zero to one! The structure of it is now defined in extensions. This will help countries like Germany, The Netherlands and all Spanish speaking countries.

FHIR Community

Grahame as always gave a very insightful and inspirational outlook on what he thinks of the future of FHIR in the next year. We still do not seem to be on the top of the Gartner hype curve. The FHIR community now exceeds a 1000 people actively involved in developing the standard. Grahame told us that HL7 and the FHIR Foundation are currently developing a certification process for FHIR credentialed consultants. There is also an option for FHIR to go broader, since a lot of the FHIR architecture, services and tooling might have great use outside of Health.

WHO’s on FHIR?

The University of Pittsburg is on FHIR! They have started using FHIR to connect their 1000+ clinical systems. They are even discussing to make parts open source. We saw interoperability at its best with Cerner and Epic on one stage together showing how their infrastructure works together with FHIR.  IBM showed us how Watson integrates with their own FHIR server and how they map between FHIR and HealthKit. Patients Know Best have worked out and implemented a very valuable clean way to look at patient consent and are actively involved in sharing their thoughts with the developers of the standard.


I will start with the tooling. As Alexander Henket nicely put it: traditionally in health there is a shortage of tooling. With the FHIR standard, for the first time, there is an abundance of it.

The build tool for Implementation Guides

In his talk, Lloyd told us that Implementation Guides can now be published independently of the Specification. This is a big step forward, since the ‘build’ of the spec is no small thing. It would take between 25 and 60 minutes.The new tool runs in about 60 seconds. You can find the documentation here. It’s also good news that Implementation Guides that are not maintained by HL7 can nonetheless be published at


HAPI has until recently been a set of API’s that you can build a server with. At the DevDays, James Agnew launched SMILE CDR. This is HAPI server components packaged as a product, that runs on top of database like Postgres, MySQL, Oracle, SQL Server. Of  course still works with HL7v2, where HAPI since long is a big name and includes Smart on FHIR and has monitoring tools and a set of really cool management tools like SMART-on-FHIR apps registration. It’s still work in progress, but James team is pretty far. You can take a peek here.

CQL Compiler

Bryn Rhodes has worked on CQL. It’s a language expressing the logic involved in Quality measures and decision support artifacts. And CQL can now be run against FHIR resources and translates to ELM. Bryn showed us all this with the CQL runner tool.

FHIR schema

Nicolai Rhyzikov from Health Samurai showed a complete Swagger definition for the FHIR REST api. His team has also been working on profiling and validation with JSON schema. See code here. There is also an application here. There is even more. His team has been working on a Test script runner in Clojure.  Mike showed JUTE. It’s a yaml like custom domain language to map HL7v2 messages to FHIR. It has a lot of similarities with FhirPath so they might see how it can be integrated.

FHIR Client for Python and Swift

Pascal Pfiffner from Harvard Medical University showed us their new Python Client for FHIR. You can find the python code here. It has a FHIR parser and even has a good basic Validator. Pascal also showed a FHIR Swift implementation, which you can find here. It has all the FHIR data models and has included the same validation feature as their Python tooling.


Ardon Toonstra showed us all new features of our own FHIR registry. Ardon showed how to find profiles and extensions, but also the whole path from uploading a resource to publishing and render them as a tree table or UML to using that same resource when writing a complete Implementation Guide in the new Simplifier IG editor, with all FHIR rendering tooling available.


Christiaan Knaap from Furore showed the evolution of SPARK that started as one of the first FHIR reference implementation servers to an enterprise grade FHIR server. SPARK has been rewritten on top of ASP.NET Core. It now consists of a several components and a custom API surface, so that it can handle many different scenario’s, like a validation only server, a front end for different databases, like MongoDb and SQL Server, a hub in an existing health infrastructure or a facade for non FHIR systems.


Alexander Henket from Nictiz showed us the FHIR Roadmap for ART-DECOR, and open source multidisciplinary tool stack for authoring and sharing of templates, valuesets and much more. The tooling now has a resource viewer, import/export of FHIR resources. It now collaborates with external FHIR repositories, for starters with and has terminology services. The  plan for coming year is to include basic profile editing scenarios.

That’s all folks!
Hope to see you next year at the DevDays, 15-17 November 2017 in Amsterdam!

Simplifier Connectors (part 2)

In the previous blogpost I described how you could send a resource to Clinfhir using a Simplifier Connector. Today I am going describe how these connectors work and how a connector is made.

Connector are written in Javascript. The script can make use of fhir.js and JQuery. That way you get easy access to any server that speaks FHIR including Simplifier itself. The connector will be run in the browser, which creates a sandboxed situation.

A connector will always have direct access to the resource and to the resource FHIR endpoint on the page from where the connector is started. That way a connector can either ask a different server to look up the resource, or post the resource to that server.

Before a resource is made public, it must go through a small vetting proces, because these scripts can still create vulnerable situations if not monitored.

In your Simplifier portal you get a list of all the connectors you are subscribed to. You can unsubscribe to them or subscribe to a new connector by using the Shop button. That way you only have to deal with Connectors that you are interested in.

The second connector we wrote that I want to introduce to you, is our FluentPathDemo. FhirPath (a specific implementation of FluentPath) is very likely going to be the language for the invariants (busines rules of Fhir Resources in STU3).

Last year at the DevDays, Josh Mandel wrote the first proof of concept FhirPath (now called FluentPath) compiler in Javascript. And Nicola Ruzjkov wrote a FhirPathDemo for it to test it out.

You can now send a simplifier resource to an updated FluentPath Demo.

  1. Go to Simplifier and find an example resource. For example, this one:
  2. Click on the Connect menu and choose “FluentPath Demo”
  3. You can now start typing FhirPath.

With the example resource above, in the FluentPath Demo you can type in


to get all identifiers of the contained resources.

If you type

contained.identifier.where(id = 'DNI')

you would get just the one identifier where the id equals DNI.

If you want to learn more about FhirPath, you can read about it here.

Next week, I will introduce a more complex Connector that calls validation on a different server.



Simplifier Connectors

In our previous blog post, Rien talked about our FHIR registry Today I am going to tell you more about our efforts connecting Simplifier to the REST of the FHIR Community.

When you start with FHIR as a developer, you usually start writing your own FHIR client and connect to a FHIR server. But we believe with FHIR you should be able to do much more. Even if you are not a programmer.

Our thought process started here: we now have a lot of resources from a lot of different projects and teams on, and we have been working hard to give you insight into them. But we don’t want you to just look at these resources. We want you to be able to do more with them. There are a lot of great FHIR tools to be found online where you can do cool stuff, and all these tools need is some FHIR resources.

To work with most FHIR tools, you must provide a resource first. Wouldn’t it be great if you there is a place, where you can store your resource, and you can send your resources to all these awesome tool out there? We hope to provide you with that place.

But what we didn’t want is having to write a new piece of server infrastructure each time that we discovered a new FHIR tool on the internet. So what we did is create the beginning of an ecosystem of what we call Connectors. Connectors are little scripts that connect to another FHIR website. They can be written by anyone. And they can be used by anyone.


I’ll give you a concrete example: David Hay has build Clinfhir is used for the Clinical Connectathons, where  people with a clinical background and no programming experience have the ability to work and experiment with FHIR. In Clinfhir you can create a Patient resource based on a profile.

Here is how you can try out the Clinfhir connector on Simplifier:

  1. Go to the page with a Patient Profile. For example Core Patient:
  2. Click on the “Connect” menu, and then choose “Build resource in Clinfhir”. (you have to be logged in to use connectors).
  3. You will be directly brought to Davids resource builder page, and Clinfhir will fetch the base Patient resource from Simplifier. You can now create a Patient resource instance based on the Patient Profile you chose.

That’s all.

Later this week I will introduce you to more connectors and we’ll explore how you can start writing your own.

FHIR service as a service

After two years of building and improving our FHIR server, we are now slowly entering the phase where we as a company start asking the question how an actual implementation of a FHIR server will look.

Will it just be a REST interface on top of a Hospital Information System, like EPIC or will it survive as a stand alone server where all other systems can safely store and retrieve data? (I must say resources of course). Will it be just a slave to other systems or does it serve a purpose on its own? Will people always want to implement all the endpoints we created? Is there eventually a need for a general purpose FHIR server like we made, or is it sufficient to create a server that only understands a specific (Profiled) situation?

These are not questions with A-or-B answer. It will be both or either depending on where and when. And many of these questions have been asked and answered by everyone building this standard.

But we had to premeditate some answers while making this server. And as a result one choice we made is accepting that our FHIR server is not an application. It can be. But it doesn’t have to be. And thus we are now transforming it into a module. A module that preferably is plug-and-play. Or as plug-and-play as possible.

Although the work is far from finished, our precious Spark FHIR Server application is now little more than a single REST controller. Everything that happens before (routing and deserialization) and after (validation, storage, retrieval, and indexing) is no longer. That’s now just a library.

It allows us to create more varieties: an open test server, a secure server, a specific implementation. A REST endpoint that is just an interface to another system.

And all that we are left with now is little dilemma’s like – is our test server called Spark? Or is it the actual module – or library – or what is this thing now? Oh yeah, and of course that huge pile of refactoring that still in the backlog.