Blog Details

Invented by Tony Brummel, Carl D. Dvorak, Khiang Seow, Daniel Bormann, Steve Larsen, Andrew Ma, Aaron T. Cornelius, Epic Systems Corp

The Epic Systems Corp invention works as follows

An electronic healthcare system comprises a modular frame work and a display communicating with the framework to provide a graphic user interface for a system user. The modular framework comprises a plurality activities, with each activity providing a different aspect of patient treatment. It is adapted to accept additional activities in order to form a single integrated system. The graphical interface can be adapted to display information that corresponds to one or more activities. It also includes a menu format to communicate available operations and visual components to display information to the system user.

Background for System and Method for a Seamless User Interface for an Integrated Electronic Health Care Information System

Electronic medical records and practice management systems are designed to store, retrieve, and deliver data for a health enterprise. Some systems only address one type of data necessary for clinical management and practice management. For example, billing records for outpatients, medical records for outpatients, etc. These systems have a single user interface that allows only a limited amount of information to be entered. They are also combined with one data repository. These systems use data repositories that are difficult to integrate and often contain duplicate information.

Other systems provide multiple interfaces for accessing a single repository of data, but the interfaces differ in appearance and operation. The facilities that implement such dissimilar interfaces have to spend a lot of time and energy training users on the different applications. These systems also limit the ability of users to move freely between applications, requiring them to complete certain tasks before moving to another. In addition, these systems require that when switching applications two programs are run simultaneously.

The systems described require complex deployment of multiple interfaces or data repositories for different system users, and terminals in the entire health care facility. Due to the inflexibility and lack of flexibility with the different interfaced applications, the health care enterprises using such systems may not comply with the best practices and regulations for healthcare. The health care enterprise also incurs unnecessary administrative overhead due to the lack of communication between the interfaced applications. For example, billing applications that contradict the diagnostic decisions filed in the enterprise?s medical records application or poor or nonexistent clinical decision support.

An electronic Health Care Information System is provided, including a modular frame work and a display communicating with the framework to provide a graphic user interface for a system user. The modular framework contains a number of activities. Each activity is responsible for a particular aspect of patient care. The activities that provide aspects of patient care can include but not be limited to those used to provide health care to patients (for example, providing a provider with medical information about a patient such as a chart-review activity or a patient’s history). Activities used to manage health care for patients (for example, registration and patient demographics) are also included. . . activities). The graphical interface can be adapted to display information that corresponds to one or several of the activities. It includes a menu format to communicate available operations within the graphical interface and visual components to display information to the system user.

The modular framework makes it possible to add additional activities without having to deal with the challenges of integrating and configuring them to work with HCIS or with each other. The modular framework makes it easy to integrate applications, which leads to a higher rate of compliance with regulations. The graphical user interface provides system users with a consistent user interface, as it uses common menu structures and visual components. This reduces the need for system users to be trained on different user interfaces. The graphical interface and modular framework allow system users to switch freely between activities within the HCIS even before they have completed a specific activity. System users do not have to finish a specific activity to access another one. This allows them to respond to emergency situations without losing information or flow of work. The graphical interface and modular framework also facilitate the combination of heterogeneous but related activities within a particular workflow (for instance, work space).

In further embodiments, the activities are provided with a single database of information, which reduces or eliminates data duplication and the problems associated with integrating multiple databases that have a different structure or format. The single database also allows for a uniform security access across all HCIS activities, making it easier to set security requirements for new users and reducing the likelihood of mistakenly granting security privileges. The single database and modular framework also allow for an alert system that warns system users when information entered into an activity is in conflict with information stored in the database about a patient. The system user can also customize the graphic user interface. This allows them to tailor the interface to their needs. As an electronic messaging and workflow system, the tool also provides a workflow manager.

Referring to FIG. A single database (a Health Care Information System?HCIS?) Daten repository 20) is in communication with an HCIS graphical user interface 22 using a communications link 23. The data repository supports a modular (?plug-in?) A single information database (a Health Care Information System (?HCIS?) According to a preferred embodiment, the activity structure is based on a modular (?plug-in?) structure. The HCIS data repositories 20 include an enterprise database 24, which stores information related system users and patients. This includes a universal patient records having data collected on each patient and user security record defining security parameters. U.S. Patent Application Ser. No. No. Dvorak and others, filed simultaneously herewith, are hereby incorporated herein by reference. The HCIS data repositories 20 also include an activities database 26, which stores all the activities that are available within the plug-in HCIS Framework. The activities database 26 contains a library with interchangeable program identifiers and data requirements that are used to build the graphical interface 22. The HCIS data repositories 20 also include a modular framework (plugin) 28 and an Information Provider 30, which are in communication both with each other and with the enterprise databases 24 and 26. As discussed below, the plug-in framework 28 can compose and present each activity available to a user of the system in a unified graphic interface using information from activities database 26. The HCIS graphical interface 22 has a uniform look and convention, including a menu format and visual components. This is because the activities database 26 contains interchangeable program identifiers. Information provider 30 finds and gives each activity the data needed to launch it. This allows each activity be launched at any moment without having to obtain data for each context. When an activity is launched by the HCIS framework functionality 28, the information provider 30 will be requested to provide the necessary data based on data requirements from the activities database 26. The information provider 30 will determine how to present the patient ID in the context of the system user environment (for example, if the activity is specific to a particular patient).

In one preferred embodiment, the data repository is a server. The enterprise database 24 as well as the activities database 26, are stored on a storage device such as a hard disk within the server. The plug-in framework 28 and the information provider 30 provide functionality by running programs on a processor in the server. Program identifications represent program modules that can be combined together to create functionality for an activity. The plug-in framework receives the program modules or program addresses links to access the program modules along with data that corresponds to the requirements for a particular activity. It can then provide this particular activity to the user of the system via the graphic user interface.

The HCIS graphical interface 22 communicates via the communications link 23 with the data repository 20, allowing users of the system to access the various activities offered by the HCIS. Communication link 23 can be the internet, dedicated data bus or any other way to communicate information between HCIS data repositories 20 and HCIS graphical interface 22. The HCIS GUI 22 has a menu in a standard format that is used across all activities and operations. This menu allows the user to choose from a variety of workspaces. For example, the workspace 34. The workspace 34 can be used to handle operations within a specific system user environment. For example, handling patient admissions and other patient encounters. As discussed below. The workspace 34 has an activity toolbar that lists activities available to system users within a workspace. A particular activity chosen by the user is displayed on an activity display area. The InfoProvider 30 builds activities dynamically based on information it receives from the universal patient records and user security records of the enterprise database 24, and the activities databases 26. Activities can be nestled within the workspace 34. The activity toolbar 36 allows users to select tabs and move freely between activities. This is done without having to close the workspace 38, or enter information already present in the workspace context. Certain combinations of data in the patient’s record can trigger alerts or requests for additional data entry. These requests can automatically launch new activities, forcing the user to comply with enterprise-defined guidelines. Access to information viewing and editing may be restricted based on the single user security record of the system user. The HCIS data repository and HCIS graphic user interface are described in relation to FIG. “2 and 3 in accordance to embodiments of the present invention.

Referring to FIG. As shown in Step 40, a user logs onto the HCIS system by using a terminal (not displayed) that displays the HCIS GUI 22. Before access to the HCIS is granted, the HCIS system asks for a valid log in identification. Step 42: After a successful login to the HCIS, the enterprise database 24 searches for a record of user security that corresponds to the user ID. The record contains all the security parameters for the particular system user. The menu 32 only displays menu options (such as workspaces) that the system user is authorized to access, as determined by the enterprise database 24. The user can select a menu item from the menu 32 to open a workspace 34, as shown in Step 44. When specific data, such as patient information, is needed to open a workspace, the information provider 30 retrieves that information from the enterprise database 24’s universal patient record, step 46. Step 48 is when the HCIS system checks the security record of the system user in the enterprise database 24. This allows it to determine which workspace activities the user can access. The activity tabs of the system user’s security clearance appear in the activity toolbar 36 (not shown). Step 50 is the selection by the user of a particular activity tab from the activities toolbar. The user can select the specific activity tab by using a mouse (not shown) attached to the terminal, where the activity will be selected with a single click. The activity can also be selected using a key on a keyboard connected to the terminal (not displayed). Or, where the HCIS graphic user interface has a touch-responsive screen, it may be possible to select the desired activity by means of a stylus.

Step 52: “After selecting an activity, it is queried in the database of activities 26 to find out what information is required to run that activity. For example, which program identifications or data requirements are needed. The information provider 30 will be asked to contact the services in step 54 to transfer the data required to launch the activity. The information provider 30 could, for example, call services that search the enterprise database 24 to find the data needed. If the data are not in the enterprise database 24 the information provider may call services and ask the user to provide the necessary information. The information provider 30 can also determine data by using other open activities in the workspace. If a new activity needs a patient ID to be opened, the information provider can determine that patient ID from other open activities within the workspace. The information provider can then obtain additional data either by transferring data from an open activity to a new activity or by searching enterprise database 24 with the patient ID to determine the required data.

The plug-in framework 28 receives the necessary data, which it uses to identify the programs in the activities database 26 using the data provided by the information provider 30, to display the new activity on the activity display area. The activities database contains interchangeable program identifiers, which allows the plug-in framework maintain a common visual component and menu format when displaying information on the graphical interface 22. Because of the common menu format and visual components, the graphical user interface 22 allows system users, without additional training and time-consuming for each activity to switch intuitively between workspaces and tasks.

Also, the plug in framework 28 and the single data repository 20, allow for additional activities and workspaces that can be easily integrated into the HCIS. The data requirements and the required program identifications for the new workspaces or activities are then added to the database of activities 26. A modular structure makes it easier to add activities without having to interface with multiple user interfaces. Having a single database also eliminates the need for multiple databases. As discussed above, using the activities database 26 and interchangeable program identifiers allows for a common menu and visual components to be utilized in various workspaces, and activities. This reduces a health enterprise?s overhead associated with user training on a healthcare information system.

In another embodiment, an user of the system may open multiple workspaces simultaneously and switch between them as desired using, for example the mouse, a key predetermined, or a stylus, (where a touchscreen is provided), as discussed above. Multiple activities may also be opened within a workspace, and the user can switch between them at any time. The system allows the user to switch freely between workspaces and activities at any time, regardless of whether a specific activity is completed. The system user can handle various situations that may arise, such as emergency situations, immediately without having to finish a current task and without losing information or progress in an interrupted activity.

In another embodiment, instead of allowing the user to select activities that are displayed in the workspace, HCIS may open an activity based on information entered by the user. In one example, if the user enters information indicating that an emergency is to be handled in the patient call documentation activity within a workspace for patient calls, the HCIS system may open an activity on the graphic user interface to schedule an emergency room appointment. Information entered by the user, in conjunction with data that is already in the patient’s file, may also trigger an alert on the HCIS system. This will automatically open another activity in the graphical interface. FIG. “Figure 3 shows a flowchart illustrating the switch from one task to another in a workspace, according to an embodiment of this invention.

The system user may perform a task in an activity currently displayed in the display area of the activity 38 when he is in a workspace where a number activity options are displayed in the toolbar 36. As shown in FIG. Step 64 is the user choosing a different activity on the workspace 34. Step 66 is the system opening another activity based on the information provided by the system user. The activities database 26 is queried upon selection or opening another activity to determine which program identifications and data are required, such as a patient ID, to open the new one, step 68. Step 70 is when the information provider 30 searches for data in the workspace context and in any open activities in the workspace. For example, a patient ID from an active activity. When it is determined that the patient identification exists in an active activity in the workspace context, the information provider 30 invokes services to transfer the required information (here the specific patient information), as shown in step72, and opens the new activity at step78. If the data required is not present in the context of the current activity, the information provider will call a service to prompt the user, such as by asking for a patient ID, at step 74. The user can be asked for this information by using a dialog box displayed on the graphic user interface 22, such as within the activities display area.

The system will open the new activity in step 78 after the user has entered the information required. The information provider 30 can obtain the information needed to open a specific activity in any context. This is done by calling a service that gives the activity the required information from various sources. For example, the workspace context, the database, the user entry, etc. . . The user can move from one activity or workspace to another with complete flexibility. When an activity is selected, in any context whatsoever, the information providers 30 only need to be informed about the data requirements of the activity. The information providers are then fully responsible and adaptable for obtaining that information. At this point, the activity will open.

FIG. The HCIS GUI 22 provides a graphical interface that allows a user to simultaneously access multiple workspaces. A system user with sufficient security clearance may have access to, for example, the menu options on the menu 32. This includes a home workspace, workbench workspace, surgery case workspace, patient admission workspace, and patient encounter workspace. When a workspace is opened, for example, the patient encounter workspace, the activities to which the system user can gain access are displayed as tabs in the activity toolbar. Tabs for activities can include, for example, graphs 110. Chart review 112, results reviews 114. Registration 116. Flowsheets 118. Patient alerts 120. Snap-shot 122. Visit navigator 124. Patient history 126. Order entry 130. Or any enterprise added activity (132) plugged into the HCIS System.

The system user can open and maintain several workspaces in the GUI 22 simultaneously, each of which may be based on a different or the same patient record. The system user can also select an activity from the toolbar 36 within each workspace. The system user can open the activities in any order, as many times as they wish. This allows for total flexibility when accessing all of the activities. The workspaces and related activities shown in FIG. The workspaces and activities shown in FIG. Open workspaces allow for the creation of any number of workspaces and activities. Other workspaces include but are not restricted to: patient call, case log, report; pharmacy, lab, radiology; inpatient, home and administration workspaces. Any workspace may include one or more of the 110-132 activities or any other activities currently available, including messaging, account management, schedules, patient lists, or future activities.

In accordance with an alternative embodiment of the invention the workspaces or activities can be defined by the user. The system user can, for example, define the tabs of activities that appear in activity toolbar 36. The system user can disable activities from appearing in an activity toolbar in a specific workspace or define the activities that appear in another workspace’s activity toolbar. The system user can also define which data fields appear in the activity display area when an activity launches. The system user can, for example, eliminate certain data from an activity or define specific activities that display data fields that would not normally be displayed. The HCIS data repository 20 and, more specifically, the enterprise database 24 may store user-defined preferences of a system users.

FIG. A sample workflow is shown in FIG. 5 for a nurse triage/call center environment, according to an embodiment of the invention. FIG. FIG. The menu options 170 in the patient call workspace can be used by users handling patient calls within a triage setting to access complete patient medical records. On the HCIS GUI, multiple patient call workspaces (140) can be opened, with each workspace representing a patient call. System users may jump between workspaces as they wish. The system user can select any activity that they are authorized to perform. The system user who has adequate security clearance can access, for example, the chart review activity, the call documentation activity, and the demographics activity in the workspace 140. The system user can also access other activities such as appointment entry 172 and customer service 174. Account maintenance 176 is another option. These additional activities can be selected from the menu 170 or triggered by the system. They may also be provided to the user in response information entered.

Click here to view the patent on Google Patents.