5 reasons why you shouldn’t do direct-to-database EHR integrations

Inside the children’s hospital, the halls were bustling with activity. Providers were rounding, kids were trying to be kids, and there was even a robot roaming the halls delivering supplies. All of this came to a screeching halt when their electronic health record system suddenly froze and became inaccessible. The staff scrambled to ensure that the most fragile patients were accounted for and visually monitored. It was as if a hurricane hit the hospital floor. This went on for hours until the system could be restored.

The EHR has become the backbone of care delivery. In a downtime, vital information about diagnoses, meds, care plans, and even where patients are physically located, is lost. Beyond the impact on patient safety, it’s estimated that downtimes like these cost hospitals more than $1M per hour in lost productivity. This particular downtime was caused by a misplaced database injection in the production instance of the hospital’s EHR system. A third party application had bypassed the safety of abstraction layers and integrated directly to the production database.

This is the wrong way to pursue EHR integration. The above story was true. An IT leader at the children’s hospital told me this after I described a very different vision for interoperability. Back at Redox, I polled some of our most experienced integration engineers for their take. Here are the top 5 reasons you shouldn’t do direct-to-database EHR integrations.

1. They break all the time

Direct to database integrations are notoriously brittle. Database schemas change frequently and aren’t published. It’s like trying to shoot a target blindfolded. Upgrades, updates, or minor changes that weren’t meticulously planned for and addressed can cause catastrophic failure. Due to the level of customization and frequent maintenance, even when tended to properly, direct-to-database integrations are susceptible to inevitable human error.

Even in a basic read-only scenario, a schema reorganization will mean one of the three following things:

1. Your integration is obviously broken.

2. Your integration is showing no data instead of real data.

3. Your integration is showing stale data.

All are bad.

EHRs typically won’t introduce breaking changes to known integration points (HL7, CDA, external facing web services, etc.) when they release new versions of their software because any changes here could require all downstream systems to have to make changes to their integrations. For many health systems, this would be a massive work effort given that it’s common for a large health system to have hundreds of downstream systems all connected via interface.

Direct-to-database connections bypass the interface layer and no longer benefit from the stability of it. It’s far more likely for an EHR update to break a direct-to-database integration than an interface based integration. Bypassing a critical check to try and accomplish something “quicker” dramatically increases your risk of failure.

2. They don’t scale

Changes always have to be made identically on both sides for the solution to not break, meaning they require a high degree of coordination (or as one of our engineers puts it, “a degree of magical thinking”) and significantly more long term maintenance than other integration solutions. Additionally, each direct to database solution is custom and doesn’t translate to the next opportunity. There is no reusability or marginal benefit when sharing with additional partners. Why invest in such a one-off, siloed connection when you can invest in infrastructure that the organization can leverage for additional use cases?

3. They overlook database integrity and performance

Database performance is the bloodstream of a system. If it slows down, everything else starts to fall over. Putting an API (including HL7v2) in front of it gives you many more levers to protect the database performance and integrity.

A well-engineered database will cache and index data to improve performance. As long as the EHR is solely responsible for the changes in the database (everything goes through the API) this works fine. Writing directly to a database bypasses the read/write of the caches and the index and hence breaks the system. Your risks range from significant errors to totally destroying your database.

4. Increased potential for malicious activity

The principle of least privilege is a well-known concept in the information security world. The basic concept is that each module should only be able to access information that is necessary to lower the potential for malicious activity. Giving access to database level operations implies full trust of the connecting party. Instead of granting access only to the information and resources that are absolutely necessary, you are providing your partner with capabilities far beyond their needs.

Another security practice database administrators rely upon is defense in depth. Because databases rely particularly heavily upon security controls implemented in other parts of a system, circumventing these with a direct-to-database healthcare integration leaves the system exposed to unchecked database actions, whether they originate from a malicious actor or a well-meaning colleague. As a steward of patient data, no healthcare organization should be comfortable with this level of risk.

5. Business logic is often not enforced at the database layer

Business logic is enforced at both the database layer and the application layer. Generally speaking, developers do much more enforcement at the app layer. By going direct to the database you can do things like bring a dead patient back to life or put a critical lab result in a place no one will ever see it.

As you might imagine, direct-to-database integration is generally not supported by most EHR vendors. Therefore, any integration strategy that includes a direct to database connection will require an alternate integration method for large EHR vendors that do not support this style of connection. If you’re hoping to build a scalable solution, going down the path of one-off direct to database integrations to meet the needs of one customer isn’t the way to go. From FHIR and APIs to HL7, X12, and the common flat file, there are too many alternatives out there to risk your application's success on direct-to-database connections.

***

Want to learn more about Redox's approach to EHR integration? Check out the overview video below!