How to Overcome the Technical Challenges of Lab Integrations

In our previous post, we discussed three types of lab software integrations and the value of each for NGS clinical diagnostic laboratories. In this post, we’ll look at some of the key technical challenges labs face with each type of integration and how the right integrator can help you address them.

Once lab and technical leads have recognized the importance of integrating the various software systems, there are a number of questions to consider. Which systems should be integrated first? How quickly can they be integrated? What’s it going to cost? Who’s going to do the work? A “heads up” on some of the challenges that come with each type of integration can help you make better choices on how to proceed. This is true whether or not you hire a trusted partner to help with the integrations.

Each type of integration brings its own set of challenges

Instrument integrations

Instrument integrations—used to connect analytical instruments with software such as laboratory information management systems (LIMS)—can be challenging because labs typically have no control over how data is formatted and exchanged. Some instrument vendors do a great job of structuring and documenting data exchange, but some instrument integrations will require contacting the vendor for additional documentation or examples that can be reverse-engineered.

Instrument integrations might be file-based, HL7-based, or use an application programming interface (API). The following table lists the pros and cons of each type based on our experience of working with them daily.

Type	Pros	Cons
File-based	Relatively quick to develop and test. Minimal IT overhead (e.g., the instrument does not have to be on a network or accessed via a VPN). Resilient in the face of software and network issues.	Lab techs will still need to manually transfer files between the instrument and LIMS. This will slow down the process and can result in errors.
HL7-based	A fully automated process that requires no additional intervention from users. If intervention is needed, users usually interact via the instrument’s interface. Interface is usually documented, supported and relatively simple to deploy.	Requires instruments to be on the same network as the software. This can be a challenge for labs that host their LIMS in the cloud (e.g., AWS) and may require significant IT overhead.
API-based	A fully automated process that requires no additional intervention from users. If intervention is needed, users usually interact via the LIMS interface.	A limited number of instruments support API integrations. Requires instruments to be on the same network as the software. This can be a challenge for labs that host their LIMS in the cloud, as it is with HL7-based integrations. Since the underlying communications are invisible to users, it can be difficult to debug or work around issues that occur in the field.

Data exchange is the key to integrating instruments with the LIMS, but the harder the data is to work with, the more complicated the integration build will be. For instance, if a QC instrument outputs multi-page spreadsheets—that require several copy-paste actions and a series of calculations to get to the final result—the integration to transfer that data to the LIMS will be complex and require a high level of integrator expertise.

Instrument software might also be missing important indexing information. Some instrument software makes it difficult to associate sample results with physical samples, so it can be a challenge to match test results to the right patient. This presents a significant area of integration work and requires stringent quality controls. Instrument software that neglects to incorporate a method for matching sample data to patients requires a custom-built workaround.

EMR/EHR integrations

When it comes to integrating clinical lab and hospital systems, a lack of compatibility can be an issue. Hospital electronic medical record (EMR), electronic health record (EHR), and laboratory information systems (LIS) tend to be patient-centric. They track demographic and personal information associated with a patient. Laboratory information management systems (LIMS), however, are intended for a research or clinical lab setting. Some LIMS are patient-agnostic and only store information relevant to the test sample. To integrate these systems effectively, labs need to configure their LIMS to account for this difference.

A further challenge relates to the history of hospital software application development, done in parallel with standardizing the HL7 specification. Most U.S. healthcare organizations (95%) use HL7 version 2. While later iterations of the specification have been refined to more tightly support a universal standard, earlier iterations allow considerable room for interpretation. In this context, building into locally interoperable solutions is favored over global refactoring of a large complex network, which is why version 2 is still extremely common today.

Labs using these earlier iterations of HL7 face a significant technical burden in updating established systems toward a more current and robust universal standard. That’s why they often delay moving toward more recent versions, whether version 3 or FHIR. As consultants, we’ve often encountered software with varied implementations, across different versions of the HL7 standard, which presents interoperability issues and adds another layer of complication to an integration that’s already complex.

To address the issue of interoperability, you may need to build a custom interface or use an integration engine such as Mirth Connect or Lyniate Rhapsody. Software consultants with experience working through HL7 version 2, HL7 version 3 (CDA), and FHIR compatibility issues can offer immense value in this exercise.

Enterprise software integrations

Enterprise software integrations can be a challenge to build and maintain because the systems being integrated support unique business use cases. The best approach is to choose a small set of high-value functionality. Once the integration is running smoothly, you can make incremental improvements and add additional features.

Labs can also find rework requests that cross system boundaries difficult to manage. Most integrations focus on the successful progress of samples through the multiple systems involved. However, if a quality check determines that a sample needs to be reworked in another system—for instance, a secondary analysis determines that resequencing is necessary—keeping both systems synchronized can be difficult.

Also, don’t forget about software upgrades, which are unavoidable. While vendors strive not to break existing interactions with their enterprise software improvements, it’s critical that the developers building these types of integrations keep software updates in mind. Whenever updates are released, you must retest integrations and make any necessary modifications to ensure everything continues to function correctly. Automated testing can greatly improve the efficiency of software updates.

When it makes sense to hire an integrator

As we mentioned in our previous post, some labs may have the in-house expertise to develop these integrations. But in our experience, many laboratory and technical leads prefer to focus their attention on the core business of the lab. In order to do this, they choose to hire a software integrator to do the heavy lifting involved in complex integrations.

An experienced software integrator:

• Has the appropriate clinical healthcare domain expertise.
• Understands how the instruments and systems work together.
• Asks the right questions to address the key pain points.
• Ensures information is translated properly between systems.
• Builds software to adhere to specifications such as HL7.
• Develops integrations that work with the systems a lab currently has in place.
• Designs and develops robust integrations based on software engineering best practices.
• Has a mature multi-system configuration management process.

Although hiring a consultant with lab software integration expertise requires an investment upfront, the value of professionally developed integrations grows over time. Integrations that are well-designed using software engineering best practices are easier to update than those that are developed in an ad hoc fashion, and they provide significantly more reliability and speed than manual processes. Taking advantage of consultants to develop complex software integrations also frees up your lab’s skilled employees to work on more interesting scientific problems to benefit both patients and healthcare providers.

Contact us to discuss how integrating your laboratory software systems could help you boost productivity and efficiency.