This a basic checklist of red flags to look for with a custom interfacing implementation built around the Chameleon SDK. Most of this list does not apply to Iguana implementations since Iguana naturally avoids all of these common mistakes.

No functional specification?

• It is important to avoid beginning implementation until a basic functional specification has been written up. This is important because it is not uncommon for the Primary Integration Engineer to get carried away with thinking about low level details of the implementation (i.e. how to solve the problem rather than 'what is the problem?'). As a result, many customers go through an expensive re-implementation of the first cut of their core messaging infrastructure because they have produced an application that is inconvenient and impractical for the Field Integration Engineers to use. A good resource on functional spec writing that explains why it's important is:

http://www.joelonsoftware.com/articles/fog0000000036.html

Site-specific business logic implemented in code?

• Chameleon and Iguana are designed to make dealing with non-standard flavors of HL7 easy by allowing customers to define site-specific configurations with different mappings and python manipulation at each site. All of this logic is nicely encapsulated in an interface configuration file, or "VMD file".

• Sometimes engineers will have instead implemented this business logic in the language they are writing their core infrastructure implementation in such as Java, C#, C++, etc. This is very bad practice since it makes supporting different flavors of HL7 very difficult, dramatically driving up the cost of deployment for each new site.

A different application per site?

• This is a huge quality problem. Here the Primary Integration Engineer will quickly create a simple application for each customer site based directly off of the generated client/server example code. This is a maintenance nightmare. The core infrastructure code needs to be thoroughly thought out and tested. This development takes time but should only happen once, up front. New site deployments should not require any changes to the core application code. For that reason, consider using the multiple configurations functionality to deploy variations of the same VMD file at different sites. Not only does it reduce the cost of supporting various flavors of HL7, it also reduces the overall maintenance effort and keeps your core infrastructure code base stable.

	If the time required up front for this type of infrastructure implementation is too great, iNTERFACEWARE strongly recommends using Iguana. With Iguana, we've implemented it all for you.

Errors Logs not clearly separated from normal log messages?

• Specific error conditions should be easy to spot and filter from normal logging activity in an HL7 interface. Having a clear time line is very important, too, with timestamps for when activity occurs.

• A good quality implementation will make it very easy to drill into and review the logs without requiring any deep technical knowledge.

• Iguana separates normal operational logs from error logs and gives users the ability to search those logs through its web interface.

No easy means to export the HL7 messages being sent and/or received?

• It is important to have an easy means for exporting messages being sent and received for audit purposes, quality assurance, and for maintaining a detailed site database.

• Iguana has the ability to export logs of processed messages through the web interface.

No log purging in place?

• One common mistake that is made with HL7 interfaces is to forget about what happens when the logs fill up and overflow the system's hard drive. A good system will have some method of truncating logs so that they are periodically purged.

• Iguana has log purging built in so it's easy to configure. If your machine's hard drive is small, consider purging your logs 2-3 times per week to allow Iguana to run optimally.

Is a complete reboot required for configuration changes?

• It is easier to write servers that require the user to restart the entire server to pick up configuration changes. In practice for the users - i.e. the Field Integration Engineers will appreciate a system that does not require rebooting to pick up configuration changes. It gives much greater comfort to your customers who are unlikely to appreciate interfaces going up and down.

• Iguana allows channels to be added and removed on the fly without needing to restart it or turn other channels off and on.

No clear alert strategy in place?

• A good alert strategy will ensure that a Field Integration Engineer is paged in the event of a serious problem with an interface.

• Iguana has the ability to send email alerts when errors occur with the HL7 interface.

No monitoring system in place?

• Is there an easy way to get visibility into the functioning of the system. Preferably this interface should not require deep technical skills for the person doing the monitoring so that it is like Iguana which has a nice web based interface to browse the logs.

• Like Iguana there should be permission levels which control what each user can do with the system.

Is the VMD file being loaded with every message?

• This is a fairly common mistake. Loading a VMD file takes a reasonable number of seconds which means that if a Chameleon application is loading the VMD every time it parses a message it will result in very poor performance. A VMD file should only be loaded once or when it changes.

• An adequate HL7 interface should be happy handling up to 6-7 messages per second - this reflects the volume one would expect for an ADT interface with 60,000 messages per day where 80% of the load is between 9-10 am and 4:30-5:30pm.

Is it possible to configure a set of filters in an interface?

• Chameleon has the ability to do Scripted Transformation, which takes an HL7 message and transforms it into another dialect of HL7. This can be a very helpful tool in terms of making site-specific customizations. A good implementation will allow a to leverage this functionality in Chameleon.

• This is functionality often overlooked by the Primary Integration Engineer when implementing custom solutions with Chameleon without Iguana.

Does the application handle badly formed HL7 messages?

• Invalidly formed HL7 messages being fed to the server should not result in the server crashing. It should be able to handle such data gracefully.

Does the server leak memory or resources over time?

• Languages like C# and Java supposedly make memory leaks impossible. In practice, however, even these languages can leak memory through circular references and all languages can leak resources like database handles, etc.

Does the application crash when a database it depends on disconnects?

• This is a standard thing to check. Poor implementations will often statically link into database implementations making them impossible to even run if the appropriate dependencies are not there. This should be avoided.

Does the application handle receiving unknown HL7 messages?

• The trick here is that the application should be able to just acknowledge and log the unknown message. This makes the interface more stable when extra messages are sent to it and prevents application errors when unexpected data are received. Chameleon does allow one to define a default message - the feature is very obvious in the 4.1 GUI but was more difficult to locate in earlier versions.

Does the application have sufficient functionality to handle ACKs when sending messages?

• There are four common scenarios to support (Iguana supports them all):

In well behaved sites it is important to match the message control ID coming back in the ACK. The application should allow configuration of this logic like Iguana does with a VMD file like ack_verify.vmd to parse out the message control ID.

Some sites will just send back ACKs where the message control ID does not match - so the solution will need to have the ability to accept any message as an ACK.

Some sites will send back a message but not validly formatted as an ACK - i.e. it might be three letters like "ACK".

Some sites are really badly behaved so that one needs to be able to configure a sender to just send messages and not wait for ACK messages.

Does the application support sending NACKs?

• Generally for implementing an HL7 listener to receive messages there will be two types of behavior required when errors occur:

• With regards to message processing errors, some sites will prefer that a negative ACK (NACK) message is sent. This should be configurable using a VMD file, like autonack.vmd, for setting up negative acknowledgements.

• In some sites sending a NACK will stop this interface. So sending NACKs should be disabled.

• Iguana allows these options to be configured.

Do the interfaces fail to start up smoothly when the machine is rebooted?

• Just a standard test to do. HL7 interfaces should be written as service applications. If there are dependencies on other services, like databases, then care should be taken to ensure that these services start up before the HL7 interface application starts or that the HL7 application can handle the database connection not being available initially.

Does the application support inputs and outputs other than just HL7 via LLP over TCP/IP?

• About 10-15 percent of HL7 interfaces require other transport mediums like batch files, etc.

• Iguana supports input from batch files, databases, etc. Also, the client executable interface means it's easy to implement custom transports if required like web services, etc. without the need to write an entire application and re-release it.

Can the application be patched easily?

• Iguana's client executable support makes it very easy to add new functionality specific to a single site without needing to re-release the entire application. The reason is that each client executable is loosely coupled to both Iguana and to the other part of the channel, whether it is a built-in component or another client executable.

• So if you encountered the situation in for one customer site where say a custom transport was required like setting up a web service, then existing production code does not need to be altered. Instead, a new client executable module can be implemented to handle this requirement. This avoids the need for an entire release and QA cycle on the existing production code.

• Many in-house implementations using a raw Chameleon SDK approach will not necessarily have been factored to allow this flexibility. Business logic will often be mixed in with transport and HL7 generation logic. Often complex low level threading architecture issues interfere with making what should seem a simple new requirement. It takes a very disciplined approach on the part of the Primary Integration Engineer to implement this type of modular breakdown.

Is deploying the application difficult?

• An automated setup file should be made or simple step-by-step instructions should be provided for the Field Integration Engineers to follow.

• However, make sure that Chameleon is installed and unaltered in its entire form with the same version that you developed with. The installation of Chameleon can be automated, which makes this process easy. Many serious problems can be created when software engineers try to make a custom deployment of Chameleon by copying DLLs in Windows directories, etc. This will often result in "DLL hell". Best practice is to install the custom application into the Chameleon directory so that it loads all the correct library versions.