Abstract
When the power fails you can bring it back. A wrong clinical judgment stays with the patient. That is why keeping the system non-autonomous cannot live in an ethics statement. It has to be something a physician can check and stop inside the product itself. The Golden Clinical Loop is one turn of work: the AI proposes, the physician confirms, the work runs, and evidence that it finished is written down.
This document does not claim autonomous diagnosis, guaranteed accuracy, prevention of medical disputes, completed validation, regulatory clearance, or improved clinical outcomes. The product screens shown here are synthetic data from a demo account. They are not evidence of clinical validity or of results in the field.
- Document type
- Clinical safety principles
- Scope
- Clinical OS and the Golden Clinical Loop
- Author
- AetherHeal
Execution authority × clinical impact
Execution authority and clinical impact are classified apart
One axis separates what the system may read, what it may propose, and what it may change. The other separates how far a job reaches into clinical judgment. Crossing the two sets the controls a job needs.
01
Execution authority
- Read(A_READ)
- Reads only approved information and changes no state in a system of record.
- Propose(B_PROPOSE)
- Proposes a draft or a next action for review. It does not execute.
- Governed write(C_GOVERNED_WRITE)
- Changes state only behind a named person's approval gate and with an allowed tool.
Clinical impact
- Non-clinical operations(N_NONCLINICAL)
- Institutional operating work that does not bear directly on clinical judgment.
- Protocol-bound(P_PROTOCOL_BOUND)
- Handled only under an institution-approved protocol and a named clinical reviewer.
- Regulated or diagnostic impact(R_REGULATED_OR_DIAGNOSTIC)
- Kept apart as work that needs regulatory review, or the judgment of a licensed physician.
This classification exists to set the boundary between internal execution control and clinical impact. It is not automatically the same as a legal or regulatory classification.
Protocol-bound (P_PROTOCOL_BOUND)
Protocol-bound work needs an approved procedure and a human review
Work classified as protocol-bound enters the controlled scope only when all seven conditions below hold.
02
- 01
Institution-approved protocol
An institution-approved protocol is the reference.
- 02
Named clinical reviewer
A named clinical reviewer is assigned.
- 03
Version
The protocol version in force is identified.
- 04
Expiry
There is an expiry point at which the work is reviewed or stopped.
- 05
Rollback
A path back to the previously approved version stays open.
- 06
Controlled rollout
Rollout happens after the approved scope and the target institution are confirmed.
- 07
No automatic updates
A new version is never applied automatically.
AGENT RAIL / COMPILER
The compiler works only with approved tools and authority that already exists
Agent Rail / Compiler is not a publicly available product. It is a private prototype that checks tools, authority, and versions before an execution path is built.
03
- 01
No arbitrary code execution
It does not run arbitrary code.
- 02
Approved tool registry only
It references only the tools in the approved tool registry.
- 03
No new authority
Compiling never creates new authority.
- 04
Static checks
Structure and authority boundaries are checked statically before rollout.
- 05
Human review
A named person reviews the output.
- 06
Versioning and rollback
Every output is versioned, and a path back to the previous version stays open.
4
Scope and the responsibility boundary
Safety is not judged one answer at a time. What we review is the record that runs, in the patient's context, until the job is finished.
In clinical work the quality of a proposal does not explain safety on its own. We look at which inputs and which uncertainty the proposal came from, who reviewed it, and under whose authority it ran. We also look at what evidence of completion was left in the hospital's system of record.
Clinical OS holds patient identifier, evidence, authority, owner, and completion state together in one flow. The chart records what finished. We handle what has not finished yet. It does not replace the EMR.
Responsibility and owner
Responsibility is split into seven layers, each with a name on it
Clinical judgment, institutional protocol, system control, and rollout approval do not collect in one place. Each responsibility has a different owner.
05
Data boundary
Data use starts from the institution's boundary and a path to withdraw
Data is bound to its processing purpose, to the institution's boundary, and to a retention period. What we learn from corrections is kept apart from the boundary that forbids reusing source health information.
06
- 01
Per-institution boundary
Data and execution context stay inside each institution's boundary.
- 02
No cross-institution reuse of source health information
Source personal health information is never reused for another customer.
- 03
Stated processing purpose and processor role
The processing purpose and the processor role are written down.
- 04
Learning from corrections and workflow patterns
Only permitted corrections and de-identified workflow patterns are used for learning.
- 05
Consent and withdrawal
Consent status and withdrawal are recorded and applied to later processing.
- 06
Retention and deletion
Retention period, deletion conditions, and the deletion procedure are set together.
7
The problem-oriented medical record (POMR) draft and its implementation boundary
A medical record is what a later review uses to judge whether care was appropriate. A record draft exposes the structure of each problem and the gaps in it. Before it becomes the final record, a physician has to review it.
Clinical Copilot lays out the record draft in problem-oriented medical record (POMR) structure. For each problem it keeps the evidence, the assessment, the plan, and the gaps apart, so the physician can see what needs checking.
The entries we check were set from the medical dispute prevention guidelines of the Korean Medical Association's medical indemnity mutual aid association (대한의사협회의료배상공제조합).
- 01Problem-oriented medical record (POMR) structure, with evidence, assessment, and plan kept apart for each problem
- 02A check of the statutory entries: chief complaint, diagnosis, course, treatment, and date and time
We are reviewing the implementation scope for electronic signature and record-integrity safeguards against the electronic medical record requirements in Article 23 of the Medical Service Act [4].
A draft becomes a record only after a physician reviews and approves it. Fully meeting the legal electronic signature requirement, and the retention and integrity requirements for electronic medical records, is a separate implementation scope.
8
The stages of the Golden Clinical Loop and their boundaries
The Golden Clinical Loop is the one turn of work every product follows. Each stage has a condition that has to hold before the work moves on.
- 01Observe
- Source, time of observation, and uncertainty are preserved.
- 02Structure
- A statement is never promoted to a confirmed fact on its own.
- 03Propose
- A proposal is a scoped next action, or a point to review. Nothing more.
- 04Confirm
- Authority is granted explicitly and its scope is set. The default is off.
- 05Execute
- Only the approved scope runs, inside an allowlist and idempotency controls.
- 06Verify
- We do not take the system's word that something finished. We check the processing record or the state change in the hospital's system of record: booking, EMR, CRM.
- 07Record
- The execution record and any corrections are written down.
- 08Follow up
- Owner, due date, and the escalation path for exceptions are kept. Whatever is left carries into the next review and into the configuration.
10
Claim scope and the evidence it requires
Raising the level of a claim requires new evidence and a new review. Nothing we say about a product goes past the evidence we hold today.
11
The boundary of what we say in public
Public wording carries both the state of the product and the level of evidence behind it. The lists below separate what we can say today from what we do not say.
What we can say
- Physician-supervised clinical decision support
- Support for record completeness and risk management
- Support for reference, workflow, classification, and measurement
- An evidence generation plan and regulatory review
What we do not say
- The AI diagnoses a patient on its own
- Accuracy is guaranteed
- It prevents medical disputes
- Clinical validation or regulatory clearance is complete
- It improves clinical outcomes
- It replaces every EMR immediately
The external standards to read alongside this section are the WHO guidance on the ethics and governance of AI for health [1], the FDA guidance on clinical decision support software [2], and the IMDRF document on clinical evaluation of software as a medical device [3].
12
References
- World Health Organization. Ethics and governance of artificial intelligence for health: WHO guidance. View the document
- U.S. Food and Drug Administration. Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff. View the document
- International Medical Device Regulators Forum. Software as a Medical Device: Clinical Evaluation. View the document
- Republic of Korea. Medical Service Act, Article 23 (Electronic medical records). 의료법 제23조(전자의무기록). Korean Law Information Center.
Questions about the scope of this document or about its citations go to drjeeju@aetherheal.com.