Hospital Information Systems: Their Function and State

175.1

Patient Database Strategies for the HIS

175.2

Data Acquisition

175.3

Patient Admission, Transfer, and Discharge Functions

175.4

Patient Evaluation

T. Allan Pryor

175.5

Patient Management

University of Utah

175.6

Conclusion

The definition of a hospital information system (HIS) is unfortunately not unique. The literature of both the informatics community and health care data processing world is filled with descriptions of many differing computer systems defined as an HIS. In this literature, the systems are sometimes characterized into varying level of HISs according to the functionally present within the system. With this confusion from the literature, it is necessary to begin this chapter with a definition of an HIS. To begin this definition,

Must first describe what it is not. The HIS will incorporate information from the several departments within the hospital, but an HIS is not a departmental system. Departmental systems such as a pharmacy or a radiology system are limited in their scope. They are designed to manage only the department that they serve and rarely contain patient data captured from other departments. Their function should be to interface with the HIS and provide portions of the patient medical/administrative record that the HIS uses to manage the global needs of the hospital and patient.

A clinical information system is likewise not an HIS. Again, although the HIS needs clinical information to meets its complete functionality, it is not exclusively restricted to the clinical information supported by the clinical information systems. Examples of clinical information systems are ICU systems, respiratory care systems, nursing systems. Similar to the departmental systems, these clinical systems tend to be one­dimensional with a total focus on one aspect of the clinical needs of the patient. They provide little support for the administrative requirements of the hospital.

If we look at the functional capabilities of both the clinical and departmental systems, we see many common features of the HIS. They all require a database for recording patient information. Both types of systems must be able to support data acquisition and reporting of patient data. Communication of information to other clinical or administrative departments is required. Some form of management support can be found in all the systems. Thus, again looking at the basic functions of the system one cannot differentiate the clinical/departmental systems from the HIS. It is this confusion that makes defining the HIS difficult and explains why the literature is ambiguous in this matter.

The concept of the HIS appears to be, therefore, one of integration and breadth across the patient or hospital information needs. That is, to be called an HIS the system must meet the global needs of those it is to serve. In the context, if we look at the hospital as the customer of the HIS, then the HIS must be able to provide global and departmental information on the state of the hospital. For example, if we consider the capturing of charges within the hospital to be an HIS function, then the system must capture all patient charges no matter which departmental originated those charges. Likewise all clinical informa­tion about the patient must reside within the database of the HIS and make possible the reporting and management of patient data across all clinical departments and data sources. It is totality of function that differentiates the HIS from the departmental or restricted clinical system, not the functions provided to a department or clinical support incorporated within the system.

The development of an HIS can take many architectural forms. It can be accomplished through interfacing of a central system to multiple departmental or clinical information systems. A second approach which has been developed is to have, in addition to a set of global applications, departmental or clinical system applications. Because of the limitation of all existing systems, any existing comprehen­sive HIS will in fact be a combination of interfaces to departmental/clinical systems and the applica­tions/database of the HIS purchased by the hospital.

The remainder of this chapter will describe key features that must be included in today’s HIS. The features discussed below are patient databases, patient data acquisition, patient admission/bed control, patient management and evaluation applications, and computer-assisted decision support. This chapter will not discuss the financial/administrative applications of an HIS, since those applications for the purposes of this chapter are seen as applications existing on a financial system that may not be integral application of the HIS.

Patient Database Strategies for the HIS

The first HISs were considered only an extension of the financial and administrative systems in place in the hospital. With this simplistic view many early systems developed database strategies that were limited in their growth potential. Their databases mimicked closely the design of the financial systems that presented a structure that was basically a “flat file” with well-defined fields. Although those fields were adequate for capturing the financial information used by administration to track the patient’s charges, they were unable to adapt easily to the requirement to capture the clinical information being requested by health care providers. Today’s HIS database should be designed to support a longitudinal patient record (the entire clinical record of the patient spanning multiple inpatient, outpatient encounters), integration of all clinical and financial data, and support of decision support functions.

The creation of a longitudinal patient record is now a requirement of the HIS. Traditionally the databases of the HISs were encounter-based. That is, they were designed to manage a single patient visit to the hospital to create a financial record of the visit and make available to the care provider data recorded during the visit. Unfortunately, with those systems the care providers were unable to view the progress of the patient across encounters, even to the point that in some HISs critical information such as patient allergies needed to be entered with each new encounter. From the clinical perspective, the management of a patient must at least be considered in the context of a single episode of care. This episode might include one or more visits to the hospital’s outpatient clinics, the emergency department, and multiple inpatient stays. The care provider to manage properly the patient, must have access to all the information recorded from those multiple encounters. The need for a longitudinal view dictates that the HIS database structure must both allow for access to the patient’s data independent of an encounter and still provide for encounter-based access to adapt to the financial and billing requirements of the hospital.

The need for integration of the patient data is as important as the longitudinal requirement. Tradi­tionally the clinical information tended to be stored in separate departmental files. With this structure it was easy to report from each department, but the creation of reports combining data from the different proved difficult if not impossible. In particular in those systems where access to the departmental data was provided only though interfaces with no central database, it was impossible to create an integrated patient evaluation report. Using those systems the care providers would view data from different screens at their terminal and extract with pencil onto paper the results from each departmental (clinical labo­ratory, radiology, pharmacy, and so on) the information they needed to properly evaluate the patient. With the integrated clinical database the care provider can view directly on a single screen the information from all departments formatted in ways that facilitate the evaluation of the patient.

Today’s HIS is no longer merely a database and communication system but is an assistant in the management of the patient. That is, clinical knowledge bases are an integral part of the HIS. These knowledge bases contain rules and/or statistics with which the system can provide alerts or reminders or implement clinical protocols. The execution of the knowledge is highly dependent on the structure of the clinical database. For example, a rule might be present in the knowledge base to evaluate the use of narcotics by the patient. Depending on the structure of the database, this may require a complex set of rules looking at every possible narcotic available in the hospital’s formulary or a single rule that checks the presence of the class narcotics in the patient’s medical record. If the search requires multiple rules, it is probably because the medical vocabulary has been coded without any structure. With this lack of structure there needs to be a specific rule to evaluate every possible narcotic code in the hospital’s formulary against the patient’s computer medication record. With a more structured data model a single rule could suffice. With this model the drug codes have been assigned to include a hierarchical structure where all narcotics would fall into the same hierarchical class. Thus, a single rule specific only to the class “narcotics” is all that is needed to compare against the patient’s record.

These enhanced features of the HIS database are necessary if the HIS is going to serve the needs of today’s modern hospital. Beyond these inpatient needs, the database of the HIS will become part of an enterprise clinical database that will include not only the clinical information for the inpatient encounters but also the clinical information recorded in the physician’s office or the patient’s home during outpatient encounters. Subsets of these records will become part of state and national health care databases. In selecting, therefore, and HIS, the most critical factor is understanding the structure and functionality of its database.

Data Acquisition

The acquisition of clinical data is key to the other functions of the HIS. If the HIS is to support an integrated patient record, then its ability to acquire clinical data from a variety of sources directly affect its ability to support the patient evaluation and management functions described below. All HIS systems provide for direct terminal entry of data. Depending on the system this entry may use only the keyboard or other “point and click” devices together with the keyboard.

Interfaces to other systems will be necessary to compute a complete patient record. The physical interface to those systems is straightforward with today’s technology. The difficulty comes in understand­ing the data that are being transmitted between systems. It is easy to communicate and understand ASCII textual information, but coded information from different systems is generally difficult for sharing between systems. This difficulty results because there are no medical standards for either medical vocab­ulary or the coding systems. Thus, each system may have chose an entirely different terminology or coding system to describe similar medical concepts. In building the interface, therefore, it may be necessary to build unique translation tables to store the information from one system into the databases of the HIS. This requirement has limited the building of truly integrated patient records.

Acquisition of data from patient monitors used in the hospital can either be directly interfaced to the HIS or captured through an interface to an ICU system. Without these interfaces the acquisition of the monitoring data must be entered manually by the nursing personnel. It should be noted that whenever possible automated acquisition of data is preferable to manual entry. The automated acquisition is more accurate and reliable and less resource intensive. With those HISs which do not have interfaces to patient monitors, the frequency of data entry into the system is much less. The frequency of data acquisition affects the ability of the HIS to implement real-time medical decision logic to monitor the status of the patient. That is, in the ICU where decisions need to be made on a very timely manner, the information on which the decision is based must be entered as the critical event is taking place. If there is no automatic entry of the data, then the critical data needed for decision making may not be present, thus preventing the computer from assisting in the management of the patient.

Patient Admission, Transfer, and Discharge Functions

The admission application has three primary functions. The first is to capture for the patient’s computer record pertinent demographic and financial/insurance information. A second function is to communicate that information to all systems existing on the hospital network. The third is to link the patient to previous encounters to ensure that the patient’s longitudinal record is not compromised. This linkage also assists in capturing the demographic and financial data needed for the current encounter, since that information captured during a previous encounter may need not to be reentered as part of this admission. Unfortu­nately in many HISs the linkage process is not as accurate as needed. Several reasons explain this inaccuracy. The first is the motivation of the admitting personnel. In some hospitals they perceive their task as a business function responsible only for ensuring that the patient will be properly billed for his or her hospital stay. Therefore, since the admission program always allows them to create a new record and enter the necessary insurance/billing information, their effort to link the patient to his previous record may not be as exhaustive as needed.

Although the admitting program may interact with many financial and insurance files, there normally exists two key patient files that allow the HIS to meet its critical clinical functions. One is a master patient index (MPI) and the second is the longitudinal clinical file. The MPI contains the unique identifier for the patient. The other fields of this file are those necessary for the admitting clerk to identify the patient. During the admitting process the admitting process the admitting clerk will enter identifying information such as name, sex, birth date, social security number. This information will be used by the program to select potential patient matches in the MPI from which the admitting clerk can link to the current admission. If no matches are detected by the program, the clerk creates a new record in the MPI. It is this process that all too frequently fails. That is, the clerk either enters erroneous data and finds no match or for some reason does not select as a match one of the records displayed. Occasionally the clerk selects the wrong match causing the data from this admission to be posted to the wrong patient. In the earlier HISs where no longitudinal record existed, this problem was not critical, but in today’s system, errors in matching can have serious clinical consequences. Many techniques are being implemented to eliminate this problem including probabilistic matching, auditing processes, postadmission consolidation.

The longitudinal record may contain either a complete clinical record of the patient or only those variables that are most critical in subsequent admissions. Among the data that have been determined as most critical are key demographic data, allergies, surgical procedures, discharge diagnoses, and radiology reports. Beyond these key data elements more systems are beginning to store the complete clinical record. In those systems the structure of the records of the longitudinal file contain information regarding the encounter, admitting physician, and any other information that may be necessary to view the record from an encounter view or as a complete clinical history of the patient.

Patient Evaluation

The second major focus of application development for the HIS is creation of patient evaluation appli­cations. The purpose of these evaluation programs is to provide to the care giver information about the patient which assists in evaluating the medical status of the patient. Depending on the level of data integration in the HIS, the evaluation applications will be either quite rudimentary or highly complex. In the simplest form these applications are departmentally oriented. With this departmental orientation the care giver can access through terminals in the hospital departmental reports. Thus, laboratory reports, radiology reports, pharmacy reports, nursing records, and the like can be displayed or printed at the hospital terminals. This form of evaluation functionality is commonly called results review, since it only allows the results of tests from the departments to be displayed with no attempt to integrate the data from those departments into an integrated patient evaluation report.

The more clinical HISs as mentioned above include a central integrated patient database. With those systems patient reports can be much more sophisticated. A simple example of an integrated patient evaluation report is a diabetic flowsheet. In this flowsheet the caregiver can view the time and amount of insulin given, which may have been recorded by the pharmacy or nursing application, the patient’s blood glucose level recorded in the clinical laboratory or again by the nursing application. In this form the caregiver has within single report, correlated by the computer, the clinical information necessary to evaluate the patient’s diabetic status rather than looking for data on reports from the laboratory system, the pharmacy system, and the nursing application. As the amount and type of data captured by the HIS increases, the system can produce ever-more-useful patient evaluation reports. There exist HISs which provide complete rounds reports the summarize on one to two screens all the patient’s clinical record captured by the system. These reports not only shorten the time need by the caregiver to locate the information, but because of the format of the report, can present the data in a more intuitive and clinically useful form.

Patient Management

Once the caregiver has properly evaluated the state of the patient, the next task is to initiate therapy that ensures an optimal outcome for the patient. The sophistication of the management applications is again a key differentiation of HISs. At the simplest level management applications consist of order-entry applications. The order-entry application is normally executed by a paramedical personnel. That is, the physician writes the order in the patient’s chart, and another person reviews from the chart the written order and enters it into the computer. For example, if the order is for a medication, then it will probably be a pharmacist who actually enters the order into the computer. For most of the other orders a nurse or ward clerk is normally assigned this task. The HIS records the order in the patient’s computerized medical record and transmits the order to the appropriate department for execution. In those hospitals where the departmental systems are interfaced to the HIS, the electronic transmission of the order to the departmental system is a natural part of the order entry system. In many systems the transmission of the order is merely a printout of the order in the appropriate department.

The goal of most HISs is to have the physician responsible for management of the patient enter the orders into the computer. The problem that has troubled most of the HISs in achieving this goal has been the inefficiency of the current order-entry programs. For these programs to be successful they have to complete favorably with the traditional manner in which the physician writes the order. Unfortunately, most of the current order-entry applications are too cumbersome to be readily accepted by the physician. Generally they have been written to assist the paramedic in entering the order resulting with far too many screens or fields that need to be reviewed by the physician to complete the order. One approach that has been tried with limited success is the use of order sets. The order sets have been designed to allow the physician to easily from a single screen enter multiple orders. The use of order sets has improved the acceptability of the order-entry application to the physician, but several problems remain preventing universal acceptance by the physicians. One problem is that the order set will never be sufficiently complete to contain all orders that the physician would want to order. Therefore, there is some subset of patients orders that will have to be entered using the general ordering mechanisms of the program. Depending on the frequency of those orders, the acceptability of the program changes. Maintenance issues also arise with order sets, since it may be necessary to formulate order sets for each of the active physicians. Maintaining of the physician-specific order sets soon becomes a major problem for the data processing department. It becomes more problematic if the HIS to increase the frequency of a given order being present on an order set allows the order sets to be not only physician-defined but problem — oriented as well. Here it is necessary to again increase the number of order sets or have the physicians all agree on those orders to be included in an order set for a given problem.

Another problem, which makes use of order entry by the physician difficult, is the lack of integration of the application into the intellectual tasks of the physician. That is, in most of the systems the physicians are asked to do all the intellectual work in evaluating and managing the care of the patient in the traditional manner and then, as an added task, enter the results of that intellectual effort into the computer. It is at this last step that is perceived by the physician as a clerical task at which the physician rebels. Newer systems are beginning to incorporate more efficiently the ordering task into other appli­cations. These applications assist the physical throughout the entire intellectual effort of patient evaluation and management of the patient. An example of such integration would be the building of evaluation and order sets in the problem list management application. Here when the care provider looks at the patient problem list he or she accesses problem-specific evaluation and ordering screens built into the application, perhaps shortening the time necessary for the physician to make rounds on the patient.

Beyond simple test ordering, many newer HISs are implementing decision support packages. With these packages the system can incorporate medical knowledge usually as rule sets to assist the care provider in the management of patients. Execution of the rule sets can be performed in the foreground through direct calls from an executing application or in the background with the storing of clinical data in the patient’s computerized medical record. This latter mode is called data-driven execution and provides an extremely powerful method of knowledge execution and alerting. that is, after execution of the rule sets, the HIS will “alert” the care provider of any outstanding information that may be important regarding the status of the patient or suggestions on the management of the patient. Several mechanisms have been implemented to direct the alerts to the care provider. In the simplest form notification is merely a process of storing the alert in the patient’s medical record to be reviewed the next time the care provider accesses that patient’s record. More sophisticated notification methods have included directed printouts to indi­viduals whose job it is to monitor the alerts, electronic messages sent directly to terminals notifying the users that there are alerts which need to be viewed, and interfacing to the paging system of the hospital to direct alert pages to the appropriate personnel.

Execution of the rule sets are sometimes, time-driven. This mode results in sets of rules being executed at a particular point in time. The typical scenario for time-driven execution is to set a time of day for selected rule set execution. At that time each day the system executes the given set of rules for a selected population in the hospital. Time drive has proven to be a particularly useful mechanism of decision support for those applications that require hospitalwide patient monitoring.

The use of decision support has ranged from simple laboratory alerts to complex patient protocols. The responsibility of the HIS is to provide the tools for creation and execution of the knowledge base. The hospitals and their designated “experts” are responsible for the actual logic that is entered into the rule sets. Many studies are appearing in the literature suggesting that the addition of knowledge base execution tot he HIS is the next major advancement to e delivered with the HIS. This addition will become a tool to better manage the hospital in the world of managed care.

The inclusion of decision support functionality in the HIS requires that the HIS be designed to support a set of knowledge tools. In general a knowledge bases system will consist of a knowledge base and an inference engine. The knowledge base will contain the rules, frames, and statistics that are used by the inference applications to substantiate a decision. We have found that in the health care area the knowledge base should be sufficiently flexible to support multiple forms of knowledge. That is, no single knowledge representation sufficiently powerful to provide a method to cover all decisions necessary in the hospital setting. For example, some diagnostic decisions may well be best suited for bayesian methods, whereas other management decisions may follow simple rules. In the context of the HIS, I prefer the term application manager to inference engine. The former is intended to imply that different applications may require different knowledge representations as well as different inferencing strategies to traverse the knowledge base. Thus, when the user selects the application, he or she is selecting a particular inference engine that may be unique to that application. The tasks, therefore, of the application manager are to provide the “look and feel” of the application, control the functional capabilities of the application, and invoke the appropriate inference engine for support of any “artificial intelligence” functionality.

175.6 Conclusion

Today’s HIS is no longer the financial/administrative system that first appeared in the hospital. It has extended beyond that role to become an adjunct to the care of the patient. With this extension into clinical care the HIS has not only added new functionality to its design but has enhanced its ability to serve the traditional administrative and financial needs of the hospital as well. The creation of these global applications which go well beyond those of the departmental/clinical systems is now making the HIS the patient — focused system. With this global information the administrators and clinical staff together can accurately access where there are inefficiencies in the operation of the hospital from the delivery of both the administrative and medical care. This knowledge allows changes in the operation of the hospital that will ensure that optimal care continues to be provided to the patient at the least cost to the hospital. These studies and operation changes will continue to grow as the use of an integrated database and implementation of medical knowledge bases become increasingly routine in the functionality of the HIS.

References

Pryor TA, Gardner RM, Clayton PD, et al. 1983. The HELP system. J Med syst 7:213.

Pryor TA, Clayton PD, Haug PJ, et al. 1987. Design of a knowledge driven HIS. Proc. 11th SCAMC, 60.

Bakker AR. 1984. The development of an integrated and co-operative hospital information system. Med Inf 9:135.

Barnett GO. 1984. The application of computer-based medical record systems in ambulatory practice. N Engl J Med 310:1643.

Bleich HL, Beckley RF, Horowitz GL, et al. 1985. Clinical computing in a teaching hospital. N Engl J Med 312:756.

Whiting-O’Keefe QE, Whiting A, Henke J. 1988. The STOR clinical information system. MD Comput 5:8.

Hendrickson G, Anderson RK, Clayton PD, et al.1992. The integrated academic information system at Columbia-Presbyterian Medical Center. MD Comput 9:35.

Safran C, Slack WV, Bleich HL. 1989. Role of computing in patient care in two hospitals. MD Comput 6:141.

Bleich HL, Safran C, Slack WV. 1989. Departmental and laboratory computing in two hospitals. MD Comput 6:149.

ASTM E1238-91. 1992. Specifications for transferring clinical observations between independent computer systems. Philadelphia, American Society for Testing and Materials.

Tierney WM, Miller ME, Donald CJ. 1990. The effect on test ordering of informing physicians of the charges for outpatient diagnostic tests. N Engl J Med 322:1499.

Stead WW, Hammond WE. 1983. Functions required to allow TMR to support the information requirements of a hospital. Proc 7th SCAMC 106.

Safran C, Herrmann F, Rind D, et al. 1990. Computer-based support for clinical decision making. MD Comput 7:319.

Tate KE, Gardner RM, Pryor TA. 1989. Development of a computerized laboratory alerting system. Comp Biomed Res 22:575.

Orthner HF, Blum BI (eds). 1989. Implementing Health Care Information Systems, Springer­Verlag.

Dick RS, Steen EB (eds). 1991. The Computer-Based Patient Record, National Academy Press.

Fitzmaurice, J. M. “Computer-Based Patient Records.” The Biomedical Engineering Handbook: Second Edition. Ed. Joseph D. Bronzino Boca Raton: CRC Press LLC, 2000

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *