UCL IXN & GOSH FHIR ToolSuite for
Healthcare Developers on Azure

Anthony Cheng, Vojtech Adam, Carmen Ibanescu, Yutong Wang, Junda He, Abhinath Kumar and Suyash Kabra

Introduction:

The UCL team that worked on the ToolSuite project, enabling more opportunities for developers to quickly and efficiently develop healthcare applications.

From left to right: Anthony Cheng, Vojtech Adam, Carmen Ibanescu, Yutong Wang, Junda He, and Abhinath Kumar

Special mention to Suyash Sudhir Kabra for contributing a number of tools for the platform.

 

Our Challenge:

With the complexities surrounding the non-standardisation of data across medical systems, standards such as FHIR and SMART have been introduced to maintain consistency of patient data. However, such standards are complex and difficult to work with and some tasks are repeated across multiple applications, which not only raises the barriers to entry for budding healthcare application developers, but also slows down the development process for applications with similar features.

 

Our project aimed to further drive the development of healthcare applications by providing a set of tools to help abstract away the complications involved with healthcare data. Healthcare data is not standardised between hospitals and developing one application to work with multiple systems is difficult to do without significant customisation. ToolSuite is the proposed platform that provides tools to any healthcare application developer, making development simpler and easier to integrate with existing medical systems.

 

Our Approach:

The project primarily focuses on two areas, the ToolSuite platform and the tools themselves. More specifically, what should the platform look like, how should the platform support tools, what kinds of tools would be impactful, how should developers use or implement such tools, and more importantly, how should the platform and tools be brought together to provide the best experience and workflow for developers.

 

Discussions with FHIR developers and our own experimentation with FHIR and SMART highlighted multiple issues, most notably, the learning curve of what these standards were, and how developers could retrieve relevant data from FHIR servers. There is by no means a lack of documentation, in fact, the reverse is true. However, it adds multiple layers of complexity that would-be developers would be deterred by, and even simple tasks such as retrieving blood pressure would require going through numerous documents and some trial and error before arriving at an acceptable solution. From this, it was decided that our first tools should consider data retrieval, using universally known formats such as SQL or JSON, and to convert such queries into the format required by FHIR servers.

 

What about the platform? The platform has to ensure that all the tools that we create are available, just like in a catalogue. Furthermore, it has to ensure that tools that other developers could create are supported across multiple languages, with supporting documentation outlining implementation strategies and uses, whilst remaining simplistic in nature. It was decided that tool developers should upload documentation of their tools and tools to the platform, with tools being used through API calls, providing the most simple “plug and develop” infrastructure that all developers can use to get started with healthcare app development.

 

Our Solution:

ToolSuite is the proposed web platform that serves a range of tools that aims to abstract away the complexities of working with healthcare data when developing software for the healthcare sector. It provides developers with necessary documentation that allows the tools and their functions to be integrated in their applications; and allows developers with more experience working with such standards to propose or add more tools to help others with their healthcare applications.

Fig 1: Overview of the ToolSuite Platform

 

The web platform was built using React as the frontend and NodeJS as the backend with details and documentation associated with various tools being stored in PostgreSQL and MongoDB databases respectively. These components are hosted on Microsoft Azure Web App Services, Azure Database for PostgreSQL and Azure CosmosDB respectively. Each tool that was available is hosted using an Azure Function, the serverless computing service, allowing tool developers to code in a variety of languages, whilst allowing any other developer to integrate the benefits provided by the tool using any programming language. This is done through an API request to the tool, allowing the computations or functions to be carried out in the cloud with the results being returned back to the developer’s application.

Fig 2: Deployment View of ToolSuite

 

With a project as large as this, it is essential to have a pipeline that automates builds and deployments so that more focus is put on the quality of ToolSuite. Azure Pipelines provided the necessary infrastructure for us to implement continuous integration and delivery, and combined with its deep integration with GitHub, made builds and deployments easier, quicker and effortless.

 

In addition, we present the three tools that were uploaded to the platform, JSON to FHIR, FHIR to JSON both developed by Suyash Kabra; and SQL to FHIR, developed by Yutong Wang and Junda He.

Converters

For developers who have never worked with medical data formats or FHIR, the learning curve can be steep. To help make it easier for the developers to use FHIR without having to learn about it, two converters were created, one that creates a FHIR resource and another that extracts relevant data from it. The goal is that with both the converters, a developer can read observations from FHIR and send data to FHIR, which are the two most basic and used tasks, with ease and without having to worry about learning how FHIR works and is structured.

JSON to FHIR

The idea for this converter is that the developer will only send basic data for an observation such as the patient ID of the patient who the reading belongs to, the date the reading was taken, the type of reading like blood pressure, heart rate etc and the reading value. All this would be sent in a simple JSON format (which is predefined and available to the developer). The converter would then create a FHIR Resource for that observation and the developer could then post the FHIR resource to the FHIR server. In this whole process, the developer did not need to know anything about how a FHIR resource looks like and they would just need to know the JSON schema format which is pre-defined.

FHIR to JSON

The reverse direction of the converter extracts the main information such as patient ID, date of reading, reading type and reading value from a FHIR Observation Resource.This ensures a participant can read data from FHIR without having to learn about how a FHIR resource looks like and how to navigate it. In general, FHIR is very nested and the reverse converter tries to flatten it out and extract the most important data required.

Example

Below is a sample Blood Pressure FHIR Observation Resource. This template is not very intuitive for newcomers and would require spending hours to understand what the fields mean and how they should be generated and also how they differ for different observation types.

Fig 3: Example Blood Pressure FHIR Resource

 

To create the above FHIR resource, a developer would instead just send the JSON data (Fig 4) to the JSON to FHIR converter and in return get the same FHIR Resource as above. It is a lot simpler to understand and use.

Fig 4: Example JSON input for JSON to FHIR converter

 

If a participant had the FHIR resource (Fig 3) and wanted to extract the crucial data from it, the response from the FHIR to JSON converter would be as shown in Fig 5. As you can see it's in a simpler, clean and smaller format and the data is not nested and easy to parse.

Fig 5: Example JSON format of data extracted from FHIR resource

 

SQL to FHIR

The idea for this tool revolves around developers knowing how to use or create SQL queries to insert or retrieve data as required. As a result, by entering a typical SQL query, this tool would convert it into the relevant FHIR query that can be used against the FHIR server. The tool was developed using Java and requires two parameters, a SQL query, and the FHIR server URL where data is located, for the conversion to occur.

Deploying the ToolSuite to 100 developers at the GOSH FHIRWorks Hackathon 2020

The GOSH FHIRWorks Hackathon was organised by GOSH DRIVE with 146 computer science students at UCL taking part in support of open source initiatives for the NHS.

As a means of testing the capabilities of ToolSuite, the service was launched into production to help participants of the GOSH FHIRWorks hackathon. To support the students, GOSH DRIVE hosted a FHIR server (done through Aridhia DRE) on Azure through the Azure FHIR API to be used by the participants at the hackathon. The server was also pre populated with synthetic patients and patient observations so that the participants would have some data to use.

 

On the ToolSuite platform, three tools were made available, including JSON to FHIR mapping, FHIR to JSON and SQL to FHIR conversion tools. Based on feedback gained from users and metrics or logs obtained from Azure, the service was successful at handling all requests made, and no disruption, downtime or errors were reported. It was simple, intuitive and offered flexibility for developers when it came to deciding what tool was best suited to their use case.

 

Deployment of the Converters for the Hackathon

To allow the developers at the hackathon to use the two converters, each converter was hosted to its own Azure Function. The developers would then use REST APIs to call the converter they wanted sending the required data in the body of the API call.

 

Each direction of the converter were just python functions. Instead of developing a webserver to host the two functions and then host the web server on Azure, Azure Functions already provided the same functionalities as the above. It also provided auto scaling, load balancing and live analytics to see if there were any problems with the converter and see how the developers were interacting with the two converters. Also hosting the two functions onto Azure functions was very quick and easy, hence why I decided to use Azure Functions.

What Does ToolSuite Mean For Developers & Hospitals

ToolSuite and the converter tools that were created forms the basis for future SMART on FHIR application development. New developers can easily get started with healthcare application development without having much knowledge of how FHIR actually works. Existing FHIR developers can expect to push out more applications or even higher quality applications using the ‘plug and develop’ infrastructure that our platform provides, abstracting away the complexities of dealing with FHIR, and reducing the need to rewrite code for typical functions.

 

Hospitals on the other hand, will see the benefits of applications that were created through the platform. Through enforcing consistency across applications in how they access data, what data is accessed and how to interpret such data, hospitals will be able to download and use an application with the guarantee of it working straight away on their system. There is no need to customise each application for each hospital, and allows more applications to be introduced without much overhead, enabling medical professionals greater access to patient data and their respective statistical analysis, so that they can make better informed decisions with their patients.

The Future

There is much more room for expansion of the ToolSuite platform. The full automation of the inclusion of community produced tools to the platform is essential to ensure that new applications can benefit from new ways of representing or interpreting information that is critical to making informed decisions from a medical professional’s perspective. A community whose applications are based on tools hosted by the platform will provide the foundations for more innovation in the healthcare sector by means of information sharing or the introduction of new technologies and methodologies, reducing the barriers to entry to healthcare application development.

 

As more healthcare applications are created, requests to the current infrastructure will increase and affect performance, bringing the development of an offline SDK into account. In

contrast with our current API service for tools, a local SDK would provide a more stable and

smoother integration service These proposals will help further automate the process and eliminate the inconsistencies and incompatibilities between various implementations, massively extending the development opportunities to a wider developer community, and the creativity, quantity and quality of healthcare applications.