test

Understanding the Sun GlassFish ESB PIX/PDQ Manager

PIX/PDQ Processing Flow

Data enters the PIX/PDQ system through either the HL7 Binding Component for v2 messages or the HTTP Binding Component for HL7 v3 messages. The data is then mapped, transformed, and routed through the appropriate BPEL process so it can be understood by the master index. Depending on the type of HL7 event, the BPEL process calls the domain lookup interface and then the Master Index facade interface which interacts with the master index itself. The message is processed through the master index system as a query, a new record, an update to an existing record, or a merge transaction. When the results are returned to the BPEL process, the BPEL process constructs an HL7 acknowledgment (ACK) and sends a reply through either the HL7 or HTTP Binding Component.

You can follow the path that each message takes through the PIX/PDQ Manager by viewing the message trace on the PIX Console. The trace reports various checkpoints throughout the transaction, and displays the order in which it was processed by each component.

The Sun PIX/PDQ Manager supports the following IHE event types. The processing flow is different for each type.

Patient Identity Feed

A patient identity feed event is triggered when a record is added, updated, or merged in a source system. The new information is then fed to the PIX/PDQ Manager and specifically to the Master Index for cross-referencing and identification. Once master index processing is complete, a message is sent out to the domains that subscribe to master index updates. An event is also entered in the ATNA audit log.

Patient Identity Feed Processing Flow

    Patient identity feeds are processed as follows. This can be seen in the figure Figure 1.

  1. An event occurs in an HL7 messaging domain that creates a new record or updates or merges existing records.

  2. The message is received by the HL7 Binding Component if it is HL7 v2, or by the HTTP Binding Component if it is HL7 v3.

  3. The message is processed through the Normalized Message Router to one of the following BPEL processes, depending on which version of HL7 is being processed: IHEPixPdqV2BpelProcess (v2) or bpelPIXManager (v3).

  4. The BPEL process maps the data and routes it to the MDM Facade EJB, which then sends it to the Master Index for processing.

  5. The Master Index compares the data against its existing records and updates the database accordingly.

    The action taken by the Master Index is based on whether the new information constitutes a new patient record, updates an existing patient record, or merges two existing patient records. This is determined by the results of the matching algorithm. If a new record is added, the master index might mark the record as a potential duplicate of existing records if the matching probabilities fall within a defined range.

  6. The BPEL process then generates an ACK or NACK response, which is sent back out to the originating domain.

  7. The BPEL process generates the audit record of the transaction, which is stored in the ATNA repository.

Patient Identity Feed HL7 Message Types

In the HL7 v2 IHE framework, this type of event is known as an ITI-8 transaction. It is triggered by the following HL7 v2 events:

In the HL7 v3 IHE framework, this type of event is known as an ITI-44. It is triggered by the following HL7 v3 events:

For audit purposes, these events are all identified as “Patient Record” events, with an event ID of 110110.

Patient Demographics Query

A patient demographics query event is triggered when a consumer needs to select a patient based on demographic data. The consumer requests information about patients that match the data from the master patient index. The query message provides a set of demographic data, which the master patient index compares and matches against existing records in the database. The master patient index generates a response with the demographic data for matching patients.

Patient Demographics Query Processing Flow

    Patient demographics queries are processed as follows. This can be seen in the figure Figure 1.

  1. A request is sent by an HL7 messaging domain for patients whose demographic information closely matches the demographic data sent in.

  2. The message is received by the HL7 Binding Component if it is HL7 v2, or by the HTTP Binding Component if it is HL7 v3.

  3. The message processed through the Normalized Message Router (NMR) to one of the following BPEL processes, depending on which version of HL7 is being processed: IHEPixPdqV2BpelProcess (v2) or bpelPDQManager (v3).

  4. The BPEL process maps the data and routes it to the MDM Facade EJB, which then sends it to the Master Index for processing.

  5. The Master Index compares the input data against existing records in the database. Any matches are returned to the BPEL process.

  6. The BPEL process then sends the patient information back through the NMR and Binding Components to the originating domain, and generates an ACK or NACK response, which is also sent back out to the originating domain.

  7. The BPEL process generates the audit record of the transaction, which is stored in the ATNA repository.

Patient Demographics Query HL7 Message Types

In the HL7 v2 IHE framework, this type of event is also called an ITI-21 transaction. It is triggered by the following HL7 v2 event. For audit purposes, it is identified as a “Query” event with an event ID of 110112.

The master patient index response to the above request is the following HL7 v2 event:

In the HL7 v3 IHE framework, this type of event is also called an ITI-47 transaction. It is triggered by the following HL7 v3 event. For audit purposes, it is identified as a “Query” event with an event ID of 110112.

The master patient index response to the above request is the following HL7 v3 event:

PIX Query

A PIX query is triggered when one of the domains in the PIX/PDQ system requests a list of patient identifiers that are associated with a specific patient identifier. This request is processed by the Master Index, which responds with a list of associated patient identifiers if any exist.

PIX Query Processing Flow

    PIX queries are processed as follows. This can be seen in the figure Figure 1.

  1. A request is sent by an HL7 messaging domain for any identifiers associated with the given patient identifiers.

  2. The message is received by the HL7 Binding Component if it is HL7 v2, or by the HTTP Binding Component if it is HL7 v3.

  3. The message processed through the Normalized Message Router (NMR) to one of the following BPEL processes, depending on which version of HL7 is being processed: IHEPixPdqV2BpelProcess (v2) or bpelPIXManager (v3).

  4. The BPEL process maps the data and routes it to the MDM Facade EJB, which then sends it to the Master Index for processing.

  5. The Master Index cross references the given patient identifier against existing information in the master index database, and either returns a list of identifiers or null, if none were found.

  6. The BPEL process then sends the list of identifiers back through the NMR and Binding Components to the originating domain, and generates an ACK or NACK response, which is also sent back out to the originating domain.

  7. The BPEL process generates the audit record of the transaction, which is stored in the ATNA repository.

PIX Query HL7 Message Types

In the HL7 v2 IHE framework, this type of event is known as an ITI-9 transaction. It is triggered by the following HL7 v2 event, and is identified as a “Query” event with an event ID of 110112:

The master patient index response to the Q23 request is the following HL7 v2 event:

In the HL7 v3 IHE framework, this type of event is known as an ITI-45 transaction. It is triggered by the following HL7 v3 event. For audit purposes, it is identified as a “Query” event with an event ID of 110112.

The master patient index response to the above request is the following HL7 v3 event:

PIX Update Notification

A PIX update notification event occurs when key data in a patient record is updated by a domain in the master index, which then broadcasts the update to a JMS topic to make it available to all interested domains. This type of message is unlike the others in that the event originates in the master index to be distributed to the HL7 domains, and it uses JMS topics to distribute the messages.

PIX Update Notification Processing Flow

    PIX update notifications are processed as follows:

  1. Sun Master Index receives an update from a domain, and publishes the update to a JMS topic, PatientTopic.

  2. The PIX Update Notification MDB receives the update from PatientTopic and determines if any domains are subscribed to updates from the originating domain, and if so, if they require HL7 v2 or v3 messages. This information is found in the PIX/PDQ database tables.

  3. For subscribing HL7 v2 domains, the MDB writes the outbound message to the tHL7V2 topic; for subscribing HL7 v3 domains, the MDB writes the outbound message to the tHL7V3 topic.

  4. The update notification BPEL process subscribes to tHL7V2 in the HL7 v2 projects, and to tHL7v3 in the HL7 v3 projects. Messages written to these topics are processed by the appropriate BPEL process and mapped to the required HL7 format.

  5. The audit record of the outbound notification is generated and stored in the ATNA repository.

  6. HL7 v2 updates are sent out through the HL7 Binding Component to the subscribing HL7 v2 domains. HL7 v3 updates are sent out through the HTTP Binding Component to the subscribing HL7 v3 domains.

Figure shows the flow of data for PIX update notifications.

PIX Update Notification HL7 Message Types

In the HL7 v2 IHE framework, a PIX outbound notification is also called an ITI-10 transaction. An update to the patient cross-reference triggers the following HL7 v2 event. For audit purposes, it is identified as a “Patient Record” event with an event ID of 110110.

In the HL7 v3 IHE framework, this type of event is also called an ITI-46 transaction. An update to the patient cross-reference triggers the following HL7 v3 event. For audit purposes, it is identified as a “Patient Record” event with an event ID of 110110.