Healthcare is a space ripe for innovation; there are many interesting problems to solve in terms of delivering healthcare and its administration. I often have clients ask, can off-the-shelf integration products support their healthcare record systems?
The big challenge in this space is integrating with existing Electronic Health Record (EHR) systems. This is getting easier with the advent of FHIR and the Cures Act. However, it is still extremely challenging, especially for small companies, to take on the burden of integrating with every health provider’s back-end systems. In large health systems, there can be many products with which to integrate for a single solution.
But with the 2020 Cures Act enforcing FHIR, is this still a problem?
The answer is, to an extent, yes.
The rollout of FHIR isn’t enforced until 2022, so if you’ve got an application you’re trying to launch, you can’t be certain that FHIR is an option. It also only enforces limited functionality (primarily reads only at this time), meaning your application needs might not be fully supported.
How about HL7 as a fallback?
It’s possible, but there are inconsistent implementations.
Thankfully, there’s a myriad of Integration as a Service (IaaS) products that support this kind of integration – mapping EHR systems to a set of canonical models abstracting complexity, typically handling connectivity setting up VPNs to the health system’s environment; and typically handle monitoring of the connection. A couple of examples in this space are Redox and Interfaceware. This can be a desirable option for integration, but it may not always be suitable for your organization.
Here are some considerations:
Development Speed, Supported Interfaces, Vendor Lock-In
Simple products may require minimal integration surface area. And not be worth taking on the complexity of including an integrator into your systems. However, it will be worth creating an adapter layer in the application to handle different provider implementations.
Depending on your integrator, you may not have all your data requirements covered. The integrator may develop new models for you, but it will be prioritized against their roadmap and other customer needs. There’s potential complexity when it comes to organizations, reliability, and system monitoring.
Developing against a single model instead of every single customer’s individual model simplifies development. That said, if not all of your data demands are covered, you have the complexity of using a partial roll-your-own and an integrator product, increasing complexity and your surface area for failure.
Vendor Lock-In
If you choose to use an integration vendor, you’re choosing to use their model structure and operational paradigm. This makes changing vendors challenging. Even if you plan architecturally, swapping out a key piece of technology is expensive and time-consuming.
Speed of Customer Rollout and Experience
One of the key benefits of Integration as a Service ( IaaS) products is their experience navigating the complexities of integrating with a health care provider’s systems. Providing a smooth process, their expertise can be invaluable if not readily available within your existing internal teams.
Products already in place can reduce implementation time, allowing for a quick connection to their services. However, the integration provider becomes an extension of your product, including customer experience. You must be comfortable with how this approach is handled since it will directly represent your organization with customers.
Another consideration is rollout availability – each vendor has limited implementation capacity. Your product rollout will be prioritized against their other customers; rollout timing may not be in your sole control.
Security and Operational Ownership
Rolling out to a healthcare system is not always straightforward. Oftentimes you need to go through a security review process. If your integration provider is new to their systems, it will likely mean two security review processes – one for your provider and one for your product.
When you outsource integration, you’re handing off ownership of security, reliability, monitoring, alerting, and all manner of operational context. Be certain that you are comfortable with a vendor team managing operational capability rather than your internal team.
Cost
There are many different cost models, but one of the most common is a per-installation model. When your customer base is small, this model can be hugely beneficial when you weigh it against all the operational overhead you take on managing it yourself. As your customer base expands, though, this cost increases dramatically. If considering cost alone, consider the growth rate of your organization and customer base.
So, how do you choose?
Largely, the choice depends on your operational readiness, your development capacity, and your customer projections. If you’re a brand new startup with no experience integrating with the medical space, then the options above stack heavily in favor of using an integration product. If you’re an established company with an existing customer base and existing operational capability, then you may want to consider your roadmap and the data requirements you have now and in the future.
AIM Consulting is a trusted advisor for EMR, EHR, RIS, and Healthcare Providers – building devices to generate, collect, analyze, and transmit data – creating a fully connected infrastructure of health systems and services. Our team of experts is available to discuss Emergent Telehealth systems, Cures Act, FHIR, and projects aligned to MedTech & IoMT. We look forward to hearing more about your organization’s needs and how our team can support your internal teams.
ABOUT THE AUTHOR: STEPHEN VERSTRAETE
Stephen has over 15 years of experience in software development and technology management, specializing in application architecture, cloud, and microservices. Stephen’s philosophy is that projects and technology should be simple, truthful, and beautiful. He believes in setting clear expectations and honest communication is essential for project success. He enjoys working with both technical and non-technical people to innovate solutions that provide value. As a leader, Stephen believes in creating environments of team-learning where communities can learn from collective experience and adopt practices that improve the overall team performance.
