On Dec. 11, the ONC TEFCA Recognized Coordinating Entity (RCE) held an online public stakeholder feedback meeting on the development of the Qualified Health Information Network Technical Framework (QTF). Although it is perhaps not clear how much consensus developed during the first meeting, the questions the RCE sought comment on made it obvious that the organization has to weigh a handful of standards issues, including the role of FHIR.
The QTF outlines the specifications and other technical requirements necessary for QHINs to exchange data. In April 2019, the initial QTF was seen as a rough draft that would be fleshed out over time. The RCE is seeking input on what will become Draft 2.
The RCE noted that the QTF will primarily address QHIN-to-QHIN transactions, and where possible it seeks to be silent on how the necessary functional outcomes are achieved within a QHIN. But it noted that there are likely to be some requirements that must be enforced at the participant and participant member level.
TEFCA’s Minimum Required Terms and Conditions (MRTCs) require QHINs to support an exchange paradigm called “QHIN Query,” in which information is requested from other QHINs in either a targeted or broadcast fashion. The MRTCs do not specify any particular standard or technical approach. QTF Draft 1 envisioned QHIN Query being accomplished by SOAP-based IHE profiles, as a straw proposal. The RCE proposes to build further on this straw proposal for QTF Draft 2, fleshing out the Draft 1 requirements with heavy reliance on existing Carequality specifications. But the webinar leaders, including Mariann Yeager, CEO of the Sequoia Project, and David Pyke, a senior consultant at Ready Computing, sought opinions about whether and how FHIR should be considered.
“We would like to understand how FHIR-based query should be deployed,” Pyke said. He asked whether they should be looking at FHIR-based query in a second version with release 4 or even release 5, which will make 25 or more resources normative. “That would mean less retooling that needs to be done over time,” he said.
The MRTCs also require QHINs to support an exchange paradigm called “QHIN Message Delivery,” in which information is pushed by one QHIN to another, either for the receiving QHIN’s own use or for it to forward on to a designated recipient system among its participants. As with QHIN Query, the MRTCs do not specify any particular standard or technical approach, and instead leave this to the QTF. Potential use cases include messaging between provider organizations when Direct addresses aren’t known and submission of public health reporting data.
Another issue that will have to be decided is whether the QTF requires that QHINs have enterprise master patient indexes or record locators. (An EMPI would be a single central index. A record locator system would be a list of where that information could be found but with no centralized patient index. Both would require patient matching.) Or should the RCE make that optional? Pyke noted that when the record retrieval is done at the QHIN level, the speed goes up exponentially.
When it comes to patient matching and ID caching, one big question is: Should the RCE set minimum match rates and how could it measure them?
Another use case is allowing providers to “subscribe” to a patient in a remote community. For instance, as health data is created about a patient, their primary care doctor could subscribe to have data about that patient automatically sent to them. The RCE is asking whether that capability should be a part of QHIN requirements in the QTF.
Another is whether patient matching should require address format consistency using the U.S. Postal Service standard. And if so, should that be a QHIN responsibility or member responsibility?
Yet another issue is whether the QTF should have requirements about the provenance metadata — the historical record of where the document originated and what changes have been made en route. Some respondents said this will become more important in the future. Others said their health systems don’t allow data to be stored if they can’t associate provenance to the data.
TEFCA is a voluntary process at this point, so the RCE is keen to get as much stakeholder feedback as possible in its development process to encourage participation. Stay tuned for more opportunities to participate.
