Patient Consent & Data Collection

​

Overview

1. Patient Consent — Patient-facing flows built with Fasten Stitch capture identity, grant authorization, and return the identifiers your backend needs to act on the consent.
2. Data Collection — Server-side jobs use the identifiers to request exports, monitor webhooks, and deliver the records to downstream systems while respecting retention policies.

​

Stage 1: Patient Consent

​

Your Role

• Introduce Fasten Stitch in your application where patients expect to manage their health data.
• Explain the benefits of sharing EHI and how their data will be used.
• Introduce Fasten as a trusted intermediary that simplifies access to multiple health systems.
• Confirm that the patient authenticated successfully with their health system.
• Persist the org_connection_id and related metadata emitted by Webhook or Stitch events for later API calls.

​

Implementation steps

1. Embed Stitch — Add the fasten-stitch-element to your application, supplying a public key that matches the deployment environment.
2. Listen for events — Parse the widget.complete event from the Stitch event bus and hand off the event payload to your backend over a secure channel.
   • (Optional) Register a webhook endpoint so you can receive patient.connection_success event notifications as a backup or for auditing.
3. Store consent artifacts — Persist the org_connection_id, brand_id, and other metadata alongside your patient record to build an auditable consent log.

​

Success indicators

• Stitch reports connection_status: authorized for the selected health system.
• Your backend acknowledges receipt of the org_connection_id and ties it to the patient in your system of record.
• Consent timestamps and environment (test vs live) are recorded for audits.

​

Stage 2: Data Collection

​

Kick off exports

• Use the /bridge/fhir/ehi-export endpoint with the stored org_connection_id.
• This API call must be made from a secure backend environment using your private key.
• Asynchronously handle the response, capturing the task_id for tracking.

​

Monitor completion

• You will be automatically subscribed to patient.ehi_export_success and related events at your registered webhook URL.
• Validate the task_id in incoming events against the job you launched and record progress updates for support visibility.
• Tasks will automatically time out after a reasonable period (Fasten will send a patient.ehi_export_failed; implement retry logic for transient failures or delays.

​

Retrieve records

• Retrieve the download link(s) from the webhook payload and stream the file(s) to your storage tier before the URLs expire
  • Links are valid for 24 hours from the time of the webhook event.
• Import, convert or fan out the FHIR JSONL export into downstream formats (clinical data repository, data warehouse, analytics pipelines, or patient-facing portals).
  • Ensure your systems can handle large files and variable resource counts. (eg. 30MB with 500 resources vs 3GB with 5,000 resources + Binary data).
  • Use a Clinical Data Repository (CDR) that natively supports FHIR to simplify ingestion and querying.
    • Open Source - Medplum, HAPI)
    • Azure Health Data Services
    • AWS HealthLake
    • GCP Healthcare API
• Apply retention policies: exports expire in Fasten storage after 24 hours, so plan long-term retention in your own infrastructure.

​

Putting it together

• Orchestrate both stages with a job tracker that links consent events, export requests, webhook updates, and downloads.
• Inform patients with status updates or notifications when collection finishes, reinforcing trust in the consent they granted.
• Iterate by reviewing failure logs from both stages to tune patient messaging, retry logic, and webhook reliability testing.