US20030139943A1 - Healthcare information system with clinical information exchange - Google Patents

Healthcare information system with clinical information exchange Download PDF

Info

Publication number
US20030139943A1
US20030139943A1 US10/052,659 US5265902A US2003139943A1 US 20030139943 A1 US20030139943 A1 US 20030139943A1 US 5265902 A US5265902 A US 5265902A US 2003139943 A1 US2003139943 A1 US 2003139943A1
Authority
US
United States
Prior art keywords
patient
information
application
clinical
events
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US10/052,659
Inventor
Carl Dvorak
Khiang Seow
Charles Young
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Epic Systems Corp
Original Assignee
Epic Systems Corp
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 Epic Systems Corp filed Critical Epic Systems Corp
Priority to US10/052,659 priority Critical patent/US20030139943A1/en
Assigned to EPIC SYSTEMS CORPORATION reassignment EPIC SYSTEMS CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: YOUNG, CHARLES, DVORAK, CARL D., SEOW, KHIANG
Priority to GB0418259A priority patent/GB2401459B/en
Priority to PCT/US2003/001805 priority patent/WO2003063050A2/en
Priority to GB0515004A priority patent/GB2421100A/en
Publication of US20030139943A1 publication Critical patent/US20030139943A1/en
Priority to US13/220,141 priority patent/US20120035961A1/en
Priority to US15/131,738 priority patent/US10181011B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • 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/60ICT 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 operation of medical equipment or devices
    • G16H40/67ICT 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 operation of medical equipment or devices for remote operation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • 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
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • 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
    • 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/60ICT 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 operation of medical equipment or devices
    • G16H40/63ICT 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 operation of medical equipment or devices for local operation
    • 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
    • G16H15/00ICT specially adapted for medical reports, e.g. generation or transmission thereof

Definitions

  • An emerging driving application for computerization in healthcare is electronic medical records.
  • Completely computerized medical records can dramatically assist in the intelligence of health care service delivery to patients.
  • the prompt sharing of critical patient information amongst the caregivers who might treat a particular patient becomes important.
  • This needs extends both within a large health care organization as well as to allied health care providers, such as referral sources in outside organizations, who may refer in patients and who already possess significant clinical information about the patients.
  • This need also arises in the exchange of information between distinct healthcare organizations, whether operating similar or dissimilar computer systems, who are also called on from time to time to efficiently exchange information about patients who need treatment at other institutions. There are no standards widely in use at this time to facilitate the exchange or dissemination of clinical or other information of this type.
  • the present invention is summarized in that a system for distributed computing in a health care environment in which multiple different applications are in use, connected on a common computer network, there is a clinical exchange server on the network, the clinical exchange server including memory, the clinical exchange server programmed to maintain a reference table, the reference table including a list of applications on the network and information about the patient identification number used by each application, to maintain a list of events reported to it by other applications on the network and to respond to inquiries from a first application about an event recorded by a second application by transmitting a query to the second application based on the information in the reference table and the list of reported events.
  • the present invention is intended to provide a flexible system of permitting the exchange of clinical data among disparate computer systems either in a common healthcare enterprise or between enterprises.
  • the present system is intended to permit a standard protocol for information exchange among computer systems collecting clinical data about patient in a simple protocol intended to minimize overhead.
  • a clinical exchange server in accordance with the present invention has as one of its advantages that it enables an interface for otherwise incompatible computer systems to share data about patients.
  • FIG. 1 is schematic diagram of the clinical exchange server of the present invention as integrated into a typical information system for a large health care institution.
  • FIG. 2 is an illustration of a data set of items of data that might be captured by a clinical exchange server.
  • FIG. 3 is a conceptual illustration of the use of the system of the present invention.
  • FIG. 4 is a schematic illustration of an intended use of the system of the present invention.
  • the device, system and method described here are intended to facilitate the exchange of information throughout a multifaceted health care enterprise and also between health case enterprises.
  • Modem health care organizations often offer a wide variety of health care services to their patients, including both in-patient and out-patient services as well as a long list of so-called ancillary services such as physical therapy, occupational therapy and home assistance or nursing care.
  • ancillary services such as physical therapy, occupational therapy and home assistance or nursing care.
  • the different applications are from different vendors who each specialize in a given sector or service within the environment, such as in-patient scheduling, laboratory results reporting, or managed care analysis. Often such applications communicate among themselves rather poorly.
  • This invention is intended to enable such an organization or enterprise to exchange certain defined information between applications and throughout the enterprise in a defined manner.
  • the system is based on the use of a clinical information exchange server device, referred to here sometimes by the acronym CIXSD.
  • the CIXSD is a dedicated server which communicates with the various computer applications operated by the enterprise.
  • the CIXSD serves as a central repository of patient identifying information and serves as a reference point which each different application can interrogate to find out certain defined information about events that have been recorded or tracked by any other application in the enterprise.
  • the term “event” refers to any category of event or patient encounter tracked or recorded by one of the computer software applications in the enterprise.
  • the CIXSD stores a set of identifying information about the patient and an event registry associated with each patient.
  • the event registry maintains data items for each event, including a minimized set of information about the event and an identification of the system that recorded and maintains a record of the event.
  • the event registry data item includes a categorization of the event and the location and system holding the information about the event, but not detailed data describing the event itself.
  • the event registry typically does not contain actual medical records data but contains instead identifiers that can be used to compose a query to the system maintaining data about the event so that the medical records application about the event on which it holds data.
  • the Master Patient Index It is not critical which application system is designated as maintaining the Master Patient Index, and the Master Patient Index can be a centralized or distributed index, as long some mechanism is maintained to list and separately identify all patients.
  • the CIXSD works in cooperation with the Master Patient Index but is not intended to be a replacement for it.
  • Each enterprise using a computer system has, or should have, a Master Patient Index which assigns a system-unique identification code for each unique patient.
  • the CIXSD does not address the issues of matching patients and monitoring access to patient data.
  • the CIXSD creates and maintains an event registry associated with each patient in the Master Patient Index.
  • the CIXSD may be a distinct dedicated server, or it can be implemented in a server which is also operating other concurrent functions.
  • the CIXSD may also be operated as a subsidiary functions of a system which serves as the Master Patient Index (MPI). While the MPI and CIXSD functions are distinct, since the CIXSD operates on the base of information provided to it by the MPI, the two functions can, if preferred, be operated by a single server. Some functionality needed for the CIXSD can be separately stored by the CIXSD server or can be stored by the MPI with which the CIXSD is associated.
  • MPI Master Patient Index
  • the Epic MPI provides an Patient Clinical Event History, which can be used by the CIXSD, but if another MPI does not itself support such a function, the CIXSD can support this function itself.
  • the Patient Clinical Event History is a registry of all important clinical events which have involved a particular patient.
  • the CIXSD should be a server, in the sense that it maintains a data registry and that it can be accessed by stations throughout the network to which it is connected.
  • THE CIXSD may or may not be a separate server from the server supporting the MPI function.
  • the CIXSD also includes a set of simple protocols designed to allow separate and distinct systems to exchange clinical information on a patient. Using these protocols, described in more detail below, distinct and separate systems can share patient clinical data in a manner that seems seamless to the user.
  • the CIXSD may also be defined by an interface designed to permit transferal of clinical information among systems.
  • FIG. 1 shown schematically in FIG. 1 is a health care enterprise network of computer systems.
  • each separate application in the network is resident on a separate server, and all the servers are connected onto a common network.
  • the overall system includes, in this example, a medical records server 12 , an outpatient records server 14 , a home health server 16 , a scheduling server 18 and a clinical information exchange server (CIXSD) 20 .
  • Each of the application servers is running the application program which its name implies, i.e. the medical records server is running a medical records program.
  • a plurality of independent users is illustrated by the terminals 22 , any of the users at any of the terminals 22 being able to operate any of the applications on any of the servers.
  • a remote access server 24 also supports access by remote users, illustrated by the remoter terminal 26 .
  • Each of the servers includes the appropriate computer components including a processor, random access memory and mass storage devices such as magnetic disk or tape drives.
  • the users access each of the systems over the common network, but, in essence, only access any one system at any one time.
  • FIG. 1 it is also envisioned that the hardware arrangement of FIG. 1 is only one of the many ways in which the systems can be physically configured.
  • each system might instead consist of a single processor with a number of dedicated terminals which only interact with that one computer to operate some special software system.
  • the CIXSD is intended to permit each of the applications in the enterprise to learn something about and to access information about patient events stored by other systems in the operation.
  • the CIXSD does not, and is not intended, to store all of the information stored by each application system about the patient event.
  • the CIXSD serves instead as a sort of pointer to direct any given application as to where to find information it may need to access in another application.
  • FIG. 2 Illustrated in FIG. 2 is an exemplary record for a patient as stored in a Master Patient Index implementing CIXSD.
  • the placement and organization of the data in the illustration of FIG. 2 is, of course, arbitrary, but what is important is the nature of the information maintained by the server device.
  • FIG. 2 at the top is a data item, “Enterprise ID#99832433” intended to indicate the name and enterprise identification number of the patient in the system hosting the CIXSD.
  • the CIXSD follows the convention of the server designated as the Master Patient Index in assigning the patient identification code to the patient.
  • the enterprise identification number is the name of the patient.
  • Below the patient master identification and name is a patient identification cross reference table.
  • This table is a look-up table to facilitate easy look up of the various patient identification numbers or codes assigned by each of the software applications in the enterprise to that identify the same patient.
  • This table includes an identification of the software applications and the patient identification numbers assigned to the patient by each separate software application. It is envisioned that some of the patient identifications will be assigned by diverse applications in the organization originating from different vendors. It is also envisioned that some of the identification codes refer to identification methods used by related organizations or remote medical practices with which the enterprise might, on occasion, share or cross-refer patients. Such entities are often called affiliates, and are referred to as such in FIG. 2. Thus in the table illustrated in FIG. 2, under the column heading “Id Type” is a listing of applications and affiliates and under the column heading “Patient #” is listed the identification number used by that application, or that affiliated facility, for that patient.
  • the CIXSD data base entry for this patient also includes certain additional identifying information about the patient such as gender, age and the like. This is illustrated in FIG. 2 right underneath the patient identification cross reference table.
  • the CIXSD data base also includes insurance information for the patient, since that information is likely to be needed quickly by many of the applications in the enterprise, and the insurance information is illustrated in the lower left portion of FIG. 2.
  • the CIXSD record for that patient includes an event registry, shown in part here under the heading “Patient Clinical Event History.”
  • the event registry is a summary or abstract of the detail on all events that are kept by any one of the application systems.
  • the CIXSD For each data item in the event registry, the CIXSD will keep a listing of the type of event, the date of the event, the application system holding data about the event and an assigned unique event number. The CIXSD does not attempt to keep a full record of all such events, but just an indication that the event occurred and an indication as to where to find additional information about the event. The indication as to where to find more information is the name of the host application which holds the event from which the event registry has abstracted this information.
  • the CIXSD can thus serve as an interpreter or intermediary to facilitate data transfer among different applications in the enterprise.
  • the CIXSD can receive a query from a first application system and sent an inquiry from a second application system to permit the first application to recover data it needs to process a request.
  • the billing system might need, for example, data about a procedure performed on a patient.
  • the billing application would send an inquiry to the CIXSD asking for information about the identification of an event kept by the medical records system on the patient on a given day.
  • the CIXSD knows the patient identifications for the patient in each system and can thus send an intelligent query to the medical records system to access the needed data to be returned to the billing system.
  • the particular software and detailed data structure of the CIXSD is not particularly critical and well within the skill of those which knowledge in the art to complete.
  • the CIXSD advantageously uses XML or HTML protocols to exchange data with the application systems. Many if not most current sophisticated application programs can use and transmit XML or HTML data because of the prevalence of the world wide web portion of the internet in computer communications. It is also contemplated that data exchange in this system can use the HL-7 data format commonly used by health care organizations to exchange data between computer systems.
  • the various applications send event abstracts to the CIXSD. These abstracts can be published to the other applications that can then store the data they might need for later processing. The abstracts are sent to the CIXSD that can add the appropriate identification codes before sending the information on to the appropriate server for the various applications. In general, the CIXSD itself will update its event registry for each such abstract that it processes so that the CIXSD has a complete inventory of all events which have occurred.
  • FIG. 3 is intended to illustrate the intended functioning of the CIXSD.
  • Four medical records application devices are indicated by the four boxes in the upper half of FIG. 3. Each device maintains and application which is maintaining its own set of data about the patient and events that involve that patient. Each application keeps identifying information about the patient using its own identification system.
  • the CIXSD in turn collects information about the events that have been recorded by each application device.
  • the CIXSD maintains an abstract of each such event and the abstracts are easily available to any other application in the network.
  • a home health nurse caring for a patient and using a portable computer to connect to the network of the health care enterprise The nurse mainly uses a software application designed for home health care, but can also use the CIXSD to access abstracts of events that were originally recorded in other application systems in the network.
  • the nurse would initially request information about the patient, as indicated at 31 .
  • the home health system application initially provides to the nurse's station a summary of the patient's medical record as indicated at 32 .
  • This summary included data from the master patient index identifying the patient and also includes an embedded event listing obtained from the CIXSD.
  • the nurse viewing this event listing may select an event, for example a hospital stay by the patient, and request an abstract of that event, as indicated at 33 .
  • the home health application sends a query to the CIXSD indicated at 34 .
  • the CIXSD consults the event registry and determines the date or dates of the event and determines from its own records where the information about the event is stored.
  • the CIXSD can then send a query to the application server storing the event, using identifiers known by that application, to get the information the nurse needs, as indicated at 35 .
  • the application generates a response, perhaps just an abstract of the needed data, and sends that back to the CIXSD (at 36 ), which can then deliver the data to the home health system and the nurse, as indicated at 37 .
  • the nurse can view the data through a conventional web browser, as indicated at 38 , if the information is transmitted and presented in XML or HTML format, or in HL-7 format.
  • the entire communication is invisible to the user and simple seems as if all the data is directly available to the nurse through his or her computer.
  • FIG. 4 Shown in FIG. 4 is a diagram which is intended to illustrate the intended use of the CIXSD system.
  • FIG. 4 rather than illustrating the physical attributes of the data interchange, the logical connections are shown.
  • Four systems for gathering and storing clinical data about the patient are illustrated across the top of the figure, an Inpatient Electronic Medical Records system, a first Outpatient Electronic Medical Records system, a second Outpatient Electronic Medical Records system, and a Home Health Medical Records system. It is not important if the systems are all within a common healthcare enterprise, or if they are hosted by separate but cooperating enterprises.
  • a computer network connects each of the systems to the CIXSD server shown at the bottom of FIG. 4.
  • the CIXSD maintains an event registry of all of the events stored by each system, lists the system holding the vent, stores the date of each event and assigns a unique event number to each event. Then each of the four systems can interrogate the CIXSD, as needed, to obtain information about events in the other systems. The CIXSD can interrogate each system in turn, to gain more data about an event in response to an inquiry from another one of the systems. In this way, each of the systems has access to the events stored by the others, yet no system needs to maintain the records or any interface information, about the other systems.
  • GetUpdates.asp which is a query intended to produce a list of events occurring for a particular patient.
  • GetDetails.asp a query intended to produce the details of a particular event.
  • Access AccessCodes/Required—A code used by the server to uniquely indemnify the client.
  • Id PatientID/Required—A string that identifies the patient on the server.
  • RefNo (LastRefNo/Optional)—An optional numeric value the server can use to restrict the range of events returned to the client. This reference number serves as a bookmark for the last access and in optionally retuned by the query.
  • HTML return format is not specified, an HTML table is returned showing the requested events.
  • the returned HTML page should not have ⁇ HTML> and ⁇ BODY> tags so that multiple returned pages can be concatenated together.
  • the first row of the table has the caption of each column and does not contain patient data.
  • Each row in the table does have:
  • a CIXSD may also provide the other information before and after the table.
  • the last access reference number is returned within a tag ⁇ LastRefNo>, e.g. ⁇ LastRefNo 3051999>
  • Other return formats are possible and envisioned.
  • the structure of the data can be varied. An optional standard XML return is specifically envisioned.
  • C. Error If an arror occurred during this query, an HTML page should be returned with the word “error” in the first line. Details of the error can be displayed in the returned HTML page. For XML, error conditions and error numbers with detailed error messages should be returned. The server should log errors for later and analysis and resolution.
  • the client must provide an audit reference string as part of the query. This audit reference uniquely identifies the client session. Information about the user, the workstation, and the session start and end times is retrievable using the reference string for at least some period of time such as 90 days.
  • AccessCode (required)—A string used by the server to uniquely identify the event.
  • ReportCode (required)—A string that identifies the report event on the server.
  • AuditRef (required)—A string supplied by the client that can be used by the server to trace the request. This is used for audit and policy enforcement.
  • the client must provide an audit reference string as part of the query. This audit reference uniquely identifies the client session. Information about the user, the workstation, and the session start and end time, are all retrievable using the reference string for at least some minimum period of time, such as 90 days.
  • the above specification of the CIXSD protocol is intended to provide an exemplar to one of skill in the art on how a CIXSD embodiment can be implemented.
  • the protocol provides security by requiring server and client to have matching access and security codes.
  • Each server can decide the patient information access policy of that server, the CIXSD just serving as the conduit for the request, the service of the request still being the responsibility of the application server.
  • the two specified interface processes are implemented in HTML for maximum compatibility and to make it easy for other systems to receive and respond to CIXSD requests. Note that the provision for an audit helps to ensure accountability by allowing requests and responses to be tracked and logged.
  • the protocol is flexible in permitting both minimal standard (i.e. HTML) and other more custom formats for data returned in response to a query. This permits use of the protocol across diverse systems.
  • HTML minimal standard
  • each server in the system must implement and support only the two defined web query interfaces describe above. Thus the burden for a new application to participate in a CIXSD enabled system is low.
  • a CIXSD server can server as a proxy system for two outside system servers to request information from a common base system server. Normally in a proxy set-up, the servers acting through the proxy would act as clients only, i.e. making information requests but not responding to requests. A CIXSD server acting as a proxy would only access its data depository in the base system server, although that server could be populated with events from any other servers.

Abstract

Modern healthcare enterprises often support complex computer networks for the many functions of the enterprise, and the networks are often running multiple incompatible application programs. Described here is a clinical server exchange device for such a complex network. The clinical exchange server maintains a master table of applications on the network and the patient identification used by each of the applications for each patient. The clinical exchange server can then serve as a sort of interpreter to allow each application to communicate through the clinical exchange server to obtain information from another application about the patient. To facilitate that exchange, each application sends to the clinical exchange server an abstract of any events involving the patient. The clinical exchange server system also envisions a protocol for information exchange, preferably through the clinical exchange server.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • Not applicable. [0001]
  • STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
  • Not applicable. [0002]
  • BACKGROUND OF THE INVENTION
  • Most health care institutions make extensive use of computers for record keeping and patient service. In fact, most health care providers rely on more than on type of computerized system. Typically providers of computerized systems for health care providers have tended to focus on one or more aspects of the total automation needs of health care providers and thus there are often at a single health care institution separate computer systems for billing and accounting, laboratory, in- or out-patient scheduling or tracking, medical records, appointments and others. Some such different systems may be different software packages while others may involve entirely different computer hardware systems as well. In some cases, all systems in an organization are linked by a network, but such a network connection alone does not ensure that the systems can cooperatively exchange information among the divergent systems in the network. Often the different systems communicate by way of one or more software interfaces that must be custom built for each pair of systems which must communicate, even on the same network. It is also a trend in the health care industry in general that different organizations can cross-refer or partner in one or more areas or for certain types of patients, and thus different organizations with entirely different computer systems and networks find a need to share patient data. [0003]
  • An emerging driving application for computerization in healthcare is electronic medical records. Completely computerized medical records can dramatically assist in the intelligence of health care service delivery to patients. However, to be completely effective, the prompt sharing of critical patient information amongst the caregivers who might treat a particular patient becomes important. This needs extends both within a large health care organization as well as to allied health care providers, such as referral sources in outside organizations, who may refer in patients and who already possess significant clinical information about the patients. This need also arises in the exchange of information between distinct healthcare organizations, whether operating similar or dissimilar computer systems, who are also called on from time to time to efficiently exchange information about patients who need treatment at other institutions. There are no standards widely in use at this time to facilitate the exchange or dissemination of clinical or other information of this type. [0004]
  • BRIEF SUMMARY OF THE INVENTION
  • The present invention is summarized in that a system for distributed computing in a health care environment in which multiple different applications are in use, connected on a common computer network, there is a clinical exchange server on the network, the clinical exchange server including memory, the clinical exchange server programmed to maintain a reference table, the reference table including a list of applications on the network and information about the patient identification number used by each application, to maintain a list of events reported to it by other applications on the network and to respond to inquiries from a first application about an event recorded by a second application by transmitting a query to the second application based on the information in the reference table and the list of reported events. [0005]
  • The present invention is intended to provide a flexible system of permitting the exchange of clinical data among disparate computer systems either in a common healthcare enterprise or between enterprises. [0006]
  • The present system is intended to permit a standard protocol for information exchange among computer systems collecting clinical data about patient in a simple protocol intended to minimize overhead. [0007]
  • A clinical exchange server in accordance with the present invention has as one of its advantages that it enables an interface for otherwise incompatible computer systems to share data about patients. [0008]
  • Other advantages, features, and objects of the present invention will become apparent from a detailed review of the following specification. [0009]
  • BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
  • FIG. 1 is schematic diagram of the clinical exchange server of the present invention as integrated into a typical information system for a large health care institution. [0010]
  • FIG. 2 is an illustration of a data set of items of data that might be captured by a clinical exchange server. [0011]
  • FIG. 3 is a conceptual illustration of the use of the system of the present invention. [0012]
  • FIG. 4 is a schematic illustration of an intended use of the system of the present invention.[0013]
  • DETAILED DESCRIPTION OF THE INVENTION
  • The device, system and method described here are intended to facilitate the exchange of information throughout a multifaceted health care enterprise and also between health case enterprises. Modem health care organizations often offer a wide variety of health care services to their patients, including both in-patient and out-patient services as well as a long list of so-called ancillary services such as physical therapy, occupational therapy and home assistance or nursing care. Typically in such organizations, there are a number of different computer software application programs serving different roles such as tracking patients, service, schedules, charges or medical results or records. Often the different applications are from different vendors who each specialize in a given sector or service within the environment, such as in-patient scheduling, laboratory results reporting, or managed care analysis. Often such applications communicate among themselves rather poorly. This invention is intended to enable such an organization or enterprise to exchange certain defined information between applications and throughout the enterprise in a defined manner. The system is based on the use of a clinical information exchange server device, referred to here sometimes by the acronym CIXSD. In brief, the CIXSD is a dedicated server which communicates with the various computer applications operated by the enterprise. The CIXSD serves as a central repository of patient identifying information and serves as a reference point which each different application can interrogate to find out certain defined information about events that have been recorded or tracked by any other application in the enterprise. In this context, the term “event” refers to any category of event or patient encounter tracked or recorded by one of the computer software applications in the enterprise. For example, and event could be a patient treatment encounter, a laboratory report, a chart entry, an accounting entry, or any other data item which is kept by one or another of the various medical information software applications in the enterprise. The CIXSD stores a set of identifying information about the patient and an event registry associated with each patient. The event registry maintains data items for each event, including a minimized set of information about the event and an identification of the system that recorded and maintains a record of the event. In short, the event registry data item includes a categorization of the event and the location and system holding the information about the event, but not detailed data describing the event itself. For example, the event registry typically does not contain actual medical records data but contains instead identifiers that can be used to compose a query to the system maintaining data about the event so that the medical records application about the event on which it holds data. [0014]
  • It is envisioned that for most computerized health care services enterprises, at least one computer server connected to the network for the enterprise will maintain a complete listing of all of the patients who are seen anywhere in the enterprise and patient unique identifiers for each such patient. This listing is referred to here as the Master Patient Index. It is not critical which application system is designated as maintaining the Master Patient Index, and the Master Patient Index can be a centralized or distributed index, as long some mechanism is maintained to list and separately identify all patients. The CIXSD works in cooperation with the Master Patient Index but is not intended to be a replacement for it. Each enterprise using a computer system has, or should have, a Master Patient Index which assigns a system-unique identification code for each unique patient. The CIXSD does not address the issues of matching patients and monitoring access to patient data. The CIXSD creates and maintains an event registry associated with each patient in the Master Patient Index. [0015]
  • Physically the CIXSD may be a distinct dedicated server, or it can be implemented in a server which is also operating other concurrent functions. The CIXSD may also be operated as a subsidiary functions of a system which serves as the Master Patient Index (MPI). While the MPI and CIXSD functions are distinct, since the CIXSD operates on the base of information provided to it by the MPI, the two functions can, if preferred, be operated by a single server. Some functionality needed for the CIXSD can be separately stored by the CIXSD server or can be stored by the MPI with which the CIXSD is associated. For example, the Epic MPI provides an Patient Clinical Event History, which can be used by the CIXSD, but if another MPI does not itself support such a function, the CIXSD can support this function itself. The Patient Clinical Event History is a registry of all important clinical events which have involved a particular patient. [0016]
  • The CIXSD should be a server, in the sense that it maintains a data registry and that it can be accessed by stations throughout the network to which it is connected. THE CIXSD may or may not be a separate server from the server supporting the MPI function. The CIXSD also includes a set of simple protocols designed to allow separate and distinct systems to exchange clinical information on a patient. Using these protocols, described in more detail below, distinct and separate systems can share patient clinical data in a manner that seems seamless to the user. The CIXSD may also be defined by an interface designed to permit transferal of clinical information among systems. [0017]
  • Thus, for purposes of illustration, shown schematically in FIG. 1 is a health care enterprise network of computer systems. In the illustration of FIG. 1, each separate application in the network is resident on a separate server, and all the servers are connected onto a common network. Thus the overall system includes, in this example, a medical records server [0018] 12, an outpatient records server 14, a home health server 16, a scheduling server 18 and a clinical information exchange server (CIXSD) 20. Each of the application servers is running the application program which its name implies, i.e. the medical records server is running a medical records program. A plurality of independent users is illustrated by the terminals 22, any of the users at any of the terminals 22 being able to operate any of the applications on any of the servers. A remote access server 24 also supports access by remote users, illustrated by the remoter terminal 26. Each of the servers includes the appropriate computer components including a processor, random access memory and mass storage devices such as magnetic disk or tape drives. The users access each of the systems over the common network, but, in essence, only access any one system at any one time.
  • It is also envisioned that the hardware arrangement of FIG. 1 is only one of the many ways in which the systems can be physically configured. For example, each system might instead consist of a single processor with a number of dedicated terminals which only interact with that one computer to operate some special software system. Or there may be dedicated networks operating only a single operation which care connected to each other only by specific limited linkages. Whichever configuration is used, the dedicated computers or servers still must communicate in some way with other computers or networks in the enterprise by a communication interface device or software. [0019]
  • The CIXSD is intended to permit each of the applications in the enterprise to learn something about and to access information about patient events stored by other systems in the operation. The CIXSD does not, and is not intended, to store all of the information stored by each application system about the patient event. The CIXSD serves instead as a sort of pointer to direct any given application as to where to find information it may need to access in another application. [0020]
  • Illustrated in FIG. 2 is an exemplary record for a patient as stored in a Master Patient Index implementing CIXSD. The placement and organization of the data in the illustration of FIG. 2 is, of course, arbitrary, but what is important is the nature of the information maintained by the server device. Referring to FIG. 2, at the top is a data item, “[0021] Enterprise ID#99832433” intended to indicate the name and enterprise identification number of the patient in the system hosting the CIXSD. The CIXSD follows the convention of the server designated as the Master Patient Index in assigning the patient identification code to the patient. Immediately below the enterprise identification number is the name of the patient. Below the patient master identification and name is a patient identification cross reference table. This table is a look-up table to facilitate easy look up of the various patient identification numbers or codes assigned by each of the software applications in the enterprise to that identify the same patient. This table includes an identification of the software applications and the patient identification numbers assigned to the patient by each separate software application. It is envisioned that some of the patient identifications will be assigned by diverse applications in the organization originating from different vendors. It is also envisioned that some of the identification codes refer to identification methods used by related organizations or remote medical practices with which the enterprise might, on occasion, share or cross-refer patients. Such entities are often called affiliates, and are referred to as such in FIG. 2. Thus in the table illustrated in FIG. 2, under the column heading “Id Type” is a listing of applications and affiliates and under the column heading “Patient #” is listed the identification number used by that application, or that affiliated facility, for that patient.
  • As illustrated as well in FIG. 2, the CIXSD data base entry for this patient also includes certain additional identifying information about the patient such as gender, age and the like. This is illustrated in FIG. 2 right underneath the patient identification cross reference table. The CIXSD data base also includes insurance information for the patient, since that information is likely to be needed quickly by many of the applications in the enterprise, and the insurance information is illustrated in the lower left portion of FIG. 2. Finally, the CIXSD record for that patient includes an event registry, shown in part here under the heading “Patient Clinical Event History.” The event registry is a summary or abstract of the detail on all events that are kept by any one of the application systems. For each data item in the event registry, the CIXSD will keep a listing of the type of event, the date of the event, the application system holding data about the event and an assigned unique event number. The CIXSD does not attempt to keep a full record of all such events, but just an indication that the event occurred and an indication as to where to find additional information about the event. The indication as to where to find more information is the name of the host application which holds the event from which the event registry has abstracted this information. [0022]
  • The CIXSD can thus serve as an interpreter or intermediary to facilitate data transfer among different applications in the enterprise. The CIXSD can receive a query from a first application system and sent an inquiry from a second application system to permit the first application to recover data it needs to process a request. The billing system might need, for example, data about a procedure performed on a patient. In this instance, the billing application would send an inquiry to the CIXSD asking for information about the identification of an event kept by the medical records system on the patient on a given day. The CIXSD knows the patient identifications for the patient in each system and can thus send an intelligent query to the medical records system to access the needed data to be returned to the billing system. The particular software and detailed data structure of the CIXSD is not particularly critical and well within the skill of those which knowledge in the art to complete. The CIXSD advantageously uses XML or HTML protocols to exchange data with the application systems. Many if not most current sophisticated application programs can use and transmit XML or HTML data because of the prevalence of the world wide web portion of the internet in computer communications. It is also contemplated that data exchange in this system can use the HL-7 data format commonly used by health care organizations to exchange data between computer systems. [0023]
  • It is also preferable if the various applications send event abstracts to the CIXSD. These abstracts can be published to the other applications that can then store the data they might need for later processing. The abstracts are sent to the CIXSD that can add the appropriate identification codes before sending the information on to the appropriate server for the various applications. In general, the CIXSD itself will update its event registry for each such abstract that it processes so that the CIXSD has a complete inventory of all events which have occurred. [0024]
  • FIG. 3 is intended to illustrate the intended functioning of the CIXSD. Four medical records application devices are indicated by the four boxes in the upper half of FIG. 3. Each device maintains and application which is maintaining its own set of data about the patient and events that involve that patient. Each application keeps identifying information about the patient using its own identification system. The CIXSD in turn collects information about the events that have been recorded by each application device. The CIXSD maintains an abstract of each such event and the abstracts are easily available to any other application in the network. [0025]
  • As an example, consider a home health nurse caring for a patient and using a portable computer to connect to the network of the health care enterprise. The nurse mainly uses a software application designed for home health care, but can also use the CIXSD to access abstracts of events that were originally recorded in other application systems in the network. The nurse would initially request information about the patient, as indicated at [0026] 31. The home health system application initially provides to the nurse's station a summary of the patient's medical record as indicated at 32. This summary included data from the master patient index identifying the patient and also includes an embedded event listing obtained from the CIXSD. The nurse viewing this event listing may select an event, for example a hospital stay by the patient, and request an abstract of that event, as indicated at 33. To process that request, the home health application sends a query to the CIXSD indicated at 34. The CIXSD consults the event registry and determines the date or dates of the event and determines from its own records where the information about the event is stored. The CIXSD can then send a query to the application server storing the event, using identifiers known by that application, to get the information the nurse needs, as indicated at 35. The application generates a response, perhaps just an abstract of the needed data, and sends that back to the CIXSD (at 36), which can then deliver the data to the home health system and the nurse, as indicated at 37. The nurse can view the data through a conventional web browser, as indicated at 38, if the information is transmitted and presented in XML or HTML format, or in HL-7 format. The entire communication is invisible to the user and simple seems as if all the data is directly available to the nurse through his or her computer.
  • Shown in FIG. 4 is a diagram which is intended to illustrate the intended use of the CIXSD system. In FIG. 4, rather than illustrating the physical attributes of the data interchange, the logical connections are shown. Four systems for gathering and storing clinical data about the patient are illustrated across the top of the figure, an Inpatient Electronic Medical Records system, a first Outpatient Electronic Medical Records system, a second Outpatient Electronic Medical Records system, and a Home Health Medical Records system. It is not important if the systems are all within a common healthcare enterprise, or if they are hosted by separate but cooperating enterprises. A computer network connects each of the systems to the CIXSD server shown at the bottom of FIG. 4. The CIXSD maintains an event registry of all of the events stored by each system, lists the system holding the vent, stores the date of each event and assigns a unique event number to each event. Then each of the four systems can interrogate the CIXSD, as needed, to obtain information about events in the other systems. The CIXSD can interrogate each system in turn, to gain more data about an event in response to an inquiry from another one of the systems. In this way, each of the systems has access to the events stored by the others, yet no system needs to maintain the records or any interface information, about the other systems. [0027]
  • In order to implement a CIXSD system using a web based HTML protocol, two specific interfaces are preferred. The first is called GetUpdates.asp, which is a query intended to produce a list of events occurring for a particular patient. The second is called GetDetails.asp, which is a query intended to produce the details of a particular event. These merit some description. What follows is a definition of the preferred parameters of these two interfaces. [0028]
  • [0029] 1. GetUpdates.asp
  • A. Input Parameeters: [0030]
  • (i) Access (AccessCodes/Required)—A code used by the server to uniquely indemnify the client. [0031]
  • (ii) Id (PatientID/Required)—A string that identifies the patient on the server. [0032]
  • (iii) Audit (AuditRef/Required)—A string supplied by the client that can be used by the server to trace the request. This is used for audit and policy enforcement. [0033]
  • (iv) RefNo (LastRefNo/Optional)—An optional numeric value the server can use to restrict the range of events returned to the client. This reference number serves as a bookmark for the last access and in optionally retuned by the query. [0034]
  • (v) Days (DateRange/Optional)—This number instructs this server to return events within the past specified dates (only used if LastRefNo is not specified). [0035]
  • (vi) Format (OutputFormat/Optional)—All servers are specified to return the query in HTML format. In addition, the server may support other formats (such as XML or proprietary format). Default is HTML. [0036]
  • Sample Queries: [0037]
  • http://Epic700/CES/update.asp?access=elctrosolor&ID=845&audit=391488588&refNo=60285 [0038]
  • http://Epic700/CES/update.asp?access=elctrosolor&ID=97110301&audit=3858 811&days=300&format=×[0039]
  • B. Returned formats: [0040]
  • If HTML return format is not specified, an HTML table is returned showing the requested events. The returned HTML page should not have <HTML> and <BODY> tags so that multiple returned pages can be concatenated together. The first row of the table has the caption of each column and does not contain patient data. Each row in the table does have: [0041]
  • (i) [0042] Column 1—Date—Date of event occurrence (required).
  • (ii) [0043] Column 2—Type—A short phrase of the event type (required).
  • (iii) Column 3—Description—A short sentence description (optional). [0044]
  • (iv) [0045] Column 4—OtherData—Other data the server may want to provide. The use of this field is for custom systems and the internal format of this filed is by agreement between the server and client (optional). It may contain information such as the provider, the clinic, the reason for the visit or any similar data.
  • (v) [0046] Column 5—ReportCode—A code with which a detail report on the event may be retrieved (optional).
  • In addition to the table, a CIXSD may also provide the other information before and after the table. The last access reference number is returned within a tag <LastRefNo>, e.g. <LastRefNo 3051999> Other return formats are possible and envisioned. The structure of the data can be varied. An optional standard XML return is specifically envisioned. [0047]
  • C. Error: If an arror occurred during this query, an HTML page should be returned with the word “error” in the first line. Details of the error can be displayed in the returned HTML page. For XML, error conditions and error numbers with detailed error messages should be returned. The server should log errors for later and analysis and resolution. [0048]
  • D. Logging: The client must provide an audit reference string as part of the query. This audit reference uniquely identifies the client session. Information about the user, the workstation, and the session start and end times is retrievable using the reference string for at least some period of time such as [0049] 90 days.
  • 2. GetDetails.asp [0050]
  • A. Input Parameters [0051]
  • (i) AccessCode (required)—A string used by the server to uniquely identify the event. [0052]
  • (ii) ReportCode (required)—A string that identifies the report event on the server. [0053]
  • (iii) AuditRef (required)—A string supplied by the client that can be used by the server to trace the request. This is used for audit and policy enforcement. [0054]
  • B. Returned Value: An HTML page of the report is returned. [0055]
  • C. Error: If an error occurred during this query, an HTML page should be returned with the word “error” in the first line. Details of the error can be displayed in the returned HTML page. The server should log any errors for later analysis and resolution. [0056]
  • D. Logging: The client must provide an audit reference string as part of the query. This audit reference uniquely identifies the client session. Information about the user, the workstation, and the session start and end time, are all retrievable using the reference string for at least some minimum period of time, such as 90 days. [0057]
  • The above specification of the CIXSD protocol is intended to provide an exemplar to one of skill in the art on how a CIXSD embodiment can be implemented. The protocol provides security by requiring server and client to have matching access and security codes. Each server can decide the patient information access policy of that server, the CIXSD just serving as the conduit for the request, the service of the request still being the responsibility of the application server. The two specified interface processes are implemented in HTML for maximum compatibility and to make it easy for other systems to receive and respond to CIXSD requests. Note that the provision for an audit helps to ensure accountability by allowing requests and responses to be tracked and logged. [0058]
  • The protocol is flexible in permitting both minimal standard (i.e. HTML) and other more custom formats for data returned in response to a query. This permits use of the protocol across diverse systems. To support the CIXSD, each server in the system must implement and support only the two defined web query interfaces describe above. Thus the burden for a new application to participate in a CIXSD enabled system is low. [0059]
  • It is specifically envisioned that the CIXSD capability can be implemented through a proxy. A CIXSD server can server as a proxy system for two outside system servers to request information from a common base system server. Normally in a proxy set-up, the servers acting through the proxy would act as clients only, i.e. making information requests but not responding to requests. A CIXSD server acting as a proxy would only access its data depository in the base system server, although that server could be populated with events from any other servers. [0060]

Claims (13)

I/we claim:
1. In a system for distributed computing in a health care environment in which multiple different applications are in use connected on a common computer network, the improvement comprising
a clinical exchange server on the network, the clinical exchange server including memory, the clinical exchange server programmed (i) to maintain a reference table, the reference table including a list of applications on the network and information about the patient identification number used by each application, (ii) to maintain a list of events reported to it by other applications on the network and (iii) to respond to inquiries from a first application about an event recorded by a second application by transmitting a query to the second application based on the information in the reference table and the list of reported events.
2. The system as claimed in claim 1 wherein the clinical exchange server also maintains an abstract about the events sent to it to facilitate exchange of information between the applications.
3. The system as claimed in claim 1 wherein the reference table includes a master patient index identification code assigned to the patient as well as the application specific identification code assigned to the patient by each application.
4. The system as claimed in claim 1 wherein the clinical exchange server also stores health insurance information about each patient so that such health insurance information can easily be accessed by any of the applications.
5. A computer network for operation by a healthcare delivery enterprise, the network including a plurality of servers operating a plurality of application programs, the network comprising
a clinical exchange server including a storage device, the clinical exchange server programmed to store in the storage device a reference table, the reference including a master patient identifier for each patient, a list of application programs, and any separate identifying code used for the patient by any of the application programs, so that the identifying code used by an application for a patient can be found by accessing the reference table, the clinical exchange server further programmed to facilitate information exchange between the applications by using the reference table to extract information from an application requested by another application.
6. The computer network of claim 5 wherein the clinical exchange server also maintains a table of events associated with patients, the table of events including identifying information about the events and the identification of the application holding information about the event.
7. The computer network of claim 6 wherein the event table also includes an abstract about each of the events.
8. The computer network of claim 5 wherein the clinical exchange server also maintain health insurance information about the patient that can be access by another application.
9. A process for allowing interchange of information among communicating computer systems which have collected healthcare information about patients, the information stored in the form of events, the process comprising constructing the systems to support the following two interfaces:
a get updates interface that includes information identifying the patient and the requesting system and returns a data table containing a description of events stored by other systems involving the patient; and
a get detail interface that includes information identifying the patient, the requesting system and the event and returns a detailed description of the event.
10. A process as claimed in claim 9 wherein the two interfaces are always routed through a clinical exchange server that maintains a list of events and the location of the systems storing data about those events.
11. A process as claimed in claim 9 wherein the two interfaces are implemented in HTML format, XML format, HL-7 format or a combination of those formats.
12. A process as claimed in claim 9 wherein each interface request also includes access identifying information to provide security for the information exchange, with the retrieval of information being restricted by organization and identity of the requesting person.
13. A process as claimed in claim 9 wherein each interface request also includes an audit string to uniquely identify each request for auditing purposes.
US10/052,659 2002-01-18 2002-01-18 Healthcare information system with clinical information exchange Abandoned US20030139943A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US10/052,659 US20030139943A1 (en) 2002-01-18 2002-01-18 Healthcare information system with clinical information exchange
GB0418259A GB2401459B (en) 2002-01-18 2003-01-17 Healthcare information system with clinical information exchange
PCT/US2003/001805 WO2003063050A2 (en) 2002-01-18 2003-01-17 Healthcare information system with clinical information exchange
GB0515004A GB2421100A (en) 2002-01-18 2003-01-17 Patient healthcare information system
US13/220,141 US20120035961A1 (en) 2002-01-18 2011-08-29 Healthcare information system with clinical information exchange
US15/131,738 US10181011B2 (en) 2002-01-18 2016-04-18 Healthcare information system with clinical information exchange

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/052,659 US20030139943A1 (en) 2002-01-18 2002-01-18 Healthcare information system with clinical information exchange

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/220,141 Continuation US20120035961A1 (en) 2002-01-18 2011-08-29 Healthcare information system with clinical information exchange

Publications (1)

Publication Number Publication Date
US20030139943A1 true US20030139943A1 (en) 2003-07-24

Family

ID=21979057

Family Applications (3)

Application Number Title Priority Date Filing Date
US10/052,659 Abandoned US20030139943A1 (en) 2002-01-18 2002-01-18 Healthcare information system with clinical information exchange
US13/220,141 Abandoned US20120035961A1 (en) 2002-01-18 2011-08-29 Healthcare information system with clinical information exchange
US15/131,738 Expired - Fee Related US10181011B2 (en) 2002-01-18 2016-04-18 Healthcare information system with clinical information exchange

Family Applications After (2)

Application Number Title Priority Date Filing Date
US13/220,141 Abandoned US20120035961A1 (en) 2002-01-18 2011-08-29 Healthcare information system with clinical information exchange
US15/131,738 Expired - Fee Related US10181011B2 (en) 2002-01-18 2016-04-18 Healthcare information system with clinical information exchange

Country Status (3)

Country Link
US (3) US20030139943A1 (en)
GB (2) GB2421100A (en)
WO (1) WO2003063050A2 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070168223A1 (en) * 2005-10-12 2007-07-19 Steven Lawrence Fors Configurable clinical information system and method of use
US20090240681A1 (en) * 2008-03-20 2009-09-24 Nadeem Saddiqi Medical records network
US20100268546A1 (en) * 2003-09-30 2010-10-21 Thomson Healthcare Inc. Internet delivery system
US20110231210A1 (en) * 2007-10-30 2011-09-22 Onemednet Corporation Methods, systems, and devices for modifying medical files
US20120124080A1 (en) * 2010-11-16 2012-05-17 Mckesson Financial Holdings Limited Method, apparatus and computer program product for utilizing dynamically defined java implementations for creation of an efficient typed storage
WO2014042986A1 (en) * 2012-09-11 2014-03-20 Theranos, Inc. Information management systems and methods using a biological signature
US9129046B2 (en) 2013-02-25 2015-09-08 4medica, Inc. Systems and methods for managing a master patient index including duplicate record detection
US9171344B2 (en) 2007-10-30 2015-10-27 Onemednet Corporation Methods, systems, and devices for managing medical images and records
US9760677B2 (en) 2009-04-29 2017-09-12 Onemednet Corporation Methods, systems, and devices for managing medical images and records
US10074147B2 (en) 2010-06-16 2018-09-11 Parexel International Corporation Integrated clinical trial workflow system
US10572461B2 (en) 2013-02-25 2020-02-25 4medica, Inc. Systems and methods for managing a master patient index including duplicate record detection

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150278297A1 (en) * 2014-03-28 2015-10-01 Caradigm Usa Llc Methods, apparatuses and computer program products for providing a speed table for analytical models
US11429679B1 (en) * 2015-07-17 2022-08-30 EMC IP Holding Company LLC System and method for augmenting element records associated with the elements of a distributed computing environment with user-defined content
US11670405B2 (en) 2018-07-12 2023-06-06 Direct Supply, Inc. Apparatus for clinical data capture
US11640504B2 (en) 2019-05-17 2023-05-02 Samsung Electronics Co., Ltd. Electronic apparatus and controlling method thereof
US11283693B2 (en) * 2019-08-12 2022-03-22 Microsoft Technology Licensing, Llc Summarized event data responsive to a query

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5544255A (en) * 1994-08-31 1996-08-06 Peripheral Vision Limited Method and system for the capture, storage, transport and authentication of handwritten signatures
US5594638A (en) * 1993-12-29 1997-01-14 First Opinion Corporation Computerized medical diagnostic system including re-enter function and sensitivity factors
US6263330B1 (en) * 1998-02-24 2001-07-17 Luc Bessette Method and apparatus for the management of data files
US20020010679A1 (en) * 2000-07-06 2002-01-24 Felsher David Paul Information record infrastructure, system and method
US20050102374A1 (en) * 1999-12-09 2005-05-12 Zephyr Media, Inc. System and method for integration of a universally publicly accessible global network
US7013298B1 (en) * 1996-07-30 2006-03-14 Hyperphrase Technologies, Llc Method and system for automated data storage and retrieval

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5890129A (en) * 1997-05-30 1999-03-30 Spurgeon; Loren J. System for exchanging health care insurance information
WO2000065522A2 (en) * 1999-04-28 2000-11-02 San Diego State University Foundation Electronic medical record registry including data replication
US7017161B1 (en) * 1999-10-11 2006-03-21 Dictaphone Corporation System and method for interfacing a radiology information system to a central dictation system
US6757898B1 (en) * 2000-01-18 2004-06-29 Mckesson Information Solutions, Inc. Electronic provider—patient interface system
US7542911B2 (en) * 2000-02-28 2009-06-02 International Business Machines Corporation Method for electronically maintaining medical information between patients and physicians
US7953615B2 (en) * 2000-04-03 2011-05-31 Mitchell International, Inc. System and method of administering, tracking and managing of claims processing
US6718489B1 (en) * 2000-12-07 2004-04-06 Unisys Corporation Electronic service request generator for automatic fault management system
US7171415B2 (en) * 2001-05-04 2007-01-30 Sun Microsystems, Inc. Distributed information discovery through searching selected registered information providers

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5594638A (en) * 1993-12-29 1997-01-14 First Opinion Corporation Computerized medical diagnostic system including re-enter function and sensitivity factors
US5544255A (en) * 1994-08-31 1996-08-06 Peripheral Vision Limited Method and system for the capture, storage, transport and authentication of handwritten signatures
US7013298B1 (en) * 1996-07-30 2006-03-14 Hyperphrase Technologies, Llc Method and system for automated data storage and retrieval
US6263330B1 (en) * 1998-02-24 2001-07-17 Luc Bessette Method and apparatus for the management of data files
US20050102374A1 (en) * 1999-12-09 2005-05-12 Zephyr Media, Inc. System and method for integration of a universally publicly accessible global network
US20020010679A1 (en) * 2000-07-06 2002-01-24 Felsher David Paul Information record infrastructure, system and method

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8671113B2 (en) * 2003-09-30 2014-03-11 Jeffrey Raymond Reihl Internet delivery system
US20100268546A1 (en) * 2003-09-30 2010-10-21 Thomson Healthcare Inc. Internet delivery system
US20070168223A1 (en) * 2005-10-12 2007-07-19 Steven Lawrence Fors Configurable clinical information system and method of use
US8386278B2 (en) 2007-10-30 2013-02-26 Onemednet Corporation Methods, systems, and devices for managing transfer of medical files
US9171344B2 (en) 2007-10-30 2015-10-27 Onemednet Corporation Methods, systems, and devices for managing medical images and records
US8090596B2 (en) 2007-10-30 2012-01-03 Onemednet Corporation Methods, systems, and devices for transferring medical files from a source facility to a destination facility
US8099307B2 (en) 2007-10-30 2012-01-17 Onemednet Corporation Methods, systems, and devices for managing medical files
US8108228B2 (en) 2007-10-30 2012-01-31 Onemednet Corporation Methods, systems, and devices for transferring medical files
US8121870B2 (en) 2007-10-30 2012-02-21 Onemednet Corporation Methods, systems, and devices for verifying and approving government required release forms
US8131569B2 (en) 2007-10-30 2012-03-06 Onemednet Corporation Methods, systems, and devices for modifying medical files
US20110231209A1 (en) * 2007-10-30 2011-09-22 Onemednet Corporation Methods, systems, and devices for transferring medical files
US8195483B2 (en) 2007-10-30 2012-06-05 Onemednet Corporation Methods, systems, and devices for controlling a permission-based workflow process for transferring medical files
US20110231210A1 (en) * 2007-10-30 2011-09-22 Onemednet Corporation Methods, systems, and devices for modifying medical files
US20090240681A1 (en) * 2008-03-20 2009-09-24 Nadeem Saddiqi Medical records network
US9760677B2 (en) 2009-04-29 2017-09-12 Onemednet Corporation Methods, systems, and devices for managing medical images and records
US10074147B2 (en) 2010-06-16 2018-09-11 Parexel International Corporation Integrated clinical trial workflow system
US11232377B2 (en) 2010-06-16 2022-01-25 Calyx Services Inc. Integrated clinical trial workflow system
US20120124080A1 (en) * 2010-11-16 2012-05-17 Mckesson Financial Holdings Limited Method, apparatus and computer program product for utilizing dynamically defined java implementations for creation of an efficient typed storage
WO2014042986A1 (en) * 2012-09-11 2014-03-20 Theranos, Inc. Information management systems and methods using a biological signature
EP2895622A4 (en) * 2012-09-11 2016-05-18 Theranos Inc Information management systems and methods using a biological signature
US9129046B2 (en) 2013-02-25 2015-09-08 4medica, Inc. Systems and methods for managing a master patient index including duplicate record detection
US9262584B2 (en) 2013-02-25 2016-02-16 4medica, Inc. Systems and methods for managing a master patient index including duplicate record detection
US10025904B2 (en) 2013-02-25 2018-07-17 4medica, Inc. Systems and methods for managing a master patient index including duplicate record detection
US10572461B2 (en) 2013-02-25 2020-02-25 4medica, Inc. Systems and methods for managing a master patient index including duplicate record detection

Also Published As

Publication number Publication date
GB2401459B (en) 2005-10-12
GB2401459A (en) 2004-11-10
WO2003063050A2 (en) 2003-07-31
GB2421100A (en) 2006-06-14
US10181011B2 (en) 2019-01-15
US20120035961A1 (en) 2012-02-09
GB0515004D0 (en) 2005-08-31
US20160232305A1 (en) 2016-08-11
WO2003063050A3 (en) 2004-07-29
GB0418259D0 (en) 2004-09-15

Similar Documents

Publication Publication Date Title
US10181011B2 (en) Healthcare information system with clinical information exchange
CA2329598C (en) Method and apparatus for the management of data files
US10698922B2 (en) System and method for providing patient record synchronization in a healthcare setting
US7814169B2 (en) System and method for establishing and retrieving data based on global indices
CA2239015C (en) Method and apparatus for the management of data files
US6263330B1 (en) Method and apparatus for the management of data files
CA2397907C (en) Electronic provider-patient interface system
US8326865B2 (en) Optimized method of locating complete aggregation of patient health records in a global domain
US20070016450A1 (en) Global health information system
US20080140723A1 (en) Pre-Fetching Patient Data for Virtual Worklists
WO2007123930A2 (en) Method and architecture for goal oriented applications, configurations and workflow solutions on-the-fly
CN1983317A (en) Method and system for data scheduling
EP2191615A2 (en) Healthcare semantic interoperability platform
KR100706765B1 (en) System and Method for Unified Management of Medical Documents
JP4932861B2 (en) Distributed information access system, distributed information access method and program
US20120179490A1 (en) Trusted Partner Medical Records System and Method
US20140129258A1 (en) System and Method for Generating and Implementing a Stateless Patient History Module
KR101524181B1 (en) A system for exchanging clinical information based on lazy response model and the method thereof
WO2000003526A1 (en) System and method for establishing and retrieving data based on global indices
WO2002019222A1 (en) Health-related information distribution system
KR100817434B1 (en) System for medical management and service method thereof
WO2002037397A2 (en) Method and apparatus for the management of data files
Bennett et al. Data Warehousing in Regional Health Information Organizations
Della Valle et al. Applying Semantic Web Service Technology in the Healthcare Environment
KR20020026038A (en) Method and apparatus for servicing custom-made health information using internet

Legal Events

Date Code Title Description
AS Assignment

Owner name: EPIC SYSTEMS CORPORATION, WISCONSIN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DVORAK, CARL D.;SEOW, KHIANG;YOUNG, CHARLES;REEL/FRAME:012912/0063;SIGNING DATES FROM 20020405 TO 20020408

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION