If It's Possible, We Can Integrate It

What you must learn is that these rules are no different than rules of a computer system. Some of them can be bent, others can be broken.” – Morpheus, The Matrix

However, despite our progress, there are still hundreds of systems that we have not integrated with. In the ambulatory setting alone, there are more than 650 technologies certified for Meaningful Use Stage 2. While working with the top 30 already gives us a leg up and covers a majority of the industry, it’s not uncommon for us to hear about a new piece of HIT technology that our customers and prospects are looking to integrate with.

Despite your perceptions of us as an integration services team, we don’t have any secret super powers to solve problems with interoperability. Our solution, as simple as it may sound, is just being the best at our specialized skill set as we can be. This means:

• Writing interfaces and transforming data to programmer-friendly formats using Mirth, an open-source interface engine.
• Setting up VPNs when needed on open-source Strongswan appliances.
• Having a team of experts in health data and project management on hand to analyze project needs.
• Everything hosted on the HITRUST-certified Datica Platform, staffed by a team of ops, security, and compliance experts.

While we may know about obscure technologies that power integrations at a given EHR vendor, our process is likely similar to anyone else’s when kicking off a project. As such, it’s worth noting that some projects may be impossible to complete due to external constraints. Turns out that data blocking in healthcare is really a thing. So, if Datica is not helping you in your pre-sales process with customers, it’s up to you to ask all the necessary questions to ensure that you will be able to successfully integrate your application with the EHR and site in question.

Four essential questions digital health teams should ask their customers

1) Can your EHR support my digital health product’s scope?

The most common data integration formats we use to exchange health data are HL7v2 and CDA-formatted documents like CCDs and CCDAs. Even though these data formats are standards, this doesn’t mean all EHRs support exchanging data through these formats. In fact, some EHRs have no integration capabilities at all. Make sure the EHR supports the data standards that you need. Particularly, make sure the EHR supports the data standards in the method you need them. For example, if you need CCDs pushed to you at the end of a visit vs. pulling them proactively, you will want to ensure the EHR has the capability to manage that process. There is a very real possibility here that the EHR may have no suitable integration technology, which may limit your data integration possibilities to flat-file style extracts or may require manual data entry to power your application.

It’s worth noting that there are some integrations that seem simple but are really complex. For example, while it would seem obvious that any EHR could expose provider availability to schedule appointments, this is actually rare functionality. It’s easy to know what appointments are scheduled/canceled but it’s hard to know when you can schedule an appointment. Just because there are no appointments from 12:00-2:00 doesn’t mean the provider isn’t doing hospital rounds or research. As such, what may have been an easy API query on Allscripts, Epic, and Athena turns into a nightmare of stored procedure R&D and database access requirements with smaller EHRs. This is why it’s good to have experts on hand to help you understand the rules of the road and to match integration expectations to reality.

2) Do you have the internal or external resources to perform the integration work?

Smaller organizations may have an EHR with HL7, CDA, or API integration capabilities, however, they might not have the personnel to configure their instance to do that integration. It’s not uncommon to find a nurse or clinic administrator who is also the EHR administrator. While they may be able to manage their provider’s schedules or handle some claims, setting up an interface or API may be foreign to them. This can be a blocker for a project.

Datica cannot directly assist with a backend EHR build. This is usually for one of these reasons:

• The EHR vendor would require us to sign an agreement that had some kind of non-compete clause to it.
• The EHR vendor will not grant us access to their systems.
• We simply lack the expertise in 650 EHRs.

As such, if the organization needs assistance with an internal EHR build, it’s out of the scope of our standard integration services. While we may be able to refer the organization to other consultants or vendors who can assist with this EHR build, additional scope and cost considerations would be included.

3) Can you commit to getting work done within reasonable timelines?

The top KPI for a fast, successful installation is an agreed upon project plan with assigned task owners and due dates. At larger orgs, the only task owners are typically the EHR integrators (Datica) and organizational IT. However, in some integrations, there may be dependencies on vendors to perform some pieces of setup. This is particularly true if the org is not licensed for a given interface yet or if the EHR vendor hosts the organization’s EHR instance.

Not to sell you a horror story but, sometimes, these timelines can be brutal. While many projects go live within a month of kickoff, we’ve also seen projects span a year due to EHR vendors dragging their feet on either contracting or infrastructure deployments. Other than badgering effectively, unless your customer’s organization can push their EHR vendor to move faster, it’s hard to make the process any faster than it is. If your integrated product must be live by a certain point to reach contractual obligations to your customer, make sure your customer has the means to get that system live by that point.

4) Who will validate clinical content and logic facilitated through integrations?

Your application may want to segment patients based on certain clinical attributes sent in the payload of the HL7 or CDA message. For example, you may want your application to send an alert when a patient with diabetes is admitted to the hospital. The question, of course, is how do you define patients with diabetes? Will they be manually defined by clinicians or will you be trying to define them by diagnoses from the admission, in their problem list, or by other clinical attributes like High A1C or being prescribed insulin?

While we can apply some logic to segment patients in our interface engine, we do not have clinical informaticists on hand to dictate or validate logic that we would create at your behest. The integration engine may not be the best place to have that application logic and you may consider those mappings and analysis to be IP of your company. You may decide that an organization purchasing your digital health product can validate your clinical content (Epic did this) or we are happy to refer you to informatics consultants who are qualified to assist you.

Evaluate the Integration’s TCO

With these additional parameters, you may want to re-evaluate the cost to integrate your digital health product. If you need to hire a niche EHR consultant to build an interface on the EHR itself and it costs $5k, can you pass that along to your customer or extract that value within your product? If not, you may debate the merits of deploying your product in a standalone fashion or adjusting the terms of your deal for your customer. If you’re new to this, we can help. All Datica Platform customers can engage with Datica for pre-sales support to define implementation strategies and to determine feasibility and ease of integration at a given site.