Distributed Computing System to Enable the Secure Exchange of Information Between Remotely Located Healthcare Applications

Abstract

Systems and methods are provided for securely exchanging information between remote computing systems such as electronic medical records in the local healthcare community, enabling interoperabilty and allowing for the synchronization of common information. Some embodiments provide for a type of software “middleware” that autonomously extracts, analyzes and transforms information from computer systems in one location and distributes it to remote location(s) to be further transformed and inserted into one or more remote computer systems. Other embodiments provide for remotely deploying and managing the software programs from a centralized management facility. Other embodiments provide for distributed, object-oriented computing systems that enable a plurality of independent, remotely located computers to interface with each other, extract or insert, format and exchange information with other computers using a secure messaging infrastructure.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. § 119(e) of U.S. provisional patent application No. 60/595,668, entitled “The Secure Exchange of Information Between Remotely Located Healthcare Applications,” filed Jul. 26, 2005, and U.S. provisional patent application No. 60/702,686, entitled “The Secure Exchange of Information Between Remotely Located Healthcare Applications,” filed Jul. 26, 2005, both of which are incorporated herein by reference in their entirety.

REFERENCE TO COMPUTER PROGRAM LISTING SUBMITTED ON CD

This application incorporates by reference the computer program listing appendix submitted on (1) CD-R entitled “Novo Innovations Source Code” in accordance with 37 C.F.R. § 1.52(e). Pursuant to 37 C.F.R. § 1.77(b)(5), the material on said CD-R is incorporated by reference herein, said material being identified as follows:

DATE OF CREATION	SIZE IN BYTES	FILE NAME
Jul. 25, 2006	1,439,318	Novo Innovations Source
		Code.txt
Jul. 25, 2006	19,557	Read Me.txt

The file “Novo Innovations Source Code.txt” includes a complete listing of all source code files on the CD-R assembled into one file. The file “Read Me.txt” includes a summary of all source code files on the CD-R.

Since this application is being filed electronically, the CD-R will be submitted separately in accordance with 37 C.F.R. § 1.52(e) and 37 C.F.R. § 1.96. Additionally, to insure that the source code contents receive the benefit of this filing date, the computer program code is included in Appendix A, entitled “Novo Innovations Source Code,” assembled Jul. 25, 2006, which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The present invention relates generally to distributed computing systems, and more particularly, to securely exchanging information between remote computing systems, enabling interoperability and allowing for the synchronization of common information.

BACKGROUND

There is an increasing use of information technology (IT) by physicians as evidenced by the rapid adoption of a type of computer software, called Electronic Medical Records (EMR), to replace the paper charts in the medical office. The use of EMRs by physicians is expected to become common over the next five to ten years.

Because of the state of the art in communications between providers in the healthcare community, most physicians using an EMR must accept or receive data such as lab results, pathology results, radiology results and transcriptions via faxes or paper couriered from the hospital. The physician must then use their personnel to collect the paper fax, scan it into the EMR, and index the scanned image to a particular patient's record. Cumulatively, the process can take several minutes per fax received.

As these computer systems are adopted, there is an emerging need to receive data from hospitals in an electronic format that can be directly interfaced into the physician EMR. Data standards like ANSI's Health Level 7 (HL7) have evolved to address this need and are used by both hospital and physician-based computer systems.

However, the detailed use of the HL7 standard varies between vendors. This is a well-known problem that led to the emergence of a type of middleware called an “interface engine.”Its purpose was to translate the HL7 messages exchanged between computer systems into the native format of each. This enabled the computer systems to off-load the responsibility of managing each individual interface. Instead, each computer system would only need to manage its connection to the interface engine.

While the interface engines and EAI middleware offer advantages in enterprise settings where all computer systems are accessible via a local area network, the situation presented by EMRs is more complex. EMRs are installed in remote physician practices, are unreachable by computer systems located in hospitals, and support the type of data that tends to be highly confidential and must be secured in the most rigorous manner.

As a result, approaches that leverage middleware technologies like HL7 interface engines must devise their own methods of delivering and securing the data. Several of the approaches currently available are: (1) establish a private network between the hospital and the EMR location, (2) use secure email to deliver the electronic data as an attachment, (3) send the electronic data via a secure website where it can be downloaded and (4) use peer-to-peer technology to enable file sharing.

Each of these approaches has the benefit of leveraging existing technology (e.g. email, web, P2P) and does accomplish the overall goal of getting electronic data from the hospital into the remote EMR. However, there are drawbacks with each approach, such as: (1) building private networks is expensive and difficult to manage as volume rises, and (2) secure email, web and P2P solutions rely on people to run the communication application, e.g., open the email, access the website or pull down the data over the P2P network.

Consequently, a need exists for allowing the electronic data to flow from system to system without involving personnel, or a special network or interface for each remote system encountered.

The preferred embodiment defined herein describes such a system that exhibits characteristics of low cost, simple operation, ease of use, reliability and stability in real-world implementations of the embodiment.

SUMMARY

In response to these and other shortcomings of the prior art, the present invention provides systems and methods for securely exchanging information between remote computing systems such as electronic medical records (EMR) in the local healthcare community, enabling interoperability and allowing for the synchronization of common information. One embodiment provides for a type of software “middleware” that autonomously extracts, analyzes and transforms information from computer systems in one location and distributes it to remote location(s) where it can be further transformed and inserted into one or more remote computer systems.

Another embodiment defines a method for remotely deploying and managing the software programs from a centralized management facility.

Another embodiment provides a middleware solution comprised of distributed, object-oriented computing system that enable a plurality of independent, remotely located computers to interface with each other, extract or insert, format and exchange information with other computers using a secure Internet-based messaging infrastructure.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

FIG. 1 is a block process diagram of the preferred embodiment of an object-based, distributed computer system constructed in accordance with the present invention.

FIG. 2 shows how the embodiment distributes information between a hospital computing environment and remote ambulatory Electronic Medical Records (EMR).

FIG. 3 is a block schematic diagram illustrating the components of a node according to the preferred embodiment of the present invention.

FIG. 4 is a block schematic diagram illustrating the components of a rendezvous server used to interconnect nodes according to the preferred embodiment of the present invention.

FIG. 5 is an exemplary object model showing the abstract class topic and associated objects used in the exchange and persistence of information in accordance with the preferred embodiment.

FIG. 6 illustrates how topic objects can be distributed across a plurality of nodes to create private exchange groups within a broader community.

FIG. 7 is an object model showing the abstract of an instance of the topic class called result, used in the exchange of clinical test results delivered between providers in the community such as hospitals and physicians.

FIG. 8 is an object model showing the abstract of an instance of the topic class called providers and associated objects, used to provide a provider directory in accordance to the present invention.

FIG. 9 is an object model showing the abstract of an instance of the topic class called physician office and associated objects, used to provide physician office information in accordance to the present invention.

FIG. 10 illustrates the payload structure used to securely exchange topic and capsule objects between participating nodes in accordance to the present invention.

FIG. 11 is a block schematic diagram illustrating the asynchronous exchange of information between two nodes using the rendezvous in accordance to the present invention.

FIG. 12 is a block schematic diagram illustrating how payloads are encrypted during an exchange between two nodes through the rendezvous in accordance to the present invention.

FIG. 13 is a block schematic diagram illustrating the results agent connected to a typical hospital information environment, showing the process execution and components to capture and distribute HL7 messages in accordance to the present invention.

FIG. 14 is a block schematic diagram illustrating the results agent in the physician office where the EMR is located, showing the process execution and components to receive, process and insert the HL7 into the EMR, and retrieve process and return the associated HL7 ACK in accordance to the present invention.

FIG. 15 is a block schematic diagram illustrating the remote command functionality of the present invention.

FIG. 16 is an object model showing the abstract of an instance of the topic class called command and associated objects, used to deliver and report command actions in accordance to the present invention.

FIG. 17 is a sequence diagram illustrating the process of listening for, capturing, analyzing and, transforming an HL7 result and generating a topic instance to distribute the result in accordance to the present invention.

FIG. 18 is a sequence diagram illustrating processing of the result topic on the node including packaging it into an encrypted payload and transferring the payload to the rendezvous server in accordance to the present invention.

FIG. 19 is a sequence diagram illustrating the processing of the payload on the rendezvous in accordance to the present invention.

FIG. 20 is a sequence diagram illustrating the process of exchanging the payload between the rendezvous server and the destination node in accordance to the present invention.

FIG. 21 is a sequence diagram illustrating the process of receiving, decrypting and inserting the HL7 message into the EMR in accordance to the present invention.

FIG. 22 is a sequence diagram illustrating the process of capturing an HL7 ACK message from the EMR and adding it to the result topic object in accordance to the present invention.

FIG. 23 is a sequence diagram illustrating the process of returning the HL7 ACK to the hospital as an update to the result topic object in accordance to the present invention.

DETAILED DESCRIPTION

Reference is now made in detail to the description of the embodiments as illustrated in the drawings. The invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are intended to convey the scope of the invention to those skilled in the art. Furthermore, all “examples” given herein are intended to be non-limiting.

The present invention provides systems and methods for a distributed computing system for securely exchanging information between remote computing systems such as Electronic Medical Records (EMR) in the local healthcare community, enabling interoperability and allowing for the synchronization of common information.

FIG. 1 shows an overview of an embodiment of the system 1 comprising a plurality of remotely located sites 6a (Hospital A), 6b (Physician Office 1), 6c (Physician Office 2) and 6d (Physician Office 3). Of course, numerous remotely located sites could exist in addition to those given. Each remotely located site 6a-6d runs distributed computing software called a node 2 on a computer on a local network behind the Internet firewall. nodes support agents 4, classes and methods that enable integration, workflow, storage, management and communications from the local computer, where it can directly access folders and/or interfaces on an application system to achieve directly interoperability.

Computer program code which may be utilized to implement the current invention is included in Appendix A, entitled “Novo Innovations Source Code,” assembled Jul. 25, 2006, which is hereby incorporated by reference in its entirety. Further explanation for implementing and utilizing an embodiment of the system is included in Appendix B, entitled “Novo Grid Technical Brief,” assembled Jul. 20, 2006, which is hereby incorporated by reference in its entirety.

Nodes are interconnected through an Internet-based rendezvous server 3. The rendezvous server (RS) serves as a “post office” that receives encrypted payloads of information from nodes, processes the payloads and puts copies of the payloads into dedicated queues (one for each node registered on the system). Each node makes an attempt to connect to the RS on a regular basis to upload information that needs to be distributed and download information sent from other nodes stored in its dedicated queue on the RS. Nodes manage information through a class of topic 5 objects. Instances of this class, called topics, provide attributes and methods to create, structure, distribute and synchronize information between nodes.

Nodes provide an operating environment for agents 4, which can interface to local environments, extract, parse, analyze and transform data into the desired format, then create or modify topic objects and securely distribute the objects to other nodes via the RS.

The preferred embodiment enables a physician located in a remote office to receive electronic results from the hospital information systems automatically and have the information put directly into the EMR in a format acceptable to the EMR.

FIG. 2 shows an overview of the embodiment in a typical use case. Hospital A uses the system to distribute information like lab test results and reports, discharge summaries, and surgical notes from the hospital system 7 typically through an ANSI ‘Health Level 7’ (HL7) Interface Engine, to the EMR 8 system located at site 6b, Physician Office 1.

Node A is installed on a computer on Hospital A's local area network, behind the Internet firewall. The hospital node supports a results agent 9 that is connected via configurable TCP port to the hospital system 7. The results agent runs a thread that listens for HL7 messages on the configured port and processes the messages as they are received.

The results agent parses the received HL7 text string into objects and filters the objects based on the values of data within the HL7 message such as message type, patient type, ordering provider, etc. The results agent can further process the information according to specified rules, such as: (1) mapping data from one format to another, (2) adding information not present in the original HL7, (3) removing or modifying data from the original HL7 and discarding duplicates and/or acting on changes in status, e.g., preliminary to final.

Once the HL7 message has been captured and transformed, the results agent creates a result topic 10 object, streams the HL7 message into the object and adds routing and management information to the topic attributes. The routing and management information includes which physician office node the result should go to, and which agent to call when the object reaches its destination.

After the topic object has been created and saved, the results agent initiates distribution of the topic. The initiation streams the topic into a payload structure and encrypts it for transmission to the RS. Threads running with the node establish an SSL session with the RS to upload the payload over the HTTP/S 11 protocol.

A payload processor 12 application receives and examines the payload to determine which nodes should receive a copy of the payload. The sorter then puts a copy of the payload into Node B's node queue 13.

Node B runs a thread that regularly connects to the rendezvous server to check its node queue for new payloads. During the next polling interval, Node B downloads the newly deposited payload, extracts the result topic 10 and calls the results agent 9. The results agent opens the topic object, extracts the information, analyzes, further transforms the HL7 if required and saves the topic object on the node. The results agent also extracts the HL7 from the topic and copies it into a folder or TCP socket on the EMR 8 where it can be processed by the EMR's interface logic.

In real world scenarios, the EMR's interface will issue an HL7 ACK message, indicating the status of the message processing. The ACK message is deemed critical audit information required by the hospital to satisfy security regulations. The preferred embodiment addresses this need using the same mechanisms described above.

The results agent 9 running on Node B runs a thread that examines a folder or listens on a TCP port for an HL7 ACK message from the EMR. When acquired, the results agent opens, parses and examines the HL7 ACK to match it with a result topic object that contains the original HL7 result message. Once located, the results agent adds the new HL7 ACK string to the result topic and initiates a distribution of the updated part of the topic.

To distribute the topic, the agent passes topic or capsule data to the node, which supports mechanisms to create, encrypt, and upload the payload to the rendezvous. The payload is uploaded to the rendezvous via HTTP/S in the manner describe previously. The payload processor 12 receives the new payload, examines its attributes to determine which nodes should receive a copy (in this case, Node A), and puts a copy into the appropriate node queue 14.

Node A, also regularly connecting to the rendezvous, downloads the payload from its node queue 14, decrypts it and passes it to the results agent identified in the payload attributes, which can add the ACK to its stored copy of the result topic, thereby creating the audit trail needed by the hospital.

This describes the basic mechanisms used by the preferred embodiment to synchronize the topic objects between nodes using the RS. As described, the preferred embodiment provides the key mechanisms necessary to extract, analyze, transform, secure, distribute, process and insert information from one system to a remote system or systems using the Internet as a transport medium.

A node, as defined in the preferred embodiment, is a distributed operating platform that enables agents to execute in a remote environment, interfacing to local systems, and processing and exchanging information with other agents running on other nodes.

Each instance of a node is assigned a unique ID and other attributes when it is initially defined that enables it to collaborate with other nodes.

Every node contains the following: (a) application server, (b) data storage mechanism, (c) secure communications mechanisms, (d) application utilities and methods and (e) management tools and services

Now referring to FIG. 3, the detail behind the node is described below.

The core functionality of the node is provided through an application server 15. The Application server runs on a computer hosting the node 24. The application server provides the mechanisms to compile and execute node applications.

Agents 4 provide key functions that execute on the node such as: (a) integration to local applications for the purpose of processing and exchanging information with other agents running on other node, and (b) management applications providing the functionality to enable the node and agents to be remotely configured and managed.

As it relates to exchanging information, each node provides the following:

• (1) A payload generator 23 that streams objects into payloads and creates the payload attributes that identifies destination nodes participating in the topic and which agent(s) should be evoked when the payload is received. The payload generator also includes mechanisms for encrypting payload data using a combination of symmetric and asymmetric keys that can only be decrypted by a receiving node.
• (2) A rendezvous queue 20 that holds encrypted payloads for distribution to a rendezvous.
• (3) An uploader 22 mechanism that connects to the rendezvous to upload payloads found in the rendezvous queue.
• (4) A DownLoader 21 mechanism that regularly connects to the rendezvous to download payloads from its node queue.
• (5) An Inbox 19 that holds encrypted payloads retrieved by the DownLoader.
• (6) An Inbox Sorter 18 that processes payloads found in the Inbox including decrypting and evoking the Agent identified in the payload attributes.

In addition to the communications functions, nodes also provide other functions:

• (7) A topic warehouse 16 is a class that stores topic objects locally on the node. The topic warehouse provides the methods used by Agents to create, update and remove topic objects. topics are physically stored in a file folder located on the host computer's file system.
• (8) The node warehouse 17 class is used to maintain definition objects for each node registered with the rendezvous. The node's definition object includes elements like its unique ID and its public encryption key.

It should be noted that each node generates an asymmetric (public/private) pair of keys when it is first created to use in encrypting and decrypting payloads. The node keeps the private key and distributes a copy of its public key by putting it in its definition object. The definition object is distributed to all other nodes registered with the rendezvous and stored in their respective node warehouses.

Additionally, the node warehouse is updated each time a new node is registered or an existing one modified on the rendezvous server.

The node components operate together to enable an automated exchange process: (1) If an Agent creates a topic object, it uses the node warehouse 17 to find the IDs of the nodes that participate in the topic. It adds the IDs to the topic object's attributes and passes the topic to the Payload Generator 23. (2) If an Agent sends a topic object to another Agent, it passes the topic object to the Payload Generator 23. The topic object's attributes include the ID's of participating nodes, the ID of Agent that sent the topic, and the ID of the Agent that should receive the topic. (3) The Payload Generator 23 examines the topic attributes to create a new payload. It encrypts the payload data (described in detail later), streams the encrypted data into the payload, and adds the node ID to the payload attributes. Once the payload is created, the Payload Generator saves the encrypted payload into the rendezvous queue 20. (4) An Uploader 22 thread scans, at a configurable interval, the rendezvous queue 20 for new payloads deposited by the Payload Generator 23. Once discovered, the UpLoader establishes an HTTP/S session with the rendezvous and streams the payload over HTTP/S. The UpLoader deletes the payload from the rendezvous queue once the rendezvous has acknowledged successful receipt. (5) The node also runs a process thread called a DownLoader 21. The DownLoader attempts to establish an SSL session with the rendezvous at a configurable interval to check for new payloads. Any payloads present are downloaded and stored in a folder on the node called the Inbox 19. (6) The Inbox Sorter 18 regularly scans the Inbox for payloads received from the rendezvous. The Inbox Sorter read a payload from the Inbox, decrypts the payload using the node's asymmetric private key, examines the payload to determine which Agent to invoke, extracts the payload topic data and passes it to the identified Agent for processing.

The rendezvous is a node running the rendezvous application on a computer accessible from the Internet. It enables the secure, asynchronous exchange of payloads between nodes. All communication with the rendezvous is done using the HTTPS protocol. A x.509 security certificate from a recognized certificate authority (CA) is installed on the rendezvous to enable the SSL handshake with the node's uploader and downloader. The rendezvous uses the node's assigned asymmetric private key (described later) to authenticate the node.

The rendezvous honors requests from recognized nodes to upload and download payloads.

FIG. 4 illustrates the components of the rendezvous in more detail.

The node queues 29 are managed by the rendezvous. When a node is first exchanges payloads with the rendezvous, the rendezvous generates a unique node queue for the node.

The receive payload servlet 26 is a thread invoked by the node uploader when it uploads payloads to the rendezvous. The servlet receives payloads over HTTP/S and passes them to the payload processor.

A payload processor 12 receives payloads from the receive payload servlet. It examines the payload attributes to determine the IDs of nodes that are listed in the payload. For each node listed in the payload, the payload processor puts a copy of the payload in that node's node queue.

The payload processor 12 also services requests from nodes for the payloads from their respective node queues.

The send payload servlet 27 is a process invoked by node downloader to download payloads from its node queue. It processes requests from nodes for the contents of their respective node queue.

Information Architecture—Topics

Nodes exchange information using an object class called topic 5, illustrated in FIG. 5. The topic 5 structure provides a means of creating and distributing replicas of the topic to a plurality of nodes where it is persisted in each node's respective topic warehouse. Data within the topic attributes 32 provides the information needed by the system to structure, address and distribute payloads to participating nodes, including: (1) the unique ID of the topic, (2) a list of topic participants and the ID's of the nodes supporting the participants, (3) the topic creation date, (4) the date and time the topic was last modified, (5) a brief description of the topic, (6) topic type designator and (7) the name of the application that processes the topic.

Topic classes are comprised of objects called capsules 33. Each capsule contains its own attributes that identify the capsule and enables the control of visibility of topic data between topic participants. Capsules provide methods to create, update, modify and remove data contained in the capsule.

The preferred embodiment enables any type of digital information to be streamed into a capsule object and distributed between nodes identified as participants in the topic attributes.

The distribution of topic objects to a plurality of nodes creates an environment whereby private exchanges between select groups of participants can be enabled.

FIG. 6 illustrates the concept using six nodes, labeled A through F respectively. Each node's topic warehouse contains only those topics to which the node is a participant. In particular, “Topic 1” 34 is distributed between Nodes A, C, and D. “Topic 2” 35 is distributed between Nodes B, C and F. “Topic 3 36 is distributed between Nodes B and E.

Every time a topic is updated by an agent on a particular node, the agent has the ability to initiate the distribution of the updates to the other agents participating in the topic. If an agent running on Node A updates Topic 1 and initiates its distribution, Nodes C and D will be automatically updated with the new information as soon as they process the payloads from the rendezvous. Conversely, if an agent running on Node D was to update Topic 1 and initiate an update, nodes A and C would automatically receive the update, effectively remaining synchronized.

Topics can be used for many purposes to suit various needs. For exchange and interoperability between healthcare applications like EMR's, three specific topics are defined; a result topic 37 for the clinical information, a provider topic 43 (see FIG. 8) that provides a list of physicians that can receive information, and a physician office definition topic 45 (see FIG. 9) that provides detailed information about a particular physician office, the local physicians and applications.

FIG. 7 illustrates a result topic that has common use in healthcare. The result topic 37 can be used to exchange an HL7 message that originated in one organization (e.g. the hospital) to another organization (e.g. the physician).

The Result topic consists of several Capsules. (1) An HL7 Capsule 39 containing the name of the originating department and the processed HL7 text string as rendered by the results agent. (2) An Original HL7 Capsule 39 that contains the order ID, test type, sending system name, and originating department. It also includes the original HL7 text string. (3) A doctor capsule 40 contains information about the ordering physician in the HL7 message including name, ID of the node representing the physician, and the unique doctor ID used by the hospital to identify the physician in the HL7 messages. (4) A patient capsule 41 contains information on the patient in the HL7 message including name, date of birth, gender, social security number, and patient class (e.g. inpatient, outpatient, etc.). (5) An audit capsule 42 for the audit of events affecting the topic (issued, transported, receive, processed) and the HL7 ACK message returned by the receiving EMR or system.

The result topic attributes contain the basic information needed to distribute to topic to participating nodes. In the example in FIG. 7, the list of participants could include as few a two participants—the source participant (the hospital) and the destination participant (the ordering physician).

The topic could also be expanded to include other participants such as consulting physicians or the patient by replicating the topic to the respective nodes by adding the participant and node ID's to the topic attributes.

The provider topic 43 illustrated in FIG. 8 is an instance of the topic class that provides a directory of physicians configured to receive information. The attributes of the provider topic include the topic ID, the list of topic participants, creation and last modified dates, description and topic type “providers.”

The provider topic is comprised of an instance of a capsule object for each doctor that uses the embodiment to receive results. Specifically, each doctor capsule 44 contains the name of the physician and the ID of the physician office topic to provide additional information needed by the rResult application to process and distribute results.

The physician office topic 45, illustrated in FIG. 9, is an instance of the topic class that provides detail relative to the provider office including filtering, processing, transformation and delivery information.

The physician office topic is comprised of very specific capsule objects: (1) The office nfo capsule 46 provides general information relative to the office including name, node ID, office ID, office type, office description and special filter maps that instruct the results agent how to process HL7 messages for that particular office. (2) The doctors capsule 47 includes a list of physicians, physician assistants, nurses and others in the office along with their respective ID's that may receive results. (3) The filters capsule 48 provides specific data used by the results agent to transform the HL7 into the proper format for the receiving EMR. Filters for laboratory, radiology, pathology, and dictated reports are included. (4) As new agents and functions are added over time, the preferred embodiment, through expansion of the physician office topic to include future capsules 49, can be created and added to the topic to enable the configuration and execution of new agents and programs on the node in the particular office.

Distributing topic and capsule updates between codes over the infrastructure is done using a special payload structure designed to facilitate the secure, asynchronous routing of information between nodes via the rendezvous.

FIG. 10 depicts the payload structure of the preferred embodiment. The topic payload 50 is a serialized object that contains unique information to enables the rendezvous server to sort and queue the payloads for the destination nodes.

The node's payload generator 23 provides mechanisms to generate a payload consisting of the following elements: (a) a unique payload ID 51, (b) the payload type 52—topic or capsule payload, command payload, management payload, (c) the list of destination nodes 53, (d) processor ID 54—the name of the application that processes the payload, (e) payload key 55—a unique, symmetric key used to encrypt and decrypt the payload and (f) payload topic or single capsule 56—the topic or capsule data contained in the payload.

The payload can consist of information like a new topic or a topic update (e.g. new participants added to an existing topic). The payload can also consist of single capsules.

FIG. 11 illustrates a functional diagram that shows the exchange of a topic payload between nodes A and B via the rendezvous.

The process begins when an agent 4 running on node A, needs to send a topic or capsule to the agent running on node B. Before distributing the topic, the agent first saves a copy of the topic in its local topic warehouse 16. Next, it passes the topic to the payload generator 23, which generates a payload: (1) it first gets the list of participating node IDs from the topic attributes, (2) it searches the node warehouse to find the node definition for each node in the topic to use in encrypting the payload, (3) it encrypts the topic and streams the encrypted data into a payload, (4) it adds attributes to the payload to enable the rendezvous and receiving node to process it and (5) it saves the new payload in the rendezvous queue 20.

The uploader 22 running on Node A runs a thread that scans the contents of the rendezvous queue for new payloads. When the payload is discovered, the uploader establishes an SSL session with the rendezvous' receive payload servlet 26 to stream the encrypted payload over HTTP/S (SSL).

The rendezvous receive payload servlet accepts the payload and returns an acknowledgement to the Node A's uploader, acknowledging the receipt of the payload. Upon receiving the acknowledgement, Node A deletes the payload from its rendezvous queue.

The receive payload servlet next passes the payload to the rendezvous payload processor 12 for processing. The payload processor runs a thread that examines the payload attributes to determine the participating nodes that must receive a copy of the payload. It then creates a copy of the payload and puts it into the node queue of each destination (Node B in this example).

The downloader 21 running on Node B runs a thread that routinely connects to the rendezvous send payload servlet 27 via SSL to request payloads from its node queue. The servlet forwards the request for the contents of the node queue to the payload processor. The payload processor returns the contents of Node B's node queue that includes the new payload sent from Node A. It streams the payload to Node B's DownLoader over HTTP/S. Once received, the downloader saves the payload into the Inbox 19.

The inbox sorter 18 running on Node B reads the payload from the Inbox 19 and decrypts the payload. It examines the topic attributes to determine the agent that needs to be evoked to process the topic and passes the topic to that agent.

The agent that processes the topic examines the topic and takes action based on programmed rules. In the case of a new topic, It can add the topic to its local topic warehouse 16. If it is a capsule for an existing topic, it can find the existing topic and add the new capsule.

The system uses a method of encrypting payloads that combines elements of k asymmetric and symmetric encryption mechanisms with SSL.

FIG. 12 illustrates the components and processes involved in encrypting the payload as it is distributed via the rendezvous.

Before describing the process, it is necessary to describe how the nodes and rendezvous are setup. All nodes generate a unique asymmetric key pair when they are first created. The private key 57 is stored by the node. The public key 58 is distributed to all nodes via the node's definition topic distributed to all nodes and stored in their respective node warehouses. This allows nodes to use the public and private keys to encrypt and decrypt data following prior art in the areas of public key infrastructures (PKI) as it relates to encryption and digital signatures.

When creating a payload, the payload generator generates a unique 2048-bit AES symmetric key called the payload key 59. This key is used to encrypt the topic data in the payloads.

As diagrammed in FIG. 12, the payload generator 16 creates a payload to distribute the topic to participating nodes. It is secured using the following sequence of events: (1) At event 60 Node A creates a payload including attributes for distributing the payload to a list of participating Nodes. (2) At event 61 Node A next generates as payload key and uses it to encrypt the topic data. (3) at event 62 the payload generator then finds the public key for each participating node in its node warehouse (part of the node definition topic). For each participating Node, the Payload Generator encrypts a copy of the payload key with that node's public key and adds it to an array of encrypted keys. (4) At event 63, the payload attributes, encrypted topic data, and array of encrypted payload keys are streamed into the payload and saved in Node A's rendezvous queue 20.

Node A's uploader establishes and maintains a one-way SSL thread with the rendezvous. It gets the payload from the rendezvous queue and streams it over HTTP/S to the rendezvous receive payload servlet 26.

The payload servlet passes the payload to the rendezvous payload processor 12.

The payload processor examines the payload attributes for the IDs of the participating nodes 64. For each participating node 65, the payload processor creates a copy of the payload and removes all of the encrypted payload keys from the array except the one encrypted with the public key of that particular node and saves the payload with the single encrypted key in that node's node queue 29.

Node B's downloader runs a thread that regularly connects to the rendezvous send payload servlet to request payloads from its node queue. The servlet passes the request to the payload processor 66, which gets the payload from the node's node queue 67. The payload processor passes the payloads found in the node queue to the send payload servlet, which streams the encrypted payloads to Node B's downloader 21 over HTTP/S.

Node B's downloader saves the payload in its Inbox 19.

The Inbox Sorter 16 running on Node B performs the following operations: (1) it reads the payload from the inbox 68, (2) it uses Node B's private key to decrypt the payload key 69 and (3) it uses the payload key 69 to decrypt the topic object.

Once decrypted, the inbox sorter can pass the topic to the appropriate agent listed in the topic attributes. Nodes use the process described for all exchanges.

The process defined in the embodiment ensures that data is encrypted from the time it is sent from the sending agent to the time it is received by the participating agents. Furthermore, the payloads can only be decrypted by the participating nodes.

Software Agents

The preferred embodiment provides a platform for autonomous software agents that execute on the node.

Agents use topics as a way of managing and persisting “conversations” as they collaborate on particular tasks. For example: (1) agents can create topics and distribute them to participating nodes it desires to collaborate with by defining the participant nodes in the topic attributes and casting the topic to all participants via the rendezvous, (2) agents have complete control over what a topic is and how it is used—requiring only the topic capsule and capsule structure, (3) they can read, write, remove, and modify data in the topic capsules, (4) they can distribute, update, and delete topics and (5) they can be called whenever a payload containing the agent's ID is received.

This abstracts the underlying complexities involved with storing, securing, communicating, and managing the distribution of information from the agent's perspective.

The Results Agents defined in the improvement is used to interface to Electronic Medical Records (EMR) systems to put formatted HL7 into the EMR's Inbox folder and listens for an HL7 acknowledgement from the EMR to return to the source node as an audit.

Results Agent

Many healthcare information systems including EMR's use an ANSI standard for data exchange called HL7 (Health Level 7). This standard defines a message structure for common medical transactions like ordering tests and receiving results.

The results agent 9 provides mechanisms to capture, parse, analyze, transform, distribute, and insert HL7 messages between remotely located healthcare information systems like Electronic Medical Records and hospital information systems. Because the results agent is a distributed application, it is best understood from the perspective of what functions execute on which nodes.

FIG. 13 and FIG. 14 illustrate the results agent. It is comprised of three mechanisms that enable it to capture and transform, receive and insert, and to audit the exchange. The illustrations provide a logical block diagram that shows the results agent from the perspective of which mechanisms execute on a hospital node and which execute on a physician office node.

FIG. 13 depicts the results agent 9 in a hospital setting. The sgent runs a process called an HL7 processor 71 that interfaces to the local application environment.

The HL7 processor is connected to an HL7 interface engine 7 on a configurable TCP port 73 to listen for HL7 messages received over the interface engine's outbound interface 72.

Upon receiving an HL7 message, the HL7 processor parses the message using a mechanism that converts the HL7 text string into objects that can be directly used by the processor. The HL7 processor then analyzes objects to determine what actions to take including discard, process, and filter the received messages 74.

A provider topic 43 provides an index used by the HL7 processor to obtain a list of physicians that can receive HL7 information. The ordering physician ID in the received HL7 message is compared to the index of physicians and their associated ID's kept in the provider topic. If a match is made, the HL7 message is further processed. If no match is made, the HL7 message is discarded.

If the ordering physician ID in the message matches a physician in the provider topic index, the HL7 listener opens the physician office topic for that physician's office to obtain additional filtering and processing rules.

If the HL7 processor determines that it should process the message, it creates an HL7 ACK 75 to return to the HL7 interface engine 7. This includes compiling the HL7 into an HL7 ACK text string and putting it into the interface engine's HL7 inbound interface 76.

After acknowledging the received message, the HL7 Processor transforms the HL7 77 based on configuration parameters and preferences identified in the physician office topic and specific configuration files. Parameters include: (1) department identifiers which indicate which department messages to process, (2) result status filters determine which HL7 messages of a particular status type are to be sent, (3) patient tType filters specifying which test results are sent based on the patient type in the HL7, (4) HL7 department strings provide the information that can be added to the HL7 to make it suitable for sending such as adding the lab directors name or other data not included in the original message and (5) processing instructions for the HL7 processor to prevent duplicates from being sent.

The HL7 processor next creates an instance of the results topic 37 and adds the hospital and ordering physician as participants in the topic. It then streams the HL7 text into the results topic and saves it to the local topic warehouse 14. The HL7 processor then casts the new topic to the destination nodes by passing the topic to the payload generator (previously described).

At this point, the node delivers the payload to the destination nodes via the rendezvous server.

FIG. 14 illustrates the use of the agent's results processor 9a and the ACK processor 9b running in the physician office where the EMR 8 is physically located. The results processor puts HL7 messages into the EMR's inbound interface 8a. The ACK processor receives HL7 ACK messages from the EMR's outbound interface 8b.

Now with respect to FIG. 14, the process begins when a new payload is put into the Physician Office node's Inbox and processed by the Inbox Sorter. As described previously, the Inbox Sorter decrypts the payload, extracts the topic and passes it to the Agent identified in the topic attribute.

The Results Agent analyzes the topic to determine the topic type. It then accesses the topic warehouse 16 for a special Provider topic 80. This topic object supplies the parameters and preferences that are to be applied by the Results Agent to transform and/or filter the newly received HL7 message.

The Results Agent then scans the topic warehouse for a replica of the newly received topic (using the topic's unique ID). If a replica of the topic is found, the Results Agent opens and adds the newly received data to the topic found in the warehouse. If no replica of the topic exists, the Results Agent can add the new topic to the topic warehouse.

Once the topic has been saved in the topic warehouse, the Agent determines to either continue processing the received HL7, or hold the HL7 82 in order to acquire additional routing information before continuing.

If an HL7 message is held for routing, the Results Agent provides several JSP applications that enable people to examine and modify the HL7 message from a Web browser.

A common example of this requirement is the case whereby an outpatient test result is delivered to the Physician Office. An outpatient test does not generally require an ordering physician to be completed. Because many hospitals require an ordering physician to be identified to fulfill the order, the hospital will insert a generic physician identifier as the Ordering Physician (often the top physician in the group). In order to route the result to the appropriate physician once it reaches the physician's office, a nurse in the office generally determines the correct provider (physician, physician assistant, or nurse) to route the HL7 result message.

The Results Agent enables office staff to view all HL7 results from a browser-based worklist. The worklist contains a column with a pull down list of all of the providers in the office. The nurse selects the provider that should receive the HL7 from the pull down list. Once selected, the Results Agent acquires the new provider selected by the nurse from the browser session and transforms the Ordering Physician in the HL7 from the original, generic physician to the provider selected.

The Results Processor next uses the parameters found in the Configuration topic to transform the HL7 83. This could include filtering out specific elements in the HL7, adding or transforming elements, or making other modifications as defined in the node's configuration files and topics.

After all necessary transforms have been completed the Results Processor puts the processed HL7 into the EMR's Inbound Interface. This is often a folder located on the EMR server, in which case the Results Agent simply copies the HL7 text string to the folder with the required file extension dictated by the EMR requirements.

The EMR processes the HL7 text string, matching the patient and provider found in the message with the patients and providers found in its database. For patients, EMR's use a reconciliation process that examines the patient's name, date of birth, gender, social security number and other specific elements to compare against a list of patient in the database. If a 100% match is made, the EMR associates the patient result in the HL7 message with a patient's record in the EMR. Providers are matched using the Physician ID code.

If a provider and/or patient's identity cannot be resolved, the EMR will queue the HL7 in a reconciler to enable a person to access and manually match the provider or patient to one the in the EMR.

If the EMR uses and HL7 interface, it normally deposits and HL7 ACK message in the Outbound Interface on the EMR (often a unique folder on the EMR server).

The Results Agent's ACK Processor 9b runs a thread to capture the HL7 ACK 85 from the EMR's HL7 Outbound interface 8b. If a new message is found, the ACK Processor reads the HL7 text, parses the text into objects 86, and determines which result the HL7 ACK is associated with.

The Results Agent next searches the node's topic warehouse for Result topics that match the HL7 ACK 87. If the matching Result topic is found, it is opened and the Audit Capsule within the topic is updated with the new HL7 ACK. If no matching topic is found, the HL7 ACK is discarded.

Once the Result topic has been updated on the Physician Office node by the ACK Processor, the Audit Capsule can be distributed back to the source node (the Hospital) to be added to the replica of the Result topic stored on the Hospital node as an audit trail.

The three components of the Results Agent, the HL7 Processor, the Results Processor and the ACK Processor comprise the major components of the Results Agent.

FIG. 15 illustrates the mechanisms of the embodiment that enable remote management and support for the nodes and Agents. This is critical for healthcare applications that are installed in a wide variety of settings across the community including locations where little or no technical expertise is available.

Due to the criticality of the issuance of commands to nodes and Agents, the source of the commands must always be identified by the node as a trusted source that cannot be compromised by external attacks. The role of a system administrator is defined as a person with the authorization and responsibility to manage the nodes and Agents.

To provide for this, the embodiment specifies a unique Master node 89 for each system to enable system administrators to securely issue commands to a node from a trusted source and receive responses providing status and/or requested information such as log files. The Master node is also used as the launching point to generate, deploy and enable nodes and Agents.

When nodes are initially created, the node ID of the Master node is assigned. Only commands issued from this location are accepted and processed by the nodes.

To enable remote command of the nodes, several components are implemented.

A Command Agent 91 runs on all nodes. It receives, executes and reports the status of all command payloads issued from the assigned Master node.

Command Central 92 is a process running on the Master node that provides the mechanisms to allow system administrators to manage the embodiment from a central location. Command Central includes (1) JSP applications that provide the system administrator's user interface, (2) a library of commands that can be executed by the remote command agents and (3) a mechanism that receives responses from the Command Agents (exchanged through a Command topic object described later) and presents it to the system administrator. The library of commands that can be executed by remote command agents include: (a) Restart the node, (b) Upgrade the software, (c) Set an application property, (d) Send logs to the System Administrator, (e) Send an application property, (f) Send System log files and (g) Send Application log files.

The Command Agent 91 provides mechanisms that receive commands, analyze, execute and respond with the status or requested information.

Now following the functional block diagram shown in FIG. 15, a system administrator accesses Command Central from the Master node. The Master node provides username and password protection, requiring secure login. Once logged in, the system administrator can select commands, input parameters and send the command to a selected node.

When a command is issued, Command Central creates an instance of a Command topic object and streams the command and associated parameters into the object. It then passes the Command topic to the Master node's Payload Generator, which creates a Command Payload and stores it in the rendezvous queue on the Master node. The Master node's UpLoader connects to the rendezvous' Receive Payload Servlet and passes the payload to the Payload Processor to store in the node queue for the node receiving the command.

The receiving node's DownLoader later connects to the rendezvous' Send Payload Servlet to download the Command Payload. It stores the payload in the Inbox, which is read by the node's Inbox Sorter and passed to the Command Agent 91.

The Command Agent analyzes the command and executes it based on its processing logic. Once executed, a response is generated and added as a Capsule to the Command topic. The topic is passed to the node's Payload Generator which puts it into a payload and routes it via the rendezvous back to the Master node.

The Master node receives the payload from the receiving node and presents the response to the system administrator via a browser-based view.

FIG. 16 depicts an object model of the Command topic 90. The class attributes include the topic type “Command” and the name of the processor “Command”. The Command topic is comprised of two Capsule objects, the Command Capsule 93 and the Response Capsule 94.

The Command Capsule 93 provides information relative to the issued command. It includes the command, command arguments, the ID of the node to which the command is issued, and a password. The password is used by the node to authenticate the command upon receipt. To accomplish this, each node is assigned a unique command password when initially registered with the rendezvous. The command will only be executed if it contains the correct password assigned to the node in the Command Capsule.

The Response Capsule 94 provides a mechanism for returning responses from the node's Command Agent including status, response detail and attachments like log files.

Referring once again to FIG. 15, after the Command topic has been created, it is saved to a topic warehouse 16 running on the RS specifically designed to queue Command topics. Next, the Command Central application streams the Command topic into a payload, encrypts the payload, and puts the payload into the node's node queue 29.

As described previously, the node's DownLoader regularly establishes an SSL session with the RS to download the contents of its node queue. The next time the handler establishes the connection, the Send Payload Servlet streams the payload to the DownLoader, where it is saved in the node's Inbox.

The node's Inbox Sorter scans the Inbox, extracts the payload containing the Command topic, decrypts the payload and passes the extracted topic to the processor or Agent identified in the Command topic attributes—the Command Processor.

The Command Processor 91 receives the topic and extracts the contents of the Command Capsule which contain the issued command and attributes. It examines the password in the Command Capsule and compares it to its assigned password. If a match is made, the Command Processor continues processing the command. If no match is made, the Command Processor discards the Command topic.

After verifying the authenticity of the command, the Command Processor executes the command which may include running local processes such as setting an application parameter or collecting information such as system log files.

Once the command has been executed, the Command Processor creates a response and streams it into the Response Capsule. It then creates a payload consisting of the Response Capsule, encrypts it, and returns it to the Master node via the mechanisms described earlier.

Command Central, running on the Master node, receives the payload, decrypts and analyzes the contents. The topic warehouse is searched for a Command topic ID matching the ID of the topic in the payload. When found, the topic instance in the topic warehouse is updated with the new Response Capsule and saved.

The system administrator is now able to access and view the contents of the Command topic including the responses and attachments returned from the node. In a real world setting, the system administrator could initiate a series of commands to the node to collect information about health and status and local Agents, performing specific actions like upgrading or installing software, and finally collecting log files indicating the results of the actions.

FIG. 17 through FIG. 23 provide a sequence diagram describing a common exchange of a clinical result between an HL7 Interface Engine located in a hospital and an ambulatory EMR located in a remote physician office made possible by the embodiment.

In view of the foregoing detailed description of preferred embodiments of the present invention, it readily will be understood by those persons skilled in the art that the present invention is susceptible to broad utility and application. While various aspects have been described in the context of a preferred embodiment, additional aspects, features, and methodologies of the present invention will be readily discernable therefrom. Many embodiments and adaptations of the present invention other than those herein described, as well as many variations, modifications, and equivalent arrangements and methodologies, will be apparent from or reasonably suggested by the present invention and the foregoing description thereof, without departing from the substance or scope of the present invention. Furthermore, any sequence(s) and/or temporal order of steps of various processes described and claimed herein are those considered to be the best mode contemplated for carrying out the present invention. It should also be understood that, although steps of various processes may be shown and described as being in a preferred sequence or temporal order, the steps of any such processes are not limited to being carried out in any particular sequence or order, absent a specific indication of such to achieve a particular intended result. In most cases, the steps of such processes may be carried out in a variety of different sequences and orders, while still falling within the scope of the present inventions. In addition, some steps may be carried out simultaneously. Accordingly, while the present invention has been described herein in detail in relation to preferred embodiments, it is to be understood that this disclosure is only illustrative and exemplary of the present invention and is made merely for purposes of providing a full and enabling disclosure of the invention. The foregoing disclosure is not intended nor is to be construed to limit the present invention or otherwise to exclude any such other embodiments, adaptations, variations, modifications and equivalent arrangements, the present invention being limited only by the claims appended hereto and the equivalents thereof.

Claims

1. A method of securely distributing objects between nodes on a network, comprising the steps of:

deploying a plurality of nodes;

deploying at least one rendezvous node to asynchronously exchange encrypted payload objects; and

deploying a central authority to manage and administer the nodes,

wherein the nodes are configured to secure, distribute and synchronize objects between specific nodes.

2. The method of claim 1, further comprising software agents at the plurality of nodes, each software agent configured to exchange acquired information with other agents.

3. The method of claim 2, wherein software agents generate objects that are capable of being transmitted to other agents including:

generating and assigning a Unique ID for the object; and

listing the ID's of all nodes that should receive a copy of the object and the ID of the agent that should be evoked when the object is received to the object attributes.

4. The method of claim 1, wherein a node, when first initialized, generates a unique public-private key pair which is distributed to all other nodes, comprising the steps of:

generating a unique 2048-bit public-private key pair;

maintaining a copy of the private key to decrypt and sign objects;

creating a node definition object that stores the node ID and the public key; and

distributing the node definition object to all other nodes.

5. The method of claim 1, wherein a node can receive an object created by an agent, package it into a serialized payload, encrypt it, and securely distribute it to nodes listed in the object attributes via the rendezvous node, comprising the steps of:

generating a serialized payload with a unique ID;

generating payload attributes from the object that include: the ID of the source node distributing the payload; the ID's of all destination nodes that should receive a copy of the payload; the ID of the agent that should be evoked when the payload is received; and an indicator of the type of information contained in the payload;

generating a one-time use, payload symmetric key and using the key to encrypt the object;

for each destination node; locating the node's definition object, extracting the public key, encrypting the symmetric key with the node's public key, adding the newly encrypted key to an array of encrypted keys for that payload, and streaming the array into the payload;

creating an SHA-1 based Hashed Machine Authentication Code (HMAC) using the encrypted object and the node's private key, and adding the HMAC to the payload attributes; and

saving the payload to an asynchronous queue on the node

6. The method of claim 1, wherein a rendezvous node can receive a payload from a node and distribute it to all nodes listed in the payload attributes, including the steps of:

running a process that accepts SSL connection requests from nodes;

receiving payloads streamed over HTTP/S from the node;

examining the payload attributes to determine which nodes should receive a copy;

providing a queue on the rendezvous for each node to persist the payload;

for each destination node: creating a copy of the payload; removing all encrypted payload keys from the array except the key for that particular node; and saving the modified payload in the queue for that node.

7. The method of claim 1, wherein the rendezvous node can retrieve and distribute payloads to destination nodes, including the steps of:

running a process that allows SSL connections from nodes;

receiving request from the connecting nodes to get the contents of their queue including a discard list of payloads the node no long wants;

retrieving the payloads found in the queue;

deleting the payloads listed in the discard list and updating the discard list to indicate which payloads were deleted; and

delivering the payload and the updated discard list to the requesting node over HTTP/S.

8. The method of claim 1, wherein nodes can receive payloads from the rendezvous node and present them to an agent, including the steps of:

supporting a queue for receiving payloads;

creating and maintaining a discard list for all received payloads to indicate to rendezvous nodes which payload to delete;

running a process that regularly connects to the rendezvous node to check for new payloads in its queue;

downloading payloads over HTTP/S and storing them in an inbox queue;

updating the discard list indicating the payload should be deleted from the rendezvous;

running a process that reads the payloads from the inbox queue, uses the node's private key to decrypt the payload symmetric key, and uses the symmetric key to decrypt the original object; and

evoking the agent identified in the payload attributes with the object from the payload.

9. The method of claim 2, wherein the software agents connect to software application interfaces to acquire, analyze, transform and distribute information to other agents via the rendezvous node, including the steps of:

connecting to local applications over a network to access a local folder or connect to a TCP port;

retrieving user data by reading a file from a local folder or listening on the TCP port;

running a process that parses the user data received into objects;

obtaining instructions for how to process the data from definition objects issued by the master node and distributed to the agent's node via the rendezvous node;

performing necessary modifications on the user data according to the instructions found in the definition objects; and

generating a new object with attributes that include a unique object ID, a list of nodes it wants to receive the user data, and the ID of the agent(s) it wants to handle the object once it is delivered.

10. A method of remotely sending commands to nodes from a central facility, including the steps of:

deploying an authorized master node that issues commands from a recognized source;

assigning the master node to each node when registered;

running a Command Agent on each node to receive, process, and report the status of commands issued from the master node in the form of a command object;

providing administrative interfaces that allows system administrators to select and issue commands and arguments from the master node; and

generating command objects that encapsulate the command and package it into a payload suitable for distribution from the master node to the target node via the rendezvous node.