WO2005067662A2 - Method and apparatus for simulating healthcare data - Google Patents

Method and apparatus for simulating healthcare data Download PDF

Info

Publication number
WO2005067662A2
WO2005067662A2 PCT/US2005/000613 US2005000613W WO2005067662A2 WO 2005067662 A2 WO2005067662 A2 WO 2005067662A2 US 2005000613 W US2005000613 W US 2005000613W WO 2005067662 A2 WO2005067662 A2 WO 2005067662A2
Authority
WO
WIPO (PCT)
Prior art keywords
healthcare
simulating
data
information
customer
Prior art date
Application number
PCT/US2005/000613
Other languages
French (fr)
Other versions
WO2005067662A3 (en
Inventor
Randy D. Reece
Terri B. Schoenrock
George C. Mager
Erwin Goldberg
Original Assignee
Rcs Mager, Inc.
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 Rcs Mager, Inc. filed Critical Rcs Mager, Inc.
Publication of WO2005067662A2 publication Critical patent/WO2005067662A2/en
Publication of WO2005067662A3 publication Critical patent/WO2005067662A3/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Administration; Management
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/50—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for simulation or modelling of medical disorders

Definitions

  • the present invention relates generally to data processing methods and systems, and more particularly to an improved method and apparatus for the simulation of healthcare data for healthcare providers and payers.
  • the healthcare environment has very complex data processing requirements, more than can be supported by any one healthcare system vendor.
  • As a result there are large amounts of patient information distributed across many systems built by different vendors.
  • the current trend is toward consolidation of all patient medical information across this multitude of heterogeneous systems. Collectively, this information is known as Patient Health Information.
  • Health Level 7 has been widely accepted as a method for communications between many of these systems. It has also been widely accepted as a messaging envelope for communications for technologies such as imaging (which has standardized on the DICOM protocol) and medical knowledge (which can be communicated using protocols such as the Arden Syntax).
  • Some of the healthcare systems that can be interconnected include Admissions, Discharge, and Transfers (ADT); Laboratories; Medical Imaging; Pathology; Pharmacies; Dictation/Transcription; Medical Records; Billing and Accounting Systems; and Payors.
  • a healthcare system provider can have multiple instances of each of these systems, as well as others not listed. In many cases, these systems (even those in the same categories) may have different interface and application protocols. As new systems are developed and deployed by healthcare providers and vendors, they must work in unison with other healthcare systems already in place. It is highly unusual for a healthcare provider to replace all of its healthcare systems at one time. If, for example, a healthcare provider is purchasing a new laboratory system, it must interface that system properly with each of its other systems already in production. This is a very complex task.
  • the method and apparatus for simulating healthcare data of this invention provides for the automated creation and communication of data between any and all of the potential healthcare computer systems for a given healthcare provider or vendor.
  • the data generated conforms to configurable statistical models which simulate any given subset of the human population and the healthcare systems that population might require.
  • Demographics including name, gender, date of birth, height, weight, addresses, race, nationality, and next of kin;
  • the inventive method and apparatus simulates all patient health information required for healthcare providers and payers worldwide. It includes a set of computer programs that can be implemented in a number of ways, including: Web services, Web products, Stand-alone installations, Client-server applications, and combinations of the above.
  • the inventive method and apparatus can be transported via any computer-readable medium or electronic distribution. Its execution can be distributed among any number of computer systems.
  • the data generated can be stored and transmitted electronically, printed, or faxed.
  • the inventive method and apparatus would typically be used in two areas of a general System Lifecycle plan, for Data Modeling tasks and for Data Generation tasks.
  • a further object or feature of the present invention is a new and improved method and apparatus to simulate patient health information for healthcare providers and payers.
  • An even further object of the present invention is to provide a novel method and apparatus for simulating healthcare data.
  • FIG. 1 (Prior Art) is a schematic view of some of the typical relationships between various healthcare systems
  • FIG. 2 (Prior Art) is a schematic illustration of a healthcare system that includes many of the devices that can be simulated by the present invention
  • FIG. 3 is a system overview of the method and apparatus for simulating healthcare of this invention
  • FIG. 4 is a schematic view of a general System Lifecycle plan, illustrating the invention's application for Data Modeling and Data Generation tasks;
  • FIG. 5 is a list of device types that may be used in or with the invention.
  • FIG. 6 lists the interface protocols for each real device
  • FIG. 7 lists the application protocols to be used by the device and its interface
  • FIG. 8 is a schematic view of a Use Case Model
  • FIG. 9 is an example of a Dynamic Interaction Model
  • FIG. 10 is an example of a Dynamic Definition: ADT/ACK
  • FIG. 11 is an example of a Static Definition - Message Level
  • FIG. 12 is an example of a Static Definition - Segment Level
  • FIG. 13 is an example of a Static Definition - Field Level
  • FIG. 14 is an example of the variables defined in a Medical Case History.
  • FIG. 15 illustrates some of the default coding systems for demographics and distributions used by the invention.
  • Fig. 1 is a schematic view of some of the prior art relationships between various healthcare systems 20.
  • Some of the healthcare systems that can be interconnected include Admissions, Discharge, and Transfers (ADT) 21; Laboratories 22; Medical Imaging 23; Pathology 24; Pharmacies 25; Dictation/Transcription 26; Medical Records 27; Billing and Accounting Systems 28; and Payors 29.
  • ADT Admissions, Discharge, and Transfers
  • FIG. 2 is a schematic illustration of a prior art healthcare system that includes many of the devices that can be simulated by the present invention.
  • FIG. 3 is a system overview of the method and apparatus for simulating healthcare of this invention.
  • System 100 includes Customer Originator 110, Customer Responder 111, System Interface 120, Customer Information 121, System Translator 130, Application Integration Broker 131, System Event Generator 140, Message Profiles 141, System Statistical Engine 145, Registration 150, Configuration 151, Trigger Management 152, Statistical Modeling 153, System Originator 160, System Responder 170, XML/SOAP 180, Transaction Logs 190, and Statistical Models 195.
  • System Interface 120, System Translator 130, System Event Generator 140, and System Statistical Engine 145 Each of the components is configurable through a web browser.
  • FIG. 4 is a schematic view of a general System Lifecycle plan, illustrating the invention's application for Data Modeling tasks and for Data Generation tasks.
  • FIG. 5 is a list of device types 300 that may be used in or with the invention, including but not limited to ADT System 320, Laboratory - Chemistry 330, Laboratory - Hematology 331, Laboratory - Urology 332, Laboratory - Microbiology 333, Laboratory - Nephrology 334, Medical Imaging - Radiology 340, Medical Imaging - CAT Scan 341, Medical Imaging - MRI 342, Medical Imaging - MRA 343, Medical Imaging - Ultrasound 344, Medical Imaging - EKG 345, Pathology 350, Pharmacy 360, Dictation 370, Transcription 375, Medical Records 380, Patient Care Registry 385, Billing and Accounting 390, and Payor 395.
  • the invention is dependent on the description of devices. These devices can be either external customer's devices, or devices of the invention. Devices can be of two types: originators of an event, and responders to an event. In healthcare computing, a device might be an originator in one instance, and a responder in another. For example, when a patient is admitted into a hospital, the ADT system is the originating device for the admission message. This admission message is transmitted to various departments, such as laboratories and imaging, which are (in this instance) considered responders to the original message (the response is usually an ACK).
  • a cascade test (one triggered by the results of another) might originate within a laboratory, and be transmitted to a responding system, such as an Electronic Health Record (EHR).
  • EHR Electronic Health Record
  • the laboratory computer is the originator of the message
  • the EHR system is the responder.
  • a customer must identify which (if any) of their computers are originators of messages, and which are responders. All device types, whether they are the customer's or are of the invention, can be of a type listed in System Originator 160. This is identical to the types listed in System Responder 170. Each of these devices is, in effect, an instance of the System Statistical Engine 145. The events that they simulate are based on statistical modeling and biomathematics. This modeling has defaults that are based on known worldwide human statistics. These defaults can be modified by each client for each device created within the invention.
  • FIG. 6 lists the interface protocols 400 for each real device, including IP/Port level 420, MSMQ (default) 430, MQSI 440, Email 450, FTP 460, HTTP 470, and HTTPS 480.
  • FIG. 7 lists the application protocols 500 to be used by the device and its interface, including HL7 520, DICOM 530, EDI 540, and XML 550.
  • Each device must define its own Interface Protocol 400 (FIG. 6) and Application Protocol 500 (FIG. 7).
  • the System Translator 130 manages the application protocol conversions between any two devices.
  • System Interface 120 is one of the external contact points for the invention.
  • a customer would have a Customer Originator device 110, a Customer Responder device 111,
  • Originator 160 and System Responder 170 can be a queuing technology such as MSMQ
  • System Translator 130 The application protocol used by the simulated devices are preferably based on the XML/SOAP 180 protocol. However, many customers will have legacy systems that use application protocols such as those listed in FIG. 7.
  • Each version of the published standards for the addressed Application Protocols 500 will be stored as a default for each message type of that protocol and version.
  • a customer is able, through the Registration 150, Configuration 151, Trigger Management 152, and
  • the System Translator 130 can be considered an Application Integration Broker
  • a Customer Originator 110 device may be using HL7 version 2.5 as its application protocol.
  • the System Translator 130 would convert each message into the
  • XML/SOAP 180 structure before communicating it to the System Event Generator 140. It would also convert any resultant messages it receives from the System Event Generator 140 into the customer's version of HL7 before communicating it back to the System Interface 120 for distribution to the client.
  • the System Event Generator 140 receives XML/SOAP 180 message segments from the System Translator 130, from the System Originator 160, and from the System Responder
  • the System Event Generator 140 will trigger events as per the event protocols defined in the Message Profiles 141 as well as the Customer
  • each message profile will have the following construct:
  • FIG. 8 is a schematic view of a Use Case Model.
  • the use case model must:
  • FIG. 9 is an example of a Dynamic Interaction Model
  • FIG. 10 is an example of a
  • FIG. 11 is an example of a Static Definition - Message
  • FIG. 12 is an example of a Static Definition - Segment Level
  • FIG. 13 is an example of a Static Definition - Field Level.
  • the Static Definition Field Level descriptions can be found in Chapter 2 of the HL7 documentation.
  • Interface 120 as well as through web pages or web services.
  • System Statistical Engine 145 is the component of the invention that simulates data for all levels of the event generation process. If, for example, a Customer Originator 110 device orders a lab test from a System Responder 170 device, all of the variable data within the OBX response message is simulated based on statistical modeling executed by this component.
  • the customer can generate its own 300,000 patients for these tests, or it can define a
  • System Originator 160 device (such as a clinical system) that can create and save patient identities.
  • a Message Profile 141 can be defined that executes the following steps:
  • [0078] Create a patient, including name, gender, age, address, etc. In 54% of the cases, the patient generated will be female, and their average age will be 42 (based on the statistical rules defined for this device).
  • the Customer Originator 110 system would request information on the patients, the orders, and the results.
  • This protocol could then be triggered 300,000 times (as a batch job) from, say, a web interface. This would result in about 1 million renal panel tests.
  • Registration 150 The client, using a web browser, would engage with System 100 using the following steps:
  • Configuration 151 The client, using a web browser or batch control records, would configure their interactions with the system in the following manner:
  • the invention can also be used to generate the batch control records.
  • Trigger Management 152 The transactions can be triggered in a number of ways, such as:
  • the Customer Originator 110 device can transmit a message to the System
  • Interface 120 using the defined Interface Protocol 400 control records.
  • Statistical Modeling 153 This is one of the possible interfaces that the client uses to configure modifications to its instances of the Statistical Models 195 database and the state-full configurations to the Message Profiles 141.
  • the configuration of the Statistical Engines 154 (System Originator 160 and System Responder 170) is primarily based on weighting algorithms stored in the Statistical Models 195 database.
  • a customer wants to begin with the following Medical Case History distribution: 3% of their patients test positive for diabetes, 1% of their patients test positive for kidney failure, 2% of their patients test positive for congestive heart failure, 8% of their patients test positive for a general viral infection, and 86% of their patients are normal.
  • the invention uses the following weighting conventions in many instances: 3 of their patients test positive for diabetes, 1 of their patients test positive for kidney failure, 2 of their patients test positive for congestive heart failure, 8 of their patients test positive for a general viral infection, and 86 of their patients are normal. [0108] If 10,000 patients are created, and Medical Case Histories are then assigned, it will conform to the distributions listed above. These assignments are performed using the Monte Carlo Simulation.
  • Demographics are broken down into the following categories: Generated from static tables (i.e. name, address), and based on probability (i.e. date of birth, nationality, gender, race). There are linkages between variables like names and values like nationality. For example, the probability of generating the name John Smith is greater for a patient from the United States than it is for a patient from Vietnam or Russia. Variables such as date of birth are defined by the following: Average (e.g., 19560731), Standard Deviation, Skew, Minimum, and Maximum.
  • Medical Case Histories can be predefined within the invention. Customers can use the defaults defined, or modify them to fit their needs. Case histories have a primary diagnosis, and possibly associated secondary diagnoses. All of these variables are accounted for in the Monte Carlo Simulation (see FIG. 14).
  • Order Entry Medical orders can take on a number of forms. For example, there may be orders for any of the following categories: Laboratory orders (e.g., CBC, glucose, urinalysis, etc.), Imaging orders (e.g., X-Rays, CT scan, MRI, etc.), Consults, Psychiatric exams, Home healthcare, etc.
  • Laboratory orders e.g., CBC, glucose, urinalysis, etc.
  • Imaging orders e.g., X-Rays, CT scan, MRI, etc.
  • Consults e.g., X-Rays, CT scan, MRI, etc.
  • Psychiatric exams Psychiatric exams
  • Home healthcare etc.
  • a customer can identify the mix of orders for which they wish to create data.
  • the Statistical Models 195 database might indicate that an HbAlc test be performed on 10 out of 100 patients that visit a clinic.
  • Result Reporting The outcomes of many of these Orders are linked to the Medical Case His
  • the statistical engines may be configured so that a positive result for HbAlc would indicate a positive diagnosis for Diabetes, and vice- versa.
  • Patient management and accounting All of the variables for patient management and accounting (such as Admission, Discharge, and Transfer rates, and medical insurance provider) are processes using the same statistical methods applied to the medical technology variables listed above.
  • XML/SOAP 180 The inventive system may use HL7 Version 2 : XML Encoding Syntax, Release 1 as the definition for the XML structures. This is the default application
  • Transaction Logs 190 All of the data generated by the Originator and Responder systems would be stored here for future retrieval and processing.
  • Demographics consist of data elements such as: Name, Date of birth, Gender,
  • the invention uses the most recently published codes for its representation of these data elements.
  • FIG. 15 illustrates some of the default coding systems 600 for demographics and distributions used by the invention, including ISO demographic definitions
  • Coding Tables The inventive system preferably conforms to all of the following standards: ANSI (e.g., X3.30, X3.4, X3.43, etc.); ISO (e.g., 5218, 1000, 2955, 8072, etc.);
  • Customer Originator 110 communicates with System Responder 170; System Originator 160 communicates with Customer Responder 111; and System Originator 160 communicates with System Responder 170.
  • An example is included here for clarity:
  • a glucose test is ordered by the customer for an imaginary patient.
  • the invention receives the request, modifies it for code content and structure (XML), communicates it to the simulation device, and creates results for the order.
  • XML code content and structure
  • Order Entry received from customer, would arrive at the System Interface 120 for processing.
  • the System Translator 130 would process any fields identified by client. For example, the code F in field 8 of the PID record indicates that the patient is a female.
  • System Responder 170 lab defined (for customer 001, device 001, site 002) might have been defined to use the code 1 for that indication.
  • Order Entry in XML from the CUSTOMER OE to LAB, customer number 001 , device number 001, site number 002, is processed by System Translator 130.
  • the XML message is passed to the System Event Generator 140, which has been configured to forward lab orders from this client to a System Responder 170 device identified as 001 with a site code of 001 for customer 001.
  • the System Responder 170 device uses the System Statistical Engine 145 (with the
  • Statistical Model 195 data qualified by the customer) to create all of the data necessary to complete the OBX (result) record. Based on biomathematics and general statistical modeling techniques, including the Monte Carlo Simulation methods, the system assigns to the patient a glucose result of 182mg. This is outside the normal range defined for this device, which is
  • a Result Report in XML is sent from the LAB, customer number 001, device number 001, site number 002 to the System Event Generator 140.
  • the event generator would review the message profiles for this customer, and would know to redirect the package back to the customer. This message would then be communicated back to the System Translator

Landscapes

  • Engineering & Computer Science (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Public Health (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Databases & Information Systems (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Data Mining & Analysis (AREA)
  • Biomedical Technology (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Pathology (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The invention provides a means for an enterprise, such as a healthcare provider, to simulate all the information it would normally receive from internal and external production systems such as laboratories, imagine systems, ADT systems, and accounting [Fig. 3, item 145]. The invention packages this simulated data into various versions of HL7, DICOM, EDI and XMI. The simulated data is coded using coding standards such as SNOWMED, ICD, CPT, HCPCS, LOINC, HCFA. ISO, FDB, ISO, ANSI, vendor, and customer data mapping tables. The invention simulates all patient demographics, as defined by each customer, and models its data based on statistically relevant distributions of outcomes [item 195]. The invention communicates al messages between the simulated systems an a customer's system using message queues and port level communications [item 190]. A customer, who is developing or implementing a new software product, can inject its system under development into the invention as though it were participating in a complete production environment [item 180]. Likewise, a customer can define one or more devices to participate within its production environment, simulating the data a device of that type might generate.

Description

METHOD AND APPARATUS FOR SIMULATING HEALTHCARE DATA
BACKGROUND OF THE INVENTION
Technical Field
[0001] The present invention relates generally to data processing methods and systems, and more particularly to an improved method and apparatus for the simulation of healthcare data for healthcare providers and payers.
Background Art
[0002] The healthcare environment has very complex data processing requirements, more than can be supported by any one healthcare system vendor. There are a great number of large, disparate systems that have been developed to perform specific tasks within the healthcare equation. As a result, there are large amounts of patient information distributed across many systems built by different vendors. The current trend is toward consolidation of all patient medical information across this multitude of heterogeneous systems. Collectively, this information is known as Patient Health Information.
[0003] Health Level 7 (HL7) has been widely accepted as a method for communications between many of these systems. It has also been widely accepted as a messaging envelope for communications for technologies such as imaging (which has standardized on the DICOM protocol) and medical knowledge (which can be communicated using protocols such as the Arden Syntax). Some of the healthcare systems that can be interconnected include Admissions, Discharge, and Transfers (ADT); Laboratories; Medical Imaging; Pathology; Pharmacies; Dictation/Transcription; Medical Records; Billing and Accounting Systems; and Payors.
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Priority Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US [0004] A healthcare system provider can have multiple instances of each of these systems, as well as others not listed. In many cases, these systems (even those in the same categories) may have different interface and application protocols. As new systems are developed and deployed by healthcare providers and vendors, they must work in unison with other healthcare systems already in place. It is highly unusual for a healthcare provider to replace all of its healthcare systems at one time. If, for example, a healthcare provider is purchasing a new laboratory system, it must interface that system properly with each of its other systems already in production. This is a very complex task.
[0005] A new system will usually be tested in a number of ways, such as:
[0006] Adaptability: it must be able to allow an organization to change quickly and to adopt new technologies as mandated by business need;
[0007] Scalability: it must deal with the current and projected workload and growth plans for many years;
[0008] Security: patient health information is considered confidential and regulated in many countries;
[0009] Usability: the system has to perform in a manner that is useful to the healthcare organization;
[0010] Boundaries: data values must exist within defined ranges; and
[0011] Dependability: all aspects of the system, including its interfaces to other systems must be completely dependable.
[0012] In addition, different healthcare providers service different populations. Some providers attend to specific medical issues such as cancer and orthopedic surgery. Others have general demographics which differ greatly from one region to another. For example, the medical issues faced by the patient population in San Francisco, California can be markedly different than those faced by the general populations in Beijing, China and
Kampala, Uganda. Systems development, and the data used to test a new system, must account for patient demographics as well as the usual computer system testing protocols.
[0013] A vendor or provider must understand the demographic it is addressing, and tailor
Attorney Docket No. 00990.P1PCT International Appl. Filing Date: 7 January 2005
PCT Patent Application Priority Date: 7 January 2004
For: Method and Apparatus for Simulating Healthcare Data ^press Mail No: EV 452851401 US its test data so that the new computer system is tested appropriately. The new system must be able to communicate with a number of medical systems (or devices) which may use different interface and application protocols.
[0014] Presently, data required to test a new system and its interfaces is taken from the older production systems, modified manually so that patient identities are protected, and then fed into the new system. This is very expensive to execute, and may not fully test all the parameters of the new system. As well, there are patient privacy rules in many countries that limit the use of real patient data.
[0015] The foregoing information reflects the current state of the art of which the present inventor is aware. Reference to, and discussion of, this information is intended to aid in discharging Applicant's acknowledged duty of candor in disclosing information that may be relevant to the examination of claims to the present invention. However, it is respectfully submitted that none of the above information discloses, teaches, suggests, shows, or otherwise renders obvious, either singly or when considered in combination, the invention described and claimed herein.
Disclosure of Invention
[0016] The method and apparatus for simulating healthcare data of this invention provides for the automated creation and communication of data between any and all of the potential healthcare computer systems for a given healthcare provider or vendor. The data generated conforms to configurable statistical models which simulate any given subset of the human population and the healthcare systems that population might require.
[0017] The topics addressed by the inventive method and apparatus include the following:
[0018] Demographics, including name, gender, date of birth, height, weight, addresses, race, nationality, and next of kin;
[0019] Medical case load for each simulated person over his or her life span;
[0020] Creation of Test Orders and Result Reporting for each simulated case;
[0021] Appointments, supplies, and accounting;
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Prw t Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US [0022] Staffing, including credentialing; and
[0023] Master files.
[0024] The inventive method and apparatus simulates all patient health information required for healthcare providers and payers worldwide. It includes a set of computer programs that can be implemented in a number of ways, including: Web services, Web products, Stand-alone installations, Client-server applications, and combinations of the above.
[0025] The inventive method and apparatus can be transported via any computer-readable medium or electronic distribution. Its execution can be distributed among any number of computer systems. The data generated can be stored and transmitted electronically, printed, or faxed. The inventive method and apparatus would typically be used in two areas of a general System Lifecycle plan, for Data Modeling tasks and for Data Generation tasks.
[0026] It is therefore an object of the present invention to provide a new and improved method for the automated creation and communication of data between healthcare computer systems.
[0027] It is another object of the present invention to provide a new and improved method to simulate any given subset of the human population and the healthcare systems that population might require.
[0028] A further object or feature of the present invention is a new and improved method and apparatus to simulate patient health information for healthcare providers and payers.
[0029] An even further object of the present invention is to provide a novel method and apparatus for simulating healthcare data.
[0030] Other novel features which are characteristic of the invention, as to organization and method of operation, together with further objects and advantages thereof will be better understood from the following description considered in connection with the accompanying drawings, in which preferred embodiments of the invention are illustrated by way of example. It is to be expressly understood, however, that the drawings are for illustration and description only and are not intended as a definition of the limits of the invention. The
Attorney Docket No 00990.PIPCT International Appl. Filing Date: 7 January 2005
PCT Patent Application Priority Date: 7 January 2004
For: Method and Apparatus for Simulating Healthcare Data Express Mail No: EV 452851401 US various features of novelty which characterize the invention are pointed out with particularity in the claims annexed to and forming part of this disclosure. The invention resides not in any one of these features taken alone, but rather in the particular combination of all of its structures for the functions specified.
[0031] There has thus been broadly outlined the more important features of the invention in order that the detailed description thereof that follows may be better understood, and in order that the present contribution to the art may be better appreciated. There are, of course, additional features of the invention that will be described hereinafter and which will form additional subject matter of the claims appended hereto. Those skilled in the art will appreciate that the conception upon which this disclosure is based readily may be utilized as a basis for the designing of other structures, methods and systems for carrying out the several purposes of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the present invention.
[0032] Further, the purpose of the Abstract is to enable the national patent offιce(s) and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is neither intended to define the invention of this application, which is measured by the claims, nor is it intended to be limiting as to the scope of the invention in any way. [0033] Certain terminology and derivations thereof may be used in the following description for convenience in reference only, and will not be limiting. For example, words such as "upward," "downward," "left," and "right" would refer to directions in the drawings to which reference is made unless otherwise stated. Similarly, words such as "inward" and "outward" would refer to directions toward and away from, respectively, the geometric center of a device or area and designated parts thereof. References in the singular tense include the plural, and vice versa, unless otherwise noted.
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Prtor"y Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US Brief Description of the Drawings
[0034] The invention will be better understood and objects other than those set forth above will become apparent when consideration is given to the following detailed description thereof. Such description makes reference to the annexed drawings wherein:
[0035] FIG. 1 (Prior Art) is a schematic view of some of the typical relationships between various healthcare systems;
[0036] FIG. 2 (Prior Art) is a schematic illustration of a healthcare system that includes many of the devices that can be simulated by the present invention;
[0037] FIG. 3 is a system overview of the method and apparatus for simulating healthcare of this invention;
[0038] FIG. 4 is a schematic view of a general System Lifecycle plan, illustrating the invention's application for Data Modeling and Data Generation tasks;
[0039] FIG. 5 is a list of device types that may be used in or with the invention;
[0040] FIG. 6 lists the interface protocols for each real device;
[0041] FIG. 7 lists the application protocols to be used by the device and its interface;
[0042] FIG. 8 is a schematic view of a Use Case Model;
[0043] FIG. 9 is an example of a Dynamic Interaction Model;
[0044] FIG. 10 is an example of a Dynamic Definition: ADT/ACK;
[0045] FIG. 11 is an example of a Static Definition - Message Level;
[0046] FIG. 12 is an example of a Static Definition - Segment Level;
[0047] FIG. 13 is an example of a Static Definition - Field Level;
[0048] FIG. 14 is an example of the variables defined in a Medical Case History; and
[0049] FIG. 15 illustrates some of the default coding systems for demographics and distributions used by the invention.
Best Mode for Carrying Out the Invention
[0050] Referring to Figs. 1 through 15, wherein like reference numerals refer to like components in the various views, there is illustrated a method and apparatus for simulating
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Pnor"y Date 7 Jan ary 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US healthcare data of this invention.
[0051] Fig. 1 is a schematic view of some of the prior art relationships between various healthcare systems 20. Some of the healthcare systems that can be interconnected include Admissions, Discharge, and Transfers (ADT) 21; Laboratories 22; Medical Imaging 23; Pathology 24; Pharmacies 25; Dictation/Transcription 26; Medical Records 27; Billing and Accounting Systems 28; and Payors 29.
[0052] FIG. 2 is a schematic illustration of a prior art healthcare system that includes many of the devices that can be simulated by the present invention.
[0053] FIG. 3 is a system overview of the method and apparatus for simulating healthcare of this invention. System 100 includes Customer Originator 110, Customer Responder 111, System Interface 120, Customer Information 121, System Translator 130, Application Integration Broker 131, System Event Generator 140, Message Profiles 141, System Statistical Engine 145, Registration 150, Configuration 151, Trigger Management 152, Statistical Modeling 153, System Originator 160, System Responder 170, XML/SOAP 180, Transaction Logs 190, and Statistical Models 195. There are four major parts to the invention: System Interface 120, System Translator 130, System Event Generator 140, and System Statistical Engine 145. Each of the components is configurable through a web browser.
[0054] FIG. 4 is a schematic view of a general System Lifecycle plan, illustrating the invention's application for Data Modeling tasks and for Data Generation tasks. [0055] FIG. 5 is a list of device types 300 that may be used in or with the invention, including but not limited to ADT System 320, Laboratory - Chemistry 330, Laboratory - Hematology 331, Laboratory - Urology 332, Laboratory - Microbiology 333, Laboratory - Nephrology 334, Medical Imaging - Radiology 340, Medical Imaging - CAT Scan 341, Medical Imaging - MRI 342, Medical Imaging - MRA 343, Medical Imaging - Ultrasound 344, Medical Imaging - EKG 345, Pathology 350, Pharmacy 360, Dictation 370, Transcription 375, Medical Records 380, Patient Care Registry 385, Billing and Accounting 390, and Payor 395.
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Pnor"y Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US [0056] The invention is dependent on the description of devices. These devices can be either external customer's devices, or devices of the invention. Devices can be of two types: originators of an event, and responders to an event. In healthcare computing, a device might be an originator in one instance, and a responder in another. For example, when a patient is admitted into a hospital, the ADT system is the originating device for the admission message. This admission message is transmitted to various departments, such as laboratories and imaging, which are (in this instance) considered responders to the original message (the response is usually an ACK). However, a cascade test (one triggered by the results of another) might originate within a laboratory, and be transmitted to a responding system, such as an Electronic Health Record (EHR). In this instance, the laboratory computer is the originator of the message, and the EHR system is the responder.
[0057] For this invention, a customer must identify which (if any) of their computers are originators of messages, and which are responders. All device types, whether they are the customer's or are of the invention, can be of a type listed in System Originator 160. This is identical to the types listed in System Responder 170. Each of these devices is, in effect, an instance of the System Statistical Engine 145. The events that they simulate are based on statistical modeling and biomathematics. This modeling has defaults that are based on known worldwide human statistics. These defaults can be modified by each client for each device created within the invention.
[0058] FIG. 6 lists the interface protocols 400 for each real device, including IP/Port level 420, MSMQ (default) 430, MQSI 440, Email 450, FTP 460, HTTP 470, and HTTPS 480. FIG. 7 lists the application protocols 500 to be used by the device and its interface, including HL7 520, DICOM 530, EDI 540, and XML 550.
[0059] Each device must define its own Interface Protocol 400 (FIG. 6) and Application Protocol 500 (FIG. 7). The System Translator 130 manages the application protocol conversions between any two devices.
[0060] System Interface 120 is one of the external contact points for the invention. A customer would have a Customer Originator device 110, a Customer Responder device 111,
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Λwi )/ Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US or multiples of both communicating with the System Interface 120. They can communicate using interface protocols such as those illustrated in FIG. 6.
[0061] The interface protocol used by the simulated devices (of the types listed in System
Originator 160 and System Responder 170) can be a queuing technology such as MSMQ
430.
[0062] System Translator 130: The application protocol used by the simulated devices are preferably based on the XML/SOAP 180 protocol. However, many customers will have legacy systems that use application protocols such as those listed in FIG. 7.
[0063] Each version of the published standards for the addressed Application Protocols 500 will be stored as a default for each message type of that protocol and version. A customer is able, through the Registration 150, Configuration 151, Trigger Management 152, and
Statistical Modeling 153 components to modify any of these standards to fit their particular needs.
[0064] The System Translator 130 can be considered an Application Integration Broker
131. The function of this component of the invention is to translate an Application Protocol
500 specification into the XML/SOAP 180 protocol, and back.
[0065] For example, a Customer Originator 110 device may be using HL7 version 2.5 as its application protocol. The System Translator 130 would convert each message into the
XML/SOAP 180 structure before communicating it to the System Event Generator 140. It would also convert any resultant messages it receives from the System Event Generator 140 into the customer's version of HL7 before communicating it back to the System Interface 120 for distribution to the client.
[0066] The System Event Generator 140 receives XML/SOAP 180 message segments from the System Translator 130, from the System Originator 160, and from the System Responder
170. Based on the contents of the message, the System Event Generator 140 will trigger events as per the event protocols defined in the Message Profiles 141 as well as the Customer
Information 121 and Application Integration Broker 131.
[0067] The invention uses a definition of message profiles as per that described in Chapter
Attorney Docket No. 00990. PI PCT International Appl. Filing Date: 7 January 2005
PCT Patent Application Priority Date: 7 January 2004
For: Method and Apparatus for Simulating Healthcare Data Express Mail No: EV 452851401 US 2 of HL7 version 2.5. Specifically, each message profile will have the following construct:
Use Case, Dynamic definition, and Static definition. Examples of some of these constructs, taken from the HL7 documentation, are given below.
[0068] FIG. 8 is a schematic view of a Use Case Model. The use case model must:
[0069] Provide a name that clearly and concisely defines the exchange;
[0070] Document the purpose for each message exchange;
[0071] Define the actors, including the sending and receiving applications;
[0072] Define the flow of events between these actors including, where appropriate, derived events; and
[0073] Document the situations in which the exchange of a particular HL7 message profile is required. Refer to the HL7 V3.0 Message Development Framework (MDF 99) for further information on use case models and their uses within HL7.
[0074] FIG. 9 is an example of a Dynamic Interaction Model; FIG. 10 is an example of a
Dynamic Definition: ADT/ACK; FIG. 11 is an example of a Static Definition - Message
Level; FIG. 12 is an example of a Static Definition - Segment Level; and FIG. 13 is an example of a Static Definition - Field Level. The Static Definition Field Level descriptions can be found in Chapter 2 of the HL7 documentation. There are also control records associated with the message profiles, which allow them to be triggered through the System
Interface 120, as well as through web pages or web services.
[0075] System Statistical Engine 145 is the component of the invention that simulates data for all levels of the event generation process. If, for example, a Customer Originator 110 device orders a lab test from a System Responder 170 device, all of the variable data within the OBX response message is simulated based on statistical modeling executed by this component.
[0076] Statistical modeling can be done on almost all variables in all messages. For example, a customer may wish to have data for 1 million renal panel tests done on 300,000 patients (54% female, average age of 42 with a standard deviation of 2.3) over a term of 1 year. And, it may want the results for electrolytes to indicate renal failure for 2% of the
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Priority Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data El^ess Maύ No EV 452851401 US patients tested. This data could be used to test a particular EHR software package for general system testing as well as for specific demographics.
[0077] The customer can generate its own 300,000 patients for these tests, or it can define a
System Originator 160 device (such as a clinical system) that can create and save patient identities. A Message Profile 141 can be defined that executes the following steps:
[0078] 1. Create a patient, including name, gender, age, address, etc. In 54% of the cases, the patient generated will be female, and their average age will be 42 (based on the statistical rules defined for this device).
[0079] 2. Store the patient in the Transaction Logs 190.
[0080] 3. Order some number of renal panel tests for this patient for a year.
[0081] 4. Store the Orders in the Transaction Logs 190.
[0082] 5. Communicate those orders to the System Responder 170 laboratory.
[0083] 6. The laboratory will generate results for the renal panel tests, where about 2% of the results will suggest renal failure.
[0084] 7. Store the Results in the Transaction Logs 190.
[0085] 8. The Customer Originator 110 system would request information on the patients, the orders, and the results.
[0086] 9. The data would be communicated to the customer from the Transaction Logs 190.
[0087] This protocol could then be triggered 300,000 times (as a batch job) from, say, a web interface. This would result in about 1 million renal panel tests.
[0088] Registration 150: The client, using a web browser, would engage with System 100 using the following steps:
[0089] 1. Initial communications for information.
[0090] 2. Fill out Customer Information 121 such as name, company name, address, phone number, billing address, information, credit card (or other billing method).
[0091] Configuration 151 : The client, using a web browser or batch control records, would configure their interactions with the system in the following manner:
[0092] 1. Define customer devices (Customer Originator 110 and/or Customer Responder
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Pnor"y Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data ExPras Mωl No EV ^2851401 US 111) of Device Types 300.
[0093] 2. Define System Originator 160 and System Responder 170 devices required by customer.
[0094] 3. Define device interface protocols for the System Interface 120 (such as from those listed in Interface Protocol 400) for each real device.
[0095] 4. Define Application Protocol 500 (for the System Translator 130) for each device.
[0096] 5. Define customer-specific modifications to the Application Protocol 500 for each device (for use by Application Integration Broker 131).
[0097] 6. Modify default Message Profiles 141 used by System Event Generator 140.
[0098] The invention can also be used to generate the batch control records.
[0099] Trigger Management 152: The transactions can be triggered in a number of ways, such as:
[0100] 1. Through the Trigger Management 152 function, the client can trigger a Message
Profile 141. This is useful when the Client has chosen to use a System Originator 160 device.
[0101] 2. The Customer Originator 110 device can transmit a message to the System
Interface 120 using the defined Interface Protocol 400 control records.
[0102] Statistical Modeling 153 : This is one of the possible interfaces that the client uses to configure modifications to its instances of the Statistical Models 195 database and the state-full configurations to the Message Profiles 141.
[0103] Statistical Models 195: The invention will model almost any Patient Health
Information variable required by the customer in the messaging system. Some variables are created by other systems, and are kept intact for System State. A list of categories where statistical modeling is applied in the invention could include the following: Demographics,
Medical Case Histories, Order Entry, Result Reporting, and Patient management and accounting.
[0104] For most customers, the modeling will be quite simple when they first begin using the invention. But, it will become much more complex as they learn to use the tool.
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Priority Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data ^ * Mal1 No EV 45 ^l40l US [0105] The configuration of the Statistical Engines 154 (System Originator 160 and System Responder 170) is primarily based on weighting algorithms stored in the Statistical Models 195 database. Say, for example, a customer wants to begin with the following Medical Case History distribution: 3% of their patients test positive for diabetes, 1% of their patients test positive for kidney failure, 2% of their patients test positive for congestive heart failure, 8% of their patients test positive for a general viral infection, and 86% of their patients are normal.
[0106] There are two major complications that preclude the use of percentages: 1. Compound case: patients with diabetes may also have kidney failure; and 2. Addition of new cases: we have now added a case for brain aneurysms.
[0107] There are many thousands of Medical Case Histories possible, with all of the combinatorial possibilities. Therefore, the invention uses the following weighting conventions in many instances: 3 of their patients test positive for diabetes, 1 of their patients test positive for kidney failure, 2 of their patients test positive for congestive heart failure, 8 of their patients test positive for a general viral infection, and 86 of their patients are normal. [0108] If 10,000 patients are created, and Medical Case Histories are then assigned, it will conform to the distributions listed above. These assignments are performed using the Monte Carlo Simulation.
[0109] Now, we will add the Medical Case History type of brain aneurysm. The customer can then add this case history to their probability distribution list: 3 of their patients test positive for diabetes, 1 of their patients test positive for kidney failure, 2 of their patients test positive for congestive heart failure, 8 of their patients test positive for a general viral infection, 86 of their patients are normal, 1 of their patients is found to have a brain aneurysm.
[0110] If the Medical Case Histories are assigned to the same 10,000 patients, the denominator for the case history distribution becomes 101, rather than 100. As more case histories and history distributions are added by the customer, they can re-run their patient populations through the inventive system to get the modified outcome distributions. This
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Priority Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US requires a state-full processing model, which is incorporated into the System Event Generator 140.
[0111] Demographics are broken down into the following categories: Generated from static tables (i.e. name, address), and based on probability (i.e. date of birth, nationality, gender, race). There are linkages between variables like names and values like nationality. For example, the probability of generating the name John Smith is greater for a patient from the United States than it is for a patient from Vietnam or Russia. Variables such as date of birth are defined by the following: Average (e.g., 19560731), Standard Deviation, Skew, Minimum, and Maximum.
[0112] Medical Case Histories can be predefined within the invention. Customers can use the defaults defined, or modify them to fit their needs. Case histories have a primary diagnosis, and possibly associated secondary diagnoses. All of these variables are accounted for in the Monte Carlo Simulation (see FIG. 14).
[0113] Order Entry: Medical orders can take on a number of forms. For example, there may be orders for any of the following categories: Laboratory orders (e.g., CBC, glucose, urinalysis, etc.), Imaging orders (e.g., X-Rays, CT scan, MRI, etc.), Consults, Psychiatric exams, Home healthcare, etc. Using the invention, a customer can identify the mix of orders for which they wish to create data. For example, the Statistical Models 195 database might indicate that an HbAlc test be performed on 10 out of 100 patients that visit a clinic. [0114] Result Reporting: The outcomes of many of these Orders are linked to the Medical Case Histories. For example, the statistical engines may be configured so that a positive result for HbAlc would indicate a positive diagnosis for Diabetes, and vice- versa. [0115] Patient management and accounting: All of the variables for patient management and accounting (such as Admission, Discharge, and Transfer rates, and medical insurance provider) are processes using the same statistical methods applied to the medical technology variables listed above.
[0116] XML/SOAP 180: The inventive system may use HL7 Version 2 : XML Encoding Syntax, Release 1 as the definition for the XML structures. This is the default application
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Priority Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US protocol for communications between the System Originator 160 devices and the System
Responder 170 devices.
[0117] Transaction Logs 190: All of the data generated by the Originator and Responder systems would be stored here for future retrieval and processing.
[0118] Demographics consist of data elements such as: Name, Date of birth, Gender,
Nationality, Race, Height, Weight, Hair color, Eye color, Education, and so on. In healthcare, much of this information has been codified by organizations such as the
American National Standards Institute (ANSI), the International Standards Organization
(ISO), the World Health Organization (WHO), etc. The invention uses the most recently published codes for its representation of these data elements.
[0119] Most organizations use some form of these standard definitions. Differences between what a customer uses and the defaults used by the invention can be recorded through the Configuration 151 engine. FIG. 15 illustrates some of the default coding systems 600 for demographics and distributions used by the invention, including ISO demographic definitions
620, ANSI demographic definitions 625, Auto-generation of Name, Address, MRN, etc. 630,
Statistical distribution of demographics 640, and Boundary tests 650.
[0120] Coding Tables: The inventive system preferably conforms to all of the following standards: ANSI (e.g., X3.30, X3.4, X3.43, etc.); ISO (e.g., 5218, 1000, 2955, 8072, etc.);
Codes and Terminology (ACR, CPT, ICD, NDC, SNOMED, LOINC, etc.); ASTM
Standards; UB-92; and others, and uses the HL7 registered OID's for the identification of coding systems, etc. Some of the tables used by the system are defined in the HL7 version
2.5 documentation.
[0121] Use Cases: There are three general methods for interacting with the invention:
Customer Originator 110 communicates with System Responder 170; System Originator 160 communicates with Customer Responder 111; and System Originator 160 communicates with System Responder 170. An example is included here for clarity:
[0122] Customer Originator 110 communicates with System Responder 170: In this example, we demonstrate how a customer's computer system might interact with a simulated
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Priority Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US lab they have defined in the invention. A glucose test is ordered by the customer for an imaginary patient. The invention receives the request, modifies it for code content and structure (XML), communicates it to the simulation device, and creates results for the order.
It then sends those results back to the ordering system as though they had been created by an actual laboratory.
[0123] Order Entry, received from customer, would arrive at the System Interface 120 for processing. The System Translator 130 would process any fields identified by client. For example, the code F in field 8 of the PID record indicates that the patient is a female.
However, the System Responder 170 lab defined (for customer 001, device 001, site 002) might have been defined to use the code 1 for that indication.
[0124] Order Entry in XML, from the CUSTOMER OE to LAB, customer number 001 , device number 001, site number 002, is processed by System Translator 130.
[0125] The XML message is passed to the System Event Generator 140, which has been configured to forward lab orders from this client to a System Responder 170 device identified as 001 with a site code of 001 for customer 001.
[0126] The System Responder 170 device uses the System Statistical Engine 145 (with the
Statistical Model 195 data qualified by the customer) to create all of the data necessary to complete the OBX (result) record. Based on biomathematics and general statistical modeling techniques, including the Monte Carlo Simulation methods, the system assigns to the patient a glucose result of 182mg. This is outside the normal range defined for this device, which is
70-108mg. It is marked as H high for further processing.
[0127] In defining the statistics for the results for the customer for this device, we may have identified 90mg as the mean with a standard deviation of 1.5. We may have also configured this device to return 3% of its results (a skew) to be high.
[0128] A Result Report in XML is sent from the LAB, customer number 001, device number 001, site number 002 to the System Event Generator 140. The event generator would review the message profiles for this customer, and would know to redirect the package back to the customer. This message would then be communicated back to the System Translator
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Priority Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US 130 for conversion back to the HL7 version 2.4 identified in the header of the original HL7 message.
[0129] After processing by the System Translator 130, the result is sent to the customer, with a modification in the PID record for gender via the System Interface 120.
[0130] The foregoing disclosure is sufficient to enable one having skill in the art to practice the invention without undue experimentation, and provides the best mode of practicing the invention presently contemplated by the inventor. While there is provided herein a full and complete disclosure of the preferred embodiments of this invention, it is not intended to limit the invention to the exact construction, dimensional relationships, and operation shown and described. Various modifications, alternative constructions, changes and equivalents will readily occur to those skilled in the art and may be employed, as suitable, without departing from the true spirit and scope of the invention. Such changes might involve alternative materials, components, structural arrangements, sizes, shapes, forms, functions, operational features or the like.
[0131] Accordingly, the proper scope of the present invention should be determined only by the broadest interpretation of the appended claims so as to encompass all such modifications as well as all relationships equivalent to those illustrated in the drawings and described in the specification.
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Pπor" Date 7 J uc"y 2 0
For Method and Apparatus for Simulating Healthcare Data ElΨress Mωl No EV 452851401 US

Claims

CLAIMS What is claimed as invention is:
1. A method for testing a healthcare computer system, said method comprising the steps of: generating simulated patient health information conforming to statistical models of the patient population; and delivering the information generated to a healthcare computer system for testing of that system.
2. The method for testing a healthcare computer system of claim 1 wherein the simulated patient health information comprises medical records.
3. The method for testing a healthcare computer system of claim 1 wherein the simulated patient health information comprises electronic health records.
4. The method for testing a healthcare computer system of claim 1 wherein the simulated patient health information comprises admissions, discharges, and transfers.
5. The method for testing a healthcare computer system of claim 1 wherein the simulated patient health information comprises information taken from the group consisting of clinic information, hospital information, emergency department information, imaging department information, laboratory department information, population care registry information, healthcare accounting and administration information, and medical research information.
6. The method for testing a healthcare computer system of claim 1 further including the step of storing and reusing the information generated.
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Pr,onty Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data ^P 33 Maύ No EV 452851401 US
7. An apparatus for simulating healthcare information for the testing of a healthcare computer system, said apparatus comprising: a simulation system; interface means for connecting said simulation system to the healthcare computer system; translator means for managing application protocol conversions between devices; event generator means for triggering events; and statistical engine means for simulating data for said event generator.
8. The apparatus for simulating healthcare information of claim 7 wherein said data comprises demographics.
9. The apparatus for simulating healthcare information of claim 7 wherein said data comprises a medical case load for each simulated person.
10. The apparatus for simulating healthcare information of claim 7 wherein said data comprises creation of test orders and result reporting for each simulated case.
11. The apparatus for simulating healthcare information of claim 7 wherein said data comprises appointments, supplies, and accounting.
12. The apparatus for simulating healthcare information of claim 7 wherein said data comprises staffing and credentialing.
13. A method for simulating healthcare data, said method comprising the steps of: providing a simulation system;
Attorney Docket No. 00990.P1PCT International Appl. Filing Date: 7 January 2005
PCT Patent Application Priority Dale: 7 January 2004
For: Method and Apparatus for Simulating Healthcare Data Express Mail No: EV 452851401 US providing an interface connecting the simulation system to a healthcare computer system; converting application protocols between the simulation system and the healthcare computer system; generating events for simulation; and providing statistically valid simulated data for said events.
14. The method for simulating healthcare data of claim 13 further including the step of defining an interface protocol for each device used.
15. The method for simulating healthcare data of claim 13 further including the step of defining an application protocol for each device used.
16. The method for simulating healthcare data of claim 13 further including the step of defining a device as one of an originator of an event and a responder to an event.
17. The method for simulating healthcare data of claim 13 further including the step of providing each message profile with a use case, dynamic definition, and static definition.
18. The method for simulating healthcare data of claim 13 further including the step of delivering the simulated healthcare data to a healthcare computer via a global computer network.
19. The method for simulating healthcare data of claim 13 further including the step of providing defaults which can be modified by the user of the healthcare computer.
20. The method for simulating healthcare data of claim 13 further including the step of storing and reusing the information generated.
Attorney Docket No 00990 PI PCT International Appl Filing Date 7 January 2005
PCT Patent Application Priority Date 7 January 2004
For Method and Apparatus for Simulating Healthcare Data Express Mail No EV 452851401 US
PCT/US2005/000613 2004-01-07 2005-01-07 Method and apparatus for simulating healthcare data WO2005067662A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US53481704P 2004-01-07 2004-01-07
US60/534,817 2004-01-07

Publications (2)

Publication Number Publication Date
WO2005067662A2 true WO2005067662A2 (en) 2005-07-28
WO2005067662A3 WO2005067662A3 (en) 2008-07-31

Family

ID=34794320

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/000613 WO2005067662A2 (en) 2004-01-07 2005-01-07 Method and apparatus for simulating healthcare data

Country Status (1)

Country Link
WO (1) WO2005067662A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11705231B2 (en) 2018-12-19 2023-07-18 Cardinal Health Commerical Technologies, Llc System and method for computerized synthesis of simulated health data

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020127525A1 (en) * 2001-03-06 2002-09-12 Arington Michael L. Distributive processing simulation method and system for training healthcare teams
US20030101076A1 (en) * 2001-10-02 2003-05-29 Zaleski John R. System for supporting clinical decision making through the modeling of acquired patient medical information

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020127525A1 (en) * 2001-03-06 2002-09-12 Arington Michael L. Distributive processing simulation method and system for training healthcare teams
US6739877B2 (en) * 2001-03-06 2004-05-25 Medical Simulation Corporation Distributive processing simulation method and system for training healthcare teams
US20030101076A1 (en) * 2001-10-02 2003-05-29 Zaleski John R. System for supporting clinical decision making through the modeling of acquired patient medical information

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CITRO ET AL.: 'A Fundamental Metric for Continuity of Care: Modeling and Performance Evaluation' IEEE TRANSDUCTION ON INFORMATION TECHNOLOGY IN BIOMEDICINE vol. 1, no. 3, September 1997, pages 189 - 204 *
KRAHL D.: 'Extend: An Interactive Simulation Tool' IEEE, PROCEEDINGS OF THE 2003 WINTER SIMULATION CONFERENCE vol. 1, December 2003, pages 188 - 196 *
PRICE R.N. ET AL.: 'Healthcare Simulation Modeling and Optimization Using MedModel' IEEE, SIMULATION CONFERENCE PROCEEDINGS vol. 1, December 1999, pages 215 - 219 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11705231B2 (en) 2018-12-19 2023-07-18 Cardinal Health Commerical Technologies, Llc System and method for computerized synthesis of simulated health data

Also Published As

Publication number Publication date
WO2005067662A3 (en) 2008-07-31

Similar Documents

Publication Publication Date Title
US11551806B2 (en) Systems and methods for integrating communications in a healthcare network
EP1994484B1 (en) Platform for interoperable healthcare data exchange
US8548824B1 (en) Systems and methods for notifying of duplicate product prescriptions
US20190354900A1 (en) System and User Interface for Acquisition and Storage of Patient Medical Insurance Data
US20040141661A1 (en) Intelligent medical image management system
US8392214B1 (en) Systems and methods for facilitating claim rejection resolution by providing prior authorization assistance
US20060261145A1 (en) Systems and methods for managing electronic prescriptions
JP2007531112A (en) System and method for creating tasks associated with electronic image files
AU2012315702B2 (en) Methods and systems for intelligent routing of health information
US20100191546A1 (en) Methods and apparatus to automatically generate subscriptions for healthcare event tracking and alerting systems
Sprivulis et al. The economic benefits of health information exchange interoperability for Australia
US10937553B2 (en) Systems and methods to organize the flow and processing of queued messages that have been received from healthcare entities
Lobach et al. A randomized trial of population-based clinical decision support to manage health and resource use for Medicaid beneficiaries
AU2011217881A1 (en) Clinical payment network system and methods
Dünnebeil et al. Modular architecture of value-added applications for German healthcare telematics
Perugu et al. Pragmatic Approaches to Interoperability–Surmounting Barriers to Healthcare Data and Information Across Organizations and Political Boundaries
US20160267230A1 (en) Touchless processing
WO2005067662A2 (en) Method and apparatus for simulating healthcare data
Cyr An overview of healthcare standards
US11664120B1 (en) Apparatuses, systems, and methods for reducing return of prescriptions to stock
Dachyar et al. Analysis of Outpatient Service Queue of Public Hospital in Jakarta
Cyr et al. Brief overview of various healthcare tools, methods, framework and standards
US11170879B1 (en) Individual health record system and apparatus
Haakalaki et al. A Model for an Electronic Health Information Management System with Structural Interoperability in Heterogeneous Environments for continued Health Care
Khalifa et al. Public health data for individual patient care: mapping poison control center data to the C-CDA consultation note

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 BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

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

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase