Using data to improve quality of care

For many of us, an on-going relationship and history with our primary care physician can certainly help ensure more personalized care. When it comes to care gaps, however, it’s not just a matter of knowing a patient’s history. Care gaps are the result of comparing care and services rendered, the results of screenings and tests, and treatment recommendations based upon the patient’s historical claims data and health records. During a typical visit, finding, comparing, and summarizing all of this information quickly, and turning that into personalized care gap recommendations can be challenging. Fortunately, Google Cloud, Exafluence (EXF), and MongoDB have been working together to make identifying and closing care gaps far more efficient, effective and easier than ever before.

Providers can enjoy a seamless user experience in SMART-on-FHIR, where clinical records turn into actionable care gaps and recommendations, helping them provide better care, in less time, with seamless and secure data exchange with payers.

• With the SMART-on-FHIR application on Google Cloud, providers can safely and securely retrieve a patient’s clinical records from the Healthcare Data Engine (HDE) during patient office visits.

• Providers can immediately request care gap recommendations from payers by sharing critical data and insights from patient health records with payers.

• Payers can receive care gap requests from providers, and leverage an enriched data set, combining patient health records, plan benefits, and treatment pathways, to identify care gaps in real time and send those back to the provider before the patient leaves the exam room.

• Providers can deliver personalized and insightful care to patients by incorporating care gap recommendations, helping both increase quality of care, and raise HEDIS scores.

Our approach to computing care gaps and how we’re making them available to the clinicians at the point of care

1. Identify data sources for computing the care gaps

When care gap recommendations are derived using historical claims data only, they are not as accurate and timely. In addition to the historical claims data, access to the patient’s current clinical data is key to computing the precise care gap recommendations. Providers and health systems use Google Cloud’s Healthcare Data Engine (HDE) to aggregate clinical data from disparate healthcare systems and create longitudinal patient records. Data from HDE is accessible in a standard compliant HL7 FHIR format through well-defined REST APIs. Many health plans have implemented MongoDB Atlas to store and manage the claims, coverage, and membership data. The EXF Care-Gap service leverages the health plan data from the MongoDB Atlas database to compute care gap recommendations based on the HDE-hosted clinical data.

2. Define and implement rules to calculate care gaps

The EXF Care-Gap service calculates the care gap recommendations in near real-time and stores them in the MongoDB Atlas database as FHIR resources. The CareGap service calculates care gap recommendations by applying configurable rules against the aggregated dataset stored in the MongoDB Atlas database and the clinical data sourced from HDE.

3. Serve care gaps through REST API and SMART-on-FHIR App

Clinical systems used at the point of care will launch a SMART-on-FHIR compliant App, which retrieves the care gap recommendations from the EXF FHIR Server and displays them to the clinicians. The App fetches the patient’s current clinical information from HDE through Apigee HealthAPIx and submits it to the EXF FHIR Server to retrieve the care gap recommendations from the Care-Gap service in FHIR format.

How Google Cloud can help compute care gap recommendations

Apigee HealthAPIx and SMART-on-FHIR

Apigee HealthAPIx is an open-source solution to accelerate interoperability in Healthcare through standards like FHIR® (Fast Healthcare Interoperability Resources) and SMART® (SMART (Substitutable Medical Applications and Reusable Technologies). It runs on Apigee Edge with Google Cloud’s HDE as a back-end.

The primary purpose of the HealthAPIx solution is to enable the API Program in healthcare organizations and provide API-level access to healthcare data. HealthAPIx solution comes with ready-made interoperability APIs to meet the Interoperability and Patient Access final rule (CMS-9115-F) published by the CMS. It enables Payers, Providers, and technology vendors to meet the regulatory and compliance requirements defined under the 21st Century Cures Act finalized by the Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS).

With Apigee HealthAPIx, healthcare providers and health systems can:

• Manage, secure, and scale APIs with an enterprise-grade platform that is FHIR-server agnostic
• Quickly close innovation gaps and keep up with digital advances
• Easily ingest healthcare data from internal, external, or open-source FHIR-ready partners

Google Cloud Healthcare Data Engine

HDE aggregates clinical data from disparate health systems to create an interoperable, longitudinal patient record. HDE can ingest and map data from HL7v2 messages and CSV and FHIR formatted flat files. It supports data ingestion in batches and near real-time. HDE harmonizes and reconciles the ingested data into FHIR R4 format, flattens it, and stores it in BigQuery. Patients’ longitudinal health records in HDE are accessible through REST API with FHIR formatted payload for transactional processing. The same data is also accessible from BigQuery through SQL-friendly interfaces for analytical processing. HDE incorporates a cloud configuration for healthcare that extends Google Cloud’s security and privacy, with support for HIPAA and HITRUST best practices. HDE leverages Google Cloud’s highly scalable and secure HIPAA-compliant managed services like Google’s Cloud Healthcare API and BigQuery.

EXF FHIR with EXF proxy in Apigee X

When it comes to managing, securing and scaling your FHIR API, an enterprise-grade platform that is FHIR-agnostic is more than recommended, it’s essential.

A FHIR server, in its most primitive format, handles inbound requests, and processes, retrieves and exchanges data over REST-based API’s, using standardized FHIR Resources, to and from underlying data sources. They have the responsibility of doing the most low-level data processing for data exchange and data format standardization, and keep us compliant with FHIR mandates.

When it comes to delivering your FHIR API’s to the outside world, security, scale and performance are mandatory. An API gateway is essential, and sits in-between your backend FHIR API, and the external clients that interact with them. Google’s Apigee X makes it easy for healthcare IT delivery teams to safely, securely, and efficiently deploy and manage your FHIR API, helping you go to market faster, with production-grade solutions and API-based digital services.

The EXF FHIR server offers unparalleled flexibility, with the ability of giving you the choice of pairing your FHIR APIs with new or existing MongoDB deployments. All flavors of MongoDB are supported, from Community-Server, Enterprise Advanced, and MongoDB Atlas. Having the flexibility to deploy in the cloud, or on-prem, or in hybrid-mode, also provides configuration for whatever requirements your organization must meet. By leveraging new or existing MongoDB deployments, the EXF FHIR server helps you reduce complexity, and more quickly integrate with existing organization datasets and sources.

EXF Care-Gap Service

Combining, enriching, and aggregating data from the provider’s FHIR resources, along with the existing plan, benefit, and treatment data, the EXF Care-Gap service can deliver actionable care gap insights in real time. It can also map and transform existing data into FHIR-native format, helping healthcare organizations bring FHIR-based, modern applications to market from existing legacy sources.

The Exafluence and MongoDB teams can work with the healthcare organizations to define, plan and execute the implementation of the Care-Gap service.

MongoDB for FHIR

MongoDB is a Document-based database, which implements the JSON-based Document Model, and as such, is a natural fit to store all of your FHIR Resources. Your FHIR Resources can be stored in native format within MongoDB, with no modification needed to the schema definitions. This helps accelerate application delivery, simplifies your overall data architecture strategy, and allows FHIR to serve as not only the data model supporting your API’s, but the new, canonical model that your organization can migrate to. The extensibility and flexibility of the Document Model also allows you to extend your FHIR Resources, allowing you to leverage native FHIR, and add the information needed to support your organization’s unique requirements.

Unlike many COTS FHIR solutions, leveraging MongoDB as your underlying datastore also allows you to reduce the number of databases needed in your tech-stack. Typically, a FHIR server will ship with an underlying database, and a relational schema that differs from the FHIR schema. These COTS solutions often don’t allow you to change the underlying database platform, and even worse, do not give you access to the underlying database directly. At MongoDB, we believe healthcare organizations should be able to do more with FHIR collections, than simply serving the external FHIR API. With direct access to the underlying database, and the MongoDB Document Model, organizations can build a new Operational Data Layer that helps modernize to Domain Driven Design principles, serve FHIR API needs, and helps build any new applications or services needed from one common data layer. To learn more about using MongoDB with FHIR, and as an Operational Data Layer, click here to read more about implementing an Operational Data Layer.

Building a more seamless, interoperable future

The approach to make care gaps accessible to clinicians at the point of care is an example of how Health Plans and Providers can exchange important healthcare information in real-time using interoperability standards like FHIR and SMART-on-FHIR regardless of the underlying technology used to implement the specifications. In this instance, the providers and health systems leverage Google’s FHIR implementation in HDE and HealthAPIx, while the Health Plans leverage FHIR implementation from EXF and MongoDB for exchanging key healthcare information in real time.

The solution outlined in this blog post helps providers and health plans to receive better scores and star ratings from the government, with significant medicare financial incentives, and it enables providers to deliver personalized and contextual care for better patient outcomes.

We look forward to partnering with healthcare organizations to build a standards-compliant and interoperable foundation for seamless, prompt, and secure information exchange between providers and payers.

References

1. Building FHIR Applications with MongoDB Atlas
2. Learn more about FHIR on MongoDB
3. Using Apigee X with the Cloud Healthcare API | Cloud Architecture Center
4. GitHub – cqframework/cql-execution: A JavaScript framework for executing CQL
5. GitHub – cqframework/cql-exec-fhir: A FHIR data source for the JavaScript CQL Execution project
6. Care Gaps – AmeriHealth Caritas Delaware
7. HEDIS Medicare Health Outcomes Survey – NCQA
8. Introducing: NCQA on FHIR
9. Beneficiary Claims Data API
10. GitHub – google/medical_claims_tools: Examples, libraries, and tools for working with bulk FHIR data (particularly FHIR BCDA Claims at the moment)
11. 2023 Medicare Advantage and Part D Star Ratings