Electronic Health Record: Part 2
Part 2: Designing the Ideal Electronic Health Record
(see Part 1: EHR: the Electronic Stages of Loss and Grief)
Our world has been radically transformed by digital technology – web-enabled smart phones and tablets have changed the way we communicate in ways that no one could have predicted. It is therefore peculiar, that despite the fact that Medicine is an information-rich discipline, widespread adoption of electronic health records (EHRs) has required an act of congress (the Health Information Technology for Economic and Clinical Health - HITECH, 2009).
Six years have passed since the passing of the HITECH edict; unfortunately, many physicians remain embittered. A recent survey published by the American EHR and the American Medical Association (AMA) shows that physicians continue to be dissatisfied or very dissatisfied with their EHR system. (http://www.americanehr.com/research/reports/Physicians-Use-of-EHR-Systems-2014.aspx)
If you could push the reset button and design a new electronic health record, what would it look like?
Most clinicians agree that an EHR should:
Update heterogeneous data from multiple entry portals, in real time and into a single repository.
Contain structured and unstructured clinical information organized into a searchable format and readily available in any clinical setting.
Include an easy to read clinical summary of all active patient problems, medications, procedures, and labs.
Communicate seamlessly on small and large scale, facilitating informed decisions on both an individual and population basis.
Facilitate physician efficiency.
In order to understand ‘what is wrong’ with current EHR offerings, it is first necessary to examine the components of an Electronic Health Record. At the core of any EHR system is the central database. The central database functions include the storage and recall of schemas, tables, queries, reports, and other objects. In truth, most EHR’s actually perform central database functions extremely well. This is not surprising, since database technologies have matured over four to five decades and are presently capable of processing tremendous volumes of data at a very high velocity. This is the domain of enterprise database companies such as Oracle, IBM and others.
WHERE IS THE PROBLEM?
In order to take in, store and retrieve large volumes of information, databases and EHR systems utilize database management software (DBMS) to present the user with management tools via a specialized User Interface. This is what physicians see and touch. This is what they perceive the EHR to be. For non-medical applications, DBMS usually take the form of electronic templates or data entry forms which prompt the user to enter structured data elements. The DBMS ensures that the data has the proper format (date string, credit card format, address, etc….), and then directs the information to the designated location in the database, ensuring it is easily recallable for future database queries.
It should be noted that data ENTRY and data DISPLAY represent very different processes, each requiring a different set of solutions. Current data display methodologies utilize relational database technologies (which search for data by content, rather than by following links) to recall and display stored data on the user’s interface. Most systems do this pretty well, and even recalcitrant physicians would (reluctantly) concede that it is very beneficial to have large volumes of patient information at their fingertips at an instant.
Data entry is more challenging. If data are homogeneous and derived from a relatively narrow domain, entry is generally a relatively straightforward process. Unfortunately, this is often not the case in medicine. Medical data is less certain. It is often heterogeneous, complex and incomplete. Moreover, interval of data submission is important and in many cases the data is completely unstructured. Handling the complexity of data is where most EHR systems seem to fall short.
Thus, the crux of the problem is how do efficiently get information out of the physician’s head and into the database ?
It sounds like a small niche, but solving this problem would have a profound impact upon the electronic health care industry.
After all, the most important tool for diagnosing a medical ailment is a detailed history. This is the differentiating factor between a skilled doctor and ordinary one. An expert doctor knows how to effectively use ‘heuristics,’ tools which we develop as a result of personal experiences. Heuristics simplify the decision-making process and allow the physician to identify small nuances in a medical history to narrow a list of potential diagnoses into a single diagnosis. Documenting the nuances of such decision making in an electronic format will be extremely difficult.
On a personal note, I found it nearly impossible to capture the essence of the visit using the electronic templates currently available in our EHR. The checklists worked well when capturing independent symptoms such as distance walked, or number of cigarettes smoked each day, but the medical history is much more than a group of independent variables that to be captured using the tools offered by a relational Database Management System (DBMS). Neither is a medical history a simple snap shot in time. As a history, it is meant to describe that which has occurred during the elapsed interval of time from when the person was last seen. Each individual symptom requires a descriptor such as ‘new’, ‘improved’, ‘worse’, ‘resolved’, … ‘associated with’, ‘caused by’ remain critical. It is in these relationships that medical diagnoses are made.
The new system failed to accurately capture the subtle nuances associated with the patient’s story. It flattened a three dimensional history into a two dimensional template and ignored the cause and effect which remains so vital. As a result, many physicians have resorted to free text options – either via typing, or voice recognition software.
One could certainly design a system which offers a vast array of discrete descriptors for each potential condition, but in an effort to be all encompassing, templates would expand into unwieldy proportions. Choosing items on unabridged templates tends to feel a little like searching for Waldo in crowd of check boxes as users spend precious time and energy searching for the correct descriptor. The system becomes distracting to both physicians and patients and serves as a real barrier to patient care.
The opposing relationship which exists between a system that records data in discrete fields (allowing querability) and freedom of expression is the crux of the problem. Macro driven systems which generate large blocks of repetitive text possess a degree of freedom of only one and free form dictation, while highly customizable, does not offer searchable data fields (at least not yet!).
To be completely fair, data querability and degrees of freedom of expression are not completely mutually exclusive as there is a third variable which transmutes the inverse relationship between querability and degrees of freedom; that factor is time.
Alternative methods of free form data entry using voice recognition have recently seen widespread adoption. The technology certainly helps to round out patient details, but fails to provide the structure necessary for population-based health initiatives. Many large EHR companies have invested in post-acquisition data processing – Natural Language Processing – with the hopes that structured data can be created from physician’s dictation. This will become a major crossroads for many technology platforms as they choose between processes which adopt pre- vs post-data acquisition structuring techniques.
RETURN OF THE NATIVE
You can’t define a data model without direct communication with clinical end users. Data modeling is about understanding all of the uses of the data, the relationships and attributes involved in the data.
To fully understand the problem, one must understand that taking a patient history is a dynamic process. Patients present with symptoms, which lead to diagnoses, which lead to treatments, which lead to outcomes. This is a tree of data with the patient as the root and the diagnoses, treatments and outcomes as subsequent data sets. While there are various nuances between each of these steps, the number of options are indeed finite. As such, it is possible to create an algorithm which accounts for all possible patient interactions and outcomes. I know how impossible that may sound, but current computing capacity does indeed allow the modeling of every possible scenario using an object-oriented hierarchical decision tree which navigates clinically relevant factors.
This where the concept of a knowledge base fits in. Until recently, little attention has been given to the process of clinician-oriented structuring of data collection tools. But times are changing. Physician domain experts are contributing by developing meaningful knowledge bases that will drive future applications. Think of it as an intricate map of symptoms, locations, severity, laterality, etc. The physician navigates a predetermined map in order to arrive at a particular diagnosis or plan of treatment. It is the very fabric on the EHR. Unfortunately, it would seem our fabric is rather threadbare. This is the root of the current problem that current EHR’s face.
I, myself, have had the good fortune of developing solutions which use Agile methodologies, placing programmer and clinician side by side. The process is a very different from the typical relational database methodology. Processes are developed which allow physicians to navigate through patient encounters using a hierarchical data algorithm, concurrently choosing discrete procedure details AND specific content.
For those of you who continue to struggle with existing EHR technology, my advice is to hold on just a little longer. As physicians we will soon have the opportunity to evaluate specialized applications which utilize robust and specialized knowledge bases of information. I suggest that you hold electronic technologies to the highest standards and reject software options that fail to meet the needs of your complex practice. Rather than decisions made based upon market dominance, characteristics for systems should be judged upon specific factors that improve physician workflow:
Fast sign in
Light weight hardware
Fast between clicks
Iterative (with frequent updates)
Reduce repetitive operations.
Interoperable with other systems.
Nimble to concurrently capture patient nuances, risk factors and complications.
Menu-driven algorithms which are highly organized:
Complete – no need for typing or speech recognition
Orderly – by anatomic location, size, or other
Relevant – options presented should be viable options
Efficient - Limited number of options for each question.
One of the developers with whom I have had the good fortune to work has shared his vision of the future EHR-landscape as a series of highly specialized front-end applications (essentially, independent database management systems –DBMS) which interface structured data to the core EHR databases. For me, it is dizzying to consider the possibilities.
Christopher L Wixon, MD is a vascular surgeon who is passionate about developing physician-oriented electronic record systems. He has co-authored a platform for cardiovascular services (www.mTuitive.com) and has developed a unique search engine for ICD-10 and CPT which use a hierarchical algorithm (www.codecatcher.co).