I have been a Data & Business Intelligence professional for over some years in the healthcare domain in New Zealand.Thus, I once got a brief opportunity in 2019 to work on a master data management project addressing the need for an index with FHIR APIs for health professionals nationwide, which could bring some consistency in healthcare providers’ data across multiple systems by various vendors. That was my beginning with the fascinating FHIR world and the exciting history and current development of data exchange standards in health informatics.
This blog series is my attempt to share my learnings and experience with FHIR so far. I want to share what it takes me to build an FHIR server and why we prefer Laravel as the web framework to orchestrate FHIR APIs. I am open to criticism and suggestions as they could guide me to build the most comprehensive EHR ever :)
In the Beginning
Post-2019, my entrepreneurial endeavours landed me with the problem of capturing an individual’s external & internal digital footprint under private ownership. It was a vague concept to begin with that needed a lot of research to evaluate feasibility, viability and desirability of such solution. Thanks to my past introduction to FHIR, I started classifying possible digital footprint categories as FHIR resources . For example, the Observation resource type is recommended for Vitals; with vitals and internal health data points, I also added air quality data around you at a given instance as an Observation.
I am working on the digital footprint piece as R&D in the side hustle and will share more with time. For now, I can say this project gave me reasons to think about building an FHIR server. One thing led to another, which I will cover in another blog, and to avoid vendor dependency for my flagship product Venus Smart Card, I ventured to build my own FHIR server. To understand FHIR, I followed the learning path lined out here and found the recommended book “Practitioner’s Guide to Health Informatics, by Mark L. Braunstein,” an eye-opener in terms of history, challenges and the complex nuances of healthcare interoperability; many things at play here, my friends!
APIs before Interoperability Standards
With a team bundled up in July 2021, we started to build a Minimum Viable Product for Covid-19 Bubble management, namely Venus Smart Card. I got a team of experienced software engineers and developers from a non-health informatics background to build an FHIR Server. The idea was to create a basic solution with some utility and add FHIR APIs later to train the team on each component of FHIR implementation and its significance.
Keeping aside the overwhelming dimension of health interoperability standards, at its core, FHIR is nothing but a bunch of APIs already defined for us to consume with necessary amendments rather than building vendor-defined APIs from ground zero. Thus, from the tech perspective, the best place to get started with FHIR is to first start with the basics of APIs. In my journey to understand FHIR, reviewing the concluded best practices of API design and implementation was proved to be a good start before jumping into FHIR API with standards. APIs on their own is a profound subject with a lot already done and written for us; however, I find this concise online guide handy for a quick overview of the basics of APIs.
Sensitive Security
I was transitioning from the data and BI world to back into the Software engineering space where I started initially years ago. But, I was new to web applications and thus, nervous about the security component and one more steep learning curve to climb. Experienced geeks in our team recommended Laravel as a web framework to implement FHIR APIs for a good reason. Around the same time, a consulting paper on FHIR security by Alissa Knight was released. I couldn’t ask for the right timing for a report focused on FHIR security. It was great to see how the FHIR community received the paper and responded to it. The conclusion of the paper and the entire discussion around it was about ensuring best practices of API securities applicable to any mission critical API implementation. There is nothing in-build in FHIR API standards itself that makes it weak on the security front.
What’s Next
In the debate sparked from the paper, The creator of FHIR Grahame Grieve recommended dealing with OWASAP top 10 risks to ensure robust security of FHIR implementation. It was a tremendous learning experience to evaluate the API security features and possibilities in Laravel to minimise security risks highlighted and kept up-to-date by the OWASAP foundation. With the first project secured to implement our homemade FHIR server, I will endeavour to write about the security evaluation exercise of Laravel framework, our FHIR project , and the real-world challenges of implementing a FHIR server.