TEFCA IAS Developer Guide

​

What is TEFCA IAS?

​

General Flow for Developers

1. QHIN Integration Fasten connects with a Qualified Health Information Network (QHIN). QHINs are essentially the access points to the TEFCA framework. They provide the network APIs and routing needed to reach records across participating health systems.
2. Identity Verification via CSPs To ensure patients are who they say they are, Fasten relies on Credential Service Providers (CSPs) certified by the Kantara Initiative. These vendors verify patient identity using government ID + facial match and return an OpenID Connect Token containing verified attributes (e.g., name, DOB).
3. Secure Data Requests When Fasten queries the QHIN for records, it attaches the patient’s OpenID Connect Token. The QHIN (and any downstream nodes) validate the token using the public key published by the CSP. This ensures requests are tied to a verified patient identity and trusted by the network.
4. Record Retrieval Once validated, Fasten can retrieve longitudinal health records from the appropriate source system through the QHIN, normalize them, and make them available via our unified API.

​

Enable Tefca Mode

<fasten-stitch-element
    public-id="pub_test_xxxxxxxxxx"
    tefca-mode="true"
></fasten-stitch-element>

​

Differences

• Patient experience – Catalog search and portal credential prompts are skipped. Patients are taken directly into a TEFCA IAS identity-proofing flow (CLEAR or ID.me), so adjust your in-product copy and support content to set that expectation before the widget launches.
• Event/webhook payloads – When TEFCA mode is on, endpoint_id, portal_id, and brand_id are often omitted from client events as well as patient.connection_* webhooks. Persist tefca_directory_id when it is returned so you still have a stable identifier for branding or analytics, and verify code paths that previously assumed the other catalog identifiers were always populated.
• Scopes – TEFCA connections always return a scope value of patient/*.read. If you surface granted scopes to users or use them for authorization logic, rely on this fixed scope string and remove assumptions about per-EHR variability.
• No-records failure behavior – TEFCA-enabled exports may fail with failure_reason: tefca_no_documents_found in the patient.ehi_export_failed webhook. This means the health system did not return any records for the individual. It is frequently seen in test mode, but is uncommon in live mode. If you are testing the API workflow, you can set fixtures.tefca_ccda on the EHI Export request to receive a known synthetic response instead of relying on the upstream test system to return data.

​

Example Test Patients

​

Clear Test Patients

​

ID.me Test Patients

​

How to Use Test Patients

1. Embed the Fasten Connect widget in your application with TEFCA IAS mode enabled.
2. Log in with the provided email address
3. When prompted to provide identity verification (using Clear or ID.me), use the corresponding phone number + email address (for CLEAR) or email address + password (for ID.me)
4. Follow the flow to authenticate, consent, and retrieve data.

​

Use Fixtures for Deterministic Test Exports

{
  "org_connection_id": "xxxxx",
  "fixtures": {
    "tefca_ccda": "myra-jones.xml"
  }
}

• myra-jones.xml
• lennie-connell.xml

​

Reset Synthetic Patients Between Runs

• Authenticate with HTTP Basic auth using your test mode public id/private key; live credentials are rejected.
• Pass the email of the synthetic patient you want to reset (see the table above).
• All vault connections for that patient are revoked so the next run starts from a clean slate.

curl -X POST https://api.connect.fastenhealth.com/v1/bridge/vault_connection/revoke \
  -u "public_test_xxxxxxxxxx:private_test_xxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "dogbeaker@aol.com"
  }'