Real World examples of how clients use the HL7 Postmaster

 

Below are some actual examples of common situations where our customers have used the HL7 Postmaster or its predecessor the EasyHL7 File System Postmaster in the past. What's important to keep in mind is that it is now possible to be running all of these scenarios (and others) at the same time, using one or more Postmasters.

 

---

 

 

Scenario 1: Filtering out unwanted HL7 messages

Customer: Government Health Agency

 

The setup: Client receives HL7 messages from a very expensive radiology system (RIS) which contain radiology reports. The HL7 messages are delivered into a very expensive intranet based EMR in use by multiple physicians and hospitals. HL7 is transported via standard HL7 TCP/IP connections.

 

 

The problem: The physicians and users only want to see radiology reports with a FINAL status (as opposed to preliminary and interim reports). The outbound HL7 interface of the RIS does not have an option to exclude preliminary or interim reports. The inbound HL7 interface for the EMR has severely limited options for filtering out unwanted HL7 messages and NO option to display the report to the user with the STATUS of the report. Both of the software vendors (the RIS and the EMR) ARE willing to customize their system to provide the functionality wanted with lowest bid for providing that service being in excess of $30,000 (as we said very expensive).

 

The Solution: Use the HL7 Postmaster to "intercept" the outbound HL7 feed from the RIS, filter out unwanted HL7 messages (messages containing preliminary or interim radiology reports), and then deliver the remaining messages to the EMR system. Like so:

 

 

The Solution (Continued): In the diagram above the RIS system sends HL7 messages out over TCP/IP as usual but instead of the EMR, the message is received by the UltraPort HL7 Listener (included with the HL7 Postsmaster**) which delivers the HL7 message to the Postmaster. The Postmaster then evaluates the messages for delivery and discovers that all messages which contain preliminary or interim reports are to be delivered to a Rubbish Bin and all other messages are to be delivered to an UltraPort HL7 TCP/IP Router (also included with the Postmaster**) for final delivery out over TCP/IP to the EMR system. The RIS system and the EMR system have absolutely no idea that anything has changed.

 

Additional Information: Rubbish Bin Destinations

 

---

 

Scenario 2: Sending and Receiving HL7 over the Internet

Customer: Anyone

 

The setup: Our client is the developer of a "hosted" web based EMR (or Lab, or Transcription, or Pharmacy, etc.) and thus has no direct "presence" at their customer sites. This makes it impossible to set up "local" HL7 interfaces. Setting up "remote" HL7 interfaces requires the use of VPNs (Virtual Private Networks) connections for each of their clients which are notoriously cumbersome and expensive (in resources and $).

 

The Problem: There is no HL7 "standard" way for HL7 interfaces to communicate via the internet as a result it is not supported by any of the client's HL7 trading partners.

 

The Solution: It is possible to use the HL7 Postmaster to "Web-Enable" any standard HL7 interface. That's right we said ANY STANDARD HL7 INTERFACE in use today and allow them to either SEND HL7 to your Web Server or RECEIVE HL7 from your Web Server or both. All of this is done in such a way as to comply with all medical patient privacy regulation (like HIPAA in the USA) and requires NO MODIFICATIONS or customizations of the remote client's current HL7 interface.

 

 

 

 

 

The Solution (Continued): By installing the HL7 Postmaster at the client's site the customer now has a local presence inside of the client's network and can establish LOCAL HL7 interfaces. The Postmaster then communicates with your web server directly by either SENDING you HL7 messages or polling your service periodically to check for HL7 messages FROM you to be delivered to the client, retrieving them from you, and then delivering those messages on to the local system. Since the client system is communicating locally using only HL7 standard interfacing practices it has absolutely no idea that it has actually been "web-enabled".

 

Additional Information: Web Service Data Sources, Web Service Destinations

 

---

 

Scenario 3: Splitting 1 HL7 feed into many

Customer: Anyone

 

The setup: Our client (you) are receiving an inbound HL7 data feed from 1 HL7 system which is being delivered to another HL7 receiving application. A simple scenario for this might be patient demographic and schedule information being sent from the Billing System to the EMR.

 

 

The Problem: Your office/clinic/hospital has expanded and acquired other systems which are capable of accepting an HL7 data feed. You now have 2 options:

 

1.Petition the HL7 Sender to produce multiple outbound HL7 feeds. For our scenario this is either impossible or cost-prohibitive.

2.Get the HL7 Receiver to forward the HL7 data on by petitioning them to create multiple outbound HL7 feeds. Again, for our scenario this is either impossible or cost-prohibitive.

The Solution: Use an HL7 Postmaster to intercept the HL7 feed from the HL7 Sender and route it to multiple destinations.

 

 

Additional Information: See sections on creating Postmaster Destinations.

 

---

 

Scenario 4: Consolidating many HL7 feeds into 1

Customer: Anyone

 

The setup: Like Scenario 3 above, our client (you) are receiving an inbound HL7 data feed from 1 HL7 system which is being delivered to another HL7 receiving application. A simple scenario for this might be patient demographic and schedule information being sent from the Billing System to the EMR.

 

 

The Problem: You now need to have the HL7 Sender send OTHER HL7 feeds in addition to patient demographics (perhaps billing information, Lab Orders, etc). Your HL7 Sender trading partner (in our scenario the Billing System) does have the capability to do this BUT has a limitation in that they must be truly SEPARATE feeds and can't go to the same destination as your existing feed (in our scenario the EMR). Your HL7 Receiver (the EMR) has the ability to receive ONLY ONE inbound HL7 feed and then it dynamically processes the HL7 based on message type, sender, etc. You again now have only 2 options.

 

1.Petition the HL7 Sender to change their system to send ALL HL7 messages on one feed. For our scenario this is either impossible or cost-prohibitive.

2.Get the HL7 Receiver to change their system to accept multiple inbound HL7 feeds. Again, for our scenario this is either impossible or cost-prohibitive.

The Solution: Use an HL7 Postmaster to intercept all of the HL7 feeds from the HL7 Sender and route it to a single destination, the HL7 Receiver.

 

 

Additional Information: See sections on creating Postmaster Destinations and Data Sources.

 

---

 

Scenario 5: Converting HL7 Messages into Documents

Customer: Anyone

 

The setup: Our client is a regional laboratory with a desire to attract business by offering the option of customized reports for each client in a variety of formats.

 

The Problem:  Time and resources (both skilled personnel and $).

 

The Solution: You can now use the HL7 Postmaster as a publishing engine to create documents from HL7 messages.

 

 

 

 

 

Additional Information: HL7 Document Templates Online Help.

 

---

 

Scenario 6: Extracting Embedded Binary Files (PDF, JPG etc) from HL7 Messages

Customer: Anyone

 

The setup: Our client has a new requirement to receive and process HL7 messages which contain diagnostic reports (Adobe PDF Files) embedded as binary data files in their HL7 messages.

 

The Problem:  How to implement this new requirement quickly and easily with a minimum of disruption to current processes, extract the binary data files safely to disk and recover them.

 

The Solution: You can design an UltraPort HL7 Document Template to do exactly this task!

 

 

 

 

 

Additional Information: HL7 Document Templates Online Help.

 

---