GB2406417A

GB2406417A - System and method for a user interface for an integrated electronic health care information system

Info

Publication number: GB2406417A
Application number: GB0428466A
Authority: GB
Inventors: Carl David Dvorak; Khiang Seow; Daniel Bormann; Steve Larsen; Cliff Michalski; Andrew Ma; Mark Lipsky; Tony Brummel
Original assignee: Epic Systems Corp
Current assignee: Epic Systems Corp
Priority date: 2000-12-22
Filing date: 2001-12-21
Publication date: 2005-03-30
Also published as: GB0428466D0

Abstract

In accordance with one aspect of the invention, a patient-centered integrated health care record is provided including information related to health care delivery for a patient, and information related to health care delivery management for the patient. The integrated health care record may be used with a health care system to facilitate management of and to provide health care for patients. The health care delivery information and the health care delivery management information for patients may be stored within the UPR [100, fig 2] as patient records, with one patient record per patient. The information may be stored as formatted data, links to formatted data, or as selections from a list. In one embodiment, audit functionality is provided, where contact with data records is recorded as an audit trail. In another embodiment, security functionality is provided, controlling access to the integrated health care record. In another embodiment, a lock manager is provided, controlling write access to the integrated health care record. In accordance with another aspect of the invention, an electronic health care system includes a modular framework [628, fig 19] and a display [622, fig 19] in communication with the modular framework for providing a graphical user interface to a system user. The modular framework includes a plurality of activities, each activity providing an aspect of patient care, where the framework is adaptable for accepting additional activities forming a single integrated system. The graphical user interface is adaptable for displaying information corresponding to one or more of the activities, and includes a common menu format for communicating available operations in the graphical user interface, and common visual components for displaying information to a system user.

Description

240641 7 ,

SYSTEM AND METHOD FOR A SEAMLESS USER INTERFACE FOR AN

INTEGRATED ELECTRONIC HEALTH CARE INFORMATION SYSTEM

Field of the Invention

The present invention relates to a seamless user interface adaptable to an integrated electronic health care system.

Background of the Invention

Health care enterprises provide various aspects of patient care. To provide patient care, it is necessary to maintain many types of information for patients.

This information includes medical information such as allergies, current medical conditions, records of encounters with health care providers, and medical history such as immunization records, past conditions and procedures, laboratory results, family history, social history and risk factors. Health care enterprises must further maintain information regarding risk management such as payers, coverages and patient benefit information, claim history, financial information such as patient account balances and insurance balances, and patient demographic information such as patient addresses, religious contacts, emergency contacts and patient employer information.

Access to these types of information is typically provided through electronic medical record and practice management information system software, embodied in a variety of separate software applications having user interfaces which are disparate in appearance and operation. Further, the variety of separate software applications are limited in the information which they can provide, typically to information related to the type of service being provided.

For example, when a patient is at a primary care physician's office for an appointment, the physician may run a medical condition/history application having one user interface configuration for accessing medical history and entering current medical conditions, including any treatments done, and tests which need to be performed on the patient. This

-

information is stored in a patient record corresponding to the medical history/condition application. The patient is then sent to the scheduling desk, where the person in charge of scheduling tests opens a scheduling application having another user interface configuration, different in appearance and operation than the first. The required test is entered and the test is scheduled. The required test and scheduled tune are then stored in another patient record corresponding to the scheduling application. After scheduling, the patient is sent to the accountant for the of lice, where an accounting application (which may, for example, be part of a risk management application) having yet a third user interface configuration different in appearance and operation from the first and second user interfaces, is accessed for handling the billing of the patient The billing clerk enters the treatments performed on the patient, accesses the patient insurance information, and generates a bill. The treatment, insurance and billing infonnation is stored in a record corresponding to the patient in the accounting application.

1 j Storing the patient information in patient records associated with the various software applications causes patient information to be duplicated multiple times, requinug storage media with greater storage capacity. In addition, the utilization of multiple, separate software applications, and the maintenance of various patient information across records for several different applications renders compliance with legislative requirements such as the Health Insurance Portability and Accountability Act (HIPAA) difficult. For example, the H1PAA has specific requirements for patient medical records such as maintaining data authentication for verifying data in patient records, authorization controls for controlling access to patient records, and audit controls for recording accesses/changes to patient records.

Regarding data verification, where duplicated information is entered for a patient in various software applications, the chance for errors in the data increase. When there is a conflict in the patient data corresponding to one application as compared with corresponding patient data present in another application, it is often difficult to reconcile which information is correct to verify the patient data Regarding authentication controls, the use of multiple applications increases the difficulty for maintaining the correct security requirements for the applications, as ! multiple security files must be maintained. The security.fUes for the various applications may include duplicated, and possibly conflicting data, increasing chances of providing a system user with erroneous security access to patient records.

Regarding audit controls, the use of multiple software applications results in the generation of multiple audit records for each patient andlor system user. Where it is desired to know the audit trail for particular patient record or system user, multiple audit reports must be generated. Each audit report will typically contain information duplicated in other audit reports, making it difficult and time consuming to sift through the various audit reports to locate specific audit information.

Storing patient information in patient records corresponding to various software applications limits the amount of patient information available to each application. id certain circumstances, it is desirable for The system user to access information not available in the patient record for a currently open application. In this case, another application must be opened to access such information. For example, a physician accessing a medical condition/history application may desire to access information regarding a patiert's insurance to determine whether specific tests are covered by the insurance. To do this, the physician must open the accounting (or risk managements application to view the patient's i = ce information.

In an effort to solve some of these problems, attempts have been made to allow applications to access the patient data records available in other applications by interfacing the patient data records from some applications with other applications.

Configunug the patient data records of one application to be accessed by other applications is expensive, requiring substantial cost for providing and maintaining the interface of patient data records with various applications, and increasing processing demands on the system. Further, such configuring of the patient data records is especially difficult where the patient data record for one application is in a different fonnat than the patient data records for other applications. Id addition, where Lnterfacing of the patient data records is finally achieved, use of the applications is significantly slowed while patient information from the patient data records are converted between formats.

Furler, attempts have been made to allow multiple different user

- -

software applications to access a single data repository including limited data for patients, however the multiple user interfaces are disparate in operation and appearance as discussed above. Facilities unpIementin such disparate interfaces must expend significant time and effort to train users for each of the confusing variety of applications with unrelated user interfaces. In addition, such systems typically limit users' ability to move freely within one application requiting, for example, that users complete a specified task before moving on to another. Further, these systems typically require that two individual programs run simultaneously on one machine when switching between applications.

Such systems also require complicated deployment of multiple user interfaces and/or data repositories to different system users and access terminals throughout the health care facility. As mentioned. health care enterprises utilizing such systems risk non-compliance with health care regulations and best practice guidelines, due to the inflexibility of the multiple interfaced applications with different system user security records and alerts systems. Additionally, the health care enterprises incur unnecessary administrative overhead created by the poor communication capabilities between the multiple interfaced applications, for example, poor or non-existent clinical decision support, or billing applications that contradict diagnostic decisions already filed in the enterprise's medical records application.

The present invention is directed to overcoming one or more of the problems discussed above.

Brief Description of the Drawings

Figure 1 is a graphic representation of a universal patient record in connection with a user interface and master files and a central data repository in accordance with an embodiment of the invention; Figure 2 is a graphic representation of a universal patient record in accordance with an embodiment of the invention; Figure 3 is a graphic representation of master files linked with the universal patient record of Figure 2 in accordance with an embodiment of the invention; ! Figure 4 is a workElow diagram illustrating the functionality of the universal patient record of Figure 2 in accordance with an embodiment of the invention; Figure 5 illustrates the universal patient record at Figure 2 with associated master files of Figure 3 as used in a suite of software ire accordance with an embodanent of the invention; Figure 6 is a vorl;flow diagram illustrating a data communication process for the Universal patient record of Figure 2 in accordance with an embodiment of the invention; Figure 7 illustrates a detailed view of the suite of software illustrated in Figure 5 for providing patient registration functionality, Figure 8 illustrates a detailed view of the suite of software illustrated in Figure 5 for providing enterprise master person index functionality, Figure 9 illustrates a detailed view of the suite of software of Figure 5 for providing inpatient admission, discharge and transfer functionality, Figure 10 illustrates a detailed view of the suite of software of Figure 5 for providing patient accounting functionality, Figure I 1 illustrates a detailed view of the suite of software of Figure 5 for providing risl; management functionality, Figure 12 illustrates a detailed view of the suite of software of Figure 5 for providing inpatient clinical system functionality, Figure 13 illustrates a detailed view of the suite of software of Figure 5 for providing web-based patient record functionality; Figure 14 illustrates a detailed view of the suite of software of Figure 5 for providin, ambulatory electronic medical record functionality; Figure 15 illustrates a detailed view of the suite of software of Figure 5 for providing nurse triage/nurse call center functionality; Figure 16 illustrates a detailed view of the suite of software of Figure 5 for providing enterprise scheduling functionality; Figure 17 illustrates a detailed view of the suite of software of Figure 5 for providing operating TOOm management functionality, - 6 Fi,Eure 18 illustrates a graphical representation depicting Me universal patient record inteahna functionality at a data level accordance with an embodiment of We invention; Figure 19 is a Ethical representation illusag interaction between a health care informs don system database repository and a health care information system graphical user intermce according to an embodiment ofthe invention; Figure 20 is a flowing illusatmg interaction between the data repository and the Ooraphical user interface configuration of Figure 19 in accordance with an embodiment of the invention; Figure 21 is a flow chart illustrating the steps for allowing a user to switch between activities within a workspace in accordance with an embodiment of the invention; ! Figure is a graphic representation of multiple workspaces and multiple activities in accordance with an embodiment ofthe invention; Figure 3 is a flow chart of a sample work flow for a nurse call/nurse triage environment in accordance with an embodiment of the invention; Figures 24 and 25 together illustrate functionality of the graphical user interface for providing Medicare Secondary Payor compliance in accordance with embodiments of the invention, and Figures 26 and 27 together illustrate functionality of the user interface for providing Health Core Financing Administrations Correct Coding Initiative by Local Medical Review Policy checking in accordance with embodiments of the invention.

Detailed Description of the Preferred Embodiment

In accordance with one aspect of the invention, a patient-centered integrated health care record (universal patient record (UPR)) is provided including information related to health care delivery for a patient, and information related to health care delivery management for the patient. Multiple UPRs may be provided, where each UPR includes information related to heals care delivery and management l - 7 of health care delivery for a particular parent. The UPR(s) is used with a health care system to facilitate management of and to provide health care for patients. The infonnation of the UPR may be stored as formatted data, links to formatted data, or as selections from a list, further discussed below. System users have access to the UPR through one or more user interfaces in communication with the UPR Having the UPR which includes information for both health care delivery arid health care delivery management for a patient provides a common source of data for a particular patient, on which a health care system may rely, without the need to interface multiple databases. Therefore, complicated, time consigning and expensive configuration and data format conversion issues are avoided. Further, the I3PRs common source of information facilitates integration of multiple software applications as a single software application, and reduces, if not eliminates, data duplication, thereby reducing storage space required for the UPR as compared with the multiple prior art patient records maintained for a patient. Further the reduced data duplication translates to lower operating costs associated with the entry of duplicated data by office personnel.

The UPR also facilitates compliance with legislative enactments, for example the Health Insurance Portability and Accountability Act (HERA). The llPR expedites authentication of data in a patient record as all data for a patient is made available. Reduced data duplication lowers the chances for conflicting data within the UPR, and the difficulty associated with determining which of the conflicting data is accurate. Additionally, using the UPR reduces the chances of multiple data records being created for a patient, where the same patient is identified with more than one patient record. one embodiment, where audit functionality is provided, compliance with HEPAA is expedited. Because substantially all data corresponding to a patient is stored in the VPR, an audit record/trail for accesses and changes to data in the UPR may easily be provided. another embodiment, security functionality is provided, where the UPR includes security information defining system user access. Because of the single source of security information, the chance for duplicated and potentially conflictinglerroneous security access is reduced. In another embodiment, a loci; manager operates at a level between the UPR and the software functionality provided by the health care system, where the lock manager controls system user write access to the UPR. Because the lock manager operates at a level between the UPR and the software functionality, and not at the database level, assigning portions of the patient record to be access-locked and access-locking the portions of the patient record occurs more efficiently than in systems locking data at the database levy.

In accordance with another aspect ofthe invention, an electronic Health Care Information System (HCIS) is prodded including a modular framework and a display in communication with the modular framework for providing a graphical user interface to a system user. The modular framework includes a plurality of software functionality (activities), where each activity provides an aspect of patient care. Activities for providing aspects of patient care include, but are not limited to, activities used in the providing of health care to a patient (for example, which provide a care provider with patient medical information such as a patient history activity and a chart review activity, etc.) and activities used in the management of health care for a patient (for example, registration, patient demographics, etc activities). The graphical user interface is adaptable for displaying information corresponding to one or more of the activities, and includes a common menu format for communicating available operations in the graphical user interface, and common visual components for displaying information to a system user.

The modular framework allows additional activities to be added to the system without the difficulties associated with interfacing and configuring He activities to work with the HCIS and with each other. Further, the ease of integrating applications due to the modular fiamework results in a high rate of compliance with.

govGluent regulations. The common menu structures and common visual components provided by the graphical user interface provide system users with a consistent interface for the HCIS, reducing the training requirements of system users who might otherwise be cross trained on multiple user interfaces. Additionally, the graphical user interface and modular framework allows system users to freely switch between activities available within the HCIS, even before completing a particular activity. The system users are therefore not forced into finishing a particular activity before gaining access to another activity, allowing for example, emergency situations l - 9 - to be addressed immediately without loss of information or worl; flow in an interrupted activity. Further, the graphical user interface and modular framework facilitates the combining of heterogenous, but related, activities within particular In further embodiments, the healthcare information system includes a single information database, such as the I3PR discussed above, for use by the activities, reducing if not eliminating data duplication between activities, and the difficulties with interfacing multiple databases having varying structure or format.

Additionally, the singe infonnation database allows a common security record to be kept for system users, facilitating uniformity of security access for system users across all activities of the HE IS, ease of selling security requirements for new system users, and reduced probability of granting mistaken security privileges as security infonnation for all activities need be entered but once. Further, the single information database and modular framework allows an alert system to be provided to warn system users where information entered in an activity conflicts with other information for a particular patient in the information database. Additionally, system users are provided the ability to configure the graphical user interface, giving the flexibility of tailoring the graphical user interface to offer functionality and information to better serve their specific needs. In addition, a worl; flow management tool is provided as an Electronic Messaging and Workflow System, further discussed below.

Figure 1 illustrates the relation of a 1JPR 100 in communication win a central data repository 102 and a system user interface 104. The IJPR 100, the central data repository 102, and the system user interface 104 work together to form a health care system, where He I 1PR 100 and the central data repository 102 reside on one or more storage media, for example, hard disk drives, computer diskettes, compact discs, magnetic tape, or any other storage media as would be appreciated by one skilled in the art. The UPR 100 is typically a part of the central data repository 102, and maintains substantially all patient-related data for a patient, including information related to health care delivery, and health care delivery management. The information is maintained as at least one of formatted text/data, links to formatted data, and selection(s) from a list. The IRE 100 may contain all patient-related data, or in a - >; - 10 preferred embodiment, may include patient-specific data with non-patiert-specific data residing elsewhere on Me central data repository 109. The system user interface 104 may be a personal computer with corresponding display device, a handheld computing device, or any other interface capable of providing the system user access to the health care systerm Typically, the health care system will include multiple UPRs, where each UPR includes health cafe and health care delivery management infonnation for a corresponding patient. The one or more UPRs 100, the central data repository 102, and the system user interface 104 maybe in cormnurucation via data bus lines, telephone lines, optical fiber transmission lines, wireless communication (preferably secured wireless communication), or in any other fashion as would be appreciated by one skilled in the art. Further, the storage media on which the DPR andlor the central data repository 109 reside may include a single storage media, or several individual storage media in conununication with one another, while still achiennug the advantages of the invention.

A system user is presented with a range of functionality in the user interface 104. Some of the functionality presented to the system user relates to the delivery of health care to a patient, and other of the functionality is related to health care delivery management for the patient. The UPR 100 and central data repository 102 offer a common source of data for providing the functionality to the system user.

The data structure of the I3PR 100 is shown in Figure 2 in accordance with an embodiment of the invention.

The UPR 100 includes information regarding health care delivery, and information regarding health care deliverynanagement for a particular patient. The information in the UPR 100 may include patient demographic information 110, security infonnation 112, status information 114, patient accounting information 116, risk management information 11S, medical records 120, scheduling information 122, and hospital stTucre information 194. Information regarding health care delivery may include medical records 120. Information regarding health care delivery management may include patient demographic information 110, security infonnation 112, status information 114, patient accounting information 116, risk management information I 18, scheduling information 122 and hospital structure information 124. in,;

As discussed above, the UPR may be one of many I3PRs within a health care system.

where each UPR maintains demographic, security, status, accounting, risk management medical record, scheduling and hospital structure information for corresponding patients. As also discussed above, the data stored in each UPR may be formatted text/flata, links to formatted text/data, or selections from a list of available data, and will be filer discussed below.

The demographic information 110 includes information such as pahent address, patient employer, and patient emergency and religious contacts. The security information 112 includes information including service areas, primary care physician and restricted status flags, where the status flags may be used to control among other things, the types of information made available to sofvare functionality associated with the health care system by linking information to the patient record depending on the context accessing the patient record. The status information 114 includes information such as inpatient and ambulatory flags, registration status, and past inpatient identifications. The patient accounting information includes information such as charges, payments, computations, guarantors, claims and links to accounts.

Patient coverages, payor and other billing information, plan, referral information and risk management contracts are included in the risk management information 1 18. I he medical records 120 includes information related to inpatient and ambulatory encounters, medications, allergies, immunizations, medical and surgical history, family and social risk factors, test results, care giver log and documentation, orders, care plans, and a current and historical problem list. The scheduling information 12? includes information related to appointment times, dates, locations, providers, types of appointments, reasons for visiting, scheduling notes, and arrival status for past and future appointments in both inpatient and outpatient facilities. The hospital structure information 124 includes information related to the hospital Unit, room number and bed number for the patient as well as services and treatment teams. The UPR includes associated files, for example, master fifes 130 maintained in the central date repository 107. The master files 130 are shown in Figure 3.

The master files 130 include demographics master files 139 which include non-patient-specific information on demographics topics, security master files - 19 134 which include non-patient-specific information on security topics, and patient accounting master files 136 which include non-patientspecific information on accounting topics. The master files 130 further include risk management master files 138 which include non-patient-specific infonnation on risk management topics, medical record master files 140 which include non-patient- specific intonation on medical record topics, scheduling master files 142 which include non-patient-specific information on scheduling topics, and hospital structure master files 144 which include nor-patient-specific information on hospital structure. The one or more I3PRs of the health care system include links to records/files in corresponding master files 13Q allowing patient-specific infonnation to be stored in a manner that supports integrated features.

One example of a link to a corresponding master file would be for insurance company payer address in risk management information 118. The risk management master files 138 may include, among other information, a list of insurance cornpanypayors having corresponding addresses, where the risi; management information 118 for orate or more UPRs 100 includes a link to a particular selection from the list of insurance company payers of the risk mngemert master files 138. Where the address for that particular insurance company payer changes, the new address need only be entered in the risk management master files 133 through an administrative functionality (discussed below), and not in each {3PR affected by the address change, as the link from the UPR(s) to the risk management master files will ensure that the most current address information is available for the patient records.

Having the UPR 100 win associated master files 130 provides a common source of data for which a health care system may rely, without the need to interface to/with multiple databases, thereby avoiding complicated, time consuming and expensive configuration and data format conversion issues. Further, the UPR's common source of information facilitates integration of multiple software applications as a single software application, as discussed below, and reduces if not eliminates data duplication, thereby reducing storage space required for the IJPR, as compared with the multiple patient records and corresponding data duplication of the prior art.

Further Me reduced data duplication translates to lower operating costs associated - 13 wi the entry of duplicated data by of lice personnel. Compliance with the EPAA is facilitated as well, as the UPR's common data source provides reliable authentication of data in a patient record as substantially all data for a patient is made available.

Reduced data duplication lowers the chances for conflicting data within the UPR, and the difficuIty associated with determining which conflicting data is accurate.

Additionally, creation of multiple patient records for a particularpatient, where the same patient is identified with more than one patient record, is reduced" Figure 4 illustrates a general workilow in software functionality based on the VPR 100 in accordance with an embodunent of the invention. As shown in box 150, a system user logs into an application using the user interface 104. The system user sdects a given software functionality which may be a patient-specific end-user functionality, or a type of administrative functionality, box 152. Where administrative functionality is selected, access is provided to the system user for non patient-specific information, box 154. Such non- patient-specific information is 1: provided in the associated master files 130 of the central data repository 109.

Administrative workilows provide for accessing, viewing, entering, editing or other manipulation of non-patient-specific data stored in the demographics, secunty, patient accounting, risk management, medical records, and scheduling master files 13, 134, 136, 13S, 140 and 149, respectively, step 156. As shown in box 158, generic data is displayed, where the UPR is not directly affected. For example, patient accounting master files 136 may be altered to change a claims submission address for a particular Insurance agency, as discussed above. One or more UPRs may include a link to this particular insurance provider, however, the address to the insurance provider may be updated without directly affecting and accessing each affected UPR. Updating non patient-specific information in this manner necessitates changing the data only once, not several times for each affected patient record. Once all manipulations or other necessary accesses to the non-patient-specific information are completed, the system user logs out from the administrative application as shown in box 160.

Where the system user selects patient-specific user fimctionality in box 152, the patient-specific infonnation is accessed using the UPR 100, as shown in box 162. When accessing the patient-specific information using the UPR, the UPR / / - 14 includes both formatted data for the particular patient, selections from lists, and links to generic infonnation from associated master files. For example, medical history for a particular patient may be stored as formatted data in the UPR, wherein insurance billing information for a particular patient may be stored in the UPR as a linl; to that patient's instance company information residing as generic information within associated master files, boxes 164, 166. Thus, changes to the associated master files are automatically accounted for in a particular UPR 100. The patient data is displayed, and patient-specific processes are perfonned, box 168, and when all desired access to this patient-specific information is complete, the system user logs out from the patient-specific user application, box 170. Figure 5 illustrates a suite of software functionality relying on the UPR 100 for data level integration, in accordance with an embodiment of the invention.

Figure 5 graphically illustrates the interaction between software functionality, generally shown at 200, and the 1JPR 100 and associated master files 130. Elements of Figure 5 having the same renounce numerals as elements of figures 1-3 discussed above are the same and will not be discussed in detail. Each element of software functionality 200 accesses one or more portions of the llPR 100 where information in the 11PR may be stored as fonnatted data, links to supporting data, for example, from corresponding master files 130, or as selections from a list, the list stored in either the UPR 100, associated master files 130, or any other data source (not shown, but may include, for example, an interface to a third party database) in communication with the UPR 100. Figure 5 illustrates the role of the UPR 100 in terms of functionality, looking at which sections of the UPR 100 are used by each software functionality, and analyzes the UPR by data range, and by which applications are served by which set(s) of data. For the purpose of simplicity, Figure 5 focuses on software functionality which provides patient-specific information, and does not include the software functionality for providing non-patient-specific functionality such as administrative actions on the non-patient-specific information.

The software functionality 200 is typically provided via the user interface 104, and may include registration 209, an enterprise master person index (EMPI) 204, admission, discharge and transfer 206, patient accounting 20S, and risk - 15 management 210. The software fimctionality 200 may fiercer include inpatient clinical systems 210, web-based padent record 914, ambulatory (electronic medical record) ED 216, nurse mage/nurse call center HIS, scheduling 220, and operating room (OR) management 222. The software fmotiona]ity 200 may be interfaced with Me UPR}00 via the access manager 240. Before discussing the role of the UPR 100 in terms of fimctionality and in teas of data range, a discussion of the access manager 240 is provided.

The access manager _40 controls venous aspects of access between the software fimctionality 200 and the UPR 100. The access mmager 240 typically includes a security system manager (not shown) for controlling system user access with the UPR 100, and a lock manager (not shown) for controlling system user's capabilities for wring to the UPR 100. The access manager exists at a level between the UPR 100 and the software functionality 200, and not at the data level ofthe VPR 100. +

-

The lock manager includes a plurality of write tokens, where each write token controls write access to a particular portion of the I3PR. Only one wnte token exists for writing to a particular portion(s) of a UPR The existence of only one write token prevents multiple system users from simultaneously writing to the same portion of the particular UPR, thereby preventing corruption of that patient record.

The portion of a patient record controlled by a particular write tolcen may be set by health care system administrators, where the wnte token may control wnte access for the entire VPR, or Just a portion of the 17PR Where the wnte tolled controls wnte access to just a portion of the UPR, additional write tokens may be provided to provide write access control for the remainder of the patient record.

Where a system user makes a wnte request to wnte information to a portion of the UPR 100 for a particular patient, the lock manager of the access manager 240 determines whether or not the write token corresponding to that portion of the UPR for the patient is available. Where the write token is available, the write token is transferred to the requesting system user, and We system user is enabled to wnte information to the corresponding portion of We UPR 100. However, where the write token is possessed by another system user, the lock manager generates and f - 16 delivers a write token information message to the requesting system user, indicating the another system user in possession of the requested write token, an identification of the user interface for the another system user, and the tune that the write token was transferred. Using write tokens m this fashion prevents multiple system users from simultaneously writing data to a particular UPR or UPR portion, thereby protecting the integrity of the patient record.

The security manager utilizes secuntyinfrmation to control access to the 11PR 100. For example, the central data repository 102 may further include an employee security data base defining the security access of venous employees of the health care enterprise. The employee security data base is then used to control access of the employees to the functionalities and patient records of the health care system.

Security information portion 119, which includes patient-specific security information, may further be used to limit a health care employee's access to patient records. For example, the security information portion 112 may restrict a particular employee's access to that universal patient record, may restrict access of employees based on the physical location where the patient is located (i.e., employees at a satellite clinic may not have access to patient records for patients at the main clinic), and an employee's access may be limited in other ways as would be understood by one skilled in the art.

From a functionality perspective, registration functionality 202 and admission, discharge and transfer fimctionality 206 allow users to view and enter/edit demographic information 110, set status information 114, and enter hospital structure information 124 in the 1JPR The EMPI 204 uses this information to perform duplicate checking, for example, duplicate patient records, and other fimctions. The patient accounting function 208 provides entry of patient account information into the llPR, and uses medical record information 120 and hospital structure information 194 to generate new charges, patient statements, insurance claims and risk management information 118 to calculate and route the new charges. Risk management finchors 210 supply and manipulate patient accounting information 116 and risk management information 118 in the UPR. Inpatient clinical system 212 (including for example, inpatient EMR and inpatient scheduling information.) uses hospital structure - 1; information 124, and both the Patient clinical system 212 and the ambulatory EMR 216 allow eddy and manipulation of medical record information 120 and reception of scbedulinginfiormation 122 for display. Furler, the inpatient clinical systems 212 and ambulatory EMR 216 utilize risk management information 118 for decision support features. The webased patient record 214 allows system users to view and edit certain medical record information 120 and scheduling infonnation 122 Mom the IJPR. The nurse triage/nurse call center fimctionality218 allows both viewing and editing of medical records infonnation 120 and scheduling information 122 from the UPR 100. Scheduling functionality220 allows reception of orders and other medical information 120 and hospital structure information 124 Mom the llPR, and provides entry of scheduling intonation 122. Furler, scheduling functionality 220 draws on risk management information 118 and allows the entry of patient accounting information 116 and the display of registration information (for example, demographic information 110) far the patient.

-

From the perspective of which applications are served by. which sets of data, demographic information 110 may be entered from any functionality including, for example, the registration 202 and admission 206 functionalities. The demographic information 110 is used and may be manipulated by the EMPI 204, and is also available to other functionality, as a means of identifying the patient to system users, for example, allowing any functionality requLring information regarding a patient's age, race, or gender, to retrieve the demographics information 110 from the UPR 100.

The security information 112 in the 11PR is created largely through internal processes, and is generally available to functionality performing security checks in determining a system user's access privileges to a particular UPR The status information 114 is typically set using the registration 202 and admission 206 functionality. The E19[PI 204 uses temporary identifications stored in a UPR and adds its own IDs to the UPR Patient accounting information 116 is entered and edited primarily from the patient accountin;, functionality 208, and also from the risk management functionality 210 and scheduling functionality 220 (used, for example, in the collection of co payments). The risk management information 118 is entered and edited through the risk management functionality 210 as well, and is used for decision support in the // - 18 inpatient clinical systems 212 and ambulatory EMR 216, and for calculating charges in and routing claims to patient accosting functionality 208. The medical record information 120 is entered and edited primarily through the inpatient clinical systems 212 and ambulatory EA<tR 216, and also hom the webased patient record 214 and the nurse triage/nurse call center functionality 713. The medical record information is utilized by patient accosting 208 to generate new clanns and by scheduling fimctiorality 220 to identify unscheduled orders for the 11PR The scheduling information 122 is entered and edited primarily through the scheduling fimctionality 220 and also through the webased patient record fimctionality 214 and nurse triageinurse call centerfimctianality218. The scheduling information 1Z is additionally made available in the inpatient clinical system 212 and ambulatory ED 216 functioDalities. Ibe hospital structure information 124 is used, entered and edited by the admission, discharge and transfer functionality 206, and furler used by patient accounting 208, inpatient clinical systems 12 and scheduling 220. Audit controls 230 in cormnunication with the llPR 100 are provided for recording all contact with the UPR 100. Any contact with the UPR 100 is recorded in an audit trail within Me audit controls 230, where the system user, information accessed, and actions performed on the data are recorded. Such actions may include viewing, editing, and creation of new data, or other manipulations to or use of data in the 11PR 100.

The relationship between the I3PR 100 and master files 130 is also shown in Figure 5 in accordance with an embodiment of the invention. It is shown that the demographic information 110 of the UPR 100 is supported by demographics master files 132, security information 112 is supported via the security master files 134, and the patient accounting information 1 16 is supported by the patient accounting master fifes 136. The risk management information 118 is supported by the risk management master files 138, the medical records 120 are supported by medical record master files 140, scheduling information 192 is supported by the scheduling master files 142, and hospital structure information 124 is supported by hospital structure master files 144. General and specific fimctionalityntilizing the UPR 100 are discussed below with reference to Figures 6-17.

Figure 6 illustrates a general process of system user inputloutput in (A 19 relation to a UPR 100 ire accordance with an embodiment of the invention, showing in greater detail processes involved in communicating data to and Tom the CUR 100. A system user logs into the health care system, using for example the user interface 104, as shown in box 300. The system user selects which feature/fimctionality is desired, box 302. For purposes of simplification, administrative functionality is not included m this diagram, and the selected feature box 302 is assumed to relate to some aspect of patient care, for example, software finctionalities 900 discussed with respect to Figure 5. Because substantially all patient-specific information is accessed through the UPR, a first step of selecting the feature in box 302 is to select a particular UPR for a patient. Before the patient record is made available to the system user, the health care system perfonns a basic security check, box 304, which filters out certain patients based on their location or relationship to the system user (for example, based on their senice area, or physical location such as being located different states). The UPR may include security information in the security information portion 112 deeming 15 security clearance for system users accessing the PER, where a security Tnanager (not

-

shown) of the access manager 940 controls system user access based on e security information. In box 306, a patient is selected using for example a standard patient look-up module, based on functionality from the EMPI fimctionality 204, box 308.

The EMPI functionality 204 provides an index for UPRs maintained in 00 the health care system, where the UPRs may be indexed by, for example, a patient identification. The EMPI functionality 204 is also capable of tracking patient activity across multiple physical locations or internal organization divisions. The standard patient look-up module may comprise programming within the EMPI functionality 204, where use of the standard look-up module in conjunction with the EMPI functionality 904 ensures availability of Virtually all patient information to the system user.

Before the patient information is displayed, further security checks are performed by the security manager using the security information of the UPR 100, box 310. Depending on the particular fimctionality being used, certain patients or information for certain patients may be unavailable for access by the system user.

Where the system user has sufficient security clearance for viewing the information - 20 for a particular patient, the system user is provided access to Me I3PR for Rat patient.

The contact with the VPR is recorded in the audit control '3a, step 312. Where the user does not have sufficient security clearance for viewing the particular patient record in box 310, the health care system may provide for emergency access to a patient's record as shown in box 314. In this circumstance, the system user's access generates an automatic message to the system user's supervisor when accessing patient information, box 316. Alternatively, a supervisor's access code maybe required to access the UPR for the patient. The emergency access is then recorded in the audit control 230, as shown in box 312. As shown in box 318, infonnation fiom the 1JPR for the particular patient is viewed. 1h this embodiment, the information in the UPR may be linlced to a file or record ire an associated master file 130, box 320, the information may be stored as a selection from a category list in the UPR 100 or master files 130, box 322, or the infonnation may be stored directly in the UPR for the patient as formatted data or free text, box 324. For exernple, where the scheduling functionality 220 is being used, the required resources for scheduling an appointment are selected from an associated master file, for example the scheduling master file 142, where the type of appointment is selected from a category list stored within the scheduling master file 142. The time of the appointment may be entered directly into the I3PR 100 for the patient using the scheduling functionality 290, and stored as part of the scheduling information 1 92 in the 1JPR 1 00.

After the patient-specific information has been gathered through Me UPR, it is displayed for the system user, box 326, utilizing for example a display (not shown) of the user interface 104. Where the user desires to edit patient information, box 328, a security check is performed by the security manager of the access manager 240 to determine if the system user has security clearance to enter the information, box 330. This may be determined utilizing security information stored for the particular system user within the UPR 100, as discussed above. Where the system user does not have proper security clearance to edit information in the UPR for the patient, the system user is limited to viewing information displayed, box 326.

However, where the system user does have security clearance to edit information in the UPR in box 33D, the access manager 940 (Figure 5) determines / - whether a write token is available, box 339. Where a wnte token for the particular portion of the UPR is not available, a write token information message is displayed to the system user including which system user is in possession of the write token, the particular user interface being used by the system user in possession ofthe Ante token, and the time that the write token was assigned, box 334. The system may continue to display patient-specific information as shown in box 326. Where the write token is available for the system user in box 332, the write token is assigned to the system user, box 338. The assignment of the write token to the system user is recorded in the audit control 230, as shown in box 340, and the system user is enabled to write to a portion of the 1JPR 100 corresponding to that particular write token, box 342. The system user may edit the patient record by adding or removing references Tom the patient record to records in associated master files, box 344, by adding or editing selections from a category list, box 346, or by entering/editing formatted data or free text within the IJPR 100, box 34S. Any changes to the VPR for the patient are continually recorded in the audit trail for that system user and for the llPR, by the audit controls 230. In an alternate embodunent, the assignment of the write token is not recorded by the audit control 230, but rather just changes to the 1JPR 100 by the system user are recorded.

Typically, the system user editing the patient information is not able to alter the infonnation in the associated master files or category lists through the VPR, but rather is only able to alter the links to the master files. Altering and editing the associated master files is allowed within administrative fimctionality, discussed above. Once changes are made to the patient record, the changes are updated on the system user's display, and also updated for other system users viewing the I}PR for the patient, as shown in box 336. The displays may be updated as each piece of information is alteredledited. Altematively, any displays connected to the health care system may be updated at predetermined intervals of time, or on demand by the system user, as would be appreciated by one skilled in the art.

Ike lock manager of the access manager 940, operating at a level between the IJPR and the software functionality, allows write tokens to be defined for portions of the patient record and allows write tokens to be assigned to system users I.--\ 1

- -

more efficiently than in systems locking data at the database level. The audit functionality provided by Audit controls 930 facilitates compliance with the BAA.

Because substantially all patient data is stored in the UPS, an audit record /trail for accesses and changes to data in the UPR may easily be provided. Further, the security manager of the access manager 240 reduces the chance for duplicated and potentially carflicteToneous security access, because the DPR provides a single source of security information for system users, furler expediting compliance with the H1PAA.

Figure 7 illustrates a detailed view of the patient registration functionality 902 of Figure including the portions of the I3PR 100 and associated master files 130 which maybe used to support the registration functionality 202 in accordance with an enbodunent of the invention. The registration functionality 902 is provided to a system user via a registration user interface 350 which may be part of the system user interface 104. The registration functionality 202 offers a range of data entry options for adding to the 11PR for the patient. New patients may be added into the health care system, demographic infonnation may be collected and stored via the demographic infonnation portion 110 and corresponding demographic master files 132, and various status information maybe set in the status information portion 114.

Further, patient accounting and risk management information may be set In the patient accountin,, information portions 116 and corresponding accounting, master files 136, and in the risk management information portion 118 and corresponding risk management master files 138. The status information 114 is Epically stored as patient-specific data in the I]PR, where the other infonnation entered into the patient record is typically supported by the associated master files, for example as data links to the master files, or as selections from lists residing within the master files.

o5 Figure 8 illustrates a detailed view of the EMPI functionality 204 in accordance with an embodiment of the invention. The EMPI functionality 204 is provided via an EMPI user interface 360 which may be part of the system user interface} 04. The EMPI fiuctionality 904 identifies patients and perfonrs duplicate checking based on a range of demographic information. For example, upon entry of a patient name andfor address, the EhIPI finctianality 204 may search through other UPRs within the health care system for other patients havin;, identical names andfor al addresses. VPRs for other patients having, for example, the same name andior address are displayed, and may be selected by the system user. this way, creation of duplicate I3PRs within the health care system may be avoided. Further, status information such as a previously used patient identification for a particular patient may be used to locate a complete set of information for the particular patient While Me status items for the patient are topically stored in the UPR, associated master files such as the demographics canter files 132 typically support the demographic infonnation 110 entered in the patient record. Other data may be used by the EAdPI fimctionality 204 including a patient's age, sex, social security information, e-mail address, alias, etc. Figure 9 illustrates a detailed view of inpatient admission, discharge and transfer functionality 206 in accordance with an embodiment of the invention.

The admission, discharge and transfer functionality 2Q6 is provided to a system user via an admission, discharge and transfer user interface 370, which may be part of the system user interface 104. The admission, discharge and transfer functionality provides options to add IlPRs for particular patients. Additionally, the admission, discharge and transfer functionality may be used to assign patients to a specific hospital unit, room and bed, collect demographics informaffon, and set various status items, for example whether a patient is being seen in an inpatient or ambulatory context. System users may also enter accounting and risk management infonnation for the patient. The status items are stored in the status information portion 114 of the UPR, whereas the other information entered into the patient record is typically stored in the demographic information portion 110 and supporting demographics master files 132, patient accounting information portion 1 16 and corresponding supporting patient accounting master files 136, risk management information portion 118 and supporting corresponding risk management master files 138, and hospital structure information 124 and corresponding master files 144.

Figure 10 illustrates a detailed view of the patient accounting functionality 208 in accordance with an embodiment of the invention. The patient accounting functionality 208 is provided to a system user via a patient accounting user interface 380, which may be incorporated in the system user interface 104. The / patient accounting functionality offers a variety of patient-specific accounting options, based on information in the FIR 100 for a patient. The patient accounting functionality 208 allows managing patient accounts, and allows for perfonring a range of charge entry and computations based on medical records information 120, and hospital structure information 124. The accounting functionality 208 utilizes nsl; management information 118 in routing the charges, for example to insurance companies. The information entered into the patient record through the accounting functionality is typically stored m patient accounting information portion 116 supported by patient accounting master files 136, risk management information portion 118 supported by risk management master files 138, medical records information portion 120 supported by medical records master files 140, hospital structure information 124 supported by hospital structure master files 144, and demographic information 110 supported by demographic master files 132.

Figure 11 illustrates a detailed view of the risk management functionality 210 in accordance with an embodiment ofthe invention. The nslc management functionality 210 is provided to a system user via a rislc management user interface 390, which may be part ofthe system user interface 104. The risk management functionality 210 provides a range of infonnation and entryoptions to create managed care coverage policies and assign patients to them. Ice addition to entering coverage information, system users may coordinate the system's interaction with patient accounting functionality. The risk management information and corresponding features are typically supported by the patient accounting information portion 116 with supporting patient accounting master files 136, risk management information portion 1 I S and corresponding risk management master files 138, and medical records information portion 120 and corresponding medical records master files 140.

Figure 12 illustrates a detailed view of an inpatient clinical system functionality 212 irt accordance with an embodiment of the invention. The inpatient EM fimctionality 21 ? is provided to a system user via an inpatient clinical system user interface 400 which may be part of the system user interface 104. Through the inpatient clinical system functionality 212, a range of information and entry options are provided to record medical information based on interactions with patients, for e:; ampIe in an inpatient context. Additionally, the inpatient clinical system functionality 212 provides scheduling and hospital census information to health care providers, and draws on and allows updating of hospital structure information 1?4 (supported by hospital structure master files 144). The inpatient clinical system fimctionality also features decision support based on medical records portion 120 with corresponding medical record master files 140, risk management portion 118 with supporting risk management Toaster files 138, and demographic information portion with corresponding demographic master files 132. Other information portions, for example, status information portions 114 provide further information to the system user via the inpatient clinical systems user interface 400.

Figure d3 illustrates a detailed view of the webased patient record functionality 214 in accordance with an embodiment of the invention. The web-based parent record functionality 214 is provided to a system user via a web-based 1JPR user interface 410 which may be integrated within the system user interface 104. The webased patient record functionality 214 provides a system user Internet access to the VPR 100, granting system users a range of information entry options to record medical information based on encounters with patients. Additionally, medical information entry, scheduling information, and decision support based on medical, demographic and risk management infommation from the UPR 100 is provided to system users via the Attempt. The infomnation for the web- based patient record functionality 214 is typically provided via the medical records portion 120 and corresponding supporting medical record master files 140, scheduling information portion 122 with supporting scheduling master files 142, demographics infonnation portion 110 with supporting demographics master files 132, and risk management information portion 11 S with corresponding supporting risk management master files I3S. Further, not shown, the Web-based patient record functionality 214 may provide hospital structure infonnation (e.g., hospital unit, room number and bed number) for a patient, where the hospital structure information 124 is supported by hospital structure master fifes 144.

Figure 14 illustrates a detailed view of the ambulator EM fimctionality 216 in accordance with an embodiment of the invention. The ambulatory EMR fimciionality 216 is provided to a system user via an ambulatory 3EMR user interface 420, which may be integrated within the system user interface 104. The ambulatory EMR functionality 216 provides information entry options to record medical information based on encounters with the patients, for example, in an emergency room context. Additionally, an ambulatory FIR functionality 216 provides scheduling information to providers, and features decision support based on medical, demographic, and risk management information. The ambulatory Em.

functionality 216 is typically supported via demographic infonnation portion 110 with corresponding demographic master files 132, status information portion 114, risl- management information portion 118 with corresponding risk management master files 138, medical records portion 120 with corresponding medical record master files 140, and scheduling information portion 122 with corresponding scheduling master files 142.

Figure IS illustrates a detailed view of the nurse triage/nurse call center finctionality218 in accordance with an embodiment ofthe invention. The nurse 0a,e/nurse call center functionality 218 is provided to a system user via a nurse iage/nurse call center user interface 430, which may be part of the system user interface 104. The nurse tnage/nurse call center functionality 218 offers a range of options to view existing medical information and log new medical information dunug telephone encounters with patients. Additionally, the call center functionality 218 may provide customer relationship management (i.e., customer service). Further, system users may view a patient's scheduled appointments and reschedule or create new appointments as needed. The nurse triaa,etnurse call center funchonality218 is typically supported by medical records portion 190 and corresponding medical record master files 140, and scheduling information portion 19 with corresponding scheduling master fifes 142.

Fissure 16 illustrates a detailed view of the enterprise scheduling functionality 290 in accordance Title an embodiment of tle invention. The enterprise scheduling functionality 200 is provided to a system user via a scheduling user interface 440, Which may be part of the system user interface 104. Me enterprise - 97 scheduling functionality 220 provides s, vstern users options to create and modify appointments for patients. Further, providers may place orders for tests and procedures, which are scheduled, based on medical information in the UPR 100. The enterprise scheduling functionality 220 is typically supported by the medical records information portion 120 and corresponding medical record master files 140, scheduling information portion 122 with corresponding scheduling master files 1, status information 114, patient accounting information 116 and corresponding patient accounting master files 136, and risk management information 118 and corresponding risk management master files 13S.

Figure 17 illustrates a detailed view of the OR management functionality 222 in accordance with an embodiment ofthe invention. The OR management functionality 222 is prodded to a system user via an OR management user interface 450, which may be part of the system user interface 104. The OR management functionality 222 provides system users the ability to record progress of and enter notes for OR procedures, end maintain a record regarding consumption of OR supplies. The OR management functionality 222 is typically supported by the medical records information portion 120 and corresponding medical records master files 140, and scheduling information portion 122 with corresponding scheduling master files 142.

The software functionality 900 has been described above as being part of the suite of software of Fig. 5. However, not all of the software functionalities 200 need be provided within the suite of software. Thus, the functionalities represented in Figs. 6-17 may operate as stand-alone functionalities interfacing with the VPR 100, or may operate in conjunction (embedded) with other of the software functionalities. For example, a software suite may comprise of only the registration fimctionality 202 and the enterprise master person index functionality 904 operating together and in conjunction with the UPR 100. Similarly, the security manager and lock manager may be embedded with the software functionalities, or may operate in a stand-alone fashion, interfacing with the UPR 100 and associated master files 130. Additional fimctionalities such as home health, pharmacy, radiology. and lab systems functionalities may be added to operate with the UPR 100 where such additional - os finctionalities are supported by various portions ofthe UPR 100, and associated master files 130. Where multiple functionalities are provided within the software suite, the interfaces for the functionalities may be provided by a cormnon user interface, for example, the user interface 104 discussed above.

Figure 18 illustrates a graphical representation depicting the IJPR mtegradug functionality at a data level. Specifically, the role ofthe UPR 100 in the process of order entry and scheduling is illustrated, providing a specific example of how software functionality based on the t1PR operates, and how worlcflows are bred on that functionality. In Figure 18, internal processes are depicted usmg solid lines, and user input/output is depicted using dashed lines.

Using a user interface 500 for an EMR, for example the inpatient clinical system or the ambulatory Elm user interfaces 400 or 420 respectively, a provider desires to place an order for a patient utilizing the UPR 100. A patient is selected, box 502, and the provider thereby gains access to information in the 1JPR for the selected patient. An order is entered, box SlO, where the order maybe for typical procedures such as medical treatments, therapy, and tests, which need to be scheduled for the patient. To accomplish the order entry, the order is sent to best practice functionality, box 512, where the order is automatically compared with coverage information from the risk management portion 118 of the UPR, and with medical record infonnation portion 120 of the t1PR The best practice functionality may be, for example, included in the inpatient clinical system, ambulatory EMR, or scheduling functionalities, and provides for a determination of, for example, whether a particular order will be covered by the patient's insurance, or whether the patient has special health concerns which would render the order unadvisable. The llPR links the best practice alerts fimctionality to information concerning the patient's insurance coverages, allergies, possibly conflicting procedures, current medications, diagnoses linked to the procedure, and other relevant information, allowing the best practice functionality to alert the provider of any possible issues with the new order.

Once the order has been altered to satisfy the alert, or the alert has been cleared, the order is recorded in the 1IPR 100 in the medical records portion 120.

Upon recording of the order, a system user via the scheduling fimctionality 220 - 29 accesses the UPR 100 to schedule a patient for the order, box 514, where information about the unscheduled order and information about the patient's status is made available to the scheduling functionality. The scheduler functionality selects a dine to perform the procedure, and information from the UPR is used to check for conflicts, box 516. For example, scheduling information from the scheduling information portion 122 may be used to determine if other potentially conflicting appointments have already been scheduled for that patient, taking into account for example the time necessary to travel from another scheduled appointment to the present scheduled appointment. Tune sensitive interactions, such as the need for fasting before drawing blood for testing may also be considered in scheduling the appointment. After the appointment is scheduled, the appointment is recorded in the ICIER, for example, in the scheduling information portion 122 for the patient. Providers with whom the patient has been scheduled may look at the schedule, box 518, where information from the UPR for the patient, for example the scheduling infonnation portion 122, is displayed, including the time, date, location, procedure, scheduling notes, and other patient specific scheduling information.

For all interactions with patient-specific information, the software fimctionality typically refers to the UPR 100. At this point, the contact is recorded in an audit trail in the audit controls 230 for that particular system user Indoor patient (not shown), where the system user, information accessed, and actions performed on the data are recorded. The actions may include viewing, editing, creating new data, or other manipulations to the UPR - Furler shown in Figure 18 are master files which may be stored in the common data repository, and which support corresponding master files of the master files 130. For example, the risk management master files 138 may include master files such as benefit plan master file 530, payor master file 532, and coverage master file 534. Similarly, the medical record master files 140 may include master files including allergen master file 540, procedure master file 542, procedure alternatives master file j44, medications master file 546, and diagnosis master file 548.

The UPR provides a common source of data by which health care providers, and scheduling, accounting, registration and insurance, etc. personnel may - 30 view current health care information for a patient at any time. Thus, where a patient is transferred from one health care context, for example from an inpatient context, to another health care context such as aprunay care physician (P(:P), where the PCP may be at the same or a different location, the PCP is able to access current infownation for the patient via the UPR Additionally, the IJPR allows a patient's care to be monitored at remote locations. Further, the UPR allows sothvare functionality to be desired to present only patient infonnation desired by a particular health care context. For example, information for an account context need not include certain medical information such as patient allergies, family medical history, etc The health care system may Include one or more suitable processors and storage media in cornmulucation with the processor(s) for providing the functionality described hey The fimctionality may be software residing on the storage media and run on the processor. Alternatively, one or more application specific integrated circuits may be used to provide some aspects of the functionality described herein. An exemplaTybealth care system which may utilize the UPR is further described below with reference to Figures 19- 27.

As discussed above, the UPR is typically a part of the central data repository, residing on one or more storage media. The I3PR may, for example, reside on the storage media as a single database record, or as multiple database records linked together. Alternatively, the UPR may be maintained in any fashion or format allowing information related to health care delivery for a patient and infonnation related to health care delivery management to be maintained for the patient and which would achieve one or more of the advantages discussed above, as would be appreciated by one skilled in the art. For example, the patient specific information of oS the UPR may be present within a single database record within a database residing on the storage media, where non-patient specific information is provided in one or more separate records within the database and linked with the record providing the patient specific information.

Although the UPR has been described as relying on master files for providing supporting non-patient-specific data in a central data repository, one skilled in the art would realize that such supporting data may be included within the UPR r) - 31 itself. Furler, the master files may be eliminated entirely, where the information in the master files is included as part of the UPR. In this case, although more storage media would be required, a common source of patient data would be provided having the advantages associated with a common data source discussed herein. Additionally, some data duplication may be acceptable in the UPR, where the UPR still provides other advantages described herein. Further, although the I}PR 100 has beers described as including eight portions, more or less portions may be included within the UPR lOO while still achieving the advantages discussed herein Similarly, the associated master files 130 may also include more or less master files for supporting the 1JPR while still achieving the advantages discussed herein. Furler, although an access manager is described herein including a lock manager and a security manager, one skilled would realize that the lock manager and security manager may be separate. The lock manager may be provided at any point in the health care system above the data level, for controlling system user write access. The security manager may be provided at any point in the health care system which allows the security manager to control system user access to the health care system and to the patient records.

This aspect of the invention has been described in terms of several embodunents, including a number of features and functions. Not all features and functions are required for every embodiment of this aspect of the invention, and in this manner a UPR is provided including information related to health care delivery for a patient, and information related to health care delivery management for the patient. The VPR provides a common source of data on which a health care system may rely, without the need to interface multiple databases. Further, the I3PRs common source of information allows multiple software applications to be integrated ?5 as a single software application, and reduces if not eliminates data duplication.

Further the reduced data duplication translates to lower operating costs associated with the entry of duplicated data lane UTR also facilitates compliance with legislative enactments for example the HIPAA, making it easier to authenticate data in the patient records and eliminate duplicative patient identities. The audit functionality allows a single audit record/trail to be maintained for system users and patient records. The security lo

- - -

finctiorality, using a single source of security information provided by He UPR, reduces the chance for duplicated and potentially confIicting/erroneous security access. The lock manager, operating at a level between the UPR and the software functionality allows assigning portions of the patient record to be locked and locking the portions of the patient record to occur more efficiently than in systems locking data at the database level.

1h accordance with another aspect of the invention, a health care information system is provided including a modular framework, and a display for providing a graphical user interface to a system user. In further embodiments, such a health care infonnation system maybe utilized with the 11PR 100 and associated master files 130 discussed above.

Referring to Figure 19, a single information database (a Health Care Information System (LICIT") data repository 620) is in communication with an HCIS graphical user interface 622 using a communications link 623, where the data IS repository 620 supports a modular ("plug-in') activity structure, in accordance with a preferred embodiment of the invention. The HC1S data repository 620 includes an enterprise database 624 which stores information related to system uses and patients, including, for example, the universal patient record 100 having data collected for each patient, and user security records defining security parameters for system users, maintaining a single data record per system user and patient. The HCIS data repository 620 farther includes an activities database 626 which stores the software functionality (activities) available in the plug-in HCLS fiamework. The activities database 626 includes a library of interchangeable program identifications and data requirements for each activity which are used in building the graphical user interface 622, fiercer discussed below. The HCIS data repository 620 farther includes a modular (plug-in) framework 628 and an information provider 630, in communication with each other, and with the enterprise database 694 and the activities database 626.

The plug-in framework 628, utilizing information Dom He activities database 696, is capable of composing and presenting each available activity to a system user in a unified graphical interface, as discussed below. Because the activities database 626 includes interchangeable program identifications, the HCIS graphical user interface - 33 622 provides a unified fool; and common corvenion including a common menu format and common visual components. Ike information provider 630 locates and provides each activity to be initiated with the data it needs to start up, allowing each activity to be launched at any tune without the necessity of obtanung data in each different context. Thus, when an activity is launched, the HCLS framework functionality 628 requests the information provider 63Q to provide necessary data for launching the activity based on the data requirements provided by the activities database 626. For example, where the activity is patient-specific, therefore requinng a patient identification in order to open, the information prodder 630 determines how to provide the patient identification in the current context (system user enviromnent), father discussed below.

In a preferred embodiinent, the single data repository 620 is a server, where the enterprise database 624 and the activities database 626 are embodied in a storage device, for example a hard dove, within the server. The funcuonatity provided by the information provider 630 and the plug in frameworl; 628 are programs running on a suitable processor within the server. The program identifications are program modules for forming specific functions which may be combined to form the functionality for a particular activity. The plug-in framework receives these program modules, or program address links for accessing the program 00 modules, along with the data corresponding to the data requirements for the particular activity, and is able to provide the particular activity to the system user via the graphical user interface.

The HCIS graphical user interface 622 communicates with the data repository 620 via the communications link 623, allowing system users to access venous activities provided by the HCIS system. The communication link 693 may represent the interpret, a dedicated data bus, or any other means for communicating information between the HCIS data repository 620 and the HCIS graphical user interface 672, as would be appreciated by one skilled in the art. The HCIS graphical user interface 692 includes a menu 632 in a common menu format across activities and operations (workspaces), providing the system user with options for opening venous workspaces, for example the workspace 634. The workspace 634 may allow handling of operations in a particular system user environment, for example handling patient admission and other patient encounters, scheduling, etc. as discussed below.

The workspace 634 includes an activity toolbar 636 listing activities available to the system user withm the particular workspace, where a particular activity selected by the system user is displayed in an actions display area 638. Activities may be nested within the work space 634 and are typically dynanucally built according to information the lafoProvider 630 delivers from the universal patient record and user security record of the enterprise database 624 and the activities database 626. Users may select tabs on the activity toolbar 636 to move freely between any combination of lo available activities without closing an open activity in the activity display area 638 or reentenug information that is already available within the workspace context Certain data combinations in the patient record may trigger alerts and requests for further data entry. These requests may automatically open new activities for the user, compelling compliance with enterprise- defined guidelines. Further, access to viewing and editing infonnation may also be limited in accordance with the system user's single user security record. Operation of and interaction between the HCIS data repository 620 and HCIS graphical user interface 622 are described with respect to Figures 20 and 2 l, in accordance with embodiments of the invention.

Refemug to Figure 20, a user logs into the HCIS system using, for example a user temunal (not shown) displaying the HCIS graphical user interface 622, as shown in step 040. The HCIS system prompt the user for a valid log-in identification before access to the HCE; system is allowed. Upon a successfi1 log-is to the HCIS system, the enterprise database 624 is searched for a user security record corresponding to the user identification, where the user security record defines all security parameters for that particular system user, step 642. Only menu options (for example, workspaces) for which the system user has appropriate security clearance, as determined from the enterprise database 624, appear on the menu 632. The system user may select a menu option from He menu 632, which opens a corresponding workspace 634 as shown in step 644. Where specific data is required to open the workspace, for example patient information, the information provider 630 retrieves the Lnformation from a universal patient record of the enterprise database 624, step - 3 5 646. The HCIS system farther checks the system user's security record of the enterprise database 694 to detent ine which activities within the workspace 634 the system user has sufficient security clearance to access step 648. Those activities for which the system user has security clearance to access appear within the activity tooIbar 636 as activity tabs (not shown), and the user may select a specific activity tab within the activities toolbar to initiate the activity, step 60. The user may select the particular activity tab using, for example, a mouse device (not shown) connected to the user terminal where He activity is selected by a click of a mouse button.

Alterrively, the activity may be selected utilizing a predetermined key of a keyboard (not shown) connected to the user terminal, or where the HATS graphical user interface includes a touch responsive screen, the desired activity may be selected utilizing, for example, a stylus (not shown).

Upon selection of an activity, the activities database 626 is queried to i. determine which information is needed to run that particular activity, for example which program identifications and data requirements, step 652. In step 654, the information provider 630 is requested to call the appropriate services for transferring the data needed for the particular activity to start up. For example, the information provider 630 may call services which search the enterprise database 624 for the necessary data. Where the data is not present in the enterprise database 624, the information provider 630 may call services to prompt the system user for the information. Additionally, the information provider 630 may determine data using other activities open within the workspace. For example, where a new activity requires a patient identification to open, the information provider 630 may determine the patient identification from other activities open within the workspace. The o5 information provider may then attam additional data by transferring the data from the open activity to the new activity, or for example, by searching the enterprise database 624 using the patient identification to determine the necessary data The necessary data is provided to the plu:,-in frameworl; 628, which utilizes the program identifications from the activities database 626 and the data from the information provider 630 to open the new activity in the activity display area 638, step 656. The activities database includes interchangeable program identifications for - 36 the activities, allowing the plug-in fiamework to maintain a common menu format and common visual components when causing information to be displayed on Me graphical user interface 622. The graphical user interface 629, because of the common menu formats and common visual components, allows system users to intuitively switch between workspaces and activities without additional and ume consmmg training for each activity, Strike the disparate menuformats and visual components utilized by the multiple interfaced systems of the prior art.

Additionally, the plug-in framework 628 and single data repository 620 allow additional activities and workspaces to be easily integrated with the HCIS. The new activities and/or workspaces with corresponding required program identifications are added to the activities database 626 along with the data requnents for the new activities. Utilizing such a modular structure facilitates adding activities to the system without the difficulty of interfacing several separate user interfaces, and fiercer, having a single data repository overcomes the difficulties of interfacing various separate databases. Further, as discussed above, utilizing the activities database 626 with interchangeable program identifications allows a common menu format and common visual components to be used in various workspaces and activities, reducing a health enterprise's overhead associated with training users on a health care information system.

In another embodiment, the system user may open multiple workspaces at one time, and switch between the workspaces as desired utilizing, for example, the mouse, a predetermined key, or a stylus (where a touch sensitive screen is provided) as discussed above. Further, multiple activities within a single workspace may be opened, where the user may similarly switch between the opened activities at any time. Thus, the system user is allowed to freely switch between available activities and workspaces at any moment, whether or not a particular activity is complete. This provides the system user with flexibility to immediately handle various situations and circumstances which may arise, for example emergency situations, without having to complete a current activity, and without loss of information or work progress within an interrupted activity.

In another embodiment, in addition to a user selecting activities to be _ a, _ displayed within the workspace, the HCIS system may cause an activity to open responsive to information entered by the system user. For example, "formation entered by the system user indicating an emergency disposition in a patient call documentation activity of a patient call workspace may automatically cause an activity for scheduling an emergency room visit to open on the graphical user interface.

Additionally, information entered by the system user m combination with data already present in the specific patient's record may trigger an alert in the HCIS system, automatically opening another activity on the graphical user interface 622. Figure 21 is a flow chart illustrating a switch from one activity to another within a workspace in accordance with an embodiment of the invention.

Where the system user is in a workspace with a number of activity options displayed in He activity toolbar 636' step 660, the system user performs a task within the activity that is currently open in the activity display area 638, step 662.

This may occur, as shown in Figure 21, by the user selecting a different activity in the workspace 634, step 664, or where the system opens another activity due to information entered by the system user, step 666. Upon selection or opening of another activity, the activities database 626 is queried to determine what program identifictibons and necessary data, for example a patient identification, are necessary to open the new activity, step 668. The infonnation provider 630 examines a current activity(ies) in the activity display area 638 and the workspace context for the necessary data, for example a patient identification from an open activity in the workspace, step 670. Where it is determined that a patient identification is present in an open activity in the workspace, the information provider 630 calls services that transfer the necessary information (here, the specific patient information) to the resew activity, as shown in step 672, and the new activity is opened, step 678. However, where the necessary data is not available in the current activity context, the information provider calls a service that prompts the user for the necessary information, for example entry of a patient identification, step 674. This information may be prompted using a dialog window displayed on the graphical user interface 622, for example within the activities display area 638, as would be appreciated by one skilled in the art. - 38

In step 676, the system user enters the required information, and the system opens the new activity, step 678. Lee information provider 630 is capable of obtaining the irfonnation that a particular activity needs to open in any context by calling the particular service that provides the information to the activity from a variety of sources, for example workspace context, database, user entry, etc allowing the user to move with total flexibility from one activity to another, and Mom one workspace to another. Where an activity is selected in any context, the inforination provider 630 needs just be informed of the data requirements for the activity, and the information provider is wholly responsible for and adaptable to obtnirung the information, at which point the activity opens.

Figure 22 illustrates an example of multiple workspaces and activities that a system user may employ simultaneously in the HCE; graphical user interface 622. For example, a home workspace 700, a workbench worl;space 70, a surgery case workspace 704, a patient admission workspace 706, and a patient encounter workspace 70S may be accessible to a system user through the menu options displayed on, for example the menu 632, for a system user havmg sufficient security clearance.

Upon opening a workspace, for example the patient encounter workspace 708, activities for which the system user has access for the particular patient appear as activity tabs (not shown) in the activity toolbar 636. For example, tabs for activities may include graphs 710, chart review 712, results review 714, registration 716, flowsheets 718, patient alerts 720, snap-shot 722, visit navigator 724, patient history 726, patient demographics 728, order entry 730, or any enterprise added activity i32 plugged into the HCIS system may appear.

Thus, from the menu options of the menu 632, the system user may open and maintain multiple workspaces simultaneously in the graphical user interface 692, where each workspace may draw on the same or a different patient record.

Further, within each workspace, the system user may select any activity listed in the activities toolbar 636. The activities can be opened in any order as many times as the system user desires, providing total flexibility in accessing all activities. The workspaces and activities included and shown in Figure 22 are exemplary in nature.

Any number of workspaces, and new activities within a workspace for new purposes - 39 can be created and accessed through an open workspace. For example, other workspaces may include, but are not limited to, patient call, case, log, report, pharmacy, lab, radiology, inpatient, home, and adrranistration workspaces. One or more of the activities 71732 or any other activity now available Including schedule, messaging, account maintenance, and patient list activities, activities such as the software functionalities 202-9 discussed above with respect to Figure 5, or any activities which become available the future may be included in any workspace.

1h accordance with another embodiment of the invention, He workspaces and/or activities may be user-defined. For example, the system user may define the activity tabs that appear in the activity toolbar 636. Activities may be disabled from appeanug in the activity toolbar for a particular worl;space, or activities from one workspace may be userdefined by the system user to appear in the activity toolbar of another workspace. Additionally, when an activity is launched, the system user may user-define what data fields are displayed within the activity display area.

For example, the system user may erunate certain data fields from appearing withers a launched activity, or, may user-define specific activities to display data fields which would normally not be displayed in the activity. User-defined preferences for a system user may be stored, for example, within the HCIS data repository 620, and more specifically, may be stored in the enterprise database 624, as part of, or corresponding to, a record for the system user.

Figure 23 illustrates a sample workflow for a nurse call center/nurse triage environment in accordance with an embodiment of the invention. Figure 23 illustrates how integration via the HCIS single user interface can help health care enterprises provide more efficient, more detailed and therefore better patient care across locations. Users handling patient calls in a triage environment can access a patient's complete medical records via, for example menu options 770 of the patient call workspace 740. Multiple patient call workspaces 140, each workspace representing the same or a different patient call, may be opened on the ACIDS;,raphical user interface, where system users are able to jump between the workspaces as desired. With any workspace, the system users may select any activity for which they have security clearance. For example, In the patient call workspace 740, the chart - 40 review activity 740, the pahent call documentation activity 744, and the patient demographics activity 746, may be accessed by the system user with adequate security access. The system user may firtber have access to other activities, for example, appointment entry 772, customer service 774, account maintenance 776, and electronic messaging 778 activities. Such additional activities may be available through the menu options 77Q ormaybe triggered automatically by the system, or provided to the system user in response to information entered as discussed below.

Any enterprise added activity 748 may be plugged into the HCIS graphical user interface due to the plugin nevork 628, providing additional activities (such as, for example, a call center ungluing specially customized forms such as Epic Smart Forms to collect the call information, an Intranet page for a particular organization, or otherfacility- specific activities). For example, upon opening a patient workspace via call center, a call center encounter is created in the patient record, which can be viewed by any authorized system user at any location utilizing the chart review activity ?42. Further, the patient call documentation activity 744 may be triggered, where clinical documentation 750 and/or customer service documentation 752 is entered The system users may create customer service encounters in a call center environment using, for example, the customer service activity 774 where the encounters may be accessed via the messaging activity 778, or through relevant activities available to system users with the appropriate role-based security clearance. The entry of clinical documentation 750 may include entering a patient disposition 756, and scheduling information 762. Disposition 756 may include, but is not limited to, urgent care 75S and emergency department 760 dispositions. Entry of an urgent care disposition 758 may cause an urgent care window (not shown) to automatically open, where patient demographic infonnation is pulled from the patient record of the enterprise database 624, and automatically displayed in relevant fields of the graphical user interface 622. System users may view arrival lists at urgent care facilities that have other products installed, and place patients on arrival lists from the patient call center enviromnent. Where the emergency department disposition 760 is entered, an expected ER arrival window (not shown) may open, where users at the call center may enter relevant information for the - 41 patient, and place the patient on the ER arrival list at facilities where products (including Epic products) are installed directly from the call center.

Where scheduling information 762 is selected, an appointment may be scheduled via schedule appointment 764, or advanced scheduling may be jumped to as shown at box 766. System users may schedule an appointment at box 764 for the patient directly from the call center, where the appointment shows up on the provider's schedule as viewed from an Epic (or other cornpames) product provided within the health care information system that allows access to the patient and/or provider record As shown at box 766, users with proper security mayjump to an advanced scheduling activity, for example, included within appointment entry 772 to access more detailed scheduling tasks.

The patient demographics activity 746 may be opened for entering/updating patient demographic information, and an order entry activity 754 may be opened, where call center system users are able to place orders that are administered at a different location, for example a flu shot. Once the order is filled, the patient record may be immediately updated to reflect the order, and health maintenance records for the patient are updated. Charges are dropped for the order, checked for correct coding, and matched to payor/plan information for the patient.

Further, benefit and billing information may be handled by the relevant activities available to system users with billing security clearance using, for example, the account maintenance activity 776.

Users handling patient calls in a triage environment are able to access a patient's complete medical record, and enter information into the record in real time, so that users working at other locations and/or roles within the enterprise can view new patient information simultaneously. Specially customized forms may be used as an enterprise-added activity 748 to record call specifics Providers can view and graph from these forms directly Mom the patient record as needed. Additionally, call center users can have more than one workspace open on their user interface at the same time for handling a single or multiple patients, allowing them to move between the workspaces with multiple calls quickly without losing the context and correct activity structure for each workspace (for example the workspace is rebuilt and (A - 49 displays correctly each tune a user returns to it from another workspace). The 'plug in" design of the HCIS user interface allows each organization to determine which activities they want to use in their call center environments. For example, some orgamzatiors could choose to collect call information via customizable SmartE;orms, which would then appear as another tab on the activities toolbar 636, while others might use protocols that are included tenth the call center application.

Figures 24 and 25 illustrate functionality ofthe HCIS graphical user interface for providing Medicare Secondary Payor (MSP) compliance in accordance with an embodiment of the invention. In this way, the invention can facilitate integrated workflows that help enterprises comply with MSP information regulations.

These regulations require health care enterprises to collect certain information at each visit from patients who are covered by Medicare. A system user accesses the scheduling activity to check in any patient who has arrived for a scheduled appointment, step 800, which may include detennining a patient's date of birth and/or age using the record for the patient. The system user may enter the scheduling activity by, for example, selecting the scheduling activity tab in the activity toolbar 636. The scheduling activity opens, step 809, and the system user locates and selects the patient's scheduled appointment, step 804. In step 806, the system checks whether there is Medicare coverage in the patient's visit account. Where there is no Medicare coverage in the patient's visit account, the user checks the patient in, as shown in step 808. However, where there is a Medicare coverage in the patient's visit account, the Medicare Secondary Payor information must be completed for the patient, and thus the system initiates the opening ofthe registration activity as shown in step 810. It is mandatory for clinical enterprises to collect Medicare Secondary Payor information o5 for patients who participate in Medicare. The HCIS's flexible, plug-in framework makes it possible not ordy to automatically check the patient's account, but to automatically open the registration activity and require the system user to enter MSP information into a standard form.

Upon initiating the opening of the registration activity in step 810, the activities database 696 is queried to determine what data is necessary (the data requirements) to open the new activity, for example is a patient identification required - 43 to run the activity, as shown in step 819. The information provider 630 checks the current activity and workspace context for the necessary information. for example whether a patient is open In the current activity, step 814. Where the necessary data is not present in the current activity, the information provider 630 calls a service that prompts the user for the necessary information, step 816, and the user enters the required information as shown in step 818. The information provider's prompt to the system user may be, for example, a dialog box displayed in the workspace requesting the information Tom the system user. The system then opens the registration activity as shown in step 820. However, where the necessary information is present in the current activity in step 814, the information provider 630 calls services that transfer the necessary information to the new activity, as shown in step 822, and the worlcilow continues as shown m step 820 where the system opens a registration activity.

Refernug to Figure 95, where the system opens the registration activity, step 820, the registration activity displays the Medicare Secondary Payor form to the user, step 822. Under current regulations, the Medicare SecondaTyPayor infonnation required by the govermnent must be entered before the form can be closed. step 824, the system user asks the patient the questions on the form and enters the information, and the system user returns to the scheduling activity to check in the patient, step 826. The system user may return to the scheduling activity, by for example, selecting the scheduling activity tab within the activity toolbar, or altematively, by "clicldng" a mouse connected to the graphical user interface in a portion of the workspace displaying the scheduling activity. lit step 898, the activities database 626 is queried to determine the data requirements to open a new activity.

The information provider 630 checks the current activity and workspace context for the data corresponding to the data requirements, and the information provider 630 calls services that transfer the necessary information to the new activity, step 832, where the current activity includes the necessary information. The workflow continues as shown in step 834 where the system activates the scheduling activity, and the system user checks the patient in, step 836. The configurability of this workflow 0 allows the enterprise employing the invention guaranteed compliance with the MSP regulations in one workflow without interfacing information between applications, - 44 - and without forcing the user to move back and forth between separate scheduling and registration applications or record information that must later be entered into a registration application by another user Although now shown, if the necessary information is not present - 5 within the current activity and work space context in box 830, services may be called to prompt the user for necessary information, where the user enters the necessary information similar to as discussed above with respect to boxes 816 and 818 of Figure Figures 26 and 27 illustrate functionality of the user interface for providing Centers for Medicare and Medicaid Service (CMS) (formerly the Health Care Financing Administration correct coding initiative (CCI)) local medical review policy aP) checking in accordance with an embodiment of the invention. These figures together show how the invention can facilitate integrated workilows that help enterprises comply with the CMS CCI by conducting LMRP checks in both the clinical and billing activities. The CCI encourages health care enterprises to use recognized order and diagnosis associations in order to ensure compliance with medical necessity requirements mandated by Medicare.

As shown in step 850, the system user working in the orders activity selects an order, step SS2, and enters a diagnosis and associates it with the order, step 854. In step 856, the system performs a medical necessity check, drawing on preloaded LMRP information which compares the order and associated diagnosis to matches approved by LIMP edits. To comply with the CMS's CCL the LMRP edit infonnation can be checked from activities associated with orders and billing, helping clinicians to comply with medical necessity guidelines, and preventing clinicians from placing orders with diagnosis associations that might not be covered by insurance. It is determined whether the order and associated diagnosis match is covered. Where the match is covered, the system user files the order, step 858, the charges for the order are then sent to billing and the order undergoes order transmittal, step 860 and 862, respectively. However, where the match between the order and associated diagnosis is not covered, the system warns the system user that the associated diagnosis is not covered by LMRP and queries the user whether to accept the order - 45 and associated diagnosis, step 864. Where the order is accepted, flow returns to step 858 where the system user files the order, and charges for the order are sent to billin, and the order undergoes order transmittal, steps 860 and 869, respectively. However, where the order is not accepted the system user changes the diagnosis associations, step 872, and the woA;flow returns to step 856. Altematively, the worlcflow returns to step 852 where the system user selects another order. As a furler nlternatlye, flow returns to step 85S where the system user files the order, and charges for the order are sent to billing, and the order undergoes order trarmttal, steps 860 and 862, respectively.

As shown in Figure 27, once the charges for the order are sent to billing, for example as specified by any of steps 860, 868 or 876, the system user enters the billing activity as shown in step 880. Similar to entering the scheduling activity as discussed above with respect to step 800 (Figure 24), the system user may enter the billing activity by, for example selecting the billing activity tab of the activity toolbar.

step 882, the system user selects the charges for the order filed, for example, at box 858 of Figure 26, and the system perfonns a medical necessity check, drawing, on preloaded L1^P information, which compares the order and associated diagnosis to matches approved by LMRP edits, and it is determined whether the match is covered, step S84. To comply with CMS's CCI, the LMRP edit information may be checked from other activities, for example activities associated with orders and billing, facilitated by the flexible plug in frameworl; 628. Where the match is covered in step 884, the system user bills for the charges as shown in step 886. However, where the match is not covered in step 884, the system warns the system user that the associated diagnosis is not covered by LMRP, and queries the system user whether to continue billing for the charges, step 888. As discussed above with respect to step 816 (Figure 24), the query may be in the fonn of a dialog box displayed in the workspace requesting the information from the system user. Even if an order with a non-covered diagnosis association has been filed by fine clinician, the billing user can be alerted to correct the billing for the order before it is sent. Where the system user indicates to continue billing for the charges in step 88S, flow returns to step 886 where the system user bills for the charges. However, where the system user does not continue billing \ - 46 for the charges, the system user places charges in charge review, step 892, and the system user selects a workDow management tool prodded, for example, as the electronic messaging activity, step 894. The system user sends the message to the user who filed the order, and the message asks for clarification of the reason for filing the non-covered diagnosis associations, step 896.

1i1 an alternate embodiment not shown, where an Epic Care medical record review is utilized, the placing of changes in change review of box 892 is done automatically by the HCIS, and thus need not be done by the system user.

The ability to conduct LMRP checks from multiple activities, which can alert various users to the same irregularities, is just one example ofthe integrated way in which an enterprise may use the invention to achieve a high late of compliance with regulations that simultaneously affect disparate aspects of the health care enterprise.

The workilow management tool discussed above is provided as an Electronic Messaging and Workflow System. The Electronic Messaging and Workflow System (i.e. Baslcet) enhanced by this invention is a comprehensive integrated interface that provides information, manes users aware of alerts and tasks that require their attention, and accesses relevant features of their applications.

Basket is a feature which may be shared by Epic applications, and typically appears in various forms in all interfaces, including the EpicDesktop. While its basic fimction is to communicate messages to recipients, there is a great deal of specialization in tenets of how messages are Generated, and what users can do when they receive them. A plurality of specialized message types available, with some providing general features, for example, entering phone messages into In Basket resembling the common While you were out. ' forms, and others being specialized in nature, for example, allowing the revision of orders for lab tests after the order has been sent to the lab.

As an Electronic Messaging System, In Basket may collect messages sent to a system user and display them. Many messages require little or no action and are, in essence, reports. Common messages of this type include, for example, staff messages, phone calls, test results, and the 'covered work message Tom the patent. - 47

As a Worllow System, In Basket may make available a cross-section of features from Epic's applications provided by the health care system. Many messages' contain a firm- to some area of an application, or present their own interface for threcipient to take action. A common message of this type may provide a link to an encounter and ask the recipient to cosign an order for a medication. En this example, the message appears in an In Basket interface on the graphical user interface, and opening the message also opens a patient's medical record associated with the order. In another example, a similar message opens an incomplete telephone encounter so that the system user can address the issues raised by the phone call.

Messages can be sent, for example, to a system user personally, to a group to which a system user belongs, to the workstation at which a system user is worldug, to any system user who has a particular patient's record open, and may be sent using other methods of identifying recipients. Many applications provided by the healthcare system have features to generate electroruc messages. When results (i.e. blood sugar, blood pressure, etc. . .) are entered (or received from a lab) for a patient, messages may be automatically generated to report those results to the provider who ordered the test. Such messages may be generated based on an urgency level of the test results. For example, messages may be generated any time test results are obtained for the patient, generated when the test results fall within a predetermined range defined as 'abnormal', or generated when the test results fall within a predetermined range defined as a 'pamc' ranger where the system user is able to configure the urgency level at which the message(s) will be sent. Further, paging capabilities may be incorporated in, or linked with, the

system to allow system users to be paged when a message is received for that system user.

The electronic messages are typically completed view the action required by the message is taken. For example, for report-Wpe messages, a system user receiving the message merely needs to read the message and mark the message as done.' For other messages, a system user may need to talce some specific action, such as cosign an order or schedule an appointment before the electroruc message is complete. When the information displayed is refreshed, completed messages are no - 4S longer displayed.

The functionality provided by the messaging and worlow system may be preferably embedded within the health care system, or operate as standalone functionality in conjunction with the health care system. Further, the messaging and worl;flow functionality is typically supported by the various parts of the HCIS data repository 62Q as would be appreciated by one skilled in the art. For example, the entepnse database 624 may maintain various files of information (i.e. threshold values defmmg urgency level of test results, defining message distribution lists, etc. . .). The activities database 626 may include program structure to provide the messaging functionality along with the other various activities offered by the health care system, including (but not limited to) performing checlcs on information entered (or received) Into a particular patient record which may necessitate automatic generation of a message to a system user. Many messages provide system users with the option of accessing one or more activities. The options are defined in terms of the activity which is made available, in that the option (typically a button or menu selection) is based on a Menu record recording the activity launched when the button is clicked or the menu option is selected. The info provider 630 may operate in conjunction with the activities database 626 in providing the messaging functionality with any required information. If the activity provides patient-specific information, the info provider, having identified a patient as the topic of the message, passes that patient to the activity. This allows the activity to open without first prompting the user for a patient. The plug- in HCIS framework 628 may allow the messaging and worldlow functionality to be displayed or otherwise presented to a system user within the HCIS graphical user interface 622.

This aspect of the invention has been described in terms of several embodiments, including a number of features and fimctions. Not all features and functions are required for every embodiment of this aspect, and in this mater a flexible system by which the plug-in frameworl; is provided and allows additional activities to be added to the system without the difficulties associated with interfacing and configunug the activities to work with the HCIS and with each another. Further, the ease of interfacing applications due to the plug-in framework results in a high rate (ax) - 49 of compliance with government regulations. I-he common menu structures and common visual components provided by the graphical user interface provide system users with an intuitive interface with the HCIS, reducing He trading requirements of system users. Furler, the graphical userinterface end pluc-in framer allows system users to seamlessly switch between activities available within the HCIS, not requiring exiting of one program and endy into another program. Additionally, providing a single data repository (i.e. IJPR 100) used by the activities virtually eliminates data duplication between activities, and eliminates the difficulties associated with interfacing multiple databases having varying structure or format. In addition, the single data repository allows a common security record to be kept for system users, facilitating uniformity of security access for system users across all activities of the HC IS, ease of setting security requirements for new system users, and reduced probability of granting mistaken security privileges as security information for all activities need be entered but once. Further, the single data repository and plug in framework allows an alert system to be provided to alert system uses where information entered in an activity conflicts with other information for a particular patient in the data repository. In addition, system uses are provided the ability to user-define the graphical user interface giving the flexibility of tailoring the graphical user interface to offer functionality and information to better serve the user's specific needs.

Although the single data repository has been described as a server in the preferred embodiment, one skilled in the art would realize that any application specific programming language, hardware, processor(s), and memory may be combined to perform the functionality of the components for the single data repository. Additionally, the enterprise database and the activities database may reside on the same storage device, or separate storage devices in communication with the information provider and the plug in framework while still being accessible and usable for all activities, where the communication link may be the intemet, a data bus, or any other means for communicating information, as would be understood by one skilled in the art. Further, although the enterprise database 624 has been disclosed in various embodiments as including data collected for each patient in a single record - 50 such as the UPR 100, one skilled in the art would realize that advantages may be achieved Mom at least the common menu format and visual components provided by the graphical user interface as discussed herein where Formation for patients and/or security information is stored in more than one record per patient. In addition, the graphical user interface may be displayed on any display device, including a cathode ray tube device, Liquid Crystal Display, or any other device capable of conveying information to a system user, where the display dence may be associated with a personal computer, server, handheld electronic device, etc. . . The feahres discussed herein are intended to be illustrative of the features that may be implemented, however, such features should not be considered exhaustive of all possible features that may be implemented in a system configured in accordance with the aspects and embodiments ofthe invention discussed above.

Claims

What is claimed is: 1. An electronic health care system comprising: a modular framework including a plurality of activities, each activity providing an aspect of patient care, the framework adaptable for accepting additional activities forming a single integrated system; and a display in communication with the modular framework for providing a graphical user interface, the graphical user interface adaptable for displaying information corresponding to one or more of the activities and including a common menu format utilized by the graphical user interface for communicating available operations in the graphical user interface, and common visual components utilized by the graphical user interface for displaying information to a system user.
2. The system of claim 1 further comprising a single information database in communication with the modular framework, the information database including data accessible by the plurality of activities of the modular framework.
3. The system of claim 2 wherein the single information database includes patient records.
4. The system of claim 2 wherein the single information database includes system user security information.
5. The system of claim 1 wherein the graphical user interface is adaptable for displaying at least one workspace, wherein the information corresponding to one or more of the activities is displayed in the at least one workspace.
6. The system of claim 5 wherein the at least one workspace includes an activities toolbar listing available activities within the workspace, and an activity display area for displaying information related to at least one selected activity.
7. The system of claim 6 wherein the activities toolbar may be defined by the system user.
8. The system of claim 1 wherein the information corresponding to the activities may be defined by the system user.
9. The system of claim 1 further comprising a security management system m communication with the modular framework and the graphical user interface for controlling access to the activities.
10. The system of claim 9 further comprising a single information database including system user security access information, the single information database in communication with the security management system, wherein the security management system controls system user access to activities responsive to the system user security access information.
11. The system of claim 1 further comprising an infor nation management system in communication with the modular framework and the graphical user interface for determining the information necessary for launching an activity, and providing the 53 necessary information to the modular framework and the graphical user interface for launching the activity.
12. The system of claim 11 wherein the information management system comprises: an activities database including program identifications and data requirements for building the graphical user interface for each activity; and an information provider for acquiring data to fulfill the data requirements for each activity; wherein upon launching a particular activity, the activities database is queried to determine program identifications and the data requirements for the particular activity, the information provider is queried for the data corresponding to the data requirements for that particular activity, and the program identifications and the data are utilized to create the graphical user interface for the particular activity.
13. The system of claim 12 further comprising a single information database including data corresponding to the data requirements for the plurality of activities, wherein the information provider searches the single information database for the data, and provides the data where the data is present in the single information database, and queries the system user for the data where the data is not present in the single information database.

O
14. The system of claim 1 whereir the modular framework comprises an activity installer for installing additional activities in the system, wherein the system maintains the common menu format and the common visual components in the graphical user interface for installed additional activities.
15. The system of claim 1 further comprising an alert system in communication with the modular framework for alerting the system user responsive to information provided by the system user in an activity.
16. The system of claim 15 wherein the alert system's alert includes providing an alert message to the system user in the graphical user interface in response to information provided by the system user in an activity.
17. The system of claim 1 S wherein the alert system's alert includes displaying information corresponding to another activity on the graphical user interface in response to information provided by the system user in an activity.
18. A method of providing a health care system having an integrated graphical user interface, comprising: within the health care system, providing a plurality of activities in a modular framework, each activity providing an aspect of patient care; displaying a menu in a common menu format on the graphical user interface, the menu communicating available operations to a system user; and displaying common visual components for the activities on the graphical user interface, the common visual components providing information to the system user. A)
19. The method of claim 18 wherein the health care system further comprises a single information database, and further comprising accessing data for the plurality of activities from the single information database.
20. The method of claim 19 wherein the accessing data includes accessing patient records from the single information database.
21. The method of claim 19 wherein the accessing data includes accessing system user security information from the single information database.
22. The method of claim 18 wherein the displaying the menu in a common menu format includes displaying at least one workspace, each workspace providing an operation to the system user, wherein the information corresponding to the one or more activities is displayed in the at least one workspace.
23. The method of claim 22 wherein the displaying the at least one workspace includes: generating an activities toolbar listing activities available within the displaying the activities toolbar in the workspace; and displaying information related to at least one selected activity in an activities display area of the workspace.
24. The method of claim 23 further comprising defining content of the activities toolbar.
2. The method of claim 23 further comprising defining the information related to the at least one selected activity displayed in the activities display area.
26. The method of claim 18 wherein displaying the menu i Includes determining security access for the system user, and displaying only the options accessible to the system user responsive to the determining.
27. The method of claim 26 wherein the determining security access for the system user includes searching a single information database having security access information for security access information for the system user.
28. The method of claim 18 further comprising launching an activity from the plurality of activities.
29. The method of claim 28 wherein the launching an activity from the plurality o activities includes: determining program identifications and data requirements necessary for launching the activity from an activities database; acquiring the data corresponding to the data requirements from an information provider; and launching the activity using the determined program identifications and acquired data.
30. The method of claim 29 wherein the acquiring the data corresponding to the data requirements includes searching a single information database for the data, and providing the data where the data is present in the single information database, and requesting the information from the system user where the information is not present in the single information database.
31. The method of claim 18 further comprising installing additional activities in the health care system while continuing to provide the common menu format and Me common visual components on the graphical user interface.
32. The method of claim 18 further comprising alerting the system user responsive to information provided by the system user in an activity.
33. The method of claim 32 wherein the alerting includes providing an alert message to the system user on the graphical user interface.
34. The method of claim 32 wherein tile alerting includes displaying information related to another activity on the graphical user interface.
35. An electronic health care system substantially as hereinbefore described with reference to the accompanying drawings.
36. A method of providing a health care system having an integrated graphical user interface substantially as hereinbefore described with reference to the accompanying drawings.