Documentation · compliance
Compliance tooling for controlled revenue-cycle workflows
Understand Cairnscript controls for evidence, reviewer decisions, release boundaries, and synthetic pilot readiness.
How Cairnscript handles patient data today
Cairnscript is currently in a synthetic-only pilot phase. Every clinical note, code suggestion, and claim shown in the demo or evidence ledger is generated from fictional, non-real patient records — no real patient health information (PHI) is ever entered into, stored by, or processed by the system today.
Before Cairnscript handles any real patient data, the following will be in place: a signed Business Associate Agreement (BAA) with each practice, documented HIPAA safeguards for data in transit and at rest, and a defined audit process for every point where PHI would enter the system. None of this is required for the current synthetic pilot — it becomes a prerequisite the moment real PHI is involved.
We're stating this plainly rather than implying a compliance posture we haven't yet built. If you have specific security or compliance questions before a live pilot, we're glad to answer them directly.
The control boundary
Compliance tooling makes it easier to inspect the controls around revenue-cycle work: evidence, policy checks, reviewer decisions, and release boundaries belong in the same conversation.
Recommendations stay review-only. External submission and network transmission are disabled in this layer, so a controlled pilot can establish what the system proves before any production action is considered.
01 / Review-only
A person closes the loop.
Every recommendation carries a human-review requirement and no automatic action or submission permission.
02 / Synthetic versus live
A fixture is not evidence.
Synthetic examples explain the workflow, but they never stand in for a tenant record, a claim, or a live operational result.