Use HL7 FHIR API to achieve greater productivity for frontend application development

HL7 FHIR API is modern RESTful API with JSON data structure, it not only defines the payload format, it also defines the API syntax eg HTTP method, URL path and query parameters. It has been adopted by EMR vendors to promote interoperability between different healthcare systems.

The original intent of HL7 FHIR when it was conceptualised back in May 2010 HL7 WGM is to create next generation light-weight interoperability standards to replace the previous SOAP/XML based integration standards, however gradually the industry recognised that this lightweight RESTful/JSON based API standards also fits extremely well for internal backend APIs to be called by frontend Web Applications such as ReactJS based SPA (Single Page Application)

In today's post, I would like to share how HL7 FHIR API dramatically simplifies the development for ReactJS SPA and increase development productivity,

1. Create a reusable component for backend API integration
2. How the UI component will call the reusable component to retrieve the data

I am going to share with you a demo ReactJS application to demonstrate how easy it is to achieve the above two objectives.

The demo ReactJS application is hosted at the following site - https://muqhwj.csb.app

Pls take note that the intent of the demo app is NOT to demonstrate the good design practice of ReactJS SPA, eg I did not use TypeScript in the demo yet, the configuration is not maintained in external configuration settings etc. I only spent 1 or 2 days to put up the demo ReactJS SPA.

The demo application shows whatever health records available in the backend system with a simple UI design - summary view and detail view. There is only one API component and one UI component 

1. All the backend API integration is coded in this API slice - https://codesandbox.io/s/muqhwj.... 
   1. I use the method - getResourcesEntries for getting ALL kinds of resources (other than Patient record) and also do transformation from backend process API to experience API for the Summary View (I moved the included patient resources into respective patient data resource eg Condition under the element "_includedPatient", so that it is easier for UI to render the data). 
   2. The second method is getResourceDetail which is to get the detail payload of the specific record for any given type of resource for the Detail View
2. The UI layout is implemented in these two files
   1. Summary View - https://codesandbox.io/s/muqhwj.... 
   2. Detail View - https://codesandbox.io/s/muqhwj.... 

If you want to try out yourself, you can fork to a new project, and then try to modify these files to add additional record type to be shown in UI, or update the data elements to be shown for each record type

1. Add new record type and corresponding menu item name in this file - https://codesandbox.io/s/muqhwj?file=/src/app/Navbar.js
2. Add/update data elements to be shown for the corresponding record type - update function resourceSummaryElements in this file - https://codesandbox.io/s/muqhwj...
3. Also you need to point your own FHIR server, please modify the server setting in the fhirAPISlice.js - https://codesandbox.io/s/muqhwj?file=/src/api/fhirApiSlice.js

Happy coding and have fun! 

Automated API implementation and documentation

In the traditional development approach, development team generally follows the below 3 steps to design API and maintain API documentation

1. Design and implement API
2. Generate Swagger file for API spec
3. Develop and maintain API documentation in Word document, include the generated Swagger file, and list out the APIs and corresponding request & response payload structure for ease of readability

One most frequently occurring issue of the above process is that the API documentation in step 3 tends to be out of date after the initial application release. At beginning the team will diligently spend time to develop the documentation, however after a while, due to tight project schedule and developers lacking time, the documentation will be out of sync with the actual APIs since every minor change may involve manual updating of the documentation.

When I worked on the recent project for implementing next generation healthcare digital platform, we adopted HL7 FHIR for the API design, we also make use of HL7 FHIR CapabiltyStatement resource to have automated way of designing API and keeping API documentation always in sync with the actual code running in the system

1. Use CapabilityStatement to define the API and request & response payload structure based on requirements
2. The CapabilityStatement will be part of the application source code. During CI/CD, the build/release pipeline will generate the corresponding Swagger file from the CapabilityStatement resource, and publish to API documentation web site
3. The API documentation web site loads and renders the newly designed APIs using RapiDoc.
4. The newly designed API will be automatically made available when the application is loaded with the updated CapabilityStatement

Below figure describes the approach we adopted to achieve the following two benefits

1. The API implemented is always in sync with the API designed
2. The API documentation is always in sync with the API implemented and running in the system.