Patient API
The Patient API provides SMART-authenticated endpoints for patient-facing applications. These endpoints use the patient's own access token (obtained via SMART App Launch) and are separate from the admin API.
Base Path
All patient API endpoints are under /api/.
SMART Health Links
POST /api/shl/ and the manifest, FHIR and DICOMweb routes beneath it.
Spec-compliant SHL creation and manifest serving, for sharing a record by QR code. See the SHL specification.
No real token leaves the server. The manifest carries an opaque session token whose audience points back at /api/shl/fhir, so a recipient calls this proxy and the backend fetches from the FHIR server with a service account. Every manifest fetch re-derives what the link asserts — how long it is good for, and what the share covers — from the share as it stands now, so correcting the rule behind a share also corrects links already in circulation, and a revoked consent makes the session inert.
Consent Notification
POST /api/consent/notify-access-request
Notifies a patient by email that a practitioner has requested access to their data. The address is resolved from the identity provider rather than taken from the request.
Document import and the scribe have moved
POST /api/document-import/, POST /api/patient-scribe/ and POST /admin/document-import/ were removed.
Turning a PDF or a free-text description into FHIR resources is not an authorization concern. Keeping it here meant this service also carried a PDF text extractor and the Java runtime it needed, and reached for an AI model — none of which an authenticating proxy has any reason to contain. Document import belongs to whichever service in a deployment owns clinical ingestion, and a self-hosted deployment that wants it needs to run one; this proxy no longer provides it.
What has not changed is where the resulting resources go. An importer only ever returned them for review; the portal still POSTs the ones a patient confirms through the FHIR proxy, which is what enforces scope, consent and audit.