Building Clinical Care Software Systems, Part III: The Electronic Health Record

by Jerome Carter on July 28, 2014 · 4 comments

Last week’s post looked at the patient information component. This week I want to look at the electronic health record. EHR systems are offered as being both clinical care support systems and replacements for the paper chart, which are two very different things.

Paper charts have non-clinical uses, and those aspects must be supported by any electronic system that purports to replace them. Over the course of their existence, paper charts evolved from being primarily repositories of clinical notes to serving administrative, financial, legal, and regulatory purposes.  Since paper charts serve multiple purposes, designing electronic versions to replace them is much harder than it might first appear because there are so many (potentially conflicting) requirements.   One such conflict that is often mentioned by clinicians is the data entry burden.

Designing an electronic system optimized for data capture is obviously not the same as designing one that intimately supports clinical work—ergo, clinician complaints.  That being said, these requirements are not mutually-exclusive; however, designing a system that accommodates all of them equally well requires an understanding of how they differ and what they have in common.

Support for clinical work requires systems with workflow awareness and designs that are optimized for learnability, collaboration, and productivity. Definitions of the electronic health record rarely, if ever, mention these traits as important characteristics.  Look at a few EHR systems’ sales brochures. How many tout workflow capability, ease-of-use, collaboration tools, and enhanced productivity as major product features?

The clinical care system architecture recognizes that competing requirements are a reality and seeks to separate them so that each may be properly studied and optimized.

Clinical Care System 4 Component Architecture

Here, the non-clinical purposes are encompassed in the EHR while clinical work support is contained in the clinical care system component.   Of course, this leads to the matter of determining what goes into each component.   Doing so requires deep analyses of both the paper chart and clinical work.  Let’s look at how the paper chart relates to clinical work.

The EHR component
Paper charts are passive care participants, acting as information stores and places to record clinical work narratives.  Charts contain clinical notes (doctors, nurses, PT, etc.), reports (consultations, discharges), labs, radiology, preventive care, and whatever else the local medical records committee approves of.     The point here is that a chart is fundamentally a collection of documents, so if nothing else, an electronic health record must get documents right.

The difference between a document and the data it contains, while not necessarily a big deal on paper, is very important in the electronic realm.  Electronically-speaking, documents may be virtual (i.e., a collection of data elements presented together) or self-contained text files oblivious to outside information.  I mention this distinction because in the CCS architecture, data live at the lowest level and documents live in the EHR. Thus, lab data from the patient information component can be presented as a lab report in the EHR component.

Viewed in this manner, the EHR component takes on the information store and recording roles of its paper cousin.   In addition, the non-clinical purposes of the EHR reside here as well.  As such, disclosures for legal purposes, chart reviews for regulatory needs, and billing information reside in the EHR component.  However, note what is not here: the user interface for clinical work support and workflow technology. These are separated to allow for independent optimization.

As the home for documents and document management, the EHR component manages issues such as document validation and security.  However, since components interact using APIs, validation and security can occur at the appropriate level. For example, a sensitive data element in the patient information component would receive a security approval request from a document that contained it whenever that document was accessed.

Just as the EHR component interacts with the patient data component to create virtual documents, it can interact with the clinical care system component (CCSC) to present information required for clinical work.  However, and this is very important, the creation of documents that are managed by the EHR component would occur within the CCSC.  The reason for this approach is that the CCSC contains the representations of clinical work, the user interface for clinicians (the EHR component should have an interface for HIM professionals), and the links to CDS (e.g., preventive care guidelines).  Actual execution of workflows is handled via an API by the Process Information component.

Clinical work documentation
Clinical documentation is one of the most often criticized functions of EHR systems. Complaints of too many clicks and being a data entry clerk are common.  Since clinical documentation serves so many uses and is here to stay, the software design challenge is how to make it less of a productivity sink.  Improving documentation methods requires understanding the properties of clinical notes both for reading and writing purposes.

Color, layout, and text
Paper documents carry more information than the words they contain.   Color is a key example.  One hospital where I attended had blue consultation forms.   Since no other forms were that color, I could tell whether a requested consult had been answered simply by seeing blue amid a background of white pages.    Layout also conveys information.  For me, reading microbiology reports, in particular, was aided by how information was distributed on the page.

Creating clinical notes
Structured data are required for downstream uses.  However, typical data entry methods like drop-downs, textboxes, radio buttons, etc., can be tedious to wade through for inputting data, and can result in hard-to-follow documents when reading.

Electronic systems are intended to be active in the care process, which means one is expected to use them while interacting with patients.  This is disruptive for many clinicians. I, for one, almost never carried a chart with me into a patient’s room–whether outpatient or inpatient.   I read the chart beforehand to get the information I needed, and used a special template I created to capture information from the encounter.  After completing the encounter and making all final decisions, I created the note.

Changing to a process that required interaction with the system would have greatly impaired my productivity unless the system supported my way of doing things.  Were I designing a system for my use today, I would likely create a version of my encounter template that was gesture-friendly, and then have it write the chart note from my markup.   The point here is that workflow has to be taken into account with note creation and, ideally, most of the note would be generated as a by-product of  interaction with the patient.  For example, within the heart label on the physical exam section of the template, one gesture would record a mitral regurgitation murmur, another would open up a treatment guideline, and yet another would bring up any EKGs, ECHO reports, etc. that the patient had undergone.

Reading clinical notes
Notes created from standard data entry elements can be difficult to read.  Cutting and pasting doesn’t help readability either.   The problem is one of reading a list of facts/data points as compared to reading a story.  From a software design standpoint, two issues arise: 1) how to assure that a note has the correct content, and 2) how to produce a human-readable note that offers a coherent picture of the patient.   Structured data entry addresses the first and seems, at times, to make the second worse.  Ultimately, more research is required to balance the two issues.  Now that more clinicians are encountering hard-to-follow notes and voicing their complaints, this area will receive the attention it deserves (1,2).

The electronic health record is an important component of a clinical care system, and it is needed to address a wide range of clinical and non-clinical needs.  However, it is not ideal for direct patient care support.

  1. McEvoy JW. The turing test and a call to action to improve electronic health record documentation. Am J Med. 2014 Jul;127(7):572-3.
  2. Embi PJ, Weir C, Efthimiadis EN, Thielke SM, Hedeen AN, Hammond KW. Computerized provider documentation: findings and implications of a multisite study of clinicians and administrators. J Am Med Inform Assoc. 2013 Jul-Aug;20(4):718-26.

 

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 4 comments… read them below or add one }

Baby Djojonegoro August 5, 2014 at 2:59 PM

I’m following your blog, and in particular, this series, with great interest. I agree with you that building a clinical care system that replaces the paper chart is complex. Not only does the paper chart serve different purposes, but the format also encodes rich at-a-glance information. You cited the example of the form color above. Another example is the physical thickness of charts (alerting the clinician to the complexity of the patient), which has no e-data equivalent.

Also, as you stated, the very property (imposing structure on the information) that facilitates the correctness of data renders it harder to digest for humans.

There is definitely a lot of work to do!

Reply

Jerome Carter August 5, 2014 at 5:24 PM

Thanks for your comment. This is a very exciting time to be involved in clinical systems. Advances in technology have made it possible to do some really interesting things.

Reply

@BobbyGvegas August 5, 2014 at 11:29 AM

Excellent blog. I have again cited your work on mine. http://Blog.KHIT.org

Still mulling over a lot of the implications.

Reply

Jerome Carter August 5, 2014 at 5:21 PM

Thanks. Just trying offer a few ideas.

Reply

Previous post:

Next post: