LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 510.84 XJtGr KO.C43-M8 cop- 2 The person charging this material is re- sponsible for its return to the library from which it was withdrawn on or before the Latest Date stamped below. Theft, mutilation, and underlining of books are reasons for disciplinary action and may result in dismissal from the University. UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN 0) ki- ll L161 — O-1096 Digitized by the Internet Archive in 2013 http://archive.org/details/briefencounterre648warn Report No. UTUCDCS-R-7U-6U8 yyii 1 1, THE BRIEF ENCOUNTER REVIEW: AN INVESTIGATION IN GRAPHIC COMPUTER-BASED MEDICAL RECORD REPORTING SYSTEMS by Henry Albert Warner C / May, 197^ Report No. UIUCDCS-R-7U-6U8 THE BRIEF ENCOUNTER REVIEW: AN INVESTIGATION IN GRAPHIC COMPUTER-BASED MEDICAL RECORD REPORTING SYSTEMS by HENRY ALBERT WARNER May, 197^ Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 iii Acknowledgments The author would like to express his thanks to Dr. R. L. Johnson and Dr. S. R. Ray for their assistance in preparing the computer oriented portions of this work, to Dr. B. T. Williams and Dr. D. F„ Schultz for adding medical credibility and to Mr. D. H. Mueller for his assistance in developing the data management routines. Appreciation is also expressed to Miss Chris Fleener and Mrs. Charlotte Conley for typing the manuscript, to Mr. R. T. Gladen and Mr. R. F. Macfarlane for preparing the illustrations and to Miss Renee Krasnow for proofreading the manuscript. A special word of appreciation is also due my wife, Cheri, for her assistance in editing the manuscript. IV TABLE OF CONTENTS Page Acknowledgments iii List of Tables , v List of Figures vi 1 . INTRODUCTION 1 2 . MEDICAL RECORD REPORTING (THE COMPLETE SYSTEM) 7 3. THE BRIEF ENCOUNTER REVIEW 11 4. MANIPULATION OF THE RECORD 21 5 . PROGRESS NOTES 34 6. INFORMATION RELATED TO THE PROBLEM LIST 45 7 . MEDICATION AND RELATED INFORMATION 54 8. LABORATORY RESULT REPORTING 65 9. HISTORIES 75 10. ODDS AND ENDS 81 11. SUMMARY AND CONCLUSIONS 82 List of References 85 List of Tables Page 6.1 Table of System Responses to User Requests for Complete Listing or Selectors by Topic Under Various Data Conditions 53 vi List of Figures Page 1.1 An Overview of the PLATO IV-based Problem Oriented Medical Information System. Brief Encounter Review Software Resides Between the PLATO IV Unit and the User 3 3.1 The Brief Encounter Review Summary Display 12 3.2 Standard Frames and Labels Used in the Presentation of the Brief Encounter Review Summary Display 18 3.3 Schematic Representation of Output Processing with the Brief Encounter Review Software Represented as the Ideal Intelligent Software Component 19 4.1 Standard Touch Selector Including Identification Box Activator . . 22 4.2 Standard Touch Selector with Null Link Indicated. . 24 4.3 Brief Encounter Review Summary Display Including Frames and Labels with Touch Link Areas Indicated. 25 4.4 Tree Representation of Linking Structure Available to the User from the Summary Display „ 26 4.5 Finite State Representation of Touch Link Activation 32 5.1 A Complete Progress Note Presented in a Single Display 35 5.2 First Part of Progress Note Completed in Figure 5.3 37 5.3 Last Part of Progress Note Started in Figure 5.2 „ „ 38 Vll List of Figures (Continued) Page 5.4 With a Hypothetical Display Limit of 100 Characters, This Progress Note Has Character Length of: "S"=180, "0"=90, "A"=285 and "P n =87 Characters. Circular, Two-way Linking is Also Indicated „ 40 5.5 Schematic Representation of Progress Note Storage 42 5.6 Flow Chart for the Presentation of Multiple (and Single) Part Progress Notes 44 6.1 Display of Complete Listings for Problems and Medications 46 6.2 Problem Selector Display Including Touch Boxes for Linking to Appropriate Related Problems 48 6.3 Display Showing a Current Problem and those Problems Related to it 49 6.4 Subtree Representation for Accessing Progress Notes via the Problem Selector 50 7.1 Warning Page Showing the Patient's Allergy to Penicillin 55 7.2 Graphic Representation of a Patient's Medication History. Overlapping Prescriptions and Prescription Durations are Clearly Represented 58 7.3 Patient Report for the Medication, Aspirin, with Tabular Information in the Upper Right - Hand Corner <,..,, 59 7.4 Display of Figure 7.3 with a Dosage Graph for the Medication Replacing the Tabular Data. The Dosage Graph was Obtained when the User Touched the Tabular Information. The Remaining Display was Unaltered 60 7.5 Subtree Representation for Accessing Information Regarding Patient Medications 61 viii List of Figures (Continued) Page 8. 1 Laboratory Report Selector 66 8.2 Normalized Graphic Report of Six Blood Chemistry Tests Taken From an SMA - 12/60. Population Standard and Individual Patterns are Indicated for Each Test 68 8.3 Various Symbol Sizes Used in the Blood Chemistry Display to Indicate Analytical Variation Inherent in Each Laboratory Test 70 8.4 Blood Chemistry Supporting Graph for Albumin Tests 71 8.5 Subtree Representation for Accessing Laboratory Reports via the Laboratory Selectors 72 9.1 The History Report Selector „ 76 9.2 History Subselector for Genetic Histories 77 9.3 Genetic Tree Representation of Patient's Family with Those Who Complain of Headaches Indicated 78 9.4 Subtree Representation for Accessing Information Concerning the Patient ' s History 80 11.1 An Overview of the Brief Encounter Review System with the Linking Structure Indicated 83 1 . INTRODUCTION Traditionally, medical data pertaining to individual patients is manually processed in a raw alpha-numeric form. Two types of problems are apparent in this method: those that concern management of the patient and those that concern management of the record. The first type includes those problems which directly affect patient care. For example, in a handwritten record where entries are sequentially made by several indi- viduals, the extraction of important medical information is often difficult, Much time may be required to locate a specific portion of the record. In addition, the hard copy record makes simultaneous usage of the record by two or more people impractical. Concerning hard copy record reliability, ". . .at any given time about 107 o of the records may be missing and about 17o are, in effect, permanently lost to the system, largely due to mis- filing." The second problem type of the present system concerns the management of the record. For example, large storage areas are required which must be heated, lit and serviced. The hard copy record must be moved, either as a unit or in sections, from person to person, ward to ward, etc. Clerks and secretaries are required to make entries. A sufficient staff is required to provide twenty-four hour medical record retrieval seven days per week. Finally, all the above items reflect a major portion of record management cost. One can assume that the primary functions of any medical record include: (1) acting as the main vehicle of communication concerning a patient's care, (2) acting as the permanent document for investigative procedures and treatments used to define and solve the patient's problems, (3) aiding the physician's memory when reviewing a patient's care, and (4) serving as a legal document concerning a patient's care. An examination of the problems with current medical record procedures and goals of a computer-based medical record system yields some requirements of the computer-based medical record system. Reliability comparable or superior to that of the manual record is essential to the computer-based medical record. Since identification of the user making entries may no longer be reflected in handwriting, style of entry or signature, an identification system or "signature proxy" must be developed. The use of plastic cards acceptable to the system with name and identification number of the user might be one solution. In addition, the system should be capable of generating a medical summary for each record. Also, the terminals must be mobile or sufficiently inexpensive to permit "terminal availability to follow the user." Much time can be lost if the user must come to a terminal. Regarding system performance, visual displays must be developed and presented quickly, and hard copy capabilities will be required for sending records to areas where the system is unavailable. Finally, error correction should be made by amendment rather than deletion and insertion. The goal here is to provide legal protection for each physician user. A successful computer-based medical record system must provide sufficient flexibility for individual preferences and needs and still consider all the above features. Research in the area of computer-based medical record systems was initiated by the medical community's interest in the development of a Source Oriented Medical Information System (SOMIS) (see figure 1.1). SENSORS ADD TERMINALS DATA ACQUISITION AND DISPLAY SYSTEMS NETWORK DATABASE FROM/TO TERMINALS <: Laboratory Equipment Pocketsize Terminal (Mcdicorder) FROM/TO SENSORS c PLATO IV Terminal Intelligent Terminal PLATO IV 1000 - 2000 User LARGE NODE LAB DATA PROCESSOR (PDPU/45) | (PDP11/45) 16-32 User LOCAL STORAGE ANTS — IMP - - OTHERS RELATIONAL DATABASE Figure 1.1. An Overview of the PLATO IV-based Problem Oriented Medical Information System. Brief Encounter Review Software Resides Between the PLATO IV Unit and the User. A component of the SQMIS project is the software package capable of generating a current summary of the medical record contents. The function of this summary is to act as an interface between the total record and the user. Summaries are generally available only in hospital records where a summary is a required part of each record. Although generally considered useful, summaries are usually not created when not required due to the time requirement. Aside from directly assisting medical care delivery by improved data retrieval and presentation, the collection of individual patient records stored together in the computer produces a broad data base suitable for medical research. Because the computer is able to quickly examine many past entries concerning a given test, the patient's record serves also as an individual data base which can be used to determine individual 2 3 norms. In giving consideration to the development of a Computer-based Medical Record Review system, one can readily see that the ability of a system to produce graphic displays is desirable as an aid to the user in the interpretation of the available data. Examples of quantitative medical data which might best be described in graphic form include pulse rate, temperature, respiratory rate, blood pressure, fluid balance and laboratory test results. Departmental reports such as those from surgical, renal, cardiac and intensive care units may also be best represented in graphic 3 form. Also, qualitative and semiquantitative information as found in progress notes can often be presented in graphic form. The purpose of this thesis research is to consider requirements and exemplary methods for displaying machine-stored patient medical data with a substantially decreased specific data access time over manual processing and with enhancement of meaning of the alpha-numeric data through the use of standard format and graphics. In that the topics discussed in this thesis are related to output display of stored data, the reader may assume that all data used for output presentation has been stored in computer storage devices through source oriented data collection procedures. Generally, the methods for introducing data to the machine are not discussed. Discussion of the data organization as it is presented to the output processor is included where appropriate. To aid in understanding the problems as well as the advantages of computer processed patient medical data, many of the topics discussed have been implemented on an educational graphics system developed at the University of Illinois, PLATO IV. PLATO IV was selected as host computer 4 because of its extensive graphic capabilities. PLATO IV graphics are produced at a rate of 60 lines and/or 180 characters per second. Also, PLATO IV has a 16 x 16 touch sensitive light grid over the display screen which permits the user to identify an area on the screen by interrupting two light beams representing the ordinate and abscissa. This is especially useful in that many potential users of a Computer-based Medical Record Review system possess limited clerical ability, making computer-user interaction through keyboard usage impractical. The reader should keep in mind that computer implementation of topics presented is not intended to represent a flawless Computer-based Medical Record Review system prepared for immediate operation. Rather, PLATO IV is a laboratory device used to examine computer-based medical record procedures and ideas. 2. MEDICAL RECORD REPORTING (THE COMPLETE SYSTEM) Recent advances in computer software and hardware technology paralled by the interest of the medical community in the development of a Source Oriented Medical Information System (SOMIS) has set the stage for development of computer-based medical record systems. Research and development in the area of Computer Aided Instruction (CAI) has produced much user oriented equipment. It is this equipment which is often most applicable to computer-based medical record systems in that user orienta- tion of the equipment often yields user acceptance. Development of a Computer-based Medical Record Review system is here described in terms of the three component packages which make up the complete system: input checking, complete record retrieval, and current summary generation. Each of these components is responsible for record presentation in a specific user situation. In the first situation, a patient has spent some time answering questions asked by a system input package regarding the patient's medical history, present condition, etc., and is now ready to leave the terminal. However, before the patient completes the questionnaire, he is required to check his answers. There- fore, the system produces a summary of the information for the patient to approve or correct. This component of the Computer-based Medical Record Review system will be called "Patient Error Detection and Correction." In a second situation, a physician might want to review all available information concerning his patient. The system is required to present everything in this patient's record from the general summaries of information to the single response items, e.g., the yes-no response to a question entered by the patient during the system's collection of the medical history. This component of the system will be called "Complete Record Review." The third case exists when a physician wants to briefly review a patient's record before seeing the patient in the clinic or hospital situation. For this type of record review, the physician requires primarily summary information with more specific information available upon request. The component which produces this type of review will be called "Brief Encounter Review." One can readily see that the Patient Error Detection and Correction component is quite different in function from either the Complete Record Review or Brief Encounter Review components. For the purposes of the paper, the Patient Error Detection and Correction component will not be discussed. On the other hand, the Complete Record Review and Brief Encounter Review are quite similar in content. In fact, the Brief Encounter Review (consisting of summary type information) is a subset of the Complete Record Review. The boundaries between the Complete Record Review and Brief Encounter Review are defined by the increased detail available only in the Complete Record Review component. One could think of the Complete Record Review component as a satellite system with the Brief Encounter Review summaries as the nucleus. If each satellite represents a package responsible for presenting informa- tion in some form, the type of information presented by each package- satellite as one moves away from the center is more detailed and of more limited scope than any other package which is closer to the center. Therefore, in this satellite system, specific detail increases toward the periphery of the system. Because the Brief Encounter Review is more narrowly defined than the Complete Record Review, the goal of this project has been to define the major sections of the Brief Encounter Review. Subpackages of the Brief Encounter Review sections have also been defined until the excessive detail of a package obviously placed it in the Complete Record Review system. 10 Software Development and Structure In approaching this project, some assumptions are made. First, the assumption is made that much standard medical information can best be interpreted if it is represented graphically. Also, it is assumed that medical care could profit from the speed and efficiency of computer- assisted record keeping. With a potential increase in medical data quantity, medical record complexity and size will increase. Machine management of this increasing complex and extensive material may be desirable. If graphic representation of data is the best reporting form for much of the medical information presently recorded, and the alpha-numerics used to produce these graphics are the best representation of the required information for storage, then the computer is a most suitable medium for contemporary medical information storage and retrieval. Only the computer can store the compact alpha-numerics and translate them into informative graphics with sufficient speed. The goal in this project was to define the software which will upon demand, translate the patient medical record which has been stored in alpha-numeric form into appropriate, standard graphic representation. This software "translator" will be defined as a tree which increases in specificity (as defined by the medical information it produces) by level. 11 3. THE BRIEF ENCOUNTER REVIEW The single most important function of the Brief Encounter Review system is the production of a current summary of the patient's medical status. The purpose for having summary generation capabilities in the Brief Encounter Review system is to provide an effective interface between the detailed record and the user. Items which should be included in the summary are (1) medical problems with qualifiers, (2) medications, (3) laboratory reports, (4) history information, and (5) specialty or investigative departmental reports. An optional comment by the physician as a personal reminder made during the last patient-physician encounter could often be helpful. Finally, due to the large number of patients a physician sees on a given day, it might be helpful to include a personal comment in the summary which would indicate something about the patient's personal life, i.e. patient just returned from vacation, son is in college, etc. This personal information may assist the physician in conveying to the patient his personal interest. (See figure 3.1). Medications and problems make up a major portion of the current medical summary. A problem is entered into the patient's records as a descriptive phrase of forty or less characters (letters, blanks, and standard punctuation). At the time the problem is entered by the physician, the system assigns a number to the problem. This number is the next higher integer not previously assigned to a problem. The problem remains current until the physician changes the problem status to noncurrent or past. Discussion of the procedure for making this status change is omitted except to say that the change is initiated by the physician through an 12 BRIEF ENCOUNTER REVIEW PROBLEM LIST 12 -Fever of unknown on 1 1 -Recurrent d i arrhea 10 -Recur rent upper GI symptomatology 9 -Recurrent proctitis 8 - Recurrent con j unct i v i 1 1 s / u ve i t i s 7 -Recurrent cyst i t i s 5 - Psych i at r l c d i ffi cu 1 1 y 4 - 1 nt er m i 1 1 en t cough (HX) SPECIALTY REPORTS uro 1 ogy •lrb report;: Ur l na. 1 Os i s MEDICATI ONS 1 2 -Asp inn 5 -Phenergan 1 2 -Ch 1 ortr i met on 11 -Mineral oil 1 1 -Lomot i 1 10-Tigan PHYSICIAN REMINDER D i d pat i ent see psych i a t r i st as recommended? PERSONAL NOTE [PROGRESS Patient returned from NOTES Carr i bbean vacat i on - (*) MORE 9/16/73 (CURRENT) I EXIT HISTORIES Medical history Social history Farni ly history Genet i c hi st or y NAME: Doe, John Q. AGE: 3 4 ■ ADDRESS: 2 701 E. Sherwin Urbana, 111. 61801 LAST I/O DATE: 09/30/73 PATIENT NO: AJ1375 Figure 3.1. The Brief Encounter Review Summary Display, 13 input function; the system cannot change a problem's status. However, the system does assign a second date to the problem when a current problem becomes a past problem. The problem, its problem number, date of onset and date of resolution become a permanent part of the complete problem list for this patient. As long as the problem remains current, the problem with its problem number appear on the summary (date of onset is omitted due to lack of available space). However, the position of the problem in the problem list may vary. For example, the last (most current) problem entered appears at the top of the problem list. Therefore, if a problem remains current for a long period of time, the problem may move from the top to the bottom of the list as more recent problems are added to the top of the list. When a problem is no longer current, it is removed by the system from the current summary problem list and is placed in the list of all problems, both past and current, experienced by the patient. A residual or static problem would remain current indefinitely. This may be sufficient reason for separating current problems into active and inactive subclasses. The goal of an updated problem list is to provide a major component in the development of a health status index. Once a problem is removed from the current problem list, this problem can never become current again. However, if a problem of similar description to a now past problem is present, a similar description is entered into the record by the physician, but a new problem number is assigned. Later discussion will be concerned with the linking of these related problems. The medication list in the current summary is very similar to 14 the problem list. When a medication is prescribed, the medication may optionally be assigned the number of the problem it is prescribed to help. Information concerning the starting date, duration, dosage and other pertinent information about the prescription is also entered. Retrieval of this related information will be discussed in the section on medication information reporting. A medication remains on the current summary list as long as the medication is being given. When the medication is stopped, it is taken off the current medication list and is put in the discontinued medications listing which is a part of the total medication listing. The discontinua- tion of a medication can generally be accomplished in one of two ways. The most straightforward way to discontinue a medication is by having the physician directly discontinue a medication through some input function. This method is very similar to the method used in changing a current problem into a past problem. The second method for discontinuing a medication is by system action. If a physician writes a prescription to run seven days, the system can calculate when the eighth day has been reached, and in the absence of a renewal order for this medication, indicate the medication has been stopped. One should note that the physician can over-ride the system action in that he can indicate that a medication which was originally planned to continue seven days has been discontinued on some arbitrary day before the seventh day. The name or description of a medication can be twenty characters long. This is generally sufficient length to handle most medication names or descriptions (either generic or trade names). 15 When a problem is taken off the current problem list, that problem with that problem number can never again become current. However, in the medication list, when a medication is discontinued and later restarted, even though the medication might be associated with a different problem, the system always views a given medication as the same medication. The reason for this is that although a patient had a cold in January and another cold in March of the same year, there is no certainty concerning the etiology of these colds. On the other hand, a medication used to treat one problem and the same medication used to treat a second problem is the same medication. Dosages, durations, problems being treated by a medica- tion, and effectiveness may vary, but the medication itself is the same. The usefulness of this approach to problem and medication reporting will become more apparent to the reader in subsequent chapters. The next three sections of the current summary include (1) specialty reports, (2) laboratory reports and (3) histories. Specialty reports consist of a listing of reports in the patient's record which were made by specialists or consultants. When a new specialty report is entered into the patient record, the entry is listed in the current summary. This entry will remain in the current summary as long as the physician thinks it is pertinent to the patient's present condition. Therefore, an entry in the class of specialty reports may remain current for days or years. One should note that a specialty report entry may once again become current after being removed from the current listing. Laboratory reports are very similar to specialty reports in that they are current upon entry. However, some laboratory reports may in a 16 sense always be current because past results are used to establish indi- vidual norms for a patient. More discussion about computation of individual norms will follow in the section on laboratory result reporting. Those laboratory reports which are not forever current may be removed randomly by the physician from the current summary listing or may displaced. Histories, like specialty reports, can remain current as long as needed. Some of the general histories include medical history, personal history and genetic history. The details of the history reports will be discussed in the section on histories. The last two sections of the current summary are the physician reminder and patient personal note. These areas serve as a scratch pad for the physician. The notes placed here can be changed as the physician wishes but will remain unchanged permanently in the absence of user editing. Information in the section physician reminder will most often pertain to some portion of the patient's case where in the patient personal note section, the information will be of a more socio-personal nature pertaining to the patient. Finally, the reader may have observed that no mention has been made about one very important part of the standard medical record--the progress notes. In that there is not sufficient space on the summary display to produce even one progress note in its entirety, the author has chosen to delay explanation of progress note representation until the discussion of "paging through the record" has been completed. Therefore, an explanation of how the user can manipulate the patient record is contained in the following chapter. 17 Software Development and Structure Before discussing the method of producing the summary, some definitions are required. First, a single presentation which is produced on the screen is called a "page" or display. Secondly, a "software package" is used to produce a single page or collection of similar pages. Now, the summary page is produced in three sections. The rules used to construct these sections are standard rules used for all displays throughout the system. Therefore, the summary page will serve as an example for all displays. The first section is responsible for producing the frame of the page. The frame consists of all labels, markings and keys which make the information meaningful (see figure 3.2). The frame is the most consistent part of any page; it never changes. The second section produces the patient data i.e., problems, medications, histories, etc. The goal in this section is twofold. First, the display must appear quickly, and secondly, the patient information stored in the machine must be stored compactly. Therefore, a trade-off must exist between the activity of the intelligent component of the software which knows where and how to place all information in a display and the amount of type and display information which must be stored with the data. The amount of activity required from the intelligent component and the amount of type and display information stored with the data are inversely related. In its most ideal from, the intelligent component acts as a total translator. It selects raw alpha-numeric data from "bins" repre- senting sections of individual records stored in the system and produces 18 Figure 3.2, Standard Frames and Labels Used in the Presentation of the Brief Encounter Review Summary Display. 19 Record 3 Record 2 Record 1 Ideal Intelligent Software Component Data Storage "Bins" CP-791 Figure 3.3. Schematic Representation of Output Processing with the Brief Encounter Review Software Represented as the Ideal Intelligent Software Component. meaningful graphics through extensive interpretation (see figure 3.3). However, the amount of interpretation which must be completed by the intel- ligent component is directly related to the amount of time required to produce a display. Therefore, the trade-off exists in the form of questions such as "How fast must the display be presented?" and "How much room is available for storing display information?" For the purposes of this thesis, it was assumed that the 20 intelligent component of the software is extremely limited. Therefore, all data type and display positioning information is stored with the data. One can readily see that although this produces extremely fast displays, at some period, perhaps during input of data, all data type and display positioning information must be determined and stored with reduction in speed of that component. The possibility exists that slower processing and resultant user response times can better be tolerated by the user during input procedures than when information is required from the system during output procedures. An ideal solution would be to develop a better balance between the amount of data type and display position information which must be stored and the degree of intelligence required from the intelligent component of the software. The third section of the software package activates the linking structure which allows the user direct access to other parts of the record, Detailed explanation of this section is covered in the next chapter. Regarding the current or noncurrent status of any entry, this condition is indicated by a single bit which is either turned on (current) or off (noncurrent). 21 4. MANIPULATION OF THE RECORD Although one could hope that the current summary would be sufficient to handle most situations in which a Brief Encounter Review type summary would be needed, it is unrealistic to assume that the user will never require more information on a given subject than what is presented in the summary. In order to give the user additional information, a method for leaving the summary display and presenting new information was developed. Many of this system's potential users possess limited clerical ability. Therefore, the use of a keyboard for user input was considered impractical. Also, in a graphic display system, it is often best to let the user reference a portion of the graphic display in his input request. Therefore, the input method described in this chapter permits input directly at the screen. The PLATO IV terminal has a touch panel which frames the display screen. The touch panel produces a 16 by 16 grid of infrared light beams with a resolution approximately equal to the size of a human finger. If the user touches the screen and breaks any single horizontal beam and any single vertical beam, the intersection is distinct, and the machine "knows" where the screen has been touched. The PLATO IV touch panel produces 256 distinct intersections which can individually or in groups identify areas on the screen. Therefore, the touch panel provides a way other than by picking up a light pen or moving a cursor from off-screen of selectively linking to individual parts of the medical record. The touch linking mechanism can be divided into two distinct 22 Figure 4.1. Standard Touch Selector Including Identification Box Activator. 23 parts: a standard selector and a display specific selector. The standard selector is presented at the bottom of the display screen (see figure 4.1). The main purpose of the selector which appears on every display except the summary is to provide links to each of the major topic selector pages, i.e. problem, medications, histories, laboratory reports or specialty reports. A link to the summary page and a link to exit this particular record are also provided. Four special purpose touch boxes which complete the selector will be discussed later in this chapter. The summary display does not require the standard selector. The reasons for this will become obvious to the reader later in this chapter. The touch boxes of the selector are uniquely designed so that the intersection of a light beam pair falls in the center of each box. To accomplish a link to one of these topic selectors, the user touches the appropriate box, interrupts the appropriate light beam pair, and the system links to the appropriate topic selector and presents the selector. In the case where no supporting information is present when a selector box is touched, the label in the box is erased and the term "NO QA.TA" is produced. The "NO DATA" condition does not alter the remaining touch links or the current display (see figure 4.2). The second group of touch links occurs in the graphic representa- tion of the medical data. For the purpose of this discussion, the summary display will be used as an example. Similar links are provided in other displays. On the summary display, the display frames and labels are presented followed by the graphic representation of the stored data. After the display is completed, the system waits for the user to respond by 24 Figure 4.2. Standard Touch Selector with Null Link Indicated. 25 RPIEF encounter reuieu PROBLEM LIST IF TOUCHED - LOCATE AND PRESENT PROBUEM SELECTOR PECTALTV REPORTS IF TOUCHED - LOOflTE AND PRESENT LISTING Figure 4.3, Brief Encounter Review Summary Display Including Frames and Labels with Touch Link Areas Indicated. 26 touching the screen (see figure 4.3). If the user touches any but the bright areas of figure 4.3 which represent touch link areas when the summary page is presented, no response is observed. However, if the user touches the screen anywhere in a bright area, a predefined response is initiated. If the bright area where the problem list was presented is touched, the machine links to a new display called the problem list selector (its function is explained in the chapter on problem lists and links). Similarly, if the user touches any of the areas which represent the medication list, history list, specialty report list, or laboratory report list, the system responds by locating and presenting selectors for the medication, history, specialty or laboratory reports, respectively. Therefore, the user can link to any one of five selectors from the summary page which in turn will provide him with more specific information on a given topic. These links are similar to the links found in the standard selector (see figure 4.4). Problem Selector Medication Selector Brief Encounter Review Summary Laboratory Reports Selector History Reports Selector Specialty Reports Selector Progress Notes Figure 4.4. Tree Representation of Linking Structure Available to the User from the Summary Display. 27 After the system has presented the display and selector, the linker is activated, and the system waits for a user response. When an intersection is interrupted, the system checks its list of explicit instructions for specific intersections. If the interrupted intersection is included in the list of explicit instructions for specific intersections, the system performs the associated instructions. If the intersection is not in the specific intersection list, the system does not disturb the current display and again waits for another user instruction. Therefore, the implicit instruction for the system when an intersection which is not on the explicit list is interrupted is to wait for a second user response. The system will repeat this action until an input on the explicit list is received. Four special boxes are included in the standard touch selector. Two of these boxes have predefined functions, and two have varying func- tions. The two boxes with predefined functions are responsible for superimposing two standard graphs. In graphic displays, it is often useful to display two graphs on the same coordinate system to help show possible relationships between them. This type of presentation is accomplished by the two selector boxes called "SUPERPOSITION STORE" and "SUPERPOSITION." When the user sees a displayed graph he would like to see with another graph in the record, he touches the box labelled "SUPERPOSITION STORE" which temporarily stores all the information required to produce the graph on the screen. The user then locates the second graph and touches "SUPERPOSITION." The system then normalizes the axis of the second graph so that both graphs may be produced and plots both graphs. The first graph is removed from temporary storage. 28 This method of producing two graphs simultaneously does not alter the stored version of either graph. When the user again requests either graph one or two (the method of request will become evident in later chapters), they appear in unaltered form. The superimposed graph is not permanently stored. The two boxes which have no predefined functions, have their function defined specifically for each display in which they are used. Some examples appear in later chapters. In developing the summary page linkings, it was observed that people like to point to items while they are studying them or referring to them. Therefore, if the problem list, for example, is immediately touch linked to more detailed information, the user is not permitted to touch the listing while referencing the display. The solution to this problem was to develop a touch link which activates all other touch links. On every page, the patient identification box is reproduced to confirm that the system has not relocated itself in a different record from the one desired while searching for and presenting a new display. Since this box serves little purpose after record confirmation is made, it was decided that the identification box could become the touch link activator. After the display is complete including selector and identifica- tion, only the identification box is touch sensitive. When the identifi- cation box is touched, all appropriate areas in the display and in the selector become touch sensitive. The identification box is no longer touch sensitive once it has been touched. This touch activation is required on every display before linking can be accomplished. Therefore, in the 29 following sections when linking procedures are being discussed, the assumption will be made that the identification box has been previously touched and the touch links are activated. Touching the identification box does not alter the current display. 30 Software Development and Structure One objective was to build consistency into every display. For example, every time the summary page is produced, the problem list and each of the other lists appear in the same position and appear on the screen in the same order. The reason for this attempt at consistency was twofold. First, the human observer quickly adjusts to things which appear the same way several times. For example, when the user calls for the current summary for his patient, he is assured that the problem list will always appear in the upper left-hand corner of the display. Secondly, in order to set up proper touch links, the author must know something about where certain items will appear on the screen. If a touch box in the selector always appears at the same loca- tion on the screen, the user always knows immediately where to find it. Also, if the touch box always appears at the same location, a standard subroutine for activating the touch link for that box can be written and used whenever that box is presented to the user. In the case of the standard selector which appears at the bottom of the screen on every page, two standard routines are used. The first routine presents the selector in standard format. The second routine activates all of the links. The routine which produces the touch links for the selector and each display has four sections. Section one is responsible for putting the machine in a state where it is waiting for input from the user. Section two contains the list of intersections corresponding to the standard selector with the appropriate collection of standard explicit instructions. The list of intersections and instructions appears in the form of the intersection coordinates followed by the special instructions to be 31 executed when that intersection is interrupted. The instructions of one group are followed by the coordinates of the next intersection and its special instruction group. This ordering is repeated until all desired intersections are listed. Section three contains all coordinates and instructions for any links found in the display area and the variable function boxes of the selector. Section four marks the end of the routine. Section four also handles the condition when a coordinate pair not explic- itly defined in sections two or three is interrupted by returning control to section one which returns the machine to a waiting state. Since sections one and two are standard, they are stored in the form of a macro. To accomplish the activation of all links, the standard macro is joined to the code and sections three and four are appended. In using the identification box as a touch activator, a three section macro was defined which first puts the machine in a waiting state. Secondly, the only coordinates included in section two are those which are found in the identification box. Section three is omitted and section four responds as before. The special instructions for the intersections of the identification box transfer control to the standard selector macro described above. Therefore, the system response when the user touches the identification box is to activate all predefined areas of the display and selector (see figure 4.5). 32 User Touched Area Other Than I.D. Box User Touched / Enable Touch\ I.D. Box cation, User Touched /^System Area Defined in /Responds as^ Activation List / Direct ed by Code in Activation List User Touched Area Not Defined in Activation List CP-792 Figure 4.5. Finite State Representation of Touch Link Activation. A special condition exists when the user touches a box in the selector which is defined in the activation list and directs the system to locate data which does not exist in a particular record. A special section of code directs the system to erase the box on the screen which was touched by the user and write "NO DATA" (see figure 4.2). The main purpose in making a visual response to the user rather than handling the situation with no response is to confirm for the user that the system has not failed. This method of searching for data is extremely important in that when the link to a new display is initiated, the system searches for the 33 data used in the new display before erasing the current display. Therefore, if no data is found for the new display, the current display has not been destroyed. 34 5. PROGRESS NOTES In the discussion of the summary information available, the topic of progress notes was purposely omitted. In that the summary display did not have sufficient physical space to produce even a single progress note, separate displays for progress notes and linking mechanisms to access these displays were developed. Progress notes appear as a textual string preceded by labels. The label consists of the name and number of the problem which a note concerns and the date the note was entered. Progress notes are individually subdivided into four parts. These components include: (1) Subjective comments (S) , (2) Objective comments (0), (3) Assessment of the problem (A) and (4) Plan for treating the problem (P) . Therefore, this approach to handling progress notes is called S.O.A.P and was developed by Lawrence Weed as part of the Problem Oriented Medical Record System. A progress note may be virtually any length. Similarly, each of the S.O.A.P. sections may be of any length. In that progress notes are a vital part of the medical record, the author did not see fit to restrict the number of characters which could be used in a given progress note. (The PLATO IV system does place some restrictions here which will be discussed in the Software Development and Structure section later in this chapter.) However, by allowing the user to define the length of the note, the author could not guarantee that a given progress note would fit on one display page. The compromise was to develop a mechanism for presenting the progress note by sections where necessary. If the system were asked by the user to present a given progress 35 .'- 7 3 - 11 PROGRESS NOTES - C - Recurrent diarrhea s - Pa. t i en t comp 1 a i ns of cons t i pa t i on . - Phys i ca 1 exam i na t i on shows some tenderness in epiqastriu.ro. No masses <. organomegaly Bowel sounds active. ->r R - P '- Treatment: mineral oil 30 ml. h.s. pn i . BER PROB L.E 1 HISTORIES SURE :R- NAME: Doe, John Q. ~ 1 i SUMMARY LIS! STUF ■E HUL: 34 ADDRESS:. 2 701 E. Sher Urbana, 111. W i n 6 1801 IV itsfl Bfeaawi =ILTY SUPE ;r- TION NOTES REPOf ?TS PCS] EXIT LRBS - NEXT | CXI LRST I/O DATE: 09/30/ — NOTE J =>AGE Figure 5.1. A Complete Progress Note Presented in a Single Display, 36 note, the system would apply its knowledge about both the amount of room on the page and the amount of room required by the note. For example, if the display could present 100 characters and the note contained 100 or less characters, the entire note would be presented on one page (see figure 5.1). If the progress note had more than 100 characters, the system would begin checking the S section. If it had less than 100 characters, it would display it and check the section. If the total characters of sections S and did not exceed 100, the system would present the section after the S section. If the 100 character limit had not yet been reached, the system would add the number of characters in the A section to the total. If the total were 100 or less, the A section would be displayed after the S and sections. If the total had not yet reached 100, the system would not check the P section since a complete note total of more than 100 initiated this system action. If, in the above example, the A section had pushed the total over 100, the system would have presented only the S and sections. To display the remaining portions of the progress note, the two boxes which have no predefined functions are implemented. One box is labelled "NEXT PAGE." This box is used to page through the remaining sections of the note. In the example, with the S and sections presented, the "NEXT PAGE" box triggers the system to check the length of the and P sections and make appropriate presentations (see figures 5.2 and 5.3). If any section were to have more than 100 characters, the first X sentences which total less than 100 characters would be presented. "NEXT PAGE" would present the remaining text of that section and the following section completely if sufficient room exists. If there were not sufficient 37 PROGRESS NOTES 04/2 8/7 3 - 11 - C - Recurrent diarrhea S - Now comp 1 a i n i ng of a 1 1 er na t i TV consiipauon ana aiarrnea. na:=> Deen •having watery stools, 3-5 per day about every four days. Then constipated for three days. Still having abdominal pains but now it seems to be paraumb i 1 i ca 1 . Comp 1 a i n i ng of 1 ow grade fever. Also says he has a headache and his eyes burn. No problem with vision. - On physical examination temperature was 9 8.6, b . p . 11 .0/ 8 , pu 1 se 76 per m i nu t e and. regular. Heart and lungs okay. Abdomen - mild tenderness in paraumb i 1 1 ca 1 reg i on . Bowe 1 sounds hyperact i ve . No organs or masses pa 1 pab 1 e . Rect a 1 exam i nat i on - no tenderness, masses or blood. BER SUMMARY PROBLEM LIST HISTORIES SUPER- STORE . NAME: Doe, John Q. AGE: 34 PROGRESS NOTES MEDS SPECIALTY REPORTS SUPER- POSITION ADDRESS: 2 701 E. Sherwin Urbana, 111. 61801 EXIT LABS NEXT NOTE NEXT PAGE LAST I/O DATE: 09/30/73 PATIENT NO: AJ1375 Figure 5.2. First Part of Progress Note Completed in Figure 5.3, 38 PROGRESS NOTES 04 '28/ 73 - 1 1 A - - C - Recurrent diarrhea p - Observe BER PROBLEM HISTORIES SUPER- NAME: Doe, John Q. SUMMARY LIST STORE AGE: 34 PROGRESS MEDS SPECIALTY SUPER- ADDRESS : 2 70 1 E . Sherw i n NOTES REPORTS POSITION Llrbana, 111. 6 1801 LAST 1,0 DATE: 03/30/73 EXIT LRBS NEXT NEXT NOTE PAGE PATIENT NO: AJ1375 Figure 5.3. Last Part of Progress Note Started in Figure 5.2, 39 room to present all of the next section, none of the next section would be displayed until "NEXT PAGE" was triggered. When section P (or the last section of P) is presented, the touching of "NEXT PAGE" returns the display to the first section (Section S) of the note. Therefore, a given note is circularly linked by sections (see figure 5.4). Since by touching the "NEXT PAGE" box, the user continues to circle indefinitely through the note, the second box without predefined function called "NEXT NOTE" is used here to exit the present note and access the next note. But, what is the next note? The definition of the next note depends on the context through which the note is accessed. If the progress notes are accessed from the summary page, then the progress notes are presented in the reverse order from which they were entered into the record. Therefore, the last note entered is the first note presented. The next note is defined as the last note entered before the note presently being reviewed. Facilities such as two-way circular linking are currently being designed and will permit the user to study the evolution or progress of a case or problem. Since a progress note is written about a specific problem the patient is experiencing, the progress notes about this problem can be accessed from the problem selector page (Details concerning the problem selector will be explained in the chapter on problem listing). If a progress note pertains to more than one problem, the progress note will be accessable from an equal number of problem names in the problem selector. When a progress note is accessed through its problem, the last note entered concerning that problem is displayed. The next note is defined as the last note ABOUT THIS PROBLEM entered before the note currently being presented. 40 Start w s_ Selector ID n Selector 1 ID ii CP-798 Figure 5.4. With a Hypothetical Display Limit of 100 Characters, This Progress Note Has Character Length of: "S"=180, "0"=90, "A"=285 and "P"=87 Characters. Circular, Two-way Linking Is Also Indicated. 41 Since one often finds that a previous problem was related to a more recent problem, if a progress note were accessed through the more recent problem, after these notes had been exhausted, the system would display the progress notes pertaining to the related problem in a similar manner. In the chapter on problem listing, a discussion concerning the possibility of a past problem being related to a more current problem will be presented. Since related problems will be linked in some manner, it is important that the progress notes for all related problems be linked. Therefore, when the system has exhausted the presentation of progress notes about a given problem, it will begin presentation of the most recent related problem's progress notes if such a problem exists. For example, if the patient had a cold on 1/1/72 and a second cold on 1/10/72 which developed into pneumonia on 1/14/72, the progress notes for pneumonia would be followed by the progress notes for the cold on 1/14/72 which in turn would be followed by the notes from the cold on 1/1/72. If the notes from the cold on 1/14/72 had been accessed first, the next notes to appear would be the notes from the 1/1/72 cold. After the last note in the entire list is presented, the user has the option of returning to any of the selectors or summary. 42 11 - Recurrent Diarrhea 6/16/73 165 50 \ 10 1 100 I 9- Recurrent Proctitis 6/16/73 300|90 | 75 | 40 95 8- Sore Throat 4/12/73 7- Recurrent Cystitis 3/27/73 70 40 30 3- Diarrhea 3/15/73 500 200 75 50 175 3- Diarrhea 3/6/73 50 10 30 10 6- Dizziness 2/7/73 163 60 50 50 4 - Intermittent Cough 1/12/73 30 30 3- Diarrhea 12/17/73 Information S.O.A. P. Information S.O.A. P. Information S.O.A.R Now Entering Progress Note About Related Problem Information S.O.A. P. Information S.O.A. P. Information S.O.A.R Information S.O.A.R Information S.O.A.R Information S.O.A.R End of Notes Has Been Reached Pointer Null Null Pointer Null Pointer Pointer Nul Null Null Nul Figure 5.5. Schematic Representation of Progress Note Storage 43 Software Development and Structure One can readily see that no matter how the progress note section is accessed, the next note is always a note which was entered at some previous time. This suggests that some form of modified stack or last in- first out queue be used to store the progress notes. When the user calls the progress notes from the summary page, he expects to review the notes in reverse order from which they were entered. However, when the user accesses the progress note through a specific problem, the user requires only a subset of the progress notes presented in the first case. To produce the notes in the first case, the system must merely pop the stack to obtain each next note. In the second case, a pointer must be included with each note which points to the next progress note written about it. This link would be established when the note was entered into the system. Figure 5.5 shows how the entire list of progress notes for a record might appear in memory. Aside from the pointer, each progress note has a list of infor- mation about itself in the label. This information includes the number and name of the problem being referenced (perhaps useful in establishing the pointer link), the number of characters contained in the note and the number of characters in each of the S.O.A.P. sections. All of this information can be obtained during input and used during output. Finally, the flow chart used in presenting progress notes appears as figure 5.6. 44 Start Locate Correct Progress Note Copy Note in Temporary Storage Clear Output Buffer Assignments 1-^S 3-«-A 2*0 4-»-P Count -*-i Finish Wait for User Input Yes Put Entire Note in Output Buffer Print Buffer jss_ Put Remainder of Section (Count) in Output Buffer No Put First 100 Characters in Output Buffer Breaking at Sentence Boundary — Delete Same from Section (Count) Yes +■ Count-*- Count +1 Print Buffer Clear Buffer Print Buffer Clear Buffer Next Page Next Page Count-*- Count +1 Yes Finish Wait for User Input CP-800 Figure 5.6. Flow Chart for the Presentation of Multiple (and Single) Part Progress Notes. 45 6. INFORMATION RELATED TO THE PROBLEM LIST The summary page has room for up to fourteen current problems. One would think that this would generally be sufficient to handle informa- tion on even the severely ill. However, since the record contains past as well as current problems, a method for producing all past and present problems regardless of number had to be developed. If the record being reviewed were to contain less than fourteen current problems, the problem list on the summary page would appear less than full. The user could obviously see that there were less than fourteen current problems. However, if the record were to contain exactly fourteen current problems, the problem list on the summary page would appear full. Unfortunately, in this case, the user could not distinguish between a record presenting a complete list of fourteen current problems and a record presenting a partial list of fourteen current problems with more current problems yet to be presented. This question was resolved by the placing of an asterisk at the end of the topic label "Problem List v " when more than fourteen current problems are present in a record. This method of flagging lists of items longer than what can reasonably be presented on the summary is used for all listings on the summary page. A method for obtaining the unlisted items is now needed. When a user wants to see the extra current problems and/or the complete list of problems, he touches (1) the identification box to activate the linking structure, (2) the box marked "MORE (*) (CURRENT)" and (3) the problem list (see figures 3.1 and 6.1). This linking sequence causes the system to display as many current problems followed by past 46 6/10/73 - - 1-2 - C - - Fever- of l 4/23/73 - ■ 11 - C - - P ecurrent d i arrhea 1/17/7 3 - - 10 - C - - P ecurrent upper- GI symptorno 1 ogy 9/2 5/7 3 - 9 - C - - Recurrent proct i 1 1 s 9/2 5/7 3 - 8 - C - - Recurrent con j unct i v 1 1 1 s u ve i t i s 3/02/7 2 - ■ 7 - C • - Recurrent cyst i t is (HX) 3/0 3/0 3/0 2/7 2 - 2/7 2 - 2/7 2 - 5 - C - - 4 - C - - 6 ,- P - - Psych i at ri - Intermitt€ c di fficulty »nt cough (HX) 2/ i 1 0/ 1 3/71 - ■ 2 - P - - D i arrhea 9/1 3/71 - - 1 - P - - Sore throe t • 11 - c 10 - c Hsp inn Chlcntr irheton Mineral oi 1 Lomot i 1 T l gan Phenergan 6 - P - Dramami ne 2 - P - Plspirin PROBLEM HISTORIES SUPER- UMMflRY LIST PROGRESS MEDS NOTES EXIT LfiB^ I ORE RGE: 3 PECIflLTY SUPER- RDDRESS: 2701 E. Sherwin REPORTS POSITION Urbana, 111. 61801 NEXT NEXT . LRST I/O DRTE: 09/30/7 3 PROBS MEDS PftTIENT NO: RJ1375 Figure 6.1. Display of Complete Listings for Problems and Medications 47 problems as possible beginning with the most recent entries. One of the special boxes in the selector called "MORE PROBS" is used to cause the display to roll over ten entries erasing the top ten problems and adding ten more problems to the bottom. The result is to allow the user to page through the complete list of current and past problems. Upon reaching the end of the listing, the linking is circular, and the beginning is again produced. Medications are also included on this page and are independently controlled by the box marked "MORE MEDS" (more detail is included in the chapter on medications). A second possible request the user may wish to make from the summary is for a selector which would allow the user to access progress notes about specific problems. To obtain this selector, the user touches the identification box on the summary page (if not previously touched) to activate the links and then touches the problem list. The system responds by producing a problem selector. This problem list will scroll as did the complete problem list (see figure 6.2). Similarly, the user can access the problem selector from the complete problem list simply by touching the problem listing. The problem selector lists all current problems as presented in the summary when accessed from the summary page. The problem selector provides up to two touch links per entry. The first link is initiated when the user touches the problem name on the problem selector page. The system responds by presenting the last progress note entered about that problem. The user can then trace through the progress notes about this problem and its prior related problems as described in chapter five. The existence of the second link is dependent on the existence of related 48 Figure 6.2. Problem Selector Display Including Touch Boxes for Linking to Appropriate Related Problems. 49 Figure 6.3. Display Showing a Current Problem and those Problems Related to it. 50 problems to each problem listed in the problem selector. If a problem in the listing has related problems, a square appears to the left of the individual entry. If the user touches a square, the problems related to the problem presented in the selector are presented. Figure 6.3 shows the resultant display when a user touches the square associated with the entry "recurrent diarrhea" in figure 6.2. The related problems display is similar to the problem selector in that touching the name of any problem links the user to the progress notes concerning that problem. Brief Encounter Review Summary Complete Problem Listing | Problem Selector WIT? or] Related Problem List CP-797 Figure 6.4. Subtree Representation for Accessing Progress Notes via the Problem Selector. 51 In summary, the user may obtain a complete listing of all problems in the record from the summary page and then proceed to the problem selector or go directly from the summary to the problem selector. From the problem selector, the user may obtain information in the form of a listing of related problems to a given problem and then proceed to the progress notes or go directly to the progress notes regarding a problem on the problem selector (see figure 6.4). 52 Software Development and Structure The method described in this chapter for presenting "More Current Problems" and/or the complete list of current and past problems is used for all five listings included in the summary page. Further discussion regarding the presentation of complete listings in the following chapters is omitted. However, a special case exists when there are no current entries in one or more of the five summary page listings. For example, if there are no current problems but some past problems in a record, the summary listing for problems is empty (since summary listings present only current items). However, in this case, a request for the complete list of problems via the "MORE (*) CURRENT" box presents all past problems. Table 6.1 represents the system re- sponses under various data conditions when the complete lists are requested. When a new problem is entered, the user has the option of linking it to any related problem already present in the record. The system would then have sufficient information to link the new progress notes together under a given problem and among related problems. Therefore, one could assume that the problems would be stored in a stack similar to the method by which progress notes are stored. The new problems could be pushed on the stack with pointers linking related problems. 53 USER REQUEST i ' -■ WHAT IS THE STATUS OF THE "CURRENT" TOPIC LIST WHAT IS THE STATUS OF THE "PAST" TOPIC LIST SYSTEM RESPONSE REQUEST FOR A TOPIC* SELECTOR NON - NULL NON - NULL PRESENT SELECTOR NON - NULL NULL PRESENT + SELECTOR NULL NON - NULL PRESENT SELECTOR NULL NULL FLASH "NO DATA" REQUEST FOR A COMPLETE LISTING BY TOPIC* NON - NULL NON - NULL PRESENT LISTING NON - NULL NULL PRESENT LISTING NULL NON - NULL PRESENT LISTING NULL NULL FLASH "NO DATA" *Topics are defined as problems, medications, laboratory tests, histories and specialty/consultant reports. Table 6.1. Table of System Responses to User Requests for Complete Listing or Selectors by Topic Under Various Data Conditions. 54 7. MEDICATION AND RELATED INFORMATION Just as in the section on problems, the Brief Encounter Review system provides more information on medications than what appears on the summary page. The medication list in the summary has room for ten entries. If more than ten current medications are maintained in the record, the summary title "MEDICATIONS" appears with an asterisk appended. The complete medication list including all current and past medications is linked similarly to the complete problem list. The user touches (1) I.D. box, (2) the box marked "MORE(*) n and (3) the medica- tion listing on the summary page, and the system presents the same display of problems and medications presented when the problem listing was touched instead of the medications listing in step 3 above. From the complete listings display, the user can scroll through both the complete listing of problems or medications by using the touch boxes marked "MORE PROBS" and "MORE MEDS" , respectively. If the user requires more information on the patient's medications, the first item to appear after the summary is the special warning page. This page is on a separate level of the information tree for medications and cannot be bypassed by the user. Examples of a special warning items would might appear on the warning page include allergies to specific medications or medication types. To aid in attracting the user's attention the system flashes the warning "ALLERGY-PENICILLIN", for example, repeatedly until the user touches the identification box. The flashing then ceases with the complete warning on the screen and all touch links active (see figure 7.1). This warning routine can be used in any section of the record. 55 Figure 7.1. Warning Page Showing the Patient's Allergy to Penicillin. 56 From the warning page, the user can proceed to the medication history graph. This link is accomplished by allowing the user to touch the warning page anywhere in the display area. Touching "MEDS" in the selector will also accomplish this link. Of course, the user can exit the medication section by touching any of the selectors at the bottom of the page. The medication history graph is designed to show chronological relationships among the various medications in the patient's record. The graph lists the medications with the numbers of the problems it was prescribed to treat along the right vertical axis of the graph. Each prescription is distinct. The medications are listed in reverse order by starting date from the bottom to top with the most recent on the bottom. Also, all current medications are displayed first. The horizontal axis represents increasing time from left to right. Therefore, this axis must float with time so that the right-most point on the hori- zontal axis spans 6 weeks subdivided into weeks and days. Also, the appropriate frequency for each prescription is given along the left vertical axis. (Author's note: A second possibility would be to re- place the frequency indicator with a dosage indicator.) With the frame for the graph developed, an algorithm using the prescription starting date, the prescription expiration date and "today's" date computes a bar of appropriate length and position to be plotted on the graph for each medication. The number of days plotted is also placed in reverse type in the left end of the respective bars. An interesting component of this graphic representation is that all current medications and only current medications extend to the right 57 vertical axis (see figure 7.2). Also, the number of medications being taken by the patient at any time is easily determined. Throughout this research, methods for presenting problems and medications have been developed in parallel. However, one major difference exists between problem and medication recording. A problem can occur only once. (A reoccurrence of a problem is assigned a new problem number and therefore, becomes a new problem.) On the other hand, a medication is always the same medication. However, a medica- tion may be associated with a number of problems (or no problem) over a period of time. A given medication will always appear only once on the medication history graph. The medication history graph presents two new problems. Since the horizontal axis represents a finite period of time, a method for scrolling the graph to the right or back in time must be available. One of the special purpose boxes in the selector could be used to initiate a finite right circular scroll of one to six weeks. A second scrolling technique is required to bring more medications onto the graph. The second special box could be used to move some number of medications already presented off the bottom of the graph and move more medications with earlier starting dates on to the top. Therefore, this graph scrolls down and to the right. To obtain more specific information about any medication currently being presented on the graph, the user must touch the appropriate bar after activating the screen at the I.D. box. This information might regard prescription dates, dosage changes, amount patient reported taking, patient comments about the drug, etc. (see 58 Figure 7.2o Graphic Representation of a Patients Medication History. Overlapping Prescriptions and Prescription Durations are Clearly Represented. 59 ft S P I R I . P R N (Patient Report) MED STARTED: 11/9/7 3 MED STOPPED: 11/20/7 3 MED GIVEN: 6-12-6 6 -TABLETS * ) 1 DOSAGE: 10gr/2t< \ 4-TABLETS ■ V \ \ (amt taken) (daily) 2 -TABLETS - \ -TABLETS - -. k k b- . |_ -^fc (3 DAILY REPORT PATIENT COMMENTS: The aspirin helped my headache but upset my stomach. BER PROBLEM HISTORIES SUPER- NAME: Doe, John Q. SUMMARY LIST STORE AGE: 3 4 PROGRESS MEDS SPECIALTY SUPER- ADDRESS: 2 701 E. Sherwin NOTES REPORTS POSITION Urbana, 111. 61801 EXIT LABS LAST I/O DATE: 09/30/73 PATIENT NO: AJ1375 Figure 7.3. Patient Report for the Medication, Aspirin, with Tabular Information in the Upper Right - Hand Corner. 60 6 -TABLETS T~~ 4 -TABLETS Camt taken) (da. 1 1 y) 2 -TABLETS 0- TABLETS PATIENT COMMENTS: The aspirin h<_. headache but upset my stomach. BER . PROBLEM HISTORIES SUPER- NAME: Doe, John Q. SUMMARY LIST STORE RGE: 34 PROGRESS MEDS SPECIALTY SUPER- ADDRESS: 2701 E. Sherwin NOTES REPORTS POSITION Urbana, 111. 61801 EXIT LABS LAST I/O DATE: 09/30/73 PATIENT NO: AJ 1375 Figure 7.4. Display of Figure 7.3 with a Dosage Graph for the Medication Replacing the Tabular Data. The Dosage Graph was Obtained when the User Touched the Tabular Information. The Remaining Display was Unaltered. 61 figure 7.3 and 7.4). The reader should note that the box in the upper right hand corner of figure 7.3 can be replaced by the dosage graph in figure 7.4. The interchanging of the box and the graph is accomplished by the user touching the box or the graph, whichever is currently being displayed, PLATO IV selectively erases what was previously written and writes the new information without disturbing the remaining parts of the display. This erase and write action can be repeated any number of times with any number of displays of similar size. Brief Encounter Review Summary Complete Medication Listing Special Warning Flag ' Medication History and Selector iwwr Medication Graph Medication Graph CP-795 Figure 7.5. Subtree Representation for Accessing Information Regarding Patient Medications, 62 In summary, the information regarding medications in a patient record is accessed as the user moves through a medication subtree (see figure 7.5). Each level of the tree provides more specific information regarding the patient's medication history. 63 Software Development and Structure In producing the medication history, the length and horizontal position of each bar is computed from the information available in the prescription. Since the date the prescription was started is always available, the system "knows" where to position the left end of the bar. If the date the prescription is to stop is also available, the length of the bar can be easily determined. Similarly, if the "to today's date" duration of the prescription is available, the system can cal- culate the position of the right end of the bar. Duration can also be computed by: Total Amount Given Duration = Amount Taken Per Day Therefore, the position and length of each bar is easily computed. However, irregularly given medications present more of a problem. The label representing the duration in days of a prescription or length of a bar appears inside the left end of each bar and is ob- tained from the system's calculation of the length of that bar. The user is assured that the numerical portion of the label will always fit inside the bar since each day represented by the bar can hold one digit of the label. Since many standard, hard copy medical records provide a place on the front of each chart for special warning information, a similar warning is placed at the front of the medication section. The warning is flashed by writing and erasing the warning phrase. After the system has flashed the warning, it checks to see if the identifica- tion box has been touched. If the box has not been touched, it flashes 64 the warning again and repeats the check. If it has been touched, the system writes the warning on the page and waits for further input from the user. The result of this procedure is a continuously flashing warning which is stopped with the complete warning remaining on the screen when the user activates the touch links by touching the screen. The dosage graph which displaces the box of information on the specific medication graph is a smaller version of any graph. All three components; frame, variable data and linking mechanisms; are included. The displacement mechanism involves erasing the previous display and producing the new display. This procedure is the same as used for all other graphic displays except the area in which the new display will be placed is erased first. 65 8. LABORATORY RESULT REPORTING As a representative of the reports available from investigative departments, laboratory reports constitute an important part of the medical record. Although the summary provides the user with a listing of those laboratory reports available in a given record, this listing tells the user nothing about the content of each report. The Brief Encounter Review system must therefore provide a link to a selector from which the user can select the report he is interested in reviewing. This link is accomplished when the user touches the listing of laboratory reports in the summary (see figure 8.1). The laboratory report selector presents a listing of all available laboratory reports. In order to handle a listing with more entries than will fit on a single display, the vertical scrolling techniques described in previous chapters may be required. From the selector, the user may begin his review of individual reports by touching the appropriate entry. The system responds to this action by locating and presenting information available in that report. Facilities are currently being developed which will flag reports listed in the summary which have abnormal results. Also, conclusion and interpretation reports on certain tests or test collections will soon be available. Often a laboratory report will consist of many individual test results which, when reviewed together, determine the information in the report. Also, many of the reports contain test results which can best be described in graphic form. Therefore, one type of laboratory reporting display is developed as a collection of normalized graphs 66 Figure 8.1. Laboratory Report Selector. 67 where each represents a specific test (see figure 8.2). In determining the results of a blood chemistry report, the physician compares the individual test results to the population standard for healthy people in the same general class as the patient, i.e., sex, race, environment, etc. Therefore, the test results are graphically displayed over a dot density display. The center or most dense area on the graph represents the normal range of values for that test as determined by the general population. From observing the position of the marker representing the test result with respect to the density, the user can determine the amount of deviation in this test result from what is considered normal in the population. However, although the result on a test for an individual may fall outside the normal range of values for that test as determined by the population, this result may not be abnormal for this specific patient. One method for determining the normal results on a test for a given individual is to repeat the test over a period of time while the patient is in a healthy state. One can readily see that this is impractical in that it would require substantial expense on the part of the patient and increase an already present overload in the clinics. Therefore, an alternative method is to collect the data on individual tests for the patient as they are normally run. Over a period of time, sufficient data will develop for some tests to permit evaluation of a new test result with respect to the past test results. But, until sufficient data has been collected, the display reporting test results must provide both information on the population standards and as much information as possible on the individual patient's standards. 68 Figure 8.2. Normalized Graphic Report of Six Blood Chemistry Tests Taken From an SMA - 12/60. Population Standard and Individual Patterns are Indicated for Each Test. 69 Figure 8.2 is an example of how the Brief Encounter Review laboratory reporting page might be developed. There are twelve standard tests in the blood chemistry report. Therefore, section one represents one half the total. Each graph is labelled and scaled so that the range of normal values falls in the center of the dot density. Since the lower bound for the tests in figure 8.2 is zero, no under- flow for values in these tests is possible. However, the case of overflow is not ruled out. The box on the right contains entries representing results which have exceeded the upper bound of the scale. The small oblong circles represent past test results for the patient. Since it is hoped that the small markers will cluster and represent the normal value for the patient, the indicator "N = #" specifies the number of entries displayed. This is especially useful where many entries appear in the same location and their number is unclear. The current or most recent test results appear as an hourglass (on its side) with the result of the test found at the intersection of the glass. The hourglasses come in five sizes and are used to represent the analytical variation in each test (see figure 8.3). In summary, the reports of any laboratory work which consist of numerous individual tests can be displayed as a collection of graphs displayed on a dot density field with the dense center area representing the population standards for the tests. The plotting of past results for each test when statistically significant, can be used to represent an individual standard for that test. Labels, units, scale and overflow are all presented by the display. Finally, the analytical variation 70 Figure 8.3. Various Symbol Sizes Used in the Blood Chemistry Display to Indicate Analytical Variation Inherent in Each Laboratory Test, 71 fiLBUMEl ""8--_ ._. month day I I I I I. I I -M-M-H-H-h PROBLEM HISTORIES SUPER- NAME: Doe, John Q. LIST STORE AGE : 3 4 MEDS SPECIALTY SUPER- ADDRESS: 2-701 E. Sherwin REPORTS POSITION Urbana , 111. 61801 LABS LAST I/O DATE: 09/ PATIENT NO: AJ1375 Figure 8.4. Blood Chemistry Supporting Graph for Albumin Tests 72 in each test is reflected in the length of the hourglass marker of current results. Although the graph collection provides information concerning the value of the current tests with respect to the population and individual standards, one cannot always determine the exact value of any single test result or determine in what order a series of past Brief Encounter Review Summary 1 ' Complete Laboratory Listing i t v Laboratory Report; Selector i WW I V Urinalysis Report Blood Chen Charts listry Part I « " Part 17 I+ + v HH Hi Individual Results vs. Time Lab Graph Individual Results vs. Time _ab Graph 1 X-Ray Reports CP-796 Figure 8.5. Subtree Representation for Accessing Laboratory Reports via the Laboratory Selectors. 73 results for a given test were completed. Therefore, the user is permitted to touch the name of the test on the graph collection for which he requires more detailed information, and the system responds by providing a standard graph of results for that test with respect to time (see figure 8.4). Since these graphs are in standard form (as defined by the system), superposition of these graphs with other stand- ard graphs is possible. The system subtree used for laboratory results reporting is included as figure 8.5. When the user requests more specific information regarding results for a laboratory test the system determines the dates of the earliest and last entries and scales the abscissa appropriately. All values for the test can then be plotted on the graph. 74 Software Development and Structure Many problems are inherent to presenting a graph collection which is normalized to an arbitrary area on the scale. For the tests used in figure 8.2 the possibility of underflow was not present, but in other such reports, the problem could easily exist. Similarly, by normalizing the scales to permit the normal range to fall in the center of the scale, the left and right bounds are equidistant and the numerical span from zero to the center must equal in magnitude the span from the center to the right bound. Therefore, cases of graph overflow may be quite frequent. The problem with using a specific hourglass with a certain test report is not a real problem in that the hourglass selected for a test report is always used in reporting that test. However, plotting the hourglass figure presents a more significant problem. Since the hourglass characters are plotted on the graph from the left edge and the centers of the characters are the markers used in interpretation, conversion algorithms used to map the characters to the left a distance dependent on the size of the character were developed. In the presentation of the graph collection display, the dot density is produced first. Therefore, when the oblong circle and hourglass characters are marked on the scale, the inside of each character must first be cleared of the dot density before the frame of the character is presented. If the inside of each character is not erased, the characters are lost in the density. The result of this required operation is increased presentation time and greater complexity for each character. 75 9. HISTORIES In this chapter, methods for presenting one type of history information will be discussed. The linking structures and presentation formats presented in earlier chapters will be used to maintain conventions previously standardized (figure 9.1). The summary display contains a listing of history information available in the record. This listing, as all other listings in the sum- mary, is touch linked to a selector from which the user can choose the report he is interested in reviewing (see figure 9.2). When the user touches an item in the selector, the system may present the information in that history record or present a subselector. For example, if the user indicates he wishes to review the patient's genetic history, the system will present a second selector in the form of a list of topics the patient previously indicated had a family history (see figure 9.3). From this selector the user may obtain specific information about any of the topics listed. (The reader should note that all selectors in this section scroll to present additional entries if required.) Genetic histories are best reported in the form of modified trees where the patient is represented by the root or top node. The patient's sisters and brothers are indicated to the left and right of the patient's node, respectively. Since the sisters are to the left of the patient node, the patient's mother is represented by the left branch node. The patient's maternal aunts and uncles are located to the left and right of the patient's mother's node, respectively. The patient's father is represented by the right branch node. The patient's paternal 76 HISTORIES MEDICAL HISTORY SOCIAL HISTORY FAMILY HISTORY GENETIC HISTORY BER PROBLEM HISTORIES SUPER- NAME: Doe, John Q. SUMMfiRY LIST STORE AGE: 34 PROGRESS MEDS SPECIALTY SUPF P ADDRESS: 2701 E. Sherwin NOTES REPORTS POSITION Urbana, 111. 61801 EXIT LABS LAST I/O DATE: 09/30/73 PATIENT NO: AJ1375 Figure 9.1. The History Report Selector, 77 GENETIC HISTORY DIABETES HYPERTENSION HEADACHES BER PROBLEM HISTORIES SUPER - SUMMARY LIST STORE PROGRESS MEDS SPECIALTY SUPER- NOTES REPORTS POSITION EXIT LABS NAME: Doe, John Q. AGE: 34 ADDRESS: 27.01 E. Sherwin Urbana, 111. 6 1801 LAST I/O DATE: 09/30/7 3 PATIENT NO: AJ137 5 Figure 9.2. History Subselector for Genetic Histories, 78 Figure 9.3. Genetic Tree Representation of Patient's Family with Those Who Complain of Headaches Indicated, 79 aunts and uncles are positioned to the left and right of this node, respectively. The grandparents are placed under each parent with the grandmother to the left and grandfather to the right. For consistency, the female entries are always placed to the left of any major node. Similarly, the males are to the right (see figure 9.3). Positive responses (the patient indicated this individual has complained of the problem) are indicated by an "X" marked through the box. In figure 9.3, the patient, one of his sisters and his mother have complained of headaches. The number of sibling boxes is arbitrary. If the patient or his parents had more than three brothers or sisters each of which had a positive response to a given condition, the marking of all three boxes would give sufficient indication that a genetic link might be investigated. Also, the tree does not trace back farther than the grandparents because information about great grandparents and the like is often unreliable. A modification might be to include a response for other relatives, i.e cousins, etc. 80 Software Development and Structure Since the genetic tree is a standard frame produced by the system, the system must only store a binary yes-no response for each tree and each person represented in the tree. Therefore, this type of display is efficient in the amount of computer storage space required. The linking structure from the summary to the genetic trees is presented as figure 9.4. Brief Encounter Review Summary Complete History Listing History Selector TTTTT Specific Topic Selector 3 if Individual Genetic Tree CP-794 Figure 9.4. Subtree Representation for Accessing Information Concerning the Patient's History, 81 10. ODDS AND ENDS The final listing to be covered in the summary page is the specialty reports. These reports would be typically from consultants or specialists. Most often, these reports would be in standard report form. Therefore, these reports would be reported in the Brief Encounter Review in a manner similar to that used for progress notes. This would allow for paging through a report in a manner similar to that used for progress notes. In the section on laboratory reports, the discussion of how the Brief Encounter Review would reproduce pictorial reports such as x-rays was omitted. Aside from PLATO IV 1 s ability to produce complex graphics, PLATO IV can project slides onto the screen through the use of rear projection techniques. Slides for PLATO IV are produced in the form of a micro-fiche. The user could be required to select a patient's micro-fiche when he prepares to review the patient's record. Sign on procedures would have the user insert the appropriate micro-fiche into the terminal before reviewing some portions of the patient's record. 82 11. SUMMARY AND CONCLUSIONS A major function of the Brief Encounter Review system is to present a current summary of the data contained in a patient medical record. Each summary is to act as an interface between the detailed medical record and the user. Each summary contains content lists for each of the five major medical record subsets: problems, medications, histories, laboratory results and specialty/consultant reports. "Scratch Pad" areas for physician use, patient identification infor- mation and a link to the progress note section are also provided. Although the summary information should be sufficient to provide the user with an overview of the patient's condition, more detailed in- formation may be required. To access the more detailed information contained in a record, the user must activate all touch links available in a display by first touching the I.D. box. The user may then select the topic (problems, medications, etc.) about which he requires more detailed information. The Brief Encounter Review system is structured as a "by-level" tree with each level providing more specifically detailed information about the topic associated with that branch. Equally as important as the tree structure is the complex linking structure de- veloped for the Brief Encounter Review system. The linking structure provides the user with extensive record manipulation capabilities without the need for keyboard entry (see figure 11.1). Building consistency into each display has been a primary goal. All displays appear on the screen in the same order. Display frames and labels appear first providing display orientation to the user. The graphic representation of the medical information is presented next. Finally, 83 SU Way inhoaa via Stondord • !•■.,■ -. . An, Linkage Sir Way L. no age Specific Special^ and Conn Reports ml Related e> Problem Lilt SliWoy LlnkOQt TT Blood Chemistry [Ponl[~~*|port It] /individual! (Individual 1 VT«t J VT Teit J Individual) ix Woy Unhoge *ia Standard Selector nr Si. Woy UnkOM via Standard Solictor Figure 11.1. An Overview of the Brief Encounter Review System with the Linking Structure Indicated. 84 appropriate linking structures are activated. The display then "waits" for a user request (a touch). Display consistency is intended to aid the user in becoming familiar with the Brief Encounter Review content. The degree of success obtained by this work can best be measured by the medical community's enthusiasm regarding each of the individual displays and complete prototype system. During the develop- ment of the Brief Encounter Review system, members of the medical community have been invited to comment on the work and to suggest modi- fications and additions to components being developed. Although the Brief Encounter Review is continually being modified and expanded, on June 30, 1974, a Model Family Practice Center is scheduled to begin operation in Danville, Illinois. Staffed by two experienced physicians, the center will use the Brief Encounter Review system together with other software packages to manage medical records on a PLATO IV-based Problem Oriented Medical Record System (PROMTS) . 85 List of References 1) Anderson, J. and F. Woodroffe, "A Clinicians 's Approach to Computer- based Medical Record Systems," INTERNATIONAL JOURNAL OF MAN MACHINE STUDIES, vol. 1, no. 4, pp. 387-403, October 1969. 2) Schroer, B. J., "The Doctor (and Computer) Will See You Nov," JOURNAL OF SYSTEMS MANAGEMENT, pp. 33-37, March 1973. 3) "Analyzing Patterns of Illness," IBM COMPUTING REPORT (in Science and Engineering), vol. 9, no. 1, pp. 8-16, Spring 1973. 4) Stifle, J., "A Plasma Display Terminal," CERL Report X-15, University of Illinois Computer-based Education Research Laboratory, March 1972. 5) Ebling, F. A. , R. S. Goldhor and R. L. Johnson, "A Scanned Infrared Light Beam Touch Entry System," Digest of Papers - SID International Symposium, Society for Information Display, pp. 136-137, San Fransico, June 1972. 6) Hurst, J. W. , "How to Implement the Weed System: In Order to Improve Patient Care, Education, and Research by Improving Medical Records," THE PROBLEM ORIENTED SYSTEM, pp. 57-66, Medcom Press, 1972. BIBLIOGRAPHIC DATA SHEET |< Report No. UIUCDCS-R-71+-648 4. Tii le .niJ Subi it It- The Brief Encounter Review: An Investigation in Graphic Computer -Based Medical Record Reporting Systems 3. Recipient ■ Acci 5- Report Date May, 197 U 7. Author(s) Henry Albert Warner 8. Performing Organization Kept. No -UIUCDCS-R-7U-6U8 9. Performing Organization Name and Address Department of Computer Science University of Illinois at Urbana- Champaign Urbana, Illinois 6l801 10. Project/Task/Work Unit No. 11. Contract /Grant No. 111. Regional Medical Program IRMP 0G-2*+B 12. Sponsoring Organization Name and Address Illinois Regional Medical Program National Institute of Health Washington, D.C. IRMP 0G-2UB 13. Type of Report & Period •Covered Master of Science Thesis 14. Prepared in cooperation with the Coordinated Science Laboratory, Computer-based Education Research Laboratory and the Regional Health Resource Center 16. Abstracts Research in the area of computer-based medical record systems was initiated by the medical community's interest in the development of a Source Oriented Medical Information System (SOMIS). A product of research in Computer -Aided Instruction (CAl) has been the development of a special class of machine which is highly user oriented. By combining the computer science interests of the medical community with the user orientation of CAI equipment, a prototype graphic computer-based medical record reporting system, the Brief Encounter Review, is being developed which may achieve the single most important element required of any medical information system: user acceptance. 17. Key Words and Document Analysis. 17o. Descriptors Problem-Oriented Medical Information System Computer-based Medical Record Retrieval System Graphic Display Computer-generated Medical Record Summary 17b. Identif iers/Open-Ended Terms Topic Selectors Standard Selector Touch- input Linking ,17c. COSATI Field/Group 18. Availability Statement Release Unlimited 19. Security Class (This Report) UNCLASSIFIED 20. Security Class (This Page UNCLASSIFIED 21. No. of Pages 91 22. Price FORM NTIS-35 (10-70) USCOMM-DC 40329-P7I Jttlwtf* m CO CO