ASF Standards · Ambulatory · Standard 28

Standard 28 — Digital Care and Artificial Intelligence Systems for Care

7 criteria · 2 core · 5 standard-level · Version 1.0 · Aligned to ISQua EEA Principle 7, 6th Edition

Criteria in this standard

28.1 — Digital Systems Are Genuinely Evaluated Before Adoption
28.2 — Digital Care Never Disadvantages a Patient Who Cannot Use It
28.3 — Genuine Technical Support Is Available for Digital Systems
28.4 — AI Systems Are Introduced in Line With Law and Best-Practice Guidance
28.5 — AI Systems Are Genuinely Monitored for Unintended Consequences
28.6 — Staff Are Genuinely Consulted Before an AI System Is Introduced
28.7 — Accountability for AI-Assisted Care Is Explicitly Defined
28.8 — Patients Are Genuinely Informed When Their Care Involves AI

28.1

Digital Systems Are Genuinely Evaluated Before Adoption

Standard

Before adopting any new digital system — booking platform, patient portal, diagnostic-support tool — the clinic genuinely evaluates its cost, benefit, and compatibility with existing systems, not adopted on vendor assurance with no real internal evaluation.

In plain terms: Before the clinic signs up for a new digital tool, someone has actually checked it’s worth it and will genuinely work with what the clinic already has — not adopted because a sales rep made it sound good.

Facility category	Crisis	Transition	Small	Standard
Applicability	Adapted	Full	Full	Full

Why this matters

Ambulatory clinics are frequent targets for digital health vendors offering booking, portal, and clinical-support tools, often with compelling pitches and limited internal IT capacity to independently evaluate them. A clinic that adopts tools based on enthusiasm rather than genuine evaluation risks ending up with systems that don’t actually integrate with its patient records, create workflow friction rather than relief, or introduce risks nobody considered before go-live.

What good looks like

A genuine cost/benefit evaluation happens before adoption.
Compatibility with existing systems is genuinely checked.
Potential unintended consequences are genuinely considered before go-live.

Common failure modes

A system is adopted purely on a vendor demonstration with no independent check.
Compatibility problems surface only after the system is already live.
Unintended consequences are discovered only in hindsight.

Worked example

In practice

A clinic considering a new online booking platform.

BeforeA booking platform vendor offered a free trial month, and the clinic manager signed up directly with no check of whether it would actually sync with the existing patient record system.

ActionA simple evaluation was retroactively conducted during the trial, confirming genuine sync compatibility and identifying one real risk — missed appointment notifications for patients without email — which was addressed with an SMS fallback before full adoption.

AfterThe Monitor reviewed the evaluation notes and the documented SMS-fallback decision. Verified.

If you are starting from zero — do this first

Build a simple one-page evaluation checklist for cost, benefit, and compatibility.
Require it before any new digital system is adopted, even during a trial.
Specifically ask what could go wrong before going live.

The most common mistake: Starting a vendor’s free trial without any real evaluation, then treating the trial’s continuation as the de facto adoption decision.

Self-assessment questions

1. Is a genuine cost/benefit evaluation conducted before adopting a new digital system? — A real, documented evaluation, not a decision made purely on a sales presentation.
Evidence: Evaluation checklist

2. Is compatibility with existing clinic systems genuinely checked before adoption? — Real, verified compatibility, not an assumption.
Evidence: Compatibility check record

3. Are potential unintended consequences genuinely considered before go-live? — Real, proactive consideration, not effects discovered only in hindsight.
Evidence: Pre-launch risk review

Common reasons for a PARTIAL answer

A free trial is treated as low-stakes and skips the evaluation entirely. — A trial that leads to continued use should still be evaluated before genuine adoption.

Implementation plan

When	What
Week 1	Build a simple evaluation checklist.
Ongoing	Apply it before any new digital system, including trials.

How the Monitor verifies this

Method	What	Detail
DOCUMENT	Evaluation review	Reviews the evaluation record for a recently adopted digital system.

Supervisor tips

Ask about the most recently adopted digital tool, trial or otherwise.

Evidence base

World Health Organization. Global Strategy on Digital Health 2020-2025. Geneva: WHO; 2021.

ASF training courses on GMJ Academy →

Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.

28.2

Digital Care Never Disadvantages a Patient Who Cannot Use It

Core

A genuine process ensures that patients who cannot use digital devices, lack internet access, or are otherwise unable to engage digitally are never disadvantaged in booking, communication, or care delivery — not digital convenience for most patients purchased at the cost of real access for the patients least able to adapt.

In plain terms: A patient who can’t use the online booking system or doesn’t have internet still gets exactly the same real access to the clinic — a working alternative, not a quietly worse option.

Facility category	Crisis	Transition	Small	Standard
Applicability	Adapted	Full	Full	Full

Why this matters

Ambulatory clinics increasingly rely on digital booking and patient portals for efficiency, but the patients most likely to need outpatient care — older adults, those in lower-income circumstances, people with disabilities affecting digital use — are frequently the same patients least able to navigate a digital-only pathway. This is marked Core because the risk here is a real, direct equity failure: a clinic’s digital modernisation can quietly reduce access for exactly the patients who need it protected.

What good looks like

A genuine, equally functional alternative exists for patients who cannot use digital channels.
New digital services are genuinely pre-tested with affected patient representatives.
Real evidence shows the alternative delivers equivalent, undiminished service.

Common failure modes

Phone booking exists nominally but is deprioritised in practice, with long waits.
A new digital service launches with no testing among patients who might struggle.
The alternative is never actually tested to confirm it’s genuinely equivalent.

Worked example

In practice

A clinic that moved primarily to online appointment booking.

BeforeOnline booking was promoted as the primary channel, and the phone line, while technically still available, was staffed by whoever happened to be free, resulting in long, inconsistent wait times for patients who called instead.

ActionA specific staff member was assigned phone-booking coverage during peak hours, with wait times tracked to confirm genuine parity with the online booking experience.

AfterThe Monitor called the booking line directly during business hours and reached a person within three minutes. Verified.

If you are starting from zero — do this first

Test your own non-digital booking channel directly, as a patient would.
Assign clear staffing responsibility for the alternative channel.
Track wait times to confirm genuine, ongoing parity.

The most common mistake: Leaving a non-digital channel technically available but under-resourced, so it quietly becomes a second-class option in practice.

Self-assessment questions

1. Is there a genuine, equally functional alternative for patients who cannot use a digital channel? — A real, equivalent alternative, not a digital-only pathway with no real fallback.
Evidence: Documented alternative channel

2. Was a new digital service genuinely pre-tested with representatives of patients who might struggle with it? — Real, prior testing, not an assumption accessibility will work out.
Evidence: Pre-launch testing record

3. Is there real evidence a patient using the alternative route received equivalent service? — A real, demonstrated instance, not an untested theoretical alternative.
Evidence: Direct test or comparison data

Common reasons for a PARTIAL answer

The alternative exists but is genuinely slower or less reliable than the digital route.

Implementation plan

When	What
Week 1	Test the non-digital channel directly and measure wait time.
Week 2	Assign clear staffing coverage for the alternative.

How the Monitor verifies this

Method	What	Detail
ASK	Direct test	Personally tests the non-digital alternative channel.

Supervisor tips

Call the clinic’s own phone line during business hours to test it directly.

Evidence base

World Health Organization. Ethics and Governance of Artificial Intelligence for Health. Geneva: WHO; 2021.

ASF training courses on GMJ Academy →

Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.

28.3

Genuine Technical Support Is Available for Digital Systems

Standard

The clinic has genuine access to technical support — in-house, vendor-provided, or contracted — for its digital systems, with testing before full implementation, not systems left running with no real technical support behind them.

In plain terms: When a digital system breaks, there’s a real person to call for help — not a system left to run itself with nobody actually responsible for fixing it.

Facility category	Crisis	Transition	Small	Standard
Applicability	Adapted	Full	Full	Full

Why this matters

Most ambulatory clinics lack dedicated in-house IT staff, which makes a genuine, accessible vendor support arrangement especially important — without it, a digital system failure can bring booking, records, or communication to a halt with no real path to resolution. A clinic doesn’t need its own IT department to meet this intent; it needs a real, known, accessible support relationship for every digital system it genuinely depends on.

What good looks like

Genuine, accessible technical support exists for every digital system in use.
Testing genuinely occurs before full implementation.
A real, known escalation path exists for issues.

Common failure modes

No clear support arrangement exists for a system in daily clinical use.
Staff don’t know who to contact when something breaks.

Worked example

In practice

A clinic running a patient portal with no clear support contact.

BeforeThe portal had been set up during initial onboarding, but staff had never been told who to contact for technical issues, and a recent outage had been resolved only after several days of searching for the original vendor contact.

ActionA support contact card with the vendor’s number was posted at the front desk, and the vendor’s actual response-time commitment was confirmed and documented.

AfterThe Monitor asked a front-desk staff member who to call for a portal issue, and received a confident, correct answer. Verified.

If you are starting from zero — do this first

List every digital system in use and confirm a real support contact for each.
Post support contacts visibly for staff who use each system.

The most common mistake: Support contact information living only with whoever originally set up the system, with no documented, accessible record for others.

Self-assessment questions

1. Does the clinic have genuine, accessible technical support for its digital systems? — Real, available support, not a system left unsupported.
Evidence: Support contract or arrangement

2. Were genuine testing and quality checks performed before full implementation? — A real pre-launch check, not a system deployed untested.
Evidence: Pre-launch testing record

3. Is there a real, known route to support when an issue arises? — A genuine, known path, not staff left to troubleshoot alone.
Evidence: Staff interview, posted contact

Common reasons for a PARTIAL answer

Support knowledge depends on one staff member rather than a documented, shared record.

Implementation plan

When	What
Week 1	Document support contacts for every digital system in use.
Week 2	Post contacts visibly for staff who use each system.

How the Monitor verifies this

Method	What	Detail
ASK	Staff interview	Asks a staff member who they’d contact for a digital system issue.

Supervisor tips

Ask a front-desk staff member, not just the clinic manager.

Evidence base

NHS Digital. Technology Assessment Criteria for Digital Health Products. London: NHS Digital; 2022.

ASF training courses on GMJ Academy →

Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.

28.4

AI Systems Are Introduced in Line With Law and Best-Practice Guidance

Standard

Any artificial intelligence tool used to support diagnosis or triage in the clinic is introduced in accordance with applicable law, or where none exists, with available best-practice guidance such as WHO’s AI ethics and governance guidance — not adopted with no reference to any external standard of responsible use.

In plain terms: Before using an AI tool in patient care, the clinic has actually checked what the law requires, or grounded its approach in real published guidance if there’s no specific law — not made it up as it went along.

Facility category	Crisis	Transition	Small	Standard
Applicability	Adapted	Full	Full	Full

Why this matters

Smaller clinics adopting AI-assisted tools — increasingly common in areas like diagnostic imaging triage or symptom-checking — are just as subject to the responsibilities of genuine governance as larger facilities, even without dedicated compliance staff. A real, citable basis for how the clinic governs its AI tools, even a simple one, is what separates responsible adoption from an unexamined decision with no actual grounding.

What good looks like

AI systems are genuinely introduced in line with applicable law, where it exists.
Where no law exists, introduction is genuinely informed by recognized guidance.
The clinic can identify, when asked, the specific basis for AI governance.

Common failure modes

No reference to law or guidance was made before adopting an AI tool.
Nobody can say, when asked, what the governance basis actually is.

Worked example

In practice

A clinic using an AI-assisted skin lesion triage tool.

BeforeThe tool had been adopted on a dermatologist’s personal recommendation, with no check of applicable regulation or any formal reference to external guidance.

ActionA brief governance review confirmed no specific national AI medical device regulation yet applied, and formally adopted WHO’s AI ethics guidance as the clinic’s reference, documented in a one-page governance note.

AfterThe Monitor reviewed the governance note and confirmed the dermatologist could name the guidance basis directly. Verified.

If you are starting from zero — do this first

Check for applicable AI-specific regulation in your jurisdiction.
Where none exists, formally adopt a recognized guidance source as reference.
Document this basis in a simple, one-page note.

The most common mistake: Adopting an AI tool on clinical recommendation alone with no separate governance check.

Self-assessment questions

1. Is any AI system in clinical use genuinely introduced in line with applicable law? — Real, verified compliance, not an assumption.
Evidence: Regulatory check record

2. Where no law exists, is introduction genuinely informed by recognized guidance? — A real, referenced source, not an ad hoc decision.
Evidence: Documented guidance reference

3. Can the clinic identify, when asked, the specific basis for AI governance? — A real, specific answer, not a vague assurance.
Evidence: Staff interview

Common reasons for a PARTIAL answer

A guidance source is named but hasn’t actually been reviewed for its application here.

Implementation plan

When	What
Week 1	Research applicable AI regulation.
Week 2	Document a governance basis for each AI tool in use.

How the Monitor verifies this

Method	What	Detail
DOCUMENT	Governance note review	Reviews the documented governance basis for AI use.

Supervisor tips

Ask for the name of the specific guidance document, not a general assurance.

Evidence base

World Health Organization. Ethics and Governance of Artificial Intelligence for Health: Guidance on Large Multi-Modal Models. Geneva: WHO; 2024.

ASF training courses on GMJ Academy →

Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.

28.5

AI Systems Are Genuinely Monitored for Unintended Consequences

Standard

The clinic genuinely monitors any AI-assisted diagnostic or triage tool for over-diagnosis, missed diagnosis, and other unintended consequences — not deploying an AI tool and assuming it works as intended with no real, ongoing scrutiny.

In plain terms: The clinic actually keeps checking whether its AI tools are working as expected — not deploying a tool once and simply trusting it from then on.

Facility category	Crisis	Transition	Small	Standard
Applicability	Adapted	Full	Full	Full

Why this matters

A clinic using an AI triage or diagnostic-support tool is depending on it to behave consistently well — but AI systems can fail in ways that aren’t visible in any single encounter, and only genuine, ongoing review of its actual output against independent clinical judgment will catch a systematic pattern of error.

What good looks like

AI output is genuinely, periodically audited against independent review.
Patient concerns related to AI-assisted care are genuinely tracked.
A documented instance exists of monitoring catching a real issue.

Common failure modes

AI output is trusted with no ongoing audit of its real accuracy.
No monitoring process has ever actually caught an issue.

Worked example

In practice

A clinic using an AI tool to flag abnormal imaging results.

BeforeThe tool had operated for a year with no formal check of its accuracy against actual clinical outcomes.

ActionA simple quarterly audit was introduced, comparing a sample of flagged and unflagged results against independent radiologist review.

AfterThe Monitor reviewed the quarterly audit record showing genuine, independent comparison. Verified.

If you are starting from zero — do this first

Identify every AI tool currently influencing clinical decisions.
Establish a simple, periodic audit comparing output against independent review.

The most common mistake: Treating AI output as reliably correct by default, with no audit ever established to test that assumption.

Self-assessment questions

1. Is AI-assisted output genuinely audited for over-diagnosis or missed diagnosis? — Real, ongoing audit, not an assumption of reliability.
Evidence: Audit record

2. Are patient concerns related to AI-assisted care genuinely tracked? — A real, specific mechanism, not concerns absorbed into general feedback.
Evidence: Tracking log

3. Is there a documented instance of monitoring identifying a genuine issue, with a real response? — A real, concrete example, not a process that has never caught anything.
Evidence: Issue response record

Common reasons for a PARTIAL answer

Auditing happens but isn’t genuinely independent of the AI vendor itself.

Implementation plan

When	What
Week 1-2	Establish a periodic, independent audit process.

How the Monitor verifies this

Method	What	Detail
DOCUMENT	Audit review	Reviews the periodic AI audit record for genuine, independent comparison.

Supervisor tips

Ask whether the audit has ever actually found anything worth flagging.

Evidence base

US Food and Drug Administration. Artificial Intelligence and Machine Learning in Software as a Medical Device. Silver Spring: FDA; 2023.

ASF training courses on GMJ Academy →

Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.

28.6

Staff Are Genuinely Consulted Before an AI System Is Introduced

Standard

Clinical staff who will actually use a new AI tool are genuinely consulted before its introduction, with real training needs identified and addressed — not a tool rolled out to clinicians with no engagement beyond a brief notification.

In plain terms: Before a new AI tool goes live, the staff who will actually use it have had a real say — not just been told it’s coming.

Facility category	Crisis	Transition	Small	Standard
Applicability	Adapted	Full	Full	Full

Why this matters

In a small clinical team, staff experience is especially valuable because there’s no large IT department standing between the decision and the people actually using the tool day to day — their early, genuine input often catches practical friction that a vendor’s generic rollout plan misses entirely.

What good looks like

Staff are genuinely consulted before, not after, an AI system’s introduction.
Consultation genuinely identifies training needs, actually delivered.
Staff asked directly can describe genuine consultation.

Common failure modes

Staff learn about a new tool only once the decision is already final.

Worked example

In practice

A clinic introducing an AI-assisted documentation tool.

BeforePhysicians received an email announcing the tool’s launch the following week, with no real input sought beforehand.

ActionThe launch was delayed by two weeks to hold a genuine consultation session, identifying a specific workflow concern that was addressed before go-live.

AfterThe Monitor interviewed a physician who could describe the consultation and the resulting change. Verified.

If you are starting from zero — do this first

Hold a consultation session before finalizing any AI system decision.

The most common mistake: Treating a notification email as equivalent to genuine consultation.

Self-assessment questions

1. Are staff genuinely consulted before a new AI system’s introduction? — Real, prior consultation, not a rollout announcement.
Evidence: Consultation record

2. Does consultation genuinely identify training needs, actually addressed? — Real needs matched by real, delivered training.
Evidence: Training delivery record

3. Can staff describe having been genuinely consulted? — Tests whether consultation actually registered with staff.
Evidence: Staff interview

Common reasons for a PARTIAL answer

Consultation happened with one lead clinician but not the wider team.

Implementation plan

When	What
Before any launch	Hold genuine consultation with actual users.

How the Monitor verifies this

Method	What	Detail
ASK	Staff interview	Asks frontline staff whether they felt genuinely consulted.

Supervisor tips

Ask for a specific example of something changed because of staff input.

Evidence base

Topol EJ. High-Performance Medicine: The Convergence of Human and Artificial Intelligence. Nature Medicine. 2019;25(1):44-56.

ASF training courses on GMJ Academy →

Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.

28.7

Accountability for AI-Assisted Care Is Explicitly Defined

Core

The clinic has genuinely considered and documented accountability for care decisions made with AI support — who is responsible when an AI-assisted decision is wrong — not leaving this as an unexamined question until it actually matters.

In plain terms: Everyone knows, in advance, who is actually responsible if an AI-supported decision turns out to be wrong — not a question nobody has thought through.

Facility category	Crisis	Transition	Small	Standard
Applicability	Adapted	Full	Full	Full

Why this matters

This is marked Core for the same reason it is at any facility scale: without explicit accountability, a safety incident involving AI-assisted care risks becoming a confused dispute over responsibility exactly when clarity matters most — for the patient, the clinician, and the clinic’s own ability to learn from what happened.

What good looks like

Clinical accountability for AI-supported decisions is explicitly documented.
Clinicians genuinely understand their own accountability.
A defined process exists for reviewing accountability in an incident.

Common failure modes

Accountability has never been explicitly addressed.

Worked example

In practice

A clinic using an AI-assisted symptom triage tool.

BeforeStaff were unclear whether responsibility for a missed urgent referral sat with the triage nurse or was somehow shared with the AI tool itself.

ActionA clear policy was documented: the AI tool is decision support only, and the reviewing clinician retains full accountability, taught explicitly during onboarding.

AfterThe Monitor interviewed a triage nurse who could clearly state her own accountability. Verified.

If you are starting from zero — do this first

Explicitly document where clinical accountability sits for each AI-supported decision.

The most common mistake: Leaving accountability ambiguous, assuming it will become clear if ever actually tested by a real incident.

Self-assessment questions

1. Is clinical accountability for an AI-supported decision explicitly documented? — A real, clear answer, not an assumption.
Evidence: Documented accountability policy

2. Do clinicians genuinely understand their own accountability? — Real, demonstrated understanding.
Evidence: Staff interview

3. Is there a defined process for reviewing accountability in a safety incident? — A real, usable process, not a question left open.
Evidence: Incident review protocol

Common reasons for a PARTIAL answer

A policy exists but hasn’t been communicated to frontline staff.

Implementation plan

When	What
Week 1	Document explicit accountability for each AI tool in use.

How the Monitor verifies this

Method	What	Detail
ASK	Staff interview	Asks a clinician to describe their accountability when using an AI-supported tool.

Supervisor tips

Ask a clinician directly: if the AI flagged something wrong, who is responsible?

Evidence base

European Commission. Ethics Guidelines for Trustworthy Artificial Intelligence. Brussels: European Commission; 2019.

ASF training courses on GMJ Academy →

Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.

28.8

Patients Are Genuinely Informed When Their Care Involves AI

Standard

A patient whose care involves an aspect delivered with AI system support is genuinely informed of this — not left to assume every decision was made by a human clinician alone, with disclosure treated as optional rather than a genuine, standard part of informed care.

In plain terms: If AI is actually involved in part of a patient’s care, they’re genuinely told — not left to assume a human made every decision alone.

Facility category	Crisis	Transition	Small	Standard
Applicability	Adapted	Full	Full	Full

Why this matters

A patient’s genuine right to understand their own care includes knowing, in plain terms, when a decision affecting them was shaped by an AI system rather than a clinician’s judgement alone. This isn’t a formality — a patient who genuinely knows AI was involved can ask informed questions, seek a second opinion with that context, or simply understand their care more completely. Disclosure buried in a general consent form a patient never actually reads does not meet this bar.

What good looks like

Patients are genuinely informed when AI is involved in their care.
Disclosure is genuinely understandable, in plain language.
A patient can genuinely confirm they were told.

Common failure modes

AI disclosure is buried in a general consent form, technically present but never genuinely read or understood.

Worked example

In practice

A clinic using an AI-assisted triage tool at intake.

BeforeAI’s role was mentioned only in a lengthy general consent document, which patients signed without genuine awareness that an AI tool had actually been involved in their specific visit.

ActionA brief, plain-language note was added at check-in: “An AI-assisted tool helped prioritise your visit; your clinician reviews every recommendation.”

AfterThe Monitor interviewed a patient who could genuinely confirm they understood AI had been involved. Verified.

If you are starting from zero — do this first

Add a brief, plain-language disclosure point at the moment care decisions involving AI are actually discussed with the patient.

The most common mistake: Treating a line buried in a general consent form as genuine disclosure, when the patient never actually registers it.

Self-assessment questions

1. Is a patient genuinely informed when AI is involved in their care? — Real, standard disclosure.
Evidence: Disclosure protocol

2. Is this disclosure genuinely understandable, not buried in technical language? — A real, plain-language explanation.
Evidence: Disclosure wording sample

3. Can a patient asked directly confirm they were genuinely told? — A real, concrete confirmation.
Evidence: Patient interview

Common reasons for a PARTIAL answer

Disclosure exists in a consent form but patients genuinely cannot recall or explain it when asked directly.

Implementation plan

When	What
Week 1-2	Draft plain-language disclosure wording for each AI-assisted care point and train staff to deliver it.

How the Monitor verifies this

Method	What	Detail
ASK	Patient interview	Asks a patient whether they were genuinely told AI was involved in their care.

Supervisor tips

Ask a patient directly rather than relying on the consent form’s existence alone.

Evidence base

World Health Organization. Ethics and Governance of Artificial Intelligence for Health: Guidance on Large Multi-Modal Models. Geneva: WHO; 2024.

ASF training courses on GMJ Academy →

Foundation courses A-00 to A-03 are live. Criterion-specific modules are being developed and will link here when published.

← Ambulatory Standards — all standards
Self-assess against these criteria →
← Standard 27 — Sustainable Care
Standard 29 — Supporting the Care Workforce →