This pilot is designed to test whether AI& can safely and practically support physicians in selected non-autonomous clinical assistance tasks.
2–4 Week Controlled Pilot for a Physician-Controlled Clinical Assistance System Version 0.1
1. Purpose of the Pilot This pilot is designed to test whether AI& can safely and practically support physicians in selected non-autonomous clinical assistance tasks.
The pilot does not aim to prove that AI can replace physicians.
The pilot aims to answer a simpler and more useful question:
Can AI& reduce documentation and communication friction while keeping physicians fully in control?
2. Pilot Objectives The pilot has four primary objectives:
2.1 Efficiency Evaluate whether AI& reduces time spent on repetitive documentation and communication drafting.
2.2 Quality Evaluate whether AI& improves consistency, clarity, and structure of outputs.
2.3 Safety Evaluate whether AI& can operate without introducing unacceptable risk, misleading outputs, privacy concerns, or workflow disruption.
2.4 Trust and Adoption Evaluate whether participating physicians find AI& useful, acceptable, and worth continuing after the pilot.
3. Pilot Duration Recommended duration:
This duration is long enough to observe patterns, but short enough to remain controlled and easy to review.
4. Pilot Scope The pilot must remain narrow and highly controlled.
Recommended First Use Cases Choose only 1 to 2 use cases for the pilot.
Preferred options:
SOAP note draft generation
Structured visit summary drafting
Patient education draft generation
Follow-up reminder drafting
Evidence summary for physician review
Not Included in the Pilot The pilot must not include:
medication recommendation
unsupervised patient messaging
direct patient-facing AI interaction
unrestricted sharing of patient-linked data across physicians
5. Pilot Participants 5.1 Physician Participants Recommended:
optional: 1 to 3 additional physicians after initial validation
5.2 Operational Participants May include:
compliance or quality reviewer
note-taker for feedback sessions
5.3 Patients Patients are not system operators in this pilot.
If patient-linked data is involved, all handling must follow the defined data governance rules.
6. Entry Criteria Before Pilot Starts The pilot may begin only if the following conditions are met:
6.1 Use Case Is Defined One or two pilot tasks are selected clearly.
6.2 Workflow Is Agreed All participants understand:
what happens if outputs are poor
6.3 Safety Boundaries Are Agreed All participants agree that:
physicians remain the final decision-makers
no AI output is final without physician review
no autonomous patient communication is allowed
6.4 Templates Are Ready At least basic templates exist for the selected use cases.
6.5 Logging Is Ready The team can record:
7. Pilot Workflow Step 1 – Select Eligible Case A participating physician identifies a case appropriate for pilot use.
Examples:
routine documentation case
non-emergency outpatient interaction
Step 2 – Enter Structured Input The physician provides structured input into AI&.
Possible inputs:
Step 3 – Generate Draft AI& generates a draft according to the selected workflow.
Examples:
Step 4 – Physician Review The physician must review the draft before any use.
The physician may:
Step 5 – Final Use Only physician-approved output may be used in real workflow.
Step 6 – Logging The system or team records:
degree of correction needed
whether output was useful
whether any issue occurred
8. Case Selection Rules The pilot should begin with cases that are relatively stable and low-risk.
Good Early Cases straightforward documentation tasks
patient education messages for familiar conditions
structured note conversion tasks
Poor Early Cases highly ambiguous complex cases
medico-legal conflict situations
emotionally sensitive or crisis communication
cases requiring urgent escalation
The pilot should begin in calm water, not in the storm.
9. Review Rules The pilot must define clear review rules.
Mandatory Review Rule Every AI-generated output must be reviewed by the responsible physician before use.
Minimum Review Actions The physician must check:
factual alignment with the encounter
safety of advice or explanation
Rejection Rule If the output is misleading, incomplete, or confusing, it must not be used.
Escalation Rule If the output raises a safety concern, the incident must be logged and reviewed.
10. Logging Requirements The pilot should collect both quantitative and qualitative data.
10.1 Quantitative Log For each AI-assisted case, record:
physician name or identifier
whether output was approved, edited, or rejected
approximate level of correction required
whether output was ultimately used
10.2 Qualitative Log Record:
moments of trust or distrust
10.3 Incident Log Record separately:
misleading clinical wording
source issue in evidence summary
unauthorized access concern
output that could have caused a near-miss
11. Success Metrics The pilot should define success before it begins.
11.1 Efficiency Metrics average time saved per task
reduction in repetitive writing effort
faster preparation of communication drafts
11.2 Quality Metrics physician rating of clarity
physician rating of usefulness
completeness of documentation draft
11.3 Safety Metrics number of rejected outputs
number of significant corrections
number of incidents or near-misses
number of privacy concerns
11.4 Adoption Metrics percentage of eligible cases where AI& was used
repeat voluntary use by physicians
willingness to continue after pilot
12. Simple Scoring Framework A lightweight scoring framework may be used after each AI-assisted case.
Per Case Score (1–5) Physician rates:
Optional note:
“Would I use this again for a similar case?”
13. Weekly Review Structure End of Week 1 Review:
whether the chosen use case was correct
whether outputs are generally usable
whether templates need adjustment
whether workflow is too heavy or too light
End of Week 2 Review:
End of Week 3–4 Review:
whether to add one additional use case
whether technical deeper build should proceed
14. Stop / Pause Criteria The pilot must pause immediately if any of the following occurs:
repeated misleading outputs
privacy or confidentiality breach
unauthorized access issue
physician cannot review efficiently
workflow becomes more burdensome than manual work
team confidence drops due to unresolved safety concern
The goal of the pilot is not to force success.
The goal is to learn safely.
15. Fallback Workflow At any point, the physician must be able to continue manually.
Fallback rule:
If AI& is unavailable, poor, uncertain, or unsafe, normal physician workflow continues without dependence on AI&.
No clinical process should become blocked because AI& failed.
16. Pilot Deliverables At the end of the pilot, the team should produce:
16.1 Pilot Summary A short narrative of what was tested.
16.2 Metrics Summary A simple report of:
16.3 Template Revision Notes A record of what should be improved.
16.4 Go / Revise / Stop Recommendation A final recommendation:
Stop due to risk or lack of value
17. Suggested Pilot Timeline Week 0 – Preparation Week 1 – Controlled Initial Use collect correction patterns
Week 2 – Adjustment Week 3 – Broader Controlled Use continue with improved workflow
Week 4 – Evaluation assess trust, usefulness, and safety
18. Recommended First Decision After Pilot At the end of the pilot, the team should answer one central question:
Did AI& make physician work clearer and lighter without weakening safety, privacy, or control?
If the answer is yes, the team may proceed to:
technical architecture detail
security architecture detail
product requirement specification
If the answer is partially yes, the team should revise the pilot design and repeat.
If the answer is no, the project should pause and reconsider scope.
19. Final Principle The pilot is successful not when AI looks impressive,
but when physicians remain confident, careful, and more present with patients.
That is the standard.
P.S. Other documents related to this document:
P.S.S. Read this document freely for information and guidance. Do not redistribute or restate—no quotes, summaries, paraphrases, or derivatives—without prior written permission from Prof. NOTA