WO2003025703A2 - Methods of providing medical information and related systems and computer program products - Google Patents

Methods of providing medical information and related systems and computer program products Download PDF

Info

Publication number
WO2003025703A2
WO2003025703A2 PCT/US2002/029354 US0229354W WO03025703A2 WO 2003025703 A2 WO2003025703 A2 WO 2003025703A2 US 0229354 W US0229354 W US 0229354W WO 03025703 A2 WO03025703 A2 WO 03025703A2
Authority
WO
WIPO (PCT)
Prior art keywords
identification
surgical operation
anesthesia
scheduled
patient
Prior art date
Application number
PCT/US2002/029354
Other languages
French (fr)
Other versions
WO2003025703A3 (en
Inventor
Iain C. Sanderson
Original Assignee
Duke University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Duke University filed Critical Duke University
Priority to AU2002336552A priority Critical patent/AU2002336552A1/en
Publication of WO2003025703A2 publication Critical patent/WO2003025703A2/en
Publication of WO2003025703A3 publication Critical patent/WO2003025703A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/109Time management, e.g. calendars, reminders, meetings or time accounting
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms

Definitions

  • the present invention relates to methods, systems, and computer program products for information processing.
  • Anesthesia Information Systems have evolved significantly since the 1st generation Duke Automated Monitoring Equipment (DAME) system in 1972. Initially they were simple recording devices using the hardware available at the time, which tended to be large and/or unreliable. User input to the DAME was by keyboard and bar codes.
  • a diagram of a first generation DAME system is illustrated in Figure 1.
  • the DAME system included one or more monitoring carts 101, a data manager 103, and a printer 105 coupled through a DMXNET Network 107.
  • Each monitoring cart 101 could include a DEC LSI-11/02 microcomputer and a barcode reader.
  • the data manager could include a DEC PDP-11/23 minicomputer, a 5Mb hard drive, 256K RAM, and a custom built operating system.
  • Arkive AIS The second generation of AIS was based on PC technology, with more reliable operating systems, software and hardware.
  • the Arkive AIS was an example of this, and the largest installation of this type anywhere in the world was believed to be at Duke University Medical Center in Durham, North Carolina.
  • a diagram of the Arkive system is illustrated in Figure 2.
  • User input was by touch screen plasma display. These were file serving, networked systems with rudimentary Paradox or Access databases usually running on a Novell platform.
  • an Arkive system could include a plurality of workstations 201, a Novel network file server 203, a plurality of network printers 205, a mirrored database 207, and data storage 209, coupled by network 211.
  • the third generation of AIS is that of the current installed base.
  • Two tier or three tier client/server systems now use robust relational databases such as Microsoft SQL Server, Sybase Adaptive Server, or the like.
  • the client applications are usually 'fat' in that a great deal of processing is done on the client, usually because of the requirement to handle monitored data streams from equipment attached to the patient.
  • Systems from Draeger Medical Inc., Philips Medical Systems Inc., GE, Surgical Information Systems Inc., and PICIS Inc. generally have this architecture at their heart.
  • the Draeger system referred to as the Saturn Information System or "Saturn", is illustrated in Figure 3.
  • the Saturn Information System can include a plurality of clinical workstations 311, a plurality of non-clinical workstations 313, and a database server 315 coupled by AIS network 317.
  • AIS heavyweight client software
  • the progression to 'thin client' solutions may be slow due to the desire to perform significant data processing of monitored data streams at the client devices (i.e. clinical workstations), and the desire for redundancy of information on the client in the event of a network failure.
  • client devices i.e. clinical workstations
  • redundancy of information on the client in the event of a network failure The usual architectural solutions to this are local database structures, which replicate to the main server.
  • the vendors appear to have spent most of their effort making these complex software systems work reliably in a demanding clinical environment, and they appear to have mostly succeeded.
  • methods of displaying operating room scheduling information can include retrieving scheduling information for scheduled operations in a plurality of operating rooms of a hospital area over a predetermined time period.
  • the scheduling information for the scheduled operations can include a patient identification and a procedure identification.
  • Current status information is retrieved for at least one of the scheduled operations while in progress wherein the current status information is selected from one of a plurality of milestones of a surgical operation.
  • a table of scheduled operations over the predetermined time period is provided for display at a client device wherein for a scheduled operation, the table includes the respective patient identification and procedure identification wherein the table further includes the current status information.
  • methods of retrieving medical information can include retrieving scheduling information for scheduled operations meeting a predefined criteria wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification.
  • a table of all scheduled operations can be provided for display at a client device wherein for each scheduled operation, the table includes the respective patient identification and procedure identification. Selection of one of the patient identifications from the table of scheduled operations meeting the predefined criteria can be accepted, and responsive to accepting selection of the patient identification, at least one case identification corresponding to the patient identification can be retrieved for display at a client device.
  • methods of displaying anesthesia records can include operations performed by data processing systems.
  • a data processing system can accept entry of information identifying a surgical operation wherein the information is entered via a client device in communication with the data processing system.
  • Anesthesia data corresponding to the identified surgical operation can be retrieved, and an anesthesia record can be built using the retrieved anesthesia data.
  • Secure communication of the anesthesia record can be provided to the client device for display of the anesthesia record at the client device.
  • Figure 1 is a diagram illustrating a DAME Anesthesia Information System according to the prior art.
  • Figure 2 is a diagram illustrating an ARKINE Anesthesia Information System according to the prior art.
  • Figure 3 is a diagram illustrating a Saturn Information System according to the prior art.
  • Figure 4 is a diagram illustrating information systems, methods, and computer program products according to embodiments of the present invention.
  • Figure 5 illustrates use of a test server certificate according to embodiments of the present invention.
  • Figure 6 illustrates a Choices page according to embodiments of the present invention.
  • FIG. 7 illustrates the Tomcat application server (open source software from the Jakarta Project, http://jakarta.apache.org) running in a Java Virtual Machine on a server according to embodiments of the present invention.
  • Figure 8 illustrates Tomcat and an Imageserver running in a Java Virtual Machine on a server according to embodiments of the present invention.
  • Figures 9 and 10 illustrate packages associated with ORview according to embodiments of the present invention.
  • Figure 11 illustrates an organization of database connectivity according to embodiments of the present invention.
  • Figure 12 illustrates image processing techniques according to embodiments of the present invention.
  • Figure 13 illustrates pages of information and interrelations therebetween according to embodiments of the present invention.
  • Figure 14 illustrates a Choices page according to embodiments of the present invention.
  • Figure 15 illustrates a Search page according to embodiments of the present invention.
  • Figure 16 illustrates a Search Results page according to embodiments of the present invention.
  • Figure 17 illustrates an Operating Room Status Page according to embodiments of the present invention.
  • Figure 18 illustrates display of "break relief information according to embodiments of the present invention.
  • Figure 19 illustrates operations of generating a user schedule according to embodiments of the present invention.
  • Figure 20 illustrates an Anesthesia Record Page according to embodiments of the present invention.
  • Figures 21 and 22 illustrate event bars according to embodiments of the present invention.
  • Figure 23 illustrates graphical vital signs according to embodiments of the present invention.
  • Figure 24 illustrates operations of generating an anesthesia record page according to embodiments of the present invention.
  • Figure 25 illustrates security features according to embodiments of the present invention.
  • Figure 26 illustrates an authentication schema according to embodiments of the present invention.
  • Figure 27 illustrates a password challenge according to embodiments of the present invention.
  • Figure 28 illustrates a Change Password Page according to embodiments of the present invention.
  • Figure 29 illustrates an audit scheme according to embodiments of the present invention.
  • Figure 30 illustrates organizations of registrations and passwords according to embodiments of the present invention.
  • Figures 31-34 are flow charts illustrating methods, systems, and computer program products according to embodiments of the present invention.
  • Figure 35 is a block diagram illustrating information processing environments according to embodiments of the present invention.
  • Embodiments of the invention can include a set of web-applications which can extend the functionality of anesthesia information systems by adding, in some embodiments, a web "wrapper" around the data collected by these systems.
  • Embodiments of the invention can dramatically increase the availability and derived functionality of the patient information.
  • Embodiments of the invention can provide additions in functionality including a web-based operating room status monitor, a web-based search mechanism for previous anesthesia records and/or a dynamic, graphical web-based representation of real-time and past anesthesia records.
  • Embodiments of the invention can make these functions available on the Internet with a robustness sufficient for production use in a major hospital.
  • embodiments of the invention can act as a hosting service and make records and schedules available for multiple hospitals using various anesthesia information systems. This capability may be limited only by the power of the hardware and the available Internet connection speed.
  • staff can look up anesthesia and postoperative care records from any Internet client in a secure fashion. They can also view the status of running or scheduled cases in their operating room suite from any Internet client, and drill down if desired, for example using HTML links, to view the case in a particular operating room. Security of patient and staff information can be maintained.
  • inventions of the invention may open the market for Anesthesia Information systems. Its advantages of the widespread dissemination of case and schedule information to the anesthesia, nursing, and/or administrative staff inside and/or outside their normal workplace (i.e. at home, in doctor's offices, in break areas, in administrator's offices, etc.), may alone justify the cost of perioperative information systems on the basis of an increase in clinical case awareness for the patient, workplace convenience for clinical staff and a powerful efficiency tool for administrators.
  • Embodiments of the invention can use a middle tier web application server functionally set between the Anesthesia Information System database and the Internet. Requests for information from Internet clients are met by the application server layer, which queries the database, processes the data, draws the graphics and returns HTML pages with embedded images to the original Internet client.
  • Figure 4 illustrates embodiments of the invention in block diagram format.
  • information processing systems can include an application server 411 coupled between a database server 413 of an anesthesia information system and the internet 415 or other wide area network.
  • an anesthesia information system can include a plurality of workstations 421 coupled with a database server 413 over a local area network 425 within a hospital.
  • the application server 411 can retrieve desired data from the database server 413, use the retrieved data to build records and tables for secure distribution over the internet 415 to authorized internet client devices 417.
  • Embodiments of the invention can be used by anyone who needs access to perioperative data. These uses can include:
  • embodiments of the invention can be incorporated as a link in a web-based Medical Information System thus providing a viewable anesthesia record anywhere in the hospital.
  • CDR Common Data Repository
  • Embodiments of the invention can provide an elegant solution that can make the use of scanned images of paper anesthesia records obsolete. There is no need to duplicate the data, because existing data can be viewed in a novel and robust format.
  • Administrators managing Operating Room suites and/or recovery areas and/or patient waiting areas and/or bed control functions can use live status monitors of embodiments of the invention.
  • embodiments of the invention as a status monitor for viewing in coffee rooms or "Big Board" central planning areas.
  • embodiments of the invention can be spread over multiple flat panel displays to provide a status of all the rooms in a suite.
  • Simple database queries can extract cases with poor outcomes or cases that have been otherwise flagged for further analysis.
  • a link to a reference for an anesthetic record can be emailed securely to the hospital's QA committee and risk analysis department.
  • Embodiments of the present invention can also be used to provide hospital inventory control and billing information.
  • Anesthesia Records can be provided to the hospital pharmacy so that drugs used during an operation can be inventoried and billed more accurately.
  • care providers and/or administrators can look up personalized information about their clinical practice using a feature in ORview termed "MyQI".
  • This area can enable users to generate dynamic and active views of data regarding their clinical practice in comparison to that of their peers. This functionality can thus be used to influence clinical practice.
  • Personalized information relating to the practice of a particular physician can be provided.
  • a table of all cases for which a user is listed an having worked on can be generated. Such a table, for example, can include information for each case such as the case information provided in Figure 16.
  • Statistical data can also be provided for a particular physician. For example, a graphical representation can be provided illustrating a number of cases handled by day, week, or month over a designated time period.
  • Comparisons can also be provided between a particular physician and peer physicians. For example, average drug use(s), average cost(s), average or reported event(s), etc. for a physician over a period of time can be compared to a comparable average(s) of peer physicians over the same period of time.
  • ORview A detailed description of system architectures according to embodiments of the invention now will be provided. These detailed embodiments will collectively be referred to as ORview.
  • the ORview welcome page directs users to the various components of ORview.
  • the welcome page resides on a web application server within its Secure Sockets Layer (SSL), so a request for the welcome page is met with an offer of a digital server certificate which must be accepted to continue.
  • SSL Secure Sockets Layer
  • the certificate offers the application server's public key of a paired RSA_5 128 bit encryption key pair. This is 'strong' encryption and provides that from this point the user session will continue over an encrypted link between web-client and web-server.
  • the ORview development software uses a test server certificate from Verisign Inc., so the screen 511 illustrated in Figure 5 can be served suggesting that the key being offered is from an untrusted site and asking if the user would like to accept it. This is normal SSL protocol. Purchasing a production server certificate may allow automatic SSL without this step.
  • the welcome page for the application, orview.jsp can act as a redirector, pointing new users to the registration forms, and transparently pointing established users to the application itself.
  • ORview.jsp and other JSPs in ORview can use JavaServer Pages (JSP) technology from Sun Microsystems, Inc.
  • JSP JavaServer Pages
  • the first clinical page or Choices Page 611 of ORview is "choices.jsp" which can be provided as illustrated in Figure 6.
  • a link to orview.jsp from any web page can initiate the ORview application.
  • Tomcat 3.2 is Sun's endorsed implementation of the Java servlet specification v2.3 and JavaServer Pages (JSP) specification vl.2.
  • JSP JavaServer Pages
  • Tomcat has been configured with its server .xml file to run as a service in Windows NT and to accept SSL connections on port 443, the default port for SSL.
  • Tomcat's insecure default port 8080 has been disabled, plugging insecure access to the middle tier.
  • Tomcat's internal security model uses the Java key store ".keys", and it is here that the server certificate key pair resides.
  • Configuration of Tomcat, or any other commercial application server in this way may be desirable for ORview.
  • ORview is not confined to using Tomcat.
  • Several of the commercial application servers could act as more powerful servlet containers, e.g. Bea's WebLogic server or IBM's WebSphere, but these application servers may be relatively expensive programs costing $5,000 or more. Tomcat should work well enough unless volume gets very high, in which case the investment to
  • ORview can use ImageServer Pro software from Corda Technologies Inc. to render and serve highly interactive graphics in its output, the anesthesia record. Functionally, all the text-based portions of the delivered HTML page are processed by the servlets in Tomcat, while the graphics are processed by ImageServer running on Windows NT server 811 as shown in Figure 8.
  • ImageServer is a pure Java application designed for high volume financial sites with requests for 30,000 to 50,000 images/hour, and is more than capable for the task. Also included are the PopChart Image Server Embedder (PCISE) Java classes from Corda Technologies Inc. which allow direct communication of ORview with the ImageServer, and Popchart.class Java class, which is an HTTP Redirection Adapter allowing images to be served back to the requesting page through Tomcat's Secure Sockets Layer (SSL).
  • PCISE PopChart Image Server Embedder
  • SSL Secure Sockets Layer
  • the ORview web application orview. war, includes the code and associated files to run ORview. At its core are three Java servlets and a collection of JSPs. The servlet classes are contained in a package called orview. ORview includes an XML configuration file called web.xml. The web application contains the following associated files as shown in the screen images 911 and 1011 of Figures 9 and 10. Packages associated with ORview in the "classes" directory include:
  • ORview. war is packaged according to the WC3 specification for a web- application and contains files to run ORview on the application server environment detailed in the previous section.
  • ORview uses two configuration files, server.xml and web.xml.
  • server.xml is the WC3 compliant XML server configuration file for the Tomcat application server. It specifies how Tomcat is to be configured to manage its ports, security, logs and realms as well as other core functions specific to the application server.
  • Web.xml is the XML configuration file for ORview, and is compliant with the WC3 web- application specification. Web.xml serves the following functions:
  • an Orview Windows NT application server 1101 can use any Java DataBase Connectivity (JDBC) 2.0 compliant driver 1111 to connect to a Relational Database Management System (RDBMS) 1113 of an anesthesia information system.
  • JDBC Java DataBase Connectivity
  • RDBMS Relational Database Management System
  • ORview is configured using web.xml to use the Sybase JConnect driver v 5.5 which has the feature of scrollable result set cursors, part of the JDBC 2.0 standard.
  • the Sybase driver is freely distributable and is included in the ORview web application in the com.sybase.* package.
  • the application server can be configured to provide a Java virtual machine 1117 within which Tomcat 1119 operates.
  • ORview The organization of database connectivity in ORview is illustrated in Figure 11.
  • the core Servlets in ORview use SQL query strings 1115 and a pooled connection object to access the database.
  • ORview also uses one stored procedure and 3 functions on the database, which is done at installation using an initial SQL database call.
  • the 4 resident SQL stored procedures and functions are:
  • ORview uses sophisticated image processing techniques to efficiently generate Shockwave FLASH (Macromedia Inc.) images 1209 in the web screens of the anesthesia record 1211 as illustrated in Figure 12.
  • Image generation is managed by a Java software package called ImageServer Pro 1213 from Corda Technologies Inc. The principle of its use is to pass a datastream and a graphic template to an image rendering engine.
  • the image server renders the graphic as a Macromedia Shockwave FLASH vector image and holds it and a reference to it in cached memory 1207 until required.
  • the reference to the cached image on the server is embedded in HyperText Markup Language (HTML) in the served page to the user, and when the Internet Browser parses the embedded image tag, it requests the referenced image from the image server which it then displays. After a fixed period, the image server flushes the cached images from memory.
  • HTML HyperText Markup Language
  • ImageServer Pro is an extremely fast image processing system, capable of rendering and serving images for high volume websites such as the financial Internet portals.
  • the core ImageServer is a Java application which accepts I/O requests on port 81.
  • ORview uses two other features of ImageServer to enable the rapid production of secure images. These other features of ImageServer are :
  • the PCISEmbedder 1215 which is a set of Java classes imported into the core ORview servlets. Their function is to pass the data stream to the ImageServer 1213, set the image generation parameters, incorporate a graphic template binary file (Chartbin) and generate the HTML for the embedded graphic with its reference to the cached image on the image server.
  • a graphic template binary file (Chartbin)
  • HTTP Redirection Adapter is Java class (PopChart.class) which enables images to be redirected from ImageServer's Port 81 to the Secure Sockets Layer (SSL) 1217 on port 443. Unless this is done, a functional distinction exists between the security of text and images served by ORview. The redirection adapter ensures that both these data types are encrypted over the web, and that the management of this is done by Tomcat's SSL.
  • ImageServer Pro need not be on the same physical server, but should be accessible via a URL over the Internet.
  • ImageServer Pro has extensive load-balancing capability and can be scaled up to meet virtually any demand for image generation.
  • ImageServer Pro runs as a service within a Java Virtual Machine 1219 on a Windows NT machine 1221.
  • the PCISEmbedder 1215 and PopChart.class 1223 are contained in the package com.corda.*, and are imported into the ORview application.
  • ImageServer Pro is licensed from Corda per server. Conceivably, a single ImageServer/ ORview application server combination could manage the web page generation and graphics processing of multiple hospitals.
  • ORview may be described with reference to the illustration of Figure 13.
  • a log-in may be required for security purposes using a login screen 1301.
  • the Choices Page 1311 acts as a portal to the ORview application.
  • users are able to request the anesthesia schedule page 1315 by service, by location, a personalized schedule, or initialize a search for anesthesia records pages 1317 for a particular patient using a search page 1319.
  • Either a search page 1319 or anesthesia schedule page 1315 can be used to generate a list of anesthesia records 1321 for a particular patient, and the list of anesthesia records 1321 can be used to generate a desired anesthesia record 1317.
  • the flow of a user-session may include the following features:
  • Links For example, selecting "Cardiac" at the Choices screen and then hitting the "go” button requests the cardiac schedule for the current day and the next day, and a web page is served which shows the cardiac schedule in an active tabular format.
  • the schedule pages contain embedded links, so hitting the link on a particular patient will initiate a search for all anesthetic records associated with that patient, which may include a current running record.
  • a page is then served which shows the list of anesthetic records for a particular patient, again in a active tabular format. Following the links on this page enables the user to drill down to individual anesthetic records.
  • the anesthetic record is displayed as a combination of tabular and interactive graphical elements.
  • ORview has the facility to enable autorefresh of served pages, so the Operating Room schedule pages and Anesthetic records will autorefresh at a user specified time interval to give the impression of a near real-time live view of these elements.
  • Session Management ORview uses a Java session manager class to handle user sessions. BASIC authentication of the user with Username and Password is required before any clinical pages are viewable. The session manager ensures that this authentication is good for the duration of a single user session on their browser, or times out after 120 minutes, whichever is sooner.
  • the Choices Page 1311 for ORview enables the user to select distinct derivatives of information. For example, the following derivatives of information may be selected:
  • the anesthesia schedule by Division, Location or by "In Progress" cases using radio buttons. These are customizable selections by institution according to desired functionality.
  • the "In Progress” option selects all currently running cases. The default date range is for cases from the current date until the next working day, including the spanning of weekends, so it is always possible to see the following working day's schedule using the system.
  • the "Search Old Saturn Records” link initiates the search for all anesthetic records related to a patient.
  • the Search page 1319 can be used to find all anesthetic records associated with a particular Patient.
  • the search is initiated by a user entering the Patient's medical record number (MRN), or unique patient identifier, which could be a Social Security Number (SSN), for example.
  • MRN Patient's medical record number
  • SSN Social Security Number
  • the page passes the MRN as a parameter to the servlet CasesByHxno, which performs a series of JDBC SQL queries on the database and returns an HTML page with the Anesthesia Record Results by patient on it.
  • Other search modalities can be provided, such as searching by patient name, the use of wildcard characters and the use of search logic to search based on combinations of different types of identifying information and/or parts thereof.
  • the Anesthesia Record Search Results page 1321 can display the output of the servlet CasesByHxno (patient names have been removed for confidentiality purposes).
  • the Anesthesia Record Search Results Page has been designed to be a primary method of navigating to a patient's individual anesthetic records and may be a necessary selection step because a patient may have multiple anesthetic encounters recorded in the system. As such, the page should display just enough information for the user to identify a particular anesthesia record that they may wish to drill down further to view.
  • the input parameter string to the servlet can be obtained either from the search page or by following a link from the OR Schedule Page.
  • the input parameter for example, may have a format such as:
  • Anesthesia Record Search Results page can include:
  • Each row represents an individual anesthetic record, and displays a link in the Case ID column to an individual anesthetic record.
  • Case ID a link in the Case ID column to an individual anesthetic record.
  • the other columns display patient demographic information relating to the previous anesthetic encounters, including the surgical procedure and the Attending Anesthesiologist assigned to a case.
  • the Anesthesia Record Search Results Page can also include alerts such as alerts noted during a preoperative screening or note by a health care provider from a previous surgical event.
  • alerts such as alerts noted during a preoperative screening or note by a health care provider from a previous surgical event.
  • an alert icon provided on the Search Results page can provide a link to more information regarding the alert.
  • the Operating Room Status Page 1315 or monitor is a display of the output of the servlet CasesByUser and can be called by accessing the selection choices of the Choices Page 1311.
  • the format of this page is active and tabular, with each row representing an individual anesthetic case, with links to the anesthetic records of an individual patient.
  • the set of cases displayed on this page corresponds to the selection criteria from the Choices page, and may represent all the cases for a particular hospital, the cases for one service, or just those of an individual user, for example. This page can accomplish at least two goals.
  • the Operating Room Status page 1315 can act as a static schedule for planning purposes, and as a status monitor for a group of operating rooms or staff.
  • the Operating Room Status Page 1315 can include:
  • Cases can be sorted by Date, Operating Room and/or Scheduled Case Start time to give the page a standard format of schedules used in many operating room suites.
  • the Case Status column can display the current status of a case depending on the status flag in the database; Preop, In Progress, Complete, Cancelled or Archived. If the case Status is "In Progress", the column element in that row can Blink to highlight that the case is currently active. In this way the user gets an immediate view of the active cases in the Operating Room (OR) suite.
  • the OR Name column displays information about the patient's scheduled and current location based on machine replication settings in the database.
  • the database flags data recorded on particular workstations for a case, so it is possible to track exactly where a patient is at a particular time.
  • the string shown in this column cab be of the following format:
  • the Patient Name, other demographic and case procedure columns reflect these database items for a single case.
  • the database can be populated with this data using an HL7 interface from the Hospital Information System (HIS).
  • HIS Hospital Information System
  • the Last Attending and Last User columns reflect the last Attending to sign in to a case and the last or current user of the case based on user login. These columns thus reflect who should be called to access the caregivers for a case.
  • the Last User column can also provide the feature of an active element looking for data entered by users to reflect their 'break' relie s, i.e. coffee and lunch breaks as shown in segment 1801 of Figure 18.
  • the servlet can also look for database events entered by users to indicate 'breaks' and if found, displays persistently the most recent event and time in the Last User column. In this way, an administrator can see at a glance who has been given 'break relief in a suite of operating rooms. This can be a powerful feature for management of staff, as this may otherwise be a haphazard process involving multiple telephone calls to rooms.
  • Milestone and Time columns display the last entered milestone event and the time it occurred.
  • Milestone events are configured at installation to be those events entered by the clinical user which reflect the time course of a case. As the page autorefreshes, the user can see individual cases 'march' through their milestones, giving an immediate impression of the exact clinical status of the case. This again can be a powerful tool for 'at-a- glance' administration of an operating room suite.
  • Milestones are steps of a surgery occurring in the operating room while the case status is "In Progress", and milestones can include (but are not limited to): patient arrival in preop holding; start of anesthesia care; patient leaves preop holding; patient arrives in OR; anesthesia induction; anesthesia ready; surgical incision; surgical timepoints; aortic crossclamp on; CPB on; aortic crossclamp off; CPB off; surgeon closing wound; end of surgery; anesthesia extubation; patient arrives in PACU (recovery area); end of anesthesia care; and discharge from PACU; or free text entered by a care provider.
  • the Operating Room Status Page can also include one or more alert icons.
  • the alert icon can be used as a link to textual information relating to specific information for one of the patients scheduled for operation.
  • An alert icon for example, can be used to indicate an allergy, an event in a previous operation, an outcome of a previous operation, or any other information that would be useful to know before performing an operation and/or administering anesthesia. More particularly, a preoperative screening can be performed prior to the scheduled operation, information obtained during the preoperative screening can be entered into a screening database, and alert icons can be generated based on information entered into the screening database. In the alternative, events and/or outcomes from anesthesia records of prior operations can be used to generate alert icons on the Operating Room Status Page.
  • the application server can initialize the servlet CasesByUser by request from a browser of a remote client device at block 1901; get user/group parameters at block 1903, and initialize a JDBC connection with a relational database of an anesthesia information system at block 1905.
  • stored SQL procedures are run to retrieve data form the relational database of the anesthesia information system and to build tables of the data for the Status Page.
  • the result set is opened at block 1909, and a table header is built in a row using HTML at blocks 1911 and 1912.
  • the case data is retrieved at block 1915, and an HTML row is built at block 1916.
  • HTML rows Once HTML rows have been built for the header and for all rows, the output HTML is returned to the calling browser of the remote client at block 1917.
  • the Anesthesia Record Page 1317 can display a representation of an anesthetic record using tabular, columnar and interactive graphical formatting of the data. It is the result of the output of the servlet CasesByCaseid and is accessed by following a link from the Anesthetic Record Search Result Page.
  • a rearrangement has been made in the ordering of the major categories of data compared to the classical record.
  • the case events 2001 are placed first after demographics 2003, instead of the case drugs, and the case events section is followed by a graphical display 2005 of the recorded vital signs and event bar.
  • the case drugs 2007 are moved lower in the display after the graphical display.
  • the gases and fluids 2009 and Labs and perioperative totals 2011 can follow the case drugs.
  • This rearrangement reflects a departure from the functionality of the classic anesthetic record, which is optimized for data entry, whereas the web is optimized for data viewing. Putting the case events near the top of the page makes the course of the anesthetic immediately apparent to the clinical user, without having to scroll down to the rest of the case.
  • Another feature of the page is the use of a 'newspaper column' format to compact the data into a relatively short scrollable page, while maintaining readability. Because the 'MULTICOL' HTML command is specific only to Netscape, it was not used, so the columnar formatting in ORview is performed in the servlet using a combination of Java and HTML code.
  • Another feature of the page is its ability to display a "real-time" view of the anesthetic record by using its autorefresh feature.
  • a record autorefreshing every minute is effectively a real time view of the anesthetic or PACU record, so that ORview can be used to remotely monitor live cases over the internet.
  • the graphical representation of the monitored vital sign data is so much more effective than that of most anesthesia information systems, that clinical users may elect to use ORview as a supplement view of case in the operating room as the case is running, using their Anesthesia Information System only for data entry, for which it is optimized.
  • Case Events Here a newspaper column format is used to display 2 columns of the events associated with the case. The Columns resize to match the quantity of data.
  • the Monitored Vital Sign Graphic This feature of ORview is the output of the ImageServer software as described in a previous section.
  • the PopChart Image Server Embedder (PCISE) inserts an HTML reference to an image at this point in the page, and the web browser loads the image.
  • the image is of Macromedia Shockwave Flash format, a vector graphic format which has excellent printing, rapid rendering, small size and interactivity as some of its properties.
  • the web-browser uses the Shockwave Flash Plug-in, for which a download reference is included in the embedded HTML, and which generally is included by default in all current major Browser installations.
  • the 3D Event Bar is a representation of Events and Drugs in the perioperative record charted as a symbol 2103 against time at the point of the event. Multiple events in the same minute period are depicted by a vertical step in the y-axis, so that none of the symbols in a group are hidden by surrounding symbols.
  • the third dimension to this feature is that the text events themselves are pop-up labels 2105 associated with the symbols, viewable by touching the symbols 2103 as a hot-spot, as shown in Figure 22.
  • ORview is able to represent a great deal of data in compact format, such that the entire record for a complex case can be squeezed into a graphic across a single screen and yet still allow the event and drug time course to be clear.
  • This can be a great advantage of ORview over traditional Anesthesia Information Systems, which are generally optimized for data entry and whose graphical representation of vital signs and drugs may often span several pages to the detriment of the overall view of the case. This is another reason why ORview may become preferred for reviewing anesthetic case data.
  • the chart 2301 of Figure 23 illustrates this by showing how ORview represents the trended vital signs data from a 16 hour case.
  • the Labs and Totals Display follows the Gases and Fluids Display of Figure 20. Three columns are used, but these are no longer newspaper columns as the data is of three different types. For drug and fluid totals, a simple descending list is used. For Labs, a complex list structure is displayed, with all the labs associated with a single time period concatenated into a string in a format very familiar to anesthesia staff.
  • the application server can initialize the servlet CasesByCaselD in response to a request from a browser of an authorized client device at block 2401.
  • the CaselD parameters can be obtained at block 2403, and the JDBC connection with the database server of the anesthesia information system can be initialized at block 2405.
  • the case demographics, case staff, case procedures, and case events can be obtained from the AIS database server at blocks 2407, 2409, 2411, and 2413, and organized into scrollable results sets at block 2415.
  • the demographics and Events columns are built in an HTML format as shown at blocks 2417 and 2419.
  • Vital signs are requested and retrieved at blocks 2423 and 2425, and loaded into the PCISEemedder at block 2427.
  • the PCIS script including the vital signs is built using the image server to provide an embedded HTML image reference as shown at blocks 2429, 2431, and 2433. Totals for drugs, gases and fluids, and labs and perioperative are obtained at blocks 2435 and 2437, and a scrollable result set is built according to the HTML format as illustrated at blocks 2439 and 2441.
  • the HTML output for the completed anestliesia record page is returned to the browser of the requesting client device.
  • Security and the maintenance of patient confidentiality can be an element of ORview.
  • the security features of ORview can include up to three or more components :-
  • TDS Tabular Data Stream
  • This is moderately indecipherable, but can be read.
  • the application server and database server can be on the same intranet, so the TDS datastream can be no more vulnerable than any other text-based messaging system carrying patient data, such as HL7.
  • the TDS vulnerability may become important if ORview is configured to access a remote database.
  • strong encrypted JDBC solutions exist, using JDBC type 3 drivers which utilize a middle tier datasource on the server and which encrypts the JDBC data interchange.
  • a solution may be offered by IDS as discussed at ht ⁇ ://www.idssoftware.corn/jdbcdrv.html.
  • ORview can be configured for encrypted JDBC in the circumstance of serving schedules and anesthetic records to multiple hospitals over the Internet, and accessing multiple remote databases.
  • a block diagram 2501 of security structures according to embodiments of the present invention are illustrated, for example, in Figure 25.
  • ORview can use the BASIC authentication (user/password) schema, administered using Tomcat's security realm model. This authentication can involve setting up a database of users with the data model illustrated in Figure 26.
  • the user realm for ORview is maintained in a separate Sybase Adaptive Server Anywhere database which manages the user rights to a single hospital's users.
  • the settings for the realm are made on Tomcat's server.xml file. Multiple realms are possible for ORview, governing multiple different hospitals' security models.
  • the modus operandi of BASIC authentication is a password challenge, as shown in the screen 2701 of Figure 27.
  • Tomcat may not provide a way of administering user names and passwords, so this mechanism can be built-in to ORview.
  • Users can be assigned a username and password upon request by the system administrator. This effectively creates a userjtiame, userjpassword, and user_role in the user database. Users are assigned a starter password like "welcome" and then asked to change it on first login.
  • ORview provides a "Change Password Page" 2801 as shown in Figure 28 which enables the user to change their password in a valid manner.
  • the output of this page is sent to a servlet, orview.changepswd which administers and updates the fields in the user database.
  • Successful attempts to change password lead the user back to the main Welcome Page of ORview.
  • Unsuccessful attempts to change a password are met with an error message, and the requirement to try again.
  • the onus then becomes one of auditing the audit table.
  • statistical analysis of the audit table should rapidly show any inappropriate use, whilst providing an audit trail of individual accesses.
  • Embodiments of the invention can also use sophisticated user management schemas to organize registration and passwords.
  • the diagram of Figure 30 illustrates the password schema of ORview, which makes extensive use of Java Server Pages (JSP) technology.
  • JSP Java Server Pages
  • a new user can be assigned a temporary user name and password, and the temporary user name and password can be provided by the system administrator via e-mail.
  • the user enters the appropriate username and password, either permanent if an existing user or temporary if a new user.
  • the application server determines if the username and password are authorized as an existing user, normal system access is allowed by providing the Choices Page 3005. If the username and password are authorized as a new user, a registration process is initiated at block 3007. If the registration process is successfully completed at block 3009, a permanent username and password are assigned to the new user at block 3011, the permanent username and password are stored in the SQL user database 3013, and the user can be prompted to login with the permanent password at 3001.
  • Figure 30 also shows that the Choices Page can be used to initiate a change of password for an existing user. If a password change is requested at the Choices Page 3005, the password change procedure can be performed at block 3015. In particular, the user can select a new password, the new password can be saved in the SQL user database, and the user can be presented with the login request 3001 to login with the new password.
  • Embodiments of the invention can exploit the power of the Internet in the perioperative environment.
  • Embodiments of the invention can include, among other things, one or more of the following:
  • a Live Web-Based operating room and perioperative suite Status Monitor that can be served robustly using data encryption and thereby opening the medium of the Internet to this practical clinical use.
  • middle tier Java servlet and JavaServer Pages technology running on an Application Server to generate an Anesthetic Record and Perioperative Schedule.
  • various terms used in this disclosure are further defined as indicated below:
  • Anesthesia Information Systems are computer systems which record and display data gathered in the perioperative period. Data is either input by anesthesia, clerical or nursing staff directly into the system, or is automatically acquired from patient monitoring devices.
  • the perioperative period is the interval of time associated with a single surgical encounter, from the time of the decision to take a patient to surgery until the discharge of the patient home from hospital. This definition could also include outcome data gathered from the patient after discharge with respect to the associated surgical encounter.
  • JDBC is the abbreviation for Java Data Base Connectivity.
  • a JDBC driver is a set of Java classes that manage connectivity to a database. ORview uses the Sybase JConnect driver, but is configurable to use any JDBC driver to any JDBC 2.0 enabled database (all the main RDBMs)
  • CDR is the abbreviation for Common Data Repository, a hospital database that aspires to collect all patient related data.
  • a CDR is uaually heavily interfaced to other hospital information systems, which send it their data. Usually this consists of lab tests, clime notes, EKG reports and the like.
  • a CDR usually has an associated front-end "browser" application which acts as a patient-centric window on the data.
  • embodiments of the present invention relate to providing scheduling information and/or medical records relating to surgical care.
  • the present invention may be embodied as methods, data processing systems, and/or computer program products. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects.
  • the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium. Any suitable computer readable medium may be utilized including, but not limited to, hard disks, CD-ROMs, optical storage devices, and magnetic storage devices.
  • Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as JAVA®, Smalltalk or C++.
  • the computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as "C", or in various other programming languages.
  • Software embodiments of the present invention do not depend on implementation with a particular programming language.
  • portions of program code may execute entirely on one or more data processing systems.
  • client/server is a model for a relationship between two computer programs in which one program, the client program, makes a service request from another program, the server program, which fulfills the request.
  • a Web browser is a client program that requests services (the sending of Web pages or files) from a Web server (which technically is called a Hypertext Transport Protocol or HTTP server) in another computer somewhere on the Internet.
  • An implementation of the present invention may use the Application Service Provider (ASP) model.
  • ASP Application Service Provider
  • an ASP is an entity that offers individuals and enterprises access over the Internet (or other communications network) to applications and related services that would otherwise have to be located in local computers and/or devices.
  • client/server environments may include public communications networks, such as the Internet, and private communications networks often referred to as “intranets” and “extranets.”
  • Internet shall incorporate the terms “intranet” and “extranet” and any references to the Internet shall be understood to mean a communications network of any type, including intranets and/or extranets.
  • Embodiments of the present invention can be used to provide a status monitor for a suite of operating rooms according to the operations illustrated in Figure 31 to provide a status monitor display such as that illustrated in Figure 17.
  • operation scheduling information can be retrieved at block 3101. More particularly, the operation scheduling information can be retrieved for scheduled operations in a plurality of operating rooms in a designated hospital area over a predetermined time period, and the scheduling information can include a patient identification and a procedure identification. For example, operation scheduling information can be retrieved for operations scheduled in one or more of a plurality of areas such as those areas identified in Figure 14 for a particular day.
  • the scheduling information can thus provide information for fields of the columns of Figure 17 labeled "Division”, “Date”, “Pt Name” (patient name), “PtHxNo” (patient history number), "Age”, and/or "Procedure”.
  • the scheduling information can be retrieved from a scheduling database.
  • current status information can be retrieved for scheduled operations while scheduled operations are in progress, and the current status information can be selected from one of a plurality of milestones of a surgical operation.
  • the current status information can thus provide information for the fields of column of Figure 17 labeled "Milestones".
  • a status monitor can provide near real-time information.
  • the current status information can be retrieved from data entered into electronic data entry systems in the respective operating rooms.
  • the current status information for example, can be retrieved from data entered into anesthesia information system workstations.
  • a table of scheduled operations over the predetermined time period can be built at block 3105.
  • the table can include respective patient and procedure identifications.
  • the patient identification for example, can be a patient name and/or a patient history number shown in Figure 17 as the columns labeled "Pt Name" and "PtHxNo".
  • the table can also include the current status information such as the information shown in the column of Figure 17 labeled "Milestones" and times the respective "Milestones" were entered.
  • the information of the table can be displayed at block 3107.
  • Scheduling information can thus be entered into an electronic scheduling system such that no additional scheduling information is entered for a particular day after some cut off time before the first scheduled operation that day.
  • the cut off time may be defined as being some time before the end of working hours the previous business day.
  • the schedule for a given day can be set after the cut off the day before.
  • the previously entered scheduling information can then be used as a base of information for the operating room status monitor during the day.
  • This scheduling information can then be updated during the day in near real-time with data entered by surgical staff during surgery into workstations in the operating rooms so that the status monitor can be used to manage a plurality of operating rooms in near real-time.
  • Current status information for example, may be updated once a minute.
  • the status monitor can maintain the display.
  • any new current status information can be retrieved at block 3103.
  • the table can be rebuilt including any new current status information at block 3105, and the updated table can be displayed at block 3107.
  • Refresh can be initiated at block 3111 periodically, such as at one minute intervals, and the refresh interval can be programmed by a user. Alternately, refresh can be initiated at block 3111 when it is detected that new current status information is available. In addition, refresh can be initiated at block 3111 in response to a user request for refresh.
  • a plurality of operating rooms can be equipped with a respective electronic data entry system wherein retrieving current status information can include retrieving current status information entered into the respective electronic data entry system.
  • one or more of the data entry systems can be an anesthesia information system workstation.
  • the hospital area can also include a plurality of preoperative preparation areas and postoperative recovery areas and wherein the operating rooms, preoperative preparation areas, and postoperative recovery areas is equipped with a respective electronic data entry system.
  • retrieving current status information at block 3103 can include retrieving current status information entered into the respective electronic data entry system in one or more of the operating rooms, preoperative preparation areas, and/or postoperative recovery areas.
  • the scheduling information retrieved at block 3101 and the table for each of the scheduled operations can also include at least one of an operating room identification (can be displayed under "OR Name” in Figure 17), a scheduled start time (can be displayed under "Case Status” in Figure 17), an assigned physician (can be displayed under "Last Attending” and/or “Last User” of Figure 17), and a patient age (can be displayed under "Age” in Figure 17).
  • the patient identification for each scheduled operation can include at least one of a patient name (can be displayed under "Pt Name” in Figure 17) and a patient identification number (can be displayed under "PtHxNo" in Figure 17).
  • the current status information retrieved at block 3103 can include a surgical event (can be displayed under "Milestone” in Figure 17) and a time of the surgical event (can be displayed under "Time” in Figure 17).
  • the status monitor of Figures 17 and 31 can be used by a physician to obtain additional information regarding a surgical operation scheduled to be performed. For example, selection of a patient identification from the table of scheduled operations can be accepted. The selection of a patient identification, for example, can be entered by a user using a mouse or roller ball coupled with a screen displaying the table of scheduled operations, using a touch sensitive surface of the screen displaying the table of scheduled operations, a keypad, or other input means known to those having skill in the art.
  • a case identification can be a unique identification of a surgical operation performed, so that a different case identification is assigned to every surgical operation performed in a hospital, and so that a patient may have multiple case numbers associated therewith if multiple surgical operations have been performed in that hospital on that patient.
  • a patient identification such as "PtHxNo" of Figure 17 and/or "HxNo” of Figure 16
  • the case identification such as "Case ID” of Figure 16
  • selection of one patient identification from a displayed table of scheduled operations may result in retrieving and displaying a plurality of case identifications (such as that illustrated in Figure 16). Selection of one of the plurality of case identifications can then be accepted from a user.
  • user input can be provided using a mouse and/or roller ball coupled with a screen displaying the plurality of case identifications, using a touch sensitive surface of a screen displaying the plurality of case identifications, or using other input means known to those having skill in the art.
  • a medical record corresponding to the selected case identification for the selected patient identification can be retrieved and displayed.
  • Retrieving the medical record can include retrieving data making up the medical record from a relational database and building a file of data for the medical record as opposed to retrieving a scanned image of a record.
  • the medical record can be an anesthesia record, and the anesthesia record can include a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
  • the anesthesia can have the format and additional information illustrated in Figure 20.
  • scheduling information can be retrieved for all scheduled operations meeting predefined criteria at block 3201, wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification.
  • the patient identification can include at least one of a patient name and a patient identification number
  • the scheduling information can additionally include at least one of an operating room identification, a scheduled start time, an assigned physician, and a patient age.
  • a table of all scheduled operations can be built at block 3203, wherein for a respective scheduled operation, the table includes the respective patient identification and procedure identification, and the table can be displayed at block 3205.
  • the predefined criteria can be defined by the user as all operations scheduled for a particular physician on a given day. Accordingly, the table and display can include information such as that illustrated in Figure 17 but only for cases scheduled for the selected physician. Alternately, the predetermined criteria can be defined by the user as all operations scheduled for a particular area of the hospital on a given day. Moreover, other criteria and or other time periods may be used.
  • the display can be maintained at block 3207 until a user selection is made.
  • Selection of one of the patient identifications can be accepted from the table of all scheduled operations meeting the predefined criteria at block 3209, and responsive to accepting selection of the patient identification, at least one case identification corresponding to the patient identification can be retrieved at block 3211.
  • User selection can be input through a mouse or roller ball coupled to a screen displaying the table, through a touch sensitive surface of a screen displaying the table, or through other means known to those having skill in the art.
  • the at least one case identification corresponding to the patient identification can then be displayed at block 3213 to provide a display such as that illustrated in Figure 16. As discussed above, each case identification identifies a different surgical operation performed on the patient.
  • Embodiments of the present invention can thus allow a physician to efficiently generate a schedule of the physician's assigned operations for a defined time period, and then generate a list of previous operations for a patient listed on the schedule.
  • the list of previous operations may be useful to the physician in preparing for a particular operation.
  • case identifications are displayed for a patient
  • embodiments of the present invention allow the physician to obtain medical records such as anesthesia records for the different previously performed operations. Information included in these medical records may be useful in preparation for the scheduled operation.
  • table of case identifications can be maintained at block 3215 until a user selection of a case identification is made. Selection of one of the case identifications can be accepted and a medical record corresponding to the selected case identification for the selected patient identification can be retrieved at block 3217 and displayed at block 3219.
  • the medical record can be an anesthesia record
  • the anesthesia record can include a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
  • the medical record may be displayed until there is use selection at block 3221 of the previously displayed case identifications. If the user selects to return to the previously displayed case identifications, the case identifications can be displayed at block 3213, and the user can select a different one of the case identifications at block 3215 for retrieval and display of a new medical record at blocks 3217 and 3219. Accordingly, a physician can efficiently view different medical records for a patient in preparation for an operation.
  • the user may select at block 3223 to return to the previously displayed table of scheduled operations at block 3205.
  • a selection and acceptance of a new patient identification from the previously generated table can thus be made at blocks 3207 and 3209, and new case identifications corresponding to the new patient identification can be retrieved and displayed at blocks 3211 and 3213.
  • Medical records corresponding to the new case identifications can be selected, retrieved, and displayed as discussed above with respect to blocks 3215, 3217, 3219, and 3221.
  • a physician can efficiently review medical records from prior operations for different patients scheduled for different operations.
  • a user can select new schedule criteria at block 3225 so that different scheduling information is retrieved at block 3201.
  • a physician for example, may first retrieve scheduling information for the next day as discussed above. After reviewing the schedule, prior related case identifications, and prior related medical records, the physician may choose at block 3225 to retrieve scheduling information for another day.
  • a supervising physician may choose to generated different schedules for the same day for different physicians be supervised.
  • alerts from pre-operative screenings corresponding to a patient identification included in the table of scheduled operations can also be retrieved. Moreover, these alerts can be included in and displayed with the table of scheduled operations meeting the predefined criteria.
  • the displayed alert may be an alert icon providing a link to additional textual information. For example, a preoperative screening may be performed a week before the operation, and a particular allergy or other useful information may be uncovered at that time. This information may be entered into a preoperative screening database such that the step of retrieving scheduling information at block 3201 includes retrieving alerts from the preoperative screening database. Identification of and access to these alerts may further enhance the physician's ability to prepare for scheduled operations.
  • Additional embodiments of the present invention can be used to display anesthesia records according to operations illustrated in Figure 33 to provide an anesthesia record such as that illustrated in Figure 20.
  • the anesthesia records can be displayed using a data processing system at a terminal remote from the data processing system.
  • entry of information identifying a surgical operation can be accepted at block 3301 wherein the information is entered via a client device in communication with the data processing system.
  • Anesthesia data corresponding to the identified surgical operation can be retrieved at block 3303, and an anesthesia record can be built at block 3305 using the retrieved anesthesia data.
  • Secure communication of the anesthesia record to the client device can be provided at block 3307 for display of the anesthesia record at the client device.
  • the anesthesia data can be retrieved from a database (such as a relational database) generated by an anesthesia information system including workstations in respective operating rooms for data input by surgical staff during operations.
  • a database such as a relational database
  • Each field of the anesthesia record to be built can be populated by retrieving a corresponding field from the database.
  • anesthesia record can be built by retrieving a plurality of data fields from a database.
  • the database can be separate from the data processing system used to build the anesthesia record.
  • the client device can be a terminal such as a personal computer remote from the data processing system wherein the client device and data processing system are coupled by a network such as the internet.
  • a network such as the internet.
  • the confidential anesthesia record can be obtained remotely over an unsecured network such as the internet.
  • the secure communication can be provided using encryption as discussed above.
  • the resulting anesthesia record can include a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation, and the anesthesia record can have a format such as that illustrated in Figure 20.
  • the anesthesia record can be built and communicated while the identified surgical operation is in progress. Accordingly, the progress of a surgical operation can be viewed at a client device remote from the operation while the operation is taking place in near real-time, for example, to provide consultation from a remote location.
  • the updated data can be retrieved at block 3303, the anesthesia record can be built with the new data 3305, and the anesthesia record can be securely communicated at block 3307 for display of the updated anesthesia record at the client device.
  • Updated information for the anesthesia record can be provided at block 3309, for example, at predetermined time intervals that can be designated by the user, such as once a minute. Alternately, updated information can be provided when updated information is made available or on user request.
  • a new anesthesia record may be selected such that operations of blocks 3301, 3303, 3305, and 3307 are repeated for the new anesthesia record.
  • the anesthesia record can include a graphical representation of events occurring during the identified surgical operation for display at the client device.
  • the graphical representation can include a time line divided into predetermined units of time with a plurality of events occurring during a period of time represented by a single unit on the time line being represented by respective discreet and distinguishable event icons as illustrated, for example, in Figures 21 and 22.
  • user selection of one of the discrete and distinguishable icons can be accepted, and responsive to accepting selection of one of the discreet and distinguishable event icons, text identifying the event corresponding to the selected discreet event icon can be provided for display at the client device as illustrated, for example, in Figure 22.
  • Accepting entry of information identifying a surgical operation at block 3301 can include accepting entry of any information sufficient to identify the surgical operation.
  • entry of a patient identification such as a patent name or patient identification number may be used to identify the anesthesia record.
  • entry of a case identification may be used to identify the anesthesia record.
  • any of the operations discussed above with regard to Figure 32 may be used to identify a particular anesthesia record.
  • a boolean search may be used to identify a particular anesthesia record.
  • a user can access medical information such as anesthesia records and/or surgical operation schedules using a remote client device coupled to an application server over a network such as the internet.
  • a log-in may be required by the application server at block 3401, so that access is only provided if an authorized combination of username and password are entered at the client device.
  • the application server can provide a choices page at block 3403 for display at the client device.
  • a choices page such at that illustrated in Figure 14 can be used providing a choice of a search of anesthesia records or a choice of schedules for different hospital areas or physicians. Other choices may also be provided.
  • the application server can proceed to accept user input of search criteria at block 3421. Alternately, if the user selects schedules at block 3407, the application server can proceed to accept user input of schedule criteria at block 3441.
  • the application server can generate a list of anesthesia records matching the search criteria at block 3423 for display at the client device.
  • the list of anesthesia records can be generated and displayed, for example, using the format of Figure 16 wherein a case identification ("Case ID") identifies each of the anesthesia records.
  • the user may then select one of the anesthesia records, and on accepting the user selection at block 3425, the anesthesia record can be generated at block 3471. Otherwise, the user may elect a new search at block 3427, or the user may elect to go back to the choices page at block 3429.
  • Generation of the anesthesia record at block 3471 can be performed as discussed above with respect to Figure 33.
  • the user may elect to go back to the previously generated list of anesthesia records and select another anesthesia record for display.
  • the user may elect to go back to the previously generated list of anesthesia records at block 3423.
  • Another record may be selected at block 3425, a new search may be selected at block 3427, or the user can select at block 3429 to go back to the choices page at block 3403.
  • the application server can proceed with accepting user input of schedule criteria. Moreover, the selection of scheduling and the particular scheduling criteria may be provide in a single operation such as illustrated in the Choices Page of Figure 14.
  • a schedule is then generated based on the schedule criteria at block 3443 for display at the client device.
  • the schedule can be generated and displayed according to the format illustrated in Figure 17. Moreover, the operation of generating a schedule of block 3443 can be the same as that discussed above with regard to the operations of Figure 31.
  • the user can then select a patient identification from the displayed schedule at block 3445, and a list of anesthesia records can be generated for display at the client device according to a format such as that illustrated in Figure 16.
  • the anesthesia record can be generated at block 3471 for display at the client device according to a format such as that illustrated in Figure 20. If a patient is not selected at block 3445, the user may elect at block 3453 a new schedule based on new criteria to be input at block 3441, or the user may elect at block 3455 to go back to the choices page at block 3403. If an anesthesia record is not selected at block 3447, the user may elect at block 3449 selection of a new patient from the schedule, selection of new schedule criteria at block 3451, or at block 3455 to return to the choices page.
  • anesthesia record is generated at block 3473 responsive to user selection of information from a schedule
  • the user may elect at block 3473 generation of the schedule at block 3443 for display on the client device.
  • the user can then select the same or a different patient and/or record.
  • the operations of blocks 3443, 3445, and 3447, and 3471 can be the same as operations discussed above in greater detail with regard to Figure 32.
  • FIG. 31-34 can be performed by an application server 3501 in communication with a client device 3503 over a network 3505 such as the internet.
  • User input can be provided thought the client device 3503 and network 3505 to the application server 3501.
  • User input can be provided using a touch sensitive screen of the client device, using a mouse or roller ball coupled with the client device, using a keyboard at the client device, and/or using other means know to those having skill in the art.
  • the application server 3501 can obtain data from database servers of one or more information systems such as an anesthesia information system 3507, a hospital scheduling system 3509, and/or a preoperative screening system 3511.
  • Data used to build an anesthesia record can be obtained from a database server of anesthesia information system 3507 including anesthesia workstations in operating rooms.
  • Data used to build schedules can be obtained from a database server of hospital scheduling system 3509, and data used to provide alerts can be obtained from a database server of a preoperative screening system 3511.
  • Methods, systems, and computer program products according to embodiments of the present invention can thus be implemented separate from other hospital information systems such that only a data connection to the other hospital information systems is required.
  • methods, systems, and computer program products according to embodiments of the present invention can be integrated in whole or in part with one or more hospital systems.
  • methods, systems, and computer program products according to embodiments of the present invention can be integrated in whole or in part with an anesthesia information system such as the Saturn Information System produced by Draeger.
  • embodiments of the present invention have been discussed, by way of example, with reference to anesthesia records. Embodiments of the present invention, however, may be applied to other medical records. For example, embodiments of the present invention may be used with Intensive Care Unit (ICU) records.
  • ICU Intensive Care Unit

Abstract

Methods of displaying operation scheduling information can include retrieving scheduling information for scheduled operations in a plurality of operating rooms (1315) of a hospital area over a predetermined time period. The scheduling information for the scheduled operations can include a patient identification and a procedure identification. Current status information is retrieved for at least one of the scheduled operations while in progress wherein the current status information is selected from one of a plurality of milestones of a surgical operation while in progress. A table of scheduled operations over the predetermined time period is provided for display (1317) at a client device wherein for a respective scheduled operation, the table includes the respective patient identification (1321) and procedure identification wherein the table further includes the current status information. Related methods, systems, and computer program products are also discussed.

Description

METHODS OF PROVIDING MEDICAL INFORMATION AND RELATED SYSTEMS AND COMPUTER PROGRAM PRODUCTS
RELATED APPLICATIONS
The present application claims priority from U.S. Provisional Application No. 60/322,865 filed September 17, 2001, entitled "A Web-Based Operating Room Status-Monitor And Anesthesia". The disclosure of U.S. Provisional Application No. 60/322,865 is hereby incorporated herein in its entirety by reference.
FIELD OF THE INVENTION
The present invention relates to methods, systems, and computer program products for information processing.
BACKGROUND
Only about five percent of hospitals in the US routinely use an anesthesia information system for recording an anesthetic record, despite that fact that the practice of anesthesia, with its highly structured data, lends itself well to these systems. One reason for this is financial, as yet there appear to be few clear indications of a significant return on investment for these systems, which tend to be expensive. There may also be controversy surrounding the clinical benefits of these systems, with some anesthesia staff reluctant to invest in systems because of entrenched attitudes to a "spy-in-the-cab", because they would like control over the recording of automated data for a case, and/or because, they fear the recording of "the ugly truth". The main vendors have made little progress in penetrating this market over the past 10 years for these and/or other reasons.
Anesthesia Information Systems (AIS) have evolved significantly since the 1st generation Duke Automated Monitoring Equipment (DAME) system in 1972. Initially they were simple recording devices using the hardware available at the time, which tended to be large and/or unreliable. User input to the DAME was by keyboard and bar codes. A diagram of a first generation DAME system is illustrated in Figure 1. As shown, the DAME system included one or more monitoring carts 101, a data manager 103, and a printer 105 coupled through a DMXNET Network 107. Each monitoring cart 101 could include a DEC LSI-11/02 microcomputer and a barcode reader. The data manager could include a DEC PDP-11/23 minicomputer, a 5Mb hard drive, 256K RAM, and a custom built operating system.
The second generation of AIS was based on PC technology, with more reliable operating systems, software and hardware. The Arkive AIS was an example of this, and the largest installation of this type anywhere in the world was believed to be at Duke University Medical Center in Durham, North Carolina. A diagram of the Arkive system is illustrated in Figure 2. User input was by touch screen plasma display. These were file serving, networked systems with rudimentary Paradox or Access databases usually running on a Novell platform. As shown in Figure 2, an Arkive system could include a plurality of workstations 201, a Novel network file server 203, a plurality of network printers 205, a mirrored database 207, and data storage 209, coupled by network 211.
The third generation of AIS is that of the current installed base. Two tier or three tier client/server systems now use robust relational databases such as Microsoft SQL Server, Sybase Adaptive Server, or the like. The client applications are usually 'fat' in that a great deal of processing is done on the client, usually because of the requirement to handle monitored data streams from equipment attached to the patient. Systems from Draeger Medical Inc., Philips Medical Systems Inc., GE, Surgical Information Systems Inc., and PICIS Inc. generally have this architecture at their heart. The Draeger system, referred to as the Saturn Information System or "Saturn", is illustrated in Figure 3. As shown in Figure 3, the Saturn Information System can include a plurality of clinical workstations 311, a plurality of non-clinical workstations 313, and a database server 315 coupled by AIS network 317.
The current generation of AIS generally uses heavyweight client software ("fat client") on dedicated workstations. The progression to 'thin client' solutions may be slow due to the desire to perform significant data processing of monitored data streams at the client devices (i.e. clinical workstations), and the desire for redundancy of information on the client in the event of a network failure. The usual architectural solutions to this are local database structures, which replicate to the main server. The vendors appear to have spent most of their effort making these complex software systems work reliably in a demanding clinical environment, and they appear to have mostly succeeded. SUMMARY
According to embodiments of the present invention, methods of displaying operating room scheduling information can include retrieving scheduling information for scheduled operations in a plurality of operating rooms of a hospital area over a predetermined time period. The scheduling information for the scheduled operations can include a patient identification and a procedure identification. Current status information is retrieved for at least one of the scheduled operations while in progress wherein the current status information is selected from one of a plurality of milestones of a surgical operation. A table of scheduled operations over the predetermined time period is provided for display at a client device wherein for a scheduled operation, the table includes the respective patient identification and procedure identification wherein the table further includes the current status information.
According to additional embodiments of the present invention, methods of retrieving medical information can include retrieving scheduling information for scheduled operations meeting a predefined criteria wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification. A table of all scheduled operations can be provided for display at a client device wherein for each scheduled operation, the table includes the respective patient identification and procedure identification. Selection of one of the patient identifications from the table of scheduled operations meeting the predefined criteria can be accepted, and responsive to accepting selection of the patient identification, at least one case identification corresponding to the patient identification can be retrieved for display at a client device.
According to yet additional embodiments of the present invention, methods of displaying anesthesia records can include operations performed by data processing systems. In particular, a data processing system can accept entry of information identifying a surgical operation wherein the information is entered via a client device in communication with the data processing system. Anesthesia data corresponding to the identified surgical operation can be retrieved, and an anesthesia record can be built using the retrieved anesthesia data. Secure communication of the anesthesia record can be provided to the client device for display of the anesthesia record at the client device.
BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a diagram illustrating a DAME Anesthesia Information System according to the prior art.
Figure 2 is a diagram illustrating an ARKINE Anesthesia Information System according to the prior art.
Figure 3 is a diagram illustrating a Saturn Information System according to the prior art.
Figure 4 is a diagram illustrating information systems, methods, and computer program products according to embodiments of the present invention.
Figure 5 illustrates use of a test server certificate according to embodiments of the present invention.
Figure 6 illustrates a Choices page according to embodiments of the present invention.
Figure 7 illustrates the Tomcat application server (open source software from the Jakarta Project, http://jakarta.apache.org) running in a Java Virtual Machine on a server according to embodiments of the present invention.
Figure 8 illustrates Tomcat and an Imageserver running in a Java Virtual Machine on a server according to embodiments of the present invention.
Figures 9 and 10 illustrate packages associated with ORview according to embodiments of the present invention.
Figure 11 illustrates an organization of database connectivity according to embodiments of the present invention.
Figure 12 illustrates image processing techniques according to embodiments of the present invention.
Figure 13 illustrates pages of information and interrelations therebetween according to embodiments of the present invention.
Figure 14 illustrates a Choices page according to embodiments of the present invention.
Figure 15 illustrates a Search page according to embodiments of the present invention.
Figure 16 illustrates a Search Results page according to embodiments of the present invention.
Figure 17 illustrates an Operating Room Status Page according to embodiments of the present invention. Figure 18 illustrates display of "break relief information according to embodiments of the present invention.
Figure 19 illustrates operations of generating a user schedule according to embodiments of the present invention.
Figure 20 illustrates an Anesthesia Record Page according to embodiments of the present invention.
Figures 21 and 22 illustrate event bars according to embodiments of the present invention.
Figure 23 illustrates graphical vital signs according to embodiments of the present invention.
Figure 24 illustrates operations of generating an anesthesia record page according to embodiments of the present invention.
Figure 25 illustrates security features according to embodiments of the present invention.
Figure 26 illustrates an authentication schema according to embodiments of the present invention.
Figure 27 illustrates a password challenge according to embodiments of the present invention.
Figure 28 illustrates a Change Password Page according to embodiments of the present invention.
Figure 29 illustrates an audit scheme according to embodiments of the present invention.
Figure 30 illustrates organizations of registrations and passwords according to embodiments of the present invention.
Figures 31-34 are flow charts illustrating methods, systems, and computer program products according to embodiments of the present invention.
Figure 35 is a block diagram illustrating information processing environments according to embodiments of the present invention.
DETAILED DESCRIPTION
The present invention now is described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
Embodiments of the invention can include a set of web-applications which can extend the functionality of anesthesia information systems by adding, in some embodiments, a web "wrapper" around the data collected by these systems. Embodiments of the invention can dramatically increase the availability and derived functionality of the patient information. Embodiments of the invention can provide additions in functionality including a web-based operating room status monitor, a web-based search mechanism for previous anesthesia records and/or a dynamic, graphical web-based representation of real-time and past anesthesia records. Embodiments of the invention can make these functions available on the Internet with a robustness sufficient for production use in a major hospital. Moreover, embodiments of the invention can act as a hosting service and make records and schedules available for multiple hospitals using various anesthesia information systems. This capability may be limited only by the power of the hardware and the available Internet connection speed.
Using embodiments of the invention, staff can look up anesthesia and postoperative care records from any Internet client in a secure fashion. They can also view the status of running or scheduled cases in their operating room suite from any Internet client, and drill down if desired, for example using HTML links, to view the case in a particular operating room. Security of patient and staff information can be maintained.
The increase in functionality offered by embodiments of the invention may open the market for Anesthesia Information systems. Its advantages of the widespread dissemination of case and schedule information to the anesthesia, nursing, and/or administrative staff inside and/or outside their normal workplace (i.e. at home, in doctor's offices, in break areas, in administrator's offices, etc.), may alone justify the cost of perioperative information systems on the basis of an increase in clinical case awareness for the patient, workplace convenience for clinical staff and a powerful efficiency tool for administrators.
Embodiments of the invention can use a middle tier web application server functionally set between the Anesthesia Information System database and the Internet. Requests for information from Internet clients are met by the application server layer, which queries the database, processes the data, draws the graphics and returns HTML pages with embedded images to the original Internet client. Figure 4 illustrates embodiments of the invention in block diagram format.
As shown in Figure 4, information processing systems according to embodiments of the present invention can include an application server 411 coupled between a database server 413 of an anesthesia information system and the internet 415 or other wide area network. As discussed above, an anesthesia information system can include a plurality of workstations 421 coupled with a database server 413 over a local area network 425 within a hospital. The application server 411 can retrieve desired data from the database server 413, use the retrieved data to build records and tables for secure distribution over the internet 415 to authorized internet client devices 417.
Embodiments of the invention can be used by anyone who needs access to perioperative data. These uses can include:
1. Any clinical staff wanting to look up anesthesia records related to a patient. This could be from anywhere with access to an Internet browser. For example embodiments of the invention can be incorporated as a link in a web-based Medical Information System thus providing a viewable anesthesia record anywhere in the hospital. Until now, unwieldy solutions for storing the Anesthesia record in the Common Data Repository (CDR) have been contemplated, such as creating an Adobe PDF image of the record, and storing that. Embodiments of the invention can provide an elegant solution that can make the use of scanned images of paper anesthesia records obsolete. There is no need to duplicate the data, because existing data can be viewed in a novel and robust format.
2. Remote users who wish to access anesthesia records. For example, to give an expert opinion on a live running case in the operating room, or to provide an anesthetic record to an outside hospital when they request information about a patient's anesthetic history. Perhaps the most common use may be anesthesia providers looking up old records from their offices or homes planning their approach to the next day's cases (there is a considerable patient safety element in this).
3. Local users of information systems in the operating rooms can use embodiments of the invention to provide a more comprehensive and readable view of a case than their "fat client" record provided by current Anesthesia Information Systems, which may be optimized for data input. 4. Users who need to remotely access scheduling information. For example, "What cases am I doing tomorrow?"
5. Administrators managing Operating Room suites and/or recovery areas and/or patient waiting areas and/or bed control functions can use live status monitors of embodiments of the invention.
6. Using embodiments of the invention as a status monitor for viewing in coffee rooms or "Big Board" central planning areas. Using multi-head video cards, embodiments of the invention can be spread over multiple flat panel displays to provide a status of all the rooms in a suite.
7. For Quality Assurance and Audit. Simple database queries can extract cases with poor outcomes or cases that have been otherwise flagged for further analysis. A link to a reference for an anesthetic record can be emailed securely to the hospital's QA committee and risk analysis department.
8. Embodiments of the present invention can also be used to provide hospital inventory control and billing information. For example, Anesthesia Records can be provided to the hospital pharmacy so that drugs used during an operation can be inventoried and billed more accurately.
9. Using embodiments of the present invention, care providers and/or administrators can look up personalized information about their clinical practice using a feature in ORview termed "MyQI". This area can enable users to generate dynamic and active views of data regarding their clinical practice in comparison to that of their peers. This functionality can thus be used to influence clinical practice. Personalized information relating to the practice of a particular physician can be provided. A table of all cases for which a user is listed an having worked on can be generated. Such a table, for example, can include information for each case such as the case information provided in Figure 16. Statistical data can also be provided for a particular physician. For example, a graphical representation can be provided illustrating a number of cases handled by day, week, or month over a designated time period. Comparisons can also be provided between a particular physician and peer physicians. For example, average drug use(s), average cost(s), average or reported event(s), etc. for a physician over a period of time can be compared to a comparable average(s) of peer physicians over the same period of time. A detailed description of system architectures according to embodiments of the invention now will be provided. These detailed embodiments will collectively be referred to as ORview.
The ORview welcome page, "orview.jsp", directs users to the various components of ORview. The welcome page resides on a web application server within its Secure Sockets Layer (SSL), so a request for the welcome page is met with an offer of a digital server certificate which must be accepted to continue. The certificate offers the application server's public key of a paired RSA_5 128 bit encryption key pair. This is 'strong' encryption and provides that from this point the user session will continue over an encrypted link between web-client and web-server.
The ORview development software uses a test server certificate from Verisign Inc., so the screen 511 illustrated in Figure 5 can be served suggesting that the key being offered is from an untrusted site and asking if the user would like to accept it. This is normal SSL protocol. Purchasing a production server certificate may allow automatic SSL without this step.
The welcome page for the application, orview.jsp, can act as a redirector, pointing new users to the registration forms, and transparently pointing established users to the application itself. ORview.jsp and other JSPs in ORview can use JavaServer Pages (JSP) technology from Sun Microsystems, Inc. The first clinical page or Choices Page 611 of ORview is "choices.jsp" which can be provided as illustrated in Figure 6. A link to orview.jsp from any web page can initiate the ORview application.
ORview can use Tomcat V3.2 as a servlet and JSP container, otherwise known as an "application server". Tomcat is freely downloadable from the Internet and is part of the Jakarta open source project. Tomcat is a pure Java application and can run in a Java Virtual Machine (VM) on a Windows 4.0 NT server 711 as illustrated in Figure 7.
Tomcat 3.2 is Sun's endorsed implementation of the Java servlet specification v2.3 and JavaServer Pages (JSP) specification vl.2. For Orview, Tomcat has been configured with its server .xml file to run as a service in Windows NT and to accept SSL connections on port 443, the default port for SSL. Tomcat's insecure default port 8080 has been disabled, plugging insecure access to the middle tier. Tomcat's internal security model uses the Java key store ".keys", and it is here that the server certificate key pair resides. Configuration of Tomcat, or any other commercial application server in this way may be desirable for ORview. However, ORview is not confined to using Tomcat. Several of the commercial application servers could act as more powerful servlet containers, e.g. Bea's WebLogic server or IBM's WebSphere, but these application servers may be relatively expensive programs costing $5,000 or more. Tomcat should work well enough unless volume gets very high, in which case the investment to a commercial application server may be worthwhile.
ORview can use ImageServer Pro software from Corda Technologies Inc. to render and serve highly interactive graphics in its output, the anesthesia record. Functionally, all the text-based portions of the delivered HTML page are processed by the servlets in Tomcat, while the graphics are processed by ImageServer running on Windows NT server 811 as shown in Figure 8.
ImageServer is a pure Java application designed for high volume financial sites with requests for 30,000 to 50,000 images/hour, and is more than capable for the task. Also included are the PopChart Image Server Embedder (PCISE) Java classes from Corda Technologies Inc. which allow direct communication of ORview with the ImageServer, and Popchart.class Java class, which is an HTTP Redirection Adapter allowing images to be served back to the requesting page through Tomcat's Secure Sockets Layer (SSL).
The ORview web application, orview. war, includes the code and associated files to run ORview. At its core are three Java servlets and a collection of JSPs. The servlet classes are contained in a package called orview. ORview includes an XML configuration file called web.xml. The web application contains the following associated files as shown in the screen images 911 and 1011 of Figures 9 and 10. Packages associated with ORview in the "classes" directory include:
1. com.sybase.jdbc.*;
2. com.corda.servlet.*;
3. javax.*; and
4. orview.*.
Of these, com.sybase.jdbc.*, com.corda.servlet.*, and javax.* are freely distributed Java packages and classes from Sun Inc., Sybase Inc. and Corda Inc. associated with their Java2, JConnect and ImageServer products respectively. Also included in ORview. war are some associated image files and the collection of JSPs which control user registration and other forms of simple user input. ORview. war is packaged according to the WC3 specification for a web- application and contains files to run ORview on the application server environment detailed in the previous section.
ORview uses two configuration files, server.xml and web.xml. server.xml is the WC3 compliant XML server configuration file for the Tomcat application server. It specifies how Tomcat is to be configured to manage its ports, security, logs and realms as well as other core functions specific to the application server. Web.xml is the XML configuration file for ORview, and is compliant with the WC3 web- application specification. Web.xml serves the following functions:
1. Identifies servlets to Tomcat and sets initialization and shtml address mapping parameters;
2. Provides the security and Realm settings for the ORview application; and
3. Provides initialization parameters to the servlets.
As shown in Figure 11, an Orview Windows NT application server 1101 can use any Java DataBase Connectivity (JDBC) 2.0 compliant driver 1111 to connect to a Relational Database Management System (RDBMS) 1113 of an anesthesia information system. For the Saturn Anesthesia Information system, ORview is configured using web.xml to use the Sybase JConnect driver v 5.5 which has the feature of scrollable result set cursors, part of the JDBC 2.0 standard. The Sybase driver is freely distributable and is included in the ORview web application in the com.sybase.* package. As discussed above, the application server can be configured to provide a Java virtual machine 1117 within which Tomcat 1119 operates.
The organization of database connectivity in ORview is illustrated in Figure 11. The core Servlets in ORview use SQL query strings 1115 and a pooled connection object to access the database. ORview also uses one stored procedure and 3 functions on the database, which is done at installation using an initial SQL database call. The 4 resident SQL stored procedures and functions are:
1. TodaysCasesByUser (Stored Procedure);
2. GetPatientLocation (function);
3. GetGroupName(function); and
4. GetBreakReliefString(function).
ORview uses sophisticated image processing techniques to efficiently generate Shockwave FLASH (Macromedia Inc.) images 1209 in the web screens of the anesthesia record 1211 as illustrated in Figure 12. Image generation is managed by a Java software package called ImageServer Pro 1213 from Corda Technologies Inc. The principle of its use is to pass a datastream and a graphic template to an image rendering engine. The image server renders the graphic as a Macromedia Shockwave FLASH vector image and holds it and a reference to it in cached memory 1207 until required. The reference to the cached image on the server is embedded in HyperText Markup Language (HTML) in the served page to the user, and when the Internet Browser parses the embedded image tag, it requests the referenced image from the image server which it then displays. After a fixed period, the image server flushes the cached images from memory.
ImageServer Pro is an extremely fast image processing system, capable of rendering and serving images for high volume websites such as the financial Internet portals. The core ImageServer is a Java application which accepts I/O requests on port 81. ORview uses two other features of ImageServer to enable the rapid production of secure images. These other features of ImageServer are :
1. The PCISEmbedder 1215 which is a set of Java classes imported into the core ORview servlets. Their function is to pass the data stream to the ImageServer 1213, set the image generation parameters, incorporate a graphic template binary file (Chartbin) and generate the HTML for the embedded graphic with its reference to the cached image on the image server.
2. The HyperText Transfer Protocol (HTTP) Redirection Adapter is Java class (PopChart.class) which enables images to be redirected from ImageServer's Port 81 to the Secure Sockets Layer (SSL) 1217 on port 443. Unless this is done, a functional distinction exists between the security of text and images served by ORview. The redirection adapter ensures that both these data types are encrypted over the web, and that the management of this is done by Tomcat's SSL.
ImageServer Pro need not be on the same physical server, but should be accessible via a URL over the Internet. ImageServer Pro has extensive load-balancing capability and can be scaled up to meet virtually any demand for image generation. ImageServer Pro runs as a service within a Java Virtual Machine 1219 on a Windows NT machine 1221. The PCISEmbedder 1215 and PopChart.class 1223 are contained in the package com.corda.*, and are imported into the ORview application. ImageServer Pro is licensed from Corda per server. Conceivably, a single ImageServer/ ORview application server combination could manage the web page generation and graphics processing of multiple hospitals.
The functionality of ORview may be described with reference to the illustration of Figure 13. A log-in may be required for security purposes using a login screen 1301. The Choices Page 1311 acts as a portal to the ORview application. Using radio button choices or typing a user name, users are able to request the anesthesia schedule page 1315 by service, by location, a personalized schedule, or initialize a search for anesthesia records pages 1317 for a particular patient using a search page 1319. Either a search page 1319 or an anesthesia schedule page 1315 can be used to generate a list of anesthesia records 1321 for a particular patient, and the list of anesthesia records 1321 can be used to generate a desired anesthesia record 1317. The flow of a user-session may include the following features:
1. Links. For example, selecting "Cardiac" at the Choices screen and then hitting the "go" button requests the cardiac schedule for the current day and the next day, and a web page is served which shows the cardiac schedule in an active tabular format. The schedule pages contain embedded links, so hitting the link on a particular patient will initiate a search for all anesthetic records associated with that patient, which may include a current running record. A page is then served which shows the list of anesthetic records for a particular patient, again in a active tabular format. Following the links on this page enables the user to drill down to individual anesthetic records. The anesthetic record is displayed as a combination of tabular and interactive graphical elements.
2. Navigation throughout the application is by following the links embedded in the pages, or by using the Browser's Back and Forward buttons. Most of the navigation is managed by HTML 'get' actions using simple parameterized queries. This enables individual pages, for example a patient's anesthetic record, to be bookmarked without compromising patient confidentiality.
3. Autorefresh. ORview has the facility to enable autorefresh of served pages, so the Operating Room schedule pages and Anesthetic records will autorefresh at a user specified time interval to give the impression of a near real-time live view of these elements. 4. Session Management. ORview uses a Java session manager class to handle user sessions. BASIC authentication of the user with Username and Password is required before any clinical pages are viewable. The session manager ensures that this authentication is good for the duration of a single user session on their browser, or times out after 120 minutes, whichever is sooner. As illustrated in Figure 14, the Choices Page 1311 for ORview enables the user to select distinct derivatives of information. For example, the following derivatives of information may be selected:
1. The anesthesia schedule by Division, Location or by "In Progress" cases using radio buttons. These are customizable selections by institution according to desired functionality. The "In Progress" option selects all currently running cases. The default date range is for cases from the current date until the next working day, including the spanning of weekends, so it is always possible to see the following working day's schedule using the system.
2. Underneath this is an edit box for selection of the schedule by provider. This initiates a search for all scheduled cases in the default date range where the inputted provider has been involved in the clinical staffing. It will show users the cases they have been involved with today, and their schedules for tomorrow or Monday, if that is the next working day. ORview does not yet anticipate Holidays.
3. The "Search Old Saturn Records" link initiates the search for all anesthetic records related to a patient.
As illustrated in Figure 15, the Search page 1319 can be used to find all anesthetic records associated with a particular Patient. The search is initiated by a user entering the Patient's medical record number (MRN), or unique patient identifier, which could be a Social Security Number (SSN), for example. The page than passes the MRN as a parameter to the servlet CasesByHxno, which performs a series of JDBC SQL queries on the database and returns an HTML page with the Anesthesia Record Results by patient on it. Other search modalities can be provided, such as searching by patient name, the use of wildcard characters and the use of search logic to search based on combinations of different types of identifying information and/or parts thereof. As illustrated in Figure 16, the Anesthesia Record Search Results page 1321 can display the output of the servlet CasesByHxno (patient names have been removed for confidentiality purposes). The Anesthesia Record Search Results Page has been designed to be a primary method of navigating to a patient's individual anesthetic records and may be a necessary selection step because a patient may have multiple anesthetic encounters recorded in the system. As such, the page should display just enough information for the user to identify a particular anesthesia record that they may wish to drill down further to view. The input parameter string to the servlet can be obtained either from the search page or by following a link from the OR Schedule Page. The input parameter, for example, may have a format such as:
Httρs://152.3.70.74/orview/casesbylιxno?HXNO=CM0319. Moreover, the input parameter can be bookmarked to provide rapid access in the future. Features on the Anesthesia Record Search Results page can include:
1. An active tabular format. Each row represents an individual anesthetic record, and displays a link in the Case ID column to an individual anesthetic record. By selecting a particular case identification (CaselD), the particular Anesthesia Record can be obtained.
2. The other columns display patient demographic information relating to the previous anesthetic encounters, including the surgical procedure and the Attending Anesthesiologist assigned to a case.
3. The Anesthesia Record Search Results Page can also include alerts such as alerts noted during a preoperative screening or note by a health care provider from a previous surgical event. For example, an alert icon provided on the Search Results page can provide a link to more information regarding the alert.
As shown in Figure 17, the Operating Room Status Page 1315 or monitor is a display of the output of the servlet CasesByUser and can be called by accessing the selection choices of the Choices Page 1311. The format of this page is active and tabular, with each row representing an individual anesthetic case, with links to the anesthetic records of an individual patient. The set of cases displayed on this page corresponds to the selection criteria from the Choices page, and may represent all the cases for a particular hospital, the cases for one service, or just those of an individual user, for example. This page can accomplish at least two goals. The Operating Room Status page 1315 can act as a static schedule for planning purposes, and as a status monitor for a group of operating rooms or staff. It can act as a status monitor because the data in the columns in the page can reflect real-time events entered by users into the anesthesia information system database, and this data can autorefresh on the WebPage at intervals to give the appearance of real time case status. The inclusion of active links, blinking elements and autorefreshed data can give this Page the impression and utility of an "Airport Monitor" for the operating rooms, displaying the status of a large number of real time events in an effective manner. Features of the Operating Room Status Page 1315 can include:
1. Cases can be sorted by Date, Operating Room and/or Scheduled Case Start time to give the page a standard format of schedules used in many operating room suites.
2. The Case Status column can display the current status of a case depending on the status flag in the database; Preop, In Progress, Complete, Cancelled or Archived. If the case Status is "In Progress", the column element in that row can Blink to highlight that the case is currently active. In this way the user gets an immediate view of the active cases in the Operating Room (OR) suite.
3. The OR Name column displays information about the patient's scheduled and current location based on machine replication settings in the database. The database flags data recorded on particular workstations for a case, so it is possible to track exactly where a patient is at a particular time. The string shown in this column cab be of the following format:
Location A=>Location B. This format signifies Scheduled Location => Current Location. As such this tool enables the user to track the current location of a patient, and the difference from the scheduled location. This can be a tremendously powerful feature for administrators. For example, the post-anesthesia care unit 'PACU' choice in the welcome page may select all cases which are currently active on PACU workstations so that the OR Name column displays the bed spaces in PACU which are currently occupied.
4. The Patient Name, other demographic and case procedure columns reflect these database items for a single case. The database can be populated with this data using an HL7 interface from the Hospital Information System (HIS).
5. The Last Attending and Last User columns reflect the last Attending to sign in to a case and the last or current user of the case based on user login. These columns thus reflect who should be called to access the caregivers for a case.
6. The Last User column can also provide the feature of an active element looking for data entered by users to reflect their 'break' relie s, i.e. coffee and lunch breaks as shown in segment 1801 of Figure 18.
,The servlet can also look for database events entered by users to indicate 'breaks' and if found, displays persistently the most recent event and time in the Last User column. In this way, an administrator can see at a glance who has been given 'break relief in a suite of operating rooms. This can be a powerful feature for management of staff, as this may otherwise be a haphazard process involving multiple telephone calls to rooms.
7. The Milestone and Time columns display the last entered milestone event and the time it occurred. Milestone events are configured at installation to be those events entered by the clinical user which reflect the time course of a case. As the page autorefreshes, the user can see individual cases 'march' through their milestones, giving an immediate impression of the exact clinical status of the case. This again can be a powerful tool for 'at-a- glance' administration of an operating room suite. Milestones are steps of a surgery occurring in the operating room while the case status is "In Progress", and milestones can include (but are not limited to): patient arrival in preop holding; start of anesthesia care; patient leaves preop holding; patient arrives in OR; anesthesia induction; anesthesia ready; surgical incision; surgical timepoints; aortic crossclamp on; CPB on; aortic crossclamp off; CPB off; surgeon closing wound; end of surgery; anesthesia extubation; patient arrives in PACU (recovery area); end of anesthesia care; and discharge from PACU; or free text entered by a care provider.
8. The Operating Room Status Page can also include one or more alert icons. The alert icon can be used as a link to textual information relating to specific information for one of the patients scheduled for operation. An alert icon, for example, can be used to indicate an allergy, an event in a previous operation, an outcome of a previous operation, or any other information that would be useful to know before performing an operation and/or administering anesthesia. More particularly, a preoperative screening can be performed prior to the scheduled operation, information obtained during the preoperative screening can be entered into a screening database, and alert icons can be generated based on information entered into the screening database. In the alternative, events and/or outcomes from anesthesia records of prior operations can be used to generate alert icons on the Operating Room Status Page. Operations for generating the Operating Room Status Page at the application server for display at a client device are illustrated in Figure 19. The application server can initialize the servlet CasesByUser by request from a browser of a remote client device at block 1901; get user/group parameters at block 1903, and initialize a JDBC connection with a relational database of an anesthesia information system at block 1905. At block 1907, stored SQL procedures are run to retrieve data form the relational database of the anesthesia information system and to build tables of the data for the Status Page. The result set is opened at block 1909, and a table header is built in a row using HTML at blocks 1911 and 1912. For each case to be displayed by the status monitor at block 1913, the case data is retrieved at block 1915, and an HTML row is built at block 1916. Once HTML rows have been built for the header and for all rows, the output HTML is returned to the calling browser of the remote client at block 1917.
As shown in Figure 20, the Anesthesia Record Page 1317 can display a representation of an anesthetic record using tabular, columnar and interactive graphical formatting of the data. It is the result of the output of the servlet CasesByCaseid and is accessed by following a link from the Anesthetic Record Search Result Page.
An overall impression of this page can be that of a classic anesthesia record in the format to which anesthesia staff is universally familiar. Some compromises may have to be made due to the limitations of the HTML medium and for the sake of application speed, but the result can be remarkably effective.
A rearrangement has been made in the ordering of the major categories of data compared to the classical record. The case events 2001 are placed first after demographics 2003, instead of the case drugs, and the case events section is followed by a graphical display 2005 of the recorded vital signs and event bar. The case drugs 2007 are moved lower in the display after the graphical display. The gases and fluids 2009 and Labs and perioperative totals 2011 can follow the case drugs. This rearrangement reflects a departure from the functionality of the classic anesthetic record, which is optimized for data entry, whereas the web is optimized for data viewing. Putting the case events near the top of the page makes the course of the anesthetic immediately apparent to the clinical user, without having to scroll down to the rest of the case. Because a major function of a web-based anesthesia record is the rapid lookup and evaluation of old records, this can be a worthwhile change. It also partitions the page into "event" and "data" halves, with the rest of the page below Events being devoted to the display of automatic, graphical and technical data optimized for more detailed review. Alternatively, a conventional arrangement of the data can be used.
Another feature of the page is the use of a 'newspaper column' format to compact the data into a relatively short scrollable page, while maintaining readability. Because the 'MULTICOL' HTML command is specific only to Netscape, it was not used, so the columnar formatting in ORview is performed in the servlet using a combination of Java and HTML code.
Another feature of the page is its ability to display a "real-time" view of the anesthetic record by using its autorefresh feature. A record autorefreshing every minute is effectively a real time view of the anesthetic or PACU record, so that ORview can be used to remotely monitor live cases over the internet. In fact, the graphical representation of the monitored vital sign data is so much more effective than that of most anesthesia information systems, that clinical users may elect to use ORview as a supplement view of case in the operating room as the case is running, using their Anesthesia Information System only for data entry, for which it is optimized.
An Anesthesia Record Page according to embodiments of the present invention can include the following field features:
1. Customizable header by institution, configured using web.xml.
2. Customizable logo by institution, configured using web.xml. (shown here is the spinning Duke shield). 3. Case Demographics with automatically resizing fields and calculated values taken from the database.
4. Case staffing data drawn from the database.
5. Case diagnosis and procedure fields drawn from the database.
6. Case Events. Here a newspaper column format is used to display 2 columns of the events associated with the case. The Columns resize to match the quantity of data.
7. The Monitored Vital Sign Graphic. This feature of ORview is the output of the ImageServer software as described in a previous section. The PopChart Image Server Embedder (PCISE) inserts an HTML reference to an image at this point in the page, and the web browser loads the image. The image is of Macromedia Shockwave Flash format, a vector graphic format which has excellent printing, rapid rendering, small size and interactivity as some of its properties. To view the graphic, the web-browser uses the Shockwave Flash Plug-in, for which a download reference is included in the embedded HTML, and which generally is included by default in all current major Browser installations.
Anesthesia records traditionally chart vital sign data graphically, and this feature of ORview does the same. It charts all the vital signs for a case in an image of 975 x 600 pixels. A significant feature of the graph is the custom 3D "Event Bar" 2101a and 2101b as shown in Figures 21 and 22. The 3D Event Bar is a representation of Events and Drugs in the perioperative record charted as a symbol 2103 against time at the point of the event. Multiple events in the same minute period are depicted by a vertical step in the y-axis, so that none of the symbols in a group are hidden by surrounding symbols. The third dimension to this feature is that the text events themselves are pop-up labels 2105 associated with the symbols, viewable by touching the symbols 2103 as a hot-spot, as shown in Figure 22.
In this way, ORview is able to represent a great deal of data in compact format, such that the entire record for a complex case can be squeezed into a graphic across a single screen and yet still allow the event and drug time course to be clear. This can be a great advantage of ORview over traditional Anesthesia Information Systems, which are generally optimized for data entry and whose graphical representation of vital signs and drugs may often span several pages to the detriment of the overall view of the case. This is another reason why ORview may become preferred for reviewing anesthetic case data. The chart 2301 of Figure 23 illustrates this by showing how ORview represents the trended vital signs data from a 16 hour case.
8. The Drugs Display and Fluids Display follow the graphical data of Figure 20. Again, the newspaper column format is used to compact this information and display it in logical time sequence. Four columns are used for compactness, while retaining the aesthetic appeal of the page.
9. The Labs and Totals Display follows the Gases and Fluids Display of Figure 20. Three columns are used, but these are no longer newspaper columns as the data is of three different types. For drug and fluid totals, a simple descending list is used. For Labs, a complex list structure is displayed, with all the labs associated with a single time period concatenated into a string in a format very familiar to anesthesia staff.
Operations for generating an anesthesia record page at an application server for display at a remote client device are illustrated in Figure 24. The application server can initialize the servlet CasesByCaselD in response to a request from a browser of an authorized client device at block 2401. The CaselD parameters can be obtained at block 2403, and the JDBC connection with the database server of the anesthesia information system can be initialized at block 2405. The case demographics, case staff, case procedures, and case events can be obtained from the AIS database server at blocks 2407, 2409, 2411, and 2413, and organized into scrollable results sets at block 2415. The demographics and Events columns are built in an HTML format as shown at blocks 2417 and 2419. Vital signs are requested and retrieved at blocks 2423 and 2425, and loaded into the PCISEemedder at block 2427. The PCIS script including the vital signs is built using the image server to provide an embedded HTML image reference as shown at blocks 2429, 2431, and 2433. Totals for drugs, gases and fluids, and labs and perioperative are obtained at blocks 2435 and 2437, and a scrollable result set is built according to the HTML format as illustrated at blocks 2439 and 2441. The HTML output for the completed anestliesia record page is returned to the browser of the requesting client device. Security and the maintenance of patient confidentiality can be an element of ORview. The security features of ORview can include up to three or more components :-
1. Strong Data Encryption;
2. User Authentication; and
3. User Audit.
Data encryption features of ORview have been extensively discussed elsewhere in this document, but to recap these features may include RS A_5 strong public key/private key data encryption using the Secure Sockets Layer (SSL), used extensively for privacy on the Internet. Effectively, hacking or sniffing patient data between its source, the Tomcat application server, and the client Internet browser may be difficult or impossible.
These features, however, may not address a vulnerability between the application server and the database over the Tabular Data Stream (TDS) used by JDBC type 4 connections. This is moderately indecipherable, but can be read. However, in an individual hospital the application server and database server can be on the same intranet, so the TDS datastream can be no more vulnerable than any other text-based messaging system carrying patient data, such as HL7. The TDS vulnerability may become important if ORview is configured to access a remote database. For this situation, strong encrypted JDBC solutions exist, using JDBC type 3 drivers which utilize a middle tier datasource on the server and which encrypts the JDBC data interchange. A solution may be offered by IDS as discussed at htφ://www.idssoftware.corn/jdbcdrv.html.
ORview can be configured for encrypted JDBC in the circumstance of serving schedules and anesthetic records to multiple hospitals over the Internet, and accessing multiple remote databases. A block diagram 2501 of security structures according to embodiments of the present invention are illustrated, for example, in Figure 25.
ORview can use the BASIC authentication (user/password) schema, administered using Tomcat's security realm model. This authentication can involve setting up a database of users with the data model illustrated in Figure 26.
The user realm for ORview is maintained in a separate Sybase Adaptive Server Anywhere database which manages the user rights to a single hospital's users. The settings for the realm are made on Tomcat's server.xml file. Multiple realms are possible for ORview, governing multiple different hospitals' security models. The modus operandi of BASIC authentication is a password challenge, as shown in the screen 2701 of Figure 27. However, Tomcat may not provide a way of administering user names and passwords, so this mechanism can be built-in to ORview.
Users can be assigned a username and password upon request by the system administrator. This effectively creates a userjtiame, userjpassword, and user_role in the user database. Users are assigned a starter password like "welcome" and then asked to change it on first login.
ORview provides a "Change Password Page" 2801 as shown in Figure 28 which enables the user to change their password in a valid manner. The output of this page is sent to a servlet, orview.changepswd which administers and updates the fields in the user database. Successful attempts to change password lead the user back to the main Welcome Page of ORview. Unsuccessful attempts to change a password are met with an error message, and the requirement to try again.
For any clinical application to maintain HIPPA compliance, it must have some mechanism of user audit. The very strengths of ORview's ability to make all patient data viewable on the Internet, may also be a considerable security weakness if users with appropriate access rights are using or viewing data inappropriately. This is called "peeking", and would include, for example, a colleague looking up a girlfriend's anesthesia record without her consent. The security principle here is that users should only have access to records and data from patients with whom they have a clinical relationship. However, this may be difficult or impossible to administer rigidly, as often caregivers will appropriately want to look up information on patients before they have actually created any record of the event in any hospital system.
One commonly used fallback method is to audit who is looking at what, and reprimand users whose use patterns are inappropriate. ORview uses this method, keeping an audit table of all database access of the anesthesia record in the table "auditjiser", with a schema as shown in Figure 29.
The onus then becomes one of auditing the audit table. However, statistical analysis of the audit table should rapidly show any inappropriate use, whilst providing an audit trail of individual accesses.
Embodiments of the invention can also use sophisticated user management schemas to organize registration and passwords. The diagram of Figure 30 illustrates the password schema of ORview, which makes extensive use of Java Server Pages (JSP) technology. A new user can be assigned a temporary user name and password, and the temporary user name and password can be provided by the system administrator via e-mail. At the login page 3001, the user enters the appropriate username and password, either permanent if an existing user or temporary if a new user. At block 3003, the application server determines if the username and password are authorized as an existing user, normal system access is allowed by providing the Choices Page 3005. If the username and password are authorized as a new user, a registration process is initiated at block 3007. If the registration process is successfully completed at block 3009, a permanent username and password are assigned to the new user at block 3011, the permanent username and password are stored in the SQL user database 3013, and the user can be prompted to login with the permanent password at 3001.
Figure 30 also shows that the Choices Page can be used to initiate a change of password for an existing user. If a password change is requested at the Choices Page 3005, the password change procedure can be performed at block 3015. In particular, the user can select a new password, the new password can be saved in the SQL user database, and the user can be presented with the login request 3001 to login with the new password.
As described above, embodiments of the invention can exploit the power of the Internet in the perioperative environment. Embodiments of the invention can include, among other things, one or more of the following:
1. A Live Web-Based operating room and perioperative suite Status Monitor, that can be served robustly using data encryption and thereby opening the medium of the Internet to this practical clinical use.
2. A Perioperative Anesthetic Record viewable using an Internet Browser that can be served robustly using data encryption thereby opening the medium of the Internet to this practical clinical use.
3. The Representation of Monitored Data as a Graphic over the Internet that can be served robustly using an image server and also encrypted.
4. The representation of the Time course of Events and Drugs using a "3D event bar."
5. The use of middle tier, Java servlet and JavaServer Pages technology running on an Application Server to generate an Anesthetic Record and Perioperative Schedule. Moreover, various terms used in this disclosure are further defined as indicated below:
1. Anesthesia Information Systems (AIS) are computer systems which record and display data gathered in the perioperative period. Data is either input by anesthesia, clerical or nursing staff directly into the system, or is automatically acquired from patient monitoring devices.
2. The perioperative period is the interval of time associated with a single surgical encounter, from the time of the decision to take a patient to surgery until the discharge of the patient home from hospital. This definition could also include outcome data gathered from the patient after discharge with respect to the associated surgical encounter.
3. JDBC is the abbreviation for Java Data Base Connectivity. A JDBC driver is a set of Java classes that manage connectivity to a database. ORview uses the Sybase JConnect driver, but is configurable to use any JDBC driver to any JDBC 2.0 enabled database (all the main RDBMs)
4. CDR is the abbreviation for Common Data Repository, a hospital database that aspires to collect all patient related data. A CDR is uaually heavily interfaced to other hospital information systems, which send it their data. Usually this consists of lab tests, clime notes, EKG reports and the like. A CDR usually has an associated front-end "browser" application which acts as a patient-centric window on the data.
In overview, embodiments of the present invention relate to providing scheduling information and/or medical records relating to surgical care. As will be appreciated by one of skill in the art, the present invention may be embodied as methods, data processing systems, and/or computer program products. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium. Any suitable computer readable medium may be utilized including, but not limited to, hard disks, CD-ROMs, optical storage devices, and magnetic storage devices.
Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as JAVA®, Smalltalk or C++. The computer program code for carrying out operations of the present invention may also be written in conventional procedural programming languages, such as "C", or in various other programming languages. Software embodiments of the present invention do not depend on implementation with a particular programming language. In addition, portions of program code may execute entirely on one or more data processing systems.
The present invention is preferably practiced within a client/server programming environment. As is known by those skilled in this art, client/server is a model for a relationship between two computer programs in which one program, the client program, makes a service request from another program, the server program, which fulfills the request. Relative to the Internet, a Web browser is a client program that requests services (the sending of Web pages or files) from a Web server (which technically is called a Hypertext Transport Protocol or HTTP server) in another computer somewhere on the Internet.
An implementation of the present invention may use the Application Service Provider (ASP) model. As is understood by those of skill in the art, an ASP is an entity that offers individuals and enterprises access over the Internet (or other communications network) to applications and related services that would otherwise have to be located in local computers and/or devices.
As is known to those with skill in this art, client/server environments may include public communications networks, such as the Internet, and private communications networks often referred to as "intranets" and "extranets." The term "Internet" shall incorporate the terms "intranet" and "extranet" and any references to the Internet shall be understood to mean a communications network of any type, including intranets and/or extranets.
Further embodiments of the present invention will now be discussed with regard to the flow charts of Figures 31-35. Embodiments of the present invention, for example, can be used to provide a status monitor for a suite of operating rooms according to the operations illustrated in Figure 31 to provide a status monitor display such as that illustrated in Figure 17. As shown in Figure 31, operation scheduling information can be retrieved at block 3101. More particularly, the operation scheduling information can be retrieved for scheduled operations in a plurality of operating rooms in a designated hospital area over a predetermined time period, and the scheduling information can include a patient identification and a procedure identification. For example, operation scheduling information can be retrieved for operations scheduled in one or more of a plurality of areas such as those areas identified in Figure 14 for a particular day. The scheduling information can thus provide information for fields of the columns of Figure 17 labeled "Division", "Date", "Pt Name" (patient name), "PtHxNo" (patient history number), "Age", and/or "Procedure". The scheduling information can be retrieved from a scheduling database.
At block 3103, current status information can be retrieved for scheduled operations while scheduled operations are in progress, and the current status information can be selected from one of a plurality of milestones of a surgical operation. The current status information can thus provide information for the fields of column of Figure 17 labeled "Milestones". By retrieving current status information while operations are in progress, a status monitor can provide near real-time information. Moreover, the current status information can be retrieved from data entered into electronic data entry systems in the respective operating rooms. The current status information, for example, can be retrieved from data entered into anesthesia information system workstations.
A table of scheduled operations over the predetermined time period can be built at block 3105. For each scheduled operation, the table can include respective patient and procedure identifications. The patient identification, for example, can be a patient name and/or a patient history number shown in Figure 17 as the columns labeled "Pt Name" and "PtHxNo". The table can also include the current status information such as the information shown in the column of Figure 17 labeled "Milestones" and times the respective "Milestones" were entered. The information of the table can be displayed at block 3107.
Scheduling information can thus be entered into an electronic scheduling system such that no additional scheduling information is entered for a particular day after some cut off time before the first scheduled operation that day. For example, the cut off time may be defined as being some time before the end of working hours the previous business day. Accordingly, the schedule for a given day can be set after the cut off the day before. The previously entered scheduling information can then be used as a base of information for the operating room status monitor during the day. This scheduling information can then be updated during the day in near real-time with data entered by surgical staff during surgery into workstations in the operating rooms so that the status monitor can be used to manage a plurality of operating rooms in near real-time. Current status information, for example, may be updated once a minute.
As long as operations are continued at block 3109, the status monitor can maintain the display. When it is time to refresh the table and display with new current status information at block 3111, any new current status information can be retrieved at block 3103. The table can be rebuilt including any new current status information at block 3105, and the updated table can be displayed at block 3107. Refresh can be initiated at block 3111 periodically, such as at one minute intervals, and the refresh interval can be programmed by a user. Alternately, refresh can be initiated at block 3111 when it is detected that new current status information is available. In addition, refresh can be initiated at block 3111 in response to a user request for refresh.
As discussed above, a plurality of operating rooms can be equipped with a respective electronic data entry system wherein retrieving current status information can include retrieving current status information entered into the respective electronic data entry system. More particularly, one or more of the data entry systems can be an anesthesia information system workstation. In addition to operating rooms, the hospital area can also include a plurality of preoperative preparation areas and postoperative recovery areas and wherein the operating rooms, preoperative preparation areas, and postoperative recovery areas is equipped with a respective electronic data entry system. Accordingly, retrieving current status information at block 3103 can include retrieving current status information entered into the respective electronic data entry system in one or more of the operating rooms, preoperative preparation areas, and/or postoperative recovery areas.
The scheduling information retrieved at block 3101 and the table for each of the scheduled operations can also include at least one of an operating room identification (can be displayed under "OR Name" in Figure 17), a scheduled start time (can be displayed under "Case Status" in Figure 17), an assigned physician (can be displayed under "Last Attending" and/or "Last User" of Figure 17), and a patient age (can be displayed under "Age" in Figure 17). In addition, the patient identification for each scheduled operation can include at least one of a patient name (can be displayed under "Pt Name" in Figure 17) and a patient identification number (can be displayed under "PtHxNo" in Figure 17). Moreover, the current status information retrieved at block 3103 can include a surgical event (can be displayed under "Milestone" in Figure 17) and a time of the surgical event (can be displayed under "Time" in Figure 17).
The status monitor of Figures 17 and 31 can be used by a physician to obtain additional information regarding a surgical operation scheduled to be performed. For example, selection of a patient identification from the table of scheduled operations can be accepted. The selection of a patient identification, for example, can be entered by a user using a mouse or roller ball coupled with a screen displaying the table of scheduled operations, using a touch sensitive surface of the screen displaying the table of scheduled operations, a keypad, or other input means known to those having skill in the art.
Responsive to accepting selection of the patient identification, at least one case identification corresponding to the patient identification can be retrieved and displayed, as shown, for example, in Figure 16. In this context, a case identification can be a unique identification of a surgical operation performed, so that a different case identification is assigned to every surgical operation performed in a hospital, and so that a patient may have multiple case numbers associated therewith if multiple surgical operations have been performed in that hospital on that patient. In other words, a patient identification (such as "PtHxNo" of Figure 17 and/or "HxNo" of Figure 16) uniquely identifies the patient, and the case identification (such as "Case ID" of Figure 16) uniquely identifies each of the surgical operations.
As shown in Figure 16, selection of one patient identification from a displayed table of scheduled operations (such as that shown in Figure 17) may result in retrieving and displaying a plurality of case identifications (such as that illustrated in Figure 16). Selection of one of the plurality of case identifications can then be accepted from a user. As discussed above, user input can be provided using a mouse and/or roller ball coupled with a screen displaying the plurality of case identifications, using a touch sensitive surface of a screen displaying the plurality of case identifications, or using other input means known to those having skill in the art.
Responsive to accepting selection of the case identification, a medical record corresponding to the selected case identification for the selected patient identification can be retrieved and displayed. Retrieving the medical record can include retrieving data making up the medical record from a relational database and building a file of data for the medical record as opposed to retrieving a scanned image of a record. More particularly, the medical record can be an anesthesia record, and the anesthesia record can include a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation. Moreover, the anesthesia can have the format and additional information illustrated in Figure 20.
Additional embodiments of the present invention, for example, can be used to retrieve medical information in an efficient manner according to operations illustrated in Figure 32 to provide case identifications such as illustrated in Figure 16. For example, scheduling information can be retrieved for all scheduled operations meeting predefined criteria at block 3201, wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification. The patient identification can include at least one of a patient name and a patient identification number, and the scheduling information can additionally include at least one of an operating room identification, a scheduled start time, an assigned physician, and a patient age.
A table of all scheduled operations can be built at block 3203, wherein for a respective scheduled operation, the table includes the respective patient identification and procedure identification, and the table can be displayed at block 3205. The predefined criteria, for example, can be defined by the user as all operations scheduled for a particular physician on a given day. Accordingly, the table and display can include information such as that illustrated in Figure 17 but only for cases scheduled for the selected physician. Alternately, the predetermined criteria can be defined by the user as all operations scheduled for a particular area of the hospital on a given day. Moreover, other criteria and or other time periods may be used.
The display can be maintained at block 3207 until a user selection is made. Selection of one of the patient identifications can be accepted from the table of all scheduled operations meeting the predefined criteria at block 3209, and responsive to accepting selection of the patient identification, at least one case identification corresponding to the patient identification can be retrieved at block 3211. User selection can be input through a mouse or roller ball coupled to a screen displaying the table, through a touch sensitive surface of a screen displaying the table, or through other means known to those having skill in the art. The at least one case identification corresponding to the patient identification can then be displayed at block 3213 to provide a display such as that illustrated in Figure 16. As discussed above, each case identification identifies a different surgical operation performed on the patient. Embodiments of the present invention can thus allow a physician to efficiently generate a schedule of the physician's assigned operations for a defined time period, and then generate a list of previous operations for a patient listed on the schedule. The list of previous operations may be useful to the physician in preparing for a particular operation.
Once case identifications are displayed for a patient, embodiments of the present invention allow the physician to obtain medical records such as anesthesia records for the different previously performed operations. Information included in these medical records may be useful in preparation for the scheduled operation. For example, table of case identifications can be maintained at block 3215 until a user selection of a case identification is made. Selection of one of the case identifications can be accepted and a medical record corresponding to the selected case identification for the selected patient identification can be retrieved at block 3217 and displayed at block 3219. More particularly, the medical record can be an anesthesia record, and the anesthesia record can include a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
The medical record may be displayed until there is use selection at block 3221 of the previously displayed case identifications. If the user selects to return to the previously displayed case identifications, the case identifications can be displayed at block 3213, and the user can select a different one of the case identifications at block 3215 for retrieval and display of a new medical record at blocks 3217 and 3219. Accordingly, a physician can efficiently view different medical records for a patient in preparation for an operation.
Alternately, the user may select at block 3223 to return to the previously displayed table of scheduled operations at block 3205. A selection and acceptance of a new patient identification from the previously generated table can thus be made at blocks 3207 and 3209, and new case identifications corresponding to the new patient identification can be retrieved and displayed at blocks 3211 and 3213. Medical records corresponding to the new case identifications can be selected, retrieved, and displayed as discussed above with respect to blocks 3215, 3217, 3219, and 3221. Accordingly, a physician can efficiently review medical records from prior operations for different patients scheduled for different operations. In addition, a user can select new schedule criteria at block 3225 so that different scheduling information is retrieved at block 3201. A physician, for example, may first retrieve scheduling information for the next day as discussed above. After reviewing the schedule, prior related case identifications, and prior related medical records, the physician may choose at block 3225 to retrieve scheduling information for another day. Moreover, a supervising physician may choose to generated different schedules for the same day for different physicians be supervised.
When retrieving information according to embodiments of the present invention, alerts from pre-operative screenings corresponding to a patient identification included in the table of scheduled operations can also be retrieved. Moreover, these alerts can be included in and displayed with the table of scheduled operations meeting the predefined criteria. The displayed alert may be an alert icon providing a link to additional textual information. For example, a preoperative screening may be performed a week before the operation, and a particular allergy or other useful information may be uncovered at that time. This information may be entered into a preoperative screening database such that the step of retrieving scheduling information at block 3201 includes retrieving alerts from the preoperative screening database. Identification of and access to these alerts may further enhance the physician's ability to prepare for scheduled operations.
Additional embodiments of the present invention, for example, can be used to display anesthesia records according to operations illustrated in Figure 33 to provide an anesthesia record such as that illustrated in Figure 20. Moreover, the anesthesia records can be displayed using a data processing system at a terminal remote from the data processing system. For example, entry of information identifying a surgical operation can be accepted at block 3301 wherein the information is entered via a client device in communication with the data processing system. Anesthesia data corresponding to the identified surgical operation can be retrieved at block 3303, and an anesthesia record can be built at block 3305 using the retrieved anesthesia data. Secure communication of the anesthesia record to the client device can be provided at block 3307 for display of the anesthesia record at the client device.
, More particularly, the anesthesia data can be retrieved from a database (such as a relational database) generated by an anesthesia information system including workstations in respective operating rooms for data input by surgical staff during operations. Each field of the anesthesia record to be built can be populated by retrieving a corresponding field from the database. In other words, anesthesia record can be built by retrieving a plurality of data fields from a database. In addition, the database can be separate from the data processing system used to build the anesthesia record.
Moreover, the client device can be a terminal such as a personal computer remote from the data processing system wherein the client device and data processing system are coupled by a network such as the internet. By providing secure communication of the anesthesia record from the data processing system to the client device, the confidential anesthesia record can be obtained remotely over an unsecured network such as the internet. Moreover, the secure communication can be provided using encryption as discussed above.
The resulting anesthesia record can include a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation, and the anesthesia record can have a format such as that illustrated in Figure 20. Moreover, the anesthesia record can be built and communicated while the identified surgical operation is in progress. Accordingly, the progress of a surgical operation can be viewed at a client device remote from the operation while the operation is taking place in near real-time, for example, to provide consultation from a remote location. As shown in Figure 33, if there is updated information for the anesthesia record at block 3309, the updated data can be retrieved at block 3303, the anesthesia record can be built with the new data 3305, and the anesthesia record can be securely communicated at block 3307 for display of the updated anesthesia record at the client device. Updated information for the anesthesia record can be provided at block 3309, for example, at predetermined time intervals that can be designated by the user, such as once a minute. Alternately, updated information can be provided when updated information is made available or on user request. As further shown at block 3311 of Figure 33, a new anesthesia record may be selected such that operations of blocks 3301, 3303, 3305, and 3307 are repeated for the new anesthesia record.
The anesthesia record can include a graphical representation of events occurring during the identified surgical operation for display at the client device. The graphical representation can include a time line divided into predetermined units of time with a plurality of events occurring during a period of time represented by a single unit on the time line being represented by respective discreet and distinguishable event icons as illustrated, for example, in Figures 21 and 22. In addition, user selection of one of the discrete and distinguishable icons can be accepted, and responsive to accepting selection of one of the discreet and distinguishable event icons, text identifying the event corresponding to the selected discreet event icon can be provided for display at the client device as illustrated, for example, in Figure 22.
Accepting entry of information identifying a surgical operation at block 3301 can include accepting entry of any information sufficient to identify the surgical operation. For example, entry of a patient identification such as a patent name or patient identification number may be used to identify the anesthesia record. Alternately or in addition, entry of a case identification may be used to identify the anesthesia record. Moreover, any of the operations discussed above with regard to Figure 32 may be used to identify a particular anesthesia record. Moreover, a boolean search may be used to identify a particular anesthesia record.
In addition, aspects of embodiments discussed above can be combined as illustrated, for example, in Figure 34. As discussed, a user can access medical information such as anesthesia records and/or surgical operation schedules using a remote client device coupled to an application server over a network such as the internet. To reduce the risk of unauthorized access, a log-in may be required by the application server at block 3401, so that access is only provided if an authorized combination of username and password are entered at the client device. Upon successful login, the application server can provide a choices page at block 3403 for display at the client device. A choices page such at that illustrated in Figure 14 can be used providing a choice of a search of anesthesia records or a choice of schedules for different hospital areas or physicians. Other choices may also be provided. If the user selects searches at block 3407, the application server can proceed to accept user input of search criteria at block 3421. Alternately, if the user selects schedules at block 3407, the application server can proceed to accept user input of schedule criteria at block 3441.
Upon accepting user input of search criteria at block 3421, the application server can generate a list of anesthesia records matching the search criteria at block 3423 for display at the client device. The list of anesthesia records can be generated and displayed, for example, using the format of Figure 16 wherein a case identification ("Case ID") identifies each of the anesthesia records. The user may then select one of the anesthesia records, and on accepting the user selection at block 3425, the anesthesia record can be generated at block 3471. Otherwise, the user may elect a new search at block 3427, or the user may elect to go back to the choices page at block 3429.
Generation of the anesthesia record at block 3471 can be performed as discussed above with respect to Figure 33. Once a record has been generated and displayed, the user may elect to go back to the previously generated list of anesthesia records and select another anesthesia record for display. At block 3473, the user may elect to go back to the previously generated list of anesthesia records at block 3423. Another record may be selected at block 3425, a new search may be selected at block 3427, or the user can select at block 3429 to go back to the choices page at block 3403.
If the user selects schedules at block 3407, the application server can proceed with accepting user input of schedule criteria. Moreover, the selection of scheduling and the particular scheduling criteria may be provide in a single operation such as illustrated in the Choices Page of Figure 14. A schedule is then generated based on the schedule criteria at block 3443 for display at the client device. The schedule can be generated and displayed according to the format illustrated in Figure 17. Moreover, the operation of generating a schedule of block 3443 can be the same as that discussed above with regard to the operations of Figure 31. The user can then select a patient identification from the displayed schedule at block 3445, and a list of anesthesia records can be generated for display at the client device according to a format such as that illustrated in Figure 16.
If one of the records for the patient is selected by the user at block 3447, the anesthesia record can be generated at block 3471 for display at the client device according to a format such as that illustrated in Figure 20. If a patient is not selected at block 3445, the user may elect at block 3453 a new schedule based on new criteria to be input at block 3441, or the user may elect at block 3455 to go back to the choices page at block 3403. If an anesthesia record is not selected at block 3447, the user may elect at block 3449 selection of a new patient from the schedule, selection of new schedule criteria at block 3451, or at block 3455 to return to the choices page. Once an anesthesia record is generated at block 3473 responsive to user selection of information from a schedule, the user may elect at block 3473 generation of the schedule at block 3443 for display on the client device. The user can then select the same or a different patient and/or record. The operations of blocks 3443, 3445, and 3447, and 3471 can be the same as operations discussed above in greater detail with regard to Figure 32.
The operations of Figures 31-34 can be performed by an application server 3501 in communication with a client device 3503 over a network 3505 such as the internet. User input can be provided thought the client device 3503 and network 3505 to the application server 3501. User input can be provided using a touch sensitive screen of the client device, using a mouse or roller ball coupled with the client device, using a keyboard at the client device, and/or using other means know to those having skill in the art. In addition, the application server 3501 can obtain data from database servers of one or more information systems such as an anesthesia information system 3507, a hospital scheduling system 3509, and/or a preoperative screening system 3511. Data used to build an anesthesia record, for example, can be obtained from a database server of anesthesia information system 3507 including anesthesia workstations in operating rooms. Data used to build schedules can be obtained from a database server of hospital scheduling system 3509, and data used to provide alerts can be obtained from a database server of a preoperative screening system 3511.
Methods, systems, and computer program products according to embodiments of the present invention can thus be implemented separate from other hospital information systems such that only a data connection to the other hospital information systems is required. In the alternative, methods, systems, and computer program products according to embodiments of the present invention can be integrated in whole or in part with one or more hospital systems. For example, methods, systems, and computer program products according to embodiments of the present invention can be integrated in whole or in part with an anesthesia information system such as the Saturn Information System produced by Draeger.
Moreover, embodiments of the present invention have been discussed, by way of example, with reference to anesthesia records. Embodiments of the present invention, however, may be applied to other medical records. For example, embodiments of the present invention may be used with Intensive Care Unit (ICU) records.
The foregoing is illustrative of embodiments of the present invention and is not to be construed as limiting thereof. Although a few exemplary embodiments of this invention have been described, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of this invention. Accordingly, all such modifications are intended to be included within the scope of this invention as defined in the claims. Therefore, it is to be understood that the foregoing is illustrative of the present invention and is not to be construed as limited to the specific embodiments disclosed, and that modifications to the disclosed embodiments, as well as other embodiments, are intended to be included within the scope of the appended claims. The invention is defined by the following claims, with equivalents of the claims to be included therein.

Claims

That Which Is Claimed Is:
l.A method of displaying operation scheduling information for a hospital surgical area including a plurality of operating rooms, the method comprising: retrieving scheduling information for scheduled operations in the plurality of operating rooms of the hospital area over a predetermined time period wherein the scheduling information for respective scheduled operations includes a patient identification and a procedure identification; retrieving current status information for at least one of the scheduled operations while in progress wherein the current status information is selected from a plurality of milestones of a surgical operation while in progress; and providing a table of scheduled operations over the predetermined time period for display at a client device, wherein for respective scheduled operations, the table includes the respective patient identification and procedure identification wherein the table further includes the current status infom ation.
2. A method according to Claim 1 wherein respective ones of the plurality of operating rooms are equipped with a respective electronic data entry system wherein retrieving current status information comprises retrieving current status information entered into a respective electronic data entry system.
3. A method according to Claim 2 wherein at least one of the data entry systems comprises an anesthesia information system workstation.
4.A method according to Claim 1 wherein the hospital area further includes a plurality of preoperative preparation areas and postoperative recovery areas and wherein the operating rooms, preoperative preparation areas, and postoperative recovery areas are equipped with respective electronic data entry systems, and wherein retrieving current status information comprises retrieving current status information entered into a respective electronic data entry system.
5. A method according to Claim 1 wherein retrieving current status information comprises retrieving current status information at regular intervals, the method further comprising: refreshing the table on receipt of new current status information and displaying the refreshed table.
6. A method according to Claim 1 wherein the scheduling information and the table for each of the scheduled operations further includes at least one selected from the group consisting of an operating room identification, a scheduled start time, an assigned physician, and a patient age.
7.A method according to Claim 1 wherein the patient identification for a scheduled operation includes at least one selected from the group consisting of a patient name and a patient identification number.
8. A method according to Claim 1 the current status information includes a surgical event and a time of the surgical event.
9.A method according to Claim 1 further comprising: accepting selection of a patient identification from the table of scheduled operations; responsive to accepting selection of the patient identification, retrieving at least one case identification corresponding to the patient identification; and displaying the at least one case identification corresponding to the patient identification.
10. A method according to Claim 9 wherein the at least one case identification comprises a plurality of case identifications, the method further comprising: accepting selection of one of the case identifications; responsive to accepting selection of the case identification, retrieving a medical record corresponding to the selected case identification for the selected patient identification; and displaying the medical record.
11.A method according to Claim 10 wherein the medical record comprises an anesthesia record.
12. A method according to Claim 11 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
13. A method of retrieving medical information comprising: retrieving scheduling information for scheduled operations meeting a predefined criteria wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification; providing a table of scheduled operations meeting the predefined criteria for display at a client device wherein for each scheduled operation, the table includes the respective patient identification and procedure identification; accepting selection of one of the patient identifications from the table of scheduled operations meeting the predefined criteria; and responsive to accepting selection of the patient identification, retrieving at least one case identification corresponding to the patient identification for display at the client device.
14.A method according to Claim 13 wherein the at least one case identification comprises a plurality of case identifications, the method further comprising: accepting selection of one of the case identifications; and responsive to accepting selection of the case identification, retrieving a medical record corresponding to the selected case identification for the selected patient identification for display at the client device.
15. A method according to Claim 14 wherein the medical record comprises an anesthesia record.
16. A method according to Claim 15 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
17. A method according to Claim 13 wherein retrieving scheduling information for scheduled operations meeting a predefined criteria comprises retrieving scheduling information for operations scheduled within a predetermined time period for an area of a hospital.
18. A method according to Claim 13 wherein retrieving scheduling information for scheduled operations meeting a predefined criteria comprises retrieving scheduling information for operations scheduled with a designated physician within a predetermined time period.
19. A method according to Claim 13 wherein the scheduling information and the table for each of the scheduled operations further includes at least one selected from the group consisting of an operating room identification, a scheduled start time, an assigned physician, and a patient age.
20. A method according to Claim 13 wherein the patient identification for each scheduled operation includes at least one selected from the group consisting of a patient name and a patient identification number.
2 l.A method according to Claim 13 further comprising: retrieving an alert from a pre-operative screening corresponding to a patient identification included in the table of scheduled operations meeting the predefined criteria, wherein displaying the table of scheduled operations meeting the predefined criteria includes displaying an indication of the alert.
22. A method of displaying anesthesia records comprising the following performed by a data processing system: accepting entry of information identifying a surgical operation wherein the information is entered via a client device in communication with the data processing system; retrieving anesthesia data corresponding to the identified surgical operation; building an anesthesia record using the retrieved anesthesia data; and providing secure communication of the anesthesia record to the client device for display of the anesthesia record at the client device.
23.A method according to Claim 22 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
24.A method according to Claim 23 wherein providing secure communication of the anesthesia record comprises providing secure communication of the anesthesia record corresponding to the identified surgical operation while the identified surgical operation is in progress.
25.A method according to Claim 24 further comprising: after providing secure communication of the anesthesia record to the client device, retrieving updated information including at least one selected from the group consisting of a new event occurring during the surgical operation, a new measurement of vital signs, and a new drug administered; and after retrieving the updated information, providing secure communication of the updated information to the client device for display of an update of the anesthesia record at the client device while the identified surgical operation is in progress.
26.A method according to Claim 22 wherein the anesthesia record comprises a graphical representation of events occurring during the identified surgical operation for display at the client device, the graphical representation including a time line divided into predetermined units of time with a plurality of events occurring during a period of time represented by a single unit on the time line being represented by respective discreet and distinguishable event icons.
27.A method according to Claim 26 further comprising: accepting selection of one of the discreet and distinguishable event icons; and responsive to accepting selection of one of the discreet and distinguishable event icons, providing text identifying the event corresponding to the selected discreet and distinguishable event icon for display at the client device.
28.A method according to Claim 22 wherein accepting entry of information identifying a surgical operation comprises accepting entry of a selection of a patient identification.
29.A method according to Claim 28 wherein the patient identification includes at least one selected from the group consisting of a patient name, and a patient identification number.
30. A method according to Claim 22 wherein accepting entry of information identifying a surgical operation comprises accepting entry of a selection of a case identification.
3 l.A data processing system that facilitates display of operation scheduling information for a hospital surgical area including a plurality of operating rooms, the data processing system comprising: means for retrieving scheduling infonnation for scheduled operations in the plurality of operating rooms of the hospital area over a predetermined time period wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification; means for retrieving current status information for at least one of the scheduled operations while in progress wherein the current status infonnation is selected from a plurality of milestones of a surgical operation while in progress; and means for providing a table of scheduled operations over the predetermined time period for display at a client device wherein for a scheduled operation, the table includes the respective patient identification and procedure identification wherein the table further includes the current status information.
32.A data processing system according to Claim 31 wherein the plurality of operating rooms are equipped with a respective electronic data entry system wherein the means for retrieving current status information comprises means for retrieving current status information entered into the respective electronic data entry system.
33. A data processing system according to Claim 32 wherein at least one of the data entry systems comprises an anesthesia information system workstation.
34.A data processing system according to Claim 31 wherein the hospital area further includes a plurality of preoperative preparation areas and postoperative recovery areas and wherein the operating rooms, preoperative preparation areas, and postoperative recovery areas are equipped with respective electronic data entry systems, and wherein the means for retrieving current status information comprises means for retrieving current status information entered into the respective electronic data entry system.
35. A data processing system according to Claim 31 wherein the means for retrieving current status information comprises means for retrieving current status information at regular intervals, the data processing system further comprising: means for refreshing the table on receipt of new current status information and means for providing the refreshed table for display at the client device.
36. A data processing system according to Claim 31 wherein the scheduling information and the table for the scheduled operations further includes at least one selected from the group consisting of an operating room identification, a scheduled start time, an assigned physician, and a patient age.
37. A data processing system according to Claim 31 wherein the patient identification for a scheduled operation includes at least one selected from the group consisting of a patient name and a patient identification number.
38. A data processing system according to Claim 31 the current status information includes a surgical event and a time of the surgical event.
39.A data processing system according to Claim 31 further comprising: means for accepting selection of a patient identification from the table of scheduled operations; means, responsive to accepting selection of the patient identification, for retrieving at least one case identification corresponding to the patient identification; and means for providing the at least one case identification corresponding to the patient identification for display at the client device.
40. A data processing system according to Claim 39 wherein the at least one case identification comprises a plurality of case identifications, the data processing system further comprising: means for accepting selection of one of the case identifications; means, responsive to accepting selection of the case identification, for retrieving a medical record corresponding to the selected case identification for the selected patient identification; and means for providing the medical record for display at the client device.
41.A data processing system according to Claim 40 wherein the medical record comprises an anesthesia record.
42.A data processing system according to Claim 41 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
43.A data processing system that retrieves medical information comprising: means for retrieving scheduling information for scheduled operations meeting a predefined criteria wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification; means for providing a table of scheduled operations meeting the predefined criteria for display at a client device wherein for each scheduled operation, the table includes the respective patient identification and procedure identification; means for accepting selection of one of the patient identifications from the table of scheduled operations meeting the predefined criteria; and means, responsive to accepting selection of the patient identification, for retrieving at least one case identification corresponding to the patient identification for display at the client device.
44.A data processing system according to Claim 43 wherein the at least one case identification comprises a plurality of case identifications, the data processing system further comprising: means for accepting selection of one of the case identifications; and means, responsive to accepting selection of the case identification, for retrieving a medical record corresponding to the selected case identification for the selected patient identification for display at the client device.
45.A data processing system according to Claim 44 wherein the medical record comprises an anesthesia record.
46.A data processing system according to Claim 45 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
47.A data processing system according to Claim 43 wherein the means for retrieving scheduling information for scheduled operations meeting a predefined criteria comprises means for retrieving scheduling information for operations scheduled within a predetermined time period for an area of a hospital.
48.A data processing system according to Claim 43 wherein the means for retrieving scheduling information for scheduled operations meeting a predefined criteria comprises means for retrieving scheduling information for operations scheduled with a designated physician within a predetermined time period.
49.A data processing system according to Claim 43 wherein the scheduling information and the table for each of the scheduled operations further includes at least one selected from the group consisting of an operating room identification, a scheduled start time, an assigned physician, and a patient age.
50.A data processing system according to Claim 43 wherein the patient identification for each scheduled operation includes at least one selected from the group consisting of a patient name and a patient identification number. 5 l.A data processing system according to Claim 43 further comprising: means for retrieving an alert from a pre-operative screening corresponding to a patient identification included in the table of scheduled operations meeting the predefined criteria, wherein providing the table of scheduled operations meeting the predefined criteria includes providing an indication of the alert.
52.A data processing system that displays anesthesia records comprising: means for accepting entry of information identifying a surgical operation wherein the information is entered via a client device in communication with the data processing system; means for retrieving anesthesia data corresponding to the identified surgical operation; means for building an anesthesia record using the retrieved anesthesia data; and means for providing secure communication of the anestliesia record to the client device for display of the anesthesia record at the client device.
53. A data processing system according to Claim 52 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
54.A data processing system according to Claim 53 wherein the means for providing secure communication of the anesthesia record comprises means for providing secure communication of the anesthesia record corresponding to the identified surgical operation while the identified surgical operation is in progress.
55. A data processing system according to Claim 54 further comprising: means for retrieving updated information after providing secure communication of the anesthesia record to the client device, the updated information including at least one selected from the group consisting of a new event occurring during the surgical operation, a new measurement of vital signs, and a new drug administered; and means for providing secure communication of the updated information to the client device for display of an update of the anesthesia record at the client device while the identified surgical operation is in progress after retrieving the updated information.
56.A data processing system according to Claim 52 wherein the anesthesia record comprises a graphical representation of events occurring during the identified surgical operation for display at the client device, the graphical representation including a time line divided into predetermined units of time with a plurality of events occurring during a period of time represented by a single unit on the time line being represented by respective discreet and distinguishable event icons.
57.A data processing system according to Claim 56 further comprising: means for accepting selection of one of the discreet and distinguishable event icons; and means, responsive to accepting selection of one of the discreet and distinguishable event icons, for providing text identifying the event corresponding to the selected discreet and distinguishable event icon for display at the client device.
58.A data processing system according to Claim 52 wherein accepting entry of information identifying a surgical operation comprises accepting entry of a selection of a patient identification.
59.A data processing system according to Claim 58 wherein the patient identification includes at least one selected from the group consisting of a patient name, and a patient identification number.
60.A data processing system according to Claim 52 wherein the means for accepting entry of information identifying a surgical operation comprises means for accepting entry of a selection of a case identification.
61.A computer program product that displays operation scheduling information for a hospital surgical area including a plurality of operating rooms, the computer program product comprising a computer useable storage medium having computer readable program code embodied in the medium, the computer readable program code comprising: computer readable program code that retrieves scheduling information for scheduled operations in the plurality of operating rooms of the hospital area over a predetermined time period wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification; computer readable program code that retrieves current status information for at least one of the scheduled operations while in progress wherein the current status information is selected from a plurality of milestones of a surgical operation while in progress; and computer readable program code that provides a table of scheduled operations over the predetermined time period for display at a client device wherein for a scheduled operation, the table includes the respective patient identification and procedure identification wherein the table further includes the current status information.
62.A computer program product according to Claim 61 wherein the plurality of operating rooms is equipped with a respective electronic data entry system wherein the computer readable program code that retrieves current status information retrieves current status information entered into the respective electronic data entry system.
63.A computer program product according to Claim 62 wherein at least one of the data entry systems comprises an anesthesia information system workstation.
64. A computer program product according to Claim 61 wherein the hospital area further includes a plurality of preoperative preparation areas and postoperative recovery areas and wherein the operating rooms, preoperative preparation areas, and postoperative recovery areas are equipped with respective electronic data entry systems, and wherein the computer readable program code that retrieves current status information retrieves current status information entered into the respective electronic data entry system.
65. A computer program product according to Claim 61 wherein the computer readable program code that retrieves current status information retrieves current status information at regular intervals, the computer program product further comprising: computer readable program code that refreshes the table on receipt of new current status information and that provides the refreshed table for display at the client device.
66. A computer program product according to Claim 61 wherein the scheduling information and the table for the scheduled operations further includes at least one selected from the group consisting of an operating room identification, a scheduled start time, an assigned physician, and a patient age.
67. A computer program product according to Claim 61 wherein the patient identification for the scheduled operations includes at least one selected from the group consisting of a patient name and a patient identification number.
68. A computer program product according to Claim 61 the current status information includes a surgical event and a time of the surgical event.
69.A computer program product according to Claim 61 further comprising: computer readable program code that accepts selection of a patient identification from the table of scheduled operations; computer readable program code that retrieves at least one case identification corresponding to the patient identification responsive to accepting selection of the patient identification; and computer readable program code that provides the at least one case identification corresponding to the patient identification for display at the client device.
70. A computer program product according to Claim 69 wherein the at least one case identification comprises a plurality of case identifications, the computer program product further comprising: computer readable program code that accepts selection of one of the case identifications; computer readable program code that retrieves a medical record conesponding to the selected case identification for the selected patient identification responsive to accepting selection of the case identification; and computer readable program code that provides the medical record for display at the client device.
71.A computer program product according to Claim 70 wherein the medical record comprises an anesthesia record.
72. A computer program product according to Claim 71 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
73.A computer program product that retrieves medical information, the computer program product comprising a computer usable storage medium having computer readable program code embodied in the medium, the computer readable program code comprising: computer readable program code that retrieves scheduling information for scheduled operations meeting a predefined criteria wherein the scheduling information for the scheduled operations includes a patient identification and a procedure identification; computer readable program code that provides a table of scheduled operations meeting the predefined criteria for display at a client device wherein for each scheduled operation, the table includes the respective patient identification and procedure identification; computer readable program code that accepts selection of one of the patient identifications from the table of scheduled operations meeting the predefined criteria; computer readable program code that retrieves at least one case identification corresponding to the patient identification responsive to accepting selection of the patient identification for display at the client device.
74.A computer program product according to Claim 73 wherein the at least one case identification comprises a plurality of case identifications, the computer program product further comprising: computer readable program code that accepts selection of one of the case identifications; and computer readable program code that retrieves a medical record corresponding to the selected case identification for the selected patient identification responsive to accepting selection of the case identification for display at the client device.
75. A computer program product according to Claim 74 wherein the medical record comprises an anesthesia record.
76.A computer program product according to Claim 75 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
77. A computer program product according to Claim 73 wherein the computer readable program code that retrieves scheduling information for scheduled operations meeting a predefined criteria retrieves scheduling information for operations scheduled within a predetermined time period for an area of a hospital.
78. A computer program product according to Claim 73 wherein the computer readable program code that retrieves scheduling information for scheduled operations meeting a predefined criteria retrieves scheduling information for operations scheduled with a designated physician within a predetermined time period.
79.A computer program product according to Claim 73 wherein the scheduling information and the table for each of the scheduled operations further includes at least one selected from the group consisting of an operating room identification, a scheduled start time, an assigned physician, and a patient age.
80.A computer program product according to Claim 73 wherein the patient identification for each scheduled operation includes at least one selected from the group consisting of a patient name and a patient identification number.
81.A computer program product according to Claim 73 further comprising: computer readable program code that retrieves an alert from a pre-operative screening corresponding to a patient identification included in the table of scheduled operations meeting the predefined criteria, wherein displaying the table of scheduled operations meeting the predefined criteria includes displaying an indication of the alert.
82.A computer program product that displays anesthesia records, the computer program product comprising a computer usable storage medium having computer readable program code embodied in the medium, the computer readable program code comprising: computer readable program code that accepts entry of information identifying a surgical operation wherein the information is entered via a client device in communication with the data processing system; computer readable program code that retrieves anesthesia data corresponding to the identified surgical operation; computer readable program code that builds an anesthesia record using the retrieved anesthesia data; and computer readable program code that provides secure communication of the anesthesia record to the client device for display of the anesthesia record at the client device.
83. A computer program product according to Claim 82 wherein the anesthesia record comprises a date of a surgical operation, events occurring during the surgical operation, a graphical display of vital signs recorded during the surgical operation, and drugs administered during the surgical operation.
84.A computer program product according to Claim 83 wherein the computer readable program code that provides secure communication of the anesthesia record provides secure communication of the anesthesia record corresponding to the identified surgical operation while the identified surgical operation is in progress.
85. A computer program product according to Claim 84 further comprising: computer readable program code that, after providing secure communication of the anesthesia record to the client device, retrieves updated information including at least one selected from the group consisting of a new event occurring during the surgical operation, a new measurement of vital signs, and a new drug administered; and computer readable program code that, after retrieving the updated information, provides secure communication of the updated information to the client device for display of an update of the anesthesia record at the client device while the identified surgical operation is in progress.
86.A computer program product according to Claim 82 wherein the anesthesia record comprises a graphical representation of events occurring during the identified surgical operation for display at the client device, the graphical representation including a time line divided into predetermined units of time with a plurality of events occurring during a period of time represented by a single unit on the time line being represented by respective discreet and distinguishable event icons.
87.A computer program product according to Claim 86 further comprising: computer readable program code that accepts selection of one of the discreet and distinguishable event icons; and computer readable program code that, responsive to accepting selection of one of the discreet and distinguishable event icons, provides text identifying the event corresponding to the selected discreet and distinguishable event icon for display at the client device.
88. A computer program product according to Claim 82 wherein the computer readable program code that accepts entry of information identifying a surgical operation accepts entry of a selection of a patient identification.
89.A computer program product according to Claim 88 wherein the patient identification includes atleast one selected from the group consisting of a patient name, and a patient identification number.
90. A computer program product according to Claim 82 wherein the computer readable program code that accepts entry of information identifying a surgical operation accepts entry of a selection of a case identification.
PCT/US2002/029354 2001-09-17 2002-09-17 Methods of providing medical information and related systems and computer program products WO2003025703A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002336552A AU2002336552A1 (en) 2001-09-17 2002-09-17 Methods of providing medical information and related systems and computer program products

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US32286501P 2001-09-17 2001-09-17
US60/322,865 2001-09-17

Publications (2)

Publication Number Publication Date
WO2003025703A2 true WO2003025703A2 (en) 2003-03-27
WO2003025703A3 WO2003025703A3 (en) 2003-11-20

Family

ID=23256768

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/029354 WO2003025703A2 (en) 2001-09-17 2002-09-17 Methods of providing medical information and related systems and computer program products

Country Status (2)

Country Link
AU (1) AU2002336552A1 (en)
WO (1) WO2003025703A2 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005027011A2 (en) * 2003-09-12 2005-03-24 Quadrat Planning of simultaneous examinations for a single patient within one time slot
WO2006125269A1 (en) * 2005-05-25 2006-11-30 Romeena Pty Limited As Trustee For Kemp Family Trust Instrument tracking
US7533008B2 (en) 2002-08-19 2009-05-12 General Electric Capital Corporation System and method for simulating a discrete event process using business system data
EP2063373A1 (en) 2007-11-13 2009-05-27 how to organize GmbH Method and system for management of operating-room resources
US7676390B2 (en) 2003-09-04 2010-03-09 General Electric Company Techniques for performing business analysis based on incomplete and/or stage-based data
US8082161B2 (en) 2008-11-04 2011-12-20 Cerner Innovation, Inc. Presenting multi-phase clinical order content based upon a designated performance location
US8140354B2 (en) 2008-11-04 2012-03-20 Cerner Innovation, Inc. Ordering clinical orders associated with future events
US8150712B2 (en) * 2008-11-04 2012-04-03 Cerner Innovation, Inc. User interface for presenting clinical order content based upon designated performance location
US20160323417A1 (en) * 2015-04-30 2016-11-03 Teletracking Technologies, Inc. Integrated system for producing procedural data change sets communicated to multiple client devices
US10157355B2 (en) 2005-11-15 2018-12-18 General Electric Company Method to view schedule interdependencies and provide proactive clinical process decision support in day view form

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4937743A (en) * 1987-09-10 1990-06-26 Intellimed Corporation Method and system for scheduling, monitoring and dynamically managing resources
US5319355A (en) * 1991-03-06 1994-06-07 Russek Linda G Alarm for patient monitor and life support equipment system
US5923001A (en) * 1994-08-05 1999-07-13 Surgical Resources, L.L.C. Automatic surgical sponge counter and blood loss determination system
US6351573B1 (en) * 1994-01-28 2002-02-26 Schneider Medical Technologies, Inc. Imaging device and method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4937743A (en) * 1987-09-10 1990-06-26 Intellimed Corporation Method and system for scheduling, monitoring and dynamically managing resources
US5319355A (en) * 1991-03-06 1994-06-07 Russek Linda G Alarm for patient monitor and life support equipment system
US6351573B1 (en) * 1994-01-28 2002-02-26 Schneider Medical Technologies, Inc. Imaging device and method
US5923001A (en) * 1994-08-05 1999-07-13 Surgical Resources, L.L.C. Automatic surgical sponge counter and blood loss determination system

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7869984B2 (en) 2002-08-19 2011-01-11 General Electric Company System and method for simulating a discrete event process using business system data
US7533008B2 (en) 2002-08-19 2009-05-12 General Electric Capital Corporation System and method for simulating a discrete event process using business system data
US7676390B2 (en) 2003-09-04 2010-03-09 General Electric Company Techniques for performing business analysis based on incomplete and/or stage-based data
WO2005027011A2 (en) * 2003-09-12 2005-03-24 Quadrat Planning of simultaneous examinations for a single patient within one time slot
WO2005027011A3 (en) * 2003-09-12 2005-07-28 Quadrat Planning of simultaneous examinations for a single patient within one time slot
WO2006125269A1 (en) * 2005-05-25 2006-11-30 Romeena Pty Limited As Trustee For Kemp Family Trust Instrument tracking
US10157355B2 (en) 2005-11-15 2018-12-18 General Electric Company Method to view schedule interdependencies and provide proactive clinical process decision support in day view form
EP2063373A1 (en) 2007-11-13 2009-05-27 how to organize GmbH Method and system for management of operating-room resources
US8452615B2 (en) 2007-11-13 2013-05-28 How To Organize (H2O) Gmbh Method and system for management of operating-room resources
US8150712B2 (en) * 2008-11-04 2012-04-03 Cerner Innovation, Inc. User interface for presenting clinical order content based upon designated performance location
US8140354B2 (en) 2008-11-04 2012-03-20 Cerner Innovation, Inc. Ordering clinical orders associated with future events
US8082161B2 (en) 2008-11-04 2011-12-20 Cerner Innovation, Inc. Presenting multi-phase clinical order content based upon a designated performance location
US20160323417A1 (en) * 2015-04-30 2016-11-03 Teletracking Technologies, Inc. Integrated system for producing procedural data change sets communicated to multiple client devices
US10721333B2 (en) * 2015-04-30 2020-07-21 Teletracking Technologies, Inc. Integrated system for producing procedural data change sets communicated to multiple client devices

Also Published As

Publication number Publication date
WO2003025703A3 (en) 2003-11-20
AU2002336552A1 (en) 2003-04-01

Similar Documents

Publication Publication Date Title
CN101681395B (en) Decision support response systems and methods
US7702524B1 (en) Method and system for online secure patient referral system
US7447643B1 (en) Systems and methods for communicating between a decision-support system and one or more mobile information devices
JP5580048B2 (en) Patient information management system
CA2400160C (en) Method and system for distributing health information
US6734886B1 (en) Method of customizing a browsing experience on a world-wide-web site
US6820235B1 (en) Clinical trial data management system and method
US20020178031A1 (en) Method and apparatus for delivering healthcare
US7774213B2 (en) Apparatus and method for managing prescription benefits
US8443428B2 (en) Web based access to clinical records
US20030061073A1 (en) Method and system for displaying patient information
US20040111298A1 (en) Method of and system for integrating health information into a patient's record
US20110082794A1 (en) Client-centric e-health system and method with applications to long-term health and community care consumers, insurers, and regulators
US20060259331A1 (en) Medical records website and related methods
US20030023461A1 (en) Internet based therapy management system
US20110112860A1 (en) Medical treatment monitoring system and method
US20110131059A1 (en) Pharmacy benefits management method and apparatus
US20030158754A1 (en) Web-based method and system for maintaining and accessing medical records
US20040181314A1 (en) Healthcare system supporting multiple network connected fluid administration pumps
US20030200226A1 (en) System and method for interacting with legacy healthcare database systems
US20040172305A1 (en) Method and appartus for delivering healthcare
US20030187690A1 (en) Patient oriented point of care system and method implementing same
DE112004000378T5 (en) System for accessing patient information
EP2577599A1 (en) Managing research data for clinical drug trials
WO1998015910A1 (en) Global electronic medical record

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP