AI& PILOT PROTOCOL DOC

2–4 Week Controlled Pilot for a Physician-Controlled Clinical Assistance System

Version 0.1

• March 2026

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?

The pilot has four primary objectives:

Evaluate whether AI& reduces time spent on repetitive documentation and communication drafting.

Evaluate whether AI& improves consistency, clarity, and structure of outputs.

Evaluate whether AI& can operate without introducing unacceptable risk, misleading outputs, privacy concerns, or workflow disruption.

Evaluate whether participating physicians find AI& useful, acceptable, and worth continuing after the pilot.

Recommended duration:

• minimum: 2 weeks

• ideal: 3 to 4 weeks

This duration is long enough to observe patterns, but short enough to remain controlled and easy to review.

The pilot must remain narrow and highly controlled.

Choose only 1 to 2 use cases for the pilot.

Preferred options:

1. SOAP note draft generation

2. Structured visit summary drafting

3. Patient education draft generation

4. Follow-up reminder drafting

The pilot must not include:

• autonomous diagnosis

• autonomous triage

• medication recommendation

• emergency guidance

Recommended:

• 1 primary physician

• optional: 1 to 3 additional physicians after initial validation

May include:

• project coordinator

• technical support person

• compliance or quality reviewer

• note-taker for feedback sessions

Patients are not system operators in this pilot.

If patient-linked data is involved, all handling must follow the defined data governance rules.

The pilot may begin only if the following conditions are met:

One or two pilot tasks are selected clearly.

All participants understand:

• when AI& may be used

• who reviews outputs

• what happens if outputs are poor

• what is logged

All participants agree that:

• physicians remain the final decision-makers

• no AI output is final without physician review

• no autonomous patient communication is allowed

At least basic templates exist for the selected use cases.

The team can record:

• AI usage events

• review outcomes

• corrections

• incidents

A participating physician identifies a case appropriate for pilot use.

Examples:

• routine documentation case

• follow-up case

• patient education need

• non-emergency outpatient interaction

The physician provides structured input into AI&.

Possible inputs:

• chief complaint

• relevant history

• findings

• assessment points

AI& generates a draft according to the selected workflow.

Examples:

• SOAP note draft

• education message draft

• follow-up summary draft

The physician must review the draft before any use.

The physician may:

• approve

• edit

• reject

• regenerate

Only physician-approved output may be used in real workflow.

The system or team records:

• type of task

• time used

• degree of correction needed

• whether output was useful

The pilot should begin with cases that are relatively stable and low-risk.

• routine follow-up visits

• straightforward documentation tasks

• patient education messages for familiar conditions

• structured note conversion tasks

• emergencies

• highly ambiguous complex cases

• medico-legal conflict situations

• emotionally sensitive or crisis communication

The pilot should begin in calm water, not in the storm.

The pilot must define clear review rules.

Every AI-generated output must be reviewed by the responsible physician before use.

The physician must check:

• factual alignment with the encounter

• clarity of wording

• completeness

• safety of advice or explanation

If the output is misleading, incomplete, or confusing, it must not be used.

If the output raises a safety concern, the incident must be logged and reviewed.

The pilot should collect both quantitative and qualitative data.

For each AI-assisted case, record:

• date

• physician name or identifier

• use case type

• draft generation time

Record:

• physician comments

• moments of trust or distrust

• unclear phrasing

• missing information

Record separately:

• misleading clinical wording

• privacy concern

• wrong context carryover

• source issue in evidence summary

The pilot should define success before it begins.

• average time saved per task

• reduction in repetitive writing effort

• faster preparation of communication drafts

• physician rating of clarity

• physician rating of usefulness

• consistency of structure

• completeness of documentation draft

• number of rejected outputs

• number of significant corrections

• number of incidents or near-misses

• number of privacy concerns

• percentage of eligible cases where AI& was used

• repeat voluntary use by physicians

• willingness to continue after pilot

A lightweight scoring framework may be used after each AI-assisted case.

Physician rates:

1. usefulness

2. clarity

3. time saved

4. trustworthiness

Optional note:

• “Would I use this again for a similar case?”

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

Review:

• patterns in editing

• trust levels

• repeated weaknesses

• safety observations

Review:

• whether to continue

• whether to revise scope

• whether to add one additional use case

• whether technical deeper build should proceed

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

The goal of the pilot is not to force success. The goal is to learn safely.

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.

At the end of the pilot, the team should produce:

A short narrative of what was tested.

A simple report of:

• number of cases

• use case types

• efficiency observations

• quality observations

A record of what should be improved.

A final recommendation:

• Go forward to next phase

• Revise and repeat pilot

• Stop due to risk or lack of value

• choose use case

• define workflow

• finalize review rules

• prepare templates

• first 5 to 10 cases

• close observation

• collect correction patterns

• revise templates

• refine prompts

• improve review process

• continue with improved workflow

• observe stability

• track repeat behavior

• summarize findings

• assess trust, usefulness, and safety

• decide next step

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

• mock-up / UI-UX design

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.

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:

• Document 1 –

• Document 2 –

• Document 3 –

• Document 4 –

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 . Sharing the link is allowed. So, share the link, not the text. Do not discuss or re-tell the contents in any form—written, spoken, or recorded—without prior written permission.