Cedars-Sinai, Anthem Make Progress on FHIR-Based Data Exchange
Through the HL7 Da Vinci Project, payers and providers are working to shift legacy document-focused data-sharing efforts to FHIR implementations. During HL7 FHIR DevDays virtual meeting in June, Cedars-Sinai Medical Center’s Ray Duncan, M.D., described the use cases his Los Angeles-based organization has chosen to prioritize with Anthem as part of the Vivity HMO and the heavy lift the transition involves.
The Da Vinci Project is a collaborative effort based at HL7 to standardize FHIR-based interfaces between payers and healthcare organizations, replacing legacy interfaces for sharing documents. The work product is being balloted by HL7 and becomes part of the HL7 FHIR standard.
Duncan, director of technology research and development at Cedars-Sinai, is a member of Da Vinci as part of Vivity, a virtual integrated health system that includes Anthem as the payer and seven large Southern California provider organizations — among them UCLA, Huntington Memorial, Cedars-Sinai, and Dignity Health. The Vivity clinical data repository is managed by a company called CareEvolution.
“Some use cases are very complex,” Duncan said. “We picked a couple to work on that required minimal build by the Epic application teams. We were able to work on integration issues in the background without changes to provider work flow.”
Nevertheless, he said, the validation of use cases implemented with FHIR against the legacy solution is pretty labor-intensive and complex. An implementation team requires a lot of skill sets. “You need database people, systems integration people, FHIR programmers, and clinical analysts,” Duncan said. “Our existing operational teams and governance processes really weren’t nimble enough for this. It would have taken a lot longer to go through the normal project channels, so this was primarily implemented by our technology R&D team.”
The first two use cases they tackled were event notifications for primary care physicians (PCPs) and Anthem quality measures. Duncan noted that Epic does has some provisions for doing event notifications between Epic customers, “but if one of our patients was seen at another organization that wasn’t using Epic, we would not hear about that,” he said.
He described the data flow: the encounter events from the CareEvolution repository are posted to a Cedars endpoint using FHIR. Cedars then inserts it into tables in its enterprise data warehouse, and does filtering on the events to make sure it doesn’t send things to PCP in-baskets that they don’t want to see. Then it delivers the notification to the PCP in-basket via a proprietary Epic service. “We do quite a lot of filtering to make sure in-basket noise is not overwhelming for PCPs,” Duncan said. “We validate patient identity and check the member number, and make sure the encounter types we are notifying about are clinical encounters. We don’t notify for encounters such as preregistration or outpatient labs or patient imaging. We only send the notification to the PCP if they have seen the patient in the last three years. The filtering removes quite a few of the notifications.”
Quality measure use case
One way that Anthem uses quality measures is to identify gaps in care and notify the care team of gaps that need to be filled. The legacy solution for this involved a real-time HL7 ADT interface from Cedars-Sinai to Anthem, with a clinical summary and CCDA document sent to Anthem several days after discharge, Duncan explained. The delay was programmed in to make sure that the discharge note was included in the CCDA. Anthem then processed the CCDAs to extract, map and code CCDA structured data while the narrative reports had to be processed by employees.
“We picked out a subset of Anthem quality measures for California to work on,” he said. Using FHIR, they built a driver table of Cedars patients with effective Anthem coverage and run an automated query for each quality measure on a daily or weekly basis depending on the criteria and time window Anthem is interested in. “After we marshall any new observations, we format them in JSON and push them to the CareEvolution endpoint over the Internet. We have done 14 quality measures so far, and there are plenty more to do. We chose ones that were relatively straightforward to implement.”
The Da Vinci HL7 documentation is only a starting point, Duncan stressed. “Until recently, it has been kind of a moving target and still evolving. Some of the use cases have been validated, while others are still being validated or are about to be validated. You have to keep a close eye on what is happening with the standard.”
New York HIE Network Shifting to FHIR Framework
Several years ago, the New York eHealth Collaborative (NYeC) began to work on interoperability issues by enabling document sharing across the state’s regional health information organizations (RHIOs). Now NYeC is shifting to a FHIR foundation to enable participants to access discrete pieces of patients’ clinical information through open application programming interfaces (APIs).
NYeC is a nonprofit organization leading the Statewide Health Information Network of New York (SHIN-NY), a network connecting all of the RHIOs. They are interconnected through a SHIN-NY hub via a statewide patient record lookup.
Speaking June 15 at the HL7 FHIR DevDays virtual meeting, Luke Doles, NYeC’s senior director of services management, New York eHealth Collaborative, first described some of the limitations of the document-centric approach based on an IHE/XCA architecture. The initiative began in the second quarter of 2014, and was not live until end of the fourth quarter of 2015. It required nearly 18 months of design, testing and implementation. There were several issues that had to be worked through, including with the size of documents. “We do weekly production testing with all the RHIOs and it is rare that the document exchange is 100 percent successful,” he said.
“Even if a clinician wants only some discrete data from a document, the entire document has to be retrieved, then parsed to get specific data,” Doles explained. “This is done for patient cohorts and reported back to care management organizations for specific lab values and vital signs. This is a very cumbersome process.”
Last summer NYeC began building a FHIR framework across the RHIOs. “This involved each RHIO setting up a FHIR endpoint,” Doles said. “This would allow the same functionality as receiving a document and parsing for discrete data except with much lighter-weight transactions and hopefully greater reliability. We would still retrieve data centrally using the record locator service and then aggregate FHIR responses into a single bundle per patient.”
As they began the work several RHIOs leveraged their HIE vendor for FHIR, but some had to do development from scratch. The FHIR resources were created pulling specific data from the RHIO’s clinical data repository. A primary use case was to retrieve data for a patient cohort such as the last A1C lab result or vital sign such as blood pressure. For this use case, they limited the required FHIR resources to Patient, Condition, and Observation.
The initial FHIR framework was in production in about 8 months, compared to the 18 months required for the IHE/XCA implementation. “The limited implementation allowed us to get the FHIR endpoints in place and provide a mechanism for the initial use case,” Doles said.
“Unfortunately, we have not been able to fully execute the initial use case because of demands for data from the RHIOs to help with the COVID-19 research and reporting. The FHIR framework was not quite ready to provide that support. Now we are planning to build on the initial FHIR framework over the next year to support these public health use cases for things like COVID-19 reporting and flu surveillance. This will be a centralized pull of data that will be aggregated and delivered to the Department of Health.”
Eventually NYeC wants to enable RHIOs to be able to do specific patient queries from their HIE through the centralized services and receive responses via FHIR resources. “This will give the RHIOs the greatest flexibility to use the framework for their own initiatives,” he said. “Even though this was a limited implementation of FHIR, it was a proof of concept that can be incrementally expanded upon to provide more functionality across the SHIN-NY.”
