How SoFaaS™ works under the hood.
For technical buyers. The architecture, the data flow, the security model, and the responsibility split between your team and ours.
Architecture
Your app talks to the SoFaaS™ runtime. The runtime talks to Epic. Three parties, one stable contract.
Authentication: SMART App Launch + OAuth 2.0
Your app launches from inside the EHR with patient context. The launch handshake, token exchange, scope negotiation, and session management run on SoFaaS™ using the standard SMART App Launch flow. Your app receives a validated session and the resource scopes it requested.
Refresh tokens, audience validation, JWKS rotation, and signing-key management are handled at the platform level. You never write OAuth code.
FHIR resource handling
SoFaaS™ exposes typed handlers for the FHIR R4 resources your category needs — Patient, Encounter, Observation, Condition, MedicationRequest, DocumentReference, ServiceRequest, and the rest. Reads, writes, and search parameters are validated at the runtime layer before they reach the EHR.
When Epic adds a new resource version or changes a field, the runtime is updated for all customers at once. Your code keeps working.
Multi-tenant model
Two tenancy levels: vendor (you) and hospital (your customer). Your apps and configs live in your vendor workspace. Each hospital deployment is its own isolated tenant underneath, with separate credentials, separate audit logs, and separate data boundaries. A bug or breach at one hospital cannot reach another.
Security boundaries
- • All in-flight traffic is TLS 1.2+.
- • All at-rest data is encrypted with managed keys.
- • Every request through the runtime is logged with caller, scope, resource, and outcome.
- • RBAC and SSO at the vendor workspace level.
- • Runtime infrastructure is HIPAA-aligned hosting under our BAA.
Responsibility split
| You build | SoFaaS™ provides |
|---|---|
| Build the app's UI and product logic | Host and run the app inside the EHR |
| Decide which FHIR resources you need | Provide pre-built FHIR handlers for those resources |
| Bring the hospital relationship | Handle Epic Showroom submission and listing |
| Maintain your own product code | Maintain the runtime through every Epic change |
| Sign your customer-facing contracts | Provide BAA and SOC 2 Type II report |
| Own your customer data outside SoFaaS™ | Operate audit logging and access control inside SoFaaS™ |
Deployment + observability
New versions of your app deploy to your vendor workspace; promotion to a specific hospital tenant is gated. Every hospital deployment has its own observability dashboard covering request volume, latency, error rate, and FHIR resource breakdown.
Audit logs are queryable by your team and exportable for hospital review.
FAQ
What standards does SoFaaS™ implement?
SMART App Launch, OAuth 2.0, and FHIR R4. Your app launches from inside the EHR with patient context; the launch handshake, token exchange, scope negotiation, and session management run on SoFaaS™ using the standard SMART App Launch flow.
Do I have to write any OAuth code?
No. Refresh tokens, audience validation, JWKS rotation, and signing-key management are handled at the platform level. Your app receives a validated session and the resource scopes it requested.
What happens when Epic ships breaking changes?
When Epic adds a new resource version or changes a field, the runtime is updated for all customers at once. Your code keeps working.
How is multi-tenancy structured?
Two tenancy levels: vendor (you) and hospital (your customer). Your apps and configs live in your vendor workspace. Each hospital deployment is its own isolated tenant underneath, with separate credentials, separate audit logs, and separate data boundaries. A bug or breach at one hospital cannot reach another.
Where do audit logs live and who can see them?
Every request through the runtime is logged with caller, scope, resource, and outcome. Audit logs are queryable by your team and exportable for hospital review.