Ship a SMART on FHIR app into Epic — buy a runtime, list on Showroom, use Redox, or build it in-house
"Compare" pages usually argue on price. We're going to argue on responsibility — what stays your problem under each option, and what doesn't. First hospital is measured from Day-1 launch through hospital BAA — often weeks once the runtime exists. Showroom submission is packaged with SoFaaS™; listing timing follows Epic's queue. We own the package, not the queue.
Which tool for which job
Before the full matrix: three jobs that get confused constantly. A listing, a runtime, and an integration platform are not substitutes for each other.
| Job | What it is | What it is not | When you need it |
|---|---|---|---|
| Epic Showroom (listing / distribution) | Epic's vendor marketplace. Hospitals discover, evaluate, and request third-party apps for deployment in their Epic instance. Formerly App Orchard. | Not a runtime, host, BAA, SOC 2 program, or integration engine. A listing does not make the app launch in a hospital's Epic. | Whenever a third-party app will be deployed across Epic-using hospitals. Internal health-system apps registered only inside one Epic instance can skip Showroom; everyone else cannot. |
| Redox or similar (data translation / integration) | An integration platform that translates and moves clinical data between systems — HL7 v2, FHIR, non-Epic sources, payers, devices. | Not a SMART on FHIR launch runtime, not Epic Showroom, and not a substitute for HIPAA hosting or hospital security review of an in-EHR app. | When you must exchange data with systems outside the Epic SMART launch path — other EHRs, ADT feeds, labs, payers, device clouds. Often used alongside a runtime, not instead of one. |
| SoFaaS™ (compliant SMART on FHIR runtime) | A managed runtime your app launches on inside Epic: SMART App Launch and OAuth, FHIR mappings, HIPAA hosting and BAA, SOC 2 Type II evidence, Showroom submission, per-hospital deploy, quarterly Epic maintenance. | Not a listing, not a data-translation bus, not a public site host, not a server-to-server FHIR client, and not VectorCare's patient-logistics product. | When the product must launch inside the clinician workflow via SMART on FHIR and the bottleneck is compliance, distribution, and keeping the integration alive — not scaffolding the app. |
Where we don't compete
Redox and 1upHealth solve a different problem. If you need to translate clinical data between many non-Epic systems, normalize FHIR across payers, or aggregate longitudinal patient records, those platforms are the right tool. Many SoFaaS™ customers use one of them alongside SoFaaS™ for non-Epic data flows. We're not asking you to pick.
Epic Showroom is non-negotiable for multi-hospital distribution. Every Epic-deployed third-party app needs the listing. The question is who runs the submission and who runs the runtime your listing points at. SoFaaS™ does both as part of the same engagement.
Building it yourself is a real option. If you have the engineering bench, the compliance team, and the patience for 12–18 months before the first hospital is live — you can build it. Most healthcare vendors who try end up shipping a runtime that looks a lot like SoFaaS™, four quarters later, after the first deal already churned.
1upHealth is a FHIR data layer, not a launch surface. If you need aggregated longitudinal records or a normalized FHIR API across sources, it is the right object. It still does not put your clinician-facing app in the chart.
Not a replacement for
- Redox, Mirth, or any integration engine
- 1upHealth or another FHIR data layer
- An Epic Showroom listing
- The vendor's own application and clinical UX
- A hospital's Epic instance
- VectorCare.com logistics products
- Public-facing or server-to-server FHIR consumers
Is a replacement for
- Building your own HIPAA hosting
- Standing up your own BAA program
- Producing your own SOC 2 evidence packet
- Writing SMART App Launch and OAuth plumbing
- Running Epic Showroom submission ops
- Quarterly Epic-change maintenance
SoFaaS™ (compliant runtime) VectorCare | Redox Integration platform | 1upHealth FHIR data platform | Build it yourself Internal engineering | Epic Showroom alone Listing only | |
|---|---|---|---|---|---|
| What it actually is | A compliant runtime your app launches inside Epic on top of | An integration platform that translates data between systems | A FHIR API gateway and longitudinal patient data layer | Engineering scope for your team to design, build, and operate | Epic's vendor marketplace listing program |
| HIPAA hosting + BAA on day one | Inherited from the SoFaaS™ platform | Hosting yes; per-deal BAA varies | Hosting yes; per-deal BAA varies | You build and certify it yourself | Not Showroom's role |
| SOC 2 Type II evidence packet | One report, accepted across the platform | Vendor-level report | Vendor-level report | Your audit, your timeline | Not part of the listing |
| Multi-hospital distribution | Same runtime, every hospital — config, not custom code | Per-hospital integration work each time | Per-hospital integration work each time | Re-validation per hospital | Listing visible to every Epic hospital |
| Time to first hospital | Day 1 launch · ~2 weeks Showroom submission filed · weeks to first live site (hospital BAA / security) | N/A — not a launch runtime | N/A — not a launch runtime | 12–18 months | Months (submission + queue), then you still need a runtime |
| Time to tenth hospital | Days of configuration | N/A — not a launch runtime | N/A — not a launch runtime | Quarter per hospital | Same listing; runtime work still per-hospital |
| Maintenance when Epic ships breaking changes | Platform-managed; your app keeps running | Platform-managed for the integration layer only | Platform-managed for the integration layer only | Your team, every quarter | Vendor's responsibility |
| Epic Showroom listing handled | Submission run on your behalf | You handle it | You handle it | You handle it | It is the listing |
| What you still own | Your code, your IP, your clinical UX, your customer relationship | Your code + your hosting + your compliance posture | Your code + your hosting + your compliance posture | Everything | Your code + hosting + compliance + maintenance |
Package vs queue.
SoFaaS™ runs Showroom submission ops and points the listing at a compliant runtime. Epic decides when the listing appears. Hospitals decide when BAAs and security reviews clear.
A note on pricing
SoFaaS™ pricing is scoped to your deployment — implementation plus a recurring fee tied to the size of the deal we unblock. We don't publish a number because the right number depends on the deal you're trying to close. When we run the math against that deal, it tends to get obvious fast.
FAQ
Is SoFaaS™ a replacement for Redox or 1upHealth?
No. Redox and 1upHealth are integration platforms — they translate clinical data between systems. SoFaaS™ is a deployment runtime — your app launches inside Epic on top of it. Many SoFaaS™ customers use an integration platform alongside SoFaaS™ for non-Epic data flows.
Can I just build it myself?
If you have the engineering bench, the compliance team, and the patience for 12–18 months before the first hospital is live, yes. Most healthcare vendors who try end up shipping a runtime that looks a lot like SoFaaS™, four quarters later, after the first deal already churned.
Do I still need an Epic Showroom listing?
Yes. Every Epic-deployed third-party app needs the listing. The question is who runs the submission and who runs the runtime your listing points at. SoFaaS™ does both as part of the same engagement.
Is SoFaaS™ a Redox alternative?
No. Redox is data translation and routing between systems. SoFaaS™ is the runtime a clinician-facing app launches on inside Epic. Vendors frequently run both: Redox for non-Epic pipes, SoFaaS™ for the in-chart launch.
1upHealth vs Epic Showroom — which do I need?
They are different objects. 1upHealth is a FHIR data layer for aggregating and serving clinical data. Epic Showroom is a catalog listing that makes your app requestable by hospitals. Neither hosts your app or launches it in the chart.
Build vs buy — what am I actually buying?
The runtime, not the app. You keep your product, your clinical UX, your IP, and your customer relationship. What you buy is HIPAA hosting and BAA, SMART App Launch plumbing, the SOC 2 evidence packet, Showroom submission ops, per-hospital deploys, and quarterly Epic maintenance.
Can we just list on Showroom and host ourselves?
Yes, and plenty of vendors do. You then own hosting in the PHI path, the BAA, the SOC 2 report, each hospital's security questionnaire, and Epic-change maintenance. The listing supplies none of those.
SMART hosting vs Redox — which do we need?
If your app launches in Epic with patient context and reads/writes FHIR in that launch, you need SMART hosting — a runtime. You need Redox only if you also have HL7 v2, other-EHR, payer, or device data flows to translate. The two answers are independent.
Who maintains the integration when Epic ships quarterly changes?
On SoFaaS™, the runtime is updated for every customer at once and your app keeps running. In-house, that maintenance is a standing quarterly obligation on your engineering team.
Why doesn't this page show prices?
SoFaaS™ pricing is scoped to your deployment — implementation plus a recurring fee tied to the size of the deal we unblock. We don't publish a number because the right number depends on the deal you're trying to close. When we run the math against that deal, it tends to get obvious fast.
Have a deal stuck on Epic?
Tell us which option you're already on, what's actually blocked, and we'll tell you within 15 minutes whether SoFaaS™ would change the answer.