- System shall assist with gathering information from various sources (TBD) at the point of care
- System shall assist with information recording at the point of care (needs more specificity)
- System shall retrieve and accept information from external sources
- System shall respond to all external legitimate requests for information
- System shall have the ability to access published clinical information (consider buying)
- System shall assist with synthesis of said information
- System shall assist with patient-doctor relationship building
- System shall not make the task harder to perform for the user
No more beating around the bush then. At this point we must tackle information recording at the point of care, or as fondly known by its practitioners, data collection (usually followed or preceded by unprintables). Note that we are insisting on usage of the term “information” instead of “data”. As far as computers are concerned, information comes in only one flavor: zeros and ones. We, on the other hand, have become accustomed to defining information as structured or unstructured, where structured information is considered computable, i.e. it can supposedly be analyzed by computers. This however, is not a material difference because computers can analyze all information to various degrees, depending on analyzing software capabilities. Primitive software is only capable of analyzing information provided in a predefined (in the software) content and format, but as software science advances, computers are becoming less dependent on the user to predigest and preformat their input into the software (at one time, you actually had to enter electrical signals for ones and zeros in order to have the computer do anything useful). So the structured vs. unstructured information debate is all about yesterday’s computers vs. tomorrow’s computers. We will build our imaginary EMR for tomorrow’s computers, some of which are already here today. This is our first technology decision: We are requiring a contextual parser and processor of information that can accept input from all known modalities (keyboard, mouse, microphone, camera/video, stylus, touch/gestures, and electronic interface). Here we refer to our #1-d requirement, which seems pertinent, and task an imaginary system analyst to call IBM.
We still have to design the front end though, so information from the encounter can be transferred to our hopefully smart processor. We are reminded of our tongue in cheek #4 requirement (or constraint really), and in order to fulfill this requirement, we will need to evaluate how our users currently document encounters, with the understanding that a large number of physicians are not using computers to document, and an even larger number of doctors use computers and hate doing so. Hence, our gold standard, or limiting factor, for #4 is the paper chart. But even the paper chart comes in all sorts of shapes and flavors:
- Blank sheet of paper allowing free hand documentation
- Structured forms with predefined questions, which may contain one or a combination of:
- Questions with predefined multiple choice answers
- Open ended questions
- Room for free hand written answers
- Room for free hand notes
- Anatomical drawings for annotation
- Dictation devices allowing transcription of voice summaries into the chart
- Abstracted lists of factors deemed important (medication list, problem list, allergies, etc.)
Most software programs can be divided into three parts, or layers: the data layer, where all the information is stored, the display layer, which is what users see and interact with, and the business layer, which controls the application and is the de facto processing brain of the software. As is the case with people, the beauty of software comes from within. Usability of software products is much more dependent on the intelligence and abilities of the controller brain than it is on the lipstick of the display. The things that are causing heartburn to current EMR users were created precisely to compensate for the feeble brains of the software. Since we already made a technology decision to splurge on the best and most sophisticated software brain available, we will abstain from stealing valuable time from the patient and from the art of observation. Additionally, we will not attempt to shorten the time required for a physician to record observations in brief and plain language (as difficult as that may be). We note here that unlike other professions, historically, physicians did not employ stenographers during patient encounters and recording observations was very much part of the science of medicine. Therefore our information gathering user interface will have the following features and functionalities available:
- Ability to record and translate to text all verbal exchange during a patient encounter. This includes the ability to identify the parties engaged in dialog and appropriately classify the information as objective or subjective (patient reported), and the ability to accept addenda to an encounter through multiple modalities (in case you are wondering, this technology already exists).
- Ability to accept electronic input from all medical equipment used in the practice, without any human intervention.
- Ability to create electronic forms dynamically, from scratch or based on scanned paper forms, including drawings, and ability to modify these as needed.
- Ability to accept input from keyboard, mouse, pen/stylus and voice for all form fields without exception and without prior setup or notice.
I can practically see the raised eyebrows of those who want to measure, analyze and provide clinical advice to practicing physicians, contending that most EMRs fail to be useful precisely because they are just electronic paper charts. Strangely enough the much touted electronic media and all its blogging/social media offshoots are doing quite well in spite of being just electronic newspapers and pamphlets, and this revolutionary transition would have failed miserably if we required authors to create content from dropdowns and checkboxes. The true power of transitioning paper to electronic media comes from the inherently better accessibility and portability of electronic media, and from the ability to insert ever improving computerized synthesis underneath the familiar look and feel of paper. As we move on to our #2 requirement and define our specifications for synthesizing and serving information, it should become apparent that although inconveniencing the user is one solution to the very difficult problem of information synthesis, it is most likely not the best solution.
We did not cover here in any detail the exchange of information imposed by 1-b and 1-c, since simple technologies for both functionalities exist today, particularly if we don’t insist on specific structures for our exchanged content, and we are not. Since our 1-a requirement proved to be a handful, and we only scratched the surface in most general terms, we will postpone discussion on requirement #2, which includes not only intelligent synthesis of information, but also serving the results to users at the right time and in the right place, to Part IV, and we will add Part V to deal with the fuzzy requirement expressed by #3. We have a long road ahead of us, and this is just make believe design...