On August 3, TEFCA’s revised Individual Access Services procedure took effect. It addresses a problem that can survive a successful identity check: the person requesting medical records is who they claim to be, but the records returned belong to someone else.
No impersonator is necessary. The patient can be genuine. The credentials can be valid. The mistake can occur when a system connects that person to a medical record.
That possibility puts two obligations in the same transaction: give people access to their own health information, and protect other people’s information from unauthorized disclosure. Verifying identity answers only part of the question.
A Verified Person Still Needs the Right Record
Consider a hypothetical patient using an application to gather records from several healthcare organizations. The patient proves their identity and signs in successfully. The application searches for records across the network.
One organization has the patient’s current address. Another has an address from several years ago. A third has a record for someone with the same name and date of birth.
An exact comparison could miss a genuine record because the address changed. A more permissive comparison could return the other person’s record. Repeating the identity check would not necessarily resolve either problem. The uncertainty concerns the connection between a known person and information held elsewhere.
This is what makes matching across a federated exchange difficult. The application and the organizations holding the records do not share one registration desk or one consistently maintained patient file.
Access and Privacy Have to Work Together
HIPAA generally gives individuals a right to access their protected health information in designated record sets, subject to specified exceptions. Covered entities must also verify the requester’s identity. HHS explains that verification cannot impose unreasonable measures that obstruct or delay access.
The right concerns information about that individual. It does not authorize releasing another person’s records because a search returned them.
A matching process therefore has to account for errors in both directions. An incorrect match risks disclosure. A missed match leaves the patient without information that belongs to them. Simply making the comparison stricter does not establish that the overall access process works better.
TEFCA Checks the Proposed Connection
The revised IAS procedure provides two response approaches: authentication through the responding organization, or verified-identity matching without a separate portal login. The latter adds a demographics double-check after successful patient discovery and before further retrieval. Its compliance date is January 1, 2027.
The sequence matters. Finding a possible record and retrieving its contents are separate decisions. An additional comparison creates an opportunity to stop before the initial association leads to further disclosure.
In the hypothetical, the important question is no longer just whether the application knows who its customer is. It is whether the information returned by the other organization supports connecting that customer to this particular record.
A Failed Check Has Consequences
Under section 4.7, a failed double-check requires rejecting the response, not retaining the patient identifier, stopping that verified-identity route, and notifying the responding organization or its associated network entity. The responder-authentication route remains available if supported. This is not a requirement to report every unsuccessful search.
Stopping a questionable match protects privacy. Preserving another route matters for access: an unresolved comparison does not prove that the patient has no records there.
Notification also turns a local failure into information another organization can act on. Without that step, one application could reject a proposed match while the organization that supplied it remained unaware of the problem.
The Process Continues After Records Arrive
If a patient reports receiving another person’s data, section 4.7 requires timely notification to the responding organization’s associated entity and timely purging of erroneous data from the IAS provider’s system. Applicable breach-notification law still governs. These are TEFCA participation requirements, not universal HIPAA portal specifications.
A patient’s report is evidence that the earlier checks need attention. Removing the wrong data addresses what the application holds. Alerting the source allows the problem to be examined where the association arose. Neither action makes the original disclosure disappear.
