Interoperability: Are you Frankenstein or an Onion?
By Brian Dobosh, VP Digital Systems and IT&S, RWJBarnabas Health
In my sixteen-year career at RWJBarnabas Health, I have seen the dawn of the modern-day Electronic Health Record (EHR). The health system has grown significantly since 2006 through mergers, acquisitions, and partnerships. This has resulted in the largest academic health system in NJ. Each time the health system grew, it introduced a new EHR or another instance of one already owned. At one time, there were seven different instances of an EHR. We are down to four, with plans to be on one by 2024.
EHRs have also grown since then, adding capabilities for interoperability because of enacted laws. Meaningful Use Stage 1 in 2010 was the beginning of EHRs as a sharing tool and has ushered in the interoperability features present today. The design of a health system plays a significant role, as it often decides the EHR infrastructure. Do you have a single instance of one EHR? Do you have one EHR with multiple instances? Multiple EHRs? *gasp*
Interoperability can be like Frankenstein or like an onion. Frankenstein interoperability is taking a piece-by-piece approach and hoping the patchwork will keep the system functioning. Often, this approach entails a sizable investment in both third-party software contracts and staff to support it, all to keep the clinician and customer experience consistent. The onion approach described below is the gold standard of interoperability. Each layer allows the organization to build its interoperability presence and maximize its reach for its patients throughout the community.
1. EHR
The core of the onion is the EHR. Intrinsically, the EHR is the most important part of building interoperability in an organization. Choosing one that easily sends, receives, and incorporates data, along with its ability to connect with third-party vendors to enhance capabilities, will decide how successful the health system can be in its interoperability journey. Choosing the wrong one can make the other layers of the onion impossible.
2. Sharing
The second layer of the onion describes how easily you can share your EHR with others. There are situations where a JV, partnership, or affiliate uses a different EHR to treat the same customers. Giving the ability to share the same instance lowers entrance costs, keeps one patient record, separates finances, and deepens the relationship of each organization.
3. Referral Network
The third layer of the onion describes connecting the rest of the community to your system. These are organizations that refer customers to your services (e.g., Laboratory, Radiology) but are not affiliated. E-Faxing is the preferred solution when an organization lacks this fundamental layer. EHRs can now supply “lite” versions of their software to allow groups to connect and keep consistency for the customer and health system. This approach tackles two key items. First, giving non-affiliated practices data they need to help the customer. Second, easing the burden of connectivity to foster the relationship of referrals to the health system.
4. Intra-EHR Data Sharing
The fourth layer is the exchange of data between health systems using the same EHR. This sounds simple, but often, EHRs miss the mark. Sharing can involve manual work by clinicians, which contributes to burnout. Sharing should be automatic and seamless. The intra-EHR sharing must go beyond the minimum Clinical Continuity Document (CCD). Data between like EHRs should share even more to complete the whole picture for a customer. The United States Core Data for Interoperability (USCDI) standardization is pushing this forward by expanding the amount of data shared in a CCD. This is a win for everyone.
5. Inter-EHR Data Sharing
The fifth layer is the exchange of data with dissimilar EHRs. When Meaningful Use (now Promoting Interoperability) began in 2010 with the introduction of the CCD, the bar of interoperability was set incredibly low. The CCD allows organizations to supply standardized blocks of clinical data to any other EHR system. There were two issues with this concept. First, programmers had to build logic into these systems (if they even could) to try to automate the process. Second, figuring out the direct addresses (think secure email) to send to was absurdly difficult, as there was no global address book to use. This often ended up with organizations meeting the bare minimum requirements to pass the Meaningful Use metric. Fortunately, Health Information Exchanges (HIE) are now prevalent and take the burden off the health system for exchanging data by serving as the repository for everyone connected.
6. Population Health Management
The sixth layer describes the health management of a population of customers. Health systems have a responsibility to care for the lives of assigned customers. Accountable Care Organizations (ACOs) help to improve care, control costs, and collect pertinent information about these customers. This allows customers get the right care, at the right time, while preventing duplicative tests and services. Having the ability for these ACOs to easily connect to the EHR and input this information is invaluable to the customers’ health journey.
7. Web services, APIs, FHIR, and SMART on FHIR
The final layer of the onion are third-party services. Third-party services should be complimentary. The extensibility of using web services, APIs, FHIR, and SMART on FHIR, allows the organization to enable services that will never be native to an EHR. Google & Apple Health, smart peripherals, and customer education services can pull and push data into the EHR through these means without intervention by clinicians and take the guesswork out for customers.
Interoperability is one cornerstone of customer and provider experience. When an organization has a Frankenstein approach, customer experience dips and clinicians become overburdened. The onion framework ties together the organization’s footprint, customer expectation, employee satisfaction, and connection to the community. So, which are you? A Frankenstein or an Onion?
