When building software, requirements are everything.
And although good requirements do not necessarily lead to good software, poor requirements never do. So how does this apply to electronic health records? Electronic health records are defined primarily as repositories or archives of patient data. However, in the era of meaningful use, patient-centered medical homes, and accountable care organizations, patient data repositories are not sufficient to meet the complex care support needs of clinical professionals. The requirements that gave birth to modern EHR systems are for building electronic patient data stores, not complex clinical care support systems–we are using the wrong requirements.
Two years ago, as I was progressing in my exploration of workflow management, it became clear that current EHR system designs are data-centric and not care or process-centric. I bemoaned this fact in the post From Data to Data + Processes: A Different Way of Thinking about EHR Software Design. Here is an excerpt.
Do perceptions of what constitutes an electronic health record affect software design? Until recently, I hadn’t given much thought to this question. However, as I have spent more time considering implementation issues and their relationship to software architecture and design, I have come to see this as an important, even fundamental, question.
The Computer-based Patient Record: An Essential Technology for Health Care, the landmark report published in 1991 (revised 1998) by the Institute of Medicine, offers this definition of the patient record:
A patient record is the repository of information about a single patient. This information is generated by health care professionals as a direct result of interaction with the patient or with individuals who have personal knowledge of the patient (or with both).
Note specifically that the record is defined as a repository (i.e., a collection of data). There is no mention of the medium of storage (paper or otherwise), only what is stored. The definition of patient health record taken from the ASTM E1384-99 document, Standard Guide for Content and Structure of the Electronic Health Record, offers a similar view—affirming the patient record as a collection of data. Finally, let’s look at the definition of EHR as it appears in the 2009 ARRA bill that contains the HITECH Act:
ELECTRONIC HEALTH RECORD —The term ‘‘electronic health record’’ means an electronic record of health-related information on an individual that is created, gathered, managed, and consulted by authorized health care clinicians and staff. (123 STAT. 259)
Even here, 10 years later, the record/archive/repository idea persists. Now, back to the issue at hand: How has the conceptualization of the electronic health record as primarily a collection of data affected the design of software systems that are intended to access, manage, and otherwise manipulate said data?
At 5am, Mr. A rolls onto the medicine floor: the fifth and final new patient to be admitted that night. The 70-year-old is well-known to our institution from his near-monthly hospitalizations and his primary care doctor, cardiologist, podiatrist, ophthalmologist, and both of his endocrinologists all work in-house. Unfortunately, for the intern admitting him (and for Mr. A), this translates into a few hours-worth of prior blood test results, MRI reports, visit notes, and discharge summaries to peruse. Where to begin? How to find the key details buried in this hoard of information?
