Your interface engine is inside your HIPAA boundary. Why isn't your iPaaS?
Samba runs in your cluster. PHI never transits a vendor tenant — and there is no BAA to negotiate, because we never hold your data in the first place.
The finding nobody wants
You already treat the interface engine as in-scope. It handles 270/271 eligibility, claims, ADT feeds, clinical results — so it sits inside the boundary, under your controls, in your data center or your subscription. Nobody argues about this.
Then a modernization project adds a cloud integration platform beside it, and the same data starts flowing through a vendor's multi-tenant runtime. The architecture diagram changed; the regulatory obligations did not. What follows is a BAA negotiation, a vendor risk assessment that never quite closes, and an audit question you would rather not have to answer.
The cleanest way to answer it is for the answer to be structural: the integration tier runs where the interface engine runs, inside the boundary you already maintain.
When this comes up
CMS interoperability & prior-authorization APIs
FHIR-based requirements are forcing payers to build integration capacity on a deadline. The platform decision made under that pressure tends to outlive the project that drove it.
HITRUST certification or renewal
Every system in scope has to be evidenced. A multi-tenant processor in the integration tier turns into a vendor assurance workstream that runs in parallel with the assessment.
Epic or Cerner migration
Large EHR programs surface every undocumented interface in the estate. It is the moment integration architecture actually gets decided rather than inherited.
Payer-provider data exchange
Two organizations, two boundaries, and PHI moving between them. Neither side wants a third party holding the data in the middle.
The boundary math
What changes, concretely, when the integration tier stays inside your boundary:
Samba |
Multi-tenant iPaaS | |
|---|---|---|
| Business associate agreement | Not required for the data path — we never receive PHI. | Required, negotiated, and renewed. |
| PHI in the vendor's systems | None. Payloads stay in your cluster. | Processed in the vendor's tenant. |
| Breach notification exposure | No third party to notify you late. | Vendor breach is potentially your reportable event. |
| Minimum necessary analysis | Bounded by systems you already assess. | Extends to a processor you cannot inspect. |
| HITRUST / audit scope | Inside the assessment you already run. | A separate vendor assurance exercise. |
| Control evidence | Generated in your environment, on your schedule. | Requested from the vendor, on theirs. |
Where Samba fits, and where it doesn't
A good fit
REST and FHIR-shaped exchange between systems you control; payer-provider data exchange; eligibility and prior-authorization workflows; feeding a data platform from clinical and claims systems; anything where the transform logic needs to be reviewed by a human and retained as evidence.
Not a fit
Samba is not an interface engine replacement and does not pretend to be one. If you need native HL7v2 or X12 parsing as a first-class capability today, that is roadmap for us, not shipped — and we would rather tell you now than in week six of an evaluation.