The earlier simple EHR design post, suggests that a basic EHR requires at minimum a HOME screen (where one selects the patient of interest), and a PATIENT FILE (where patient information is displayed and captured).

This post will explain the PATIENT FILE in more detail.

Why not use the term “patient chart”?

At first, it may make more sense to use the term PATIENT CHART. Isn't that where the patient information is stored and captured?

In paper-based systems, the patient chart is the bundle of paper kept on the patient. In a hospital ward this is the bundle of hospital papers. In the clinic this is the bundle of clinical paperwork. The patient chart sits in the archive and in the chart room between appointments.

Using this analogy, the patient chart represents the end-store of data about a patient, and I agree with this.

However, we must also realize that this end-store of patient information is relatively static. Once recorded, it is there forever.

The process of how information gets into the patient chart is quite dynamic. It comes from different forms and papers, that work their way into the PATIENT CHART.

That is why I proposed the use of the term PATIENT CHART to represent that relatively static end-store of patient information.

And I propose a different term, PATIENT WORKFLOW, to represent the dynamic process of how patient information is captured and interacted with (ie. presented) during unique situations.

Therefore, we need a different term from PATIENT CHART, to encompasses both the PATIENT CHART and the PATIENT WORKFLOW. Hence, the made up term PATIENT FILE.

The PATIENT CHART: Enduring & Broadly Similar

This end-store of patient information,  the genetic patient chart, is reasonably similar across many care setting around the world. Many different clinics or hospitals, for instance, could function by accessing a generic patient chart ∂esigned with the same general layout. The reality is that most paper-based clinical charts are relatively similar.

Ideally, the patient chart is designed using the absolute best practices in the information display. It should be designed with a focus on patient safety, speed of information retrieval and information communication to the user, and applicability across many care settings and user types.

I realize that an exception to this 'one chart suits all approach' is subspecialty clinics that create their own ‘shadow charts’ that display and sort information in a unique way. Or units (Eg. ICU) with unique data summary pages. Or specific charts for certain types of clinicians. Yes, at times a special chart may be designed,  but this is generally adding to the existing structure of a patient chart, rather than wholly re-imaging its overall layout. A subsequent post will discuss the 'Magic Chart', which is my approach to solving this conflict within the patient chart between building something that is 'highly generalizable' and 'unique' at the same time.

The PATIENT WORKFLOW: Transient & Highly Variable

The opposite of the enduring and generalizable patient chart, is the PATIENT WORKFLOW. The PATIENT CHART can be broadly used by many different types of clinicians, across different organizations around the world.

However, the PATIENT WORKFLOW is highly unique. Each organization, each user role, each clinic type likely has its own workflows. These workflows change based on the patient's circumstances and supply chain circumstances. Workflows are hard to transfer across organizations, and even re-use within the same organization.

Because the WORKFLOW section of the PATIENT FILE is highly variable, we must assume that each organization requires tools to be able to build and edit their own workflows from day one.

Building an EHR

As proposed, a PATIENT FILE is the section of the electronic health record where information about a single patient is displayed and captured.

The display and capture of this information may occur within the PATIENT CHART and within the PATIENT WORKFLOW.

In general, the PATIENT CHART section of the PATIENT FILE could be relatively similar across an organization(s), whereas the WORKFLOW must be customized frequently.

This provides a mental construct on how to design the EHR. Design the patient chart to be long-lasting and highly generalizable. Design the workflows with tools to give to each organization to build their own.

The next post will discuss the concept of a PATIENT WORKFLOW in more detail, and how it differs from a simple 'form.'

Note: healthcare directed towards multiple patients at once

This approach to EHR design is focused on healthcare that is directed towards a single patient at a time - which is pretty much always the norm. However, there are exceptions. For instance, a patient receiving group care, or when a public health clinician is managing the care of multiple patients at once. Cases where care is not directed towards a single patient at a time require a different EHR setup.

But as we said, this design approach is based for the majority of clinicians who care for a single patient at a time. Therefore, the start of care involves opening the patient’s file.

Note: EHR Composability

This article is not meant to suggest I do not believe in customizing the PATIENT CHART for specific users and clinical settings. The post on the Magic Chart discusses a way to do this automatically (which I think is a safer and more sustainable approach then asking clinicians to do this on a case by case basis). The purpose of this post is to create a mental framework as a first step for EHR design, that suggests there is a very different type of functionality required for organizations using the PATIENT CHART part of the application versus the PATIENT WORKFLOW section.

‍