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.
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 fhir.org.
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.
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.
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 Simplifier.net: 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 Firely 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 Simplifier.net 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!