Before you begin serious implementation of the UltraPort MS SQL Schema Engine there are several important concepts which you should take into consideration.

 

WHO is the HL7 interface for? That is to say with who is your trading partner? What is your mission? You should always know beforehand which system(s) you are trying to create HL7 interfaces for. Things you'll need to consider here are:

•Do you have their HL7 documentation? If you are going to be receiving HL7 messages from another party, that party SHOULD have an outbound HL7 implementation guide. Any HL7 compliant software should have available on request an INBOUND implementation guide which outlines their business rules and requirements for trading partners who wish to send them HL7 messages as well as an OUTBOUND implementation guide (if they produce HL7 messages). This document should outline which HL7 version(s) they support, which specific HL7 message types they produce/expect, which HL7 message segments they produce/expect in their messages and which HL7 fields are required in those segments. Most importantly, it should BOLDLY state if there are any deviations from the ANSI HL7 standards including CUSTOM "Z" segments, etc. Will YOU need to produce such a document?.

•Can you get "sample" HL7 messages? Whether you intend for your interface to receive HL7 messages from your trading partner or produce HL7 messages to send to them, getting some example messages which the other side will produce/expect can be crucial.

•Does your trading partner deviate at all from standard HL7? If they do then you will definitely want to create your own custom HL7 Vendor definition for the schema profile.

 

What kind of HL7 interface are you trying to create? Are you receiving (importing) HL7 messages sent to you by someone else? Are you sending (exporting) HL7 messages which will be sent to someone else? Or is it both of these? Things you will need to consider here are:

•Do you want to use the same database schema for both Inbound and Outbound messages? There's not really a right or wrong answer here it's simply based on your own feeling of what works best for you. Some people like to create totally separate SQL databases for Inbound and Outbound messages, some people use the same database but create a different schema profile for inbound versus outbound, and some people use the same schema for everything.

•How are the HL7 messages to be transported? If you're importing HL7, how is your trading partner going to deliver the messages to you. The Schema Engine's inbound processors import HL7 messages from data files in a folder on the file system. How do the files get there? If the trading partner wants to send them over a standard HL7 TCP/IP socket interface do you need an HL7 Listener (like the very handy and affordable UltraPort HL7 TCP/IP Listener). If you're exporting HL7 messages how are they to be delivered to your trading partner? The Schema Engine's outbound processors export HL7 messages into HL7 data files in a folder on the file system. Do you need an HL7 message sender (like the equally handy and affordable UltraPort HL7 TCP/IP Router)?

•Does your trading partner deviate at all from standard HL7? If they do then you will definitely want to create your own custom HL7 Vendor definition for the schema profile.

 

What is your potential volume? Whether outgoing or incoming how much volume you anticipate having can be very important. High volume considerations can trigger many different considerations, such as:

•Do have sufficient DBA support? The UltraPort Schema Engine is a great product for a great price but it doesn't preclude the need for a good database administrator. Any SQL database which might have tables with millions of rows cannot be simply left to it's own devices and might need to be 'tweaked' in different ways to improve performance. What about database backups? SQL Server settings such as file allocation, etc.

•Do you have sufficient storage (database and disk)? The Schema Engine works well with all versions of MS SQL Server from SQL 2000 onward (even the FREE SQL Server Express which you can download from Microsoft). One common mistake that people have made is simply forgetting that there might be some restrictions which they forgot to consider. Such as:

1.They're using SQL Server Express, have high volume, want to retain all of their messages but forget that SQL Server Express has a 4GB limitation on database size.

2.They're using the full version of SQL Server, but didn't notice that their database was installed not on an NTFS disk partition but on a FAT32 disk partition which also has a 4GB file size limit.

3.They've opted in their Global Settings to disable database maintenance but haven't implemented a plan of their own. What is the plan for removing HL7 messages from the database after they have been processed? A wise old software developer once said "If you design a system where records only get added and never get deleted then congratulations, you've created a virus".

4.Remember that the Schema Engine creates different log files, archive files, etc. based on your settings, the database maintenance feature makes sure that these file system files and aged database records are periodically purged to help keep the system singing along.