If you are building an app that promises patients all their health records in one place, Individual Access Services (IAS) under TEFCA probably sounds like a dream. One connection to a nationwide network, with patients directing their information into your application. Far less chasing records from one provider at a time.
There is considerable opportunity here. But before putting “nationwide patient record aggregation” into the next pitch deck, its important take a close look at what comes with it.
TEFCA’s updated IAS Implementation SOP, version 3.0, takes effect August 3, 2026. Its requirements reach well beyond getting a patient to click “I agree.” Identity verification, secure authentication, patient matching, consent, and responsibility for mistakes all come into play.
For any app collecting records, those requirements mean development work, expense, and some friction during enrollment. For the hospital, physician practice, or health plan releasing records, that meticulousness serves an obvious purpose: making sure the person requesting the information is actually entitled to receive it.
Both perspectives deserve attention.
First, What Acctually Changes on August 3rd?
IAS allows an individual to use a TEFCA-connected service to access, obtain, or transmit their health information. The IAS Provider has a direct contractual relationship with that individual.
The updated SOP establishes how IAS requests must be supported and answered. It does not require every provider to join TEFCA, and it does not turn every app that collects health information into an IAS Provider. But organizations using this TEFCA pathway must meet the applicable requirements.
Importantly, the final version gives responding organizations two ways to support IAS access:
- Mode 1 – the patient signs in. The responding organization returns a connection to its patient-access interface, where the individual authenticates through the organization’s supported process.
- Mode 2 – vrified identity and patient matching. The responding organization finds an acceptable match uniquely attributable to the individual under its matching policy and provides a path to the required information without a separate portal login.
The final SOP allows either option. Although it identifies a future goal of requiring Mode 2, it does not impose that requirement on everyone today.
That distinction matters. An app hoping to collect records seamlessly across multiple sources may still encounter sources that require the patient to authenticate separately. The recommendation is to vendors is to build that possibility into the product before promising otherwise.
The hard part starts before the first record arrives
An IAS Provider must contract with an approved Credential Service Provider (CSP) to verify individuals’ identities to at least NIST Identity Assurance Level 2, or IAL2. It must also authenticate users at Authenticator Assurance Level 2, or AAL2.
Those are different things. Identity proofing establishes who the person is. Authentication helps establish that the person accessing the account is its legitimate user.
The SOP also requires verified demographic information, including name, birth date, address, and either email or mobile phone, along with signed digital evidence of verification in the required transactions. Verification must be repeated when verified demographics change, expire, or are invalidated.
In other words, collecting a name, date of birth, and a checked consent box will not get an IAS Provider across the finish line.
And yes, the Trojan Horse concern is still here
In my earlier post, “Preventing IAS from Becoming a Trojan Horse,” I discussed the risk of third parties using a patient’s identity, or claiming to “stand in the patient’s shoes,” to obtain records through an access pathway intended to serve that patient.
The updated requirements make that discussion even more relevant. There are three separate questions: Who is this person? Which records belong to this person? And, if someone else is acting for the patient, what authority do they have?
An identity check does not answer all three.
For example, verifying a third party’s identity does not establish that the third party is the patient’s HIPAA personal representative. That status depends on authority under applicable law; a signed HIPAA authorization does not, by itself, establish it. HHS expressly requires verification of a personal representative’s authority.
An app can legitimately help patients obtain their records. But its workflow should make the patient’s involvement and the app’s authority clear. A third party quietly operating under the patient’s identity presents a very different situation.
Dates to Watch
August 3 is the effective date, but several requirements phase in later:
- October 1, 2026: Updated identity token and related messaging requirements, plus separate issuer addresses for production and testing.
- January 1, 2027: The demographics double-check for Mode 2.
- July 1, 2027: Additional technical standards for the patient-access interfaces used in both modes.
- Directory reporting: Supported response modes must be identified within 60 days after the necessary directory fields become available.
The double-check requires the IAS Provider to compare returned patient demographics against its own information before proceeding. A failed match requires stopping that Mode 2 request, discarding the patient identifier, and notifying the responding organization.
Also, the March proposal is not the final rule. Its proposed “TEFCA IAS Consent” transaction workflow and blanket August 2027 requirement for the identity-based approach were not carried into the final SOP.
My recommendations for vendors and apps considering IAS
Before committing to IAS as your record aggregation strategy, I would focus on four issues:
- Budget for identity verification as an ongoing function. Approved CSP services, secure authentication, reverification, and valid identity tokens require continuing support.
- Design for both response modes. Separate patient logins may affect enrollment, completion rates, and how much information your app can collect.
- Build a process for wrong-patient information. Matching errors require a way to stop retrieval, notify the source, and remove erroneous information. Plan for the January 2027 double-check now.
- Review the business model alongside the technology. IAS Providers have separate privacy, consent, security, export, and deletion obligations. Selling identifiable information, receiving payment for it, or using it for targeted advertising or other marketing requires separate, clearly labeled consent under the IAS Provider requirements.
For data sources, I would focus on a documented matching policy, a supported response method, and a clear process for evaluating identity and authority concerns without unnecessarily delaying legitimate access.
IAS offers a valuable pathway for patient record aggregation. But an app considering it needs to be prepared for the responsibilities that come with requesting information in the patient’s name. And the organization releasing it needs a sound basis for trusting that request. That is precisely where the Trojan Horse either gets stopped, or gets invited inside.