The FHIR Standard : «healthy» choice for a startup ?
We started Lifen in 2015 with a simple mission : improve communication for Healthcare professionals. As you could imagine, things were quite simple at the beginning : we had a web app plugged into a single backend connected to every communication channels (secured emails, messaging platforms and even postal mail). From a single app, doctors were able to send a report to every single healthcare professional in France. As we were rolling out the first version of our app to physicians, we’ve come to realize that integration with other software would be critical. At the same time, a first partner came to ask us to integrate our services with an API.
Sooner or later, we knew that we would have to create an API, but we did not realize it would come so fast. After a few weeks trying to reinvent the wheel, the choice of an open standard quickly became obvious for our API.
We chose FHIR, which is a draft standard describing healthcare data formats and elements. To understand the FHIR modeling, you can compare it to a Lego Game : all basic bricks (called “resources”) are available to you. You can easily map the most complex concepts by combining and arranging them. Built on top of this model, FHIR includes an application programming interface (API) for exchanging electronic health records as long as an implementation guide describes precisely how to interact with a resource.
At the end of 2016, our first FHIR resource was born. And today, we want to share the rights and wrongs of our 2-year experience with this standard.
The benefits of FHIR
“Follow your instinct”
Even though the word « FHIR » is starting to buzz in HealthTech events, it was not really the case in 2016. When you have to convince stakeholders to be a part of the FHIR story, you first think about the key-word “draft”, which means “specifications in progress” — not really reassuring. Moreover, when you have a very simple use-case (eg. sending a document from A to B), the full FHIR specification may seem disconcerting.
Fortunately today, the success of FHIR is represented by tech giants :
- Apple is still moving towards patients, and has made all of its health apps FHIR-compatible.[1]
- Google focuses on Artificial Intelligence and has open-sourced an implementation of a protocol buffer for the FHIR standard[2]. They recently announced a Google HealthCare API with connectors to many health standards including FHIR (beta access not yet delivered).[3]
- Amazon and Microsoft Azure are building infrastructure layers linked to a FHIR-Server with HIPAA Compliance. [4]
We have also met with some major French hospital groups which have implemented an identity server in FHIR. We are not the only ones anymore and the entire ecosystem has adopted this new paradigm.
“The only way to win is to learn faster than anyone else”
While building a minimum viable product in the risk-averse sector that is health care, we have tried (and given up on) a lot of features before we found the ones that stand out. The first database modeling phases are always critical for a startup because you want to both go fast and plan for the future at the same time. The key advantage of the FHIR standard is that it’s based on years of healthcare expertise. Look for your concept in the specification, and you’ll just know how to implement it. It allows you to focus on real value-added features (security, user experience, performance…).
Like any other startup, we often come across edge cases that are specific to our business and not modeled in the standard. Fortunately « FHIR » comes with a handy model of « Extensions » that enables you to customize it to your needs.
Once the modeling is done, FHIR lets you implement the solution faster with a lot of open-source libraries (we are currently using FHIR clients in Python, Javascript, Ruby, Java & Go).
Internal communication is also much easier : this model brings us a common & precise language to talk about existing & future features. With FHIR, the number of our data model objects shrinked from 28 to 7 while we continued to ship new features every week.
FHIR challenges
Time to rebuild !
The first implementation of the FHIR API was based on our custom backend and a mapping layer to FHIR standard. The business mapping was quite simple. Yet, our web developers started to ask for more API features : new filters, pagination options and other complex API actions. Hence, developments on the FHIR server became real blockers for the evolution of the product. The time to rebuild our back end from scratch had come. Even in the context of a small, agile, 2-year-old startup, the project was a real challenge. We had to build a brand new FHIR Server while guaranteeing continued customer service. It’s hard to imagine the workload of a similar migration in a 20-year old hospital system with millions of patients. Let’s hope this will not be a barrier for the transformation of digital healthcare in the world.
Interoperability ready ?
Using FHIR to model data exchanges between our proprietary apps is a first milestone. But is it ready to be used to connect to actual hospital IT ? Well … so-so.
First, we’re way ahead by using FHIR in a Production environnement and all of the french FHIR use cases are still being developed by the HL7 France organization [5].
When we discuss new integrations with other healthcare vendors, developers crave for new web standards such as FHIR but the lack of clear short-term business incentives makes it hard to convince executives. Indeed, most hospitals are not yet using FHIR, so building a new connector will not bring in new customers in the short term.
Still, the FHIR foundation specified mappings with older standards currently in use to save some integration work.
Are open-source libraries bullet-proof for production ?
If you thought about using one of the many librairies available, be careful of their level of maturity. For example, we’ve seen many librairies with no security layer or with no performant search engine. For us, it has been a long and challenging task to implement the server with our strong technicals requirements.
Today, we are proud to offer a FHIR server fully compliant to French regulations for healthcare data storage. Moreover, this server includes two essential parts for building a new ecosystem : a healthcare directory & an oAuth system to strongly authenticate all health care professionals in France. [6]
Many like-minded startups have already joined us on our mission to promote the FHIR standard. Let’s make a difference in healthcare interoperability : join us on this journey !
