Templates Healthcare

Healthcare

EHR Records (FHIR)

Patients, practitioners, appointments and coverage shaped like FHIR R4 — imported read-only from your EHR.

What's inside

  • Patients , **Practitioners**, **Appointments** and **Coverages** entities — field names, cardinalities and coded values follow FHIR R4
  • EHR Records app — internal-only view for staff
  • Import from EHR workflow — reads each resource type through the FHIR connector and upserts it by FHIR id
  • No sample records: previews use synthetic FHIR resources until your EHR is connected

Required integrations

  • fhir

EHR Records (FHIR)

Start a Studio app from the records your EHR already holds. The four entities follow the shape of FHIR R4 Patient, Practitioner, Appointment and Coverage, so data read from any FHIR R4 server lands in them without per-field glue.

How it works

  1. Connect the FHIR (EHR) integration in org settings: generate a client key, register its public JWK with your EHR as a SMART Backend Services client, and enter the client ID your EHR issues.
  2. Bind it to this project as ehr.
  3. Run Import from EHR. Practitioners and patients import first, then appointments and coverage, so their references resolve to the records just imported.
  4. Run it again at any time — records are matched on their FHIR id and updated in place. Each step follows the EHR’s result pages up to its max_pages limit (20 by default).

EHR data is PHI, so imports run only for an organization on a paid plan with an active BAA.

Patient identifiers are sent to your EHR unredacted. HASP removes PHI from what other integrations send out, but not from this connector: a FHIR search finds records by patient identifiers, and it sends them only to your own EHR. The connector only reads, and every request is on the audit chain. You confirm this when you connect the integration.

Before you run it against a production EHR

  • Add search filters. The import steps ship with no filter, only a page size. Many production EHRs refuse an unfiltered search on patients, appointments or coverage. Others allow it but return far more than you want: at the default limits a step stops after 1,000 records (50 per page × 20 pages) and reports next_page_url in its output. Set each step’s search params, for example appointments in a date range, before the first real run.
  • Cardinality is a guide, not a gate. Fields that FHIR marks as required are flagged required in forms. A record imported from the EHR is still saved if the EHR leaves one out.

What you can extend

  • Narrow each import with FHIR search parameters (for example, today’s appointments only) in the step’s search params.
  • Add a schedule trigger to keep the records in sync.
  • Hand an agent the fhir.read and fhir.search tools to look up a single patient or appointment on demand.

The connector is read-only: nothing in this template writes back to your EHR.