De Novo EMR Design Part II: The Quest for Information

The Edwin Smith papyrus ca. 1500 BCE

In Part I of this series, we engaged in a design exercise for an imaginary software product that has no stated (or hidden) purpose other than to improve patient care. Following our initial definition of patient care, we formulated three general requirements and several constraints, none of which were specific enough to start building software tools from. The next step in our journey will break down each requirement into more specific tasks. What follows below will seem like an unnecessary and laborious statement of the obvious to some. However, I would submit that the careless bypassing of fundamental analysis is precisely what led us to where we are today, and even if we are forced to cut corners eventually, it is imperative that we define all corners prior to cutting them, instead of feigning shock and surprise after the fact. So without further ado, let’s start where we left off.

System shall assist with gathering information from various sources (TBD) at the point of care

The first thing we need to do before we begin gathering anything is to figure out the sources of information that may be able to contribute to patient care, and the essence of each contribution, which will serve as a guide to any prioritization efforts that may be required down the road.

1. The Patient – You cannot provide patient care without a patient, and any activities undertaken without adequate input from the patient (or proper surrogate) do not fit our definition of patient care.  Therefore the patient is the primary and most important source of information. Information gathered from the patient can be subjective or objective. Subjective is not a derogatory term that implies lack of importance, and quite the opposite is true in most cases. Subjective information is the patient’s point of view, without which it would be quite impossible to do anything that qualifies as patient care. Objective information is something observed or measured by someone other than the patient, but the lines can be blurred when observation depends on patient voluntary response (e.g. range of motion). Information from the patient is available through several modalities and can be solicited or unsolicited.
   1. Narrative – This is the patient’s story, historically delivered in person, but more recently also available through phones and now through electronic communications over the Internet. Originally, large parts of the patient story were known to the doctor who was part of the community he served, but to compensate for societal lack of wisdom, increasingly larger portions of the narrative are being solicited through paper forms, clerical assistants to physicians and most recently computer software (see below). In most cases, the patient still has the opportunity to relay unsolicited and unstructured information to the doctor, but the allotted time for this activity is shrinking by leaps and bounds. The patient narrative delivered in person has value beyond the story itself, as it exposes other forms of information that can be processed by humans, such as demeanor, tone of voice, body language, general appearance and even smell. It is worth noting here that this sensory exchange of information is bi-directional and the patient is also gleaning important information about the physician. Therefore, at this point in our analysis, we will make a note to consider this expanded definition of narrative when addressing our third general requirement dealing with patient-doctor relationship building. 
   2. Examination – The physical examination of the patient, once the hallmark of practicing medicine, is somewhat diminishing in its diagnostic importance nowadays. Palpation, auscultation and manual handling of the patient is being surpassed by machines that can accurately “see” inside the patient and analyzers measuring biophysical markers and functions that could only be hypothesized by inference or educated guess. Here we are going to use this new and expanded definition of patient examination to include input from any available equipment at the point of care (others will be considered in #3 below). However, as was the case with the narrative discussion above, the traditional “laying on of hands” has implications to our third general requirement. Since we are after all a type of animal, consensual agreement to intrusion by another person into our personal space (and beyond) implies the establishment of an uncommon level of trust and, in some cases, may have healing effects in and of its own. Therefore, we will make the same note as above.
   3. Remote asynchronous – Although historically doctors acquired quite a bit of information about their patients asynchronously, and largely unsolicited, by virtue of being part of the same social community as their patients, those days are mostly gone, and here we will consider newer electronic forms of communication. From email to text messages to patient portals and direct transmission of monitoring data, patients today have multiple asynchronous venues to relay information to their physicians. These communication channels are used, when available, mostly for inquiries and requests for service, but they can also contain information pertinent to patient care. Monitoring data in particular (e.g. glucose levels, blood pressure, peak flows, etc.), whether in electronic or paper format, and subject to our constraint stating that patient care is not equivalent to lifestyle coaching, is obviously pertinent to caring for an individual patient, and in all cases this form of communications has implications for our third general requirement. We note this, and move on to the next item on the list.
2. The Chart – Before the chart, we had “papers”, ledgers, index cards and other less common methods of recording the most salient points of encounters with patients over time. This source of information forces us to consider the corollary to information gathering, which is the voluntary recording of information by the user. This is a fork in our design road. We can assume that information created as a byproduct of patient care is recorded by an external product, or we can add this capability as another requirement for our patient care software. We choose the latter and therefore add a requirement as follows: System shall assist with information recording at the point of care. This requirement will need to be further broken down, in a future iteration, to account for information sources as outlined in #1 above.
3. Other Facilities – In the world of modern day medicine, and primary care in particular, physicians providing patient care must bring into account information generated by others currently or previously engaged in the same activities. This information may be solicited by the physician, in the form of orders to diagnostic facilities or specialty consults, or unsolicited if the patient sought and received treatment at other facilities in the past, which may or may not be pertinent to the care provided by our user. There are two general categories of medical information generators that should be considered:
   1. Diagnostic, Ancillary and Administrative Facilities – These include laboratory and imaging services purveyors as well as pharmacies and any other existing or future holders of information pertinent to patient care. Our product will be required to both solicit and accept unsolicited information from these entities.
   2. Care Providing Entities – This is the entire universe of medical service providers surrounding our physician and patient interaction. Inpatient facilities, long term care facilities and other physicians, are included in this category and we become acutely aware of the need to build our software in a way that it can communicate with a large and extremely ill defined spectrum of other software and traditional partners. Summarizing both categories leads us to state that the System shall retrieve and accept information from external sources.
   This item introduces another requirement originally put forward in the Holy Bible as “…all things whatsoever ye would that men should do to you, do ye even so to them” [Matthew 7:12]: System shall respond to all external legitimate requests for information. Note that here, and immediately above, we are not requiring the system to merely assist the user with this task, but instead we are requiring that the system takes full responsibility for exposing and/or sending appropriate information to other entities (the term appropriate or legitimate is an important constraint).
4. Literature – The final source of information pertinent to caring for patients is of course the science of medicine and the recorded experience of those similarly engaged in providing or receiving care from a medical professional. This body of knowledge is approaching magnitudes and velocities that are impossible to collect, analyze and entrust to human memory, particularly on the fly while caring for any one patient. We classify reliability and importance of clinical information, based on accepted practices, in descending order as follows:
   1. randomized controlled trials
   2. controlled trials, no randomization
   3. observational studies
   4. opinion of expert panel
   5. clinical practice guidelines & recommendations
   The first thing to note here is that unlike information to be gathered from all other sources, literature is not patient specific. To satisfy our fourth constraint prohibiting us from treating patient care as a commodity, information gathered from literature will require significant processing to make it useful when caring for an individual patient. We will therefore split this requirement into two parts: the first, System shall have the ability to access general published information, to be addressed here and the second, involving analysis and processing, to be addressed through our requirement pertaining to synthesis of gathered information. Although this is not the proper time to make technology decisions, we are noting here that gathering information from published materials is probably something we are going to buy off the shelf, instead of building our own module from scratch, as long as we can impose our requirements and, most importantly, our constraints on any commercially available software package. We will make a note to that effect here, and elaborate on it when considering our next general requirement which deals with information synthesis.

To summarize, our first requirement yielded several insights for future consideration and four sub-requirements as follows:

1. System shall assist with information recording at the point of care (needs more specificity)
2. System shall retrieve and accept information from external sources
3. System shall respond to all external legitimate requests for information
4. System shall have the ability to access published clinical information (consider buying)

Funny how certain things rise to the top and impose themselves on the software if patient care is the driving concern, and an orderly design process is undertaken.

And on this note, let’s pause, since we are quickly exceeding the boundaries of polite imposition on readers’ time. If you were expecting to be knee deep into buttons and font sizes by now, please understand that the user interface is the last thing to address in proper software design. If you paid close attention to the narrative so far, you should have noticed that we never mentioned buttons, screens, fields or anything of the sort. We cannot, and should not, define the problem in terms of its solution, just like you are not defining the patient complaint in terms of currently available prescription drugs. We will apply solutions, like buttons and pick lists, or maybe build new things that don’t exist just yet, after we completely understand the problem and the preferences of our users. The same can be said to those expecting discussion on standards, transport protocols and terminologies. We are not at a point where we should constrict our analysis to existing technology solutions, which by the way, are not serving us very well currently, this being the rationale for engaging in this thought exercise in the first place.

With this in mind, we will move on to Part III: A Better Haystack, where the need to synthesize and present the information we are gathering will be examined, forcing us to add specificity to our existing requirements (#1 should be most enlightening), before concluding our first design iteration in Part IV: Continuous Healing Relationships.