By Brian Carter, senior vice president of product, Validic.
Clinicians, CIOs and virtually every person in a decision-making position in a health system is courted multiple times a week by third-party solution developers with amazing products to help them with some of their most pressing problems. The features look great, but at some point they have to ask: does it integrate with my existing clinical workflows in a way that makes it easy to use, hard to forget about, and actually save my team some time?
This question is extremely important; according to one study about clinical decision support (CDS), zero CDS interventions succeeded when they weren’t delivered automatically in the clinician workflow. By contrast, the same study showed that 75 percent of those interventions succeeded when they were automatically presented in clinical workflow. Workflow integration comes in a variety of flavors, with the value of that integration typically (and somewhat unfortunately) proportional to the amount of investment made in preparing for that integration.
Visual integration is the lightest-weight kind of integration. iFrames, SMART apps and “widgets” are all common technologies that come to mind when describing visual integration. Essentially, you are taking one application and layering it as a self-contained component inside another application. This ideally includes a single sign-on function so the person signed into the main application doesn’t have to sign into another widget on their screen.
A common example on the web is Disqus. If you scroll to the comments section of a web page to share your opinions, you’ll find a nicely-embedded component with other people’s comments. But, if you want to contribute a comment yourself, you have to sign in. This comment feature is actually a totally different application provided by another company called Disqus, which was visually integrated with a few lines of code.
Data integration is often what’s being talked about when interoperability comes up. Data integration simply means enabling the data from one application to flow meaningfully into another application. The concept is simple, but the application of this strategy can be highly complex. It involves getting two systems to not only get data from one place to another, but also to be formatted and codified in a way that the receiving system can actually understand it.
Technologies common in health care surrounding data integration include the emerging FHIR specification from HL7, legacy APIs provided by EHR vendors, health information exchanges that serve as intermediaries between different systems, as well as enterprise data warehouses and big data platforms. Data integration is a critical strategy whenever users of one system need information that users of another system have generated.
Triggers and hooks start to get deeper into true, real-time, automatic workflow integration. Both triggers and hooks involve one application enacting an action in another application based on a predefined event or condition.
- A trigger generally initiates from an external system and pushes something into a workflow in another application. A simple example here would be if a third-party remote patient monitoring solution observes a patient with a series of out-of-range blood pressure values. Rather than waiting for a clinician to log into the EHR and review this information, the solution initiates a trigger by pushing a notification into the EHR.
- A hook is when an application calls out to “hook” or pull information in from another application. An emerging standard in this space is CDS Hooks, which has predefined actions in an EHR workflow that can initiate a “hook.” For example, when a provider initiates a final review of pending orders, the EHR can “hook” a service to render a suggestion card to enroll the patient in a remote monitoring program if appropriate (or if not appropriate, remain completely behind the scenes and silent), without the clinician having to do anything to initiate that analysis.
Lastly, we come to full application service/workflow integration. This is where an existing clinical application builds workflows using services, or application programming interfaces (APIs), to create their own workflow using the smarts of a third-party system behind the scenes. The benefit of this approach is that the integration is truly seamless; users don’t know (or need to know) that they’re using services from a variety of different vendors or applications. For example, one major health system has created their own patient panel worklist for care managers that is 100 percent their own application workflow, even though it’s being fueled by the data and insights generated by a third party.
Today, all of these integration options must exist together to enable the right strategy for each organization. If you’re early in your project, and will only have a few users, a stand-alone or visually-integrated mode might make the most sense to get started. But, you need the confidence and assurance that your investment will scale with you; as the number of users goes up, the importance of deeper integration does too. History has shown that once you get beyond a pilot with virtually any third-party clinical solution, having options to integrate the data, initiate actions in native EHR workflows, and even building your own native workflows is critical.
At a time when physician burnout is higher than ever, and much of that burnout can be attributed to onerous work in front of a computer screen, it is important that new technical solutions solve this problem rather than adding to it. And, as digital health solutions and remote monitoring programs scale within an organization, deeper integration within existing systems becomes increasingly important. Too many times, “providers can just log into this neat web portal” is the answer for how a new solution fits into a provider’s day. This isn’t going to work in a future with dozens of third-party applications. In order to deliver solutions that providers can really use, thinking critically about the right way to integrate is necessary.