Skip to main content

​
Onboarding And Environment Setup

​
What is the difference between test mode and live mode?

Test mode only connects to sandbox environments and synthetic or vendor-provided test data. Live mode uses live credentials and production configuration. The Developer Portal toggle switches which mode’s credentials, webhooks, and logs you are viewing; it does not disable your account or permanently change your setup.

​
Do test and live mode use separate API keys and webhooks?

Yes. Generate separate credentials and configure separate webhooks for test and live mode. Test credentials and test webhooks will not work in production (live mode).

​
Can we reuse the same webhook URL in test and live mode?

No. Webhook URLs must be unique for your organization. Test and live webhooks have separate signing secrets, so use distinct URLs per environment.

​
Patient Connections

​
Does a patient need to log in to every health system individually?

For portal-based SMART-on-FHIR connections, yes. The patient authorizes each health system or portal separately using that system’s login flow. For TEFCA mode, patients verify identity through a supported Credential Service Provider, such as CLEAR or ID.me, but TEFCA coverage depends on participating networks and source availability. Some workflows may still require portal login.

​
How should we associate a Fasten connection with our user?

Pass a stable, server-generated user id, session id or equivalent reference as external_id when starting the flow.

​
How do we know a connection succeeded?

Listen for the connection success client event and store the org_connection_id. This ID is the durable reference you will use for later export and status workflows. We strongly recommend that you also register a webhook and listen for the patient.connection_success event as a backup or for auditing purposes.

​
EHI Export

​
Why does Fasten use JSONL files instead of FHIR Bundles?

Fasten supports exporting data in FHIR Bundle format, but we recommend using JSONL (also known as NDJSON) for several reasons:
  1. Reduced Redundancy: FHIR Bundles often include redundant data structures. A Fasten-generated Bundle wrapper doesn’t provide any additional information compared to JSONL.
  2. Industry Standard for Large Exports: JSONL is widely used in the HL7 community for large FHIR exports, including bulk/population EHI export endpoints.
  3. Streamlined Processing: JSONL files are ideal for use with streaming JSON processors, which we recommend due to the variability in export sizes. Using a FHIR Bundle wrapper would make streaming processing either impossible or significantly more complex, depending on the programming language.
While we can provide FHIR Bundles if needed, JSONL is the default format because it’s more efficient and better suited for most use cases.

​
Where do we get failure details?

Use the patient.ehi_export_failed webhook. It contains the failure_reason and other context.

​
Do we need to poll the export status endpoint?

Prefer webhook-driven processing. Polling can be useful as a fallback, but webhooks are the primary path for completion and failure events.

​
Webhooks

​
Why did we receive duplicate webhooks?

Webhook systems are at-least-once delivery systems. Retries, network failures, and downstream acknowledgement timing can produce duplicate events with identical payload bodies or task IDs. Make webhook handlers idempotent.

​
How many times are webhook events retried?

Fasten webhook delivery retries events with exponential backoff — up to four retries over roughly the next 24 hours.

​
Catalog Search And Provider Matching

Send support:
  • Provider or facility name.
  • Provider Website URL.
  • Patient Portal URL (if available).
  • Location, city, and state.
  • Any DBA or alternate names.

​
Can Fasten give an ETA for upstream EHR fixes?

Often no. EHR/vendor issues can be opaque and depend on that vendor’s triage process. Fasten can file tickets, provide evidence, and follow up, but source-side timelines are not always predictable.

​
Sandbox And Test Data

​
Is sandbox data representative of production?

Not always. Many EHR and payer sandboxes contain synthetic, incomplete, stale, huge, or malformed data. Some are heavily rate limited. Use sandbox data for integration mechanics, but validate product assumptions with live or more realistic datasets when possible. See our Test Data Guide for more details.

​
Can the same sandbox patient exist across multiple providers or payers?

Usually no. Sandboxes are generally isolated by EHR or payer and are not coordinated with each other.

​
TEFCA

​
Does TEFCA replace portal login?

TEFCA can reduce reliance on individual portal logins, but it does not eliminate every portal-based workflow. Network coverage, QHIN behavior, identity proofing, and source participation all affect whether records are available through TEFCA.

​
Which identity providers are supported?

Fasten has supported CLEAR and ID.me for identity proofing. BYO Identity workflows may be available for eligible customers, but they require setup and confirmation.

​
Why does TEFCA mode fail on localhost or in private browsing?

TEFCA mode requires cookies. When you host your app on localhost, browser security sandboxing can restrict cookies and prevent the TEFCA flow from completing. Similar cookie restrictions can occur in private browsing or incognito mode.

​
Is Fasten at risk of being shut down like other platforms that allow access to medical records for non-clinical use?

No, Fasten operates under a completely different legal framework compared to platforms like Particle Health, Health Gorilla and Metriport which act as on-ramps to the national health information exchanges (HIEs). Here’s why Fasten is fundamentally different:
  1. Patient Access Rights: Fasten leverages patient access to their own medical information, a right established under HIPAA and reinforced by the Cures Act Final Rule. This ensures patients can access and share their records electronically with any app or platform they choose.
  2. Patient Consent: The process is built around patient consent. Patients log in via their provider’s patient portal and specify exactly which records they want to share.
  3. No HIE Dependency: Unlike HIE on-ramp platforms, Fasten does not connect to HIEs or rely on their networks. HIEs operate as walled gardens requiring HIPAA compliance and specific clinical relationships, which has led to issues like the Particle Health - Epic lawsuit.
  4. Information Blocking Protections: Blocking access to patient access APIs would constitute information blocking, which is strongly opposed by the ONC (now ASTP). These APIs are new (introduced in December 2022) and are designed to ensure patients have uninterrupted access to their data.
Fasten’s approach is fully aligned with patient rights and regulatory requirements, making it a secure and compliant platform for accessing medical records.