When measuring performance the following considerations are most important.

•Obviously the most important consideration is What is your anticipated peak hourly volume?.

•What types of HL7 messages are you receiving and how large are they? This is NOT just the physical size of the message but more importantly HOW MANY segments on average does each message contain? A HL7 message containing a 3 MB radiology report embedded DICOMM image with 12 total segments will typically load much faster than a 50KB message with 2000 segments.

•What database platform and connection are you using? With the UltraPort SQL Schema Engine there are four (4) different platforms: MS SQL Server (Native), MS SQL Server (ODBC), MySQL (Native), and MySQL (ODBC). In our testing we have found that MS SQL Server runs better and faster than MySQL and that Native connections run only slightly better than ODBC connections.

•How "stressed" is your database server? Obviously our processes will not be the only ones reading and writing to these databases.

There are 3 different "import" operations which can occur when the Listener receives the HL7 message and it's important to know what each one is and how it can affect performance. Here they are in order from the fastest operation to the slowest.

1.A standard import of a "new" HL7 message into a trained database schema. This is the fastest possible import operation. A single query is issued to determine if the message already exists and needs to be "reloaded" (#2 in this list), and then the message is carved up into it's atomic elements and loaded into the schema data tables. How long this operation takes will be determined by factors like the size of the message and the performance of the database server and network. A "basic" HL7 ADT message with a dozen or so segments will generate 30-40 insert commands, you can extrapolate that out for a message with say 2000 segments.

2.A "reload". This scenario typically only occurs when testing because it means that you have received a message which already exists in the database and has to be "reloaded". This type of import operation takes significantly longer than #1 because the database engine has to "purge" the original message from <xx> schema data tables and only then perform the import operation.

3.A "Training Operation". This scenario occurs when you have checked "AutoTrain" in your Schema Engine profile and it takes the longest. It occurs when the import operation determines that either a data column or columns are not large enough to accept the message data OR if there are missing data tables or columns. When this occurs the import operation fails, but then automatically issues SQL statements to alter the database and tries again. It repeats this over several "passes" until the import operation ultimately succeeds. While this operation takes the longest it is also the most beneficial and will ultimately improve overall performance because subsequent import operations become easier as these errors are corrected.

How slow is too slow? This means how quickly can the listener import the HL7 message and reply to the sender. If it takes your process up to 2-3 seconds to import the message and your trading partner is only waiting 500 milliseconds before giving up and resending the message you will have problems. The first message will complete the import operation and when they resend the message that will result in a "reload" operation which takes even longer, thus they will resend it again, etc. This loop will continue until they eventually give up and flag the message as "Unacknowledged". This overworks your SQL Server for no reason and typically annoys your trading partner.

IMPORTANT TIP: It is vitally important that your trading partner wait for your Listener to acknowledge each HL7 message before sending or resending another message.

It is extremely important that you define what your reasonable expectations are.

Below is a real (paraphrased for clarity) example of a conversation between our HL7 support professionals and customer(s).

HermeTech: What is your anticipated daily message volume?

Customer: 25,000 messages, so I need my listener and database to handle 25,000 messages per day.

HermeTech: 25,000 per day, so if we round up that's about 1200 messages per hour over a 24 hour period. Is that correct?

Customer: Well, no, 90% of the traffic will be received in normal business hours 8AM to 5PM. So that's 22,500 messages over 9 hours let's round up and say 3,000 messages per hour. I need a listener that can handle 3,000 messages per hour.

HermeTech: Ok, so you need the ability to handle 3,000 messages per hour of sustained traffic, that's 72,000 messages per day. Is that correct?

Customer: Yes.

HermeTech: Now what happens if your receiving server is down for 4 days, or something you have no control over (like say a global pandemic) happens and their sending server is down for 4 days (a long weekend). When connections are reestablished there will be well over 100,000 messages backlogged/queued from the 4 down days PLUS the 25,000 new messages expected for the current day. Your total capacity is 72,000 messages per day so it will take you a minimum of 2 days to handle the backlog. Is that acceptable?

Customer: Goodness, no! My clients would kill me. I need to be able to handle a backlog or data dump like this in a couple of hours at most.

So, this customer example went from needing a HL7 listener capable of handling 25,000 messages per day, to needing one capable of handling 25,000 messages per hour. What's the real answer?

Building on the prior section, if you are exchanging high volumes of HL7 messages it is vitally important that you establish boundaries and manage the expectations of your Trading Partner and yourself. It is perfectly reasonable for you to ask that your trading partner manage or "throttle" the speed at which they deliver HL7 messages to you. On your side with the UltraPort SQL Listener if you need to slow down the process you have the option of setting up a Message Throttle to regulate the speed with which HL7 transactions are processed.