Putting the “why” in “EHR”: capturing and coding clinical cognition

Abstract

Complaints about electronic health records, including information overload, note bloat, and alert fatigue, are frequent topics of discussion. Despite substantial effort by researchers and industry, complaints continue noting serious adverse effects on patient safety and clinician quality of life. I believe solutions are possible if we can add information to the record that explains the “why” of a patient’s care, such as relationships between symptoms, physical findings, diagnostic results, differential diagnoses, therapeutic plans, and goals. While this information may be present in clinical notes, I propose that we modify electronic health records to support explicit representation of this information using formal structure and controlled vocabularies. Such information could foster development of more situation-aware tools for data retrieval and synthesis. Informatics research is needed to understand what should be represented, how to capture it, and how to benefit those providing the information so that their workload is reduced.

“Alexa, Ms Jones has had shortness of breath for a month, developed palpitation today, and now has an irregular heartbeat with a rate of about 135. I think her symptoms and physical findings are due to an arrhythmia. Has she ever had an arrhythmia before?”

The adoption of the electronic health record (EHR) has been touted as the solution to inefficient, error-prone health care, yet mainstream medical literature is replete with complaints about the failures of EHRs to meet these promises. For example, over the past 4 years, the New England Journal of Medicine alone has published at least 27 perspective articles on the potentials and failings of EHRs. Commentators, including leaders in informatics research, have called for improvements in user interface design, patient data access, and automated decision support.¹ The fictitious exchange that begins above, and is continued in Table 1, imagines an EHR with a “smart speaker” for data entry and retrieval, and a database with all the patient’s data from all sources. (A version of this conversation was originally presented in oral form at the AMIA Fall Symposium as part of a paper presentation.²) This hypothetical user interface, certainly within the realm of possibility,³ provides an easy-to-use data entry method and a Google-like search function to improve data capture and retrieval. Yet, despite these improvements, the EHR is still up to its old tricks: Alexa overwhelms Dave (the physician) with irrelevant data, distracts him with an inappropriate alert, and fails to warn him that electrocardioversion after prolonged symptoms requires a course of anticoagulation prior to the procedure. Why should this be, given that great minds and powerful commercial forces are being applied to these problems?

Table 1.

Hypothetical interaction between a physician and an electronic health record via a “smart speaker” user interface

----------Initial Visit---------
“Alexa, Ms Jones has had shortness of breath for a month, developed palpitations today, and now has an irregular heartbeat with a rate of about 135. I think her symptoms and physical findings are due to an arrhythmia. Has she ever had an arrhythmia before?”
	“She doesn’t have ‘arrhythmia’ on her problem list, Dave. This word appears 22 times in her health record and 350 times in reports from the health information exchange. Would you like me to read them?”
“Yes.”
	“Okay. Admission note from 1995 states ‘patient has no family history of arrhythmia.’ Admission note from 1996 states ‘patient has no family history of arrhythmia.’ Admission note from 1997 states …”
“Alexa stop. Order an electrocardiogram.”
	“Okay. I have ordered an electrocardiogram.”
----------Two Hours Later---------
“Alex, what did the electrocardiogram show?”
	“The electrocardiogram performed 1 hour ago shows atrial fibrillation with a ventricular response rate of 183.”
“So maybe she has hyperthyroidism. Alexa, order thyroid function tests.”
	“I’m sorry, Dave, I’m afraid I can’t do that. Ms Jones had this test performed less than 6 months ago and hospital policy…”
“Alexa, override.”
	“Okay. Thyroid function tests ordered.”
“Alexa, schedule Ms Jones for electrocardioversion.”
	“Okay. Electrocardioversion scheduled.”

The system has access to extensive information about the patient but is unable to filter it in a way that is appropriate to the immediate need. The system issued an inappropriate alert regarding a duplicate, but necessary laboratory test, while it failed to issue an alert about the electrocardioversion order because it could not infer that the condition (atrial fibrillation) was not of recent onset.

[NB: While subsequent electrocardioversion was successful in reversing the patient’s abnormal heart rhythm, the procedure was complicated by a pulmonary embolism which might have been avoided if the patient had been treated with 1 month of anticoagulation. Unfortunately, the system did not issue an alert for evidence of subacute (nonacute) onset atrial fibrillation, nor did it recommend a cardiology consult—steps that physicians sometimes fail to take in treating atrial fibrillation].²⁰

I believe that “why” is not only the question, but also the answer. When we examine where EHRs outperform their paper-based predecessors (eg, laboratory data summaries, drug interaction alerts, and automated billing), the common fundamental principle is that data such as laboratory orders, medication history, and problem lists are represented in coded, structured forms, using controlled terminologies.⁴ But an important part of the patient’s story is still lacking such formal representation: the clinician’s reasoning. I refer to this as the “why” in patient care.

Why is Ms Jones having palpitations? Why is her heartbeat irregular? Why is Dave ordering thyroid function tests? Why is he ordering anticoagulation therapy? The association of symptoms with physical findings, the differential diagnosis, and the rationale for selection of tests and treatments may seem obvious; but such reasoning is beyond today’s EHRs, other than through natural language processing of narrative text and statistical associations from sets of "big data." Such approaches are appropriate for population studies but are less useful in the care of individual patients where a high degree of accuracy is required. As a result, EHRs are unable to identify the precise relationships among our observations and actions—the “why” behind our interpretations and strategies.

Fifty years ago, in his 2-part landmark paper on the problem-oriented medical record,^5,6 Larry Weed recommended reorienting physicians away from documentation tasks to allow them to focus on cognitive tasks. His work led to a revolution in how medical records are written but the cognitive aspect received less emphasis. With today’s pressures for increasing patient care throughput and decreasing work hours for house staff, documentation of clinical reasoning in narrative text is a lower priority and formal representation is practically nonexistent.⁷

Consider, for example, if a clinician’s differential diagnosis was recorded in the same manner as a problem list, with each item enumerated and captured with a controlled terminology. It would then be possible for a decision support system to identify what might be removed from the list (based on evidence in the record), suggest additional conditions that may have been overlooked (based on evidence in a knowledge base), and provide the best evidence for diagnostic strategies. Similarly, when the goal is made explicit (eg, anticoagulation for a specific indication), appropriate knowledge resources can be brought to bear for “just in time” decision support and an appropriate, comprehensive set of interventions can be ordered automatically (see Table 2). In addition, because the differential diagnosis and goals are structured, the EHR can detect when they are missing and assist with their inclusion. The addition of “why” in the EHR will mean that the data we collect can be used to make our medicine more personalized and, thus, more precise. These new data will also better inform a “learning health care system.”⁸ For example, knowing why a drug was chosen or discontinued will be much more useful for learning about it’s efficacy than simple co-occurrence of a condition and a pharmacy order. Table 3 offers additional examples of potential benefits for adding “why” to the EHR.

Table 2.

A second hypothetical interaction between the physician and the EHR via a “smart speaker” user interface

----------Initial Visit---------
“Alexa, Ms Jones has had shortness of breath for a month, developed palpitations today, and now has an irregular heartbeat with a rate of about 135. I think her palpitations are due to her arrhythmia. Has she ever had an arrhythmia before?”
	“No arrhythmia is listed in any of the problems lists from her past 25 years of health records. Reports from the health information exchange includes Atrial Fibrillation on a problem list from 5 years ago, but no additional information is available.”
“Alexa, please order an electrocardiogram.”
	“Okay. I have ordered an electrocardiogram.”
----------2 Hours Later ---------
“Alexa, what did the electrocardiogram show?”
	“The electrocardiogram performed 1 hour ago shows atrial fibrillation.”
“So maybe she has hyperthyroidism. Alexa, order thyroid function tests.”
	“Okay. Thyroid function tests have been ordered.
	In addition to hyperthyroidism as a possible cause of her atrial fibrillation, you may wish to consider heart valve disease and pulmonary embolism. Would you like me to order an echocardiogram and a D-dimer test?”
“Yes.”
	“Okay. I have ordered an echocardiogram and a D-dimer test.”
“Alexa, please schedule Ms Jones for electrocardioversion.”
	“I’m sorry Dave, I’m afraid I can’t do that. You associated her 1-month history of palpitations with her current arrhythmia, suggesting her arrhythmia has been present for longer than 1 month. Hospital policy recommends 1 month of anticoagulation prior to cardioversion. Would you like me to order anticoagulation?”
“Yes.”
	“Okay. Given that Ms Jones is known to have CES1 variant rs2244613, usual anticoagulation with dabigatran is contraindicated. Second line therapy is warfarin sodium. Since you are treating her for prophylaxis of arrhythmia-related thromboembolic disease, the recommended target INR is between 2.0 and 3.0. Would you like me to initiate the standard therapeutic plan with warfarin sodium based on her weight, gender, and genetic variants?”
“Yes.”
	“Okay. Warfarin sodium, a follow-up prothrombin time test, and an appointment in anticoagulation clinic have been ordered. An order has also been placed for cardioversion for 1 month from now. Would you like me to order digoxin for heart rate control?”
“Yes.”
	“Okay. I ordered digoxin 0.125mg daily.”
----------Two Months Later ---------
“Alexa, Ms Jones is no longer having palpitations but still has shortness of breath. Her heartbeat today is regular at 60 beats per minute. What has happened since I last saw her?”
	“Regarding her atrial fibrillation, her echocardiogram showed stenosis of the mitral and aortic valves. Her D-dimer was 2.0mg/L, her T4 was 25ug/dl and her TSH was 0.0mU/L. Her warfarin was continued, and INR values have been between 2.0 and 2.5. She underwent successful cardioversion 1 month ago. Her electrocardiogram this morning shows normal sinus rhythm with a rate of 60 beats per minute.”
“Alexa, please order a thyroid scan.”
	“Okay. I have ordered a thyroid scan. You noted that her shortness of breath has continued. You have linked this symptom to her atrial fibrillation. Now that her atrial fibrillation has resolved, would you like to consider other possible causes?”
“Yes.”
	“Okay. Her normal D-dimer and chronic presentation make pulmonary embolism less likely. She has no history of pulmonary disease and does not smoke. She has documented aortic valve stenosis which can cause shortness of breath. Would you like me to order a cardiology consult?”
“Yes.”
	“Okay. I have ordered a cardiology consult.”
“Thank you, Alexa.”
	“You’re welcome, Dave.”

In this case, the EHR has information about the temporal nature of the patient’s symptom, knowledge that the symptom is the reason for the electrocardiogram and therefore is able to associate the symptom with the diagnosis (atrial fibrillation). Note that the system is able to filter the patient’s record based on knowledge of a condition of interest, rather than searching for a text phrase, and that the duplicate order alert was suppressed because of knowledge about the recent change in the patient’s condition. However, this time an alert regarding the need for anticoagulation was issued based on the inference of the duration of the patient’s condition. The system was also able to recommend appropriate therapy, including pharmacogenomic-based dosing, based on the reason for the therapy, and alert the physician to a possible undiagnosed problem, with a suggested differential diagnosis.

Table 3.

Some examples of the types of computable information that could be added to EHRs and the advanced functionality they would enable, along with the informatics research challenges that will need to be addressed

“Why”	Uses	Research Challenges	Knowledge Requirements
Relating symptoms, signs and problems to each other	Automated decision support for diagnosis, management, and monitoring of clinical condition	Controlled terminology; relationship semantics; user interface design (anticipatory data entry, graphical, speech)	Expert diagnostic system knowledge base
Explicit listing of differential diagnoses for problems	Diagnostic decision support tools to add and exclude conditions and to suggest differentiating diagnostic tests	Using data captured for differential diagnoses to reduce need for other data entry such as orders and problem lists	Expert diagnostic system knowledge base
Relating orders to specific diagnoses	Application of guidelines and disease-specific order sets; integration of pharmacogenomic-based recommendations; automated workflow plans for follow-up appointments, referrals, and diagnostic and therapeutic interventions	Development of method for executing computable guidelines; adapt standard order sets to local settings; expansion of EHR capabilities to support intelligent workflow	Computable guidelines; expanded order sets
Relating problems to outcome states	Monitoring plans; integration of end-of-life planning into workflow	Expansion of EHR capabilities to support intelligent workflow	Formal representation of care plans
Patient preferences for prioritizing outcomes	Personalized precision medicine	Controlled terminology; user (patient) interface design; expansion of EHR capabilities to include the patient as user	Formal representation of outcomes; identifying relations between plans and expected outcomes
All of the above	Suppression of false-positive alerts	Modification of alert logic to consider situational awareness (eg, supress warnings about duplicate laboratory tests if the patient has a new problem relevant to the laboratory test)	Revision of existing medical logic modules
All of the above	Filtered data retrieval	Reasoning with semantic relationships	None
All of the above	Automated progress note generation	Reasoning with semantic relationships; automated text generation	Formal representation of note structure
All of the above	Phenotype determination for research studies	Reasoning with semantic relationships	Phenotype definitions that can take advantage of semantic relationships
All of the above	Learning health system	None!	None!

Simply admonishing clinicians to write better notes and require additional, redundant data entry into some new documentation feature, however, is unlikely to succeed. Instead, our EHRs need to move away from being “billing diaries” and evolve into next-generation smart systems that actively participate in the management of the patient.⁹ In such a system, the clinicians would provide not only their orders, but also their reasoning in actionable form. The effort required for this new type of documentation would be offset by eliminating the need for writing the redundant, bloated, low-information clinical notes that plague us today, reducing the order entry workload through anticipatory work plans, and decreasing the fatigue caused by false-positive alerts.

This next-generation EHR will not be realized through simple software upgrades. Basic informatics research is needed to understand how “why” should be represented in a computable form,¹⁰ how to develop data entry mechanisms to capture and study it,¹¹ and how to use clinical reasoning insights to improve patient care processes,¹² including automated decision support systems based on formal ontologic principles.¹³ Fortunately, significant advances are being made in the techniques needed to support such research, including ontology development,¹⁴ natural language processing to help us extract the limited reasoning currently captured in clinical text,¹⁵ and the development of voice-based user interfaces.¹⁶ New technologies, such as Substitutable Medical Applications and Reusable Technologies (SMART)¹⁷ and Fast Healthcare Interoperability Resource (FHIR),¹⁸ now exist for creating tools to capture and use reasoning information, and for integrating the tools into existing EHRs and workflows, respectively.

Additional challenges will involve establishing a pragmatic evolutionary pathway from the current EHRs, in which we are currently deeply invested, and transforming the training of clinicians to prepare them to understand and collaborate with next-generation smart EHR systems. Patients will play a role as well, contributing to the parts of their record they know best, such as past medical history, family history, current medications, and, perhaps most importantly, goals.¹⁹Table 3 provides some examples of the informatics research and expansion of formal knowledge bases that will be needed.

There is no question that the “to-do” list to realize this vision is daunting. We will need to design a new type of clinical documentation, develop tools for its capture, and alter decades-old cultural norms for note-writing practices to institute their use. I believe that a strong foundation of informatics research can get us there but will require the support of many stakeholders. This might include traditional funders of informatics research (eg, the National Library of Medicine and the Agency for Health Research and Quality), EHR vendors, private and federal health care payors, as well as any organization interested in improving the utility of data in EHRs, such as the other 26 institutes and centers at the NIH and private foundations. It will also require the buy-in of payors and regulators, who will need to revise their notions of what constitutes clinical documentation. None, to my knowledge, have identified improving the data content of the EHR as a goal, although it would seem logical do to so given their stated objectives. Their enlightenment may need to await the development of significant demonstration projects—a catch-22. Perhaps it is time for a special issue of JAMIA devoted to the topic (The author credits an anonymous JAMIA reviewer for this suggestion).

The extra effort needed to express and record the “why” behind our clinical interpretations and decisions will be repaid in many ways, not the least of which will be improved coordination of all members of the health care team. Doing so in a structured form will allow the EHR itself to become a full member of the team. Developing practical data capture methods represents a worthy challenge for informatics researchers, one that will enable them to build and integrate next-generation, situationally aware clinical decision support tools into more effective, efficient, and safer patient care processes. The scenario in Table 2 and the wish list in Table 3 are intended to focus the discussion of possible types of clinical reasoning that might be represented in the EHR, the challenges to their capture, and their potential benefits. The clinical informatics community has already been working on many of these problems and approaches for years. It is time to evolve our EHRs to capture the “whys” of patient care to fully deliver on the promise of those efforts.

FUNDING

Dr Cimino is supported in part by research funds from the UASOM Informatics Institute the Center for Clinical and Translational Sciences (CCTS) under grant UL1TR001417 and from the EASI-PRO grant U01TR001806 (under subcontract with Northwestern University), both from the National Center for the Advancement of Translational Science (NCATS).

Conflict of interest statement

None declared.