Friday, August 11, 2023

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 EMR vendor product, the EMR vendor also does not have information and model to represent patient flowsheet, though the reading is represented using Observation resource.

I searched FHIR chat group, there is also no specific implementation guideline on patient flowsheet, thus I have proposed the following design, I welcome comment and discussion on this topic.

1) Use PlanDefinition resource to represent the flowsheet

2) Use CarePlan resource to represent the association of the selected flowsheet to the patient

3) For the Observation resource, use "basedOn" attribute to specify the specific patient flowsheet for the reading submission


Below diagram illustrates the model and relationship between the three resources




2. CarePlan resource

CarePlan resource to represent the specific flowsheet selected for the patient, the "category" attribute will be used to specify this care plan is patient flowsheet.



3. PlanDefinition resource for the flowsheet which can be selected and assigned to the patient





4. Observation resource for the patient flowsheet reading, use "basedOn" to associate wth the patient flowsheet



5. Revised Design after consultation within FHIR community

After discussion within FHIR community, the consensus is that we should use Questionnaire to represent the Flowsheet template.

Below please find the overview of the revised model (Click on the image to Zoom In)




Thursday, May 18, 2023

Leverage HL7 FHIR Operation to achieve the purpose of "Small Functional APIs"

Overview

During the course of design and implementation for API for modern API driven development, various engineers have been asking the gradually of API, how much responsibility each API shall have, and how to balance the initial implementation and ongoing maintenance of the APIs from both API provider and API consumer perspectives. In this post, I will be sharing my recommendations from my personal professional perspective, do let me know your view.

Technology has been evolving, eg from SOAP to RESTful, from monolithic application design to SOA and now MSA, however the underlying design principles remains unchanged, and we can still go back to the decades old design principles to guide modern application design, and API design specifically in this post.

One of the design principles I would like to reference here is the following para from "Basics of the Unix Philosophy"

"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features."

As this quote conveys, the Unix culture centers around small and simple tools that can be combined. This advice still rings true even after more than 45 years later when we deal with API design and development. To adapt this principle to API design, we may say,  "Make each API do one thing well".

Benefits of making small functional APIs

So what's the benefits of adopting this API design principle, there are three benefits according to this books - Building Secure and Reliable Systems

  1. Design for Understandability. 
  2. Design for Least Privilege 
  3. Design for Resilience 


Design for Understandability

It is much easier for API consumer to understand the API as it is small functional API, it has very specific functional responsibility, it has very specific input parameters and expected response. It is also easier to API provider to rollout new API faster and safer since it does not involve the changing of existing gigantic API

Design for Least Privilege

Each API can be enforced specifically to allow certain API consumers to call, this can be easily enforced at the typical API Gateway products. In contrast to very coarse grained API, this can not done, as API gateway will not be able to go into the API payload to check whether a certain API consumer is allowed to call or not, also if the API gateway starting to go down to this level of detail, then it also embeds the business specific logics, it will complicate the API gateway management and maintenance

Design for Resilience

Wth each API only serve for specific functional responsibility, we can also control the blast radius. When things go wrong, only the specific APIs are affected, thus only specific functional areas are affected.


How to design small functional APIs


However "great power comes with great responsibility", to reap the benefits, we need to take extra care to have good design in place, to ensure the API design is consistent and scalable across many different small functional APIs.

Luckily we do not need to start from scratch, HL7 FHIR also defined capability for standardised, consistent and scalable way of designing small functional APIs, this is the Extended Operations on RESTful APIs.


I will cover the use of HL7 FHIR Operations capability in next post, stay tuned!

Thursday, August 11, 2022

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
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! 

Monday, May 23, 2022

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.



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




Tuesday, April 8, 2014

HL7 FHIR Partial Update

Below I summarized what I have tried so far for handling partial update in HL7 FHIR.

1) Syntax

URL: http://[server]/[resource]/[logical id]/_delta
method: POST

I did not use PATCH method since some of older browser does not support this method, also not sure whether PATCH method has been supported in all javascript library

2) Extension element to specify update mode

For each element to be added/replaced/deleted, added the following extension

       <extension url="http://hl7.org/fhir/Profile/iso-21090#updateMode" >
            <valueCode value="A or R or D" />
        </extension>

As an example, below is the XML snippet for updating birthDate

 <birthDate value="1970-03-13">
      <extension url="http://hl7.org/fhir/Profile/iso-21090#updateMode" >
            <valueCode value="R" />
        </extension
>

  </birthDate>


3) Handling collection

For collection data elements such as name, address and contact in Patient resource, server needs to know which element within the collection is to be replaced/deleted. So I decided to pull collection element's internal id as part of the query response, and then use the same id when submitting the payload to server

- Added collection element internal id in query response as part of element extension

    <telecom>
        <extension url="http://hl7.org/fhir/metadata#id">
            <valueString value="1308"/>
        </extension>

        <system value="phone"/>
        <value value="68181256"/>
        <use value="home"/>
    </telecom>

- Payload for partial update
      <telecom>
            <extension url="http://hl7.org/fhir/metadata#id">
                <valueString value="1308"/>
            </extension>

            <extension url="http://hl7.org/fhir/Profile/iso-21090#updateMode" >
                <valueCode value="R" />
             </extension>

           <system value="phone"/>
           <value value="68181256"/>
           <use value="office"/>
    </telecom>


4) Suggestion

The above approach works okay so far, however I'd like to make one suggestion here. As we can see from the above XML snippet, the content is very verbose after adding extension elements.Can we add the two attributes (id and updateMode) in FHIR resource as part of Element built-in attributes? In this way, the content will be very compact as the following snippet shows,

     <telecom  id="1308" updateMode="R">             
           <system value="phone"/>
           <value value="68181256"/>
           <use value="office"/>
    </telecom>


Tuesday, November 12, 2013

Open source implementation of HL7 FHIR persistence

After I presented the journey from HL7v2 to HL7 FHIR during HIMSS DHW 2013 few weeks ago, the slide is here Use of FHIR in next generation healthcare product for reference, I started to think about how easy it is to implement native FHIR based RDMBS storage, so that the FHIR resource can be natively stored in RDMBS and users are also able to directly query the data using SQL. There are some existing open source implementation, but as far as I can tell those implementations are using document based storage such as MongoDB, data reuse and extraction for reporting and other usage might be problem.

It is not as straightforward as I have initially thought, I need to explore different ways of persisting FHIR resource into RDMBS such as

1) Whether it is possible to just generate O/R mapping without changing the existing FHIR resource java classes. For this issue, the initial assessment is not 100 percent possible, I intend to compile a list and feed back to Grahame for consideration.
2) Whether to store patient name as JPA embeddable or entity
3) How to handle nested collection, such as List<CodeableConcept> since CodeableConcept object itself contains list of Coding object. or List<HumanName> where each attribute such as 'family' attribute is again a collection of String object
4) With nested collection, is it possible to query such attributes at API level. For example I already encountered some problems when I tried to query collection attributes within embedded table as even the latest JPA 2.1 spec does not support such implementation yet, as a result I have to go back to change the O/R mapping approach



Though it is still in early stage of exploring and trying out, I think it might be useful experience to share with other like-minded developers who might be keen to explore the same to create FHIR based persistence similar to HL7 RIMBAA concept, so I decided to make it as open source project, the project is hosted at sourceforge http://sourceforge.net/projects/hl7-fhir/

The scope of the project is illustrated below,  the reference implementation uses eclipselink 2.5 which is based on the latest JPA 2.1 spec,  database tier is using hsqldb as reference.




Once I have finalized the O/R mapping approach, the next step is to come up a XSLT to auto generate all the JPA O/R mapping based on FHIR XSD

So do stay tuned, and let me know if you have any feedback or have the intention to contribute to this project!

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...