It’s HL7: What Can Go Wrong?

These days I’m getting lots of questions about medical connectivity, health data integration, and system interfaces. There are many options for custom clinical data integration but the best is of course  HL7 because it’s ubiquitous. People that aren’t experienced with health data interfaces often think that since we have HL7 interfaces we basically have a standard that we can apply equally to all problems. Given that’s not the case I asked Glenn Johnson, a 25-year veteran of the software industry with good healthcare experience and a senior vice president with Magic Software Enterprises Americas, to give us some advice about what can go wrong with HL7 interfaces and how to avoid some of the pitfalls. Here’s what Glenn had to say:

You’ve all heard someone ask this question “What can go wrong?” when they really mean, “nothing can go wrong.” As an integration vendor, I suppose I am expected to say all HL7 messaging and integration projects are perfect, neat and tidy. But in the real world, things do go wrong. And while you can never eliminate the human factor and the unexpected, spending some time carefully considering alternative scenarios will help to minimize risk and prepare you for dealing with the everyday challenges of real world healthcare integration. So I asked real HL7 healthcare integration implementers and their partners what goes wrong in the real world after the marketing is over. These ten ideas summarize what I learned.

1. Not knowing the limitations of your endpoints. This was a popular response. An integration project involves connectivity, transport, messaging, routing and data transformation between various endpoints. These can be thought of as sources and destinations. Frequently, too little is known about these endpoints at the outset of a project causing potentially lengthy delays while research or trial and error discovery takes place. In some applications, a cross-reference needs to be generated. In others, a fixed data dictionary is used. While an .xsd for an XML file can be reverse-generated, it is much better to work with vendor-supplied .xsd files from the original software vendor. Ability to quickly and easily access information about these applications and data sources, as well as their limitations, is useful. Getting this information ahead of when it is needed will prevent resources from going idle while the research is being conducted.
2. Forgetting to invite everyone to the banquet. Integration is a team effort; not sharing information between teams will cause failures. Use case interviews with all stakeholders will help to establish that input. It is also useful to gather cross-disciplinary teams together into a conference room at key points in the project. Lay everything out on the whiteboard and then capture that information electronically for future reference. Get everyone involved in current state and future state dialogues.
3. Too many cooks in the kitchen. While it is vitally important to invite everyone to the banquet table and get input from all the stakeholders, too many cooks in the kitchen spoil the pot. An integration project needs to have an assigned project manager (PM) with sufficient authority and leadership skills to be able to keep the project moving forward and break down the political walls by settling turf wars between the various departments and application managers.
4. Failure to thoroughly document project requirements. While most projects have at least some detailed requirements gathering, failure to look beyond the obvious will often lead to poorly developed requirements in areas that may have seemed less important to the initial stakeholders. While “scope creep” is to be avoided, project requirements should be thoroughly documented from end-to-end for your business processes.
5. Reliance on manual programming. Too often the response to an integration challenge is made by software developers. While it is very appropriate to have in-house and consulting programmers who create custom applications that deliver proprietary value to your organization, there is nothing proprietary about an XML transformation engine or a process monitor, for example. Healthcare integration is specialized, but it is not something that needs to be proprietary. In fact, it shouldn’t be. Manual programming is expensive, difficult to maintain and easily becomes obsolete due to business and environmental changes. Manual programming also results in integration that is not “loosely coupled.” When integration is tightly coupled, it is fragile, meaning that one little change breaks the whole process flow. Third-generation programming languages (RPG, COBOL, Java, C#, etc.) are poorly suited to integration projects.
6. Reliance on single purpose tools. There are any number of useful tools that do things like HL7 integration or HIPAA messaging, but they do nothing else. Add a need to access FTP, for example, and they have no added functionality. You can’t anticipate every future need. But you can acquire integration solutions with broad enough technical capabilities and a commitment to a roadmap that keeps your integration platform relevant for a long time to come. Choose a broad enough integration framework that will handle a wide variety of standards, protocols and formats. Try to get as many adapters and components included up front as possible. Avoid approaches that require a separate purchase for every database, message queue or communication protocol, for example. Needless to say, among those formats supported, you must make sure your required HL7 messaging formats are included.
7. Overkill. While single purpose tools are limiting and have too many gaps to handle broad integration requirements, it is also possible to choose extremely complex integration technologies that get in the way of productivity. Avoid integration solutions that have too many moving parts: dozens or even scores of different software products that can be purchased all under one umbrella integration name. These overkill approaches have different pieces of software that have to be installed for various aspects of an integration solution: messaging, application integration, cloud integration, java connectivity, legacy connectivity, etc. You should use a single-stack integration platform that incorporates all of these capabilities within a single design, deployment and monitoring environment.
8. No stress testing before going live. Many projects can get off track because they are not scalable or because the correct scale was not anticipated. Saving a few hundred dollars on a server can easily cost an organization tens or hundreds of thousands of dollars later on if the environment does not support the scale needed. Of course, you will never need the more capable hardware if your software architecture and integration platform do not scale as well. So make sure you have an integration platform that is itself built on a scalable application platform.
9. Security oversights. Integration architects have a tendency to think of information security as someone else’s concern. Sure everyone pays lip service to these issues, but failure to anticipate security requirements from the very outset can create delays in the project. Your security architects should be included as a part of your project team from the outset or else they will simply execute veto power over your approach later on.

10.  Building a black box. Monitoring of ongoing integration and logging of integration process activity is vital to a successful integration project. Too many lumpy solutions fail to incorporate monitoring and logging. But even when a monitor is included, you need to be careful not to treat your project like it is a black box. Use the monitoring tools that come with your integration platform to archive HL7 messages as appropriate. Create a dashboard view that displays the KPIs of your various integration flows. And then be prepared to act on what you learn.

What can go wrong with a healthcare integration project? Whatever you haven’t properly planned for in the beginning. Take some time to consult with those who have experience in a broad variety of integration projects and requirements and you may very well avoid planning lapses such as those mentioned here…and number eleven, too.