HK1185974A - Managing healthcare information in a distributed system - Google Patents

Description

Managing healthcare information in a distributed system

Cross Reference to Related Applications

U.S. provisional patent application No. 61/406,003 entitled "System and Method for Managing Healthcare Information", filed 2010, 10, 22, in accordance with USC § 119(e), is claimed priority.

Technical Field

The present invention relates to managing healthcare information. In particular, the present invention relates to a distributed system for managing healthcare information across different platforms.

Background

Electronic healthcare information is increasingly being exchanged over networks. Electronic healthcare information is exchanged between medical offices and other physicians, local hospitals and clinics, local and national laboratories and imaging centers, insurance payers, local pharmacies, public health and government agencies and patients. This type of collaboration requires the practice of participating in many healthcare transactions with many different people and organizations. These transactions include ordering and scheduling checks and obtaining results, referrals and consultation of patients by other providers, obtaining authorization of insurance payers and submitting payers' claims, and prescribing and replenishing medications. Physicians and their staff are frequently engaged in telephone, facsimile and internet to perform collaborative exchanges. Some of the costs associated with these exchanges will be reduced if more of these communications are performed electronically.

Previous attempts to overcome these problems have had drawbacks. For example, some physicians have created Electronic Medical Records (EMRs), however, physicians typically maintain internal systems and if they do exchange information, it is only exchanged with hospitals, payers, laboratories, and pharmacies. Thus, the physician will miss opportunities for a greater amount of information exchange.

Health Information Exchange (HIE) is emerging in many communities, however they lack widespread acceptance and they focus on creating comprehensive, patient-centric records and do not focus on enhancing clinical workflow for physician practice.

Other solutions have drawbacks that prevent their adoption by physicians. For example, most software is insufficient or too immature to meet the wide range of collaboration needs of physician practice. Furthermore, the cost of employing this technique is often considered too great for both the licensing and the expense of redesign practices. Finally, existing systems do not match established workflows that physicians and staff are accustomed to performing. As a result, existing systems must be reconfigured, which requires manual intervention by personnel to complete the process.

Disclosure of Invention

The techniques described in this disclosure overcome the deficiencies and limitations of the prior art, at least in part, by providing a system and method for managing healthcare information. The data manager allows users to control the applications as they deem to be in match by configuring settings and downloading different applications to include as part of the data manager. The data manager is securely connected to other collaboration partners in the community and works with local and remote computer systems. Furthermore, since there are multiple data managers in the system that store different pieces of information, there is no risk of system-wide failures.

In one embodiment, the rendezvous engine acts as an intermediary between data servers. The data servers each include a data manager that includes a controller, a grid engine, an application manager, a virtual care team module, a scrubber module, and a user interface engine. The controller manages the core functions and the transfer of data between the data manager components. The grid engine manages information sent between the data servers. An application is an application created by a user or downloaded as a third party application. The application manager manages the creation and communication between applications. The virtual care team module manages the transfer of patient data between the data servers. The scrubber module manages pseudo-anonymization of data and data collection for clinical trials. The user interface engine generates a user interface for displaying the application and collecting clinical trial data.

Drawings

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

FIG. 1 is a high-level block diagram illustrating a system for managing data according to one embodiment of the present invention.

Figure 2A is a block diagram of a rendezvous engine in accordance with one embodiment of the invention.

FIG. 2B is a block diagram of a data manager, according to one embodiment of the invention.

FIG. 3A is a block diagram of a grid engine according to one embodiment of the invention.

FIG. 3B is a block diagram of an application manager, according to one embodiment of the invention.

FIG. 3C is a block diagram of a virtual care team module according to one embodiment of the invention.

FIG. 3D is a block diagram of a scrubber module according to one embodiment of the invention.

Figure 4A is a graphical illustration of a user interface for accessing patient records according to one embodiment of the present invention.

FIG. 4B is a graphical illustration of a user interface for viewing an application store according to one embodiment of the invention.

Fig. 4C is a graphical illustration of a user interface for viewing functionality provided by a referral (referral) application according to one embodiment of the invention.

Figure 4D is a graphical illustration of a different embodiment of a user interface for viewing functionality provided by a referral application according to an embodiment of the invention.

FIG. 4E is a graphical illustration of a user interface for viewing a timeline according to one embodiment of the present invention.

FIG. 4F is a graphical illustration of a user interface for viewing an application store according to one embodiment of the invention.

Fig. 4G is a graphical illustration of a user interface of a user view of a timeline after reconciling a patient record with an update from another application, according to an embodiment of the invention.

Fig. 4H is a graphical illustration of a user interface for requesting patient information.

Fig. 5 illustrates a flow diagram of a method for generating a payload according to one embodiment of the invention.

Figure 6 illustrates a flow diagram of a method for using a rendezvous engine to send data between data servers according to one embodiment of the invention.

FIG. 7 illustrates a flow diagram of a method for monitoring changes between applications in accordance with one embodiment of the present invention.

Figure 8A illustrates a flow diagram of a method for propagating patient identifiers between multiple data servers according to one embodiment of the invention.

Fig. 8B illustrates a flow diagram of a method for updating patient information among multiple data servers in accordance with one embodiment of the present invention.

Fig. 9 illustrates a flow diagram of a method for identifying patients of a study according to one embodiment of the invention.

FIG. 10 illustrates a flow diagram of a method for generating a pseudo-identifier for a patient according to one embodiment of the invention.

Detailed Description

A system and method for managing healthcare information is described below. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the techniques described in the various example embodiments may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention.

Reference in the specification to "one embodiment," "an embodiment," or "an example embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the description. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The present embodiments of the invention also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-disks, read-only memories (ROMs), Random Access Memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, flash memory (including USB shields having non-volatile memory), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

Finally, the algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose programs may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

Overview of the System

Fig. 1 illustrates a block diagram of a system 100 for managing dispersed healthcare information, according to one embodiment of the invention. In fig. 1 and the remaining figures, letters following a reference number, such as "115 a," refer to a unit having that particular reference number. Reference numerals without a subsequent letter, such as "115," herein generally refer to any or all instances of the element bearing the reference numeral. In the illustrated embodiment, these entities are communicatively coupled via a network 105.

The illustrated description of the system 100 for managing healthcare information includes data servers 115a, 115b.. 115n accessed by users 125a, 125b.. 125n, practice (practice) management software (PMS)121, an Electronic Medical Record (EMR) application 123, an application server 152, and a rendezvous server 102. In the illustrated embodiment, these entities are communicatively coupled via a network 105. The data servers 115a, 115b.. 115n in fig. 1 are used by way of example. Although fig. 1 illustrates three data servers 115a, 115b. Data server 115a is coupled to network 105 via signal line 108. The user 125a accesses the data server 115a via the signal line 110. In one embodiment, the data server 115a is a master data server 115a that manages the organization of some information for other data servers 115 n. Data server 115b is coupled to network 105 via signal line 112. The user 125b accesses the data server 115b via the signal line 120.

In one embodiment, the data server 115a is a hardware server, such as MedicityA hardware server to provide power. The data server 115a includes a data manager 103a and a storage device 141. Data manager 103a manages the healthcare information stored in the storage device 141 and controls how long the information lasts in the storage device 141. Data server 115a is coupled to a Local Area Network (LAN)109 via signal line 114.

In one embodiment, the data server 115a communicates over a LAN to access the EMR application 123 via signal line 116 and to access the PMS121 via signal line 118. The EMR application 123 is software for managing electronic medical records maintained by an enterprise, such as a physician's office. The PMS is software that is used to manage the daily operations of a medical practice, such as tracking patients, scheduling appointments, and managing billing, including entering charges for services, coding services, and submitting claims to insurance companies. Although only the EMR application 123 and PMS121 are depicted as being connected to the LAN 109 in this illustration, the data server 115a may communicate over the LAN to access other systems and devices. The data server 115 is described in more detail below with reference to fig. 2B.

The system 100 illustrates a distributed computing model in which each data server 115 runs a data manager 103. Each data manager 103 exchanges information with other data managers 103 n. The community of data managers 103n forms a grid, which is a transport network that supports information delivery. The data manager 103a exchanges information with other data managers 103n in a secure manner by limiting access to the information to specific members of the system 100. In particular, the user 125a of the data manager 103a determines which other participants on the grid the user 125a wants to participate with, which eliminates the risk that others outside the closed community will access the information.

The rendezvous server 101 manages asynchronous communication of information between the data servers 115a, 115b.. 115 n. The rendezvous server 101 accesses the network via signal line 104. Although only one rendezvous server 101 is illustrated, one of ordinary skill in the art will recognize that multiple rendezvous servers 101 are possible. The rendezvous server 101 is described in more detail with reference to figure 2A.

Application server 152 manages the uploading, purchasing, and downloading of applications by users 125a of data manager 103 a. The application is downloaded by the other data manager 103n and incorporated into the data manager 103 n. The application is described in more detail below with reference to fig. 3B. In one embodiment, the application server 152 is stored on the primary data server 115 a. Application server 152 is coupled to network 105 via signal line 154.

In one embodiment, the application server 152 processes the purchase by communicating with the collaboration server 101 to retrieve the identity of the user 125n, billing the user 125n for the purchase, generating a receipt, and performing other functions known to those of ordinary skill in the art for completing the purchase. In one embodiment, the application server 152 distributes a percentage of the purchase price to the user developing the application and keeps the rest of the purchase price as a service charge for maintaining the application repository.

The network 105 is of a conventional type, wired or wireless, and may have any number of configurations, such as a star configuration, a token ring configuration, or other configurations known to those skilled in the art. Additionally, network 105 may include a Local Area Network (LAN), a Wide Area Network (WAN) (e.g., the internet), and/or any other interconnected data path across which multiple devices may communicate. In yet another embodiment, the network 105 may be a peer-to-peer network. The network 105 may also be coupled to or include portions of a telecommunications network for transmitting data in a number of different communication protocols. In yet another embodiment, the network 105 comprises a bluetooth communication network or a cellular communication network for sending and receiving data, such as via Short Messaging Service (SMS), Multimedia Messaging Service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, email, and the like.

Rendezvous engine 200

Referring now to figure 2A, a rendezvous server 101 includes a rendezvous engine 200, a memory 237, a processor 235, a communication unit 245, and a storage device for storing a payload queue 210, each coupled to a bus 219. Bus 219 may represent one or more buses, including an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, a Universal Serial Bus (USB), or some other bus known in the art for providing similar functionality. In one embodiment, the rendezvous engine 200 includes a grid state manager 202, a registration engine 204, a classifier (sorter)206, and a user interface engine 208. Rendezvous engine 200 is also discussed in USPN 7,653,634 entitled "System for the Processing of Information between moved Located Healthcare Entitures", filed on 30.10.2007 and USPN 7,953,699 entitled "System for the Processing of Information between moved Located Healthcare Entitures", filed on 4.12.2009, each of which is incorporated herein by reference.

Processor 235 includes an arithmetic logic unit, a microprocessor, a general purpose controller, or some other array of processors for performing computations and providing electronic display signals to a display device. Processor 235 is coupled to bus 220 for communication with other components via signal line 236. The processor 235 processes data signals and may include various computing architectures including a Complex Instruction Set Computer (CISC) architecture, a Reduced Instruction Set Computer (RISC) architecture, or an architecture implementing a combination of instruction sets. Although only a single processor is shown in FIG. 2A, multiple processors may be included. Processing power may be limited to support image display and image capture and transmission. The processing power may be sufficient to perform more complex tasks including various types of feature extraction and sampling. It will be clear to those skilled in the art that other processors, operating systems, sensors, displays and physical configurations are possible.

The memory 237 stores instructions and/or data that the processor 235 may execute. A memory 237 is coupled to the bus 220 for communication with other components via signal lines 238. The instructions and/or data may include code to perform any and/or all of the techniques described herein. The memory 237 may be a Dynamic Random Access Memory (DRAM) device, a Static Random Access Memory (SRAM) device, flash memory, or some other memory device known in the art. In one embodiment, memory 237 also includes non-volatile memory or similar persistent storage devices and media, such as a hard disk drive, floppy disk drive, CD-ROM device, DVD-RAM device, DVD-RW device, flash memory device, or some other mass storage device known in the art for storing information on a more persistent basis.

The communication unit 245 transmits and receives data to and from the data server 115n and the application server 152, and the data server 115n and the application server 152. Communication unit 245 is coupled to bus 220 via signal line 246. In one embodiment, the communication unit 245 includes a port for direct physical connection to the data server 115n, the application server 152, or another communication channel. For example, the communication unit 245 includes USB, SD, CAT-5, or similar port for wired communication with the user device 115. In another embodiment, communication unit 245 includes a processor for using one or more wireless communication methods, such as IEEE802.11, IEEE 802.16, BLUETOOTHOr another suitable wireless communication method to exchange data with the data server 115n, the application server 152, or any other communication channel.

In yet another embodiment, the communication unit 245 comprises a cellular communication transceiver for sending and receiving data over a cellular communication network, such as via Short Messaging Service (SMS), Multimedia Messaging Service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, email, or another suitable type of electronic communication. In yet another embodiment, the communication unit 245 includes a wired port and a wireless transceiver. Communication unit 245 also provides other conventional connections to a network for distributing files and/or media objects using standard network protocols, such as TCP/IP, HTTP, HTTPs, and SMTP, as will be understood by those skilled in the art.

Grid state manager 202 is software that includes routines for managing activity information received from data manager 103 n. In one embodiment, grid state manager 202 is a set of instructions executable by processor 235 to provide the functionality described below for hosting a message queue for each data manager 103n and receiving and validating data manager session requests. In another embodiment, the grid state manager 202 is stored in the memory 237 and is accessible and executable by the processor 235. In either embodiment, the grid state manager 202 is adapted to cooperate and communicate with the processor 235 and other components of the data manager 103 via signal lines 222.

Registration engine 204 is software and routines for registering users 125n for access to data manager 103 n. In one embodiment, the registration engine 204 is a set of instructions executable by the processor 235 to provide the functionality described below for registering a user. The enrollment engine 204 receives a username and password, generates a unique identifier associated with the data manager 103n, and receives user preferences for the user interface generated by the data manager 103n, such as preferred screen font size, color, and how to organize the application. In another embodiment, the registration engine 204 is stored in the memory 237 and is accessible and executable by the processor 235. In either embodiment, the registration engine 204 is adapted to cooperate and communicate with the processor 235 and other components of the meeting engine 200 via signal lines 224. In one embodiment, registration engine 204 communicates with master data manager 103a to coordinate registrations. In another embodiment, the registration engine 204 is a component of the master data manager 103 a.

The classifier 206 is software and routines for handling payloads from the data manager 103. In one embodiment, the classifier 206 is a set of instructions executable by the processor 235 to place incoming payloads in the payload queue 210, identify a destination for each payload, place new payloads from the payload queue 210 in an outbox for the destination data manager 103n via the communication unit 245, and delete payloads from the payload queue 210 after receiving a drop request.

Data manager 103

Referring now to FIG. 2B, the data server 115 includes a data manager 103, a memory 237, a processor 235, a communication unit 245, and a storage device 141, each connected to a bus 220. Those skilled in the art will recognize that some of the components of the data server 115 have the same or similar functionality as the components of the rendezvous server 101 and therefore the description of these components will not be repeated here. For example, the processor 235, the memory 237, the bus 220, and the communication unit 245 are similar to the processor 235, the memory 237, the bus 219, and the communication unit 245, respectively.

In one embodiment, the data manager 103 includes a controller 201, a grid engine 203, an application 205, an application manager 207, a Virtual Care Team (VCT) module 209, a scrubber module 211, and a user interface engine 213.

The controller 201 is software including routines for managing core functions of the data manager 103 and for transmitting data to different components. In one embodiment, the controller 201 is a set of instructions executable by the processor 235 to provide the functions described below for managing data. In another embodiment, the controller 201 is stored in the memory 237 and is accessible and executable by the processor 235. In either embodiment, the controller 201 is adapted to cooperate and communicate with the processor 235 and other components of the data manager 103 via signal lines 230.

In one embodiment, the controller 201 listens for data through a listening port, scanning a folder, etc.; insert data into locations such as TCP ports, folders, etc.; parsing by converting incoming data into objects, such as Java objects; analyzing by inspecting the object to determine an action; saving data by creating a new topic or adding to a topic saved in the data storage 141; formatting by presenting the data in a desired format, such as by mapping, translation, and grouping; the packets are sent for distribution and notification is made, for example, by sending an email or Web reminder in response to an event occurrence, to thereby perform the core functions.

The grid engine 203 is software that includes routines for managing healthcare information on the data server 101. In one embodiment, grid engine 203 is a set of instructions executable by processor 235 to provide the functions described below for storing objects in storage 141, generating and encrypting payloads, generating queues for outbound payloads, uploading payloads to rendezvous engine 200, downloading payloads from rendezvous engine 200, generating queues for inbound payloads, decrypting and processing received payloads, executing commands from master data manager 103a, and performing maintenance activities. In another embodiment, the grid engine 203 is stored in the memory 237 and is accessible and executable by the processor 235. In either embodiment, the grid engine 203 is adapted to cooperate and communicate with the processor 235 and other components of the data manager 103 via signal lines 232.

In one embodiment, storage 141 includes a node repository and a topic repository. The node repository stores identifiers for other data managers 103n (i.e., other nodes in the system 100) and information, such as Public Key Infrastructure (PKI) information, for authenticating data requests from the nodes. Memory device 141 is coupled to bus 220 via signal line 248.

The topic repository stores topic objects that include topic attributes and summaries (capsules). In one embodiment, the topic attributes include an identifier (e.g., a Universally Unique Identifier (UUID) associated with the open source software), a participant list, a creation date, a last modified date, a description, and a type. A summary is a serialized object stored as a name/value pair. In one embodiment, the summary includes identifiers (e.g., HL7, original HL7, doctor, patient, Audit), descriptions, and information specific to the type of information in the summary, such as information about tests, departments, doctors, topic status, node IDs, patient information, and Audit information. The summary supports a number of data formats including health level 7 (HL7), extensible markup language (XML), Portable Document Format (PDF), Tagged Image File Format (TIFF), waveform audio file (WAV), digital imaging and communications in medicine (DICOM), and Moving Picture Experts Group (MPEG). One of ordinary skill in the art will appreciate that other data formats are possible. The grid engine 203 sends the topics to any other data manager 103n in the system 100. When a data manager 103n makes a change to a copy of a topic, the grid engine 203 sends copies to other data managers 103n to update their topic copies.

Referring now to FIG. 3A, a more specific embodiment of the grid engine 203 is illustrated. The grid engine 203 includes a payload generator 301, an inbox 303, an outbox 305, an uploader 307 and a downloader 309. The payload generator 301 performs an authentication function and generates a payload. In one embodiment, the payload generator 301 generates a public/private key pair, stores the private key in the data storage 141, and sends the public key to the other data manager 103n that has access to the payload.

The payload generator 301 generates a payload including the topic object. In one embodiment, the payload includes a class handle, a payload type, a topic participant, a payload topic, a payload identifier, a primary physical identifier, a summary, and a topic. The class handle is used to activate the grid engine 203 of the data manager 103n that receives the payload. The payload type is a topic or summary. The topic parameter is a list of data managers 103n that have access to the topic. The payload summary is a list of identifiers for summaries contained in the payload. The payload identifier is a unique identifier, such as a UUID, for identifying the payload. The primary physical identifier is a unique identifier of the data manager 103 that created the original payload.

Once the payload generator 301 creates the payload, the payload generator 301 generates a payload header including an identifier for the recipient data manager 103n and encrypts the payload with the public key of the recipient data manager 103 n. In one embodiment, the payload generator 301 encrypts the payload by encrypting the topic attribute and the summary with a 2048 bit Advanced Encryption Standard (AES) symmetric key, incorporates a digital signature of the data manager 103 that created the payload with a hash-based message authentication code (HMAC), and encrypts the payload using hypertext transfer protocol security (HTTPS).

The outbox 305 maintains an outbox queue. In one embodiment, the outbox 305 stores the payload created by the payload generator 301 in an outbox queue, periodically contacts the rendezvous engine 200, establishes Secure Sockets Layer (SSL), updates the contents of the message outbox queue, and sends a drop request to the rendezvous engine 200 via the communication unit 245. The rendezvous engine 200 places the payload in an outbox for the destination data manager 103 n. The destination data manager 103n downloads the payload, decrypts the AES key with its private key, and decrypts the payload using the AES key.

Inbox 303 maintains a message inbox queue by downloading any new messages from rendezvous engine 200 via communication unit 245 and places the new messages in the message inbox queue.

Application 205

The application 205 is software including routines for performing tasks. In one embodiment, the application 205 is a set of instructions executable by the processor 235 for performing tasks. In another embodiment, the application 205 is stored in the memory 237 of the data server 115 and is accessible and executable by the processor 235. In either embodiment, the application 205 is adapted to cooperate and communicate with the processor 235, the storage device 141, the controller 201, the application manager 207, the user interface engine 213, and other components of the data server 115 via signal lines 226.

Applications 205 include any type of application, such as enterprise applications, billing applications, word processing applications, media applications, and the like. The applications are used to perform tasks such as retrieving the patient's healthcare data, processing payments received from insurance providers, authorizing payments, ordering laboratories, dictating software, maintaining a healthcare registry (e.g., bone marrow), receiving the patient's health check results from the laboratory, sending prescriptions to a pharmacy, etc. In one embodiment, the application 205 is developed by the user 125. In another embodiment, the application 205 is a third party application downloaded from the application server 152 and installed on the data server 115. The application server 152 includes, for example, an application repository that allows users to search, browse, purchase, and download third party applications.

Application manager 207

The application manager 207 is software including routines for developing and managing the application 205. In one embodiment, the application manager 207 is a set of instructions executable by the processor 235 to provide the functionality described below for developing and maintaining the application 205. In another embodiment, the application manager 207 is stored in the memory 237 of the data server 115 and is accessible and executable by the processor 235. In either embodiment, the application manager 207 is adapted to cooperate and communicate with the processor 235, the storage device 141, the controller 201, the application 205, the user interface engine 213, and other components of the data server 115 via signal lines 239. The application manager 207 is described in more detail with reference to fig. 3B.

Figure 3B illustrates one embodiment of the application manager 207 in more detail. In this embodiment, application manager 207 includes an application module 302, a attestation module 304, a collaboration module 306, a context module 308, and a bridge module 310.

The application module 302 is software that includes routines that allow the user 125 to develop and install the application 205 on the data server 115. The application module 302 receives requests submitted by the user 125 from the controller 201 for developing new applications, installing third party applications, and the like. In one embodiment, the application module 302 includes a Software Development Kit (SDK) that includes a set of development tools that allow the user 125 to develop the application 205. In another embodiment, the application module 302 allows the user 125 to download and install third party applications 205 from the application server 152. In both embodiments, the application module 302 allows the user 125 to define preferences and rules for the application 205. The application module 302 stores the rules and preferences in the storage device 141. In yet another embodiment, the application module 302 includes tools for developing Application Programming Interfaces (APIs) for allowing the data manager 103 to interact with third party applications stored in the application server 152 or any other data server 115 n. In one embodiment, the application module 302 uses Java adapters to provide software developers with tools for accessing different information platforms, such as the data server 115n and local, state, and national registries. The application module 302 sends the newly created application to the application server 152 via the communication unit 245 to make it available to other users.

Examples of tools for accessing the platform include a journal API for creating, updating, and accessing data in a personal journal; a messaging API for accessing the secure messaging infrastructure to exchange information with other platforms; a physician catalog API for accessing a global catalog of physicians and other providers on the grid; a print service for accessing a local printer; an international disease classification (ICD) -9 diagnostic table for accessing ICD lookup; a current surgical terminology (CPT) lookup to access a CPT surgical table; a Practice Management (PM) bridge for accessing data for demographic, insurance, and scheduling queries from the MPS bridge; an electronic medical record driver for accessing clinical and other data queries and implementing insertion results, reports, referrals and other information; a vocabulary mapping service for translating local terms into standardized terms (e.g., systematic medical nomenclature (SNOMED)); a formatting service for a standardized form; a community search for searching for patient information in a Health Information Exchange (HIE); and a payer gateway for exchanging information with payers who make their services available in the electronic exchange.

The journal API is used to create patient records. In one embodiment, the log API includes demographic information including a name, date of birth, and address for the patient; scheduling information, the scheduling information including a reservation type, a date and a time; current and historical clinical problems of the patient; for surgery or treatment of a patient; family history; social history including lifestyle, occupation, environmental health risks, and patient demographics such as marital status, ethnicity, and religion; high-level indications including intent, healthcare agents, and resuscitation intent, including patient instructions and references to external documents; reminders such as allergies and adverse reactions; medications, including current medications and related historical medication use; immunization, including immune status and historical information about past immunizations; medical devices and any implanted or external devices; vital signs, including trends and baselines over time; functional state, including information about what is normal for the patient, deviations from normalcy (both positive and negative), and epitaxial examples; results, including laboratory and surgical results and reports; occasions (encounters), including past healthcare occasions, including activities and locations; and care plans, including active, incomplete, or unexhausted activities for the patient, including orders, appointments, procedures, referrals, and services.

The attestation module 304 is software that includes routines for attesting to the applications 205 developed by the users 125. In one embodiment, attestation module 304 receives a message from application module 302 that user 125 has developed a new application. The attestation module 302 determines whether the new application is compatible with the application 205 installed on the data server 115. For example, attestation module 304 determines whether the new application includes an API for interacting with application 205. In another embodiment, the attestation module 304 attests that the new application can be uploaded to the application server 152. The attestation module 304 instructs the user interface engine 213 to generate a user interface to display the message. In one embodiment, the message indicates that the new application is certified for installation on the data server 115, uploaded to the application server 152, and the like. In another embodiment, the message indicates that the new application is not certified and includes a list of questions that need to be resolved in order to certify the new application.

The collaboration module 306 is software that includes routines for generating a list of data servers 115n in communication with the data server 115 a. In one embodiment, the list includes the applications installed in each of the data servers 115 n. The collaboration module 306 generates the list in response to receiving a request submitted by the user 125 to develop a new application. The user 125, for example, uses the list to develop an API for the new application.

The context module 308 is software that includes routines for managing interactions between the applications 205. The context module 308 receives messages from the application 205 while the application 205 is performing tasks. The context module 308 analyzes tasks, such as analyzing requests submitted by the user 125, retrieved healthcare data for the patient, and the like. The context module 308 determines whether the analysis matches one or more rules or preferences defined for any other applications installed on the data server 115. In response to determining that the rule or preference of the application matches, the context module 308 sends a notification to the application. Context module 308 is described in more detail with reference to FIG. 7.

The bridge module 310 is software that includes routines for managing the exchange of data between the application 205 and computing systems, e.g., PMS121, EMR application 123, diagnostic devices (not shown), etc., that are locally connected to the data server 115. The bridge module 310 communicates data, such as queries, instructions, messages, patient's healthcare data, and the like, between the application 205 and the local computing system. The bridge module 310 converts the data into a format compatible with the requirements of the destination. For example, the application 205 generates a query for retrieving a list of patients with leukemia from the EMR application 123. The bridge module 310 converts the query to the HL7 standard and submits the query to the EMR 123. The bridge module 310 receives the patient list from the EMR123, converts the list into a PEF as requested by the application 205, and sends it to the application 310. The bridge module 310 converts the data to HL7 standard, care document continuity (CCD), care record continuity (CCR), Structured Query Language (SQL), PDF, or any other format or standard known to one of ordinary skill in the art.

Virtual Care Team (VCT) module 209

A Virtual Care Team (VCT) module 209 is software that includes routines for creating VCT records relating to a particular patient and for collaborating with other data servers 115 n. In one embodiment, the VCT module 209 is a set of instructions executable by the processor 235 to provide the functionality described below for creating VCT records and collaborating with other data servers 115 n. In another embodiment, the VCT module 209 is stored in the memory 237 of the data server 115 and is accessible and executable by the processor 235. In either embodiment, the VCT module 209 is adapted to cooperate and communicate with the processor 235, the storage device 141, the controller 201, the user interface engine 213, and other components of the data server 115 via signal lines 240.

The VCT records include healthcare data associated with a patient or a group of patients (e.g., family, colleagues, etc.). Healthcare data includes patient Identity (ID), demographic information, information related to the patient's care team, insurance information, prescriptions, outcomes, allergies, medical history, referrals, rules, preferences, and the like. The patient's care team is a set of data servers 115n (e.g., attending physicians, cardiologists, insurance providers, etc.) associated with the patient's healthcare. The VCT module 209 is described in more detail with reference to fig. 3C.

Fig. 3C illustrates one embodiment of the VCT module 209 in more detail. In this embodiment, the VCT module 209 includes a creation module 352, a referral module 354, a data transmitter 356, a data receiver 358, and an advertisement module 360.

The creation module 352 is software that includes routines for creating VCT records. The creation module 352 receives requests from the controller 201 submitted by the users 125 to create VCT records (e.g., requests submitted by hospital administrators to create VCT records for new patients). The creation module 352 generates VCT records based on information included in the request (e.g., a registration form filled out by the patient, etc.). In one embodiment, the creation module 352 retrieves additional information about the patient from a local database, such as the PMS121, EMR application 123, or the like, when insufficient information is included in the request. In another embodiment, the creation module 352 instructs the user interface engine 213 to generate a user interface that requests additional information from the user 125. The creation module 352 stores the VCT record in the storage device 141. The creation module 352 generates VCT records that facilitate sending information to other data servers 115n and that facilitate sending complete records to applications outside the system 100.

The referral module 354 is software that includes routines for sending and receiving referrals for a patient to and from other data servers 115 n. The referral module 354 identifies one or more data servers 115n for the patient from a data server directory in the storage device 141. In one embodiment, the referral module 354 identifies the data server 115b in response to receiving a request submitted by the user 125a from the controller 201. The request is submitted, for example, by an attending physician, to identify a cardiologist for the patient. In another embodiment, the referral module 354 automatically identifies the data server 115b based on the patient's VCT records. For example, the referral module 354 determines a patient insurable item from the patient's VCT records. The referral module 354 then identifies an insurance provider for the patient. In yet another embodiment, the referral module 354 identifies the data server 115b for the patient in response to receiving the instruction from the application 205. The referral module 354 identifies the data server 115n for the patient corresponding to the information in the patient's VCT record. For example, referral module 354 identifies clinics located within five miles of the patient's residence, neurology specialists covered by the patient's insurance provider, and so forth.

Referral module 354 instructs controller 201 to send the referral to data server 115b. The instructions include a copy of the patient's VCT records and information such as an identification of the data server 115b, a method for communicating with the data server 115b, and the like. The referral module 354 updates the patient's VCT records by adding the data server 115b to the patient's care team. In one embodiment, the referral module 354 updates the VCT record for the patient in response to receiving the confirmation from the data server 115b.

Referral module 354 also receives referrals sent by other data servers 115n from controller 201. The referral module 354 extracts a copy of the patient's VCT records from the referral and assigns a patient ID local to the data server 115 a. The referral module 354 then creates a link between the local patient ID and the patient ID present in the VCT record. The referral module 354 updates a copy of the patient's VCT record with the link and stores it in the storage device 141. The referral module 354 also instructs the controller 201 to send the link to the data server 115n from which the referral was received. The referral module 354 is described in more detail with reference to fig. 8A.

The data receiver 356 is software that includes routines for receiving new healthcare data associated with a patient from the controller 201. In one embodiment, the data receiver 356 receives new healthcare data submitted by the user 125. For example, the data receiver 356 receives a patient's blood pressure level submitted by a nurse. In another embodiment, the data receiver 356 receives healthcare data from a computing system locally connected to the data server 115 a. For example, the data receiver 356 receives a scanned image of the patient's shoulder from an MRI scanner connected to the data server 115 a. In yet another embodiment, the data receiver 356 receives new healthcare data, such as prescriptions, updated insurance program plans, etc., sent by other care team members of the patient. In this embodiment, data receiver 356 determines whether new healthcare data is needed by data server 115a based on rules and preferences stored in storage 141. For example, cardiologists require blood test results from patients, but physical therapists do not. In one embodiment, the data receiver 356 instructs the user interface engine 213 to generate a user interface that displays the new healthcare data. In this embodiment, the user 125 (e.g., physician, nurse, etc.) selects new healthcare data that is needed by the data server 115 a. The data receiver 356 receives the patient's VCT record and updates it with new healthcare data.

In one embodiment, data receiver 356 performs reconciliation (reconcile) of the new data including the conflict information. For example, the new information is demographic information that does not match any patient data in the storage device 141. The data receiver 356 determines different patients that may match the demographic information, e.g., if the numbers in the birth data are exchanged or the name "jone" is replaced with "john," the data receiver 356 identifies patients that match the demographic information. Data receiver 356 maintains rules in storage device 141 for correcting conflicting information. In one embodiment, the data receiver 356 sends the corrected data to the care team member submitting the conflicting information via the communication unit 245 for confirmation. If the same conflicting information is received in the future, the data receiver 356 uses the same rules to correct the information.

The data transmitter 358 is software that includes routines for transmitting healthcare data associated with a patient to a patient's care team member via the communication unit 245. Data transmitter 358 receives new healthcare data associated with the patient from data receiver 356. Data transmitter 358 identifies the patient's care team member from the VCT record. The data transmitter 358 then instructs the communication unit 245 to transmit the new healthcare data to the patient's care team members. In one embodiment, prior to instructing the communication unit 245, the data transmitter 358 formats the new healthcare data based on each of the care team member's preferences. In another embodiment, the data transmitter 358 determines whether new healthcare data may be transmitted to the care team member based on rules present in the patient's VCT record (e.g., care team member preferences, privacy rules of the patient, HIPAA compliance, etc.).

The notification module 360 is software including routines for notifying the data server 115 a. The notification module 360 generates a notification including a unique identifier (such as a UUID) associated with the data server 115a and instructs the controller 201 to send them to the other data servers 115 n. The notification includes information about the data server 115a, such as a list of healthcare services provided by the data server 115a, a list of physicians, a list of insurance plans covering the services provided by the data server 115a, a location, and so forth. The notifications are advantageous, for example, because the other data servers 115n send referrals to the data server 115a based on these notifications.

Scrubber module 211

The scrubber module 211 is software that includes routines for identifying individuals for a study (such as a clinical trial) and for scrubbing identifying information data for a patient. In one embodiment, the scrubber module 21 is a set of instructions executable by the processor 235 to provide the functionality described below for scrubbing identification information in response to a request from the application 205. In another embodiment, the scrubber module 211 is stored in the memory 237 of the data server 115 and is accessible and executable by the processor 235. In either embodiment, the scrubber module 211 is adapted to cooperate and communicate with the processor 235, the storage device 141, the controller 201, the application 205, the user interface engine 213, and other components of the data server 115 via signal lines 242. The scrubber module 211 is described in more detail with reference to fig. 3D.

Referring now to FIG. 3D, one embodiment of the scrubber module 211 is shown in greater detail. FIG. 3D is a block diagram of a scrubber module 211, the scrubber module 211 including a notification enumeration engine 372, a participant identification engine 374, a data scrubbing engine 376, a pseudo-identifier generator engine 378, and a notification response engine 380, each coupled to a signal line 242.

The notification enumeration engine 372 registers notifications for recruiting potential participants for the study. The notification enumeration engine 372 receives requests from an organization for potential participants for a study. An organization is any group that uses medical information, such as government health organizations (e.g., CDCs), insurance companies, and clinical research organizations (e.g., hospitals).

The request includes an identifier, such as a name for the study and a patient factor for identifying potential participants for the study. For example, a clinical research organization uses the scrubber module 211 to identify a plurality of individuals available for a study testing medications for a health condition in which patients are in a particular age group and have responded adversely to different medications. The clinical research organization issues a notification that includes input data identifying the participants. The input data relates to diagnosis, medication, laboratory results, gender, age, location, previous medical history (such as previous conditions, medical history) and other factors relevant to the study. In one embodiment, the notification enumeration engine 372 sends a request to the participant identification engine 374 for immediate identification of potential participants for the study. In another embodiment, the participant identification engine 374 stores a request in storage 141 for identification of potential participants for the study at a later time.

The participant identification engine 374 identifies potential participants for the study based on the notifications from the organization received from the notification enumeration engine 372. The participant identification engine 374 identifies individuals based on matching input data with patient data and medical records. In one embodiment, information for the identified individual is sent to the data washing engine 376. In another embodiment, the number of individuals identified as matching is sent to the notification response engine 380.

The data washing engine 376 modifies the patient data to wash its identifying aspects. In one embodiment, the data washing engine 376 receives a request from the application 205 to wash patient data. For example, patient data includes data relating to admission to a patient or a laboratory event. In another embodiment, the data washing engine 376 receives individuals matching the notification from the participant identification engine 374. The data washing engine 376 receives patient data from a main patient index that is part of the data storage device 141 or stored at another location, such as part of the EMR application 123. In one embodiment, the data washing engine 376 modifies the identification information by removing demographic data. Identifiable demographic data includes name, address, date of birth, race, government issued number, such as social security number, and business patient number, such as patient identifier. In another embodiment, the data washing engine 376 modifies the patient data by replacing the identifiable demographic data. For example, the data washing engine 376 replaces the birth date with the age of the individual or swaps numbers for the birth date.

The data washing engine 376 requests the pseudo-identifier from the pseudo-identifier generator engine 378. The pseudo-identifier generator engine 378 generates a pseudo-identifier for the patient. The data washing engine 376 receives the pseudo-identifier from the pseudo-identifier generator engine 378 and associates the pseudo-identifier with the patient by storing the pseudo-identifier in the storage device 141.

In another embodiment, the data washing engine 376 associates the pseudo-identifier with the patient by storing the pseudo-identifier with the patient data in a master patient index. The data washing engine 376 sends the pseudo-identifier and other data to the application 205 requesting washing or to the notification response engine 380. Thus, the pseudo-identifier is used by an organization to retrieve a person's medical record without revealing the person's identity. Also, since the pseudo-identifier is a static identifier that is always associated with the same patient, the organization requesting the pseudo-identifier tracks the same person over time. For example, clinical research companies use the flusher module 211 for studies on the same person over a 5 year period.

The advisory response engine 380 responds to advisories used to recruit potential participants for the study. The advisory response engine 378 receives the number of patients that match the input data from the patient identification engine 374 or the washed information from the pseudo identifier generator 378. In one embodiment, the advisory response engine 380 notifies the care provider that the individual is identified as a potential participant for the study. In another embodiment, notification response engine 380 sends basic statistics (statistics) to the organization requesting the potential participants. For example, notification response engine 380 notifies the organization of the specific number of potential participants that participant identification engine 372 has identified.

User interface engine 213

The user interface engine 213 is software that includes routines for generating user interfaces in response to instructions received from other data manager 103 components. In one embodiment, the user interface engine 213 is a set of instructions executable by the processor 235 to provide the functionality described below for generating a user interface for the application 205, the VCT module 209, or the scrubber module 211. In another embodiment, the user interface engine 213 is stored in the memory 237 of the data server 115 and is accessible and executable by the processor 235. In either embodiment, the scrubber module 211 is adapted to cooperate and communicate with the processor 235, the storage device 141, the application 205, the user interface engine 213, and other components of the data server 115 via signal lines 242. The user interface engine 213 is described in more detail with reference to fig. 4A-4H.

Turning now to the user interface engine 213, fig. 4A is a graphical representation of a user interface 401 generated by the user interface engine 213 for accessing at least one patient record. In this example, the user interface 401 displays a home page 402 for the medical office web site of the healthcare provider for the medical office. The home page 402 includes icons 404 of the underlying composite applications that the user installs to meet his or her unique needs. The user searches for patient records by typing in the first name of the patient, the last name of the patient, or any combination thereof in a search box and clicking on the search button 406 on the home page 402. For example, the key "Angela" in the search box is used to retrieve the list 412 of patients whose names include Angela. In addition, the home page 402 includes an enumerate all 408 button that, when selected, displays the entire list of available patient records and a create records 410 button that, when selected, displays a user interface for creating records for the new patient.

Fig. 4B is a graphical representation 403 of a user view of an application repository hosted by the application server 152. In this embodiment, the application repository includes a category icon 422 through which the user can view and select the type of application to be installed. In addition to category icons 422, the application repository enumerates applications that belong to a particular type under the section, such as popular applications, suggested applications, installed applications, updates to installed applications, and new applications. In this example, the user selects all buttons 424 and selects the "what is new" tab 426. A child section 428 opens that lists all applications under what is the new tab page 426 and the user selects to purchase the timeline application 430. In another embodiment, at least one of the enumerated applications is installed for free by the user. In yet another embodiment, the applications listed in the application repository are developed by third party vendors.

Fig. 4C is a graphical representation 405 of a user view of the functionality provided by the referral application 430 including sending and receiving patient referrals. In this embodiment, the referral application 430 displays a work list 432 that includes patient referrals 438 sent by the user in response to the user selecting the send referral 436 option. In another embodiment, the options present in the header 434 include drop-down boxes for illustrating the different categories in order to narrow referrals of interest to the user. For example, under the send referral 436 option, the user may choose to individually view completed, ongoing, rejected, and not yet accepted referrals if of interest. Each patient referral 438 includes the patient's name, the status of the referral, the department or institution to which the referral was sent, and the date and time of the referral, updates and schedules. The user interface engine 213 allows the user to configure the display of referral information 438 and other features of the display.

Fig. 4D is another graphical representation 407 of a user view of the functionality provided by the referral application 430 in response to clicking on the patient referral 438 in fig. 4C. In this embodiment, the underlying composite application list displayed near the top of the web page visually changes their appearance at least in part to reflect the medical records of the patient 440 associated with the patient referral 438 from FIG. 4C. Referral application 430 includes accompanying referral information 442 listing the referral provider, referral details, scheduling information and any messages exchanged between the referral provider and the referred provider relating to patient treatment.

Fig. 4E is a graphical representation 409 of a user view of the functionality provided by the patient care timeline application 452. The graphical representation 409 displays a sliding list 454 of encounters with the patient 440, including routine visits, laboratory tests and examinations from at least one healthcare facility. Upon selection of one such encounter 456, the patient care timeline application 452 displays a subsection 458 that lists the details of that particular encounter. The sub-section 458 includes the name, visit type, opinion, personal and medical information of the physician of the patient 440. Each information tab page 460 associated with the patient 440 expands in response to clicking on it to allow the user to specifically view the information and edit the information if needed. In another embodiment, the patient care timeline application 452 visually indicates to the user that at least one of the other underlying applications has important patient information related to the patient care timeline application 452. For example, an exclamation point highlighted on the patient care timeline application 452 in response to the number three highlighted on the virtual care team application is an indication that the two applications are ready to communicate with each other to reconcile patient records.

Fig. 4F is a graphical representation 411 of a user view of reconciliation updates obtained by the virtual care team application 462 for reconciliation with patient records. The virtual care team application 462 displays an update tab page 464 associated with different departments and/or institutions. Further, the virtual care team application 462 displays a visual number indicating the number of updates to reconcile. In this example, the virtual care team application 462 displays the number three. The update tab page 464 associated with the department and/or institution includes the day, date, time, and time zone for each individual update 466 received. In one embodiment, the user is required to authorize reconciliation updates 466 by selecting a check box next to each update 466. In another embodiment, reconciling all updates at once without checking is "mark update as reconciled? A reconciliation button under the "text 468 checks each individual update 466.

Fig. 4G is another graphical representation 413 of a user view of the patient care timeline application 452 after reconciling patient records with updates from the virtual care team application 462. The user interface engine 213 changes the appearance of the patient care timeline application 452 at least partially in response to reconciling the updates in the virtual care team application 462 in fig. 4F. In this embodiment, the patient care timeline application 452 displays the updated encounter and the updated fields in the encounter by highlighting them for at least one period of time to the user. In this example, cardiac stress test encounter 472 is highlighted after the user clicks on the patient care timeline application 452, along with accompanying payer information tab page 474, issue information tab page 476, and medication information tab page 478.

Turning now to FIG. 4H, one embodiment of a user interface 481 generated by the user interface engine 213 is illustrated for generating a request or notification for recruiting potential participants for a study. User interface 481 displays a number of inputs for generating a request. The plurality of inputs includes an input 483 for identifying or tagging the study. User interface 481 displays an input area 485 for capturing medical-related criteria for creating input data used to identify a patient for a study. In an example, the input area 485 includes diagnostic information, allergy information, medication information, and laboratory results information. User interface 481 displays gender input 487 identifying one or all genders for the study. User interface 481 displays an age input 489 for identifying an age or age group for the study. The user submits the request or notification by pressing the submit button 491. One of ordinary skill in the art will recognize that other variables may also be displayed for generating a request, such as text boxes for specifying location, previous condition, family history of the condition, and the like. The notification enumeration engine 372 receives a request for identification of potential participants for a study and registers the request.

Method of producing a composite material

Referring now to fig. 5-10, various exemplary embodiments of the invention will be described.

Figure 5 is a flow diagram 500 illustrating one embodiment for generating a payload. The first data manager 103a includes a grid engine 203 that generates 502 public/private key pairs and sends 504 the public key to all authorized data managers 103 n. In one embodiment, the public/private key pair is generated using a 2048 bit RSA PKI. The grid engine 203 generates 506 a payload for a topic object that includes a topic attribute and a plurality of summaries. The grid engine 203 encrypts 508 the payload. In one embodiment, grid engine 203 uses an AES symmetric key to encrypt the topic object. The topic engine 203 uploads 510 the payload to the inbox for the rendezvous engine 200 via the communication unit 245.

Figure 6 is a flow diagram 600 illustrating one embodiment for using a rendezvous engine 200 to send data between data managers 103 n. The rendezvous engine 200 includes a classifier 206 that receives 602 a payload from a first data manager via a communication unit. The classifier 206 classifies 604 the payload into the payload queue 210. The classifier 206 identifies 606 the destination for the payload as the second data manager 103 b. The classifier 206 places 608 the payload in the outbox for the second data manager 103 b. The second data manager 103b downloads 610 the payload and decrypts 612 the payload.

FIG. 7 is a flow diagram 700 illustrating one embodiment for sending notifications to an application based on tasks performed by another application. The controller 201 receives 702 a user-submitted request to retrieve patient data using a retrieval application. The retrieval application retrieves 704 patient data. For example, the retrieval application retrieves a patient's Virtual Care Team (VCT) record from the data storage 141. The user interface engine 213 generates 706 a user interface that displays the patient data. The application manager 207 includes a context module 308 that determines 708 whether the patient data matches the rules of the health monitoring application. The context module 308 sends 710 a notification to the health monitoring application in response to determining that the patient data matches the rule. In this example, the context module 308 determines from the patient's VCT records that the patient's cholesterol level is above a threshold and sends a notification to the health monitoring application. The health monitoring application instructs the user interface engine 213 to generate a user interface. The user interface engine 213 generates 714 a user interface for displaying the message. In this example, the user interface displays a warning message that the patient's cholesterol level is too high.

Figure 8A is a flow diagram 800 illustrating one embodiment for delivering a referral. The VCT module 209 includes a creation module 352 that assigns 802 a first patient Identifier (ID) to a new patient (e.g., attending caregiver). The creation module 352 creates 804 a VCT record for the patient. In this example, the attending physician 115a diagnoses that the patient requires surgery on his knee and submits a request. The referral module 354 identifies the data server 115b (e.g., orthopaedic surgeon) from the storage device 141. The controller 201 sends 806 the referral to the data server 115b via the communication unit 245. The referral includes a copy of the patient VCT record including the first patient ID. The referral module 354 also updates 808 the VCT record to include the data server 115b as a member of the patient's care team. The referral module 354 of the data server 115b assigns 810 a second patient ID for referral based on the format requirements and rules of the data server 115b. The referral module 354 generates 812 a first link between the first patient ID and the second patient ID. The controller 201 of the data server 115b then sends 814 the first link to the data server 115 a. The referral module 354 of the data server 115a updates 816 the VCT record to include the first link.

The referral module 354 of the data server 115b then identifies the data server 115n (e.g., physical therapist) for the patient. The controller 201 of the data server 115b sends 818 a referral to the third data server 115 n. This referral includes a copy of the patient's VCT record including the second patient ID and the first link. The referral module 354 of the data server 115b updates 820 the VCT record to include the data server 115n as a member of the patient's care team. The referral module 354 of the data server 115n assigns 822 a third patient ID for the referral. The referral module 354 of the data server 115n also generates 824 a second link between the first patient ID, the second patient ID and the third patient ID. The controller 201 of the data server 115n then sends 826 the second link to the data server 115b. The referral module 354 of the second data server 115b updates 830 the VCT record for the patient to include the second link. The controller 201 of the data server 115n also sends 828 a second link to the data server 115 a. The referral module 354 of the data server 115a updates 832 the VCT record for the patient to include the second link and the data server 115n as members of the patient's care team.

The linking is advantageous, for example, in scenarios when the data server 115a receives healthcare information represented by the second patient ID from the data server 115b. In this example, the data server 115a readily identifies and retrieves the VCT record for the patient based on the first link. Additionally, in this example, the second link allows healthcare information associated with the patient to be exchanged between the data servers 115a, 115b, 115n, although the data server 115a is not referral by the data server 115 a.

FIG. 8B is a flow chart 850 illustrating one embodiment for exchanging information between the patient's care team members. The data receiver 356 of the data server 115a receives 852 new information associated with the patient. The data receiver 356 updates 854 the patient's VCT record with the new information. The data transmitter 358 of the data server 115a determines 856 whether new information should be transmitted to other care team members of the patient. In response to determining that the new information should be sent, the data transmitter 358 sends 858 the new information to the data server 115b. The data transmitter 358 also transmits 860 new information to the data server 115 n. The data receiver 356 of the data server 115b determines 862 if new information is needed. The data receiver 356 updates 864 the patient's VCT records in response to determining that new information is needed. The data receiver 356 of the data server 115n determines 866 whether the data server 115n requires new information. The data receiver 356 rejects 868 the new information in response to determining that the data server 115n does not require the new information.

Fig. 9 is a flow diagram 900 of one embodiment of a method for recruiting participants for a study. The notification enumeration engine 374 receives 902 a request for potential participants for a study, the request including input data identifying the potential participants. In one embodiment, the input data includes information relating to diagnosis, medication, laboratory results, gender, age, location, and the like. The notification enumeration engine 374 stores 906 the request and input data in the storage device 141. The participant identification engine 372 receives 906 the patient information or an update to the patient information. The participant identification engine 372 identifies 908 potential participants based on the input data and the patient information. The notification response engine 378 generates 910 a report or message based on identifying the potential participants. In one embodiment, the notification engine 378 generates a message that the individual is a matchmaker for the study. In this embodiment, the message is sent to a care provider or individual. In another embodiment, the notification response engine 378 generates a message including statistics based on identifying one or more potential participants. In this embodiment, the advisory response engine 378 sends the message to the clinical research organization that is recruiting participants for the study.

FIG. 10 is a flow diagram 1000 of one embodiment of a method for pseudoanonymizing patient information. The data washing engine 376 receives 1002 data relating to a patient. In one embodiment, the data relates to admission to a patient or a laboratory event. The data washing engine 376 modifies 1004 the data by removing demographic information. In one embodiment, the data washing engine 376 removes any critical information used to identify the individual. For example, the key information includes a name, social security number or other government identifier, date of birth, mailing address, or ethnicity. In another embodiment, the data washing engine 376 modifies the data by substituting demographic data that results in the identification of the individual. In one embodiment, the critical information is determined by government standards for the purpose of protecting the identity of the individual. The pseudo-identifier generator 378 generates 1006 a pseudo-identifier for the modified data relating to the patient. The data washing engine 376 associates the pseudo-identifier with the modified data related to the patient. The data washing engine 376 stores 1010 the pseudo identifier and the modified data in the storage device 141. The data washing engine 376 receives 1012 a request for modified data, the request including a pseudo identifier. The data washing engine 376 retrieves the modified data based on the pseudo identifier and sends 1014 the modified data to the requestor via the communication unit 245.

The foregoing description of the exemplary embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims of this application. As will be understood by those skilled in the art, the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Similarly, the particular naming and division of the modules, routines, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Additionally, as will be apparent to one of ordinary skill in the art, the disclosed modules, routines, features, attributes, methodologies and other aspects can be implemented as software, hardware, firmware or any combination of the three. Moreover, wherever a component of the present invention is implemented as software, examples of which are modules, the component may be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in any other way now or hereafter known to one of ordinary skill in the art of computer programming. In addition, the present disclosure is in no way limited to implementation in any specific programming language or for any specific operating system or environment. Accordingly, the disclosure is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims (74)

1. A method for managing interactions between applications, the method comprising:

receiving a request to perform a first task using a first application;

performing the first task using the first application;

analyzing the first task performed by the first application;

determining whether the analysis matches one or more rules associated with a second application; and

sending a notification to the second application.

2. The method of claim 1, further comprising performing a second task with the second application in response to determining that the analysis matches one or more rules associated with the second application.

3. The method of claim 2, further comprising generating a user interface in response to determining that the analysis matches one or more rules associated with the second application.

4. The method of claim 3, wherein the user interface displays at least one of a message indicating that the analysis matches one or more rules and a result of the second task.

5. The method of claim 3, wherein the user interface displays an icon indicating that information from the first application needs to be reconciled with the second application.

6. The method of claim 1, wherein the first application is developed by a user.

7. The method of claim 6, further comprising certifying the first application by determining whether the first application is compatible with the second application.

8. A system for managing interactions between applications, comprising:

a controller to receive a request to execute a first task using a first application;

the first application coupled to the controller, the first application to perform the first task; and

an application manager coupled to the first application, the application manager to analyze the first task performed by the first application, determine whether the analysis matches one or more rules associated with a second application, and send a notification to the second application.

9. The system of claim 8, further comprising: a second application coupled to the application manager, the second application to perform a second task in response to determining that the analysis matches one or more rules associated with the second application.

10. The system of claim 8, further comprising: a user interface engine coupled to the application manager, the user interface engine to generate a user interface in response to determining that the analysis matches one or more rules associated with the second application.

11. The system of claim 8, wherein the user interface engine displays an icon indicating that information from the first application needs to be reconciled with the second application.

12. The system of claim 8, wherein the first application is developed by a user.

13. The system of claim 8, wherein the application manager certifies the first application by determining whether the first application is compatible with the second application.

14. A computer program product comprising a computer usable medium including a computer readable program, wherein the computer readable program when executed on a computer causes the computer to:

receiving a request to perform a first task using a first application;

performing the first task using the first application;

analyzing the first task performed by the first application;

determining whether the analysis matches one or more rules associated with a second application; and

sending a notification to the second application.

15. The computer program product of claim 14, further comprising performing a second task with the second application in response to determining that the analysis matches one or more rules associated with the second application.

16. The computer program product of claim 15, further comprising generating a user interface in response to determining that the analysis matches one or more rules associated with the second application.

17. The computer program product of claim 16, wherein the user interface displays at least one of a message indicating that the analysis matches one or more rules and a result of the second task.

18. The computer program product of claim 16, wherein the user interface displays an icon indicating that information from the first application needs to be reconciled with the second application.

19. The computer program product of claim 14, wherein the first application is developed by a user.

20. The computer program product of claim 19, further comprising certifying the first application by determining whether the first application is compatible with the second application.

21. A method for managing referrals of a patient, the method comprising:

receiving a first referral of the patient from a first server, the first referral including a first identity of the patient and a care team record;

assigning a second identity of the patient;

generating a first link between the first identity and the second identity of the patient; and

sending the first link to the first server and one or more care team members of the patient.

22. The method of claim 21, further comprising identifying a second server and sending a second referral of the patient to the second server.

23. The method of claim 22, further comprising updating the care team record of the patient with the second server.

24. The method of claim 23, further comprising receiving a second link from the second server and updating the care team record of the patient with the second link.

25. The method of claim 21, further comprising receiving new healthcare information associated with the patient.

26. The method of claim 25, further comprising determining whether the new healthcare information should be sent to the care team member of the patient.

27. The method of claim 25, further comprising:

receiving the new healthcare information from the first server;

determining whether the new healthcare information associated with the patient is needed; and

updating the care team record for the patient in response to determining that the new healthcare information is needed.

28. The method of claim 27, further comprising rejecting the new healthcare information in response to determining that the new healthcare information is not needed.

29. The method of claim 25, further comprising generating a user interface that displays the new healthcare information.

30. The method of claim 21, further comprising receiving the notification from a second server.

31. A system for managing referrals of a patient, comprising:

a controller to receive a first referral of the patient from a first server and to send a first link to the first server and one or more care team members of the patient, the first referral including a first identity of the patient and a care team record; and

a referral module coupled to the controller for assigning a second identity of the patient and for generating the first link between the first identity and the second identity of the patient.

32. The system of claim 31, wherein the referral module further identifies a second server and updates the care team record for the patient with the second server and a second link.

33. The system of claim 32, wherein the controller further sends a second referral to the second server and receives the second link.

34. The system of claim 31, further comprising: a data receiver coupled to the referral module for receiving new healthcare information associated with the patient.

35. The system of claim 34, further comprising: a data transmitter coupled to the data receiver, the data transmitter to determine whether the new healthcare information should be transmitted to the care team members of the patient.

36. The system of claim 34, wherein the data receiver receives the new healthcare information from the first server, determines whether the new healthcare information associated with the patient is needed, and updates the care team record for the patient in response to determining that the new healthcare information is needed.

37. The system of claim 36, wherein the data receiver rejects the new healthcare information in response to determining that the new healthcare information is not needed.

38. The system of claim 34, further comprising: a user interface engine coupled to the data receiver, the user interface engine to generate a user interface to display the new healthcare information.

39. The system of claim 33, wherein the controller further receives an advertisement from the second server.

40. A computer program product comprising a computer usable medium including a computer readable program, wherein the computer readable program when executed on a computer causes the computer to:

receiving a first referral of a patient from a first server, the first referral including a first identity of the patient and a care team record;

assigning a second identity of the patient;

generating a first link between the first identity and the second identity of the patient; and

sending the first link to the first server and one or more care team members of the patient.

41. A method for recruiting participants for a study, comprising:

receiving a request for a potential participant for the study, the request including input data identifying the potential participant;

storing the request in a notification database;

receiving patient information;

identifying the potential participant based at least in part on the input data and the patient information; and

generating a message based on identifying the potential participant.

42. The method of claim 41, wherein the input data comprises data relating to at least one of diagnosis, medication, laboratory results, gender, location, and age.

43. The method of claim 42, further comprising generating a user interface for capturing the input data.

44. The method of claim 41, wherein the patient information includes data relating to at least one of admission to a patient and a laboratory event.

45. The method of claim 41, wherein the message indicates that an individual is a matchmaker for the study.

46. The method of claim 45, further comprising sending the message to at least one of a care provider and the individual.

47. The method of claim 41, wherein the message includes statistics based on identifying one or more potential participants.

48. The method of claim 47, further comprising sending the message to an organization that is recruiting the participants for the study.

49. The method of claim 48, wherein the organization is one of a government health organization, an insurance company, and a clinical research organization.

50. The method of claim 41, wherein the request further includes an identifier for the study.

51. A system for recruiting participants for a study, comprising:

a processor;

a notification list engine stored on memory and executable by the processor, the notification list engine to receive a request for a potential participant for the study, the request including input data identifying the potential participant, and to store the request in a notification database;

a participant identification engine stored on the memory and executable by the processor, the participant identification engine to receive patient information and to identify the potential participant based at least in part on the input data and the patient information; and

a notification response engine stored on the memory and executable by the processor, the notification response engine to generate a message based on identifying the potential participant.

52. The system of claim 51, wherein the input data comprises data relating to at least one of diagnosis, medication, laboratory results, gender, location, and age.

53. The system of claim 52, further comprising: a user interface engine stored on the memory and executable by the processor to generate a user interface for capturing the input data.

54. The system of claim 51, wherein the patient information includes data relating to at least one of admission to a patient and a laboratory event.

55. The system of claim 51, wherein the message indicates that an individual is a matchmaker for the study.

56. The system of claim 55, wherein the advisory response engine sends the message to at least one of a care provider and the individual.

57. The system of claim 51, wherein the message includes statistics based on identifying one or more potential participants.

58. The system of claim 57, wherein the advisory response engine sends the message to an organization that is recruiting the participants for the study.

59. The system of claim 58, wherein the organization is one of a government health organization, an insurance company, and a clinical research organization.

60. The system of claim 51, wherein the request further comprises an identifier for the study.

61. A method for pseudoanonymizing patient information, comprising:

receiving data relating to a patient;

modifying the data relating to the patient;

generating a pseudo identifier;

associating the pseudo identifier with modified data;

receiving a request for the modified data, the request including the pseudo identifier; and

transmitting the modified data.

62. The method of claim 61, wherein the data related to the patient is at least one of admission to the patient and a laboratory event.

63. The method of claim 61, wherein modifying the data related to the patient comprises removing identifying information.

64. The method of claim 63, wherein the identification information includes at least one of a name, a government identifier, a date of birth, a mailing address, and a ethnicity.

65. The method of claim 64, wherein the identification information is determined by government standards.

66. The method of claim 61, wherein modifying the data related to the patient comprises replacing identification information.

67. The method of claim 61, wherein transmitting comprises transmitting the modified data to one of a government health organization, an insurance company, and a clinical research organization.

68. A system for pseudoanonymizing patient information, comprising:

a processor;

a data washing engine stored on memory and executable by the processor, the data washing engine to receive data related to a patient, to modify the data related to the patient, to associate a pseudo identifier with modified data, to receive a request for the modified data, the request including the pseudo identifier, and to transmit the modified data; and

a pseudo identifier generator engine stored on the memory and executable by the processor, the pseudo identifier generator engine to generate the pseudo identifier.

69. The system of claim 68, wherein the data related to the patient is at least one of an admission to the patient and a laboratory event.

70. The system of claim 68, wherein modifying the data related to the patient includes removing identifying information.

71. The system of claim 70, wherein the identification information includes at least one of a name, a government identifier, a date of birth, a mailing address, and a ethnicity.

72. The system of claim 71, wherein the identification information is determined based on government standards.

73. The system of claim 68, wherein modifying the data related to the patient comprises replacing identification information.

74. The system of claim 68, wherein the modified data is transmitted to one of a government health organization, an insurance company, and a clinical research organization.