Easy to integrate with — and built to keep your data safe.
This page is for technical evaluators: how a connection is designed, exactly what crosses the wire, and how the privacy boundary is built. It is grounded in our audited security model. Where something is a design contract rather than shipped code, we say so and tag it Coming.
Connect through standards, on a seam you can turn on deliberately.
We integrate against open, free, standards-based surfaces first — and every connector that touches an external system is built to be switched on only when the conditions are met.
Real-seam OFF by default
Live todayConnectors (credential/NPI lookup, the assistant's language model, clearinghouse and EHR seams) are written so the real network call is gated behind an environment switch. The shipped default is synthetic/mock, so the whole system can be evaluated end-to-end with nothing live and no data at risk.
Tokenize at your boundary
ComingThe required integration design is that your side mints an HMAC-keyed token (a pseudonym) and de-identifies before transmission, so PHI never travels to our store. This is a contract in our production-PHI plan — it is the integration shape we build toward, not yet shipped code, so we mark it planned rather than claiming "we tokenize" today.
BAA-gated activation
GatedThe seam is opened only after a signed Business Associate Agreement, a verified boundary, and an explicit, out-of-band approval. There is no repo flag or self-serve toggle that flips a real-PHI path on.
Standards over bespoke
ComingWe build against FHIR R4 / US Core / SMART-on-FHIR for EHRs, ASC X12 (837P / 835 / 270-271 / 276-277 / 278) via clearinghouse seams for claims, and HRIS aggregators for workforce data — so one integration generalizes across many systems. These connectors are roadmap; the free reference anchors below are live.
Tokens and non-PHI identifiers — by design.
On a real connection, the architecture is built so only the following leave your environment for ours. The "never" rows are what the boundary is designed to keep out.
Provider-minted, HMAC-keyed tokens
Your side mints a pseudonym for the patient/record before transmission. We receive the token, not the record number.
Free, public, non-PHI identifiers
NPI (open NPPES registry), ICD-10 diagnosis codes, HCPCS codes, PECOS public enrollment data — all free, all non-PHI.
FHIR-standard, permissioned reads
Where an EHR is connected, standard FHIR R4 / US Core reads under SMART-on-FHIR OAuth2 — scoped to what your authorization allows.
Raw MRNs / account numbers / member IDs
An MRN or account number is itself a HIPAA identifier. The architecture requires it tokenized at your boundary before it ever leaves your systems.
Free-text PHI in logs or to the assistant
The audit trail records only metadata; the assistant answers only from synthetic, permission-filtered data and its output passes a mandatory redaction filter.
PHI-free by construction — and demonstrable.
The privacy model is not a policy document; it is built into the code and the test gate. Each control below can be demonstrated, and most can be shown failing closed.
Fail-closed PHI boundary
An input boundary in code refuses every PHI crossing. Even with all environment locks reading "true," its allowed state stays false and the crossing check throws. The first crossing is a deliberate, out-of-band approval — never a flag in the repository.
Mandatory output redaction
A redaction filter is the required last step on the assistant and résumé seams. It masks SSNs, emails, phones, labelled MRN/member/policy numbers, and secret shapes — and it fails closed (an error redacts rather than leaks). Honest note: this filter does not yet have its own dedicated unit test, so today its strongest single proof is source review. A targeted test is a planned hardening item.
Append-only, correlation-traced audit
Every consequential action writes to an append-only audit trail keyed by a per-request correlation ID. It stores allowlisted metadata only — timestamps, event, user, route, status, IP, correlation and source trace — never request bodies, emails, or tokens.
Synthetic, zero-PHI today
Every seed is synthetic; a policy scan blocks non-synthetic identifiers from entering the codebase. There is no real-PHI path to exploit because, by construction, one does not exist yet — it is gated behind the BAA and the boundary.
Server-enforced access control
Permissions are checked on every route by the server, not just hidden in the UI. Query-parameter token auth is rejected; tokens are short-lived with rotating refresh.
The assistant executes nothing
The grounded assistant answers from synthetic, permission-filtered data and names its source. It runs no code, and every response passes the redaction filter before display. Its language-model seam is off by default.
Every security claim maps to something you can inspect.
From our audited security review. We show the proof and the honest strength of each claim — including where a claim currently rests on source review rather than a test.
| Claim | Proof | Strength |
|---|---|---|
| PHI boundary is fail-closed | phiBoundary.js — status().allowed is hardcoded false even with all three env locks true; assertCrossingAllowed() always throws | Strong |
| Output redaction on every AI/seam response | outputGuard.js mask() redacts SSN/email/phone/MRN/member/policy + secret shapes; fail-closed | Medium — proof rests on source review (no dedicated unit test yet) |
| Audit trail carries no PHI or tokens | auditService.js — allowlisted fields only (ts/event/userId/route/status/ip/correlationId/sourceTrace) | Strong |
| Audit is append-only and request-correlated | Per-request correlationId via AsyncLocalStorage; JSONL with rotation; audit never crashes the request path | Strong |
| No PHI reaches the language model | Assistant grounds only on synthetic, permission-filtered data; output masked; LLM seam OFF by default (needs explicit env + key) | Strong |
| No secrets or PHI in committed code | Policy scan with a self-test (fails the build if a detector goes silent) | Strong |
| Role-based access enforced server-side | permissionGate → 401/403, audited; query-param token auth rejected | Strong |
Note: file names refer to our private product repository, shared with evaluators under a pilot — not a public package. CPT procedure codes are AMA-licensed and are not displayed in our public materials; ICD-10 and HCPCS are free to use.
Built on free, open anchors first.
Our integration roadmap starts where access is free, public, and PHI-free, then extends to gated systems through standards and partnerships.
Reference anchors
Live todayNPPES NPI (open, no key), ICD-10 and HCPCS code sets, and PECOS public enrollment data — the credential/NPI-first verification spine. No PHI, no gate. Note: an NPI proves identity, not licensure; state-board verification is a separate capability.
Claims / clearinghouse
ComingAn X12 EDI seam (837P claim, 835 ERA, 270/271 eligibility, 276/277 status, 278 prior auth) via a clearinghouse — Availity as the self-serve primary, Optum/Change as the richer gated option. Mock-lane until a trading-partner agreement and the PHI gate.
EHR & HRIS
ComingEHR reads via FHIR R4 / SMART-on-FHIR (vendor sandboxes self-serve; production per customer). Workforce data via HRIS aggregators (Finch / Merge) or a direct connector. Behavioral-health EHRs are partner-gated and pursued via partnership.
Want to evaluate the integration with your team?
A design-partner pilot proves one workflow end-to-end on synthetic data — and you can run the test suite yourself. Or get updates as connectors ship.