This is a talk I gave at the re-Clojure 22 technology conference in December 2022:

Clojure is a programming language that is a dialect of Lisp, but none of the concepts here require the use of Clojure as a programming language. Rather, this talk is more about learning from some of the principles behind Clojure, and functional programming languages generally, and internet-era software architectural design, to re-imagine the software we use in health and care.

Introduction

In this blog post, I argue that we must transform the way we perceive and use electronic health records (EHRs). By employing the principles of Clojure and reimagining the EHR, we have the potential to turn this essential tool inside out, unlocking its full potential, and support a health and care system designed around the needs of patients and professionals.

Traditional EHR vs inside-out thinking

To begin, let’s understand the traditional or conventional Electronic Health Record (EHR). Typically, an EHR is considered an application or system that healthcare providers purchase, deploy, and often integrate with other systems. These EHRs are organization-centric, designed to meet the needs of the purchasing entity, and are heavily focused on process and billing. They tend to be monolithic, with proprietary internals and limited interoperability within the product. Interoperability is considered ‘external’.

In essence, EHRs are like isolated islands in the digital healthcare landscape, making integration complex and resulting in data concretions within an enterprise. Patient data is contained within these applications, making it challenging to use the same data for different purposes like population health analytics, service management, and research. Furthermore, the tooling used for EHRs differs significantly from what is required for analytics and research. For example, we may use Python or R for research, proprietary tools for analytics in managing services, and very different tools for applications supporting direct care.

Unbundling the EHR

The concept of unbundling the EHR involves shifting the focus from the organization to the patient and adopting the FAIR principles: findability, accessibility, interoperability, and reusability. In this model, data becomes the central element, with the potential for easy composition of data from multiple organizations, regardless of their origin. This shift allows us to move beyond process measures to more meaningful outcomes in healthcare.

By concentrating on data, the architecture inherently becomes distributed, similar to how we build external systems. This approach is inspired by Rich Hickey’s concept of using plain data, RPC, and queues in system architecture. The result is a suite of independent but composable computing and data services, both internally and externally interoperable. These services provide flexibility, adaptability, and scalability, aligning with the dynamic nature of healthcare.

We must move to a domain-driven design in health care.

Interoperability

In healthcare, interoperability has been a long-standing challenge. Various approaches, such as convergence through shared applications or information exchanges, have been attempted. However, these approaches often fall short, especially in supporting granular analytics and research.

A more effective solution is to approach interoperability through composition and layering of domain-aligned data and software components. Instead of forcing organizations to adopt a single shared application, the focus shifts to standardized data exchange. This enables the creation of shared care records that may not contain all the detail but are sufficient for many purposes.

Domain-Centric Approach

Breaking down the EHR into its domain-specific components can provide clarity and facilitate meaningful, semantic interoperability. Components related to radiology, staff, patients, reference data, classifications, and terminology can be understood and managed individually across organisational boundaries. It is seductive to think that a single system can do all that we need, but health and care is too complex and needs to be broken up into smaller, manageable chunks which can be developed and improved independently.

An approach predicated upon organisations and not health and care domains creates fragmentation and loss of shared semantics. Traditional EHRs often adopt the shared single instance approach or attempt to converge various systems. However, this can lead to fragmentation and a lack of shared semantics. Unbundling the EHR, on the other hand, enables data to flow seamlessly and allows for dynamic composition of services, resulting in a more cohesive and flexible healthcare ecosystem.

For example, an organisation-focus means that a staff member who works across multiple sites may need multiple logins and find it difficult to generate a report detailing all of the surgical procedures performed across those sites, as there may not be shared understanding of the identifiers that underpin that staff member. If they are a prescriber, each organisation must be careful to register their accounts so that they have access to e-prescribing.

Instead, we should be recognising the importance of domain-boundaries, and that a staff index, and associated data such as scope of practice, and regulatory informaion, is a first-class, important domain within health and care; likely needing federation and aggregation of a number of disparate sources of information, but presented as a unified, and simpler service to other domain components.

Turning electronic health and care records inside-out

What can we learn from Clojure?

While Clojure is an excellent language to implement the software for the next generation of electronic health record systems, we can learn the most from the principles that underpin the design of Clojure:

• Data-orientated
• First class names
• Working to abstractions
• Functional / pure functions / reproducibility
• Immutability
• Loose coupling
• Dynamic / flexible / adaptive to change
• First class events / event modelling
• Building the internals of our systems as in the large (Internet-era approach)

Using these principles, we can look towards interoperability through composition and layering of domain-orientated data and software components.

Example : thinking about analytics for electronic prescribing

Imagine a scenario: You’re in a hospital, and you need to closely monitor all the antibiotics being prescribed to patients. It’s a critical task that can impact patient outcomes, but it’s also one that can be quite complex due to the diverse nature of healthcare systems.

Option 1: Leveraging In-Built Analytics

The first option is to rely on the built-in analytics tools provided by EPMA (electronic prescribing and medicines administration) or Electronic Patient Records (EPR) vendors. These tools are designed to work seamlessly within their respective systems, offering insights and analytics specific to that environment. While this option can be effective within the confines of a single system, it falls short when dealing with the intricate web of healthcare data spread across different platforms.

In the real world, many hospitals use different prescribing systems, each tailored to a specific aspect of patient care. For instance, chemotherapy prescribing systems differ significantly from those used for general medical purposes. Moreover, various healthcare enterprises, including community services and general practitioner surgeries, operate on different systems altogether. This fragmentation poses a significant challenge when aiming for a comprehensive, population-level analysis of healthcare data.

Option 2: Embracing Health Information Exchanges

The second approach involves aggregating data from various sources into a Health Information Exchange (HIE). An HIE acts as a bridge between disparate healthcare systems, allowing data to flow between them. While this approach can provide a degree of standardization and interoperability, it doesn’t fully address the underlying issues of data granularity and accessibility. In essence, it’s a step in the right direction but may not be the ultimate solution for comprehensive healthcare data analysis.

Option 3: Unbundling Electronic Health Records (EHRs)

Now, here’s where unbundling the Electronic Patient Record (EPR) or Electronic Health Record (EHR) system comes in. In simple terms, this means taking the data generated by these systems, transforming it into a standardized, self-describing event stream, and making it accessible for a wide range of applications, including direct-care (e.g. alerts), analytics (a dashboard of all antimicrobials across an estate), and research.

This unbundling process begins with extracting data from these systems. While many suppliers can provide data feeds in a standardized format, some may require transformation and extraction to create a consistent event stream. Once achieved, this event stream becomes a valuable resource for healthcare professionals.

The Power of Data Annotation

To maximize the utility of this event stream, we must recognise the importance of data annotation. This involves enriching the data with additional information using terminology and drug dictionaries. For instance, a healthcare provider can perform lookups against drug codes in the event stream, providing meaningful insights about the medications prescribed. We must recognise that mapping and annotations are first-class problems in our domain, and those tools should be available on demand, for a range of use-cases, and independent from individual vendors.

These annotated event streams can then be divided into substreams, each tailored to specific aspects of patient care. For example, an antimicrobial event stream can be created and used to populate a real-time dashboard, enabling healthcare providers to monitor antibiotic usage and make informed decisions promptly.

Transforming Healthcare Data Management

In essence, the vision revolves around turning the traditional approach to EHRs inside out. Instead of relying solely on monolithic EHR systems, healthcare institutions should be able to embrace the power of first-class, composable data and software services. This shift would allow for dynamic data composition and interoperability spanning organizational boundaries, ultimately benefiting patient care, analytics, and research.

As healthcare continues to evolve, the ability to harness and analyze data effectively becomes paramount. By breaking down data silos, enhancing interoperability, and making data truly first-class, the healthcare industry can take significant strides toward improved patient outcomes and a more efficient healthcare system. It’s a journey that requires effort and collaboration and a foundation of vendor-neutral, and open, data and computing services.

First-class annotation and mapping

In the world of healthcare and patient care, one of the most crucial aspects is the ability to make sense of the vast and ever-evolving landscape of health and care data. This requires the use of standardized terminologies, and one example is SNOMED CT. Driven by the need for dynamic and adaptable software systems, we need ubiquitous tooling that harnesses the potential of SNOMED CT in healthcare, providing access to its power in any application, for any purpose.

For example, we can standardise on vocabularies, such as the list of specialty codes. However, such an approach leads to concretions in our software systems, because if the master list of codes is updated, any software that needs to make sense of those codes needs to be updated. In addition, these codes are usually not self-describing, or contain information about the relationships between those codes.

Instead, an ontology provides rich semantics supporting inference and sense-making.

For example, imagine I wish to build a compelling user experience so that a user can rapidly search for correspondence relating to a speciality. If I have a flat list of codes, ‘neurology’ and ‘paediatric neurology’ are considered independent specialties, and if I wish to allow users to search for ‘paediatrics’ and also include ‘paediatric neurology’ then I must build those kinds of rules outside of my vocabulary / classification list.

A more dynamic and flexible approach such as that enabled by SNOMED CT might allow a user to choose ‘neurology’ and find letters for all types and subtypes of ‘neurology’ as a specialty, which would, of course, include ‘paediatric neurology’ by virtue of the ontological basis underpinning SNOMED CT. While some might think that this a dry and academic subject, by getting our foundations right, we make it easier to build compelling, and delightful user experiences.

I’ve open-sourced a number of libraries and services that can support this kind of work:

• https://github.com/wardle/hermes - SNOMED CT library and web service
• https://github.com/wardle/codelists - Generate code lists via declarative rules
• https://github.com/wardle/dmd - UK drug dictionary
• https://github.com/wardle/hades - HL7 FHIR terminology wrapper around hermes

This work should be open-source and available widely, and used for many different purposes, including direct care, analytics pipelines and research. Such libraries and tools need to be quick to set-up and use, and not require significant investments in infrastructure or server capacity. It makes little sense to not share foundational software services. It is otherwise akin to developers needing to start by building their own encryption libraries; no-one should do that but instead use open, readily available and battle-tested ready-made libraries.

Mapping and projections are first-class problems in our domain

We need to recognise, and therefore provide compelling, battle-tested solutions to first-class problems in our domain. Recognising the issues forces use to focus our limited resources on things that have the greatest benefit. If we think that building user interfaces is the biggest issue, then we spend our time (erroneously) building solutions for e-forms. Instead, if we recognise the true (shared) challenges, then we should quickly see that semantic interoperability depends fundamentally on data and software that can make sense of, and map between different ways of encoding health and care data.

Here we see that, for a specific research project, I’ve taken complex, real-life hierarchical and nested health data and generated a simplifed rectangular projection to make it easier for subsequent analysis. Fundamentally, the projections will vary depending on context and use-case, so we must focus on capturing highly granular and specific data at the point of care, while building tools and chains and data pipelines that permit turning that specific data into a variety of formats convenient for the use-case at hand. Importantly, we delay the loss of granular information until as late a stage as possible. Too many times, we look to ask professionals to record categorical data in order to simplify subsequent use of those data, rather than capturing data at the right level of granularity for clinical use, and making use of the right tools, and right expertise, to classify those data later on according to the need at hand. We should derive those projections.

Here is an overview of some of the tools I have built so far, in my spare time.

My current focus has been on lower-level, fundamental software and data services. However the future should be that we build an ecosystem of composable higher-value components, well-tested and built by community efforts, relating to design systems and decision support. Why are we building prescribing rules in proprietary software systems when the community could be building in the open to be used for whatever purpose necessary?

Finally, I’ve recognised that one way of composing together data and software services within health and care is through the use of graph APIs. Such APIs allow one to seamlessly navigate across disparate data services permitting user-facing applications to be built independently of the the underlying software and data subsystems resolving the queries at hand.

In the video, I give a demonstration of using Hermes from a Clojure REPL, permitting interactive programming. For example, I show how I can build a data pipeline that takes diagnostic and problem codes and map them into a specific emergency reference set (subset) to simplify analysis.

Conclusion

In conclusion, the concept of unbundling the EHR and adopting Clojure-derived principles has the potential to transform healthcare data management. By focusing on data, achieving interoperability, and leveraging standardized terminologies, we can create a more flexible, adaptable, and patient-centric healthcare ecosystem. This approach not only benefits direct patient care but also empowers analytics and research, ultimately leading to better outcomes in the healthcare industry.