The HL7 FHIR standard provides a useful model of health and care information, but it is a specification from which a local standard can be built via profiling. It defines models of data and a specification for how to exchange those data via an architectural pattern called representational state transfer (REST). While there are other ways that data in HL7 FHIR can be exchanged, using REST as an architectural pattern means that software using HL7 FHIR for data exchange will read and write to resources that represent something in the health and care domain.

You can read about the RESTful aspects of HL7 FHIR in more detail on the official HL7 FHIR website.

The semantics of that architectural pattern are of reading, or writing, deleting or searching, or doing something else to a resource.

The problem is that health care doesn’t use that semantic pattern.

Read and write semantics

Medical records are immutable. As I wrote in 2017:

Immutability refers to an approach to software engineering in which data are unchangeable. Such an approach is particularly suitable when considering medical records and processes. Indeed, from a medico-legal perspective, all data should be regarded as immutable as it is usually necessary to be able to view the state of the record at any point in time.

Section 5.11, Clinical information system design : Mark Wardle, 2017

Our paper records accumulate. They accrete.

We don’t rip out old information.

New records update and take the place of older records in our decision-making, but those older records still exist.

Of course, most implementations will not actually delete data when when we issue a DELETE against a resource. For example, if we issue a DELETE against a resource representing an organisation in our health and care environment, the underlying software is likely to effect that change by simply marking that organisation as deleted.

So what’s the issue?

It’s that thinking that the model of data that we use to examine, process and make sense of a health and care record is the same as the one that might populate that medical record in the first place.

Different models for reading and writing

The problem is that the modelling of information used for reading is widely different to that information we record as a consequence of the processes of care.

The medical record is not simply a record, but a working tool that helps professionals and patients make sense and reduce the uncertainty about a decision, whether that decision is about an individual patient (shall I have that procedure?), a clinical service (how do we configure our service to best improve outcomes?) or for research (what new knowledge can we gain?).

“You’re a victim of it or a triumph because of it. The human mind simply cannot carry all the information without error so the record becomes part of your practice.” Dr Larry Weed, Internal Medicine Grand Rounds, 1971

In other complex domains, a pattern of command query responsibility separation (CQRS) has been used in which the information models of querying (reading) data are separate from those of creating data.

I would argue that for many situations in health and care, we should build quite different data models for issuing “commands” or “actions” than the data models I subsequently use in order to make sense of the record.

We should move away from REST semantics towards separating how we think about commands from how we think about queries.

For example, I prescribe a drug (an action) and that data model, that domain event, is used to populate a view (a query) of all recently prescribed drugs and provide a flattened ‘view’ of a medication list based on those actions. I am not reading and writing a medication list, but the list is built as a consequence of the actions.

This approach scales well to the medical record, because the medical record should be dominated by reads. That means it is very easy to optimise reading and processing of data differently to the systems that handle writing.

It also simplifies our data modelling work - because we can build clinical data models that focus on workflow and process (our actions), and then separately conceive of the best ways to make sense and view the logical record - quite rightly through different ‘prisms’ depending on need.