As those who follow this blog know, over the last year or so I have been looking at EHR systems from three perspectives: theory, design, and development. On the theoretical front, the focus has been on discrete mathematics especially graphs, relations/functions, and predicate logic. The series Mathematics and Clinical Concepts offers a look at basic clinical concepts from a mathematical perspective. (A formal theory is in there somewhere waiting to be teased out.)
Looking for a theory for clinical systems made me look at clinical systems from a high-level, abstract perspective. In doing so, my view of clinical systems changed markedly. The main driver of my change in perception was the discovery of Petri nets and, later, workflow patterns. Petri nets made the distinction between processes and data, between tasks and state, absolutely clear. By doing so, they made the design flaws present in current EHR systems quite obvious. EHR systems fail to cleanly separate state and tasks, which makes their internal design and functionality difficult to follow, scale, or extend. Thomas Beale, of openEHR, made this point quite succinctly in his comment on the post Is the Electronic Health Record Defunct? In responding, I used ideas that I was saving for a later post. Now that the cat is out of the bag, this seems to be as good a time as any to present these ideas.
Electronic health record systems are expected do a lot of things: keep an accurate record of patient data, provide decision support, assist in care delivery, and lower costs, to name a few. However, the key design flaw in EHR systems is that they are based on the concept of a patient data repository; the remaining functionality is glommed on to that basic concept. This approach means any EHR system is a continuous renovation project because all care-process-oriented functionality is conceptually foreign to an archive or repository system (see Is the Electronic Health Record Defunct? for more on this topic). This is not to say that the electronic health record as a concept is bad, only that the concept has been used improperly.
The EHR concept has been used to create systems that have too many ideas that are foreign to its essential nature. So what is the best way to move forward with clinical care system design and development? Start from the beginning. But this time, not with paper records as the standard by which electronic systems are judged. This time around, the focus must be on the tasks that electronic systems are intended to support and the data that those tasks consume and produce. (Thank you Petri nets!)
Here is an initial attempt at a four-component architecture that could provide the functionality required in what I define as a clinical care system.
The Four Key Components
Knowing that tasks and data (state) are fundamental design concepts, the next step is nailing down specifics. Obviously, patient information is important. Medications, problems, labs, demographics, histories, physical exams, genomics, etc. are patient data that describe the state of the patient at some point in time. (Patient state is an essential concept for clinical systems, and it will be the subject of a future post.)
In current EHR systems, paper-based thinking dominates, and we think of their functionality in terms of their paper cousins. The problem list, medication list, etc. have their origins in paper charts. This paper orientation is used to design the relational database tables that hold this information, which codifies the paper-based view. However, in electronic form, this information need not be tied to these specific representations. In fact, it is best not to do so.
Interoperability would be much more straightforward if patient data representation was addressed as a design challenge separate from software systems that access or use patient data. For example, once everyone agrees on what data elements are contained in a family history and what metadata a family history should have, sharing across systems will be much easier. Such an approach requires semantic controls and supporting tools. Calls for atomic data, standard metadata, and similar appeals (e.g., JASON) are essentially asking for patient data storage and semantics to be clearly and cleanly separated. openEHR and archetypes illustrate the principle of separating semantics from storage.
Under the four-component scheme, terminologies and ontologies that support the semantics of patient data reside in the patient Information component. In addition, only patient data reside here. Insurance information, for example, lives one level up in the EHR.
The patient information component is a software system that provides a user interface and tools for managing its content as well as a series of APIs for interactions with other components.
Electronic Health Record
Managing access to patient information is a separate problem from managing the semantics of patient information. As such, patient information management requires its own software system to assure that vital functions, such as security, reporting (includes clinical research and population health needs), disclosures, billing, legal and regulatory requirements, are properly addressed. This is where the electronic health record comes in. In this four-component scheme, an EHR system is a production-quality software system optimized for managing access to patient data and acts as a legal record. It does not directly support clinical work and is not intended for use by clinical professionals. The EHR accesses the patient information component via one or more APIs. It provides patient record functionality via one or more APIs to other components.
Supporting clinical work requires first-class support of process management and workflows, which is what this component provides. Business process management capability/workflow engine technology allow this component to manage resources (people, software), task input/output data requirements, environmental info (location, active processes, etc.), and user roles. Clinical decision support lives most naturally in this component. Processes have their own data and information requirements (task semantics, visual workflow representations, etc.) that are managed by this component. APIs expose the required functionality to other components.
Clinical Care System
Clinical professionals require usable software systems that both support their work habits and that help them in providing safe care. Clinical care systems must understand clinical roles and cognitive needs, as well as clinical care processes—no small feat. Here is how I define a clinical care system.
Definition: A clinical care system is a software system designed to support role-based clinical processes at the point of delivery while maintaining a legal record of the patient’s data as well as clinical actions and interventions. Clinical care systems must be able to adapt to end-user needs (for example, by offering user-configurable workflows and user interfaces). Collaboration between clinical teams or individuals must be easy to initiate and manage. Cross-cutting issues (e.g., security, interoperability, performance, etc.) should be optimized for clinical environments. Properly designed clinical care systems promote and assure safe, effective care.
A clinical care system is domain-specific (primary care, endocrinology, etc.), role-based (physician, nurse, physical therapist, etc.) productivity software for clinical professionals. It is the highest level component in this architecture.
From a design perspective, having these four components helps to separate the hard problems in each area so that research, design, and development efforts do not confuse issues and, thereby waste time and resources.
All four components have APIs that allow interactions with other components. They exist as a hierarchy with the patient information component at the lowest level and the clinical care system, which requires all of the lower-level components, at the highest.
When using the term “components,” I am speaking from an architectural perspective. Thus, each component is (or can be) a production-quality software system in its own right. This architectural approach promotes low-coupling and high cohesion, allowing for flexibility in configuring systems to meet the requirements at hand. For example, in a public health department, the patient information, EHR, and process information components would be topped by a public health system and not a clinical care system. Using this four-component model for clinical systems promotes innovation by separating the key functions and hard problems inherent in clinical systems into discrete units where each may be optimally-addressed on its own merits.
Clinical software systems are complex. For too long that complexity was not obvious because the most visible clinical systems, EHR systems, were seen as extensions of their paper cousins. The use of the paper chart as a metaphor for electronic systems that support care resulted in the concept of an archive/repository being used to design systems intended for use by clinical professionals. The result has generally been systems with poor usability and inconsistent safety features that do not optimally support clinical work.
Enough effort has been expended trying to build “smart” record systems that support clinical work. It is time to begin anew, jettisoning the paper chart as a design metaphor, and instead focusing on the complexity of the healthcare environment and clinical work. Recognizing patient information, records, processes, and clinical productivity support as distinct domains with each requiring its own research, design, and development efforts, allows each to be appreciated for the intellectual challenges it presents.
Innovation is about solving problems, but trying to solve ill-chosen problems is a waste of time. A good deal of work has already been done in each of these domains; it simply has been applied to the wrong metaphor. Out with the old, in with the new.