The Dual Journey: Healthcare Interoperability and Modernization

Interoperability in healthcare isn’t just a buzzword; it’s a fundamental necessity. It refers to the ability of IT systems to enable the timely and secure access, integration, and use of electronic health data. However, integrating data across different applications is a pressing challenge, with 48% of US hospitals reporting a one-sided sharing relationship in which they share patient data with other providers who do not, in turn, share patient data with the hospital.

The ability to share electronic health data seamlessly across various healthcare systems can revolutionize patient care, enhance operational efficiency, and drive innovation. In this post, we’ll explore the challenges of healthcare data sharing, the role of interoperability, and how MongoDB can be a game-changer in this landscape.

The challenge of data sharing in healthcare

Today's consumers have high expectations for accessing information, and many now anticipate quick and continuous access to their health and care records. One of the biggest IT challenges faced by healthcare organizations is sharing data effectively and creating seamless data integrations to build patient-centric healthcare solutions. Healthcare data has to be shared in multiple ways:

• Between internal applications to ensure seamless data flow across various internal systems.

• Between primary and secondary care, to coordinate care across healthcare providers.

• To patient portals and telemedicine to enhance patient engagement and remote care.

• To payers, institutions, and patients themselves, to streamline interactions with insurance companies and regulatory bodies.

• To R&D units to accelerate medical research and pharmaceutical developments.

The complexity of healthcare data is staggering, and hospitals regularly need to integrate dozens of different applications—all of which means that there are significant barriers to healthcare data sharing and integration.

A vision for patient-centric healthcare

Imagine a world where patient data is shared in real-time with all relevant parties—doctors, hospitals, labs, pharmacies, and insurance companies. This level of interoperability would streamline the flow of information, reduce errors, and improve patient outcomes.

Achieving this, however, is no easy feat as healthcare data is immensely complex, involving various types of data such as unstructured clinical notes, lab tests, medical images, medical devices, and even genomic data. Furthermore, types of data mean different things depending on where and where it was collected. Achieving seamless data sharing also involves overcoming barriers to data sharing between different healthcare providers and systems, all while adapting to evolving regulations and standards.

The intersection of modernization and interoperability

Modernization of healthcare IT systems and achieving interoperability are two sides of the same coin. Both require significant investments and a focus on transitioning from application-driven to data-driven architecture.

By focusing first on data and then connecting applications with a developer data platform like MongoDB Atlas, healthcare organizations can avoid data silos and achieve vendor-neutral data ownership. As healthcare interoperability standards define a common language, organizations might question whether, instead of reinventing the wheel with their own data domains, they can use the interoperability journey (and its high investments) to modernize their applications.

MongoDB’s document data model supports the JSON format, just like FHIR (Fast Healthcare Interoperability Resources) and other interoperability standards, making it a more efficient and flexible data platform for developing healthcare applications beyond the limitations of external APIs.

FHIR for storing healthcare data?

The most implemented standard worldwide, HL7 FHIR, treats each piece of healthcare data as a self-contained resource, which can be accessed through unique URLs on FHIR servers, similar to how web pages are accessed on the internet.

FHIR adopted a pragmatic approach for which there was no need to define a complete and unique set of resources for all the clinical data, but trying to get what most of the electronic health records (EHR) share. That is the 80% / 20% approach. For the 20% of non-standardized data, they created the famous FHIR Extensions, to extend every resource to the specific needs.

However, FHIR is not yet fully developed, with only 15 of the 158 resources it defines having reached the highest level of maturity. The constant changes can be as simple as a name change or can be so complex that data has to be rearranged.

FHIR is designed for exchange of data, however, as questioned above, it might be thought to be used also for persistence. In this post from Alastair Allen, he discusses the problems that could arise when using FHIR for persistence depending on the use case, and this chart aids in the decision-making.

For specific applications with no complex data, such as an Enterprise Master Patient Index (EMPI) to match and unify patient demographics across applications or to integrate data from wearables, leveraging FHIR for persistence is a good approach. However, building a primary operational repository for broader applications like a Patient Summary or even a Healthcare Information System (HIS) presents a significant challenge. This is because the data model these applications require for a specific organization goes beyond the capabilities of FHIR, and solving the bias through FHIR extensions makes this an inefficient approach.

OpenEHR as an alternative approach

In Catalonia, Spain—for about 8 million people and roughly 60 public hospitals—there are 29 different hospital EHR systems. This fact converts Catalonia to a long-experienced actor in healthcare interoperability. Each hospital maintains a team of developers exclusively focused on building interoperability interfaces. This is not a one-time cost, but it is a fact that there will be an increasing demand for data sharing. This will never end, and the costs are increasingly higher.

In Catalonia, as well as in other European regions, some thought about changing the paradigm. Rather than implementing interoperability interfaces, why not create new applications that are implicitly interoperable? This is what openEHR proposes, defining the clinical information model from the maximal perspective and developing applications that consume a subset of the clinical information system. This is what the openEHR fans relate to as “Interoperability.” It’s not a protocol but an open architecture.

However, while FHIR is very versatile—offering data models for administrative and operational data efficiently—openEHR focuses exclusively on clinical data. So while a combination of FHIR and openEHR can solve part of the problem, future healthcare applications need to integrate a wide variety of data, including medical images, genomics, proteomics, and data from complex medical devices—which could be complicated by the lack of a single standard.

Overcoming this challenge with the document model and MongoDB

Now, let’s discover the power of the document model to advance interoperability while modernizing systems. MongoDB Atlas features a flexible document data model, which provides a flexible way of storing and organizing healthcare data using JSON-like documents. With a flexible data schema, healthcare organizations can accommodate any data structure, format, or source into one platform, providing seamless third-party integration capabilities necessary for interoperability. While different use cases will have different solutions, the flexibility of the document model means MongoDB is able to adapt to changes.

Figure 2 below shows a database modeled in MongoDB, where each collection stores a FHIR resource type (e.g., patients, encounters, conditions). These documents mirror the FHIR objects, conserving its complex hierarchy.

Let's imagine our application requires specific fields not supported by FHIR, and there is no need for an FHIR extension because it won’t be shared externally. We can add a metadata field containing all this information that is as flexible as needed. It can be used to track the standard evolution of the resource, the version of the document itself, tenant ID for multi-tenant applications, and more.

Another possibility is to add the searchable fields of the resource as key-value pairs so that you can retrieve data with a single index. We can maintain the indexes by automating this with the FHIR search parameters.

In a single repository, we can combine FHIR data with custom application data. Additionally, data in other protocols, such as DICOM metadata and OMOP, can be integrated, providing unparalleled flexibility in accessing your data. This setup permits access through different endpoints within one repository. Using MQL (the MongoDB Query Language), you can build FHIR APIs or use the MongoDB SQL interface to provide SQL querying capabilities to connect your preferred business intelligence tools.

MongoDB’s developer data platform

At the center of MongoDB’s developer data platform is MongoDB Atlas, the most advanced cloud database service on the market. It provides integrated full-text search capabilities, allowing applications to perform when making complex queries without the need to maintain a separate system.

With all the possibilities of generative AI, multi-dimensional vectors to represent the meaning of the data are becoming a necessity for all vendors and organizations. MongoDB’s capabilities of storing vectors alongside the operational data while providing the vector search aggregation stage functionality, enables fast data retrieval with the possibility of pre-filtering your data with any of the data existing in your operational database. This is executed in a single query, deriving in a best-of-class performance operation.

These capabilities transform a single database into a unique, powerful, and easy-to-use interface capable of handling diverse use cases without the need for any single-purpose databases.

Solving the dual challenge with MongoDB

Achieving interoperability and modernization in healthcare IT are challenging but essential. MongoDB provides a powerful platform that meets organizations’ modern data management needs. By embracing MongoDB, healthcare organizations can unlock the full potential of their data, leading to improved patient outcomes and operational efficiency.

Refactoring applications to incorporate interoperability resources as part of documents—and extending them with all the requirements for your modern needs—will ensure organizations’ data layers remain robust and adaptable.

By doing so, organizations can create a flexible architecture that can seamlessly integrate diverse data types and accommodate future advancements. This approach not only enhances data accessibility and simplifies data management but also supports compliance with evolving standards and regulations. Furthermore, it enables real-time data analytics and insights, fostering innovation and driving better decision-making. Ultimately, this strategy positions healthcare organizations to effectively manage and leverage their data, leading to improved patient outcomes and operational efficiencies.