Hospital Association Seeks Delay in TEFCA Individual Access Service Roll-Out

In a letter to the Sequoia Project, the American Hospital Association (AHA) recommended that the proposed procedure for individual access services (IAS) under TEFCA be delayed until liability and compliance concerns are addressed.

As a TEFCA proposed use case, IAS supports patients in accessing their own medical records by creating workflows to direct the data to third-party apps. IAS workflows entail identity verification (checking that the patient is who they claim to be), patient matching (linking patient records across different systems using demographic data) and patient consent (patient directs the disclosure of their own health data to parties of their determination).

AHA describes the proposed Individual Access Services (IAS) Exchange Purpose (XP) Standard Operating Procedures (SOP) version 3.0. outline of three proposed approaches for responding nodes to respond to IAS requests.

The proposals touch on all three aspects of the IAS workflow:
• Response Approach 1: Would require responding nodes to respond to IAS requests using a FHIR credential-based log-in flow using certain demographic fields for patient matching.
• Response Approach 2a: Would require responding nodes to respond to IAS requests using a new “TEFCA IAS Consent” (TIC) flow, which would prevent responding node verification, and a revised proposed patient matching process that has not been validated. The TEFCA RCE would require responding nodes to implement this by Aug.1, 2027.
• Response Approach 2b: Would require responding nodes to respond to IAS requests using the same approach as approach 2a, but with fewer patient matching data fields or without the TIC. The TEFCA RCE would require responding nodes to implement this by Aug. 1, 2027.

AHA said it is concerned that the proposed SOPs rely on untested consent and patient matching components, presenting significant compliance risks for responding nodes that are covered entities. The proposed implementation date also does not provide adequate time to build functionality, test reliability and integrate workflows, much less address some of the legal and regulatory compliance risks.

AHA urged the Sequoia Project to delay implementation of these proposals and encourages it to coordinate with ONC and OCR to pursue statutory and regulatory relief for providers because many of these questions exceed the capacity for sub-regulatory guidance, such as the SOPs, to address.

For example, the creation of a statutory safe harbor protecting providers from liability for disclosures fulfilled via these IAS processes could mitigate risks for providers in the event of a breach, according to AHA. 

When a third party misrepresents consent for disclosure, providers should not be held liable or obligated to undertake breach notification steps if they were complying with the IAS process, the letter said. Alternatively, OCR could issue regulations clarifying that providers who comply with this IAS process have fulfilled their legal obligations to verify patient consent, as well as the identity and authority of the entity requesting health information, prior to disclosing records.

AHA described it as an asymmetry in privacy and security requirements that third parties requesting data are not covered entities or business associates. It “forces providers and covered entities to bear the full risk for activities outside their control. Entities without the same level of downside risk — such as the third parties making or facilitating these data requests — are not similarly incentivized to undertake the same levels of data protection and verification,” the letter states. “We have consistently urged that third parties be held to the same privacy and security requirements as covered entities and business associates. We would encourage the Sequoia Project to work with ONC and OCR to issue agency-level requests for information, proposed rules and clarifying guidance. Such regulations should address topics such as providers’ duty to verify third parties, responsibilities for breach notification and liability in the event of third-party breaches resulting from IAS workflows.”