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)

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!