OpenAdaptWhere OpenAdapt runs and what it can see
OpenAdapt runs on a computer you control, signed in to your system, and keeps each run's full record there. OpenAdapt Cloud is designed to hold no patient or member details. We sign a BAA or PHIPA agreement before we record anything on real data. We don't hold a SOC 2 report.
Where one referral and one claim go
One referral, at a clinic
Your network
- Where the details come fromPatient detailsYour eReferral system, web form or AI document reader, as today. OpenAdapt receives the referral as data.
- The computer that runs itPatient detailsA computer or virtual machine you control, signed in to the EMR. It types the entry, shows the approval screen and keeps the full run record: values typed and read back, screenshots, who approved. Use the computer's full-disk encryption.
- Your EMRPatient detailsThe saved record. Typed in a signed-in session, then read back through read-only access, where your EMR offers it.
Outside your network
- OpenAdapt CloudDesigned to hold noneAccounts, approved program versions, run status and receipts. A receipt holds the result and the checks it ran, with no patient or member details. Exception today: referrals an AI vendor sends through OpenAdapt pass through it.
- OpenAdapt staffTest records onlyBuild and fix programs on test patients or test members, or on copies you approve.
One claim, at an insurer or TPA
Your network
- Where the details come fromMember detailsYour intake inbox, claim file or portal export, as data. OpenAdapt receives the claim as data.
- The computer that runs itMember detailsA computer or virtual machine you control, signed in to the claims system. It keeps the full run record on that computer.
- Your claims systemMember detailsThe saved claim. Typed in a signed-in session, then read back through a read-only database role, a report export or an API.
Outside your network
- OpenAdapt CloudDesigned to hold noneAccounts, approved program versions, run status and receipts. A receipt holds the result and the checks it ran, with no patient or member details. Exception today: referrals an AI vendor sends through OpenAdapt pass through it.
- OpenAdapt staffTest records onlyBuild and fix programs on test patients or test members, or on copies you approve.
This page prints cleanly for your review. The one exception to the map today: referrals that a healthcare AI vendor sends through OpenAdapt pass through OpenAdapt Cloud on their way to the clinic computer. A path that avoids it isn't built yet.
Runs on your computer
Normal runs happen on a computer or virtual machine you control. It types in a signed-in session, the way your staff do, and your system's audit log shows that session. It keeps the full run record: values typed and read back, screenshots, and who approved. OpenAdapt doesn't encrypt the run record for you; use the computer's full-disk encryption. Programs can be stored encrypted if you turn that on.
An entry that was done and checked gets a signed receipt (the result and each check it ran). It holds no patient or member details, names, typed values or screenshots, so it can be shared.
For a locked-down network, the engine has a strict no-outbound mode and can run as an unattended service on your own server.
Hosting
OpenAdapt Cloud holds accounts, approved program versions, run status and receipts. Its providers are Netlify, Supabase and, for browser-only hosted work without patient data, Modal; Stripe handles billing. The website also uses Cal.com for booking, and PostHog, Google Analytics and Meta for site analytics; the privacy notice lists them. We state the hosting region in writing before a pilot. A Canadian hosting option is planned.
Hosted runs aren't for patient data. We have no BAA with Modal, the provider that runs them, so hosted runs aren't HIPAA-eligible. Workflows with patient or member data (PHI) run on your own computers.
Agreements and certifications
- BAA or PHIPA agreement: we sign one, from our template, before we record anything on real data.
- SOC 2: not held.
- Penetration test: none published yet.
- Testing: the readiness test runs on test records or a test copy. Nothing is written to real records until you approve go-live in writing.
Answers for your IT and privacy review
What gets installed?
The open-source engine, installed with your IT team, with permission to control the keyboard and mouse. The desktop app is in beta and ships as a Python package; there are no signed installers yet.
Has it run on our EMR or claims system?
We qualify each workflow on your own system, against your normal and fault cases, before it touches a real record. The runs this site shows used synthetic records on open-source systems or our own test apps.
What extra access does the record check need?
A second, read-only way into your system: a report export, read-only API access or a database role. We ask for the narrowest access your system offers.
Does an AI model see our screens?
No AI model was called in the OpenEMR, openIMIS and remote-desktop test runs this site shows. Proposing a fix after a screen changes can use a model; whether it does in your deployment is set in writing in your proposal.
Is the demonstration recorded on a real patient?
We make it on a test patient, a test member or a test copy of your system wherever we can. We sign a BAA or PHIPA agreement before we record anything on real data.
Does screen automation break our vendor or portal contract?
It uses your system the way your staff do, in their own session. Two carrier-portal terms we read forbid letting anyone else use your login and list web robots as prohibited. We review your contract and portal terms with you before we build.
Questions insurers ask
| Topic | Our answer today |
|---|---|
| State data-security laws (NAIC Model #668) and NYDFS Part 500 | Normal runs happen on your computer; Cloud receives results and receipts. No SOC 2 report; we answer your vendor questionnaire directly. |
| Privacy of financial and health information (GLBA, state privacy rules) | Local runs keep member details on your computer. |
| HIPAA, for health plans and TPAs | A business associate agreement, signed before any work on real data. |
| AI use by insurers (NAIC AI bulletin; OSFI E-23 in Canada) | No AI model decides anything about a member. In our recorded runs the program made 0 model calls, and by default each save waits for approval. |
| Third-party risk (OSFI B-10) | The engine is MIT-licensed and runs locally; you keep the programs and run records if you stop. |
| Carrier-portal terms | We read each portal's terms with you and prefer carrier APIs and downloads where they exist. |
| Errors and omissions | It checks against the record where it can, stops when it can't tell, and by default each save waits for approval. Liability terms are set in your pilot agreement. |
What it's designed not to do
- Retry a save it couldn't confirm.
- Type into a record that doesn't match, on the steps that carry identity.
- Save an entry before a person approves it, unless your team has switched a workflow that passed its readiness test to ask only about problems.
Getting data into an EMR without a usable API? See our guide.
Sources
- NAIC Insurance Data Security Model Law (#668): adopted in 28 jurisdictions as of 8 Oct 2026 (NAIC adoption map). NAIC Model Bulletin on the use of AI by insurers: adopted in 29 jurisdictions as of 8 Oct 2026.
- New York 23 NYCRR Part 500, section 500.11: third-party service provider security policy.
- OSFI Guideline B-10, third-party risk management, in force 1 May 2024; Guideline E-23, model risk management, in force 1 May 2027.
- US HHS guidance: third-party administrators of group health plans are generally business associates under HIPAA.
See it on your process
Bring one task your team types every day. We'll tell you whether it fits, and what a test on your own system would cover.