Tune in to our new Profiling Academy and become a profiling expert yourself!

By Lilian Minne – At the DevDays 2017, we launched our new product: the Profiling Academy. The Profiling Academy is available for all Simplifier users (free to join) and is meant for anyone willing to learn more about FHIR profiling. We aim to share our knowledge in a way that is easy to digest for all levels of FHIR users: beginner, moderate and advanced.

The Profiling Academy offers short, digestible modules covering one topic each. Each module offers reading material, real-life examples and exercises.  At this moment the following modules are available: Start Profiling, Extensions, Slicing and Best-Practices. More modules will be added in the near future. If you want to follow a module, just click on its name or use the menu in the upper navigation bar.

Profiling academy

Don’t forget to visit the other pages as well:

  • Feature movies: Watch interesting movies explaining some of the features of our products.
  • Helpful links: This page contains useful links when working with FHIR.
  • Meet our team: Get to know our Profiling Team members who are happy to introduce themselves.
  • About FHI: Learn more about our company and how to get in touch.

We are curious to know how you feel about the Profiling Academy. As the Profiling Academy was built using the IG-editor in Simplifier (pretty cool, right?), please leave your comments in the Issue Tracker of the project.

Advertisements

Make your first FHIR client in R – within one hour!

R on FHIR

R on FHIR is the latest addition to our FHIR tool suite. It is available on The Comprehensive R Archive Network (CRAN). R on FHIR is, as you can tell from the name, an R package that supports R users with fetching data from FHIR servers. It provides simple, but powerful tools to perform read, version read and search interactions on FHIR servers and fetch the resulting resources in an R friendly format.

R on FHIR consists of two classes called fhirClient and searchParams, just like our .NET API. The fhirClient provides functions to perform read and search operations and to use the FHIR paging mechanism to navigate around a series of paged result Bundles. The searchParams class provides a set of fluent calls to allow you to easily construct more complex queries. The searchParams class falls outside the scope of this blog, but you can read the documentation on R on FHIR  to learn more about how to use this class. The documentation also includes some examples for both classes.

Step 0 – Install R (and RStudio)

Before we start, we need to make sure we have R with preferably RStudio installed, on our machine. See the links below. For this blog I used R version 3.2 (higher versions will also work, lower I think too, but I did not test that) and RStudio version 1.0.153.

https://www.r-project.org/

https://www.rstudio.com/products/rstudio/

Step 1 – Install and load R on FHIR

FHIR up (first and last pun, I promise) your RGui or RStudio and execute the following  statement in your console:

# This will install R on FHIR from The Comprehensive R Archive Network.
> install.packages("RonFHIR")

Step 2 – Create a new R script

In this blog we are going to write a function which returns an overview of a population based on a postal code. Go to File > New File > R Script or hit Ctrl+Shift+N in RStudio and for RGUI File > New script. Now that we have an empty script we can start writing our function called ‘getAreaInfo’ with the postal code as our parameter. On the first line of our function we create an instance of a fhirClient. Your script should look like this:

# This function load the R on FHIR package from the library 
# where R stores its packages.
library(RonFHIR)

getAreaInfo <- function(postalCode){
 client <- fhirClient$new("https://vonk.furore.com")
}

Step 3 – Searching Patients on a FHIR server

Now that we initialized a client we can start performing a search operation on a server. The most basic search is the fhirClient’s $search. It searches all resources of a specific type based on zero or more criteria. The $search function will return a Bundle as a list containing the found ResourceEntries as a data.frame.  Normally, any FHIR server will limit the number of search results returned. To obtain all results we can use $continue which uses the FHIR paging mechanism to navigate around a series of paged result Bundles. In our script below we used the $search and $continue functions to find all Patients living within the given postal code and return how the genders are distributed.

library(RonFHIR)

getAreaInfo <- function(postalCode){
 client <- fhirClient$new("https://vonk.furore.com")
 
 postalQuery <- paste("address-postalcode=", postalCode, sep = "")
 
 bundle <- client$search("Patient", c(postalQuery, "address-use=home"))
 
 genders <- c()
 
 while(!is.null(bundle)){
 genders <- c(genders, bundle$entry$resource$gender)
 bundle <- client$continue(bundle)
 }
 
 table(genders)
}

Now that our function is complete we can call it from our console, but first we have to tell R to source our code. This can be done with Code > Source or Ctrl+Shift+S in RStudio and File > Source R code… in RGUI. Now we can run our ‘getAreaInfo’ function in our R console.

> getAreaInfo(3999)
genders
female   male 
     1    574

Congratulations! You just created your first function using a FHIR client in R to track the gender distribution in a given postal area.

Finally

This blog only showed a quick example of how you can use R on FHIR. For more details and examples you can always consult the documentation. Feel free to give feedback and join the R on FHIR development at our GitHub page.

We are planning to do a birds of a feather session during the HL7 FHIR DevDays here in Amsterdam. Hope to see you there.

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.

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!

Introducing Forge for STU3

DutchKingWedding

Royal tears of joy at the official STU3 release ceremony

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.

dutch-king-willem-alexander-with-wife-maxima-and-animal-pelt

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:

  1. 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.
  2. 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:

  1. 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.
  2. Limiting ElementDefinition.type.profile max cardinality to 1. This takes away any ambiguity for e.g. code/UI generation.

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.

King-Willem-Alexander-Queen-Maxima-Princesses-Catharina-Amalia

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

Kings day

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. The Furore FHIR team 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 simple.

 

Download Forge for STU3 for free from simplifier.net

Happy profiling and long live the King!

 

Zo waerlijck helpe my Forge almechtig