In the first part of this blog post, we discussed why integration has become so vital for the healthcare industry today, and its role in moving the healthcare innovation cycle forward. In the second part, we will cover the present day challenges associated with integrating various healthcare systems, and choosing interoperability and integration models.
Challenges
Large volumes of data, from disparate data sources, continue to flood the healthcare market due to large-scale innovation. These unstructured data requires good amount of processing to be meaningful and to give the right intelligence. This poses some major challenges for integration:
Complexities of Bidirectional Integration
Unidirectional integration, in which data gets transferred from upstream to downstream systems, is no longer sufficient today. As providers are expected to make evidence-based decision making, they need access to both raw and processed data. This means, core systems should have data from all the disparate systems. This makes bidirectional integration a must-to-have, but for that to work, the systems involved should have placeholders to receive data from the integrated systems. Most often, these systems have finite placeholders limiting the amount of data the base system can receive. It is also a challenge to predict the placeholders, be it a pain score, a care score or assessment data, as these are rapidly increasing day-by-day.
Disparate Data Formats and Systems
In healthcare, patient data is captured in different systems in different formats. Say, a patient’s broken arm looks like an image in the medical record, but appears as an ICD-10 code S52.501A in the claims data. Following are the challenges in this regard:
• Integration should enable the systems to process both structured and unstructured data.
• Every system defines its own custom solution for integration which makes it difficult for the target systems to integrate with the multiple disparate systems.
• Further, most base systems offer only pull option and not push option (due to HIPAA and security reasons). So, the downstream systems, sometimes, don’t have real time discrete data.
Evolving Industry Standards
With rapidly evolving standards, integration work is never over; rather it’s a continuous process. Standards like Fast Healthcare Interoperability Resources (FHIR) provide lightweight integration between systems; however, that may not be sufficient for most of the new solutions. Also, continuous evolution of standards cause the APIs to expand across systems, causing delays and additional cost in integration. Regulations such as HIPAA mandates protecting and securing patient data in the receiving systems as well.
Interoperability Models
For integrating various applications or products in order to have the data in sync, there are few interoperability models that are defined as below:
Push
In this model, data is sent from the source to target as an encrypted transmission between sender and receiver. It assumes that infrastructure and legal agreements are in place, enabling widespread sharing of data. In such transmissions, the access is limited to two parties, with no scope of a third party’s involvement. Push model doesn’t have standard audit trails.
Pull
In this model, data is pulled by the target from the source system as an encrypted transmission. This model also assumes that legal agreements and permissions are in place for data sharing but with no standard audit trails.
View
In this model, the access is given for the receiver system to view the data in the source system. Security approaches are defined between systems and agreements are made for viewing data. The data is never transferred between systems in such cases.
Distributed Ledger (Blockchain or HashGraph)
This model provides a universal set of tools for cryptographic assurance of data integrity, standardized auditing, and formalized contracts for data access.
Integration Models
Depending on your unique challenges and business scenarios, choose one of the following integration models:
Custom Integration
Custom integration includes the use of custom or standard APIs, flat file data exchange, integration via database etc. The interface types that are commonly used in custom integrations are Data file exchange, Database integration and Web-service integration.
Such integration requires technical expertise, knowledge of custom or standard APIs and most importantly, involves time and cost!
Integration-ready-software
In this case, the software comes with ready-to integrate and out-of-the-box ‘plug and play’ options (ex: Google drive). However, the options are limited to most obvious and key integration needs.
Integrator Platform
Such platforms come with the capability to support different types of protocols. They also enable ready-made integration for specific products that the vendor partners with or supports. (ex: cloud-based platforms).
What are your unique integration needs and challenges? Let us know in the comment session.
