TEFCA Individual Access Services (IAS)

Overview

The Trusted Exchange Framework and Common Agreement (TEFCA) is a nationwide framework for secure health information sharing in the United States. Persona functions as a Kantara-certified Credential Service Provider (CSP) for TEFCA Individual Access Service (IAS) providers. As the CSP, Persona performs NIST IAL2 identity proofing for patients and issues an ID Token to the IAS provider containing verified demographics. IAS Providers use the Persona-issued ID Token in TEFCA exchange requests.

TEFCA is one application of IAL2 identity proofing. If you need IAL2 for another purpose, such as workforce, education or healthcare provider onboarding, see IAL2 identity proofing with Persona and the IAL2 framework templates solution.

This guide outlines Persona’s IAS Provider integration for TEFCA, including the transition to the TEFCA IAS SOP 3.0 claim format.

Migrating to TEFCA IAS SOP 3.0

The TEFCA IAS SOP 3.0 compliance date is October 1, 2026. Choose the path that matches how you receive Persona ID Tokens today. For new implementations, use an OIDC Authentication Template in Authentications rather than the legacy Workflow integration. The claim comparison below shows what changes when your tokens move to 3.0.

Already in effect for both SOP versions: On OIDC tokens, aud is your HCID URI as a single string and azp carries the client ID. The tefca_ial2claims_version claim already appears on issued tokens, with "2.1" until that template’s cutover. OIDC discovery advertises the union of 2.1 and 3.0 claim names; it does not identify your template’s version. Read the version from an issued token instead. These are not changes scheduled for October 1 or your SOP cutover.

If you use the legacy Workflow integration (solution 1.0) and are staying on it

Your Workflow-generated tokens will automatically conform to SOP 3.0 on October 1, 2026. You do not need to change your Persona configuration, create an OIDC test template, or schedule a template cutover for this to happen.

If you use the legacy Workflow integration (solution 1.0) and want to migrate to OIDC

Migrating to Authentications is recommended but optional; it is a separate integration change, not the automatic Workflow token update.

If you already use an OIDC Authentication Template (solution 2.0)

Existing OIDC templates do not switch automatically on October 1. Each continues issuing its configured version until Persona coordinates its SOP 3.0 cutover with you. You do not need to change the Persona template configuration yourself.

OIDC Configuration

Persona’s IAS integration uses the OpenID Connect (OIDC) authorization code flow. To configure this in Persona, see this guide.

OIDC Flow

At a high level, your OIDC integration will look like the following:

1. Patient accesses your application.
2. Your application redirects the patient to Persona for IAL2 identity proofing.
3. Patient completes identity proofing and is redirected from Persona back to your application.
4. Your application exchanges the authorization code at Persona’s token endpoint and receives the ID Token.
5. Your application can use the ID Token in requests to the TEFCA network.

OIDC ID Token

After a patient successfully completes IAL2 identity proofing through a Persona inquiry, Persona generates a JWT-format OIDC ID Token signed by Persona’s private key. The token is returned to the IAS Provider (Relying Party) through the standard OIDC authorization code flow — the patient is redirected back to your configured redirect_uri, and your application exchanges the authorization code for the ID Token (and refresh token) at Persona’s OIDC token endpoint.

Persona’s ID Tokens follow the configured version of the TEFCA IAS SOP issued by the Sequoia Project (RCE).

Healthcare Common Identifier (HCID)

As the IAS Provider, you will need to supply your Healthcare Common Identifier (HCID) formatted as a URN per RFC 3001.

urn:oid:<hcid>

For example: urn:oid:1.2.3.4.5.6.7.8.9.10

The HCID audience value is configured on your Authentication Template in the Persona Dashboard. Note this control is only available if your Persona account is configured for TEFCA IAS Services. Contact Persona support if you do not have access. Persona automatically uses the configured value as the aud claim of every ID Token issued from that template.

The aud claim contains only your HCID URI. Your OIDC client ID is carried separately in the azp (Authorized Party) claim:

"aud": "urn:oid:<hcid>",
"azp": "env_<environment_id>.atoc_<auth_template_id>"

Persona’s OID

An Object Identifier (OID) is a globally unique, hierarchical identifier used to unambiguously identify organizations and systems across networks. OIDs are used in TEFCA to anchor a CSP’s identity within the trust chain.

Persona’s TEFCA CSP OID: 1.3.6.1.4.1.65312.2.10

If you are integrating with CommonWell, you may need to list Persona’s OID in your CommonWell dashboard.

Token Validation

ID Tokens are Base64URL-encoded and digitally signed by Persona. The cryptographic signature proves authenticity and makes tokens tamper-evident.

To validate a Persona-issued ID Token:

Tokens must be transmitted and stored securely. Per the TEFCA spec, data must be encrypted in transit (HTTPS/TLS) and at rest.

Refresh Tokens

Persona issues a refresh token alongside the ID Token. The refresh token can be used to generate a new ID Token without requiring the patient to complete a new inquiry.

The 90-day window reflects the period during which a patient’s verified identity can be considered current for the purposes of requesting medical records. See the section on Persona Wallet for more information on the re-verification experience for patients.

ID Token Claims

Standard Claims

These claims are included in TEFCA IAS ID Tokens, regardless of which demographics were verified. The tefca_ial2claims_version value identifies the claim format issued by the template.

Demographic Claims

Demographic claims depend on the SOP version configured on the Authentication Template and on what was verified during identity proofing. These changes take effect when a Workflow token switches automatically on October 1, 2026, or when Persona moves an OIDC template to 3.0 with you.

SOP 2.1 vs 3.0 claim changes

The namespaced claim keys use literal http:// and capitalized OIDC; they are identifiers, not links to visit.

SOP 3.0 required demographics

A 3.0 token requires given_name, family_name, birthdate (ISO 8601 YYYY-MM-DD), and a complete address. The address must include street_address, locality, region, postal_code, and country. Use a two-letter subdivision code for region (such as CA) and a two-letter country code for country (such as US); formatted is optional. At least one verified contact method, email or phone_number, is also required. When present, the verified email address or phone number itself is the verification signal; 3.0 does not include email_verified or phone_number_verified boolean claims.

If any required demographic, required address field, or both contact methods are missing, Persona does not issue a 3.0 token. The token endpoint responds with HTTP 400 invalid_grant when the failure occurs during code exchange; if it occurs during authorization, the redirect returns access_denied.

Claims included when verified

Do not require claims removed in 3.0 in your relying-party integration; the comparison above lists them and their replacements.

Sample ID Token

This illustrative SOP 3.0 payload shows required demographics, a verified email address, and examples of optional verified claims. Values are placeholders, not real patient data or usable identifiers. Optional demographics are omitted when not verified.

{
  "iss": "https://authenticate.withpersona.com/authenticate/oidc",
  "sub": "example-subject",
  "aud": "urn:oid:1.2.3.4",
  "exp": 1790892000,
  "iat": 1790888400,
  "auth_time": 1790888390,
  "nbf": 1790888400,
  "jti": "example-token-id",
  "nonce": "example-nonce",
  "azp": "example-client-id",
  "inquiry_id": "example-inquiry-id",
  "tefca_ial2claims_version": "3.0",
  "given_name": "Example",
  "family_name": "Patient",
  "birthdate": "1990-01-01",
  "address": {
    "street_address": "123 Example Street",
    "locality": "Example City",
    "region": "CA",
    "postal_code": "90210",
    "country": "US"
  },
  "email": "patient@example.com",
  "gender": "F",
  "http://rce.sequoiaproject.org/OIDC/claim/ssn_last_four_digits": "0000",
  "http://rce.sequoiaproject.org/OIDC/claim/zip_plus_four": "0000"
}

Flow Configuration Guidance

Persona has an IAL2 inquiry flow optimized for patient matching on the TEFCA network. There are a number of pathways by which an individual can verify their identity. Multiple evidence combinations that satisfy NIST IAL2 assurance are supported including but not limited to: REAL ID, passport NFC, DMV, and selfie verifications. The flow dynamically routes patients through the most appropriate pathway based on the documents they present.

Native Mobile Experience

TEFCA flows are configured to require the native mobile experience. Completion of the flow on web is not recommended because:

• Barcode capture is significantly more difficult with webcams.
• NFC chip reading is only available on mobile devices.

Persona Wallet

The Persona Wallet (Reusable Personas) can significantly improve the patient re-verification experience. Upon completion of an inquiry, patients will be prompted to store their government ID in their Persona Wallet; this is completely optional. Upon returning to subsequent inquiries, if a patient has stored their government ID with Persona Wallet, they can use their saved credentials to expedite the document verification steps.

Unique Patient Identifier

Accounts in Persona represent a single identity, consolidating all of an individual’s verification interactions and attempts over time. Using a consistent identifier allows Persona to link each inquiry to the same account and enables many fraud detection capabilities.

When integrating with Persona, associate an immutable unique identifier per patient as the login_hint in your authentication request. We map the value from the login_hint to the account reference_id in Persona and consolidate all inquiries to this same account.

Testing & Synthetic Patient Guide

Persona provides a sandbox environment for testing your TEFCA integration end-to-end before going live.

Sandbox Environment

You can use your sandbox environment to test your integration and the patient experience. Sandbox inquiries do not perform live data verification and allow for the simulation of passed or failed verifications.

Synthetic Test Patients

Qualified Health Information Networks (QHINs) have synthetic test patient data to facilitate testing IAS Provider to QHIN integrations. Persona supports the synthetic identities contained below.

To use the synthetic identities, create an inquiry in your sandbox environment. Enter either the phone number or email address of a synthetic patient in the inquiry. Ensure that the Pass verifications toggle is enabled and submit any phone or email confirmation code. Persona will update the inquiry and the account with the synthetic patient’s demographics and issue an ID Token with the corresponding demographics.

Plans Explained

TEFCA Individual Access Services by plan

Learn more about pricing and plans.