Clinical decision support

Your model is right. Your runtime isn't ready.

CDS vendors don't fail on the model. They fail on the runtime around it — the per-hospital integration, the clinician-workflow surface, the audit trail, the compliance posture. SoFaaS™ owns that runtime so your recommendations ship into the hospitals that already trust it.

The shape of a stuck CDS deal

The clinical leadership wants the recommendation. The model performs. The pilot was successful. Then the deal hits the wall: no SMART App Launch surface inside the workflow, no audit on the FHIR reads your model needs, no Showroom listing, no standardized way to write the recommendation back into the chart.

Each hospital wants a different answer to the same question. Without a runtime, you're rebuilding the integration from scratch every time.

What hospital review actually asks CDS vendors

  • What patient data does your model read, when does it read it, and where does it go?
  • How does the recommendation surface inside the clinician workflow without breaking it?
  • What's the audit trail when a clinician accepts, modifies, or rejects a recommendation?
  • How do we disable or scope the deployment without redeploying your app?
  • Show me your SOC 2 Type II report, your BAA, and your sub-processor list.

What SoFaaS™ handles for you

SMART App Launch

Recommendation surface launches inside Epic with patient and encounter context.

Scoped FHIR reads

Standardized read access for the resources your model needs, with audit on every call.

Recommendation write-back

Task, ServiceRequest, or Communication — whichever fits the hospital's workflow.

Per-deployment scoping

Disable, scope, or roll back from the runtime without redeploying your app.

SOC 2 Type II + BAA

Full report shareable under NDA the same week procurement asks.

Showroom listing

Submission and ongoing maintenance handled. Distribution open by the time you're cleared.

The first hospital is hard. The tenth is harder.

The first hospital teaches you what CDS review actually looks like — clinical safety, audit, governance, deployment scoping.

The tenth hospital is what kills internal-build CDS platforms. Each one wants its own SSO, its own audit format, its own EHR version, its own answer to "how do we kill-switch this if the model drifts?" Without a runtime, every hospital is another integration project.

SoFaaS™ sits between your CDS product and the long tail of hospital-specific requirements. You ship the same model; we make it deployable into every hospital that asks.

FAQ

Why does CDS get stuck in hospital review?

Clinical decision support touches the clinician's active workflow with a recommendation that, if wrong, has clinical consequences. That triggers the longest version of every hospital review — clinical safety, model governance, data provenance, audit, and integration with order entry. Most CDS vendors burn months per hospital reconciling those reviews because they're rebuilding the runtime each time.

What does SoFaaS™ handle for a CDS vendor?

SMART App Launch into the clinician workflow with patient and encounter context, FHIR read access for the resources your model needs, write-back of recommendations as the right resource type (Task, ServiceRequest, Communication — whatever fits), audit logging the hospital can ingest, the SOC 2 Type II + BAA posture, and the Epic Showroom listing. You keep the model, the rules engine, and the clinical content — the parts that make your CDS yours.

How does this work with our existing rules engine or model?

Your engine stays where it is. SoFaaS™ is the layer between Epic and your engine — the FHIR reads that feed your model, the write-back of the recommendation, the per-hospital configuration of where in the workflow it surfaces. We don't touch the clinical logic; we own the runtime around it.

What about clinical safety and model governance?

Clinical safety review of the recommendation logic stays with you and the hospital — that's a clinical conversation, not a runtime one. SoFaaS™ makes that conversation easier by giving the hospital a clean audit of every read and write your CDS performs, plus a standardized way to disable, scope, or roll back the deployment.

Does this work for prospective CDS or just retrospective?

Both. Prospective CDS that fires inside the clinician workflow uses SMART App Launch and writes recommendations back as the appropriate FHIR resource. Retrospective CDS that runs against population data uses scoped FHIR Bulk Data access through the same compliance posture. The runtime supports both shapes.

Have a deal stuck on Epic?

Tell us about it. Half-hour call. We'll know within 15 minutes whether SoFaaS™ can unblock you.

Talk to us