Sonntag, 14. Dezember 2014

Setting the campus on FHIR

I am regularly teaching at my alma mater, the University of Heidelberg/Heilbronn University's faculty for medical informatics. My class aims to offer a "hands on" interoperability course teaching students not only about communication standards in healthcare but also how to deploy them in real live scenarios.

Without access to a heterogenic medical software landscape as it is usually found within a hospital's infrastructure it is difficult to give students an idea of what is going on in the trenches of healthcare interoperability.

But with a Cloverleaf Communication Server sponsored by Health-Comm on premise, it is possible to simulate message flow between different systems, allowing the students so send, receive, parse and convert HL7 Version 2 messages, CDA documents, proprietary CSV data - you name it, we parse it - set up their own virtual networks and thus get the full monty of interfacing fun rather than just reading HL7 specs or flipping the pages of IHE integration profiles.

With the introduction of FHIR however, a whole new world of opportunities opened up. For the first time it is possible to not only touch interfaces from the middleware's point of view but also to let students craft their own applications and interfaces and let them fly - for real, without exceeding the courses tight time frame.

Why is FHIR such a game changer in education?

  1. The FHIR Resource structure allows narrowing the scope of a project down to a few or even just one resource depending on the project's time frame. 
  2. The documentation of FHIR is very complete, well structured and offers a lot of examples. It covers the whole spectrum from reading general introductions to highly technical specifications while at the same time it allows for "cherry picking" by reading only those parts of the specs that are relevant to the project's scope, so the vast volume of the specification does not overwhelm the students.
  3. There's a huge community out there that willingly supports any student seeking help. 
  4. There are many open source projects, libraries and sample implementations students can use for reference. There's even a selection of FHIR server implementations that can be deployed on premise allowing the students to concentrate on the client side implementation and still be able to set up a complete network for their project.
  5. The availability of public test servers allows students to work and test independently from one another and independent from a connection to the project's own server. 
  6. Testing is easy. Students can validate their XMLs against schemas, use the public server's validation tool, use rest clients (e.g. Postman) to simulate transactions and thus regularly check whether their part of the project is on track.
In order to prove my point I threw the following challenge at my students (Despite all the FHIR enthusiasm, starting off and ending the use case with HL7 Version 2 was an important factor to keep the project anchored in the present tense):
  • Use Cloverleaf to create a FHIR Patient Resource from an V2 message and post it to a server
  • Deploy a Open Source FHIR server of your choice on premise and learn how to configure it to suit the project's needs
  • Create a very basic JAVA Application (FHIR Client, based on HAPI) which connects to a FHIR server and provides a GUI for displaying, searching, editing and adding Patient resources.
  • Use Cloverleaf to create a RESTful query from an V2 Message an retrieve a Patient Resource from a FHIR server.
  • Use Cloverleaf to translate a Patient Resource into an V2 Message
  • finally: let's throw the individual projects together in our own little Connectathon and see if we can bring Cloverleaf, FHIR Server and FHIR Client to talk to each other and pass the patient data from V2 to FHIR server, display and edit it on the FHIR client and retrieve it from the FHIR server by V2 Query.

Frankly, I had my doubts. Would the students be able to grasp the concept of FHIR with hardly any prior knowledge to build upon and only three weeks of time to cover the whole project? Would the open source tools, servers and libraries who's beta version warning often read longer than the whole documentation allow to simply be deployed and used without any in-depth knowlede of the code? And finally: Would my old WiFi router be able to lift the task of being a Connetathon's backbone?

Whether it all worked out as planned or the whole project blew up in my face will be reported in detail right here soon. Stay tuned...