HIPAA-compliant CSV import: alternatives to OneSchema

Most CSV import vendors will sign a BAA if you push. The interesting question is what changes about the integration on the day they sign it. Usually: not much. The data still flows through their inference and their storage; the BAA shifts liability but not architecture.

AdaptivMapr started from the opposite end. The default mode of the product is built so a BAA is not required at all — only column headers and at most three sample rows (clamped to 80 characters each) leave the customer's browser. That clamp is enforced at the HTTP edge in every route that accepts sample data, by a single chokepoint function in lib/parser.ts. There is no setting that loosens it.

Schema-only mode

In schema-only mode the LLM never sees a row of PHI. It sees something like:

["AHV", "Vorname", "Nachname", "Geb.Dat."]

and three pseudonymous rows. The mapping proposal comes back; the customer's code applies the mapping locally; the full file never touches AdaptivMapr's network. The legal team's review takes an afternoon because there is, in the literal sense, no PHI to govern.

That is the difference. A generic importer with a BAA is still a PHI processor. AdaptivMapr in schema-only mode is not a PHI processor, and the contract reflects that — no DPA needed, free and unlimited.

When you need full-data mode

About 5% of import jobs really do need row-level cleanup. Names in one column ("John A. Doe") that have to be split. Free-text gender fields with "M", "male", "Männlich", "Homme" all meaning the same thing. Partial addresses that need geocoding. For these, AdaptivMapr does not run the LLM call itself — it delegates to PHI Gateway, which has the jurisdiction-aware inference infrastructure and the BAAs with the providers already in place.

The result is that full-data mode inherits the PHI Gateway BAA, which the customer has already signed for the rest of their clinical stack. There is no second negotiation.

What this means for switching

Teams currently routing PHI through OneSchema, Flatfile, or an in-house import widget end up reviewing two things on a switch:

• The 95% of imports that can run in schema-only mode and stop being a compliance line item entirely.
• The 5% that need full-data, which run under the inherited PHI Gateway BAA instead of a vendor-specific one.

Neither of those is a feature comparison. They are architecture-level changes that show up in the legal review rather than the spec sheet. That is the only reason to switch. Everything else — UI polish, ecosystem, framework adapters — is either at parity or behind the incumbents, and we do not pretend otherwise.

See the migrate-from-OneSchema page for a fair comparison, or jump straight to the healthcare template catalog.