FHIR resources
SoFaaS™ speaks FHIR R4. You read and write through a stable API surface; the runtime translates to Epic's FHIR endpoints and back. Same code across every hospital.
Supported resources
Below is the resource surface most SoFaaS™ apps use in production. The runtime supports more, but these are the ones that have been hardened against the long tail of hospital-specific Epic configurations.
| Resource | Operations | Typical use case |
|---|---|---|
| Patient | read · search | Demographics, identifiers, contact info. |
| Encounter | read · search | Visit details, location, encounter type, status. |
| Observation | read · search · write | Labs, vitals, assessment scores. Most common write target for RPM and ambient. |
| Condition | read · search | Active and historical diagnoses. |
| MedicationRequest | read · search | Active and historical medication orders. |
| DocumentReference | read · write | Clinical notes. The standard write target for ambient scribes. |
| ServiceRequest | read · search · write | Referrals and orders for procedures, transport, DME. |
| Appointment | read · search | Scheduled appointments, availability. |
| Coverage | read | Insurance and eligibility. |
| Practitioner | read · search | Identify the launching clinician and the care team. |
Reads
Reads are direct: you ask for a resource by ID or run a search bound to the launch context. Patient context is enforced at the runtime — you can't accidentally read another patient's record by passing the wrong ID. The runtime returns 403 if you try.
For latency-sensitive workloads, batch reads are available. Don't loop over single reads in a hot path.
Writes
Writes are where most hospital security questions live. Every write through SoFaaS™:
- Is logged with full provenance (which app, which user, which encounter, what payload).
- Is bound to the active launch context — no out-of-band writes.
- Surfaces in the hospital's Epic audit log in a format their compliance team already ingests.
For DocumentReference writes (ambient scribes, AI documentation), the runtime handles the note formatting and signing flow Epic expects. You hand us the note content; we give it the structure that lets the clinician review, edit, and sign it inside the normal Epic workflow.
Search & paging
Search uses standard FHIR R4 query parameters. Results are cursor-paged — follow the next link until exhausted, or stop when you have enough. Don't depend on the absolute position of a record across pages; Epic instances vary on stable ordering.
Versioning
SoFaaS™ exposes a stable v1 API. When Epic ships breaking changes — and they do, roughly each quarter — we update the runtime. Your app keeps calling the same v1 endpoints. We publish a changelog and notify you in the console if a behavior change could affect your app, even when the API surface stays the same.
Need a resource that isn't in the table above? Tell us — we add resources based on what active customers actually need.