US20120101849A1 - Virtual care team record for tracking patient data - Google Patents
Virtual care team record for tracking patient data Download PDFInfo
- Publication number
- US20120101849A1 US20120101849A1 US13/280,292 US201113280292A US2012101849A1 US 20120101849 A1 US20120101849 A1 US 20120101849A1 US 201113280292 A US201113280292 A US 201113280292A US 2012101849 A1 US2012101849 A1 US 2012101849A1
- Authority
- US
- United States
- Prior art keywords
- patient
- data
- server
- referral
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
Definitions
- the invention relates to managing healthcare information.
- the invention relates to a distributed system for managing healthcare information across different platforms.
- the exchange of electronic healthcare information over networks is increasing.
- the electronic healthcare information is exchanged between medical offices and other physicians, local hospitals and clinics, location and national labs and imaging centers, insurance payers, local pharmacies, public health and government agencies and patients.
- This type of collaboration requires the practice to engage in numerous healthcare transactions with many different people and organizations. These transactions include ordering and scheduling tests and obtaining results, referring and consulting on patients with other providers, obtaining authorization and filing claims with insurance payers and prescribing and refilling medications. Physicians and their staff are frequently on the phone, at the fax machine and on the Internet performing collaborative exchanges. Some of the cost associated with these exchanges would be reduced if more of the communications were performed electronically.
- EMRs electronic medical records
- the physicians typically maintain an internal system and if they do exchange information it is only with hospitals, payers, labs and pharmacies. Thus, the physicians are missing an opportunity for a larger exchange of information.
- HIES Health information exchanges
- the technology described in the invention overcomes 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 application as they see fit by configuring the settings and downloading different applications to include as part of the data manager.
- the data manager is securely connected to other collaborative partners in the community and works with local and remote computer systems.
- there are multiple data managers in the system that store different pieces of information there is no risk of a system-wide failure.
- a rendezvous engine acts as an intermediate between data servers.
- the data servers each include a data manager that comprises a controller, applications, an application manager, a virtual care team module, and a user interface engine.
- the controller manages the core functions and the transmission of data between data manager components.
- the applications are applications that are created by the user or downloaded as third-party applications.
- the application manager manages the creation and communication between applications.
- the virtual care team module manages the transmission of patient data between data servers.
- the user interface engine generates user interfaces for displaying the applications and collecting clinical trial data.
- the virtual care team module includes a creation module, a referral module, a data receiver, a data transmitter and an advertisement module.
- the creation module generates new virtual care team records.
- the referral module assigns a second identity to a patient and generates a link between a first identity and the second identity of the patient.
- the data receiver receives new data and updates the virtual care team record.
- the data transmitted transmits the updated record to the other care team members.
- the advertisement module advertises the data server.
- FIG. 1 is a high-level block diagram illustrating a system for managing data according to one embodiment of the invention.
- FIG. 2A is a block-diagram of a rendezvous engine according to one embodiment of the invention.
- FIG. 2B is a block diagram of the data manager according to one embodiment of the invention.
- FIG. 3A is a block diagram of the grid engine according to one embodiment of the invention.
- FIG. 3B is a block diagram of the application manager according to one embodiment of the invention.
- FIG. 3C is a block diagram of the virtual care team module according to one embodiment of the invention.
- FIG. 3D is a block diagram of the scrubber module according to one embodiment of the invention.
- FIG. 4A is a graphical illustration of a user interface for accessing a patient record according to one embodiment of the 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 the functionality offered by the referral application according to one embodiment of the invention.
- FIG. 4D is a graphical illustration of a different embodiment of a user interface for viewing the functionality offered by the referral application according to one embodiment of the invention.
- FIG. 4E is a graphical illustration of a user interface for viewing a timeline according to one embodiment of the 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's view of the timeline after reconciling a patient record with updates from another application according to one embodiment of the invention.
- FIG. 4H is a graphical illustration of a user interface for requesting patient information.
- FIG. 5 illustrates a flowchart of a method for generating a payload according to one embodiment of the invention.
- FIG. 6 illustrates a flowchart of a method for using a rendezvous engine to transmit data between data servers according to one embodiment of the invention.
- FIG. 7 illustrates a flowchart of a method for monitoring changes between applications according to one embodiment of the invention.
- FIG. 8A illustrates a flowchart of a method for propagating patient identifiers between multiple data servers according to one embodiment of the invention.
- FIG. 8B illustrates a flowchart of a method for updating patient information between multiple data servers according to one embodiment of the invention.
- FIG. 9 illustrates a flowchart of a method for identifying participants of a study according to one embodiment of the invention.
- FIG. 10 illustrates a flowchart of a method for generating pseudo identifiers for patients according to one embodiment of the invention.
- the present embodiment of the invention also relates 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.
- 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 memories including USB keys with non-volatile memory or any type of media suitable for storing electronic instructions, 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.
- the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
- 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.
- 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.
- I/O devices including but not limited to keyboards, displays, pointing devices, etc.
- I/O controllers 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.
- FIG. 1 illustrates a block diagram of a system 100 for managing decentralized healthcare information according to one embodiment of the invention.
- a letter after a reference number such as “ 115 a ” is a reference to the element having that particular reference number.
- a reference number in the text without a following letter, such as “ 115 ,” is a general reference to any or all instances of the element bearing that reference number.
- these entities are communicatively coupled via a network 105 .
- the illustrated description of a system 100 for managing healthcare information includes data servers 115 a , 115 b . . . 115 n that are accessed by users 125 a , 125 b . . . 125 n , practice management software (PMS) 121 , an electronic medical records (EMR) application 123 , an application server 152 and a rendezvous server 101 .
- PMS practice management software
- EMR electronic medical records
- application server 152 an application server 152
- rendezvous server 101 a rendezvous server 101 .
- the data servers 115 a , 115 b . . . 115 n in FIG. 1 are used by way of example. While FIG. 1 illustrates three data servers 115 a , 115 b . . .
- Data server 115 a is coupled to the network 105 via signal line 108 .
- a user 125 a accesses the data server 115 a via signal line 110 .
- the data server 115 a is a master data server 115 a that manages the organization of some information for the other data servers 115 n .
- Data server 115 b is coupled to the network 105 via signal line 112 .
- a user 125 b accesses the data server 115 b via signal line 120 .
- the data server 115 a is a hardware server, such as one powered by Medicity®.
- the data server 115 a comprises a data manager 103 a and a storage device 141 .
- the data manager 103 a manages healthcare information that is stored in the storage device 141 and controls how long the information persists in the storage device 141 .
- the data server 115 a is coupled to a local area network (LAN) 109 via signal line 114 .
- LAN local area network
- the data server 115 a communicates over the LAN to access the EMR application 123 via signal line 116 and to access the PMS 121 via signal line 118 .
- the EMR application 123 is software for managing electronic medical records that are kept by an enterprise, such as a physician's office.
- the PMS is software for managing the day-to-day operations of a medical practice, such as tracking patients, scheduling appointments and managing billing including entering charges for services, coding the services and submitting claims out to insurance companies.
- the EMR application 123 and PMS 121 are depicted in this illustration as being connected to the LAN 109 , the data server 115 a could communicate over the LAN to access other systems and devices.
- the data server 115 is described in greater detail below with reference to FIG. 2B .
- the system 100 illustrates a distributed computing model where each data server 115 runs a data manager 103 .
- Each data manager 103 a exchanges information with other data managers 103 n .
- a community of data managers 103 n forms a grid, which is a transmission network that supports the transportation of information.
- the data manager 103 a exchanges information with other data managers 103 n in a secure manner by limiting access to information to specific members of the system 100 .
- a user 125 a of the data manager 103 a determines which other participants on the grid the user 125 a wants to participate with, which eliminates the risk that others outside of the closed community will access the information.
- the rendezvous server 101 manages the asynchronous communication of information between data servers 115 a , 115 b . . . 115 n .
- the rendezvous server 101 accesses the network via signal line 104 .
- signal line 104 Although only one rendezvous server 101 is illustrated, persons of ordinary skill in the art will recognize that multiple rendezvous servers 101 are possible.
- the rendezvous server 101 is described in greater detail with reference to FIG. 2A .
- the application server 152 manages uploading, purchasing and downloading of applications by a user 125 a of the data manager 103 a .
- the applications are downloaded by other data managers 103 n and incorporated into the data manager 103 n .
- the applications are described in greater detail below with reference to FIG. 3B .
- the application server 152 is stored on a master data server 115 a .
- the application server 152 is coupled to the network 105 via signal line 154 .
- the application server 152 processes purchases by communicating with the rendezvous server 101 to retrieve the user's 125 n identity, billing the user 125 n for the purchase, generating receipts and performing other functions known to those of ordinary skill in the art for completing a purchase. In one embodiment, the application server 152 distributes a percentage of the purchase price to the user that developed the application and keeps the rest of the purchase price as a service charge for maintaining an application store.
- the network 105 is a conventional type, wired or wireless, and may have any number of configurations such as a star configuration, token ring configuration or other configurations known to those skilled in the art. Furthermore, the network 105 may comprise 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 includes portions of a telecommunications network for sending data in a variety of different communication protocols. In yet another embodiment, the network 105 includes Bluetooth communication networks or a cellular communications 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, etc.
- SMS short messaging service
- MMS multimedia messaging service
- HTTP hypertext transfer protocol
- the rendezvous server 101 comprises a rendezvous engine 200 , a memory 237 , a processor 235 , a communication unit 245 and a storage device for storing payload queues 210 that are each coupled to the bus 219 .
- the 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 to provide similar functionality.
- the rendezvous engine 200 comprises a grid status manager 202 , a registration engine 204 , a sorter 206 and a user interface engine 208 .
- the rendezvous engine 200 is also discussed in U.S. Pat. No.
- the processor 235 comprises an arithmetic logic unit, a microprocessor, a general purpose controller or some other processor array to perform computations and provide electronic display signals to a display device.
- the processor 235 is coupled to the bus 220 for communication with the other components via signal line 236 .
- Processor 235 processes data signals and may comprise 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.
- the processing capability may be limited to supporting the display of images and the capture and transmission of images. The processing capability might be enough to perform more complex tasks, including various types of feature extraction and sampling. It will be obvious to one 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 may be executed by processor 235 .
- the memory 237 is coupled to the bus 220 for communication with the other components via signal line 238 .
- the instructions and/or data may comprise code for performing 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.
- DRAM dynamic random access memory
- SRAM static random access memory
- flash memory or some other memory device known in the art.
- the memory 237 also includes a non-volatile memory or similar permanent storage device and media such as a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device known in the art for storing information on a more permanent basis.
- a non-volatile memory or similar permanent storage device and media such as a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device known in the art for storing information on a more permanent basis.
- the communication unit 245 transmits and receives data to and from the data servers 115 n and the application server 152 .
- the communication unit 245 is coupled to the bus 220 via signal line 246 .
- the communication unit 245 includes a port for direct physical connection to the data servers 115 n , the application server 152 or to another communication channel.
- the communication unit 245 includes a USB, SD, CAT-5 or similar port for wired communication with the user device 115 .
- the communication unit 245 includes a wireless transceiver for exchanging data with the data servers 115 n , the application server 152 or any other communication channel using one or more wireless communication methods, such as IEEE 802.11, IEEE 802.16, BLUETOOTH® or another suitable wireless communication method.
- the communication unit 245 includes a cellular communications transceiver for sending and receiving data over a cellular communications network such as via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, e-mail or another suitable type of electronic communication.
- SMS short messaging service
- MMS multimedia messaging service
- HTTP hypertext transfer protocol
- WAP direct data connection
- e-mail e-mail
- the communication unit 245 includes a wired port and a wireless transceiver.
- the communication unit 245 also provides other conventional connections to the network for distribution of files and/or media objects using standard network protocols such as TCP/IP, HTTP, HTTPS and SMTP as will be understood to those skilled in the art.
- the grid status manager 202 is software including routines for managing activity information received from the data managers 103 n .
- the grid status manager 202 is a set of instructions executable by the processor 235 to provide the functionality below for hosting a message queue for each data manager 103 n and receiving and verifying data manager session requests.
- the grid status manager 202 is stored in the memory 237 and is accessible and executable by the processor 235 . In either embodiment, the grid status manager 202 is adapted for cooperation and communication with the processor 235 and other components of the data manager 103 via signal line 222 .
- the registration engine 204 is software and routines for registering users 125 n for access to the data manager 103 n .
- the registration engine 204 is a set of instructions executable by the processor 235 to provide the functionality below for registering users.
- the registration engine 204 receives a username and password, generates a unique identifier that is associated with the data manager 103 n and receives user preferences for the user interface generated by the data manager 103 n , such as preferred screen font size, colors and how the applications are organized.
- the registration engine 204 is stored in the memory 237 and is accessible and executable by the processor 235 .
- the registration engine 204 is adapted for cooperation and communication with the processor 235 and other components of the rendezvous engine 200 via signal line 224 .
- the registration engine 204 communicates with a master data manager 103 a to coordinate registration.
- the registration engine 204 is a component of the master data manager 103 a.
- the sorter 206 is software and routines for handling payloads from data managers 103 .
- the sorter 206 is a set of instructions executable by the processor 235 to put incoming payloads into the payload queue 210 , identify the destination for each payload, place the new payloads from the payload queue 210 in the outbox for the destination data managers 103 n via the communication unit 245 and deletes payloads from the payload queue 210 after receipt of a discard request.
- the data server 115 comprises a data manager 103 , a memory 237 , a processor 235 , a communication unit 245 and a storage device 141 that are each connected to the bus 220 .
- the processor 235 , memory 237 , bus 220 and communication unit 245 are similar to the processor 235 , memory 237 , bus 219 and communication unit 245 , respectively.
- the data manager 103 comprises a controller 201 , a grid engine 203 , applications 205 , an application manager 207 , a Virtual Care Team (VCT) module 209 , a scrubber module 211 and a user interface engine 213 .
- VCT Virtual Care Team
- the controller 201 is software including routines for managing the core functions of the data manager 103 and for transmitting data to the different components.
- the controller 201 is a set of instructions executable by the processor 235 to provide the functionality below for managing data.
- the controller 201 is stored in the memory 237 and is accessible and executable by the processor 235 .
- the controller 201 is adapted for cooperation and communication with the processor 235 and other components of the data manager 103 via signal line 230 .
- the controller 201 performs core functions by listening for data by listening to ports, scanning folders, etc.; inserting data into locations such as a TCP port, folders, etc.; parsing by converting incoming data into objects, such as Java objects; analyzing by examining objects to determine actions; saving data by creating a new topic or adding to a topic that is saved in the data storage 141 ; formatting by rendering data into the required format, such as by mapping, translating and grouping; sending packages of information for distribution and notifying by, for example, sending an email or a Web alert in response to an event occurring.
- the grid engine 203 is software including routines for managing healthcare information on the data server 101 .
- the grid engine 203 is a set of instructions executable by the processor 235 to provide the functionality below for storing objects in the storage device 141 , generating and encrypting payloads, generating a queue for outbound payloads, uploading payloads to the rendezvous engine 200 , downloading payloads from the rendezvous engine 200 , generating a queue for inbound payloads, decrypting and processing received payloads, executing commands from a master data manager 103 a and performing maintenance activities.
- 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 for cooperation and communication with the processor 235 and other components of the data manager 103 via signal line 232 .
- the storage device 141 includes a node warehouse and a topic warehouse.
- the node warehouse stores identifiers for the other data managers 103 n (i.e. other nodes in the system 100 ) and information for authenticating data requests from the nodes, such as public key infrastructure (PKI) information.
- PKI public key infrastructure
- the storage device 141 is coupled to the bus 220 via signal line 248 .
- the topic warehouse stores topic objects that include topic attributes and capsules.
- the topic attributes include an identifier (e.g. a universally unique identifier (UUID) that is associated with open source software), a list of participants, a creation date, a last modified date, a description and a type. Capsules are serialized objects that are stored as name/value pairs.
- a capsule includes an identifier (e.g. HL7, original HL7, doctor, patient, audit), a description and information particular to the type of information in the capsule, such as information about a test, a department, a doctor, a topic status, a node ID, patient information and audit information.
- Capsules support many data formats including Health Level Seven (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). Persons of ordinary skill in the art will recognize that other data formats are possible.
- the grid engine 203 transmits the topics to any other data manager 103 n in the system 100 . When a data manager 103 n makes a change to a copy of the topic, the grid engine 203 transmits the copy to the other data managers 103 n to update their copy of the topic.
- HL7 Health Level Seven
- XML eXtensible Markup Language
- PDF Portable Document Format
- TIFF Tagged Image File Format
- WAVeform audio file WAV
- DICOM Digital Imaging and Communications in Medicine
- MPEG Moving Picture Experts Group
- the grid engine 203 comprises a payload generator 301 , an inbox 303 , an outbox 305 , an uploader 307 and a downloader 309 .
- the payload generator 301 performs authentication functions and generates payloads.
- the payload generator 301 generates public/private key pairs, stores the private key in the data storage 141 and transmits the public key to the other data managers 103 n that have access to the payloads.
- the payload generator 301 generates a payload that includes the topic object.
- the payload includes a class handler, a payload type, topic participants, a payload topic, a payload identifier, an original agent identifier, capsules and topics.
- the class handler is used to activate the grid engine 203 of the data manager 103 n that receives the payload.
- the payload type is a topic or capsule.
- the topic participants is a list of data managers 103 n that have access to the topic.
- the payload capsule is a list of the identifier for the capsules contained in the payload.
- the payload identifier is a unique identifier for identifying the payload, such as a UUID.
- the origin agent identifier is the unique identifier of the data manager 103 that created the original payload.
- the payload generator 301 creates the payload, the payload generator 301 generates a payload header that includes the identifier for the recipient data manager 103 n and encrypts the payload with a public key of the recipient data manager 103 n .
- the payload generator 301 encrypts the payload by encrypting the topic attributes and the capsules with a 2048-bit Advanced Encryption Standard (AES) symmetric key, incorporates a digital signature of the data manager 103 that creates the payload with a Hash-based Message Authentication Code (HMAC), and the payload is encrypted using a HyperText Transfer Protocol Secure (HTTPS).
- AES Advanced Encryption Standard
- HMAC Hash-based Message Authentication Code
- the outbox 305 maintains an outbox queue.
- the outbox 305 stores the payload created by the payload generator 301 in an outbox queue, periodically contacts the rendezvous engine 200 , establishes a secure sockets layer (SSL), uploads the content of the message outbox queue and sends discard requests to the rendezvous engine 200 via the communication unit 245 .
- the rendezvous engine 200 places the payload in the outbox for the destination data manager 103 n .
- the designation data manager 103 n downloads the payload, decrypts the AES key with its private key and uses the AES key to decrypt the payload.
- the inbox 303 maintains a message inbox queue by downloading any new messages from the rendezvous engine 200 via the communication unit 245 and puts the new messages in the message inbox queue.
- the applications 205 are software including routines for performing tasks.
- the applications 205 are a set of instructions executable by the processor 235 for performing tasks.
- the applications 205 are stored in memory 237 of the data server 115 and are accessible and executable by the processor 235 .
- the applications 205 are adapted for cooperation and communication 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 the signal line 226 .
- the applications 205 include any type of applications such as an enterprise application, an accounting application, a word processing application, a media application, etc.
- the applications are for performing tasks such as retrieving health care data of a patient, processing payments received from an insurance provider, authorizing payments, ordering labs, dictation software, maintaining a healthcare registry (e.g. bone marrow), receiving health check-up results of a patient from a lab, sending prescriptions to a drugstore, etc.
- the applications 205 are developed by a user 125 .
- the applications 205 are third-party applications that are downloaded from an application server 152 and installed on the data server 115 .
- the application server 152 for example, includes an application store that allows users to search, browse, purchase and download third-party applications.
- the application manager 207 is software including routines for developing and managing the applications 205 .
- the application manager 207 is a set of instructions executable by the processor 235 to provide the functionality described below for developing and managing the applications 205 .
- the application manager 207 is stored in memory 237 of the data server 115 and is accessible and executable by the processor 235 .
- the application manager 207 is adapted for cooperation and communication with the processor 235 , the storage device 141 , the controller 201 , the applications 205 , the user interface engine 213 and other components of the data server 115 via the signal line 239 .
- the application manager 207 is described in further detail with reference to FIG. 3B .
- FIG. 3B illustrates one embodiment of the application manager 207 in more detail.
- the application manager 207 includes an application module 302 , a certification module 304 , a collaboration module 306 , a contextual module 308 , a bridge module 310 .
- the application module 302 is software including routines for allowing users 125 to develop and install applications 205 on the data server 115 .
- the application module 302 receives a request submitted by the user 125 to develop a new application, install a third-party application, etc. from the controller 201 .
- the application module 302 includes a software development kit (SDK) comprising a set of development tools that allow users 125 to develop applications 205 .
- SDK software development kit
- the application module 302 allows users 125 to download and install third-party applications 205 from an application server 152 .
- the application module 302 allows the users 125 to define preferences and rules for the applications 205 .
- the application module 302 stores the rules and preferences in the storage device 141 .
- the application module 302 includes tools to develop application programming interfaces (APIs) to allow the data manager 103 to interact with third-party applications stored in the application server 152 or any other data servers 115 n .
- the application module 302 uses Java adapters to provide software developers with the tools for accessing different information platforms, such as the data servers 115 n and local, state and national registries.
- the application module 302 transmits 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 platforms include a journal API for creating, updating and accessing data in personal journals; a messaging API for accessing the secure messaging infrastructure to exchange information with other platforms; a physician directory API for accessing a global directory of physicians and other provides that are on the grid; a print service for accessing local printers; an International Classification of Disease (ICD) lookup for accessing ICD-9 diagnosis tables; a Current Procedural Terminology (CPT) lookup for accessing CPT procedural tables; a Practice Management (PM) bridge for accessing data from the MPS bridge for demographic, insurance and scheduling queries; an Electronic Medical Records driver for accessing clinical data and other data queries and enabling the insertion of results, reports, referrals and other information; a vocabulary mapping service for translating local terms to standardized terms (e.g.
- SNOMED Systemized Nomenclature of MEDicine
- HIE Health Information Exchange
- the journal API is used to create a patient record.
- the journal API includes demographic information including name, date of birth and address for a patient; scheduling information including appointment type, date and time; clinical problems that are both current and historical for the patient; procedures or treatments for the patient; family history; social history that includes lifestyle, occupation, environmental health risks and patient demographics such as marital status, ethnicity and religion; advanced directives including wills, healthcare proxies and resuscitation wishes including both patient instructions and references to external documents; alerts such as allergies and adverse reactions; medications including current medications and relevant historical medication usage; immunizations including immunization status and historical information about past immunizations; medical equipment and any implanted or external devices; vital signs including trends over time and baselines; functional status including information about what is normal for the patient, deviations from normalcy (both positive and negative) and extensive examples; results including lab and procedure results and reports; encounters including past healthcare encounters including activity and location; and a plan of care including active, incomplete or pending activities for the patient including orders, appointments, procedures,
- the certification module 304 is software including routines for certifying the applications 205 developed by the users 125 .
- the certification module 304 receives a message from the application module 302 that a new application has been developed by a user 125 .
- the certification module 302 determines whether the new application is compatible with the applications 205 that are installed on the data server 115 .
- the certification module 304 determines whether the new application includes APIs to interact with the applications 205 .
- the certification module 304 certifies that the new application can be uploaded to an application server 152 .
- the certification module 304 instructs the user interface engine 213 to generate a user interface that displays a message.
- the message indicates that the new application is certified to be installed on the data server 115 , uploaded to the application server 152 , etc. In another embodiment, the message indicates that the new application is not certified and includes a list of issues that need to be resolved for the new application to be certified.
- the collaboration module 306 is software including routines for generating a list of data servers 115 n that communicate with the data server 115 a .
- 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 a user 125 to develop a new application.
- the user 125 uses the list to develop APIs for the new application.
- the contextual module 308 is software including routines for managing the interactions between the applications 205 .
- the contextual module 308 receives a message from an application 205 when the application 205 performs a task.
- the contextual module 308 analyzes the task, for example, analyzes a request submitted by the user 125 , the retrieved health care data of a patient, etc.
- the contextual module 308 determines if the analysis matches one or more rules or preferences that are defined for any other application installed on the data server 115 .
- the contextual module 308 transmits a notification to the application.
- the contextual module 308 is described in further detail with reference to FIG. 7 .
- the bridge module 310 is software including routines for managing the exchange of data between the applications 205 and the computing systems, for example, PMS 121 , the EMR application 123 , diagnostic devices (not shown), etc. that are locally connected to a data server 115 .
- the bridge module 310 communicates data such as, queries, instructions, messages, health care data of a patient, etc. between the applications 205 and the local computing systems.
- the bridge module 310 converts the data into a format that is compatible with the requirements of the destination. For example, an 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 into a HL7 standard and submits the query to the EMR 123 .
- the bridge module 310 receives the list of patients from the EMR 123 , converts the list into a PDF as requested by the application 205 and transmits it to the application 310 .
- the bridge module 310 converts the data to HL7 standards, Continuity of Care Document (CCD), Continuity of Care Record (CCR), Structured Query Language (SQL), PDF or any other format or standard known to a person of ordinary skill in the art.
- CCD Continuity of Care Document
- CCR Continuity of Care Record
- SQL Structured Query Language
- VCT Virtual Care Team
- the Virtual Care Team (VCT) module 209 is software including routines for creating VCT records that are related to a specific patient and for collaborating with other data servers 115 n .
- 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 .
- the VCT module 209 is stored in memory 237 of the data server 115 and is accessible and executable by the processor 235 .
- the VCT module 209 is adapted for cooperation and communication 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 line 240 .
- a VCT record comprises health care data associated with a patient or a group of patients (for example, a family, colleagues, etc.).
- the health care data includes a patient identity (ID), demographic information, information related to a care team of the patient, insurance information, prescriptions, results, allergies, medical history, referrals, rules, preferences, etc.
- a care team of a patient is a group of data servers 115 n (for example, a primary physician, a cardiologist, an insurance provider, etc.) that are associated with the health care of the patient.
- the VCT module 209 is described in further detail with reference to FIG. 3C .
- FIG. 3C illustrates one embodiment of the VCT module 209 in more detail.
- 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 including routines for creating VCT records.
- the creation module 352 receives a request submitted by a user 125 for creating a VCT record (for example, a request submitted by a hospital administrator to create a VCT record for a new patient) from the controller 201 .
- the creation module 352 generates a VCT record based on the information (for example, a registration form filled out by the patient, etc.) included in the request.
- the creation module 352 retrieves additional information about the patient from local databases such as the PMS 121 , the EMR application 123 , etc.
- the creation module 352 instructs the user interface engine 213 to generate a user interface requesting additional information from the user 125 .
- the creation module 352 stores the VCT records in the storage device 141 .
- the creation module 352 generates a VCT record that is helpful for both transmitting information to other data servers 115 n and for transmitting a complete record to an application outside of the system 100 .
- the referral module 354 is software including routines for transmitting and receiving referrals for a patient to and from other data servers 115 n .
- the referral module 354 identifies one or more data servers 115 n for a patient from a directory of data servers in the storage device 141 .
- the referral module 354 identifies a data server 115 b responsive to receiving a request submitted by a user 125 a from the controller 201 .
- the request for example, is submitted by a primary care physician to identify a cardiologist for the patient.
- the referral module 354 automatically identifies a data server 115 b based on a patient's VCT record.
- the referral module 354 determines that a patient does not have insurance coverage from the patient's VCT record. The referral module 354 then identifies an insurance provider for the patient. In yet another embodiment, the referral module 354 identifies a data server 115 b for a patient responsive to receiving an instruction from an application 205 . The referral module 354 identifies the data servers 115 n for a patient corresponding to the information in the patient's VCT record. For example, the referral module 354 identifies a clinic located within five miles of the patient's house, a neurologist covered by the patient's insurance provider, etc.
- the referral module 354 instructs the controller 201 to transmit a referral to the data server 115 b .
- the instruction includes a copy of the patient's VCT record and information such as an identification of the data server 115 b , methods to communicate with the data server 115 b , etc.
- the referral module 354 updates the VCT record of the patient by adding the data server 115 b to the care team of the patient. In one embodiment, the referral module 354 updates the VCT record of the patient in response to receiving an acknowledgment from the data server 115 b.
- the referral module 354 also receives referrals transmitted by other data servers 115 n from the controller 201 .
- the referral module 354 retrieves the copy of the patient's VCT record from the referral and assigns a patient ID that is 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 the 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 transmit the link to the data servers 115 n from which the referral was received.
- the referral module 354 is described in further detail with reference to FIG. 8A .
- the data receiver 356 is software including routines for receiving new health care data associated with a patient from the controller 201 .
- the data receiver 356 receives new health care data submitted by a user 125 .
- the data receiver 356 receives the blood pressure level of a patient submitted by a nurse.
- the data receiver 356 receives health care data from a computing system that is locally connected to the data server 115 a .
- the data receiver 356 receives scan images of a patient's shoulder from an MRI scanner that is connected to the data server 115 a .
- the data receiver 356 receives new health care data transmitted by other care team members of the patient, for example, prescriptions, updated insurance coverage plan, etc.
- the data receiver 356 determines whether the new health care data is required by the data server 115 a based on rules and preferences stored in the storage 141 . For example, a cardiologist requires blood test results of a patient but not a physical therapist. In one embodiment, the data receiver 356 instructs the user interface engine 213 to generate a user interface that displays the new health care data. In this embodiment, a user 125 , (for example, a physician, a nurse, etc.) selects the new health care data required for the data server 115 a . The data receiver 356 retrieves the VCT record of the patient and updates it with the new health care data.
- the data receiver 356 performs reconciliation of new data that includes conflicting information.
- 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 might match the demographic information, for example, the data receiver 356 identifies patients that match the demographic information if the numbers in the data of birth are transposed or the name “Jon” is replaced with “John.”
- the data receiver 356 saves the rule for correcting the conflicting information in the storage device 141 .
- the data receiver 356 transmits the corrected data to the care team member that submitted the conflicting information via the communication unit 245 for confirmation. If the same conflicting information is received in the future, the data receiver 356 corrects the information using the same rule.
- the data transmitter 358 is software including routines for transmitting health care data associated with a patient to the patient's care team members via the communication unit 245 .
- the data transmitter 358 receives new health care data associated with a patient from the data receiver 356 .
- the data transmitter 358 identifies the patient's care team members from the VCT record.
- the data transmitter 358 then instructs the communication unit 245 to transmit the new health care data to the patient's care team members.
- the data transmitter 358 formats the new health care data based on the preferences of each of the care team members.
- the data transmitter 358 determines whether the new health care data can be transmitted to the care team members based on the rules (for example, care team member preferences, patient's privacy rules, HIPAA compliance, etc.) present in the patient's VCT record.
- the advertisement module 360 is software including routines for advertising a data server 115 a .
- the advertising module 360 generates advertisements that include a unique identifier associated with the data server 115 a , such as a UUID and instructs the controller 201 to transmit them to other data servers 115 n .
- the advertisement includes the information about the data server 115 a such as, health care services provided by the data server 115 a , a list of physicians, a list of insurance plans that cover the services provided by the data server 115 a , location, etc.
- the advertisements are advantageous as, for example, the other data servers 115 n transmit referrals to the data server 115 a based on these advertisements.
- the scrubber module 211 is software including routines for identifying individuals for a study, such as a clinical trial and for scrubbing patient data of identifying information.
- the scrubber module 211 is a set of instructions executable by the processor 235 to provide the functionality described below for scrubbing identifying information in response to a request from an application 205 .
- the scrubber module 211 is stored in memory 237 of the data server 115 and is accessible and executable by the processor 235 .
- the scrubber module 211 is adapted for cooperation and communication with the processor 235 , the storage device 141 , the controller 201 , the applications 205 , the user interface engine 213 and other components of the data server 115 via the signal line 242 .
- the scrubber module 211 is described in further detail with reference to FIG. 3D .
- FIG. 3D is a block diagram of the scrubber module 211 that includes an advertisement listing engine 372 , a participant identifying engine 374 , a data scrubbing engine 376 , a pseudo identifier generator engine 378 and an advertisement response engine 380 that are each coupled to signal line 242 .
- the advertisement listing engine 372 registers an advertisement for recruiting potential participants for a study.
- the advertisement listing engine 372 receives a request for potential participants for a study from an organization.
- the organization is any group that uses medical information, such as a government health organization (e.g. the CDC), an insurance company and a clinical research organization (e.g. a hospital).
- the request includes an identifier such as a name for the study and patient factors for identifying potential participants for the study.
- a clinical research organization uses the scrubber module 211 to identify a number of individuals that are available for a study to test a medication for a health condition where the patients are in a particular age group and have responded adversely to a different medication.
- the clinical research organization places an advertisement that includes input data for identifying the participants.
- the input data relates to a diagnosis, medication, lab results, gender, age, location, previous medical history such as previous illnesses, a history of illnesses and other factors that are relevant to the study.
- the advertisement listing engine 372 transmits the request to the participant identifying engine 374 for an immediate identification of potential participants for the study.
- the participant identifying engine 374 stores the request in the storage device 141 for identification of potential participants for the study at a later time
- the participant identifying engine 374 identifies potential participants for a study based on the advertisement from an organization that is received from the advertisement listing engine 372 .
- the participant identifying engine 374 identifies individuals based on matching the input data with patient data and medical records.
- information for the identified individuals is transmitted to the data scrubbing engine 376 .
- the number of identified individuals that match is transmitted to the advertisement response engine 380 .
- the data scrubbing engine 376 modifies patient data to scrub it of identifying aspects.
- the data scrubbing engine 376 receives a request from an application 205 to scrub patient data.
- the patient data includes data related to an admission of a patient or a lab event.
- the data scrubbing engine 376 receives the individuals that match the advertisement from the participant identifying engine 374 .
- the data scrubbing engine 376 receives patient data from a master patient index that is part of the data storage 141 or stored in another location, such as part of the EMR application 123 .
- the data scrubbing engine 376 modifies identifying information by removing demographic data.
- Identifiable demographic data includes name, address, birth date, ethnicity, government issued numbers such as a social security number and operational patient numbers such as a patient identifier.
- the data scrubbing engine 376 modifies patient data by replacing the identifiable demographic data. For example, the data scrubbing engine 376 replaces the birth date with the age of the individual or transposes the digits for the birth date.
- the data scrubbing engine 376 requests a pseudo identifier from the pseudo identifier generator engine 378 .
- the pseudo identifier generator engine 378 generates a pseudo identifier for a patient.
- the data scrubbing 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 .
- the data scrubbing engine 376 associates the pseudo identifier with the patient by storing the pseudo identifier with patient data in the master patient index.
- the data scrubbing engine 376 transmits the pseudo identifier and other data to the application 205 that requested the scrubbing or to the advertisement response engine 380 . Therefore, the pseudo identifier is used by an organization to retrieve medicals records of person without revealing the identity of the person. Also, because the pseudo identifier is a static identifier that is consistently associated with the same patient, the organization that requests the pseudo identifier tracks the same person over time. For example, a clinical research company uses the scrubber module 211 for a study for the same person over a period of 5 years.
- the advertisement response engine 380 responds to an advertisement for recruiting potential participants for a study.
- the advertisement response engine 378 receives a number of patients that match the input data from the participant identifying engine 374 or scrubbed information from the pseudo identifier generator 378 .
- the advertisement response engine 380 notifies a provider of care that the individuals are identified as potential participants for the study.
- the advertisement response engine 380 sends basic statistics to the organization that requested the potential participants. For example, the advertisement response engine 380 informs the organization that a specific number of potential participants have been identified by the participant identifying engine 372 .
- the user interface engine 213 is software including routines for generating a user interface in response to instructions received from the other data manager 103 components.
- 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 applications 205 , the VCT module 209 or the scrubber module 211 .
- the user interface engine 213 is stored in memory 237 of the data server 115 and is accessible and executable by the processor 235 .
- the scrubber module 211 is adapted for cooperation and communication with the processor 235 , the storage device 141 , the applications 205 , the user interface engine 213 and other components of the data server 115 via the signal line 242 .
- the user interface engine 213 is described in further detail with reference to FIGS. 4A-4H .
- FIG. 4A is a graphic representation of a user interface 401 that is generated by the user interface engine 213 for accessing at least one patient record.
- the user interface 401 displays a homepage 402 of a medical office website for healthcare providers of that medical office.
- the homepage 402 includes icons 404 of underlying composite applications that are installed by a user to meet his or her unique needs.
- a user searches for a patient record by typing a first name of the patient, a last name of the patient or any combination thereof in the search box and hitting the search button 406 on the homepage 402 . For example, typing “Angela” in the search box retrieves a list 412 of patients whose first name includes Angela.
- the homepage 402 includes a List All 408 button that, when selected displays the entire list of available patient records and a Create Record 410 button that, when selected, displays a user interface for creating a record for a new patient.
- FIG. 4B is a graphic representation 403 of a user's view of an application store that is hosted by the application server 152 .
- the application store includes a categories icon 422 by which the user can view and select the type of applications to install.
- the application store lists the applications belonging to a particular type under sections such as popular applications, suggested applications, installed applications, updates to installed applications and new applications.
- the user selects the all icon 424 and selects the “what's new” tab 426 .
- a sub-section 428 opens up that lists all the applications under the “what's new” tab 426 and the user chooses to buy the Timeline Application 430 .
- at least one of the applications listed is free to be installed by the user.
- the applications listed in the application store are developed by third-party vendors.
- FIG. 4C is a graphic representation 405 of a user's view of the functionality offered by the referrals application 430 including sending and receiving of patient referrals.
- the referrals application 430 displays a worklist 432 comprising the patient referrals 438 that were sent by the user in response to the user selecting the sent referrals 436 option.
- the options present in the header 434 includes a drop down box to illustrate different categories in order to narrow down the referrals the user is interested in. For example, under the sent referrals 436 option, the user can choose to view referrals that are completed, in progress, denied and not yet accepted ones separately if interested.
- Each patient referral 438 comprises the patient name, status of the referral, the department or institution the referral is sent to and date and time of the referral, update and schedule.
- the user interface engine 213 allows the user to configure the display of the referral information 438 and other features of the display.
- FIG. 4D is another graphic representation 407 of a user's view of the functionality offered by the referrals application 430 in response to clicking on a patient referral 438 in FIG. 4C .
- the list of underlying composite applications displayed near the top of the webpage change in their appearance visually at least in part to reflect the medical record of the patient 440 associated with the patient referral 438 from FIG. 4C .
- the referral application 430 includes the accompanying referral information 442 which lists the referring provider, referral details, scheduling information and any messages exchanged between the referring provider and the referred provider pertaining to the patient treatment.
- FIG. 4E is a graphic representation 409 of a user's view of the functionality offered by the patient care timeline app 452 .
- Graphic representation 409 displays a sliding list 454 of encounters with the patient 440 including routine visits, lab tests and checkups from at least one medical institution.
- the patient care timeline application 452 Upon selecting one such encounter 456 , the patient care timeline application 452 displays a sub section 458 listing the details of that particular encounter.
- the sub section 458 includes the physician's name, visit type, complaint, personal and medical information of the patient 440 .
- Each information tab 460 associated with the patient 440 in response to clicking on it, expands to let the user view the information in detail and edit the information if needed.
- the patient care timeline app 452 indicates visually to the user that at least one of the other underlying applications has important patient information which is pertinent to the patient care timeline application 452 .
- a highlighted exclamation mark on the patient care timeline application 452 in response to a highlighted numeral three on the virtual care team application is an indication that the two applications are ready to communicate with each other to reconcile patient record.
- FIG. 4F is a graphic representation 411 of a user's view of reconciliatory updates procured by the virtual care team application 462 in order to reconcile patient records.
- the virtual care team application 462 displays an update tab 464 associated with different departments and/or institutions.
- the virtual care team application 462 displays a visible numeral indicating the number of updates to be reconciled.
- the virtual care team app 462 displays the number three.
- the update tab 464 associated with a department and/or institution comprises the day, the date, the time and the time zone for each individual update 466 received.
- each update 466 needs to be authorized by the user to be reconciled by selecting the check box beside the update 466 .
- all the updates are reconciled at once without checking every individual update 466 by checking the reconcile icon underneath the “Mark updates as reconciled?” text 468 .
- FIG. 4G is another graphic representation 413 of a user's view of the patient care timeline application 452 after reconciling a patient record with updates from the virtual care team application 462 .
- the user interface engine 213 changes the patient care timeline application 452 appearance at least in part in response to the updates being reconciled in the virtual care team application 462 in FIG. 4F .
- the patient care timeline application 452 displays the encounter that received the updates and the fields in the encounter that were updated by highlighting them to the user for at least a period of time.
- the cardiac stress test encounter 472 is highlighted and accompanying payers information tab 474 , problems information tab 476 and medications information tab 478 after the user clicks on the patient care timeline 452 .
- FIG. 4H one embodiment of a user interface 481 generated by the user interface engine 213 for generating a request or advertisement for recruiting potential participants for a study is illustrated.
- the user interface 481 displays a plurality of inputs for generating a request.
- the plurality of inputs includes an input 483 for identifying or labeling the study.
- the user interface 481 displays input area 485 for capturing medical related criteria for creating input data that is used to identify patients for the study.
- input area 485 comprises diagnosis information, allergy information, medication information, and lab result information.
- User interface 481 displays a gender input 487 for 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.
- a user submits the request or advertisement by pressing the submit button 491 .
- Persons of ordinary skill in the art will recognize that other variables can also be displayed for generating the request, such as a text box for specifying a location, previous illnesses, family history of illnesses, etc.
- the advertisement listing engine 372 receives the request and registers the request for identifying potential participants for the study.
- FIGS. 5-10 various example embodiments of the invention will be described.
- FIG. 5 is a flow diagram 500 illustrating one embodiment for generating a payload.
- a first data manager 103 a includes a grid engine 203 that generates 502 public/private key pairs and transmits 504 the public key to all authorized data managers 103 n .
- the public/private key pairs are generated with a 2048-bit RSA PKI.
- the grid engine 203 generates 506 a payload for a topic object, the topic object including topic attributes and a plurality of capsules.
- the grid engine 203 encrypts 508 the payload.
- the grid engine 203 uses an AES symmetric key to encrypt the topic object.
- the grid engine 203 via the communication unit 245 uploads 510 the payload to an inbox for the rendezvous engine 200 .
- FIG. 6 is a flow diagram 600 illustrating one embodiment for using a rendezvous engine 200 to transmit data between data managers 103 n .
- the rendezvous engine 200 includes a sorter 206 that receives 602 a payload from a first data manager via the communication unit.
- the sorter 206 sorts 604 the payload into a payload queue 210 .
- the sorter 206 identifies 606 the destination for the payload as a second data manager 103 b .
- the sorter 206 places 608 the payload in an outbox for the second data manager 103 b .
- the second data manager 103 b downloads 610 the payload and decrypts 612 the payload.
- FIG. 7 is a flow diagram 700 illustrating one embodiment for transmitting a notification to an application based on a task performed by another application.
- the controller 201 receives 702 a request submitted by a user 125 for retrieving patient data using a retrieval application.
- the retrieval application retrieves 704 the patient data.
- the retrieval application retrieves a virtual care team (VCT) record of a patient from the data storage 141 .
- VCT virtual care team
- the user interface engine 213 generates 706 a user interface displaying the patient data.
- the application manager 207 includes a contextual module 308 that determines 708 whether the patient data matches a rule of a health monitor application.
- the contextual module 308 transmits 710 a notification to the health monitor application in response to determining that the patient data matches the rule.
- the contextual module 308 determines from the patient's VCT record that the patient's cholesterol level is higher than a threshold and transmits a notification to the health monitor application.
- the health monitor application instructs the user interface engine 213 to generate a user interface.
- the user interface engine 213 generates 714 a user interface displaying a message.
- the user interface displays a warning message that the patient's cholesterol level is too high.
- FIG. 8A is a flow diagram 800 illustrating one embodiment for transmitting referrals.
- a VCT module 209 includes a creation module 352 that (for example, a primary care physician) assigns 802 a first patient identifier (ID) for a new patient.
- the creation module 352 creates 804 a VCT record for the patient.
- the primary care physician 115 a diagnoses that the patient requires surgery on his knee and submits a request.
- the referral module 354 identifies a data server 115 b (for example, an orthopedic surgeon) from the storage device 141 .
- the controller 201 transmits 806 a referral to the data server 115 b via the communication unit 245 .
- the referral comprises a copy of the patient's VCT record that includes the first patient ID.
- the referral module 354 also updates 808 the VCT record to include the data server 115 b as a member of the care team of the patient.
- the referral module 354 of the data server 115 b assigns 810 a second patient ID for the referral based on the format requirements and the rules of the data server 115 b .
- 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 115 b then transmits 814 the first link to the data server 115 a .
- the referral module 354 of the data server 115 a updates 816 the VCT record to include the first link.
- the referral module 354 of the data server 115 b then identifies a data server 115 n (for example, a physical therapist) for the patient.
- the controller 201 of the data server 115 b transmits 818 a referral to the third data server 115 n .
- This referral comprises a copy of the patient's VCT record that includes the second patient ID and the first link.
- the referral module 354 of the data server 115 b updates 820 the VCT record to include the data server 115 n as a member of the care team of the patient.
- the referral module 354 of the data server 115 n assigns 822 a third patient ID for the referral.
- the referral module 354 of the data server 115 n 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 115 n then transmits 826 the second link to the data server 115 b .
- the referral module 354 of the second data server 115 b updates 830 the patient's VCT record to include the second link.
- the controller 201 of the data server 115 n also transmits 828 the second link to the data server 115 a .
- the referral module 354 of the data server 115 a updates 832 the patient's VCT record to include the second link and the data server 115 n as a member of the patient's care team.
- the links are advantageous in scenarios, for example, when the data server 115 a receives health care information from the data server 115 b that is represented by the second patient ID.
- the data server 115 a easily identifies and retrieves the VCT record of the patient based on the first link.
- the second link allows exchange of health care information associated with the patient between the data servers 115 a , 115 b , 115 n.
- FIG. 8B is a flow diagram 850 illustrating one embodiment for exchanging information between care team members of a patient.
- the data receiver 356 of the data server 115 a receives 852 new information associated with a patient.
- the data receiver 356 updates 854 the VCT record of the patient with the new information.
- the data transmitter 358 of the data server 115 a determines 856 whether the new information should be transmitted to other care team members of the patient.
- the data transmitter 358 transmits 858 the new information to the data server 115 b .
- the data transmitter 358 also transmits 860 the new information to the data server 115 n .
- the data receiver 356 of the data server 115 b determines 862 whether the new information is required.
- the data receiver 356 updates 864 the VCT record of the patient in response to determining that the new information is required.
- the data receiver 356 of the data server 115 n determines 866 whether the new information is required for the data server 115 n .
- the data receiver 356 rejects 868 the new information in response to determining that the new information is not required for the data server 115 n.
- FIG. 9 is a flow diagram 900 of one embodiment of a method for recruiting participants for a study.
- the advertisement listing engine 374 receives 902 a request for potential participants for a study including input data for identifying the potential participants.
- the input data includes information relating to a diagnosis, medication, lab results, gender, age, location, etc.
- the advertisement listing engine 374 stores 906 the request and input data in the storage device 141 .
- the participant identifying engine 372 receives 906 patient information or an update of patient information.
- the participant identifying engine 372 identifies 908 a potential participant based on the input data and the patient information.
- the advertisement response engine 378 generates 910 a report or message based on identifying the potential participant.
- the advertisement engine 378 generates a message that an individual is a match for the study. In the embodiment, the message is sent to a provider of care or the individual. In another embodiment, the advertisement response engine 378 generates a message that includes statistics based on identifying one or more potential participants. In the embodiment, the advertisement response engine 378 sends the message to a clinical research organization that is recruiting participants for the study.
- FIG. 10 is a flow diagram 1000 of one embodiment of a method for pseudoanonymising patient information.
- the data scrubbing engine 376 receives 1002 data related to a patient. In one embodiment, the data is related to an admission of a patient or a lab event.
- the data scrubbing engine 376 modifies 1004 the data by removing demographic information. In one embodiment, the data scrubbing engine 376 removes any key information for identifying an individual. For example, key information includes name, social security number or other government identifiers, birth date, mail address or race. In another embodiment, the data scrubbing engine 376 modifies the data by replacing demographic data that leads to identification of an individual. In one embodiment, the key information is determined by government standards for the purpose of protecting the identity of individuals.
- the pseudo identifier generator 378 generates 1006 a pseudo identifier for the modified data related to the patient.
- the data scrubbing engine 376 associates 1008 the pseudo identifier with the modified data related to the patient.
- the data scrubbing engine 376 stores 1010 the pseudo identifier and the modified data in the storage device 141 .
- the data scrubbing engine 376 receives 1012 a request for the modified data including the pseudo identifier.
- the data scrubbing engine 376 retrieves the modified data based on the pseudo identifier and transmits 1014 the modified data to the requestor via the communication unit 245 .
- modules, routines, features, attributes, methodologies and other aspects of the disclosure can be implemented as software, hardware, firmware or any combination of the three.
- a component an example of which is a module, of the invention is implemented as software
- the component can 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 every and any other way known now or in the future to those of ordinary skill in the art of computer programming.
- the 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.
Abstract
A system and method for managing healthcare information is disclosed. The data servers each include a data manager that comprises a controller, applications, an application manager, a virtual care team module, and a user interface engine. The controller manages the core functions and the transmission of data between data manager components. The applications are applications that are created by the user or downloaded as third-party applications. The application manager manages the creation and communication between applications. The virtual care team module manages the transmission of patient data between data servers. The user interface engine generates user interfaces for displaying the applications and collecting clinical trial data.
Description
- This application claims priority under 35 USC §119(e) to U.S. provisional patent Application Ser. No. 61/406,003, entitled “System and Method for Managing Healthcare Information,” filed Oct. 22, 2010.
- 1. Field of the Invention
- The invention relates to managing healthcare information. In particular, the invention relates to a distributed system for managing healthcare information across different platforms.
- 2. Description of the Related Art
- The exchange of electronic healthcare information over networks is increasing. The electronic healthcare information is exchanged between medical offices and other physicians, local hospitals and clinics, location and national labs and imaging centers, insurance payers, local pharmacies, public health and government agencies and patients. This type of collaboration requires the practice to engage in numerous healthcare transactions with many different people and organizations. These transactions include ordering and scheduling tests and obtaining results, referring and consulting on patients with other providers, obtaining authorization and filing claims with insurance payers and prescribing and refilling medications. Physicians and their staff are frequently on the phone, at the fax machine and on the Internet performing collaborative exchanges. Some of the cost associated with these exchanges would be reduced if more of the communications were performed electronically.
- Previous attempts to overcome these problems suffer from deficiencies. For example, some physicians have created electronic medical records (EMRs), however, the physicians typically maintain an internal system and if they do exchange information it is only with hospitals, payers, labs and pharmacies. Thus, the physicians are missing an opportunity for a larger exchange of information.
- Health information exchanges (HIES) are appearing in many communities, however, they lack widespread acceptance and their focus is on creating comprehensive, patient-centric records and not on enhancing clinical workflow for physician practices.
- Other solutions suffer from deficiencies that prevent them from being adopted by physicians. For example, most software is insufficient or too immature to meet the broad range of collaborative needs of a physician practice. In addition, the costs of adopting the technology, both for the licensing and the expense of re-engineering the practice, are often considered too great. Lastly, the existing systems fail to match the established workflow that the physicians and staff are accustomed to performing. As a result, the existing system must be restructured, which requires manual intervention by the staff to complete the process.
- The technology described in the invention overcomes 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 application as they see fit by configuring the settings and downloading different applications to include as part of the data manager. The data manager is securely connected to other collaborative partners in the community and works with local and remote computer systems. In addition, because there are multiple data managers in the system that store different pieces of information, there is no risk of a system-wide failure.
- In one embodiment, a rendezvous engine acts as an intermediate between data servers. The data servers each include a data manager that comprises a controller, applications, an application manager, a virtual care team module, and a user interface engine. The controller manages the core functions and the transmission of data between data manager components. The applications are applications that are created by the user or downloaded as third-party applications. The application manager manages the creation and communication between applications. The virtual care team module manages the transmission of patient data between data servers. The user interface engine generates user interfaces for displaying the applications and collecting clinical trial data.
- In one embodiment, the virtual care team module includes a creation module, a referral module, a data receiver, a data transmitter and an advertisement module. The creation module generates new virtual care team records. The referral module assigns a second identity to a patient and generates a link between a first identity and the second identity of the patient. The data receiver receives new data and updates the virtual care team record. The data transmitted transmits the updated record to the other care team members. The advertisement module advertises the data server.
- The 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 are used to refer to similar elements.
-
FIG. 1 is a high-level block diagram illustrating a system for managing data according to one embodiment of the invention. -
FIG. 2A is a block-diagram of a rendezvous engine according to one embodiment of the invention. -
FIG. 2B is a block diagram of the data manager according to one embodiment of the invention. -
FIG. 3A is a block diagram of the grid engine according to one embodiment of the invention. -
FIG. 3B is a block diagram of the application manager according to one embodiment of the invention. -
FIG. 3C is a block diagram of the virtual care team module according to one embodiment of the invention. -
FIG. 3D is a block diagram of the scrubber module according to one embodiment of the invention. -
FIG. 4A is a graphical illustration of a user interface for accessing a patient record according to one embodiment of the 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 the functionality offered by the referral application according to one embodiment of the invention. -
FIG. 4D is a graphical illustration of a different embodiment of a user interface for viewing the functionality offered by the referral application according to one embodiment of the invention. -
FIG. 4E is a graphical illustration of a user interface for viewing a timeline according to one embodiment of the 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's view of the timeline after reconciling a patient record with updates from another application according to one embodiment of the invention. -
FIG. 4H is a graphical illustration of a user interface for requesting patient information. -
FIG. 5 illustrates a flowchart of a method for generating a payload according to one embodiment of the invention. -
FIG. 6 illustrates a flowchart of a method for using a rendezvous engine to transmit data between data servers according to one embodiment of the invention. -
FIG. 7 illustrates a flowchart of a method for monitoring changes between applications according to one embodiment of the invention. -
FIG. 8A illustrates a flowchart of a method for propagating patient identifiers between multiple data servers according to one embodiment of the invention. -
FIG. 8B illustrates a flowchart of a method for updating patient information between multiple data servers according to one embodiment of the invention. -
FIG. 9 illustrates a flowchart of a method for identifying participants of a study according to one embodiment of the invention. -
FIG. 10 illustrates a flowchart of a method for generating pseudo identifiers for patients according to one embodiment of the invention. - A system and method for managing healthcare information are 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 invention. It will be apparent, however, to one skilled in the art that the technology described in the various example embodiments can 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 invention 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 invention are not necessarily all referring to the same embodiment.
- Some portions of the detailed descriptions that 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 discussion, 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 embodiment of the invention also relates 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 memories including USB keys with non-volatile memory or any type of media suitable for storing electronic instructions, 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 systems 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 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.
-
FIG. 1 illustrates a block diagram of asystem 100 for managing decentralized healthcare information according to one embodiment of the invention. InFIG. 1 and the remaining figures, a letter after a reference number, such as “115 a” is a reference to the element having that particular reference number. A reference number in the text without a following letter, such as “115,” is a general reference to any or all instances of the element bearing that reference number. In the illustrated embodiment, these entities are communicatively coupled via anetwork 105. - The illustrated description of a
system 100 for managing healthcare information includesdata servers users 125 a, 125 b . . . 125 n, practice management software (PMS) 121, an electronic medical records (EMR)application 123, anapplication server 152 and arendezvous server 101. In the illustrated embodiment, these entities are communicatively coupled via anetwork 105. Thedata servers FIG. 1 are used by way of example. WhileFIG. 1 illustrates threedata servers Data server 115 a is coupled to thenetwork 105 viasignal line 108. Auser 125 a accesses thedata server 115 a via signal line 110. In one embodiment thedata server 115 a is amaster data server 115 a that manages the organization of some information for theother data servers 115 n.Data server 115 b is coupled to thenetwork 105 viasignal line 112. A user 125 b accesses thedata server 115 b via signal line 120. - In one embodiment, the
data server 115 a is a hardware server, such as one powered by Medicity®. Thedata server 115 a comprises adata manager 103 a and astorage device 141. Thedata manager 103 a manages healthcare information that is stored in thestorage device 141 and controls how long the information persists in thestorage device 141. Thedata server 115 a is coupled to a local area network (LAN) 109 viasignal line 114. - In one embodiment, the
data server 115 a communicates over the LAN to access theEMR application 123 viasignal line 116 and to access thePMS 121 viasignal line 118. TheEMR application 123 is software for managing electronic medical records that are kept by an enterprise, such as a physician's office. The PMS is software for managing the day-to-day operations of a medical practice, such as tracking patients, scheduling appointments and managing billing including entering charges for services, coding the services and submitting claims out to insurance companies. Although only theEMR application 123 andPMS 121 are depicted in this illustration as being connected to theLAN 109, thedata server 115 a could communicate over the LAN to access other systems and devices. Thedata server 115 is described in greater detail below with reference toFIG. 2B . - The
system 100 illustrates a distributed computing model where eachdata server 115 runs adata manager 103. Eachdata manager 103 a exchanges information with other data managers 103 n. A community of data managers 103 n forms a grid, which is a transmission network that supports the transportation of information. Thedata manager 103 a exchanges information with other data managers 103 n in a secure manner by limiting access to information to specific members of thesystem 100. Specifically, auser 125 a of thedata manager 103 a determines which other participants on the grid theuser 125 a wants to participate with, which eliminates the risk that others outside of the closed community will access the information. - The
rendezvous server 101 manages the asynchronous communication of information betweendata servers rendezvous server 101 accesses the network viasignal line 104. Although only onerendezvous server 101 is illustrated, persons of ordinary skill in the art will recognize thatmultiple rendezvous servers 101 are possible. Therendezvous server 101 is described in greater detail with reference toFIG. 2A . - The
application server 152 manages uploading, purchasing and downloading of applications by auser 125 a of thedata manager 103 a. The applications are downloaded by other data managers 103 n and incorporated into the data manager 103 n. The applications are described in greater detail below with reference toFIG. 3B . In one embodiment, theapplication server 152 is stored on amaster data server 115 a. Theapplication server 152 is coupled to thenetwork 105 viasignal line 154. - In one embodiment, the
application server 152 processes purchases by communicating with therendezvous server 101 to retrieve the user's 125 n identity, billing theuser 125 n for the purchase, generating receipts and performing other functions known to those of ordinary skill in the art for completing a purchase. In one embodiment, theapplication server 152 distributes a percentage of the purchase price to the user that developed the application and keeps the rest of the purchase price as a service charge for maintaining an application store. - The
network 105 is a conventional type, wired or wireless, and may have any number of configurations such as a star configuration, token ring configuration or other configurations known to those skilled in the art. Furthermore, thenetwork 105 may comprise 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, thenetwork 105 may be a peer-to-peer network. Thenetwork 105 may also be coupled to or includes portions of a telecommunications network for sending data in a variety of different communication protocols. In yet another embodiment, thenetwork 105 includes Bluetooth communication networks or a cellular communications 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, etc. - Referring now to
FIG. 2A , therendezvous server 101 comprises a rendezvous engine 200, amemory 237, aprocessor 235, acommunication unit 245 and a storage device for storingpayload queues 210 that are each coupled to thebus 219. Thebus 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 to provide similar functionality. In one embodiment, the rendezvous engine 200 comprises a grid status manager 202, aregistration engine 204, asorter 206 and auser interface engine 208. The rendezvous engine 200 is also discussed in U.S. Pat. No. 7,653,634, entitled “System for the Processing of Information between Remotely Located Healthcare Entities,” filed Oct. 30, 2007 and U.S. Pat. No. 7,953,699, entitled “System for the Processing of Information between Remotely Located Healthcare Entities,” filed Dec. 4, 2009, each of which is herein incorporated by reference. - The
processor 235 comprises an arithmetic logic unit, a microprocessor, a general purpose controller or some other processor array to perform computations and provide electronic display signals to a display device. Theprocessor 235 is coupled to thebus 220 for communication with the other components viasignal line 236.Processor 235 processes data signals and may comprise 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 inFIG. 2A , multiple processors may be included. The processing capability may be limited to supporting the display of images and the capture and transmission of images. The processing capability might be enough to perform more complex tasks, including various types of feature extraction and sampling. It will be obvious to one 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 may be executed byprocessor 235. Thememory 237 is coupled to thebus 220 for communication with the other components viasignal line 238. The instructions and/or data may comprise code for performing any and/or all of the techniques described herein. Thememory 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, thememory 237 also includes a non-volatile memory or similar permanent storage device and media such as a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device known in the art for storing information on a more permanent basis. - The
communication unit 245 transmits and receives data to and from thedata servers 115 n and theapplication server 152. Thecommunication unit 245 is coupled to thebus 220 viasignal line 246. In one embodiment, thecommunication unit 245 includes a port for direct physical connection to thedata servers 115 n, theapplication server 152 or to another communication channel. For example, thecommunication unit 245 includes a USB, SD, CAT-5 or similar port for wired communication with theuser device 115. In another embodiment, thecommunication unit 245 includes a wireless transceiver for exchanging data with thedata servers 115 n, theapplication server 152 or any other communication channel using one or more wireless communication methods, such as IEEE 802.11, IEEE 802.16, BLUETOOTH® or another suitable wireless communication method. - In yet another embodiment, the
communication unit 245 includes a cellular communications transceiver for sending and receiving data over a cellular communications network such as via short messaging service (SMS), multimedia messaging service (MMS), hypertext transfer protocol (HTTP), direct data connection, WAP, e-mail or another suitable type of electronic communication. In still another embodiment, thecommunication unit 245 includes a wired port and a wireless transceiver. Thecommunication unit 245 also provides other conventional connections to the network for distribution of files and/or media objects using standard network protocols such as TCP/IP, HTTP, HTTPS and SMTP as will be understood to those skilled in the art. - The grid status manager 202 is software including routines for managing activity information received from the data managers 103 n. In one embodiment, the grid status manager 202 is a set of instructions executable by the
processor 235 to provide the functionality below for hosting a message queue for each data manager 103 n and receiving and verifying data manager session requests. In another embodiment, the grid status manager 202 is stored in thememory 237 and is accessible and executable by theprocessor 235. In either embodiment, the grid status manager 202 is adapted for cooperation and communication with theprocessor 235 and other components of thedata manager 103 viasignal line 222. - The
registration engine 204 is software and routines for registeringusers 125 n for access to the data manager 103 n. In one embodiment, theregistration engine 204 is a set of instructions executable by theprocessor 235 to provide the functionality below for registering users. Theregistration engine 204 receives a username and password, generates a unique identifier that is associated with the data manager 103 n and receives user preferences for the user interface generated by the data manager 103 n, such as preferred screen font size, colors and how the applications are organized. In another embodiment, theregistration engine 204 is stored in thememory 237 and is accessible and executable by theprocessor 235. In either embodiment, theregistration engine 204 is adapted for cooperation and communication with theprocessor 235 and other components of the rendezvous engine 200 viasignal line 224. In one embodiment, theregistration engine 204 communicates with amaster data manager 103 a to coordinate registration. In another embodiment, theregistration engine 204 is a component of themaster data manager 103 a. - The
sorter 206 is software and routines for handling payloads fromdata managers 103. In one embodiment, thesorter 206 is a set of instructions executable by theprocessor 235 to put incoming payloads into thepayload queue 210, identify the destination for each payload, place the new payloads from thepayload queue 210 in the outbox for the destination data managers 103 n via thecommunication unit 245 and deletes payloads from thepayload queue 210 after receipt of a discard request. - Referring now to
FIG. 2B , thedata server 115 comprises adata manager 103, amemory 237, aprocessor 235, acommunication unit 245 and astorage device 141 that are each connected to thebus 220. Those skilled in the art will recognize that some of the components of thedata server 115 have the same or similar functionality to the components of therendezvous server 101 so descriptions of these components will not be repeated here. For example, theprocessor 235,memory 237,bus 220 andcommunication unit 245 are similar to theprocessor 235,memory 237,bus 219 andcommunication unit 245, respectively. - In one embodiment, the
data manager 103 comprises acontroller 201, agrid engine 203,applications 205, anapplication manager 207, a Virtual Care Team (VCT)module 209, ascrubber module 211 and a user interface engine 213. - The
controller 201 is software including routines for managing the core functions of thedata manager 103 and for transmitting data to the different components. In one embodiment, thecontroller 201 is a set of instructions executable by theprocessor 235 to provide the functionality below for managing data. In another embodiment, thecontroller 201 is stored in thememory 237 and is accessible and executable by theprocessor 235. In either embodiment, thecontroller 201 is adapted for cooperation and communication with theprocessor 235 and other components of thedata manager 103 viasignal line 230. - In one embodiment, the
controller 201 performs core functions by listening for data by listening to ports, scanning folders, etc.; inserting data into locations such as a TCP port, folders, etc.; parsing by converting incoming data into objects, such as Java objects; analyzing by examining objects to determine actions; saving data by creating a new topic or adding to a topic that is saved in thedata storage 141; formatting by rendering data into the required format, such as by mapping, translating and grouping; sending packages of information for distribution and notifying by, for example, sending an email or a Web alert in response to an event occurring. - The
grid engine 203 is software including routines for managing healthcare information on thedata server 101. In one embodiment, thegrid engine 203 is a set of instructions executable by theprocessor 235 to provide the functionality below for storing objects in thestorage device 141, generating and encrypting payloads, generating a queue for outbound payloads, uploading payloads to the rendezvous engine 200, downloading payloads from the rendezvous engine 200, generating a queue for inbound payloads, decrypting and processing received payloads, executing commands from amaster data manager 103 a and performing maintenance activities. In another embodiment, thegrid engine 203 is stored in thememory 237 and is accessible and executable by theprocessor 235. In either embodiment, thegrid engine 203 is adapted for cooperation and communication with theprocessor 235 and other components of thedata manager 103 viasignal line 232. - In one embodiment, the
storage device 141 includes a node warehouse and a topic warehouse. The node warehouse stores identifiers for the other data managers 103 n (i.e. other nodes in the system 100) and information for authenticating data requests from the nodes, such as public key infrastructure (PKI) information. Thestorage device 141 is coupled to thebus 220 viasignal line 248. - The topic warehouse stores topic objects that include topic attributes and capsules. In one embodiment, the topic attributes include an identifier (e.g. a universally unique identifier (UUID) that is associated with open source software), a list of participants, a creation date, a last modified date, a description and a type. Capsules are serialized objects that are stored as name/value pairs. In one embodiment, a capsule includes an identifier (e.g. HL7, original HL7, doctor, patient, audit), a description and information particular to the type of information in the capsule, such as information about a test, a department, a doctor, a topic status, a node ID, patient information and audit information. Capsules support many data formats including Health Level Seven (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). Persons of ordinary skill in the art will recognize that other data formats are possible. The
grid engine 203 transmits the topics to any other data manager 103 n in thesystem 100. When a data manager 103 n makes a change to a copy of the topic, thegrid engine 203 transmits the copy to the other data managers 103 n to update their copy of the topic. - Turning now to
FIG. 3A , a more detailed embodiment of thegrid engine 203 is illustrated. Thegrid engine 203 comprises apayload generator 301, aninbox 303, anoutbox 305, anuploader 307 and adownloader 309. Thepayload generator 301 performs authentication functions and generates payloads. In one embodiment, thepayload generator 301 generates public/private key pairs, stores the private key in thedata storage 141 and transmits the public key to the other data managers 103 n that have access to the payloads. - The
payload generator 301 generates a payload that includes the topic object. In one embodiment, the payload includes a class handler, a payload type, topic participants, a payload topic, a payload identifier, an original agent identifier, capsules and topics. The class handler is used to activate thegrid engine 203 of the data manager 103 n that receives the payload. The payload type is a topic or capsule. The topic participants is a list of data managers 103 n that have access to the topic. The payload capsule is a list of the identifier for the capsules contained in the payload. The payload identifier is a unique identifier for identifying the payload, such as a UUID. The origin agent identifier is the unique identifier of thedata manager 103 that created the original payload. - Once the
payload generator 301 creates the payload, thepayload generator 301 generates a payload header that includes the identifier for the recipient data manager 103 n and encrypts the payload with a public key of the recipient data manager 103 n. In one embodiment, thepayload generator 301 encrypts the payload by encrypting the topic attributes and the capsules with a 2048-bit Advanced Encryption Standard (AES) symmetric key, incorporates a digital signature of thedata manager 103 that creates the payload with a Hash-based Message Authentication Code (HMAC), and the payload is encrypted using a HyperText Transfer Protocol Secure (HTTPS). - The
outbox 305 maintains an outbox queue. In one embodiment, theoutbox 305 stores the payload created by thepayload generator 301 in an outbox queue, periodically contacts the rendezvous engine 200, establishes a secure sockets layer (SSL), uploads the content of the message outbox queue and sends discard requests to the rendezvous engine 200 via thecommunication unit 245. The rendezvous engine 200 places the payload in the outbox for the destination data manager 103 n. The designation data manager 103 n downloads the payload, decrypts the AES key with its private key and uses the AES key to decrypt the payload. - The
inbox 303 maintains a message inbox queue by downloading any new messages from the rendezvous engine 200 via thecommunication unit 245 and puts the new messages in the message inbox queue. - The
applications 205 are software including routines for performing tasks. In one embodiment, theapplications 205 are a set of instructions executable by theprocessor 235 for performing tasks. In another embodiment, theapplications 205 are stored inmemory 237 of thedata server 115 and are accessible and executable by theprocessor 235. In either embodiment, theapplications 205 are adapted for cooperation and communication with theprocessor 235, thestorage device 141, thecontroller 201, theapplication manager 207, the user interface engine 213 and other components of thedata server 115 via thesignal line 226. - The
applications 205 include any type of applications such as an enterprise application, an accounting application, a word processing application, a media application, etc. The applications are for performing tasks such as retrieving health care data of a patient, processing payments received from an insurance provider, authorizing payments, ordering labs, dictation software, maintaining a healthcare registry (e.g. bone marrow), receiving health check-up results of a patient from a lab, sending prescriptions to a drugstore, etc. In one embodiment, theapplications 205 are developed by a user 125. In another embodiment, theapplications 205 are third-party applications that are downloaded from anapplication server 152 and installed on thedata server 115. Theapplication server 152, for example, includes an application store that allows users to search, browse, purchase and download third-party applications. - The
application manager 207 is software including routines for developing and managing theapplications 205. In one embodiment, theapplication manager 207 is a set of instructions executable by theprocessor 235 to provide the functionality described below for developing and managing theapplications 205. In another embodiment, theapplication manager 207 is stored inmemory 237 of thedata server 115 and is accessible and executable by theprocessor 235. In either embodiment, theapplication manager 207 is adapted for cooperation and communication with theprocessor 235, thestorage device 141, thecontroller 201, theapplications 205, the user interface engine 213 and other components of thedata server 115 via thesignal line 239. Theapplication manager 207 is described in further detail with reference toFIG. 3B . -
FIG. 3B illustrates one embodiment of theapplication manager 207 in more detail. In this embodiment, theapplication manager 207 includes anapplication module 302, acertification module 304, acollaboration module 306, acontextual module 308, abridge module 310. - The
application module 302 is software including routines for allowing users 125 to develop and installapplications 205 on thedata server 115. Theapplication module 302 receives a request submitted by the user 125 to develop a new application, install a third-party application, etc. from thecontroller 201. In one embodiment, theapplication module 302 includes a software development kit (SDK) comprising a set of development tools that allow users 125 to developapplications 205. In another embodiment, theapplication module 302 allows users 125 to download and install third-party applications 205 from anapplication server 152. In both embodiments, theapplication module 302 allows the users 125 to define preferences and rules for theapplications 205. Theapplication module 302 stores the rules and preferences in thestorage device 141. In yet another embodiment, theapplication module 302 includes tools to develop application programming interfaces (APIs) to allow thedata manager 103 to interact with third-party applications stored in theapplication server 152 or anyother data servers 115 n. In one embodiment, theapplication module 302 uses Java adapters to provide software developers with the tools for accessing different information platforms, such as thedata servers 115 n and local, state and national registries. Theapplication module 302 transmits the newly created application to theapplication server 152 via thecommunication unit 245 to make it available to other users. - Examples of tools for accessing platforms include a journal API for creating, updating and accessing data in personal journals; a messaging API for accessing the secure messaging infrastructure to exchange information with other platforms; a physician directory API for accessing a global directory of physicians and other provides that are on the grid; a print service for accessing local printers; an International Classification of Disease (ICD) lookup for accessing ICD-9 diagnosis tables; a Current Procedural Terminology (CPT) lookup for accessing CPT procedural tables; a Practice Management (PM) bridge for accessing data from the MPS bridge for demographic, insurance and scheduling queries; an Electronic Medical Records driver for accessing clinical data and other data queries and enabling the insertion of results, reports, referrals and other information; a vocabulary mapping service for translating local terms to standardized terms (e.g. Systemized Nomenclature of MEDicine (SNOMED)); a formatting service for standardizing forms; a community search for searching a Health Information Exchange (HIE) for patient information; and a payer gateway for exchanging information with payers that make their services available in an electronic exchange.
- The journal API is used to create a patient record. In one embodiment the journal API includes demographic information including name, date of birth and address for a patient; scheduling information including appointment type, date and time; clinical problems that are both current and historical for the patient; procedures or treatments for the patient; family history; social history that includes lifestyle, occupation, environmental health risks and patient demographics such as marital status, ethnicity and religion; advanced directives including wills, healthcare proxies and resuscitation wishes including both patient instructions and references to external documents; alerts such as allergies and adverse reactions; medications including current medications and relevant historical medication usage; immunizations including immunization status and historical information about past immunizations; medical equipment and any implanted or external devices; vital signs including trends over time and baselines; functional status including information about what is normal for the patient, deviations from normalcy (both positive and negative) and extensive examples; results including lab and procedure results and reports; encounters including past healthcare encounters including activity and location; and a plan of care including active, incomplete or pending activities for the patient including orders, appointments, procedures, referrals and services.
- The
certification module 304 is software including routines for certifying theapplications 205 developed by the users 125. In one embodiment, thecertification module 304 receives a message from theapplication module 302 that a new application has been developed by a user 125. Thecertification module 302 determines whether the new application is compatible with theapplications 205 that are installed on thedata server 115. For example, thecertification module 304 determines whether the new application includes APIs to interact with theapplications 205. In another embodiment, thecertification module 304 certifies that the new application can be uploaded to anapplication server 152. Thecertification module 304 instructs the user interface engine 213 to generate a user interface that displays a message. In one embodiment, the message indicates that the new application is certified to be installed on thedata server 115, uploaded to theapplication server 152, etc. In another embodiment, the message indicates that the new application is not certified and includes a list of issues that need to be resolved for the new application to be certified. - The
collaboration module 306 is software including routines for generating a list ofdata servers 115 n that communicate with thedata server 115 a. In one embodiment, the list includes the applications installed in each of thedata servers 115 n. Thecollaboration module 306 generates the list in response to receiving a request submitted by a user 125 to develop a new application. The user 125, for example, uses the list to develop APIs for the new application. - The
contextual module 308 is software including routines for managing the interactions between theapplications 205. Thecontextual module 308 receives a message from anapplication 205 when theapplication 205 performs a task. Thecontextual module 308 analyzes the task, for example, analyzes a request submitted by the user 125, the retrieved health care data of a patient, etc. Thecontextual module 308 determines if the analysis matches one or more rules or preferences that are defined for any other application installed on thedata server 115. In response to determining a match with a rule or a preference of an application, thecontextual module 308 transmits a notification to the application. Thecontextual module 308 is described in further detail with reference toFIG. 7 . - The
bridge module 310 is software including routines for managing the exchange of data between theapplications 205 and the computing systems, for example,PMS 121, theEMR application 123, diagnostic devices (not shown), etc. that are locally connected to adata server 115. Thebridge module 310 communicates data such as, queries, instructions, messages, health care data of a patient, etc. between theapplications 205 and the local computing systems. Thebridge module 310 converts the data into a format that is compatible with the requirements of the destination. For example, anapplication 205 generates a query for retrieving a list of patients with leukemia from theEMR application 123. Thebridge module 310 converts the query into a HL7 standard and submits the query to theEMR 123. Thebridge module 310 receives the list of patients from theEMR 123, converts the list into a PDF as requested by theapplication 205 and transmits it to theapplication 310. Thebridge module 310 converts the data to HL7 standards, Continuity of Care Document (CCD), Continuity of Care Record (CCR), Structured Query Language (SQL), PDF or any other format or standard known to a person of ordinary skill in the art. - The Virtual Care Team (VCT)
module 209 is software including routines for creating VCT records that are related to a specific patient and for collaborating withother data servers 115 n. In one embodiment, theVCT module 209 is a set of instructions executable by theprocessor 235 to provide the functionality described below for creating VCT records and collaborating withother data servers 115 n. In another embodiment, theVCT module 209 is stored inmemory 237 of thedata server 115 and is accessible and executable by theprocessor 235. In either embodiment, theVCT module 209 is adapted for cooperation and communication with theprocessor 235, thestorage device 141, thecontroller 201, the user interface engine 213 and other components of thedata server 115 viasignal line 240. - A VCT record comprises health care data associated with a patient or a group of patients (for example, a family, colleagues, etc.). The health care data includes a patient identity (ID), demographic information, information related to a care team of the patient, insurance information, prescriptions, results, allergies, medical history, referrals, rules, preferences, etc. A care team of a patient is a group of
data servers 115 n (for example, a primary physician, a cardiologist, an insurance provider, etc.) that are associated with the health care of the patient. TheVCT module 209 is described in further detail with reference toFIG. 3C . -
FIG. 3C illustrates one embodiment of theVCT module 209 in more detail. In this embodiment, theVCT module 209 includes acreation module 352, areferral module 354, adata transmitter 356, adata receiver 358 and anadvertisement module 360. - The
creation module 352 is software including routines for creating VCT records. Thecreation module 352 receives a request submitted by a user 125 for creating a VCT record (for example, a request submitted by a hospital administrator to create a VCT record for a new patient) from thecontroller 201. Thecreation module 352 generates a VCT record based on the information (for example, a registration form filled out by the patient, etc.) included in the request. In one embodiment, where the information included in the request in insufficient, thecreation module 352 retrieves additional information about the patient from local databases such as thePMS 121, theEMR application 123, etc. In another embodiment thecreation module 352 instructs the user interface engine 213 to generate a user interface requesting additional information from the user 125. Thecreation module 352 stores the VCT records in thestorage device 141. Thecreation module 352 generates a VCT record that is helpful for both transmitting information toother data servers 115 n and for transmitting a complete record to an application outside of thesystem 100. - The
referral module 354 is software including routines for transmitting and receiving referrals for a patient to and fromother data servers 115 n. Thereferral module 354 identifies one ormore data servers 115 n for a patient from a directory of data servers in thestorage device 141. In one embodiment, thereferral module 354 identifies adata server 115 b responsive to receiving a request submitted by auser 125 a from thecontroller 201. The request, for example, is submitted by a primary care physician to identify a cardiologist for the patient. In another embodiment, thereferral module 354 automatically identifies adata server 115 b based on a patient's VCT record. For example, thereferral module 354 determines that a patient does not have insurance coverage from the patient's VCT record. Thereferral module 354 then identifies an insurance provider for the patient. In yet another embodiment, thereferral module 354 identifies adata server 115 b for a patient responsive to receiving an instruction from anapplication 205. Thereferral module 354 identifies thedata servers 115 n for a patient corresponding to the information in the patient's VCT record. For example, thereferral module 354 identifies a clinic located within five miles of the patient's house, a neurologist covered by the patient's insurance provider, etc. - The
referral module 354 instructs thecontroller 201 to transmit a referral to thedata server 115 b. The instruction includes a copy of the patient's VCT record and information such as an identification of thedata server 115 b, methods to communicate with thedata server 115 b, etc. Thereferral module 354 updates the VCT record of the patient by adding thedata server 115 b to the care team of the patient. In one embodiment, thereferral module 354 updates the VCT record of the patient in response to receiving an acknowledgment from thedata server 115 b. - The
referral module 354 also receives referrals transmitted byother data servers 115 n from thecontroller 201. Thereferral module 354 retrieves the copy of the patient's VCT record from the referral and assigns a patient ID that is local to thedata server 115 a. Thereferral module 354 then creates a link between the local patient ID and the patient ID present in the VCT record. Thereferral module 354 updates the copy of the patient's VCT record with the link and stores it in thestorage device 141. Thereferral module 354 also instructs thecontroller 201 to transmit the link to thedata servers 115 n from which the referral was received. Thereferral module 354 is described in further detail with reference toFIG. 8A . - The
data receiver 356 is software including routines for receiving new health care data associated with a patient from thecontroller 201. In one embodiment, thedata receiver 356 receives new health care data submitted by a user 125. For example, thedata receiver 356 receives the blood pressure level of a patient submitted by a nurse. In another embodiment, thedata receiver 356 receives health care data from a computing system that is locally connected to thedata server 115 a. For example, thedata receiver 356 receives scan images of a patient's shoulder from an MRI scanner that is connected to thedata server 115 a. In yet another embodiment, thedata receiver 356 receives new health care data transmitted by other care team members of the patient, for example, prescriptions, updated insurance coverage plan, etc. In this embodiment, thedata receiver 356 determines whether the new health care data is required by thedata server 115 a based on rules and preferences stored in thestorage 141. For example, a cardiologist requires blood test results of a patient but not a physical therapist. In one embodiment, thedata receiver 356 instructs the user interface engine 213 to generate a user interface that displays the new health care data. In this embodiment, a user 125, (for example, a physician, a nurse, etc.) selects the new health care data required for thedata server 115 a. Thedata receiver 356 retrieves the VCT record of the patient and updates it with the new health care data. - In one embodiment, the
data receiver 356 performs reconciliation of new data that includes conflicting information. For example, the new information is demographic information that does not match any patient data in thestorage device 141. Thedata receiver 356 determines different patients that might match the demographic information, for example, thedata receiver 356 identifies patients that match the demographic information if the numbers in the data of birth are transposed or the name “Jon” is replaced with “John.” Thedata receiver 356 saves the rule for correcting the conflicting information in thestorage device 141. In one embodiment, thedata receiver 356 transmits the corrected data to the care team member that submitted the conflicting information via thecommunication unit 245 for confirmation. If the same conflicting information is received in the future, thedata receiver 356 corrects the information using the same rule. - The
data transmitter 358 is software including routines for transmitting health care data associated with a patient to the patient's care team members via thecommunication unit 245. Thedata transmitter 358 receives new health care data associated with a patient from thedata receiver 356. Thedata transmitter 358 identifies the patient's care team members from the VCT record. Thedata transmitter 358 then instructs thecommunication unit 245 to transmit the new health care data to the patient's care team members. In one embodiment, prior to instructing thecommunication unit 245, thedata transmitter 358 formats the new health care data based on the preferences of each of the care team members. In another embodiment, thedata transmitter 358 determines whether the new health care data can be transmitted to the care team members based on the rules (for example, care team member preferences, patient's privacy rules, HIPAA compliance, etc.) present in the patient's VCT record. - The
advertisement module 360 is software including routines for advertising adata server 115 a. Theadvertising module 360 generates advertisements that include a unique identifier associated with thedata server 115 a, such as a UUID and instructs thecontroller 201 to transmit them toother data servers 115 n. The advertisement includes the information about thedata server 115 a such as, health care services provided by thedata server 115 a, a list of physicians, a list of insurance plans that cover the services provided by thedata server 115 a, location, etc. The advertisements are advantageous as, for example, theother data servers 115 n transmit referrals to thedata server 115 a based on these advertisements. - The
scrubber module 211 is software including routines for identifying individuals for a study, such as a clinical trial and for scrubbing patient data of identifying information. In one embodiment, thescrubber module 211 is a set of instructions executable by theprocessor 235 to provide the functionality described below for scrubbing identifying information in response to a request from anapplication 205. In another embodiment, thescrubber module 211 is stored inmemory 237 of thedata server 115 and is accessible and executable by theprocessor 235. In either embodiment, thescrubber module 211 is adapted for cooperation and communication with theprocessor 235, thestorage device 141, thecontroller 201, theapplications 205, the user interface engine 213 and other components of thedata server 115 via thesignal line 242. Thescrubber module 211 is described in further detail with reference toFIG. 3D . - Referring now to
FIG. 3D , one embodiment of thescrubber module 211 is shown in more detail.FIG. 3D is a block diagram of thescrubber module 211 that includes anadvertisement listing engine 372, aparticipant identifying engine 374, adata scrubbing engine 376, a pseudoidentifier generator engine 378 and anadvertisement response engine 380 that are each coupled to signalline 242. - The
advertisement listing engine 372 registers an advertisement for recruiting potential participants for a study. Theadvertisement listing engine 372 receives a request for potential participants for a study from an organization. The organization is any group that uses medical information, such as a government health organization (e.g. the CDC), an insurance company and a clinical research organization (e.g. a hospital). - The request includes an identifier such as a name for the study and patient factors for identifying potential participants for the study. For example, a clinical research organization uses the
scrubber module 211 to identify a number of individuals that are available for a study to test a medication for a health condition where the patients are in a particular age group and have responded adversely to a different medication. The clinical research organization places an advertisement that includes input data for identifying the participants. The input data relates to a diagnosis, medication, lab results, gender, age, location, previous medical history such as previous illnesses, a history of illnesses and other factors that are relevant to the study. In one embodiment, theadvertisement listing engine 372 transmits the request to theparticipant identifying engine 374 for an immediate identification of potential participants for the study. In another embodiment, theparticipant identifying engine 374 stores the request in thestorage device 141 for identification of potential participants for the study at a later time - The
participant identifying engine 374 identifies potential participants for a study based on the advertisement from an organization that is received from theadvertisement listing engine 372. Theparticipant identifying engine 374 identifies individuals based on matching the input data with patient data and medical records. In one embodiment, information for the identified individuals is transmitted to thedata scrubbing engine 376. In another embodiment, the number of identified individuals that match is transmitted to theadvertisement response engine 380. - The
data scrubbing engine 376 modifies patient data to scrub it of identifying aspects. In one embodiment thedata scrubbing engine 376 receives a request from anapplication 205 to scrub patient data. For example, the patient data includes data related to an admission of a patient or a lab event. In another embodiment, thedata scrubbing engine 376 receives the individuals that match the advertisement from theparticipant identifying engine 374. Thedata scrubbing engine 376 receives patient data from a master patient index that is part of thedata storage 141 or stored in another location, such as part of theEMR application 123. In one embodiment, thedata scrubbing engine 376 modifies identifying information by removing demographic data. Identifiable demographic data includes name, address, birth date, ethnicity, government issued numbers such as a social security number and operational patient numbers such as a patient identifier. In another embodiment, thedata scrubbing engine 376 modifies patient data by replacing the identifiable demographic data. For example, thedata scrubbing engine 376 replaces the birth date with the age of the individual or transposes the digits for the birth date. - The
data scrubbing engine 376 requests a pseudo identifier from the pseudoidentifier generator engine 378. The pseudoidentifier generator engine 378 generates a pseudo identifier for a patient. Thedata scrubbing engine 376 receives the pseudo identifier from the pseudoidentifier generator engine 378 and associates the pseudo identifier with the patient by storing the pseudo identifier in thestorage device 141. - In another embodiment, the
data scrubbing engine 376 associates the pseudo identifier with the patient by storing the pseudo identifier with patient data in the master patient index. Thedata scrubbing engine 376 transmits the pseudo identifier and other data to theapplication 205 that requested the scrubbing or to theadvertisement response engine 380. Therefore, the pseudo identifier is used by an organization to retrieve medicals records of person without revealing the identity of the person. Also, because the pseudo identifier is a static identifier that is consistently associated with the same patient, the organization that requests the pseudo identifier tracks the same person over time. For example, a clinical research company uses thescrubber module 211 for a study for the same person over a period of 5 years. - The
advertisement response engine 380 responds to an advertisement for recruiting potential participants for a study. Theadvertisement response engine 378 receives a number of patients that match the input data from theparticipant identifying engine 374 or scrubbed information from thepseudo identifier generator 378. In one embodiment, theadvertisement response engine 380 notifies a provider of care that the individuals are identified as potential participants for the study. In another embodiment, theadvertisement response engine 380 sends basic statistics to the organization that requested the potential participants. For example, theadvertisement response engine 380 informs the organization that a specific number of potential participants have been identified by theparticipant identifying engine 372. - The user interface engine 213 is software including routines for generating a user interface in response to instructions received from the
other data manager 103 components. In one embodiment, the user interface engine 213 is a set of instructions executable by theprocessor 235 to provide the functionality described below for generating a user interface forapplications 205, theVCT module 209 or thescrubber module 211. In another embodiment, the user interface engine 213 is stored inmemory 237 of thedata server 115 and is accessible and executable by theprocessor 235. In either embodiment, thescrubber module 211 is adapted for cooperation and communication with theprocessor 235, thestorage device 141, theapplications 205, the user interface engine 213 and other components of thedata server 115 via thesignal line 242. The user interface engine 213 is described in further detail with reference toFIGS. 4A-4H . - Turning now to user interface engine 213,
FIG. 4A is a graphic representation of auser interface 401 that is generated by the user interface engine 213 for accessing at least one patient record. In this example, theuser interface 401 displays ahomepage 402 of a medical office website for healthcare providers of that medical office. Thehomepage 402 includesicons 404 of underlying composite applications that are installed by a user to meet his or her unique needs. A user searches for a patient record by typing a first name of the patient, a last name of the patient or any combination thereof in the search box and hitting thesearch button 406 on thehomepage 402. For example, typing “Angela” in the search box retrieves alist 412 of patients whose first name includes Angela. In addition, thehomepage 402 includes aList All 408 button that, when selected displays the entire list of available patient records and aCreate Record 410 button that, when selected, displays a user interface for creating a record for a new patient. -
FIG. 4B is agraphic representation 403 of a user's view of an application store that is hosted by theapplication server 152. In this embodiment, the application store includes acategories icon 422 by which the user can view and select the type of applications to install. In addition to thecategories icon 422, the application store lists the applications belonging to a particular type under sections such as popular applications, suggested applications, installed applications, updates to installed applications and new applications. In this example, the user selects the allicon 424 and selects the “what's new”tab 426. Asub-section 428 opens up that lists all the applications under the “what's new”tab 426 and the user chooses to buy theTimeline Application 430. In another embodiment, at least one of the applications listed is free to be installed by the user. In yet another embodiment, the applications listed in the application store are developed by third-party vendors. -
FIG. 4C is agraphic representation 405 of a user's view of the functionality offered by thereferrals application 430 including sending and receiving of patient referrals. In this embodiment, thereferrals application 430 displays aworklist 432 comprising thepatient referrals 438 that were sent by the user in response to the user selecting the sentreferrals 436 option. In another embodiment, the options present in theheader 434 includes a drop down box to illustrate different categories in order to narrow down the referrals the user is interested in. For example, under the sentreferrals 436 option, the user can choose to view referrals that are completed, in progress, denied and not yet accepted ones separately if interested. Eachpatient referral 438 comprises the patient name, status of the referral, the department or institution the referral is sent to and date and time of the referral, update and schedule. The user interface engine 213 allows the user to configure the display of thereferral information 438 and other features of the display. -
FIG. 4D is anothergraphic representation 407 of a user's view of the functionality offered by thereferrals application 430 in response to clicking on apatient referral 438 inFIG. 4C . In this embodiment, the list of underlying composite applications displayed near the top of the webpage change in their appearance visually at least in part to reflect the medical record of thepatient 440 associated with thepatient referral 438 fromFIG. 4C . Thereferral application 430 includes the accompanyingreferral information 442 which lists the referring provider, referral details, scheduling information and any messages exchanged between the referring provider and the referred provider pertaining to the patient treatment. -
FIG. 4E is agraphic representation 409 of a user's view of the functionality offered by the patientcare timeline app 452.Graphic representation 409 displays a slidinglist 454 of encounters with thepatient 440 including routine visits, lab tests and checkups from at least one medical institution. Upon selecting onesuch encounter 456, the patientcare timeline application 452 displays asub section 458 listing the details of that particular encounter. Thesub section 458 includes the physician's name, visit type, complaint, personal and medical information of thepatient 440. Eachinformation tab 460 associated with thepatient 440, in response to clicking on it, expands to let the user view the information in detail and edit the information if needed. In another embodiment, the patientcare timeline app 452 indicates visually to the user that at least one of the other underlying applications has important patient information which is pertinent to the patientcare timeline application 452. For example, a highlighted exclamation mark on the patientcare timeline application 452 in response to a highlighted numeral three on the virtual care team application is an indication that the two applications are ready to communicate with each other to reconcile patient record. -
FIG. 4F is agraphic representation 411 of a user's view of reconciliatory updates procured by the virtualcare team application 462 in order to reconcile patient records. The virtualcare team application 462 displays anupdate tab 464 associated with different departments and/or institutions. In addition, the virtualcare team application 462 displays a visible numeral indicating the number of updates to be reconciled. In this example, the virtualcare team app 462 displays the number three. Theupdate tab 464 associated with a department and/or institution comprises the day, the date, the time and the time zone for eachindividual update 466 received. In one embodiment, eachupdate 466 needs to be authorized by the user to be reconciled by selecting the check box beside theupdate 466. In another embodiment, all the updates are reconciled at once without checking everyindividual update 466 by checking the reconcile icon underneath the “Mark updates as reconciled?”text 468. -
FIG. 4G is anothergraphic representation 413 of a user's view of the patientcare timeline application 452 after reconciling a patient record with updates from the virtualcare team application 462. The user interface engine 213 changes the patientcare timeline application 452 appearance at least in part in response to the updates being reconciled in the virtualcare team application 462 inFIG. 4F . In this embodiment, the patientcare timeline application 452 displays the encounter that received the updates and the fields in the encounter that were updated by highlighting them to the user for at least a period of time. In this example, the cardiacstress test encounter 472 is highlighted and accompanyingpayers information tab 474,problems information tab 476 andmedications information tab 478 after the user clicks on thepatient care timeline 452. - Turning now to
FIG. 4H , one embodiment of auser interface 481 generated by the user interface engine 213 for generating a request or advertisement for recruiting potential participants for a study is illustrated. Theuser interface 481 displays a plurality of inputs for generating a request. The plurality of inputs includes aninput 483 for identifying or labeling the study. Theuser interface 481displays input area 485 for capturing medical related criteria for creating input data that is used to identify patients for the study. In the example,input area 485 comprises diagnosis information, allergy information, medication information, and lab result information.User interface 481 displays agender input 487 for identifying one or all genders for the study.User interface 481 displays anage input 489 for identifying an age or age group for the study. A user submits the request or advertisement by pressing the submit button 491. Persons of ordinary skill in the art will recognize that other variables can also be displayed for generating the request, such as a text box for specifying a location, previous illnesses, family history of illnesses, etc. Theadvertisement listing engine 372 receives the request and registers the request for identifying potential participants for the study. - Referring now to
FIGS. 5-10 , various example embodiments of the invention will be described. -
FIG. 5 is a flow diagram 500 illustrating one embodiment for generating a payload. Afirst data manager 103 a includes agrid engine 203 that generates 502 public/private key pairs and transmits 504 the public key to all authorized data managers 103 n. In one embodiment the public/private key pairs are generated with a 2048-bit RSA PKI. Thegrid engine 203 generates 506 a payload for a topic object, the topic object including topic attributes and a plurality of capsules. Thegrid engine 203 encrypts 508 the payload. In one embodiment, thegrid engine 203 uses an AES symmetric key to encrypt the topic object. Thegrid engine 203 via thecommunication unit 245uploads 510 the payload to an inbox for the rendezvous engine 200. -
FIG. 6 is a flow diagram 600 illustrating one embodiment for using a rendezvous engine 200 to transmit data between data managers 103 n. The rendezvous engine 200 includes asorter 206 that receives 602 a payload from a first data manager via the communication unit. Thesorter 206sorts 604 the payload into apayload queue 210. Thesorter 206 identifies 606 the destination for the payload as asecond data manager 103 b. Thesorter 206places 608 the payload in an outbox for thesecond data manager 103 b. Thesecond data manager 103 b downloads 610 the payload and decrypts 612 the payload. -
FIG. 7 is a flow diagram 700 illustrating one embodiment for transmitting a notification to an application based on a task performed by another application. Thecontroller 201 receives 702 a request submitted by a user 125 for retrieving patient data using a retrieval application. The retrieval application retrieves 704 the patient data. For example, the retrieval application retrieves a virtual care team (VCT) record of a patient from thedata storage 141. The user interface engine 213 generates 706 a user interface displaying the patient data. Theapplication manager 207 includes acontextual module 308 that determines 708 whether the patient data matches a rule of a health monitor application. Thecontextual module 308 transmits 710 a notification to the health monitor application in response to determining that the patient data matches the rule. In this example, thecontextual module 308 determines from the patient's VCT record that the patient's cholesterol level is higher than a threshold and transmits a notification to the health monitor application. The health monitor application instructs the user interface engine 213 to generate a user interface. The user interface engine 213 generates 714 a user interface displaying a message. In this example, the user interface displays a warning message that the patient's cholesterol level is too high. -
FIG. 8A is a flow diagram 800 illustrating one embodiment for transmitting referrals. AVCT module 209 includes acreation module 352 that (for example, a primary care physician) assigns 802 a first patient identifier (ID) for a new patient. Thecreation module 352 creates 804 a VCT record for the patient. In this example, theprimary care physician 115 a diagnoses that the patient requires surgery on his knee and submits a request. Thereferral module 354 identifies adata server 115 b (for example, an orthopedic surgeon) from thestorage device 141. Thecontroller 201 transmits 806 a referral to thedata server 115 b via thecommunication unit 245. The referral comprises a copy of the patient's VCT record that includes the first patient ID. Thereferral module 354 also updates 808 the VCT record to include thedata server 115 b as a member of the care team of the patient. Thereferral module 354 of thedata server 115 b assigns 810 a second patient ID for the referral based on the format requirements and the rules of thedata server 115 b. Thereferral module 354 generates 812 a first link between the first patient ID and the second patient ID. Thecontroller 201 of thedata server 115 b then transmits 814 the first link to thedata server 115 a. Thereferral module 354 of thedata server 115 aupdates 816 the VCT record to include the first link. - The
referral module 354 of thedata server 115 b then identifies adata server 115 n (for example, a physical therapist) for the patient. Thecontroller 201 of thedata server 115 b transmits 818 a referral to thethird data server 115 n. This referral comprises a copy of the patient's VCT record that includes the second patient ID and the first link. Thereferral module 354 of thedata server 115 bupdates 820 the VCT record to include thedata server 115 n as a member of the care team of the patient. Thereferral module 354 of thedata server 115 n assigns 822 a third patient ID for the referral. Thereferral module 354 of thedata server 115 n also generates 824 a second link between the first patient ID, the second patient ID and the third patient ID. Thecontroller 201 of thedata server 115 n then transmits 826 the second link to thedata server 115 b. Thereferral module 354 of thesecond data server 115 bupdates 830 the patient's VCT record to include the second link. Thecontroller 201 of thedata server 115 n also transmits 828 the second link to thedata server 115 a. Thereferral module 354 of thedata server 115 aupdates 832 the patient's VCT record to include the second link and thedata server 115 n as a member of the patient's care team. - The links are advantageous in scenarios, for example, when the
data server 115 a receives health care information from thedata server 115 b that is represented by the second patient ID. In this example, thedata server 115 a easily identifies and retrieves the VCT record of the patient based on the first link. Furthermore, in this example, although thedata server 115 n was not referred by thedata server 115 a, the second link allows exchange of health care information associated with the patient between thedata servers -
FIG. 8B is a flow diagram 850 illustrating one embodiment for exchanging information between care team members of a patient. Thedata receiver 356 of thedata server 115 a receives 852 new information associated with a patient. Thedata receiver 356updates 854 the VCT record of the patient with the new information. Thedata transmitter 358 of thedata server 115 a determines 856 whether the new information should be transmitted to other care team members of the patient. In response to determining that the new information should be transmitted, thedata transmitter 358 transmits 858 the new information to thedata server 115 b. Thedata transmitter 358 also transmits 860 the new information to thedata server 115 n. Thedata receiver 356 of thedata server 115 b determines 862 whether the new information is required. Thedata receiver 356 updates 864 the VCT record of the patient in response to determining that the new information is required. Thedata receiver 356 of thedata server 115 n determines 866 whether the new information is required for thedata server 115 n. Thedata receiver 356rejects 868 the new information in response to determining that the new information is not required for thedata server 115 n. -
FIG. 9 is a flow diagram 900 of one embodiment of a method for recruiting participants for a study. Theadvertisement listing engine 374 receives 902 a request for potential participants for a study including input data for identifying the potential participants. In one embodiment, the input data includes information relating to a diagnosis, medication, lab results, gender, age, location, etc. Theadvertisement listing engine 374stores 906 the request and input data in thestorage device 141. Theparticipant identifying engine 372 receives 906 patient information or an update of patient information. Theparticipant identifying engine 372 identifies 908 a potential participant based on the input data and the patient information. Theadvertisement response engine 378 generates 910 a report or message based on identifying the potential participant. In one embodiment, theadvertisement engine 378 generates a message that an individual is a match for the study. In the embodiment, the message is sent to a provider of care or the individual. In another embodiment, theadvertisement response engine 378 generates a message that includes statistics based on identifying one or more potential participants. In the embodiment, theadvertisement response engine 378 sends the message to a clinical research organization that is recruiting participants for the study. -
FIG. 10 is a flow diagram 1000 of one embodiment of a method for pseudoanonymising patient information. Thedata scrubbing engine 376 receives 1002 data related to a patient. In one embodiment, the data is related to an admission of a patient or a lab event. Thedata scrubbing engine 376 modifies 1004 the data by removing demographic information. In one embodiment, thedata scrubbing engine 376 removes any key information for identifying an individual. For example, key information includes name, social security number or other government identifiers, birth date, mail address or race. In another embodiment, thedata scrubbing engine 376 modifies the data by replacing demographic data that leads to identification of an individual. In one embodiment, the key information is determined by government standards for the purpose of protecting the identity of individuals. Thepseudo identifier generator 378 generates 1006 a pseudo identifier for the modified data related to the patient. Thedata scrubbing engine 376associates 1008 the pseudo identifier with the modified data related to the patient. Thedata scrubbing engine 376stores 1010 the pseudo identifier and the modified data in thestorage device 141. Thedata scrubbing engine 376 receives 1012 a request for the modified data including the pseudo identifier. Thedata scrubbing engine 376 retrieves the modified data based on the pseudo identifier and transmits 1014 the modified data to the requestor via thecommunication unit 245. - The foregoing description of the example 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 familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, 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. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, routines, features, attributes, methodologies and other aspects of the disclosure can be implemented as software, hardware, firmware or any combination of the three. Also, wherever a component, an example of which is a module, of the invention is implemented as software, the component can 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 every and any other way known now or in the future to those of ordinary skill in the art of computer programming. Additionally, the 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 (20)
1. 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 and a care team record of the patient;
assigning a second identity of the patient;
generating a first link between the first identity and the second identity of the patient; and
transmitting the first link to the first server and one or more care team members of the patient.
2. The method of claim 1 , further comprising identifying a second server and transmitting a second referral of the patient to the second server.
3. The method of claim 2 , further comprising updating the care team record of the patient with the second server.
4. The method of claim 3 , further comprising receiving a second link from the second server and updating the care team record of the patient with the second link.
5. The method of claim 1 , further comprising receiving new health care information associated with the patient.
6. The method of claim 5 , further comprising determining whether the new health care information should be transmitted to the care team members of the patient.
7. The method of claim 5 , further comprising:
receiving the new health care information from the first server;
determining whether the new health care information associated with the patient is required; and
updating the care team record of the patient in response to determining that the new health care information is required.
8. The method of claim 7 , further comprising rejecting the new health care information in response to determining that the new health care information is not required.
9. The method of claim 5 , further comprising generating a user interface displaying the new health care information.
10. The method of claim 1 , further comprising receiving an advertisement from a second server.
11. A system for managing referrals of a patient comprising:
a controller for receiving a first referral of the patient from a first server and for transmitting a first link to the first server and one or more care team members of the patient, the first referral including a first identity and a care team record of the patient; and
a referral module coupled to the controller, the referral module 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.
12. The system of claim 11 , wherein the referral module further identifies a second server and updates the care team record of the patient with the second server and a second link.
13. The system of claim 12 , wherein the controller further transmits a second referral to the second server and receives the second link.
14. The system of claim 11 , further comprising a data receiver coupled to the referral module, the data receiver for receiving new health care information associated with the patient.
15. The system of claim 14 , further comprising a data transmitter coupled to the data receiver, the data transmitter for determining whether the new health care information should be transmitted to the care team members of the patient.
16. The system of claim 14 , wherein the data receiver receives the new health care information from the first server, determines whether the new health care information associated with the patient is required and updates the care team record of the patient in response to determining that the new health care information is required.
17. The system of claim 16 , wherein the data receiver rejects the new health care information in response to determining that the new health care information is not required.
18. The system of claim 14 , further comprising a user interface engine coupled to the data receiver, the user interface engine for generating a user interface displaying the new health care information.
19. The system of claim 13 , wherein the controller further receives an advertisement from the second server.
20. A computer program product comprising a computer useable medium including a computer readable program, wherein the computer readable program when executed on a computer causes the computer to:
receive a first referral of the patient from a first server, the first referral including a first identity and a care team record of the patient;
assign a second identity of the patient;
generate a first link between the first identity and the second identity of the patient; and
transmit the first link to the first server and one or more care team members of the patient.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/280,292 US20120101849A1 (en) | 2010-10-22 | 2011-10-24 | Virtual care team record for tracking patient data |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US40600310P | 2010-10-22 | 2010-10-22 | |
US13/280,292 US20120101849A1 (en) | 2010-10-22 | 2011-10-24 | Virtual care team record for tracking patient data |
Publications (1)
Publication Number | Publication Date |
---|---|
US20120101849A1 true US20120101849A1 (en) | 2012-04-26 |
Family
ID=45973731
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/280,290 Abandoned US20120101843A1 (en) | 2010-10-22 | 2011-10-24 | System and method for anonymizing patient data |
US13/280,292 Abandoned US20120101849A1 (en) | 2010-10-22 | 2011-10-24 | Virtual care team record for tracking patient data |
US13/280,287 Active 2032-03-09 US8661453B2 (en) | 2010-10-22 | 2011-10-24 | Managing healthcare information in a distributed system |
US14/171,655 Active US8990834B2 (en) | 2010-10-22 | 2014-02-03 | Managing healthcare information in a distributed system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/280,290 Abandoned US20120101843A1 (en) | 2010-10-22 | 2011-10-24 | System and method for anonymizing patient data |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/280,287 Active 2032-03-09 US8661453B2 (en) | 2010-10-22 | 2011-10-24 | Managing healthcare information in a distributed system |
US14/171,655 Active US8990834B2 (en) | 2010-10-22 | 2014-02-03 | Managing healthcare information in a distributed system |
Country Status (4)
Country | Link |
---|---|
US (4) | US20120101843A1 (en) |
CN (1) | CN103339605A (en) |
CA (1) | CA2815487A1 (en) |
WO (1) | WO2012054932A2 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120253844A1 (en) * | 2011-03-30 | 2012-10-04 | Mckesson Financial Holdings | Apparatus, method and computer-readable storage mediums for providing a context-sensitive alert regarding a multimedia object |
US20130275361A1 (en) * | 2012-04-17 | 2013-10-17 | Cerner Innovation, Inc. | Associating multiple data sources into a web-accessible framework |
US20130304510A1 (en) * | 2012-05-08 | 2013-11-14 | Drfirst.Com, Inc. | Health information exchange system and method |
US20160300018A1 (en) * | 2013-11-28 | 2016-10-13 | Agfa Healthcare Nv | A method and computer program product for management of the distribution of medical reports in clinical application |
US20180144095A1 (en) * | 2016-11-18 | 2018-05-24 | International Business Machines Corporation | Resolving conflicting data among data objects associated with a common entity |
US10332625B2 (en) | 2014-04-07 | 2019-06-25 | Imprivata, Inc. | Coordinating communications among healthcare providers |
US11114194B2 (en) | 2015-10-01 | 2021-09-07 | Audacious Inquiry | Network-based systems and methods for providing readmission notifications |
US11557396B2 (en) | 2010-09-29 | 2023-01-17 | Humana Inc. | Electronic medical record exchange |
Families Citing this family (60)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120215560A1 (en) | 2010-07-21 | 2012-08-23 | dbMotion Ltd. | System and methods for facilitating computerized interactions with emrs |
US20120072312A1 (en) * | 2010-09-22 | 2012-03-22 | Microsoft Corporation | Curated Application Store |
US20120253845A1 (en) * | 2011-03-30 | 2012-10-04 | Mckesson Financial Holdings | Apparatus, method and computer-readable storage mediums for browsing and selecting a multimedia object |
JP6044148B2 (en) * | 2011-08-03 | 2016-12-14 | 株式会社リコー | Communication control device, information management system, information management device, communication control program, and information management program |
US10726088B1 (en) | 2011-08-12 | 2020-07-28 | Allscripts Software, Llc | Computing system for presenting supplemental content in context |
US10678876B1 (en) * | 2016-02-26 | 2020-06-09 | Allscripts Software, Llc | Computing system for presenting supplemental content in context |
US20130144647A1 (en) * | 2011-12-05 | 2013-06-06 | Mitch Ellingson | Method and system for dental enterprise resource planning |
US9678956B2 (en) * | 2012-02-17 | 2017-06-13 | Kno2 Llc | Data capturing and structuring method and system |
CN106169099A (en) * | 2012-08-01 | 2016-11-30 | 优菲米特有限责任公司 | User interface for analyte monitoring system |
US9782075B2 (en) | 2013-03-15 | 2017-10-10 | I2Dx, Inc. | Electronic delivery of information in personalized medicine |
US11089959B2 (en) | 2013-03-15 | 2021-08-17 | I2Dx, Inc. | Electronic delivery of information in personalized medicine |
US20140358009A1 (en) * | 2013-05-30 | 2014-12-04 | Michael O'Leary | System and Method for Collecting Eye-Movement Data |
US9304761B2 (en) * | 2013-06-12 | 2016-04-05 | Nuesoft Technologies, Inc. | System and method for collaborative programming of data entry workflows between system developers, end users, and third party developers |
US10116752B2 (en) * | 2013-09-17 | 2018-10-30 | Karos Health Incorporated | System and method for bridging divergent information networks |
US20150100349A1 (en) * | 2013-10-07 | 2015-04-09 | ZirMed, Inc. | Untethered Community-Centric Patient Health Portal |
WO2015066656A1 (en) * | 2013-11-01 | 2015-05-07 | Evariant, Inc. | Claims data anonymization and aliasing analytics apparatuses, methods and systems |
WO2016020935A2 (en) * | 2014-08-07 | 2016-02-11 | Abhijit Manohar Gupta | A one screen multi-fold gesture based, interactive time-line view based, relationship management system and method |
US10846424B2 (en) | 2014-09-05 | 2020-11-24 | Medidata Solutions, Inc. | Method for multi-tiered, rule-based data sharing and ontology mapping |
US20160092401A1 (en) * | 2014-09-30 | 2016-03-31 | Jeffrey O'Connor | Document Generation Methods and Systems |
CN104463755A (en) * | 2014-10-20 | 2015-03-25 | 深圳市前海安测信息技术有限公司 | Two-way hospital referral system, method and platform |
US20150149362A1 (en) * | 2015-02-04 | 2015-05-28 | vitaTrackr, Inc. | Encryption and Distribution of Health-related Data |
US10891383B2 (en) | 2015-02-11 | 2021-01-12 | British Telecommunications Public Limited Company | Validating computer resource usage |
US20150161413A1 (en) * | 2015-02-16 | 2015-06-11 | vitaTrackr, Inc. | Encryption and distribution of health-related data |
JP6596879B2 (en) * | 2015-03-31 | 2019-10-30 | 富士通株式会社 | Data format creation support program for clinical trials, data format creation support method for clinical trials, and information processing apparatus |
US20160342746A1 (en) * | 2015-05-21 | 2016-11-24 | Naveen Sarabu | Cloud-Based Medical-Terminology Manager and Translator |
US10956614B2 (en) | 2015-07-31 | 2021-03-23 | British Telecommunications Public Limited Company | Expendable access control |
US11347876B2 (en) | 2015-07-31 | 2022-05-31 | British Telecommunications Public Limited Company | Access control |
US10853750B2 (en) | 2015-07-31 | 2020-12-01 | British Telecommunications Public Limited Company | Controlled resource provisioning in distributed computing environments |
US10257277B2 (en) | 2015-08-11 | 2019-04-09 | Vocera Communications, Inc. | Automatic updating of care team assignments in electronic health record systems based on data from voice communication systems |
CN109874340B (en) | 2015-11-18 | 2023-06-13 | 全球样本解决方案股份有限公司 | Distributed system for secure storage and retrieval of encrypted biological specimen data |
CN105530318A (en) * | 2016-01-15 | 2016-04-27 | 深圳市智慧健康产业发展有限公司 | Dynamic gene monitoring service platform having gene accurate service |
US10257174B2 (en) * | 2016-01-20 | 2019-04-09 | Medicom Technologies, Inc. | Methods and systems for providing secure and auditable transfer of encrypted data between remote locations |
EP3437007B1 (en) | 2016-03-30 | 2021-04-28 | British Telecommunications public limited company | Cryptocurrencies malware based detection |
WO2017167550A1 (en) * | 2016-03-30 | 2017-10-05 | British Telecommunications Public Limited Company | Blockchain state reliability determination |
WO2017167545A1 (en) | 2016-03-30 | 2017-10-05 | British Telecommunications Public Limited Company | Network traffic threat identification |
WO2017167544A1 (en) | 2016-03-30 | 2017-10-05 | British Telecommunications Public Limited Company | Detecting computer security threats |
WO2017167548A1 (en) | 2016-03-30 | 2017-10-05 | British Telecommunications Public Limited Company | Assured application services |
WO2017167549A1 (en) | 2016-03-30 | 2017-10-05 | British Telecommunications Public Limited Company | Untrusted code distribution |
US10331416B2 (en) | 2016-04-28 | 2019-06-25 | Microsoft Technology Licensing, Llc | Application with embedded workflow designer |
JP6742857B2 (en) * | 2016-08-16 | 2020-08-19 | キヤノン株式会社 | Information processing system, information processing method, and program |
CA3049412A1 (en) | 2017-01-05 | 2018-07-12 | Spear Education, Llc | Systems and methods for dental practice planning and management |
EP3382591B1 (en) | 2017-03-30 | 2020-03-25 | British Telecommunications public limited company | Hierarchical temporal memory for expendable access control |
WO2018178034A1 (en) | 2017-03-30 | 2018-10-04 | British Telecommunications Public Limited Company | Anomaly detection for computer systems |
US11586751B2 (en) | 2017-03-30 | 2023-02-21 | British Telecommunications Public Limited Company | Hierarchical temporal memory for access control |
WO2018206406A1 (en) | 2017-05-08 | 2018-11-15 | British Telecommunications Public Limited Company | Adaptation of machine learning algorithms |
US11823017B2 (en) | 2017-05-08 | 2023-11-21 | British Telecommunications Public Limited Company | Interoperation of machine learning algorithms |
WO2018206408A1 (en) | 2017-05-08 | 2018-11-15 | British Telecommunications Public Limited Company | Management of interoperating machine leaning algorithms |
WO2019025015A1 (en) * | 2017-08-04 | 2019-02-07 | Clinerion Ltd. | Patient recruitment system |
US11636455B2 (en) * | 2018-07-12 | 2023-04-25 | Inbox Health Corp. | Intelligent patient billing communication platform for health services |
US20210232705A1 (en) * | 2018-07-13 | 2021-07-29 | Imagia Cybernetics Inc. | Method and system for generating synthetically anonymized data for a given task |
EP3824386B1 (en) | 2018-07-17 | 2024-02-21 | ICU Medical, Inc. | Updating infusion pump drug libraries and operational software in a networked environment |
ES2962660T3 (en) * | 2018-07-17 | 2024-03-20 | Icu Medical Inc | Systems and methods to facilitate clinical messaging in a network environment |
KR102139180B1 (en) * | 2019-07-11 | 2020-07-29 | (주)레몬헬스케어 | Method and system for providing insurance requesting system based on cloud computing |
US11495337B1 (en) * | 2019-12-12 | 2022-11-08 | Allscripts Software, Llc | Computing system for full textual search of a patient record |
US11562080B2 (en) * | 2020-05-08 | 2023-01-24 | International Business Machines Corporation | Secure ingress and egress of data fields through legacy computer systems |
US11824937B2 (en) | 2021-04-04 | 2023-11-21 | Rissana, LLC | System and method for handling the connection of user accounts to other entities |
US20230045394A1 (en) * | 2021-08-06 | 2023-02-09 | AndorHealth, LLC | Virtual care systems and methods |
US20230039151A1 (en) * | 2021-08-09 | 2023-02-09 | Wellscape LLC | Digital Healthcare Tracking and Coordination for Family and Friends |
US11757823B2 (en) * | 2021-08-20 | 2023-09-12 | Salesforce, Inc. | Electronic mail authentication and tracking in database system |
US11875905B1 (en) | 2023-03-08 | 2024-01-16 | Laura Dabney | Salubrity retention system using selective digital communications |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5579393A (en) * | 1994-06-21 | 1996-11-26 | Escan, Inc. | System and method for secure medical and dental record interchange |
US20050010443A1 (en) * | 2003-05-14 | 2005-01-13 | Clinilabs, Inc. | Methods for online clinical trial recruiting |
US20050159983A1 (en) * | 2004-01-16 | 2005-07-21 | Sullivan Robert J. | Rules-based health care referral method and system |
US20050209893A1 (en) * | 2004-03-18 | 2005-09-22 | Nahra John S | System and method for identifying and servicing medically uninsured persons |
US20070083403A1 (en) * | 2004-03-26 | 2007-04-12 | Crystallon Systems, Inc. | Referral management method, apparatus and system |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6196970B1 (en) * | 1999-03-22 | 2001-03-06 | Stephen J. Brown | Research data collection and analysis |
US7877694B2 (en) * | 2003-12-05 | 2011-01-25 | Microsoft Corporation | Hosted notifications templates |
US8000977B2 (en) * | 2004-03-11 | 2011-08-16 | Healthcare Charities, Inc. | System and method to develop health-care information systems |
US20050209990A1 (en) * | 2004-03-18 | 2005-09-22 | Ordille Joann J | Method and apparatus for a publish-subscribe system with access controls |
US8275850B2 (en) * | 2004-05-05 | 2012-09-25 | Ims Software Services Ltd. | Multi-source longitudinal patient-level data encryption process |
US7970813B2 (en) * | 2004-10-08 | 2011-06-28 | Sharp Laboratories Of America, Inc. | Methods and systems for imaging device event notification administration and subscription |
US7438233B2 (en) * | 2005-01-24 | 2008-10-21 | Shepherd Medical Solutions Llc | Blinded electronic medical records |
US7665098B2 (en) | 2005-04-29 | 2010-02-16 | Microsoft Corporation | System and method for monitoring interactions between application programs and data stores |
KR101473337B1 (en) * | 2007-10-01 | 2014-12-16 | 삼성전자 주식회사 | Method and Appartus for providing interface compatibility based on a component model |
US10438694B2 (en) * | 2007-11-19 | 2019-10-08 | Medicalis Corporation | Management of medical workflow |
US20090180398A1 (en) * | 2008-01-16 | 2009-07-16 | Sony Corporation, A Japanese Corporation | Method and apparatus for facilitating interaction between the services provided by respective networked devices |
US20110077965A1 (en) * | 2009-09-25 | 2011-03-31 | Cerner Innovation, Inc. | Processing event information of various sources |
US20120215560A1 (en) * | 2010-07-21 | 2012-08-23 | dbMotion Ltd. | System and methods for facilitating computerized interactions with emrs |
-
2011
- 2011-10-24 US US13/280,290 patent/US20120101843A1/en not_active Abandoned
- 2011-10-24 US US13/280,292 patent/US20120101849A1/en not_active Abandoned
- 2011-10-24 CA CA2815487A patent/CA2815487A1/en not_active Abandoned
- 2011-10-24 CN CN2011800612943A patent/CN103339605A/en active Pending
- 2011-10-24 US US13/280,287 patent/US8661453B2/en active Active
- 2011-10-24 WO PCT/US2011/057535 patent/WO2012054932A2/en active Application Filing
-
2014
- 2014-02-03 US US14/171,655 patent/US8990834B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5579393A (en) * | 1994-06-21 | 1996-11-26 | Escan, Inc. | System and method for secure medical and dental record interchange |
US20050010443A1 (en) * | 2003-05-14 | 2005-01-13 | Clinilabs, Inc. | Methods for online clinical trial recruiting |
US20050159983A1 (en) * | 2004-01-16 | 2005-07-21 | Sullivan Robert J. | Rules-based health care referral method and system |
US20050209893A1 (en) * | 2004-03-18 | 2005-09-22 | Nahra John S | System and method for identifying and servicing medically uninsured persons |
US20070083403A1 (en) * | 2004-03-26 | 2007-04-12 | Crystallon Systems, Inc. | Referral management method, apparatus and system |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11557396B2 (en) | 2010-09-29 | 2023-01-17 | Humana Inc. | Electronic medical record exchange |
US20120253844A1 (en) * | 2011-03-30 | 2012-10-04 | Mckesson Financial Holdings | Apparatus, method and computer-readable storage mediums for providing a context-sensitive alert regarding a multimedia object |
US20130275361A1 (en) * | 2012-04-17 | 2013-10-17 | Cerner Innovation, Inc. | Associating multiple data sources into a web-accessible framework |
US9026531B2 (en) * | 2012-04-17 | 2015-05-05 | Cerner Innovation, Inc. | Associating multiple data sources into a web-accessible framework |
US11107015B2 (en) * | 2012-05-08 | 2021-08-31 | Drfirst.Com, Inc. | Information exchange system and method |
US20130304510A1 (en) * | 2012-05-08 | 2013-11-14 | Drfirst.Com, Inc. | Health information exchange system and method |
US20170235890A1 (en) * | 2012-05-08 | 2017-08-17 | Drfirst.Com, Inc. | Information exchange system and method |
US20160300018A1 (en) * | 2013-11-28 | 2016-10-13 | Agfa Healthcare Nv | A method and computer program product for management of the distribution of medical reports in clinical application |
US11107576B2 (en) | 2014-04-07 | 2021-08-31 | Imprivata, Inc. | Coordinating communications among healthcare providers |
US10332625B2 (en) | 2014-04-07 | 2019-06-25 | Imprivata, Inc. | Coordinating communications among healthcare providers |
US11636946B2 (en) | 2014-04-07 | 2023-04-25 | Imprivata, Inc | Coordinating communications among healthcare providers |
US11114194B2 (en) | 2015-10-01 | 2021-09-07 | Audacious Inquiry | Network-based systems and methods for providing readmission notifications |
US11133088B2 (en) * | 2016-11-18 | 2021-09-28 | International Business Machines Corporation | Resolving conflicting data among data objects associated with a common entity |
US20180144095A1 (en) * | 2016-11-18 | 2018-05-24 | International Business Machines Corporation | Resolving conflicting data among data objects associated with a common entity |
Also Published As
Publication number | Publication date |
---|---|
CA2815487A1 (en) | 2012-04-26 |
US20140215490A1 (en) | 2014-07-31 |
US8990834B2 (en) | 2015-03-24 |
WO2012054932A2 (en) | 2012-04-26 |
US20120102502A1 (en) | 2012-04-26 |
US8661453B2 (en) | 2014-02-25 |
US20120101843A1 (en) | 2012-04-26 |
WO2012054932A3 (en) | 2012-09-20 |
CN103339605A (en) | 2013-10-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8990834B2 (en) | Managing healthcare information in a distributed system | |
JP5377494B2 (en) | Healthcare semantic interoperability platform | |
US8301462B2 (en) | Systems and methods for disease management algorithm integration | |
US8380631B2 (en) | Communication of emergency medical data over a vulnerable system | |
US7974924B2 (en) | Medical data encryption for communication over a vulnerable system | |
US8788287B2 (en) | Systems, apparatus, and methods for developing patient medical history using hierarchical relationships | |
CA2657614C (en) | Method and system for remote review of clinical data | |
US20180294048A1 (en) | Patient-centric portal | |
US20110125527A1 (en) | Systems, apparatus, and methods for identifying patient-to patient relationships | |
US20100082369A1 (en) | Systems and Methods for Interconnected Personalized Digital Health Services | |
US20130054678A1 (en) | Data collection form authoring system with remote client data collection and management system | |
US10467699B2 (en) | System and method for conveying and processing personal health information | |
US20150234984A1 (en) | Patient-Centric Portal | |
US20140136236A1 (en) | Patient and physician gateway to clinical data | |
US20120239413A1 (en) | Sending Healthcare Information Securely | |
Bouhaddou et al. | Toward a virtual lifetime electronic record: the department of veterans affairs experience with the nationwide health information network | |
US20090204439A1 (en) | Apparatus and method for managing electronic medical records embedded with decision support tools | |
US20150039338A1 (en) | Digital and computerized information system to access contact and medical history data of individuals in an emergency situation | |
US20060190294A1 (en) | Medispatch: A concept for secure medical communication | |
US20140136234A1 (en) | Method and apparatus for mapping patient created data from external systems to electronic health records | |
Watfa et al. | Computer Based E-Healthcare Clinical Systems: A Comprehensive Survey | |
Mahncke et al. | Secure transmission of shared electronic health records: A review | |
Gargeya et al. | Moving toward an e-hospital | |
Watfa et al. | Healthcare applications for clinicians | |
Simonian | Information Management by Patients and Parents in Health and Disease |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MEDICITY, INC., UTAH Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MATHUR, ALOK;LASSETTER, JAMES K.;PICCOLO, ANDY;AND OTHERS;SIGNING DATES FROM 20111103 TO 20111108;REEL/FRAME:027223/0354 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |