Presenters at the May 27 HL7 Da Vinci Project community roundtable provided concrete evidence demonstrating how the use cases represent specific ways to use HL7’s Fast Healthcare Interoperability Resources (FHIR®) standard for specific purposes in value-based care data exchange interactions between providers and payers.
FHIR for Data Exchange for Quality Measurement (DEQM) Use Case
A clear indication of the value of the medication reconciliation process use case was provided by Kirk Anderson, chief technology officer for Cambia Health Solutions, a nonprofit healthcare organization that’s the parent company of Regence, a member of the Blue Cross Blue Shield Association. Initial efforts to use the FHIR use case with MultiCare, a Tacoma, Washington-based healthcare system, resulted in a dramatic boost in the insurer’s ability to get information on members’ prescribed medications from the provider.
“One of the key metrics we’re excited about was the significant increase in Regence’s ability to receive (MRP) data from about 5% to 100% by removing manual processes from the effort,” Anderson said. “It was a huge value for us, and the improved user experience between provider and payer was definitely a value-add.”
Payers check on members’ medications after discharge to find out what prescriptions have been added, comparing what’s on the list after discharge to what the patient was taking before hospitalization. This can help avoid different types of medication errors, and proof that a payer has done this reconciliation is increasingly required to achieve value-based care incentives. But this process is difficult across multiple care settings, and typically tedious and labor-intensive.
Before implementing the use case with MultiCare, Regence employees had “to search for data within provider systems’ electronic medical records systems, and that’s not a great security solution,” Anderson said.
Regence is working with other provider organizations on implementing other Da Vinci Project use cases. Besides MultiCare, Regence is working with OHSU in Portland, Oregon, Providence Health & Services, and OCHIN, a Portland-based health IT services provider. In 2019, Regence worked closely with these partners through a process of ideation, development and testing before beginning the process of going live this year.
“Payer and provider technology collaboration is a new animal,” Anderson said. “We have not done a lot together; we have to establish new relationships, and we had to understand that the terminology on the payer side means something different on the provider side. And you need priority alignment on all sides – the nature of the work we’re doing is such that you have to do it not only in collaboration but in lockstep with the party on the other end of your interoperable exchange.” Although, in the case of MultiCare, it was essential to gain cooperation with its EHR vendor, Epic, to enable integration between the records system and the FHIR-based use case.
“Da Vinci implementation guides are critically important – having them as open-source, community-driven efforts vetted by experts are invaluable,” he added. “And because we’ve done this once with MultiCare, it is trivial for us to extend this and allow another provider to execute the same process with us. That’s really the magic of the use of standards. We will see more technology providers … building in support for standards. That’s where we get the benefit of ‘build once and reuse.’ ”
FHIR for Payer Data Exchange (PDex) (Provider Directory) Use Case
In another real-world implementation of a Da Vinci Project use case, HealthSparq is continuing work on how to enable consumers to use FHIR-based APIs to access accurate, up-to-date provider directories, said Keith LoMurray, director of analytics and data products at HealthSparq. This is one of two requirements put in new final regulations recently released by the Centers for Medicare & Medicaid Services; it will go into effect January 1, but enforcement won’t begin until six months later.
Initial federal requirements for information available in provider directories will be minimal, affecting providers’ names, address, phone numbers, specialties and other demographic information; however, more information likely will be required in the future, LoMurray said. HealthSparq is developing an approach that can scale over time.
The company is developing an interoperable solution that supports authentication and access management requirements, then maps into hosted FHIR servers.
The eventual solution will need to scale because federal rules require the public to be able to access payers’ provider directories through an application programming interface (API). A public-facing API “is not a common pattern in healthcare,” LoMurray said. “In securing those APIs, you have to know how you are going to do that.” For many organizations, “jumping into a public API will be difficult. For a truly public API, how do you do registration, how do you make sure this is secure, how do you make sure you’re not crashed with a malicious attack?”
The quality of payers’ provider data – including how to update it to keep it current – will be an operational challenge in meeting the requirements of the new final regulation, he added. “People get very frustrated when your directory says a provider is accepting new patients, and then it turns out they’re not, or you list the wrong location for them. Interoperability doesn’t do anything around your provider data quality problem.”
FHIR for Clinical Data Exchange (CDex) Use Case
Finally, the third presentation involved UnitedHealthcare’s UnitedHealth Group’s implementation of a FHIR use case to facilitate the payer’s ability to gather lab results for members to close gaps in clinical quality measures.
The effort uses a “Lab Chase Service” to query to see if members have been given specific types of tests. That’s because if payers achieve certain quality measures, they can qualify for incentive payments under some reimbursement arrangements, said Nick Radov from UnitedHealthcare. “But we have to have hard data to support that; we have to show that procedures were actually performed.”
The company initially set its sights on diabetes, particularly HbA1c, a hemoglobin test that monitors a patient’s average level of blood sugar for the past two to three months. In this effort, UnitedHealth partnered with reference lab companies it works with – Quest Diagnostics, LabCorp and BioReference. “In some cases, they are pushing some data to us through HL7 Version 2 (V2), but there’s always some percentage of missing data that does not automatically come through or gets matched up to the patient.”
To improve the gathering of results, UnitedHealth implemented the Clinical Data Exchange (CDex) use case. When the payer gets a claim, it triggers a “lab chase” that sends a query to a lab vendor’s FHIR server to inquire about whether a lab result is available, thus ensuring that a test has been done.
Queries can be issued in near real-time, Radov said. “Overall, this has been successful for us in leveraging a Da Vinci use case to facilitate interoperability and acquire more clinical data at relatively low cost.”
In addition to improving its tracking of HbA1c tests, UnitedHealth is using the FHIR-based process to query reference labs on other tests. “The priority now is COVID-19 testing,” Radov said. “We will expand rapidly to add on more codes for different quality measures.”
Presenters in the roundtable highlighted the importance of adopting the use cases to improve performance under value-based care approaches that will require more data sharing between providers, payers and patients. Most importantly, FHIR will increasingly enable data sharing to be automated, obviating the need for slow, manual processes that healthcare organizations now use.
Recording Now Available
Want more information? Access the live recording and slides here.
To learn more about the HL7 Da Vinci Project and to join the community, visit hl7.me/davincinews.
