mil i LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 510.84 It6r no. 588-589 cop 2 Digitized by the Internet Archive in 2013 http://archive.org/details/architectureofco589mill UIUCDCS-R-73-589 ARCHITECTURE OF A COMMUNITY MEDICAL HISTORY DATA BASE by Craig Alan Mills August 7, 1973 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN URBANA, ILLINOIS ARCHITECTURE OF A COMMUNITY MEDICAL HISTORY DATA BASE BY CRAIG ALAN MILLS B.S., University of Santa Clara, 1971 THESIS Submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science in the Graduate College of the University of Illinois at Urbana-Champaign , 1973 Urbana, Illinois Ill ACKNOWLEDGMENT The author would like to express his appreciation to his advisor, Professor S. Ray, for his advice and criticism. The author would also like to express his gratitude to his wife, Linda, for translating his handwriting into a typed draft. IV PREFACE The medical profession has many cumbersome methods, such as most present medical codes, handwritten records, and the amount of paperwork involved in the care of a patient. These cumbersome methods and the establishment of Medicare, insurance forms, and other red tape which have become an in- tricate part of our society hinder the development of computer applications in the medical profession. This paper attempts to cover the many .legal , security, and technical problems that arise. A general background of computer applications in the medical professions is given with emphasis on the usefulness of a medical history data base. From such computer applica- tions, the medical profession will derive innumerable benefits These benefits include more complete records, more individual- ized care, and efficient handling of paperwork. V TABLE OF CONTENTS CHAPTER Page 1 INTRODUCTION 1 2 SCENARIO OF A HOSPITAL INFORMATION SYSTEM 4 2.1 Hospital Information Systems 4 2.2 Community Medical History Data Bases 8 3 DATA BASE ARCHITECTURE 11 3.1 Legal Impediments 11 3.2 Security 15 3.3 Directories 21 3.4 Files 33 4 CONCLUSION 48 APPENDIX 51 LIST OF REFERENCES 66 CHAPTER 1 INTRODUCTION Technology has created many new ways to cure people. However, with these new ways come new results, symptoms, ques- tions, and answers that must be recorded. Politics have created Medicare and Medicaid and all the red tape that goes with it. In this day of rising prices, more people have more insurance creating more paperwork. Legal questions have prompted the use of more forms and more complete forms. With all of this addi- tional information, the highly technological medical profession is still manually storing and retrieving information. The hospital and private practices are businesses. How- ever, they often lack the efficiency of their industrial coun- ter parts even with industrial and financial leaders on the Board of Trustees. With the increase in cost and paperwork, it has become increasingly important for the hospital to be effi- cient, but being efficient does not necessarily mean less care for the patient. Efficiency could mean less cost to the patient and a more individualized service. Some hospitals have started to computerize and streamline their operations . One example is the State University Hospital of New York. The State University Hospital of New York and Downstate Medical Center is unique in that it has had its activities con- trolled by an on-line computer system, Thomis (Total Hospital Operating and Medical Information System) , since its opening in 1966. See in particular [22] . 2 The patient's previous history is retrieved from disk. The computer then assigns a bed within the contraints of sex and locations, and preprinted, self-adhering labels for the patient are prepared by the computer. The nursing station is notified that the patient has arrived and the telephone office is informed which telephone is assigned to that patient. The computer handles all transactions for both in- patients and out-patients although they require to some degree separate programs and files. In the case of a future order, the computer records the request and then informs the service area on the day the procedure is to be performed. Scheduling of procedures is done for the following service areas: Radi- ology, Physiology, Rehabilitation Medicine, Physical Therapy, Occupational Therapy, Neurology, Orthopedics, Plastic Surgery, Inhalation Therapy, Psychiatry, Opthalmalogy , and Operating Room. When ordering from the pharmacy, at the same time a validation is printed out on the ordering terminal, a prescrip- tion label is printed containing all data legally necessary and a copy for the file is made. The stock inventory of the item ordered is reduced by the appropriate amount. If the inven- tory of the item falls below a specified level, the pharmacy is sent a notification to reorder. As is the case with all orders, the patient's bill is updated. Thomis handles the reporting of quantitative laboratory results in the areas of clinical chemistry, coagulation, hema- tology, special hematology, serology, and clinical isotopes. 3 The results are entered by a clerk and then distributed by Thomis to the appropriate nursing stations. In-patient records are updated. Out-patient records are not usually available, so their results are summarized nightly and sent to the medical records department. Thomis also includes an accounts receivable subsystem, management reports, extensive census reports, and statistical programs for research and activity analysis [22] . Even with the existence of such systems, computers are not being used to their full potential. Often a single hospi- tal will attempt to computerize too much and cost, poor manage- ment, or lack of communication between users and installers will cause the collapse of the project. Other times, several small projects are completed but are not easily integrated into a harmonious unit. One area that has not been successful is the storage and retrieval of a complete and detailed patient history data base. In this paper an attempt is made to design such a data base . First, a description of what the computer can do to help hospitals is given in Chapter 2. Following this, in Chapter 3, the problems that will be incurred in developing information systems are briefly examined. Then, in detail the actual data base for a complete system is discussed with a view to the problems, expectations, and solutions that arise. Finally, in the conclusion, the main points are summarized and implementation requirements are outlined. CHAPTER 2 SCENARIO OF A HOSPITAL INFORMATION SYSTEM 2.1 Hospital Information Systems Like a business, hospitals also suffer wastes of time, energy, and money when computers are misapplied. For this reason, computers should be applied in modular fashion to areas with a well-defined purpose. At present, there are four major areas of hospital activity to which computers have successfully been applied. The first, since hospitals are very much a busi- ness, is data processing, where the most widespread use of com- puters in hospitals is in business systems. For example, busi- ness data processing, and in particular, data processing for accounts receivable, bills, and payroll are highly developed outside the hospital and easily adapted to any individual hospital . The second and more challenging area is that of informa- tion retrieval. Here the peripheral display device gains a greater importance than the computer. It does not matter how economical a display device is, if it makes too much noise for a nursing station, for example, it does not belong in the hos- pital . While airlines have had excellent information retrieval systems for many years, there are as yet no exceptional models in hospitals, although there are several working models which 5 will eventually be refined into a smooth functioning system. However, a major cause for frustration is the doctor who con- tinues to compile medical records in a cumbersome way. Never- theless, because of its sheer bulk, medical data will even- tually be forced to be recorded in a structure that will permit computer manipulation. The third area is management. Hospitals have manage- ment staffs and often trustee groups whose members are indus- trial, financial, and professional leaders who have had consid- erable management experience with computers and automation. Hence, the computer can be used for financial analysis and maintenance scheduling within the hospital itself. The fourth area is the medical-clinical activity: diagnostic, research, and educational. The mini-computer is becoming very important in this area as the laboratory control element. The role of the mini-computer in the laboratory is threefold. Depending on the size of the laboratory computer and the interface with the hospital's central computer, the laboratory computer is expected to reduce turnaround of test results by assuming much of the clerical work. In some systems the computer will assign patient lab numbers, produce work lists, quality control results, specimen tube labels, patient records, tally sheets for lab workload analysis and charge lists for ac- counting, and route the output to the proper location. All this frees nurses and the technologist from clerical work and allows them to be better utilized. 6 Many laboratory procedures require computations to convert raw data obtained from analytical instruments into meaningful information. Computerization of these procedures, especially in an on-line real time system, reduces the chance of a mathematical or transcription error. In some cases, a computer can monitor analytical in- struments, make corrections for drift of baseline, interpret and chart repeated analysis of standards, decide when methods are out of control and when to repeat a method that appears in error and relay error messages to the technologists. The focus of this paper will be on the second area, in- formation retrieval. With the attempt to develop Hospital In- formation Systems (HIS) come several large problems. The prob- lems are not only technical but legal, behavioral, social, and political. Two problems that should be mentioned in connection with HIS are data processing requirements for health insurance and the right of privacy for patients in regard to computerized data bases. Along with the diversity of forms required by the various insurance companies , Medicare and Medicaid are increas- ing substantially the amount of data processing for claims. The processing of the claims places a large burden on the hos- pital and in many cases forces them to computerize early. Besides allowing the hospital to keep pace, the computer organizes and clarifies records. Before computerization patient records were often disorganized and frequently contained illeg- ible handwritten records and notes. They were, consequently, implicitly safe from invasion of privacy. With computerization, 7 several problems will have to be solved before data bases are widely accepted. To assure continued patient confidence in the doctor, the computer must be covered by testimonial priv- ilege. Also, the prevention of "leaks" must be considered, as there will be several programmers, technicians, nurses, etc. with access to the computer. Policies need to be developed on the use of medical information based on the purpose of the request, nature of the information being requested, individ- uals or organizations requesting the information, and need or lack of need for an informed written consent from the patient. Hospital information can be divided into two categor- ies: medical information and administrative information. How- ever, the information in these two categories is not distinct. Both categories contain patient identification and a list of tests given to each patient, for the results in one category and for billing purposes in the other. The most vital part of all the information is the pa- tient identification. For instance, should the originating department request a test and the only legible identification they give is the patient's name, then the Lab must call the Information Center or Admitting Office to determine the loca- tion of the patient in order to transmit the results to the correct place and personnel. The carbon copy of the test re- quest goes to the accounting department which organizes their records by patient numbers, so they too must inquire and waste time to gather the essential information. 8 In short, to make a Hospital Information System effi- cient, administrators and physicians must have a understanding of the information flow in the hospital: they must be aware of what information is needed by whom and when. 2.2 Community Medical History Data Bases Previous discussion has shown that an in-house Hospi- tal Information System is desirable, but desirability is not enough. Present cost of such a system would prove economic- ally justifiable to only the largest institutions with over 1000 beds. Also, it has been estimated that nearly 70% of im- portant clinical observations are recorded outside the hospital environment and at best only a rough sketch of the family med- ical history is available. The solution to these problems is to extend the Hospital Information System to include the entire community. This would provide a system not only economically feasible to small hospitals, but also to individual doctors. This Community Medical History Data Base would contain complete records gathered from all medical sources, including family histories. It is also possible that centralized billing and insurance processing is desirable and economical, but the re- mainder of this paper will concentrate on the development of the Community Medical History Data Base, forthwith referred to as the CMHDB. See in particular [21 and 47] . For the private doctor, CMHDB must be designed to com- pete with the present system. It should be just as quick for a nurse to retrieve information from CMHDB as it is presently 9 to find the hard copy. The nurse must be able to request some type of summary on the patient for the doctor to review before meeting the patient. During the examination the doctor may want to request more detail, or, in an emergency, pertinent information must be available immediately. All these condi- tions must be met before a CMHDB becomes viable to the individ- ual doctors. However, not only must the requirements be met, they must be an improvement upon the existing system, espec- ially in respect to retrieval time and completeness of records. For this a cathode ray display screen should be available for scanning the records for the needed information without produc- ing a hard copy. This kind of response time requires an on- line system. By being on-line, the nurse does not have to worry if a requested file for a given appointment has arrived. In emergencies information is retrieved in seconds. With the short response time, hard copy information is minimized since more detail can be quickly retrieved. With retrieval of data on-line, updating would most likely be on-line. The nurse of a particular doctor is more familiar with the terminology of that doctor than any central updating service would be. Also, the thought of 200-400 doctors sending incomplete forms to the central updating services makes it economically plausible that the updating should be done at each doctor's office. This also avoids double bookkeeping. Having the nurse do the updating requires CMHDB to contain suf- ficient safeguards to avoid accidental (or purposeful) removal 10 or changing of the wrong information. Posting the current date and other miscellaneous bookkeeping could be done auto- matically by CMHDB. Some doctors or hospitals may want to use "Mumps" while others may establish their own language to cope with their par- ticular terminology or special needs. Because of this, it is expected that each user could have his own customized inter- face. It will be up to the doctor or hospital to implement the interface. For further information on "Mumps", see [25]. 11 CHAPTER 3 DATA BASE ARCHITECTURE 3.1 Legal Impediments The changes required in the law to allow CMHDB to be efficient and effective poses a problem almost as immense as the development of CMHDB. There is no distinct body of law to be attacked. The government makes laws in response to in- fluences, post de facto. As the law is presently stated, the creation of an automated system is precluded. See in partic- ular [21 and 64] . Many states, such as California and Kansas, have regu- lations that allow automation of medical records after the orig- inal records have been manually created. In Maryland, as in other states, medical records are required to be manually cre- ated, i.e., legibly written by pen. Laws of this nature must be revised to allow efficient use of automation. Regulations covering the contents of medical records vary from broad descriptive statements in Arizona, Iowa, and Ohio to Michigan's regulations which contain specific itemiza- tion of information to be included in the records. Generally, the medical record principles, standards, and interpretations promulgated by the Joint Commission on Accreditation of Hospi- tals meet the various state regulations. State courts have used them as evidence of the standard of care in negligence cases. Hence, any automated medical record system would do well to abide by these standards. 12 The Joint Commission with the interpretations under Standard II requires all medical records to contain: 1. Identification data and consent forms, 2. History of the patient, 3. Report of the physical examination, 4. Diagnostic and therapeutic orders, 5. Observations, 6. Reports of actions and findings, and 7. Conclusions. The patient medical records, usually the most detailed, should include: patient's name, address, next of kin, and other pertinent data for identification and consents as deemed neces- sary by the hospital's administration and the medical staff. The history of the patient should incorporate the chief complaints, details of past illness, inventory of systems, past history, social history, and family history. This history should be as unbiased and concise as humanly possible. The report of the physical examination should contain all relevant findings resulting from an assessment of all the systems of the body. If a physical examination has been con- ducted recently, then only new information need be recorded with the understanding that no other information has changed since then. Diagnostic and therapeutic orders written by authorized house staff members and other individuals who have assigned practice privileges, telephone orders written by licensed 13 nurses, and diet orders should be contained in the patient record. Observation reports should include progress notes by the medical staff and house staff, consultation reports, nur- ses' notes, and entries by allied health personnel. Consulta- tion reports should contain a written opinion by the consul- tant. Progress notes by the medical staff should give a chron- ological report of pertinent facts concerning the patient's recovery and should be sufficient to describe the changes in each of the patient's conditions and the results of the treat- ment. Nurses' notes and entries by allied health personnel should contain only meaningful information. Opinions requir- ing medical judgment should be authenticated only by authorized house staff members and those persons who have been assigned practice privileges. Reports of actions and findings should include such items as reports of pathology and clinical laboratory examina- tions, radiology examinations, medical and surgical treatment, and any other diagnostic or therapeutic procedures. All diag- nostic and therapeutic procedures should be recorded and authen- ticated in the medical record and may include any reports from out-of-hospital facilities. All treatment procedures performed must be documented in the medical record. The surgeon should record and sign a preoperative diagnosis prior to surgery. Operative notes, prepared after surgery, should contain a de- scription of the findings, the techniques used, the tissue re- moved or altered, and post-operative diagnosis. 14 The conclusion includes provisional diagnosis, primary and secondary final diagnosis, clinical resume and necropsy reports. The provisional diagnosis should reflect the respon- sible practioner's evaluation of the patient's condition at the time of admission. All relevant discharge diagnoses should be recorded, using the terminology of a recognized system of disease nomenclature. The clinical resume should summarize the significant findings and events of the patient's hospital- ization, his condition on discharge, and the recommendations and arrangements for future care. Where a necropsy is performed, provisional and anatomic diagnosis should be recorded on the medical record within 72 hours, where feasible, and the complete protocol should be made part of the record within three months. A copy of the clinical resume is required to be sent to the medical practitioner or clinic responsible for subsequent care of the patient. This requirement would be implicitly met by CMHDB, since the resume is available to anyone who needs it once the clinical resume is entered. Some comments should be made here concerning certain key words and phrases. The phrase "entries by allied health personnel," recognizes that persons other than medical or den- tal practitioners and licensed nurses may write entries. This is important because specialized personnel may be needed for data entry into CMHDB. The words, "pertinent," "relevant," "meaningful" and "necessary," need to be defined to form uniform and standard records. It is generally accepted that whether or not auto- mation is implemented medical records need to be reorganized. 15 Medical records at this time contain much useless information and are often missing useful information. Automation of medi- cal records may prove to be the catalyst for this reorganization. Then there are the key words "signature" and "authen- tication." The Joint Commission of Accreditation of Hospitals has been farsighted in recognizing the potential application of computer technology to medical records. This is seen in the Joint Commission definition of "authenticated": To prove authorship, for example, written signature, identifiable ini- tials or computer key. Many states have regulations requiring handwritten signatures which will have to be modified before automated medical records can be effective. Hospital medical records are retained anywhere from 7 to 25 years, depending on the state regulation. The American Hospital Association recommends 15 years. The Joint Commission interpretation states, "The length of time that records are to be kept is dependent upon the length of time that they may be needed for continuing patient care and for legal, research, or educational purposes." In any case, an automated medical re- cord system would have to retain records for an indefinitely long period, which can be treated as permanent. A more detailed discussion of the law and automated medical records can be found in [64] . 3.2 Security Access control to the data base has important implica- tions in the content and structure of the data base. The 16 software security features will, of course, work in conjunc- tion with hardware features. Nevertheless, software safety techniques have a dramatic effect on the data base. First of all, a list of eligible users must be maintained in a high level of the memory hierarchy. Accompanying every request must be a positive identification of the user. Sufficient identification information to recognize the user to a high confidence level plus the degree of access freedom the user has is information that will be frequently used. It is possible that identification could be as simple as using a bank cash card where the user would enter a machine readable card and separately enter through a console a code. Identification could be further verified by having the computer asking suspicious users or randomly selected users such ques- tions as birthdate, address, or questions from the user's medi- cal file. Access control is simplified if the data is struc- tured in a modular fashion. This is so users restricted to a certain type of information can be easily given just that in- formation. For instance, an orthodontist should not be allowed and it is unlikely that he would want information concerning the obstetrics of his patient. However, serious problems do arise as to whom is allowed what information. It would be dif- ficult indeed to provide mutually exclusive data for the obste- trician and the orthopedist. This would imply that the data base should be organized into small blocks of data and that for each user there should be a list of those data blocks to which 17 the user has access. A solution to this problem is achieved by organizing the data base on a problem-oriented basis. The speciality of a doctor is defined by the problems he is trained to cure. A problem-oriented organization allows the doctor the information he needs while at the same time he can be re- stricted to just that information. Most hospitals presently organize their patient files by hospital stay, but each hospi- tal stay usually has a list of problems in Hospital-International Classification of Diseases-Adapted (H-ICD-A) codes on the dis- charge summary sheet. Most problem coding is either infeasible or at best in- efficient for computer use. For example, Current Medical In- formation £ Terminology (CMIT) codes spleen infraction as 05-3723 and myocardium infraction acute as 04-1921, and a new code for each infraction. This makes statistical searches dif- ficult, to say the least, and lookup tables quite large. H-ICD-A and International Classification of Diseases-Adapted (ICD-A) are modifications of International Classification of Diseases (ICD) which was developed 100 years ago to record causes of death, and has a structure unsuitable for the computer. In 1965, the College of American Pathologists published SNOP , Systemized Nomenclature of Pathology. It is presently being extended to become either the Lexicon of Medical Prac- tice for Computer or Systematized Nomenclature of Medicine (SNOMed) . SNOMed codes will contain five fields as follows: 1. Topography - anatomic sites of disease, 18 2. Morphology - names of visually apparent altera- tions of the cell, tissue or organ structure, 3. Etiology - a classification of causes of diseases and injuries , 4. Function - the terms for disturbances of physio- logic function as in signs and symptoms, 5 . Therapy and Diagnostic Procedures and Miscellan - eous Hospital Functions - the names of forms of therapy and diagnostic procedures. The first four fields are the same as SNOP and the fifth could be a modified version of the Current Procedural Terminology of the AMA. The topography field consists of two parts, a site num- ber and a sub-site number. There are 140 sites and a variable number of sub-sites, depending on the particular site. All 36 parts of the lung, for example, would be preceded by the site code 28. Greater detail will be required in the topography of SNOMed to satisfy the wide variety of specialists in the medi- cal field. The other three fields of SNOP have the same two part structure. The divisions of Morphology include: 1. Traumatic Abnormalities, 2. Congenital Malformations, Absences and Deform- ities , 3. Mechanical Abnormalities, 4. Inflammations and Repair, 5. Degenerations, Neerosis and Depositions, 6. Fine Structure and Cytologic Alterations, 7. Growth Alterations, 8. and 9. Neoplasms and Miscellaneous Conditions. 19 In Etiology the sections are: 1. Bacteria, 2. Rickettsiae, 3. Viruses, 4. Other Pathogenic Organisms, 5. Chemicals, 6. Reserved for Expansion, 7. and 8. Drugs, 9. Physical Agents of Injury. It is hoped most microbiologic parts of this field will be contained in SNOMed . The field of Function has: 1. Disorders of Elements, Ions, Simple Compounds, and Certain Metalloproteins , 2. Metabolic and Nutritional Disorders, 3. Enzyme Disorders, 4. Endoerine Disorders, 5. Blood Coagulation Disorders, 6. Immune Responses and Hypersensitivity Reactions, 7. Cardiovascular, Respiratory and Neuromuscular Disorders , 8. Mental, Psychic, and Personality Disorders, 9. Miscellaneous Functional Disorders. There will be many additions to this field in SNOMed (more con- cerning SNOMed can be found in [69]). With the code being stored in the data base, a central dictionary can be stored to translate the code into preferred terms and synonyms or just the preferred term with the 20 translation of preferred term into the local synonyms being done at the terminal. Reverse translation can be done sim- ilarly. In many cases, it may be quicker for the doctor or his nurse to deal directly with the SNOMed code. As an example, a visual aid for SNOP has been tested. Most terms are arranged according to topography. Their code numbers can be located in seconds by lifting the page to the proper site to select from the alphabetically arranged diagnoses. Such visual aids could be prepared for each of the different fields in medicine [69] . Using SNOMed for coding diagnoses provides quick coding of the diagnoses, easy manipulation and retrieval by computer, and most important of all a means of restricting the flow in information. Using this coding, users can be restricted in the kind of information they receive by storing a set of codes each user can request. Treating the coding as a five dimensional space, this restricting set would range from a list of points to a cross product of intervals on each axis. SNOMed also allows the user more freedom to request very specifically which disease he wishes information on by entering one number for one field to find all diseases with that characteristic in the patient's history. This also allows statisticians a wide lat- itude. Searches for certain combinations are much easier to locate. Besides restricting the information requested to that information relevant to the user, a user can be restricted to read-only or write-only. A private doctor and his nurse, for example, would have access only to those records relevant to 21 his practice and then only through his terminal. It is pos- sible that the doctor, owing to his reputation for legibility and completeness, may be allowed read-only access while the nurse might only have write-only access. 3.3 Directories After solving the legal problems and deciding on se- curity information, medical codes, and data base contents, the architecture of the data base can be discussed in depth. The first structure encountered are the directories. Two main directories are needed in the data base, one for user identification and one for patient sub-directories. The user directory first must contain the user identification number and if a pass card system is used the code is needed. It is possible that these two numbers could be replaced by a digitized voice print or finger print, but these would require much more storage. Also needed is a list of terminals the user is permitted or expected to use. Should user identifica- tion number, code and terminal identification not match those in the directory, the computer may wish to question the user further to confirm identification or report the attempted mis- use. For this the user's data base or patient identification number is needed. The user's patient file would contain his name, occupation and address and this information should not be duplicated in the user directory. Once the user has achieved clearance, his request must be checked to see if it is within the restricting set; that is, the information re- quested is relevant to his specialty. Whether the user has 22 read-only, write-only, or read and write access must also be determined. This user identification directory does not read- ily lend itself to compaction. The following illustrates the suggested contents for the directory with their approximate size in core. User identification number 2 bytes Code 2 bytes Data base number 3 bytes Flags (count of terminal numbers and size of restriction set) 2 bytes Read-write Access 2 bits Terminal numbers (variable) 1 byte each Restriction set (variable) 10 byte minimum Minimum number of bytes per user 20 bytes Read-write access and terminal numbers might be combined into one number indicating a set of terminals the user can use and his read-write access. The restriction set will need overhead storage to indicate the number of subsets and whether each sub- set consists of a single point or a set of points (Figure 1) . If one allows for the possibility of 500 users, the user directory would require 10-15K bytes. This size direc- tory could easily be contained in core on a medium-large com- puter. It is not expected that there will be a very dynamic turnover of users or very many changes in user access rights. Probably the most that need be expected is a weekly update. Because of this relative stability and the core contained size, 23 User ID# Code Patient ID# a b c d e Restriction Set a) Number of terminals (4 bits) b) Size of restriction set (10 bits) c) User read-write access rights (2 bits) d) 6 e) Terminal identification numbers (1 byte each) Figure 1. User directory element. 24 a rather fixed structure allowing rapid access can be used. Some permutations of the access code can be used for a simple table lookup of the particular user entry address. The user entry can then be accessed with this address for verifying identification . Once clearance for the user and his request has been accomplished, the data base is ready to be entered. If the request is for the entering of new information or a new pa- tient, then it is assumed the computer will automatically store the information and make all the needed entries in the appro- priate tables. The "appropriate tables" just referred to will be discussed as viewed with respect to requests for information retrieval. Every request will contain a patient identification number and at least one SNOP number. Other information in the request might include dates indicating how recent or old the information should be, combination of SNOP numbers indicating a search for complications of a disease or request for specific test results. Location of the patient directory is the first problem in answering a request. The patient identification number will be used to locate a patient directory, since names are not unique and phonetically similar names are easily misspelled. Once the particular directory is located, name, address, and other identification information can be sent back to the ter- minal for verification of the patient identification while the requested information is being retrieved. If the data base is designed to handle 100,000 patient histories, any table lookup 25 runs into storage problems. Using a transformation of the patient identification number to address the table and allow- ing three bytes for the directory address and directory length, 300K bytes of storage are needed for the table. Since this table is used with every request, small access times are needed. To avoid frequently retrieving sections of the table from sec- ondary memory, as large a section as possible should be main- tained in primary storage. Ideally the whole table would be in core. All of which means a large core is required. Once the particular directory address has been retrieved from the table, the patient directory can be retrieved. Immed- iately upon retrieval identification information can be sent for verification of the patient number. The identification in- formation should consist of name, current address, marital sta- tus, birth date, and physical description. The physical de- scription would include height, weight, color of eyes and hair, sex, and race. This is sufficient information for the requestor to make a positive identification on the patient even if some of the information is wrong. By letting the requestor make the visual check, it saves the requestor from typing this informa- tion into the computer, saves the computer from making the match and deciding if sufficient information matches to make a positive identification, and finally occupies the requestor while the com- puter retrieves the needed information. To retrieve the requested information, the computer would search a linked list of SNOMed codes in the patient directory. The list would include codes for family history, personality 26 history, and the social history, besides those for the medical history. Because there are expected to be as many as 100,000 patient directories, storage conservation and data compaction are of prime importance. Many data compaction techniques are presented in the literature. The methods referred to in the following discussion are explained in detail in the references [45, 55, and 61]. The header information of the patient direc- tories can be broken into three fields; name, address, and de- scription. The name field would have the format: last, first, middle initial. As can be seen, using "b" and "#" to repre- sent a blank and end of field respectively, coding " ,b" and ".#" as one character each is feasible. Similarly, in a study whose results are presented in Figure 2, 10 other pairs oc- curred with sufficient frequency to warrant coding with a spe- cial character . With the code presented in Figure 2, an average of 4.14 bits were needed to encode one character. If a differ- ent format were used or the whole middle name was included, a new frequency study would have to be made. The codes are con- structed such that from the first four bits of the code, the number of bits in the code can be determined. For example, all seven bit codes and only seven bit codes begin with "1111." Also, since the characters are ordered by frequency of occur- rence, it can be concluded that four bit codes occur nearly 40 per cent of the time. Therefore, 40 per cent of the time a direct one step table lookup is all that is needed for the translation. 27 OHOrlOHOHOHOOrlOHOrlOHOHOHOnOrl r-iiHOO'-HrH,HrH-HH rHrH i-|t-liHi-<»H»HHr-l/Hr-lr-liH<-«i-t^l-t ul / 5] r.j •'J 3 01 a 1-1 u! 'tof^OMHCOcot^i/iiocoiiinocitDut^^'in •.0 I (ONHH^Ji^ahiOinNHOOOOOOOO I rHMr-irHOOOOOOOOOOOOOOOOO I ccooooooooooooooooooo c^Tj-Li(^< v ir v -cMr-vominvOr-( vOOOCNrHf^tNCOvOOOCOCTiCN'iHOO^LICNICNi-l^HrHrH iO(MO<^OH*tnWOW> i t>3>lXr-aits>.'-vo » n m •»* oi ao 18 • (T3 +J o OtHOr-HO^-"Oi-iOOi--IO^ 00'Ht--t<-HfHiHOOOOOOOOOOOO>Hr-( OOOOGOOO»-IOOOOOO>-trHrHrHiHrHrH^^iHvOkDi/i(NHO[nnrjiojM^Jia3(NHOi^coooin NroOOiO^O)H(N\Dh'-l^;ir)NC^vOfJnOOOHiO^OHJ10(^ MN(\003HHOO>'MD*Dinnff») fflUJiilini/l^^'l'ifro^nc - , AM flfM(N(N'N l Ni\Hr-;HHHHH ^^■^^OOOCOOOOOOOOOOOOOCOOOOOOO o o o o tt T\ 00 U3 ro L.") r~» i-H CO r^ (N O C"> i*" r-~ ID L"> o ui r^ m ffi i/i fo o i^ o a) a .0 ^ ^t ni O ^1 n 01 H fHO O (N o O Ul .—) H r» N(NH <£> v- V nnrMMf-iOCOO r-l.-(r-l<-lr-lr-|rHiH—( c r~ r- r- i^ vo un in in ir< tn *j< -3]M * £ Ci ■"!£ y g O C £- J « K C • OU'JOhD J« 2 W T3 i-H d) •H M-l (D e to c o 4-1 -o 0) W w (D TS O o C (TJ •P 42 .0002 / 10110 & 00 .OOOOy 10111 Totals 21^,708 1.0006 Figure 4. Suffix codes — used for address fields 31 description can be coded as follows: 1. Color of hair (black, brown, blonde, grey, others) 3 bits 2. Color of eyes (blue, brown, others) 2 bits 3. Race (Caucasian, Black, Chicano , Oriental, others) 3 bits 4. Height (0-128 inches) 7 bits (0-256 centimeters) 8 bits 5. Weight (0-512 pounds) 9 bits (0.0-204.8 kg.) 11 bits Using inches and pounds the description field is 43 bits. Assuming 80 per cent of the time that the name field is less than or equal to twenty characters, line (1) is then less than or equal to twenty-five characters and line (2) can be represented by a seven bit code. Thus, to encode line (1) , line (2), and the description field, a thirty byte record can be used with a high confidence level that a trailer will not be needed. If a trailer of an additional ten bytes is needed for the overflow, the last bit of the record can be used as a flag. Once the header record has been retrieved, translated, and sent, the computer can search for the SNOMed codes requested Each patient directory would hopefully contain at least three codes, those for the family, social, and personal histories. It is not expected, though, that there will be enough codes, on the average, to warrant a complex tree structure. A simple linear linked list with the codes in numerical order is expected to suffice. The five field SNOMed codes are ten bytes long. Any attempt to organize the codes would result in a high overhead 32 Name field Address I pref i 3 Address suffix Pty empty Description field a) City-zipcode table address (6 bits) b) State table address (6 bits) c) Trailer flag (1 bit) Note: a double vertical line represents an end of field character. Figure 5. A patient directory information header. 33 in terms of storage, maintenance time, and search time. For instance, if each field is linked in a numerically ordered list, one additional byte for each field for the link address would be needed. Five more bytes for each of 20 codes for 100,000 patients is 10M bytes more for the patient directories and five linked lists to be altered each time a new code is entered. Each element of the list would contain a ten byte code, one byte for the number of references and five bytes for each reference consisting of two bytes for date and three bytes for address. Since two or more SNOMed codes could refer- ence the same address, with some coding a reference might just point to another reference that has the same date and address at a savings of four bytes. If the list were ordered by the topography field, then a request for any history of inflamma- tions within the last year would search every Morphology field in the list for code 4 with a reference not older than one year. Should the list become very long, time could be saved by list- ing the occurrences of the major divisions of the five fields immediately following the header. There would be one list of divisions and the addresses of their occurrences for each field. With at least 30 bytes per header and 16 bytes per list element, 100,000 directories would probably occupy 25M to 50M bytes, or about one full disk (Figure 5) . 3.4 Files It is hoped that automated records will spur reorganiza- tion of medical records with intent to save useful and only use- ful information. Man-machine interaction will play an important 34 role in this organization. However, in one experiment with nurses and automated records, nurses entered four times as many notes as normal which had half the normal useful content. Besides deciding what is useful data, standardization is needed. As can be seen in the history or physical examina- tion form from Mercy Hospital in Urbana, Illinois (see Appendix), the doctor is allowed a rather free hand in filling out the form. Certainly there are questions that will always be left to the discretion of the doctor, but there are several that can be answered with a yes, no, (a), (b) , (c) , or 98.6 in "check-off" list fashion. In addition, standard questions should be listed so that the doctor does not forget anything and the record is complete. University of Illinois' McKinley Hospital has an auto- mated history that is given patients periodically. The history contains 100-200 questions such as "do you smoke?" and if the answer is yes, "how many packs a day?". The answers are stored in 192 words, not compacted. When uniform standard forms are used, a "yes" answer can be stored with one bit instead of hav- ing to store an arbitrary question and answer that would consume several bytes. Standardization has other positive side effects such as making it more feasible to use para-medics for standard questioning and having the doctor add any free text notes he feels are necessary, thereby freeing the doctor from much of the routine for more important things . Free text can be compacted about 35 per cent, depending on the character distribution. The use of variable length 35 character codes becomes unwieldly when an unrestricted charac- ter code such as the 88 EBCDIC character set is used. If it is found in a study of medical free text that the whole char- acter set is not needed, then variable length character codes could be considered. Other factors affecting the decision of whether or not to use variable length code are character fre- quency distribution, frequency of certain combinations of characters, and the possible use of a certain subset of char- acters on a particular form allowing for the use of different compaction codes in different places. One way to compact an unrestricted character set is to use the free codes for pairs of characters. For example, only 88 of a possible 256 EBCDIC codes are used, leaving 168 codes for pairs of characters. The following method employing this idea has been suggested as being efficient in compaction and expansion times. EBCDIC spreads its 88 codes over the 256 possible values. The compaction code compresses the 88 codes into the first 88 values (i.e., A is 1, B is 2, etc.). Then master and combining characters are chosen such that the number of master characters times the number of combining characters is less than or equal to 168 and such that the frequency of the combined pairs is maximized for optimal compaction. In Figure 6, eight master characters were chosen. Of the eight letters chosen, six occurred most frequently while I and U were chosen for their key position in syllables. For combining characters the 21 most frequent characters were chosen. 36 x o uj u/Ol .- w m (OtO(0(ou>u>(C(o E > (0 ■o5 »-0((>wini0MD 7) v«-+«8--»* ~- •- -£ iAr--%=. ii : y ■ r u T° *0 moowu.O'-cio^inior^axjKaiooiiiu.o c 5 E u E 0) cr>- u)+o>5 x>.ns^- not inter* coo*. . 2 1° mtof^cDoxaiOOWij.O'-Mm^iPcor'vcoffirf Q E >. (A -isrOX>-N<0Do-oa)H-Mr- — .i-[coa at «i Is o«-Mn^in ^.<00QLJlL0I-_i5Z0D.(tWK3>J M u *• IB k. 5" ^r 5 hi 3 E > CO (dooii^o-"*!!) in<0O0> rod no roport U« No Tin. Romovod ..□ a Bactorlol Sm.or Q ' S F |nal Culturo O 2 Othar Bod Fluid. X-RAY BACTERIOLOGY O' Cho.t Q? CNS • CNS Spoeot Q| Cj2 Othor Rasp. 0^8 MommogrorrK O 2 O 3 St. I. to I Q? Pleural It Parlrmaal ' J * Dig..t;». Tract & GB O 5 Urogenital Q A Br0 | B Se ,„ Q« Cordlo.otcuio.Q B UyorScen 3 Parasitology FUNCTIONS O ' EKG Q 2 BMR ^\ 3 Pulmonary O 4 EEG TIME OF FIRST SURGERY If began within 6 hours of admission mark h«r« , o Ottiorwiso numbtr of Dayi Pr«op. Stay LTJ n OPERATIONS PATIENT NUMBER CONSULTING PHYSICIANS LID OPERATING SURGEON . SECOND SURGEON OPERATIONS SURGEON OPERATIONS .a jj.n .a m.D ZD.D .D 61 DISCHARGE SUMMARY SHEET Mtrcy Hospital • Urbana, Illinois Family Nam* Room No. Hosp. No. Attending Physician Dot* of Admission Data of Discharge Provisional Diagnosis Final Diagnosis Oporotion: Briof History and Essential Physical Findings. CODE NUMBER Significant Laboratory, X-ray, and Consultation Findings Couria in Hospital with Complication!, ■ .-,y Condition, Traotmant, Final Olspotitian on Discharge and Prognosis: Data: I havo Examined and Approved this Completed Racord Slgnad_ MP 62 MERCY HOSPITAL, Urbona, Illinois M. D. HISTORY 63 MERCY HOSPITAL, Urbona, Illinois ON THIS EXAMINATION. THE FOLLOWING SHOULD BE INCLUDED: Skin; head-eyes, •on, nun, meuthjthroat; neck; lymphnedet; chesl; breoits, heart; lungs; blood vessels, oLdc genitalia; rec ta I; bones --| o i nti , muteUf; extremities; neurological. Provisional Diagnosis: . M D PHYSICAL EXAMINATION 64 MERCY HOSPITAL, Urbane, Illinois f- rom :A trending P H y 1 I c I c ToiContult Findings: Diagnosis: Recommendations: Date_ JD Signature of Conlultonl CONSULTATION r . j . cini 65 MERCY HOSPITAL, Urbono, Illinois Surgoon Assistant Dot* Prooporotivo Olognotii Pottoporoti v» Diagnosis Operation Findings: (including tho condition of oil argons oaominod) and Procoduras (Including Incision, Ifgoruros, suturos, droinogo, ipongo count and Wound primarily cloan Hoaling o* woundi CUan --primary intontlon Stitch obseossi Homatomot Wound primarily infactod Grandulotions: D..p t.p.i.: -M.D. REPORT OF OPERATION COOt l|0 4 66 LIST OF REFERENCES [1] Amarel, S., and Kulikowski, C. "Medical Decision Making and Computer Modeling." Dept . of Computer Science, Rutgers University, New Brunswick, New Jersey, Tech- nical Report, 2 pages. [2] . "Are Office Doctors Collecting Enough Data?". Medical World News , Jan. 14, 1972, pp. 18-20. [3] . Control Data Medlab Systems . Control Data Corp., Analog-Digital Systems Division, La Jolla, Cal- ifornia, General Technical Proposal Q0049-1-RJB, Pub- lication No. X0010323, Jan. 1970. [4] . "The Medical History," Feasibility Study of Automated Medical Examining System, Philco Ford Corp., Palo Alto, Calif., Section 4, Sept. 1970, 16 pages. [5] . "Multiphasic Testing." Medical World News , Oct. 15, 1972, pp. 51-62. [6] . "Right of Privacy and Medical Computing." Data - mation , Vol. 16, No. 4, April 1970, pp. 173-178. [7] Balintrg, J. L. "The Camp System for Computerized Menu Plans." Hospitals, J.A.H.A . , Vol. 45, May 16, 1971, pp. 92-96. [8] Ball, M. "Effectiveness of On-Line Data Acquisition in the Clinical Laboratory," Journal of the Assoc, for the Advancement of Medical Instrumentation , Vol. 6, No. 1, Jan. -Feb. 1972, pp. 28-31. [9] Barnett, G. 0., Greenes, R. A., and Grossman, J. H. "Computer Processing of Medical Test Information." Methods of Information in Med icine, Oct. 1969, pp. 177-182. [10] Barnett, G. O. , and Greenes, R. A. "Interface Aspects of A Hospital Information System." Annals of t he Ne w York Academy of Science s , Sept. 30, 1969, pp. 756-768. [11] Baruch, J. J., and Barnett, G. 0. "Joint Venture at Massachusetts General." Datamation , Vol. 11, No. 12, Dec. 1965, pp. 29-33. 67 [12] Berlin, M. M. "Computers in the Laboratory." Computers and Automation , Vol. 19, No. 6, June 1970, pp. 24-27. [13] Bond, V. B., Bowman, C. M. , Lee, N. L., Petersen, D. R. , and Reslock, M. H. "Interactive Searching of a Struc- ture and Biological Activity File." Journal of Chem - ical Documentation , Vol. 11, No. 3, 1971, pp. 168-170. [14] Cashman, M. W. "A Read/Write Optical Memory System." Datamation , Vol. 19, No. 3, March 1973, pp. 66-69. [15] Clary, M. D. "Data Processing Requirements for Health Insurance." Datamation , Vol. 16, No. 3, March 1970, pp. 81-86. [16] Coe , F. L. "A Computer Based Diagnostic and Data Manage- ment Program for Kidney Stones." Michael Reese Hosp. and Med. Center, Pritzker School of Medicine, Univ. of Chicago, Chicago, Illinois, 3 pages. [17] Craig, J. L. , and Derryberry , 0. M. "Applied Concepts of Automation in an Occupational Medical Program." In - dustrial Medicine , Vol. 40, No. 5, August 1971, pp. 9- 17. [18] Dearden, J., and McFarlan, F. W. Management Information Systems: Text and Cases , Richard D. Irwin, Inc., Homewood , Illinois, 1966. [19] Gabrielli, E. R. "Dual Data System in the Hospital." Journal of Clinical Computing , Dec. 1971, pp. 4-7. [20] Gabrielli, E. R. "Organization of the Information Con- tained in the Clinical Chart." Journal of Clinical Computing , June 1971, pp. 1-7. [21] Gabrielli, E. R. , Newcombe , H., Teitelbaum, L. E., Shep- ley, M. D., and Sagen, 0. K. Blueprint of the Western New York Health Data Network , Report of the Medical Society of the County of Erie, New York. [22] Geisler, R. "The Thomis Medical Information System." Datamation , Vol. 16, No. 6, June 1970, pp. 133-136. [23] Gouvela, W. A., Diamantis, C, and Barnett , G. O. "Com- puter Applications in the Hospital Medication System." American Journal of Hospital Pharmacy , Mar. 1969, pp. 140-150. [24] Greenes, R. A. "Medical Information Systems: A Look Ahead." Conf. on Computers in Radiology, Columbia, Missouri, Sept. 1970, 14 pages. 68 [25] Greenes, R. A., Barnett, G. 0., Klein, S. W. , Robbins , A., and Prior, R. E. "Recording, Retrieval and Review of Medical Data by Physician Computer Interaction." New England Journal of Medicine , Feb. 5, 1970, pp. 307-315. [26] Greenes, R. A., Pappalardo, A. N. , Marble, C. W. , and Barnett, G. 0. "A System for Clinical Data Manage- ment." Proc . of the Fall Joint Comp. Conf ., Vol. 35, 1969, pp. 297-305. [27] Haggerty , J. R. "Computerized Information System." Hos - pitals, J.A.H.A ., Vol. 44, Nov. 1, 1970, pp. 43-46. [28] Hall, P., Mellner, C. H. , and Danielsson, T. "A Data Processing System for Medical Information," Methods of Information in Medicine , Vol. 6, No. 1, Jan. 1967, pp. 1-6. [29] Hemmer, J. "The Data Transmission System." Upstate Med- ical Center, Syracuse, New York, Technical Report, 7 pages. [30] Hoffman, P. B. , Grossman, J. H., Thoren, V. J., and Barnett, G. O. "Automated Patient Census Operation: Design, Development, Evaluation," Hospital Topics , May, 1969. [31] Holmgren, J. H., and Zimmerman, W. "Computerized Order- ing: How it Works, What it Does." The Modern Hospi - tal , March 1971, p. 70. [32] Hopp, D. I., and Cable, J. D. "The Construction of the Clinical Data Base." Journal of the Assoc, for the Advancement of Medical Instrumentation , Vol. 6, No. 1, Jan. -Feb. 1972, pp. 32-37. [33] Jackson, G. G. "Information Handling Costs in Hospitals." Datamation , Vol. 15, No. 5, May 1969, pp. 56-59. [34] Jackson, G. G. "The Role of Administrators and Physicians in the Development of Hospital Information Systems." Computers and Automation , Vol. 19, No. 6, June 1970, pp. 33-35. [35] Jacobs, J. F. Jr., Davis, R. F., and Bakerman, S. "Com- puter Diagnosis Generated from SMA-12/60 Chemistry Profiles." Journal of the Assoc, for the Advancement of Medical Instrumentation , Vol. 6, No. 1, Jan. -Feb. 1972, pp. 37-42. [36] Jenkins, D. R. "Problems of Computer Applications in Med- ical Research." Transactions New York Academy of Sciences , 1966, pp. 439-447. 69 [37] Josephus, M. , and Venarda, M. "How Mercy Planned its Communications." The Modern Hospital , August 1966, pp. 87-89. [38] Jydstrup, R. A., and Gross, M. J. "Cost of Information Handling in Hospitals." Health Services Research , Winter 1966, pp. 235-271. [39] Katona, P. G., Pappalardo, A. N. , Marble, C. W. , Barnett G. 0. , and Pashby, M. M. "Automated Chemistry Labora- tory: Application of a Novel Time-Shared Computer System." Proc . of the IEEE , Vol. 57, No. 11, Nov. 1969, pp. 2000-2006. [40] Liu, H. "A File Management System for a Large Corporate Information System Data Bank." Proc. of the Fall Joint Comp. Conf . , Vol. 13, 1968, pp. 145-156. [41] Matthews, D. Q. The Design of the Management Information System . Averbach Publishers, New York, New York, 1971. [42] McLaughlin, R. A. "A Bleak Future for Discs?" Datamation , Vol. 19, No. 4, April 1973, pp. 106-108. [43] McNabb, M. E. "90-Day Nonselective Menus by Computer." Hospitals, J.A.H.A ., Vol. 45, May 16, 1971, pp. 88-91. [44] Mueller, W. J., Walsh, L. F., Hemmer , J. A., and Allen, F. H. "Patient Oriented Hospital Information System." Workshop on Hospital Information Systems 23rd ACEMB , Washington, D.C., November 1970, 5 pages. [45] Mulford, J. E. , and Ridell, R. K. "Data Compression Techniques for Economic Processing of Large Commercial' Files." ACM Symposium on Information Storage and Re - trieval , 1971, pp. 207-215. [46] Myers, J., Gelblat, M. , and Enterline, H. T. "Automatic Encoding of Pathology Data." Archives of Pathology , Vol. 89, Jan. 1970, pp. 73-78. [47] O'Brien, J. J. Management Information Systems Concepts , Techniques, and Applications , Van Nostrand Reinhold Co. , New York, 1970. [48] Opit, J. J., and Woodroffe, F. J. "Computer-Held Clini- cal Record System--I, Description of System." British Medical Journal , Vol. 4, Oct. 1970, pp. 76-79, and "Computer-Held Clinical Record System--II, Assessment." British Medical Journal, Vol. 4, 1970, pp. 80-92. 70 [49] Pendergrass, H. P., Greenes, R. A., Barnett , G. O., Poitras, J. W. , Pappalardo, A. N. , and Marble, C. W. "An On-Line Computer Facility for Systematized Input of Radiology Reports." Radiology , March 1969, pp. 709- 713. [50] Pollycove, M. "Benefits and Disadvantages of Clinical Laboratory Computerization." Journal of the Assoc . for the Advancement of Medical Instrumentation , Vol. 6, No. 1, Jan. -Feb. 1972, pp. 42-46. [51] Reilly, N. B. "Computers in Medicine." Datamation , Vol. 15, No. 5, May 1969, pp. 46-49. [52] Reingold, E. M. "Notes on AVL Trees." Department of Computer Science, University of Illinois, Urbana , Illinois, Report No. 411, May 1971. [53] Rothfeld, M. "Sensible Surgery for Swelling Medical Costs." Fortune , Vol. 86, April 1973, pp. HOff. [54] Ruderman, M. "The Hospital Computer Comes of Age." Computers and Automation , Vol. 19, No. 6, June 1970, pp. 28-32. [55] Ruth, S. S., and Kreutzer, P. J. "Data Compression for Large Business Files." Datamation , Vol. 18, No. 9, Sept. 1972, pp. 62-66. [56] Schwartz, M. D. "Status of Hospital Information Systems." Hospital Progress , June 1970, pp. 53-60. [57] Silver, H. K. , Kempe , H., and Bruyn , H. B. Handbook of Pediatrics , Lange Medical Publications, Los Altos, California, 1969. [58] Singer, J. P. "Computer-Based Hospital Information Sys- tems." Datamation , Vol. 15, No. 5, May 1969, pp. 38- 45. [59] Singer, J. P., and Petro, F. A. "A Case History: Imple- mentation of a Computer-Based Patient Accounting Sys- tem." Computers and Automation , Vol. 19, No. 6, June 1970, pp. 19-22. [60] Smith, R. M. "How To Automate A Hospital." Management Services , Jul. -Aug. 1966, pp. 48-53. [61] Snyderman, M., and Hunt, B. "The Myriad Virtues of Text Compaction." Datamation , Vol. 16, No. 16, Dec. 1970, pp. 36-40. 71 [62] Souder , J. J. "Computers Can Bring a New Rationality into Hospital Design." The Modern Hospital , Vol. 108, March 1968, pp. 80-86. [63] Spann , M. L., and Willis, D. D. "A Comparative Study of a Fragmentation vs. a Topological Coding System in Chemical Substructure Searching." Journal of Chemical Documentation , Vol. 11, No. 1, Nov. 1971, pp. 43-47. [64] Springer, E. W. Automated Medical Records and the Law , Health Law Center, Division of Aspen Systems Corpora- tion, Pittsburgh, Penn., 1971. [65] Springer, G. D., Jr. "One Computer Works for Three Hos- pitals." The Modern Hospital , Vol. 107, No. 1, August 1966. [66] Wagner, R. A. "Common Phrases and Minimum Space Text Storage." Communications of the ACM , Vol. 16, No. 3, March 1973, pp. 148-152. [67] Walsh, L. F. "Data Communication System for On-Line Hos- pital Computer Applications." State University of New York, Syracuse, New York, 11 pages. [68] Weed, L. L. Medical Records, Medical Education, and Pa - tient Care , The Press of Case Western Reserve Univ. , Cleveland, Ohio, 1970. [69] Wells, A. H. "The Lexicon of Medical Practice for Com- puter." College of American Pathologists , Sept. 1972, pp. 229-237. [70] Wright, M. A. "Mechanizing a Large Index." The Computer Journal , Vol. 3, No. 2, July 1960, pp. 76-83. [71] Yarnall, S. R. "The Central Role of the Data Base His- tory in Health Screening." University of Washington School of Medicine, 15 pages. BIBLIOGRAPHIC DATA SHEET 1. Report No. UIUCDCS-R -73-589 3. Recipient's Accession No. 4. Title and Subtitle Architecture of a Community Medical History Data Base 5. Report Date August 7, 1973 7. Author(s) Craig Alan Mills 8. Performing Organization Rept. No - UIUCDCS-R-73-589 9. Performing Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana., Illinois 61801 10. Project/Task/Work Unit No. 11. Contract /Grant No. 12. Sponsoring Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 6l801 13. Type of Report & Period Covered Thesis Research 14. 15. Supplementary Notes 16. Abstracts The medical profession has many cumbersome methods, such as most present medical codes, handwritten records, and the amount of paperwork involved in the care of a patient. These cumbersome methods and the establishment of Medicare, insurance forms, and other red tape which have become an intricate part of our society hinder the development of computer applications in the medical profession. This paper attempts to cover the many legal, security, and technical problems that arise. A general background of computer applications in the medical professions is given with emphasis on the usefulness of a medical history data base. From such computer applications, the medical profession will derive innumerable benefits. These benefits include more complete records, more individualized care, and efficient handling of paperwork. 17. Key Words and Document Analysis. 17a. Descriptors Data base, information retrieval, automated medical records, data compaction, computers and the hospital, community medical record data base. 17b. Identifiers /Open-Ended Terms 17c. COSATI Field/Group 18. Availability Statement Unlimited Release 19. Security Class (This Report) UNCLASSIFIED 20. Security Class (This Page UNCLASSIFIED 21. No. of Pages 75 22. Price FORM NTIS-35 (10-70) USCOMM-DC 40329-P7! NOV \ 5 *376 Jf* , » ^ nflffl 1 JB HI MSB I B I 1 mm m Wmm IwflflMlfl