Accountable Care Organizations (ACO), meaningful use, data warehouses, and every clinical or business healthcare system depends on interfaces. Yet it is often the most overlooked, underappreciated, and misunderstood system in healthcare information technology.
Ever take a look at an Interface Schema? It looks like a road map with streets leading to various destinations. If you are involved in any aspect of Healthcare Informatics you more than likely have to deal with interfaces. Unfortunately, it’s one of those things that we often farm out to someone that understands HL7 interface language and all we want to know is that it’s working.
When I evaluate an organization’s IT infrastructure I like to start with looking at an interface schema. Most of the time I am not able to find a schema, either because nobody thinks it would be useful, or the Interface Architect wants to load up the page with too much technical detail. We are now so dependent on interfaces that we really need to rethink how we develop, deploy, and utilize our interface maps.
Your typical interfaced system landscape normally has an engine at the core of all the message traffic flowing to/from your various systems. Even if you have a standardized software (single vendor) solution for your healthcare organization, you have internal interfaces for that standard software and external to: labs, pharmacies, radiology groups, registries, dictation, data warehouse, and anything else you probably have not thought of. The interface engine is at the core of your data, passing everything through, as well as having to translate or stop traffic depending on the rules created. The reason you need an interface engine is because many systems park data in various forms within their data base. They also allow free text or users to input dummy data into the software system. One other reason is that interfaces can overwrite good data and you need a traffic cop to stop it before that happens.
Understanding the nuances and rules created on your interface engine is key to solving many of your interface issues. Without your interface schema or road map, you are driving blind.
Start with listing every internal software system that you have and start thinking about what messages (if any) are being sent out or received by each system. More than likely you are using an interface engine at the center of all your HL7 messages. The interface engine market varies from open source to very pricey solutions depending on your needs. What is important is to list out the connections to/from each system, what types of data is being passed and have an understanding of what is the source of truth. In other words, which system is your primary Master Index? Extracts are not interfaces, but are often confused with being an interface. Creating a file that gets parked on an FTP directory is not an interface. So don’t bother to list it, unless you want to identify it as a potential future HL7 interface.
Once you have a simple interface schema white boarded then you can take a step back and look at the mess. It will not be pretty and it will not look technical. But your goal is to:
- Develop a graphical view of all your message traffic.
- Identifying potential data integrity issues.
- Pinpoint why error logs are out of control.
- Uncover old interfaces that have out lived their usefulness.
- Identify what interfaces need critical alerts if they go down.
- Provide input to testing plans for software upgrades.
One additional side benefit of a basic interface schema is being able to show organizational leadership the complexity of your IT system, the backend support required and possibly additional resource requirements to improve data quality. Additionally, you will be able to show how interfaces are not “plug and play.” Keep the drawing simple and create different versions if you have to, one with IP and port numbers and another without. The more your clutter it, the less likely you can use it with non-technical audiences.
There are very few things you can change in your system that is NOT going to affect your interfaces and consequently downstream systems. The oxymoron of standard interfaces is that it’s always different.
