Sending HL7 messages created with EasyHL7 objects is really quite simple. While the objects in themselves only deal with reading and writing HL7 message data to / from the file system and RAM. They do not deal at all with message transport over TCP/IP. However, when combined with a piece of HL7 Sending software like the UltraPort HL7 TCP/IP Router (or any third party software with equal functionality), you can have a complete TCP/IP 'aware' solution up and running in minutes.
You simply have your solution create hl7 messages (using the the CreateMessage or CreateFromHL7 methods of the EasyHL7Message object) and then save your messages into a folder on the file system (see the Save method). The Router software does the rest, and yes, it's really that simple.
OR you can use a very exciting feature of the UltraPort HL7 Router in that there is a FREE API for Visual Studio .Net allowing you to enhance your VS.Net application by having your application forward your outbound HL7 messages directly to a waiting UltraPort router from anywhere on your network! It's incredibly easy to use, multiple applications can send HL7 messages to the same UltraPort Router at the same time, no TCP/IP or Socket programming experience is necessary it's all done for you with easy to follow code like that shown below. Click HERE to download the UltraPort Proxy Toolkits (ZIP format). For the online documentation for the UltraPort Router Proxy toolkit click HERE.
Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click Try Dim MyRouterProxy As New UPRTK.Net2005.RouterProxy With MyRouterProxy 'There's no use in trying to send if 'the Router is not running If Not .PingTheRouter("192.168.1.122", 12345) Then MessageBox.Show("The UltraPort Router isn't running!") Exit Sub End If 'Assume we've got a process that creates outbound 'HL7 messages and places them in a sorted list Dim myList As SortedList = GetHL7Messages() Dim i As Integer = 0 For i = 0 To myList.Count - 1 Dim oMsg As EHL7_mc2005.EasyHL7Message = myList.GetByIndex(i) If .SendHL7Message("192.168.1.122", 12345, oMsg.HL7) Then MarkMessageAsSent(oMsg) Else 'We got an error MessageBox.Show(.LastError, "Error Sending") Exit Sub End If Next End With Catch ex As Exception MessageBox.Show(ex.Message) End Try End Sub |
Advantages to using this method over other methods.
| 1. | Simplicity. Your solution doesn't know or care whether the HL7 messages are being sent over TCP/IP or whether the files are being picked up by the recipient in some other manner. |
| 2. | Smaller Code. Since you don't have to integrate message transport into your solution's codebase, you actually get to write less code with no 'special handling' code. And less code written means less code that can malfunction, less code to be documented, tested, etc. etc. |
| 3. | Less Cost. A fact, most major commercial HL7 integration engines can be implemented to EITHER receive HL7 messages over TCP/IP OR as Hl7 message data files transferred by some other method into a folder on the file system. This fact gives you the ability to negotiate whether or not TCP/IP communication is even needed at all on a case-by-case, site-by-site, customer-by-customer basis. If it's not needed (ie you can just produce files) then your solution is completely adequate right out of the box. If your trading partner requires it or prefers it, only then do you have to integrate the third party software. So you don't buy it if you don't need it. |
Buy Vs Build - The age old question. My company writes our own software, why don't we just build our own TCP/IP communications programs.
There's certainly nothing wrong with building your own HL7 TCP/IP applications. As with anything, there are several important things to consider.
| 1. | Resources. TCP/IP and network programming is NOT like writing business / medical software. It's a totally different skill / knowledge set. Do you have the proper human resources to do the job? Can you afford the loss of customer goodwill if you get it wrong OR it takes an extended amount of time to debug. It's certainly not the type of thing you want to try on a 'learn as you go' basis. |
| 2. | Cost. Plain and simple, cost drives us all. For instance, there are several commercially available software development tools for just this purpose (creating HL7 TCP/IP listeners/routers). In most of these instances there are some not inconsiderable run-time distribution costs associated with using them. So, if you use them, you might get all of the joy and fun of writing your own software AND THEN end up paying more to distribute your application to your customer than if you had just bought an EasyHL7 product right off the shelf at the full retail price! |
| 3. | Time. How many man-months of development time will it take to do this (assuming you've got the resources). That's development, debugging, testing, documenting, alpha, beta, release and support. Now, once it's done, how many implementations will you be doing over the course of 1 year. It's interesting, in having this same conversation with a customer who was considering building vs buying he discovered that if his business continued on it's current trends he would be 'spending' over 15 years worth of total implementation cost to build it himself (just using programmer salary to calculate it). No software product has a 15 year lifespan! |