FHIR in Action – How Well Does It Work?

 Two years ago, I was at eHealth week in Athens, Greece, and stumbled upon several other Americans who represented the Office of the National Coordinator (ONC) touting Fast Healthcare Interoperability Resources (FHIR) as a standard that would help move healthcare interoperability forward more quickly than what we have seen over the last few decades.

FHIR has been developed by the HL7 standards organization and among some of its features is based upon RESTful techniques and the Pareto idea of addressing 80% of the most common clinical use cases. At that time (2014), I started a dialogue with some of the writers of the standard and my investigation found that the area of the FHIR standards which addressed medical device data integration had not progressed as far as some other areas (RESTful techniques and less rigidity). I use the term device here a bit loosely as what in the past were hardware devices (self-contained apparatus with sensing, display and other functions) are swiftly becoming software devices with merely hardware sensors feeding software interfaces which provide the display and analyses functions and are modules amongst many other software modules on different platforms.

Regardless of the limited medical device integration capability, FHIR can be an answer to meeting the current trends for device development with mainly software service mechanisms that span many hardware platforms and rely upon internet transmission techniques riding on different transmission frequency mechanisms (mobile, POTS, satellite, etc).

Fast forward two years and while doing some research for this blog post introduction, I stumbled upon two blog posts. One by Shahid Shah that talked about FHIR (amongst other things) for medical device integration into EHRs, his main advice being to decouple medical device integration services with healthcare specific standards from the device itself. The second one was by the one of the authors of FHIR, Graham Grieve, who cautions that FHIR might be in the initial rocket phase of the Gartner Hype Cycle curve. He states the FHIR is a standard and a culture and institutions and vendors need to adopt both in order to ensure FHIR will work.

My interview below with Thomas Buchendorfer of NHS 24 in Scotland details just that: the use of the FHIR standard as an API for integration of patient generated data into their personal health file and their ‘statutory systems’ by working with vendors to innovate and build the interface.

Is FHIR ready for prime-time? There are still a few details to be worked out. As described below, one large healthcare system has implemented an integrated care platform which used the FHIR DSTU 2 standard and oAuth2 at scale as interface standards to their in-house systems. As noted in the previous post/article, healthcare organizations have a large influence over what is developed and marketed. If they specify standards at the interfaces for their acquisitions, then the vendors will comply. As for complete medical device integration mechanisms within the FHIR standard, that has yet to be simplified.

Standards like FHIR can be useful in the development and support of integrated care systems. Integrated care systems are systems that not only provide remote monitoring of physiological parameters, but support patient and other carer personal diaries, requests for social services, calendaring and appointment functionality as well as traditional clinical care services. (The term "carer" refers to various actors involved in the patient's care, to include clinicians, social workers, parents, children, friends, etc.)

The European project, SmartCare, is a project that endeavored to build and provide at scale integrated platforms to provide integrated care services. This project had nine European regions implementing integrated platforms to support a myriad of services. One of the first wave deployment regions was NHS 24 in Scotland. They used SmartCare to develop a ‘Falls’ program to support patients who had fallen or are at risk of falling and guide them to the services available and to help them towards self-management and prevention. NHS 24 also looked at this project as a way to develop an architecture to support the integration of patient generated data into their personal healthcare and statutory systems.

I spoke with Thomas Buchendorfer, Technical Lead for SmartCare at the Scottish Centre for Telehealth and Telecare (NHS 24), in May 2016 about his use of FHIR as an interface specification in developing his system for SmartCare and beyond.

 

Bridget Moorman: Tell me about what you were attempting to do with SmartCare and how that led you to use FHIR in your implementation.

Thomas Buchendorfer: NHS 24 used SmartCare as an opportunity to build a “Falls” management system for patients who had fallen (usually elderly). We wanted to provide them material regarding the services and information we had for patients who had fallen as well as assist them in prevention of future falls. To this end, we provided a person-held file and diary along with links into systems for other types of support. We looked at this as an opportunity to provide a baseline architecture for the inclusion of patient generated data into our healthcare information systems.

In Scotland we have fairly strict security and data privacy regulations, so we wanted to ensure any system we procured and deployed adhered to those. With that in mind, we also wanted to ensure that the ownership of the data was properly accounted for; i.e., that patient generated data was owned and controlled by the patient. We wanted to develop a person-held file and set up a database with an application programming interface (API) so that applications could move data in and out of that database. The API needed to be able to tell third party software how to move the data in and out of our person-held file.

SmartCare was a three year project and we had to balance two things with our implementation: being achievable in the timeframe of the project and being commercially viable. Using a custom API would not meet those requirements. When we spoke with our pool of vendors, we asked which API would be the easiest and which would be better long-term for industry. We all agreed that using FHIR would be best after looking at a long list of options. We wanted to do the right thing strategically even if there was a learning curve and believed that it would not be that much more difficult to use FHIR than a custom solution. In the end, we used FHIR as an application programming interface and data structure specification.

FHIR relies upon specific cases of REST based web services and supports JavaScript Object Notation (JSON) and EXtensible Markup Language (XML). After our investigation, we believed that FHIR DSTU 2 was best used as an API and data specification for a data repository on the internet. We also wanted to take advantage of and use a peer-to-peer integration model that could become production grade.

A very general architecture for our implementation is shown below. We have two domains, internet and statutory and the FHIR API along with oAuth2 sits between them. The statutory domain is data gathered by professionals and is sometimes moved into a national database. Some internet domain data could potentially also be moved to the statutory domain and that is our plan for the future.

Bridget Moorman: What were some of the issues you had when implementing this architecture?

Thomas Buchendorfer: FHIR only addresses about 80% of the use cases with extensions covering the other 20% (those extensions can be defined by the public). We primarily used two of the use cases: an emergency care summary, which has a list of allergies and medications, and a care plan, which initially is a simple list of actions. Social care services are not one of those use cases. We plan to work on that as well and we believe FHIR should look into support for that. Another issue with FHIR was its lack of access control. It is open, so in order to meet our data privacy and security requirements we used oAuth2 for access control. (note: this was a similar finding in a paper by an Austrian group that built an interface with FHIR as a pilot). The easy part was to build the FHIR-HL7 side. Our integration engine took the definitions from the FHIR standard and auto-generated the code. The hard part was mapping the systems on either side of the API. FHIR defines how to “assemble a document,” however, figuring out how to do that so your servers accept the data and do what you want is more difficult. In the end it wasn’t about understanding the standard correctly but how our software worked. Our implementation of FHIR has an open source code base and dealing with bugs and support issues can at times be difficult due to the differing levels of support and tool maturity at this point.  In this case, it was sufficient for us and we could eventually use the server code that we adopted.

Our main functional requirement for this project was to transfer data in and out of a repository according to permissions. As depicted in the diagram above, we have a person-held file (PHF) which is a data repository. One or more web applications can connect to that PHF core. The PHF is owned by the service user and is not considered statutory. In the PHF are some data that is personally collected and some data that is delivered from the statutory sources. Our vision is to have this function as a subscription service. As data travels from the statutory sources to the PHF, the ownership of that data changes and NHS 24 doesn’t have a say regarding that data anymore unless it travels back to the statutory domain.

Even though the PHF is personally held, we at NHS 24 take seriously our duty to ensure that the data is protected, so to mitigate that risk we ensured that the physical server for these ‘cloud’ services resides in the EU and is administered by a vendor who has accreditation for UK OFFICIAL data. We used a Platform as a Service (PaaS) cloud computing model and vendor. NHS 24 then built the applications by contracting with experienced industry suppliers and managed the data on top of the runtime, middleware, operating system, virtualization, servers, storage and networking provided by the PaaS. Essentially, the FHIR interface and the information sharing engine is one of the bridges between statutory systems on internal networks and a public healthcare cloud. The FHIR interface also supports connections between systems inside the public cloud itself.

Bridget Moorman: Can you expand on the issues with security and how you dealt with that.

Thomas Buchendorfer: We see this implementation as a baseline architecture for future linkage of systems from the internet domain to and from our statutory domain, so we wanted it to function similarly to other patterns typical on the internet. We used oAuth2 as the access control and what it does is manage the permissions to make calls on the FHIR API. It asks “who are you?” and then issues a token for access or rejects access based on whether or not the permission was granted. We use an encrypted channel as well. Currently NHS 24 maintains the access control list and the different systems use certificates, however we see this function migrating to the user in the future. The users should typically allow or deny the access to the repository themselves, i.e., asking the question, “Do you permit this application to communicate with the PHF/database?” The different applications require tokens to interact with the PHF. Interestingly, we had some issues with the oAuth2 implementation and debated different flows to get the user experience correct. The client side was easier to implement than the server side. We wanted the user experience to be similar to what they would have with an application like Dropbox, in other words, just like what they were already used to with their other Internet interfaces. We also wanted to ensure integration with other portal accesses (see LivingItUp block in diagram) and wanted to use those delegated access tokens for data sharing through this interface as well. Some of this is still in our plan for ongoing development.

Bridget Moorman: Can you elaborate on your future ideas for this architecture?

Thomas Buchendorfer: NHS 24 has embarked on an effort to ensure that our services are person centered. In order to do this we believe we need to innovatively address how to use technology today and in the future to support more involvement by our citizens. By using the SmartCare project to build an interface to the Internet domain for our services, and by using the FHIR standard as our API, we believe we have positioned ourselves well for future external data sources being integrated into our systems while respecting citizen ownership of those data sources.   As stated before, we used two of the use cases available with FHIR for this particular service. We are planning on using several others for future services, namely, scheduled appointments, more complex care plans and device readings or observations. We have implemented this current interface iteration at scale as of June 2016 with more than 400 users registered on the Person-Held File so far and have capacity for more. We are very satisfied that we have a foundation from which to move forward and see this as a way to work with industry to innovate solutions for the future.

Bridget Moorman: Thank you, Thomas, and best of luck in your future projects using FHIR.

Photo of Aberdeen, Scotland above, copyright Alexandra Starnes at Team Starnes and used by permission.