Integrations
Two connections make this platform work for your practice: your clearinghouse, so authorizations can reach payers under your own trading relationship, and your practice systems, so we can see the work and write the answer back.
#You write no code
Neither connection is a development project. You enable our application in systems you already own, create a service account for it, and paste a handful of values into Settings → Connections. We do the calling; nothing is ever pushed to us.
#The credentials stay yours
| What | Why it is yours and not ours |
|---|---|
| Clearinghouse entitlement | Your trading relationship with payers, your audit trail at the payer, and revoking it needs nothing from us. |
| EHR service account | Your patient record. You decide what our application may see, and you can disable it in your own console without asking us. |
| Write permission | Held separately from read. Connecting is not consent to write into your chart, and we refuse chart writes until you turn that on deliberately. |
#What happens to a value you paste in
- It is validated before it is storedWe authenticate against the vendor with exactly the values you gave. If they are wrong, nothing is stored at all, and you are told which part failed. A wrong credential that is stored anyway fails later, at a real authorization, in front of a patient appointment.
- Secrets are encrypted and never shown againPasswords and client secrets go to a managed secret store. They are never returned by any screen, never written to a log, and never included in an audit record. You see a short fingerprint instead, so you can match it against your own vendor console without either of us handling the value.
- Non-secret values stay readableEndpoints, client ids and application names are shown in full, because you have to be able to check your own setup.
- Revoking is immediate and completeA revoked connection stops being handed out before the store is even read. It is not merely marked revoked while still working.
#Your data does not mix with anyone else's
Each practice's connection is resolved from that practice's own record at the moment of every vendor call. A practice with no connection gets no vendor access at all: the platform refuses rather than falling back to a shared credential. That refusal is deliberate, and there is a test that fails if a shared credential is ever reintroduced.
#After both are connected
- Scheduled procedures start appearing without anyone entering them.
- You can mint API keys for your own integrations. Those are gated on a working connection, so a key cannot be issued against a rail that does not function.
- Nothing reaches a payer and nothing reaches your chart without a named person releasing that exact action. Connecting does not change that, at any autonomy level.