Healthy Architectures - Using CQRS and Event Sourcing for Electronic Medical Records

The health care industry has been migrating to electronic medical/health records (EMR/EHR) for some time. Recently, through government initiatives, greater emphasis has been placed on moving the bulk of health records to EHR/EMR. While there are many problems of interest in the EHR/EMR space (such as privacy, free text processing and semantic interoperability), this paper discusses some problems related to the complexity of the healthcare domain. In particular, performance, scalability, and traceability are discussed as associated with reconstructing healthcare related business events. The paper considers using Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) as a means to address these concerns. It presents a brief discussion of EMR/EHR and goes on to introduce the use of CQRS and ES in this space. Taken together, these patterns can be used to build an EMR/EHR system that scales while maintaining detailed patient information.

Background

Electronic Medical/Health Records (EMR/EHR) contain information about a patient. These records can contain a number of different patient related details such as: doctor visits, patient privacy choices, insurance, billing, pharmacy, and demographic information. Depending on the data retention criteria, these records can spans the lifetime of the patient. The records are used for both transactional and analytical purposes.

The healthcare domain is highly complex from a patient record perspective due to its nonlinear process flows as well as its myriad structured and unstructured data elements. As an example, consider the scenario where an adult patient has an acute condition related to a pre-existing chronic condition or childhood event. The high level workflow is described notionally as follows [1]:

1. The Patient arrives at a Primary Care Facility
2. The Patient details the condition to the Clinician and Clinician Support Staff
3. The Clinician and Clinical Support Staff assess the current state and determine eligibility and benefits. The system minimally captures and presents:
   • a. Clinical Data regarding the patient - This may involve input from multiple sources (e.g., nurses, consulting clinicians, pharmacy and lab). The associated data maybe be related to the current visit, but also may include previous visits (including both the present facility and others) extending back through the patient's childhood.
   • b. Administrative data regarding the patient- This typically involves eligibility and benefits checking as well as prior-authorization activities. This administrative data may be a factor in selecting from possible treatment options.

Additionally, the system may be required to provide decision support analysis associated with pre-existing conditions, drug interactions, allergies, and immunizations among other factors.

4. The Clinician, Clinical Support Staff and Patient collectively devise an initial treatment plan. For this step the system minimally captures and presents:

1. • a. Required procedures
   • b. Required medications and associated prescriptions
   • c. Additional instructions and notes
   • d. Coordination with other providers and facilities

In addition to capturing and presenting the treatment plan information, the EMR/EHR will likely work with other systems to enter the orders as well as request prescriptions and labs as needed.

5. The treatment plan is successful and visit conclusion procedures are conducted. For this concluding step the system must minimally capture and present:

1. • a. Any remaining visit information
   • b. Instructions for the course of treatment
   • c. Supporting information to enable the patient to understand and comply with the course of treatment
   • d. Schedule subsequent visits and procedures as necessary.

From the example, it is clear that even at a high level there are numerous events that must occur correctly in order for the visit to be considered successful. The system must provide both real-time and historical information with a high degree of accuracy in order to support the Clinician and Support Staff decisions. Consequently, the EMR/EHR must be both responsive to the user's transactional needs while providing traceability to previous event details for analytical purposes. It also follows that, given the large number of detail-oriented events that occur during one visit; across the patient's history, the potential for errors in the patient record can be high. However, given the state of hardware and software, there also exists enormous potential in reducing the error at a fine grain level through the use of scalable, detail oriented EMR/HER.

Creating scalable architectures that also address the detail-oriented needs of healthcare has been challenging using traditional architecture. Interestingly, for some time the Domain Driven Design (DDD) community has been working with Command Query Responsibility Segregation (CQRS) pattern to create scalable solutions for complex domains [2]. CQRS has often been complemented with the Event Sourcing (ES) pattern as a way to create, reverse, and replay system events [3, 4, 5]. CQRS and ES have been in use for some time, but are gaining interest as an alternative to more traditional architectures. In the space of healthcare they may afford a means to address some of the many challenges in the domain. This article discusses CQRS and ES at a high level. For a detailed discussion, the reader is directed to the references.

CQRS:

CQRS separates read (queries) and write (command) activities into fundamentally separate responsibilities. Apart from allowing reads and writes to occur in parallel, CQRS implies that different schemas, indexes, and optimizations can be used for read purposes and write purposes. The read data stores and the write data stores, therefore, need not be collocated. Parallelized background processes can be used to synchronize stores based on events, query request or in batch. In effect, the user accesses the read database first, when the requested data is not in the read cache, the master database can be checked. Clearly, a balance must be stricken to maintain the fidelity (i.e. eventual consistency) of the read cache for this approach to be useful

Given the parallelization of queries and commands, concurrency management becomes an important consideration in this technique. For complex entities in a high-volume multiuser environment, concurrency conflicts can potentially lead to data write requests based on invalid views of the data. Clearly, validation rules must be exercised prior to data writes.

Recommendation- Using Task Based User Interfaces in Healthcare: One approach to address the invalid view problem is to leverage another technique from DDD philosophy. DDD recommends the use of Task-based User Interfaces (TBUI). TBUI deconstructs the user interaction into a collection of commands that represent the user's intent. Collections of commands are submitted to a business component and are handled in a command queue where validation can occur. TBUI is potentially an effective means to address the nonlinear workflows that are so prevalent in the healthcare field.

Figure 1 indicates the passing of commands from the presentation layer to a business components where read and write logic are separated. Validation of commands occurs in the UI and in the write logic prior to changes in the write cache. Synchronizing from the write store to the read store may use a variety of strategies [6], but in this case, it is done through an Operational Data Store which acts as the authoritative source of data. If the read store doesn't contain the necessary data, a check against the authoritative data source can be conducted, if desired.

Figure 1: Command Query Responsibility Segregation (CQRS) Using an Operational Data Store

Event Sourcing

A complementary approach that can be used in conjunction with CQRS (and TBUI) to manage concurrency conflicts and capture user intention is Event Sourcing (ES). ES allows system states to be reconstructed and sequences of application events to be replayed or reversed at a fine- grained level.

In EMR/EHR systems, the ability the capture and reconstruct the events associated with a patient's history is clearly valuable in analyzing the patient's circumstance. As mentioned earlier, healthcare workflows can be nonlinear in nature. Clinicians and administrators may need to interact with an EMR/EHR system in ways that match the circumstances of the work environment. Additionally, from a clinical perspective, as monitoring and treatment technology (e.g. drug delivery) becomes more portable and ubiquitous, capturing and maintaining this information enables a thorough understanding of a patient's status as well as issues that may arise with the technologies themselves.

Given the desire to maintain and reconstruct events in a patient's history, a granular record of electronic events is potentially useful. With the increasing availability of storage, computing power, and high-performance analytics techniques, business-level events can be reconstructed from application events in order to support diagnostic, business and even epidemiological needs. In this environment, Event Sourcing becomes a viable pattern to address this problem.

Event Sourcing (ES) is a pattern that captures the succession of user and system events to create an event trace of all activities involving the system. While this may seem like a large amount of data being written, in the age of the cloud, the data and compute resources are effectively infinite (although clearly constrained by cost). With ES, the resulting event log is in some senses a fine-grained operational data store that can be used to reconstruct, replay, or reverse, application level events. Consequently, the same level of reproducibility should be possible for clinical and administrative events through composition and aggregation. Figure 2 shows a simple read and write event associated with a business component.

Figure 2: Read and Write Events fired by a Business Component.

Pairing CQRS and ES

The capture of application events proposed by ES is one approach to address concurrency conflicts at the system level introduced by CQRS. When taken in conjunction with the CQRS suggestion of capturing user commands, the combination of the two patterns enables a detailed understanding of application behavior and user intention. The event data can be used to populate the CQRS Read Cache Schema (Figure 1), construct audit records (in particular, healthcare mandated audit logs), populate the master data repository, and feed the analytics models. With regards to analytics, it is worthwhile to note that as business-level analytics processing becomes more real-time, the event information (when used to reconstruct clinical events) can be a substantial enabler in supporting clinical decision support.

Recommendation: CQRS and ES Boundaries. Generally speaking CQRS and ES exist within a Business Component boundary. For instance, given a SOA, the Business Component boundary may be the a Service or Service Component [7, 8]. The entire EMR/EHR application architecture, especially in a large distributed implementation, need not be CQRS and ES. Rather, CQRS and ES should be used where there is a clear benefit given the healthcare tasks involved.

Remarks

This paper has discussed the potential benefits of CQRS and ES in healthcare. The benefits arise fundamentally from separating read and write activities, while capturing a detailed record of application events and user intention. In the healthcare arena, these have particular merits in deconstructing a complex domain, enabling a scalable architecture, and capturing detailed a record of events. However, these merits must also be qualified. Every architectural approach has its pros and cons, and must be evaluated in the context in which it is to be used. In particular, CQRS introduces complexities that are not present in more traditional architectures. Depending on the domain, segregation of command and query activities may not yield a substantial benefit. Similarly, unintended consequences may arise from ES. Since ES uses an event-driven model, special considerations must be taken such that replay or reversal of a sequence of events, does not invoke changes to other systems.

This paper has only touched on the various aspects of using CQRS and ES. The focus has been on the potential benefits to problems endemic to EMR/EHR solutions. This is meaningful particularly because of the increasing interest to move to the digital storage and management of electronic patient data. The details of CQRS and ES have not been discussed here. The reader is directed to the references for more information.

About the Author

Arunava Chatterjee is a Solutions Architect working on SOA and Distributed Architectures for the Enterprise in Healthcare. He has published in a multiple fields including Bayesian Statistics, Natural Language Processing and Physics. He holds a Ph.D. in Physics from Florida State University and can be contacted at bob.chatterjee1@gmail.com.

References

1. AHRQ Publication No. 09(10)-0091-1-EF, October 2009
2. Evolution of DDD - Adzic, Gojko, June, 2010.
3. CQRS - Fowler, Martin, July 2011.
4. Event Sourcing - Fowler, Martin, December 2005.
5. Clarified CQRS - Dahan, Udi, December 2009.
6. AMP: Adaptive Multi-stream Prefetching in a Shared Cache. Gill, B, Bathen, L.
7. When to Avoid CQRS - Dahan, Udi, April 2011.
8. The Open Group Service Integration Maturity Model (OSIMM), Version 2, Nov 2011.