The physician hard intercept.
The hard intercept is the design by which no AI-generated document with clinical content would leave the HarnessHealth system without a cryptographic physician signature. It is meant to be enforced at the API gateway. Today it runs in the sandbox only; it is not yet enforced in production.
Design specification.
All AI output is classified at generation time. Clinical content is defined as: direct patient recommendations, medication mentions, diagnosis or differential language, care plan content, and billing code assignments. Content meeting this threshold is tagged as requiring attestation. This step is live — try it below.
Tagged output is held in the attestation queue. It cannot be returned to the requesting application without an attestation token. The queue is persistent — documents are not dropped if the requesting application disconnects.
An attestation token is generated only when: a licensed physician with an active NPI and sufficient remaining authority budget has reviewed and approved the document. A physician with an expired or revoked license cannot generate valid tokens.
The token contains: physician NPI (fixed once signed), timestamp UTC (fixed once signed), document SHA-256 hash, review duration in seconds, authority consumption decrement. The token is signed with the platform private key and can be independently verified.
The requesting application receives the document plus the attestation token. The token is written to the audit trail and its hash is anchored on the public hashcare registry, which is what makes later alteration detectable. An administrator-proof log is designed, not yet enforced.
Paste (or use a sample of) AI-drafted output below. The server — not your browser — runs the same classifier described above and decides whether it is tagged clinical. Nothing you type here is stored. No PHI, please.
- General health information queries that do not meet the clinical content threshold
- Billing and administrative content that is not patient-directed
- Developer sandbox mode (attestation is simulated in sandbox; production mode requires live physician review)
- Steps 2–5 (queue hold, authority budget, token issuance, audit anchoring): the classifier above runs live, but it is not yet wired to a persistent queue in production — that gate needs a persistent queue in Google Cloud (Firestore) with its own credentials, and it is not yet wired. Still design, not enforcement.