Yale Pilots Patient-Centered Clinical Decision Support Apps

Yale New Haven Health recently conducted two pilot projects to deploy patient-centered clinical decision support apps that combined patient-generated health data with clinical data from the EHR to support remote patient monitoring.

During a recent webinar sponsored by the Agency for Healthcare Research and Quality, informatics executives discussed the challenges involved in a pilot project monitoring COVID-19 patients using a Bluetooth-enabled blood pressure monitor, and how the lessons learned from the COVID-19 pilot were applied to the following pilot that monitored patients with postpartum hypertension.

Nitu Kashyap, M.D., associate chief medical information officer at Yale New Haven Health, said the goals for both of these pilot projects was to enhance an existing workflow. They were trying to test the ability of a patient-centered decision support application to enhance the value of ongoing clinical efforts.

The first project was launched in May 2021, and the second in February 2022. The clinical rationale for the COVID-19 tracker started in the spring of 2020. “When we were in the early stages of COVID, we had to develop a mechanism for testing COVID, and we had no outpatient treatment; there was no vaccine,” Kashyap said. Dropping pulse oximeter was a sign of early deterioration, so a program was developed where a group of care coordinators was assigned to manage patients who tested positive and were prescribed a pulse oximeter. The goal was to manage these patients in the outpatient setting safely and escalate care where needed, she added.

At one point, the care coordinators were managing about 200 to 300 patients at a time. Once enrolled, the patients would then answer responses on heart rate, respiratory rate, pulse ox, and any additional symptoms. The care coordinators would then reach out to them based on symptoms or a predetermined frequency at five to seven days and at the end of the program, around 10 days, as they were released from isolation.

As AHRQ notes, often patient-generated health data from remote monitoring tools are not integrated into the electronic health record, which hampers clinician workflows, hinders patient-clinician engagement, and impacts clinical decision-making. The goal with this project was to integrate the patient-generated data into the EHR.

Healthcare systems also have staffing limitations, so anything that can automated is helpful for the clinicians, Kashyap said. “Also, it is important to see trends, not just individual values. And, of course, patients need some feedback in real time based on anything that they entered, as well as a way to escalate symptoms if something is noticed.”

David Lobach, M.D., Ph.D., is vice president of Elimu Informatics, which partnered with Yale on the pilots. He said they looked to use FHIR resources wherever possible, but as they found out, a lot of this depends on what the EHR vendor (in this case, Epic) has implemented. Lobach outlined seven issues the project team came across.

One of the first issues was to identify patients for enrollment, Lobach said. The standards for this use would have been a FHIR subscription resource or HL7 version 2 messaging. But unfortunately, subscription was not implemented in the EHR, and HL7 version 2 was not implemented in the app, “so we ended up using an EHR rules engine in order to identify the patients for the enrollment.”

The next issue was having a way to request to enroll a patient. “There are really no standards available right now around this issue,” Lobach said, “so we ended up using CDS Hooks in what was considered an ‘off label’ use by Epic in order to get a trigger to do the enrollment action.”

The third issue was informing the patients that they've been enrolled. “The communication request resource would have been used here, but that wasn't implemented by the HER,” he said, “so we had to using text messages, which actually worked quite well and engaging the patients.”

The fourth issue was authenticating the patient. “This could be done by Smart on FHIR, but if we did that, it would require the patients to have a portal account and login credentials,” Lobach said. “That can get cumbersome and become a barrier to use, so what we chose to do was to send short-lived links to a Web-based intake form as a way to get the patients engaged in providing their data.”

The fifth issue was getting the patient data from the EHR to the app. They encountered a blockage that took them a while to figure out why the FHIR resources weren't working. It was because a firewall was blocking the connection between the cloud-hosted app and the internal client system. They had to add an exception to the firewall to get around this issue.

The next issue was getting the patient data from the app to the EHR. The available FHIR resource would have been the questionnaire response, but it was not implemented, and the observation resource was only partially implemented. “We ended up just using up the observation resource, Lobach explained, “but we had to use proprietary codes because there wasn't a standardized vocabulary hooked up to the observation resource.

The final issue was the concept of alerting the clinician. “The communication request resource could have been used here but wasn't implemented by the EHR, so we ended up using a rule-driven system that we created within the EHR,” he said.

In summary, he said that they learned that FHIR is evolving. “There was a lack of a FHIR standard resources to request the ability to enroll in an existing service. We had other places where the implementation of the FHIR standard was lagging. We also ran into some issues with the current cybersecurity environment that would obstruct third-party apps from doing this type of integration.”

Other key things that they took away is that having local champions is really critical for success. “We have a team that kept working with us through all these challenges, and persevered.” Also, you need the skill set for doing the FHIR integration in order to make this type of process work, Lobach said. “We demonstrated we could build a patient engagement app that integrates into the EHR. It would have been a lot harder if we hadn't had the FHIR standards, but they were limited. We needed a lot of collaboration with the EHR vendor. It's not plug and play. That said, we were able to have a successful implementation and deployment of a patient engagement app, actually two apps, that integrated with existing workflows and relied on these new emerging interoperability standards such as FHIR.”