Scenarios · Health system IT

Build on the records your EHR already holds.

Integration teams connect their EHR's FHIR R4 endpoint once, with a backend client key they register themselves. Studio apps, workflows and agents then read patients, practitioners, appointments and coverage through that one governed connector — read-only, authorized per call, and on the same audit chain as everything else.

What changes for your team: a new internal tool no longer starts with a custom interface project. The EHR connection is configured once; each app reuses it.

Where the work happens

  • Studio — the EHR Records template: FHIR-shaped entities and an import workflow that upserts by FHIR id.
  • Agent SDK — fhir.read and fhir.search tools, available only to agents granted PHI read access.
  • Audit & Trust — the audit export, optionally rendered as FHIR R4 AuditEvent and Provenance resources for your SIEM.

How it works

  1. You register HASP with your EHR, not the other way around.

    Generate a client key in settings and register its public key with your EHR as a SMART Backend Services client. Your EHR issues the client ID and decides which resources the client may read. The private key never leaves HASP and is never shown again. Lookups send patient identifiers to your EHR unredacted, because that is how a FHIR search finds a record; the connection only reads, and only from the EHR you register.

  2. Records land in entities that already speak FHIR.

    The template's Patients, Practitioners, Appointments and Coverages follow FHIR R4 field names and coded values. The import workflow reads each type and matches records on their FHIR id, so re-running it updates rather than duplicates.

  3. Agents look things up only when they are allowed to.

    An agent's EHR lookup is checked before it runs: the connector must be bound to the project and the agent must hold PHI read access. Every call is recorded on the audit chain.

  4. Your SIEM gets the audit trail in a format it understands.

    Request the audit export as FHIR R4 and the package carries an AuditEvent bundle next to the signed export. The signed export stays the evidence of record — verify it with the published recipe.

Try this as a Studio template.

Talk to Sales → See the template →

Why this survives governance

  • Read-only by construction.

    The connector has no create or update operation. Nothing built on it can write back to the EHR, so the clinical system of record stays the only place clinical data changes.

  • Your credentials, your EHR's access rules.

    The EHR is reached with a client your team registered, under scopes your EHR grants. HASP orchestrates, gates and audits the call; it does not become a second system of record for your EHR's access policy.

Connect your EHR in your environment.

Talk to us → See Audit & Trust →