Developing the Interface
Now that you’ve scoped your interface/integration needs (covered in Part 1), the next step is to develop the interface based on that knowledge. Your interface spec should capture the following:
- Interface name
- Source or destination system name and version
- Message types used in the interface
- Message definitions including segments, fields, data types
- Segment and field attributes
- Data types
- HL7 tables
- Specialized interoperability challenges
When you combine these elements with your clinical or workflow constraints, they become your specification (or profile). You’ll use this to generate your interface code and validate your requirements as you develop the interface. With a profile in place, you can more easily identify risks, communicate with other stakeholders, save time and generate other documents related to your project.
Here are options for building an HL7 profile.
Now you need to determine any gaps existing between the systems you’ll be connecting. You can do this by conducting a gap analysis. Here’s a list of questions you should ask to help identify gaps related to the message you’ll run through the systems. By pinpointing who handles what as part of developing the interface engine, you’ll save lots of time and headaches down the road.
Deploying and Testing
Next you need to deploy and test the interface in the customer environment to make sure you’re not injecting errors with your code and that the interface suits the needs of the clinical workflow. Keep in mind that you’ll test more than once: during configuration and development; during the formal validation phase; and during maintenance.
By automating your tests, you can save significant time. You may be able to take advantage of built-in test tools depending on the interface engine you choose. Check out these lists to see what your test software should handle and for possible test scenarios.
Just remember, you want to configure and test your interface in a test system, not in a production system. But make sure your test system mirrors your production system and that you use de-identified production data.
Once you’ve got a few customer deployments under your belt, you’ll need to scale. Here are a few signs:
- It’s hard to grow/evolve over time as a change to one interface impacts many interfaces
- You’re finding that systems are inflexible because they must understand other systems’ expected data structure and semantics
- Costs grow rapidly because you are relying on another vendor to change or add new interfaces
- You’re up against a steep learning curve, needing to be well versed in a specific vendor’s technology to develop interfaces
- You find yourself incurring additional costs for network connectivity and infrastructure
- You lack skilled analysts and find a need for extensive training
- Documents go missing, and your team is playing email ping-pong with customers trying to keep up with changes
- Your implementation manager is struggling to keep up with multiple shifting timelines
- You need to create a dedicated team of developers
Conclusion: Avoid This Trap
After researching HL7 and healthcare integration, you might find some developers conclude that HL7 is just too darn complex. They assume they can find and pioneer an easier way to integrate applications with key systems. But this isn’t really viable if you need to connect your application to inbound data from another system in your customer’s environment. Chances are, your customer is already using HL7 and they aren’t going to change the foundations of their data exchange just for a single vendor. Instead, use this issue to build your credibility with customers and prospects. Come prepared with smart questions shaped by a clear understanding of the interfacing lifecycle. And get them thinking: finally, someone who gets it.
Download a One-Page Integration Checklist for Startups and Small Teams
The Integration Checklist for Startups and Small Teams will help you identify all the details you need for effective interfacing. The checklist covers everything from scoping and development through deployment. You’ll be ready to pass on all the information needed by your developers.