Saturday, October 9, 2021

Make use of HL7 FHIR to modernise our digital application platform

When there is change in business need, the change in application is inevitable. From application design perspective, the key is how to design the application so that we manage the ongoing change efficiently, and make our life less worry and happier, we can either 

1) Perform "Full body surgery" to change every part of the application, that leads to longer time for development and testing, more artefacts to deploy, and tends to have more bad fix. or

2) Structure the application framework so that the change is contained within a specific area of the application so that the change is faster, the testing is faster, and deployment is faster


Typical development approach

When development starts, in the typical development approach, frontend developer and backend developer work on the following two activities before defining the structure and format to expose APIs to frontend.

1) Understand  and analyze the business requirements, so that we understand the data elements and format of each data element for the respective functional module

2) Define the data model, how many database tables and table columns, and what’s the relationship of these tables

3) Understand and analyze the application UI requirements, understand what data is required on each UI screen, where all these data come from,  and how the data is presented on the UI

If any of the above information is not available for us, we are kind of “stuck”. Also if any change on backend requirement or frontend requirement changes, we have to perform surgery to the whole body. When you perform full body surgery, there tends to be a lot of bad fix in addition to the extra time spent for development and testing.

1) Database access logic to cater for new data elements, how to save, how to retrieve

2) Backend API change to expose the new data elements in the API

3) Frontend integration needs to change to retrieve new data elements in the APIs


How we use HL7 FHIR in our platform
1) FHIR based data model (Relational DB store or NoSQL data store) – We do not need to figure out how to design our data model, and how to manage the persistence and query. What we need do is to figure out is what data value we shall constrain for the data element eg what is the list of valid status code for appointment.

2) FHIR APIs for external system integration, and APIs for frontend components to call – We do not need to spend time to brainstorm on the structure and data elements for the API payload and the syntax to call the API. What we need do is to define the business operation for the API eg shall we allow book appointment and reschedule appointment, and which part of the API payload is required

3) The platform also supports fully custom designed data model and workflow plugins to handle business logic enforcement
 

Key benefits

1) Since all backend APIs are standardized to follow HL7 FHIR APIs,  we can implement reusable component to handle frontend-to-backend integration, do once and use for ALL backend services that conforms to HL7 FHIR APIs

2) Both frontend and backend developers can independently work on the respective development

a) Frontend developers can use any external HL7 FHIR public server for development and testing on the frontend UI component

b) When backend API is ready,  frontend developer just needs to configure the backend APIs to the new URL

3) In the situation where there is new data element to be shown on UI, only change required is frontend UI component – where to display, and how to display. (Assuming no special business logic handling of this new data element at backend)


If you are interested to be part of this exciting team and journey,  do submit your CV to join us




No comments:

Post a Comment

How to model Patient flowsheet in HL7 FHIR

1. Overview Recently I am working on the HL7 FHIR information model to represent patient flowsheet for the purpose of integration with one E...