Addressing Health Equity through Remote Patient Monitoring and Continuity of Care

Remote Patient Monitoring (RPM) programs are gaining momentum as healthcare organizations focus on improving Health Equity―aimed at addressing health disparities that impact underserved or underrepresented communities. This article discusses a solution utilizing RPM, and interoperability standards for healthcare, to achieve health equity goals.

The Current Situation

In a traditional healthcare model, the burden is placed on patients to undertake preventive steps and make healthy lifestyle choices. This is hard for low-income patients, especially those with chronic ailments like diabetes and obesity. Given their economic/health conditions, focusing on healthy diet, exercise, constant monitoring of vitals and preventive healthcare visits are luxuries that may be out of reach. Here are some challenges patients might face:

Working multiple hourly jobs that may not be conducive to breaks for healthcare visits
Access to transportation to show up to healthcare visits
Restrictions based on health insurance plans, which may limit their choices to fewer providers who may not be easily accessible/available

As a result, these patients may not get proper care, at the right time, to prevent avoidable health complications. When such complications arise, often times, they end up visiting Emergency Rooms (ER). These facilities may not have access to the patient’s medical records to make informed choices on a care plan. Therefore, the ER facilities may have to perform multiple scans and diagnostic procedures before starting treatment. This increases staff workload and may also affect care provided to those that truly need emergency care.

All these aspects contribute to waste and drive-up healthcare expenses. This, in turn, makes health insurance plans more expensive. Worst of all, these factors can affect quality of care, patient experience and contribute to staff burnout. These challenges warrant a shift in healthcare from episodic and symptom-based treatment to preventative, value-based care.

Introduction

Healthcare providers and payors are making a conscious effort to address these challenges by focusing on health equity initiatives. However, pro-actively monitoring and performing preventive intervention on a per-person basis presents economic, scalability, and sustainability challenges. In this article, we will discuss a health equity solution that leverages RPM at scale and Continuity of Care to deliver preventive care. The solution will focus on four main aspects:

Minimal disruption to patients’ day-to-day lives through the use of RPM programs
Eliminating the burden on patients to provide technology support for RPM
Promoting Continuity of Care through efficient exchange of a patient’s medical record between providers―realized through the use of a data repository that conforms to interoperability standards
Reducing cost through strength in numbers, by implementing this solution for a group of patients

We will discuss the process flow required to implement a sample use case. We will demonstrate how the process flow integrates solutions for RPM at scale and Continuity of Care. We will then discuss a reference implementation architecture, including AWS services, to implement this use case.

Solution Overview

Minimal disruption to day-to-day lives

RPM programs play an important role in minimizing disruptions to patients’ daily lives. The article RPM 101: What Is Remote Patient Monitoring, Its Benefits, and Uses? highlights some of the benefits of using RPM programs to monitor patients.

These programs utilize home health monitoring devices like blood pressure monitors, pulse oximeters, and body weight monitors. The devices, termed Internet of Medical Things (IoMT), make it possible to consistently collect personal health data to monitor patients, without the need for in-person visits. This enables healthcare providers to perform early intervention, if they detect any abnormalities. To minimize the burden on healthcare providers, it would be helpful to automate the anomaly detection and alerting process.

With the advent of telehealth visits, it is now possible to perform such interventions by integrating RPM with telehealth visits. This remote monitoring and intervention approach help minimize disruptions to the day-to-day lives of patients, who may not have the ability to visit care providers on a frequent basis.

Eliminate the burden of technology to enable RPM

The IoMT devices utilized by RPM programs can transmit data to a data repository maintained by providers. Usually, these devices are connected to a patient’s home network, which enable them to stream data over the internet. However, this places the burden on patients to provide a network connection capable of transmitting data to the data repository. This factor could negatively impact participation in RPM programs, thereby putting the entire Health Equity solution at risk for low adoption rate and reduce its effectiveness.

By shifting this responsibility away from patients, it opens up possibilities to invest into standardized, reliable transmission, and reception devices/technologies that multiple patients can benefit from. This additional undertaking on the part of healthcare providers, medical device manufacturers and health insurance companies, will help improve adoption of health equity solutions. This in-turn has the potential for a huge pay-off in terms of improving patient satisfaction, quality of care, and reducing staff burn-out.

The article Top 4 reasons healthcare providers should invest in remote patient monitoring provides additional compelling evidence to support the value of this investment.

Healthcare payors have also realized the significance of investing in RPM technology. The article Why insurance companies are investing heavily in RPM for Telehealth Providers discusses some of the financial benefits of investment in RPM technology.

Continuity of Care

Continuity of Care is essential to improving health equity, enabling a patient’s personal health records to travel with them, regardless of the healthcare facility they visit. This is essential to ensure there is no disruption/duplication in care delivery. In our solution, during the telehealth visit, if the care provider recommends the patient to consult with a specialist, it would be greatly beneficial for the specialist to have access to all of the patient’s personal health records.

To achieve this, it will be beneficial to implement a data repository that collects and integrates data from multiple health information systems, with the personal health data, received from RPM monitors. It is important that the data repository also adhere to interoperability standards which will facilitate efficient exchange of information. The article Interoperability in Healthcare discusses some of the essential aspects of interoperability.

Most personal health data will eventually need to reside in Electronic Health Record (EHR) system(s). However, there are several advantages to routing personal health data to EHR systems from the data repository rather than the other way around. The following are some of the advantages that far exceed just the Continuity of Care aspect:

The data repository can be designed to store data in an easy to share/exchange format, that conforms to interoperability standards. This enables the repository to act as the central hub in a hub-spoke model to facilitate data exchange between multiple health information systems. This helps reduce complexity involved in establishing peer-to-peer communication between those systems.
Data from multiple health information systems can be integrated to provide a 360° view. For example, EHR, ERP, revenue-cycle, and inventory management systems can feed data into the data repository. Maintaining all this data in any one of those systems would not be practical or relevant.
3The repository can serve a wide variety of use cases, including direct integration with analytics and machine learning solutions.
The repository can greatly minimize the burden on EHR systems, allowing them to focus on their primary functions and reduce complexity. This helps reduce the administrative overhead involved with maintaining and operating EHR systems.

RPM at Scale

We discussed the use of RPM programs and Continuity of Care to implement Health Equity solutions. However, as noted initially, implementing such solutions on a per-person basis presents economic, scalability and sustainability challenges. These challenges could be minimized by implementing the solution for a group of patients. Identifying a group of patients with similar health complications, who require similar levels of monitoring and care can help spread the effort and cost amongst members of the group. Implementing the health equity solution at scale provides benefits such as:

Reducing effort on the part of care providers – collectively monitoring patients with a unified set of tools, while enabling care providers to patients individually
Spreading the cost of care amongst a group of patients―enabling investment in development of new care models to improve health outcomes
Opening up possibilities to organize educational programs and support groups to foster healthy lifestyle choices

Our solution achieves these benefits by distributing identical IoMT device/gateway packages to the patient cohort, as well as monitoring the patient cohort collectively using a unified dashboard.

Business Process Flow

For a top-level understanding of how such a health equity solution could be implemented, let us consider the following use case: A scenario of providing care for a cohort of low-income female patients, over the age of 50, with a history of cardiac arrests, verified for insurance eligibility to be part of the program. This section walks through the process flow.

Health Equity Use Case Process Flow

As part of the RPM program, the patients in the cohort will be supplied with the following IoMT devices: a blood pressure monitor, a pulse oximeter and a body weight monitor. These devices are registered to each patient, so the readings that will be sent from the devices can be associated with the patient.

The patients are requested to record readings using the blood pressure monitor and pulse oximeter twice a day—one in the morning and another before bed-time. Patients are also requested to record readings using the body weight monitor once in the morning, before meal.

Next, we would need to resolve the burden of technology. This can be addressed by providing patients with a gateway device. The gateway device must also be registered to a patient’s medical record. The gateway device should be configured to collect patient vitals data from the supplied IoMT devices. It should also be equipped with a Subscriber Identity Module (SIM) card that can connect to a cellular network provider to securely transmit this data over the internet. Time to add cellular data connectivity to your medical devices? discusses options to implement such gateway devices.

The next aspect that needs to be addressed is Continuity of Care. We described how a data repository that conforms to interoperability standards can help solve this concern. For this use case, readings from the IoMT devices can be transmitted to the data repository by the gateway device. The data repository enables integration of patient vitals data received from IoMT devices, with the patient’s medical record from EHR systems, and data from other health information systems.

In order to track and monitor over-all health of the patient cohort, a unified dashboard can be created using data from the data repository. The dashboard can display the patient vitals data along with other personal health information such as demographics, diagnosis, care plans and health insurance plans. This dashboard can be integrated with EHR systems to enable care providers to have access to relevant information about the cohort, within the EHR system.

The unified dashboard provides care providers the ability to view all patient data in a consistent manner. If they notice abnormalities in a patient’s vitals data received from IoMT devices, say with blood pressure readings or body weight trending in an undesired direction, the care provider can initiate a telehealth appointment request with the patient. To minimize burden on healthcare providers, IoMT devices such as Medtronic’s MyCareLink monitors generate alerts when abnormal readings are detected. By highlighting these readings in the dashboard, it enables healthcare providers to efficiently address such abnormalities. To ensure the dashboard is secure, row and column level security can be defined to ensure care providers have access to a specific subset of patients and specific data needed to provide care.

During the telehealth appointment, care providers can request that the patient record and send current vitals data using the IoMT devices. This data can then be streamed to the data repository, by the gateway device, and integrated with the patient’s personal health data. A near real-time web portal, integrated with the population health dashboard, can display this data to a care provider. This helps create an experience similar to an in-person visit for both the patient and the provider.

If the care provider decides to refer the patient to a specialist, they can request the transfer of relevant information from the data repository to the specialist’s health information system. Ideally, this interface would be pre-configured to allow seamless data exchange. Implementation of a multisite, interdisciplinary remote patient monitoring program for ambulatory management of patients with COVID-19 provides a comprehensive overview of setting up clinical processes around such use cases.

Reference Implementation Architecture on AWS

A high-level AWS Health Equity Reference Architecture

Amazon Web Services (AWS) offers a range of HIPAA eligible services that can be leveraged to create a secure, seamless and cost-effective solution for the use case described above. The reference architecture provided here only focuses on the use case delivery. Please refer to Architecting for HIPAA Security and Compliance on AWS for detailed information on how to architect for a HIPAA compliant solution. The AWS services proposed in this architecture are HIPAA eligible and help minimize administrative overhead while being flexible and scalable.

In this HIPAA eligible architecture, messages streaming from gateway (remote) devices, through a cellular network, are received by AWS IoT Core and stored in Amazon SQS. AWS Lambda process messages in an Amazon SQS queue and inserts patient vitals data into Amazon HealthLake. The patient vitals data is integrated with data from mainstream health information systems, such as EHR systems in Amazon HealthLake. This architecture is focused on low transmission rate devices. In a separate post for RPM, we will cover the architecture for high transmission rate devices, using streaming pipelines.

The merged data can be exported to Amazon S3 for further consumption through AWS Glue and Amazon Athena. Amazon QuickSight interfaces with Athena to enable building population health dashboards. For on-demand visualization of near real-time data, during tele-health appointments, a light weight web portal hosted on AWS App Runner can be used. This web portal extracts data from Amazon HealthLake using FHIR APIs. HealthLake’s FHIR APIs also enable data exchange with specialists or other entities for follow-ups.

The following section discusses the services associated with process flow, in detail:

1. Ingestion of EHR data

This can be accomplished in many different ways. If the EHR supports data export in FHIR format, that would be the preferred approach. Since FHIR is gaining recognition as an industry standard for data exchange, this promotes compatibility with many health information systems. If the EHR system currently does not support data export in FHIR format, data can be exported in HL7 format and converted to FHIR using one of our partner solutions. Data in a FHIR format can be securely landed in Amazon Simple Storage Service (Amazon S3).

2. Ingestion of data from monitoring devices (IoMT devices)

Patient monitoring devices, such as the blood glucose/pressure monitors and pulse oximeters, need to be pre-configured with a secure communication channel to a specific gateway device. The mode of communication between the monitors and the supplied gateway device should be determined by the device manufacturer. Primary considerations for the communication mode are security, fault-tolerance and performance.

We recommend transmitting FHIR encoded messages from the gateway devices. Transmitting messages in FHIR format enables efficient integration with many health information systems. These messages must be transmitted and received using a secure, reliable, performant solution. We recommend using a combination of AWS IoT Core, Amazon Simple Queue Service (Amazon SQS) and AWS Lambda for this purpose.

AWS IoT Core is a managed service that enables secure communication using MQTT protocol. The service receives incoming messages, from the gateway devices, to be distributed to downstream services. AWS IoT Core can automatically scale up or down to ensure that it can reliably receive messages. This allows gateway devices to conveniently stream messages according to a patient’s schedule(s), with minimal disruption to their daily lives.
Amazon SQS, a queuing service, can be used to reliably store messages received by AWS IoT Core and hold them until the messages are processed.
AWS Lambda, a serverless, event driven compute service can be used to process the messages and load them into the data repository.

3. Data Repository

This is a key component of the architecture that integrates data from disparate systems like the EHR, IoMT devices and other health information systems. For this purpose, we recommend leveraging a combination of Amazon HealthLake (HealthLake) and Amazon S3. The following are some of the key benefits of using HealthLake:

HealthLake stores data in FHIR format which promotes interoperability and efficient data exchange between health information systems. As discussed, efficient access to a patient’s medical record promotes Continuity of Care, and helps reduce duplication of diagnostic procedures, thus reducing waste.
HealthLake provides built-in version tracking and CREATE/READ/UPDATE/DELETE (CRUD) capabilities. This avoids the need for complex transformation and integration of solutions that would be otherwise needed if a custom data repository was used.
HealthLake provides built-in natural language processing. This feature helps extract information such as diagnosis, family history, procedures and more from unstructured clinical notes. This facilitates accurately identifying patients that may qualify to be part of the patient cohort.
HealthLake enables integration with analytics services through a normalized data model. Using tools such as Amazon SageMaker (which builds, trains, and deploys machine learning models for any use case), the data within HealthLake can be analyzed. This opens up possibilities to uncover insights and trends, that can only be gleaned by integrating and analyzing data from multiple systems. An example would be to use machine learning to perform early detection of health complications in the patient cohort.

Amazon S3 complements HealthLake by acting as a data lake, which can be used to store raw/detailed versions of data while processed/summarized information gets stored in HealthLake. This enables the repository to enable varied use cases that may require data at different levels of detail.

4. FHIR Data Conversion

Data stored in Amazon HealthLake needs to be made available to dashboarding tools, which will allow us to build the population health/patient monitoring dashboard. Currently, mainstream dashboarding tools do not support the FHIR data format. Therefore, we need to extract data from Amazon HealthLake. It currently supports two modes of data extraction. A full data export tool and standardized FHIR APIs to query data. Given the volume of data required to create a population health dashboard, it becomes necessary to perform daily exports of FHIR data to Amazon S3. Once data is in Amazon S3, a combination of AWS Glue and Amazon Athena (Athena) can be used to view data in a relational format, which dashboarding tools are compatible with. Athena enables conversion of FHIR format to a relational structure when serving a data request. This reduces proliferation of data, thereby minimizing security overhead and storage costs.

Given that the FHIR data format is gaining recognition as a standard data exchange format for healthcare data, there is a possibility that mainstream dashboarding tools will add support to natively query data from FHIR repositories like HealthLake. This should help remove this extra step and simplify the architecture. Here is one such example of a FHIR data visualization tool built by an AWS partner.

5. Unified Dashboard

The unified dashboard helps with remote monitoring of a group of patients. It helps track trends at the group level, drill-down to individual patient data and enable early detection of abnormalities in high-risk patients. For this use case, we recommend using Amazon QuickSight (QuickSight) for dashboarding since it has native integration with Athena. Dashboards built using QuickSight can be integrated with EHR systems to provide a single interface experience so the care providers don’t need to access multiple systems to deliver care.

6. Near real-time web portal
We need to present current vitals data streamed by the patient during a tele-health appointment to the care provider. Since the data is provided to the data repository, Amazon HealthLake, we recommend leveraging HealthLake’s FHIR APIs to extract the near real-time data. A light-weight web portal hosted on AWS App Runner can ingest data using the FHIR APIs and display data in near real-time. This web portal can be integrated with the population health dashboard to augment the single interface experience.

7. Data sharing with external providers
The data repository can be leveraged to share relevant portions of the patient’s medical record with specialists or other entities, if recommend during the tele-health appointment. In such cases, we recommend utilizing HealthLake’s FHIR APIs to transmit relevant data to those entities.

Conclusion

In this article, we presented some of the challenges that make health equity goals hard to achieve. We discussed factors that deter low-income patients from seeking a healthy lifestyle and their challenges with accessing healthcare. We identified Remote Patient Monitoring (RPM) programs and Continuity of Care as critical components for the successful implementation of health equity programs that focus on prevention.

We explored a sample use case that leverages IoMT devices for RPM, to minimize disruption to patient’s daily lives. We discussed the use of gateway devices, that directly transmit data over cellular networks, to eliminate the burden of technology from patients. We emphasized the criticality of instituting a data repository to realize Continuity of Care. We discussed how the data repository, conforming to interoperability standards, helps improve accessibility to a patient’s healthcare data as they visit multiple healthcare providers, who may or may not be part of the same organization or share the same health information systems. We also discussed RPM at scale that helps minimize cost through strength in numbers.

We explored reference architecture for the sample use case, using AWS services. We showed a reference architecture that leverages services like AWS IoT Core, Amazon HealthLake, Amazon S3, and Amazon QuickSight. We highlighted the value of using Amazon HealthLake and Amazon S3, that form the data repository for ingestion, integration and health information exchange. Here are some examples of how AWS customers have leveraged Amazon HealthLake.

While several third-party/partner solutions can be leveraged to implement the RPM program and cellular transmission of data, it is critical to ensure the data repository is implemented, along with these components, to realize the full value of the solution. The data repository enables data collection, retention, integration, analytics and interoperability. Thus, it forms the fundamental fabric around which the entire solution revolves. The benefits far exceed the current solution, since the data repository can be leveraged for many other use cases. Some of the benefits we have highlighted include:

Clinical use cases such as staffing optimization―reducing staff burn-out
Ease of access to data―promoting interoperability and data sharing across healthcare entities
Accelerating analytics and discoveries―integration of data from multiple systems of record

In summary, RPM programs and Continuity of Care are concepts that have been implemented by healthcare organizations, resulting in varying levels of adoption and success. The solution presented in this article provides a highly prescriptive approach and architecture to combining these concepts with a data repository to implement a Health Equity solution. This solution will help create a better future for all parties involved―patients, providers and payors.

AWS helps customers operationalize such health equity initiatives through several incentive programs. You can read more about the programs here: New global program to help customers develop solutions to improve health outcomes and health equity. It is also possible to integrate pre-built solutions from AWS partners such as Philips’ HealthSuite to power such initiatives. If you are interested to learn how AWS and our partners can help, please contact your AWS Representative.

AWS for Industries