Level 4 taught you to govern AI across a dental practice, a group or a support organisation. Level 5 builds the part that acts. An assistant suggests; an automation does. It texts a patient, requests a form, verifies benefits, assembles a claim or places a call, and when it is wrong the error has reached a patient, a payer or the practice-management system before anyone looks at it. This level is written for practice IT and systems leads, practice-management and imaging system administrators, group operations staff, revenue-cycle and patient-access leaders, security officials, and the staff who own automation projects. It is architectural rather than technical, and needs no programming background.
Modules one to three set authority and orchestrate patient-facing work. Module one places every proposed automation at one of three levels — suggest, act inside the practice, or act outward only with a named person's approval — names the licensed and delegated acts a practice act keeps with a person, writes the permanent exclusion list, and bounds each automation in a written register before it touches a record. Module two treats first contact as one designed operation with named owners, timeouts and a dead-end path so nothing waits forever on a patient who never replies, applies minimum necessary to an automation that could otherwise read the whole database, and separates where a state disclosure duty actually bites from where a plain statement is good practice. Module three builds recall, reactivation and short-notice fill lists consent first: consent recorded per channel and purpose, revocation honoured within ten business days across text, voice and email, artificial-voice calls designed to the rules in force, and measurement that claims only what it measured.
Modules four to six cover data and the two integrations that matter most. Module four maps every system an automation touches — practice-management system, imaging system, clearinghouse, portal, phone, text and fax — separates the boundaries where a standard transaction and an adopted code set fix the format from those where the practice is free, and writes a data contract at each so the automation never guesses. Module five earns write access one action at a time: a read-only phase long enough to see what the automation would have done, a proposal queue a person works, then a narrow, logged, reversible write, with the clinical record first on the permanent no list. Module six is the integration that never graduates: an imaging-assist output may be surfaced to the dentist inside the dentist's own workflow and nowhere else, never written into the chart, the treatment plan, the claim narrative or a patient presentation, and never stated as a finding by an automation.
Modules seven to nine cover money, gates and identity. Module seven automates everything up to the approval point and nothing past it: assembling a claim from what the dentist documented, attaching the right patient's images, chasing and reconciling without deciding, and keeping ledgers, adjustments, refunds and payment instructions under separation of duties no automation may cross. Module eight designs gates that produce a decision rather than a click — the source beside the draft, one specific thing to check, an easy way to disagree, a role the state permits to decide, a volume a full schedule can absorb, and a measured change rate. Module nine gives every automation its own named identity, its own credentials and the narrowest access that lets it work, never a dentist's or a manager's login, with secrets held properly, vendor access bounded and an access review a small practice can run.
Modules ten to thirteen are control, defence and response. Module ten designs the stop, inventories the work caught in flight, writes and drills the manual route the front desk can still run, and handles the return: the backlog, the aged requests and the records requests that never waited. Module eleven threat-models the text nobody at the practice wrote — health histories, guardian messages, referral letters, payer replies, scanned mail — explains why a word list cannot close the gap, and builds defender-side controls that limit what a fooled run can reach. Module twelve specifies an action log someone can follow a year later, says what must never enter a log because a log of patient information is itself patient information, and finds the failures that raise no error. Module thirteen runs an automation failure as a runbook: the first-hour questions, the containment ladder, the analysis that chooses the notification path, a contact-rule failure and a suspected device problem handled through their own channels, and the review that changes the design.
Module fourteen closes on measurement and assembly: what the published work measured and what it did not, the baseline a practice takes before it builds anything, an honest ledger that counts rework, exceptions and reviewer time, and the implementation project a practice owner and a security official could each approve. No figure in the level is an expected result. The level ships with a printable workbook and eleven templates, the examination draws forty scenario questions from a reviewed bank, and the capstone is a Dental Automation Implementation project for a fictional practice.
Everything here is professional education. It is not clinical training, does not teach diagnosis, radiographic interpretation, prescribing, treatment planning or code selection, and is not legal, privacy, security or coverage advice. Completing the level earns an independent educational certificate issued by AI Coalition Network with a public verification page. It is not a dental or dental hygiene licence, a radiography permit, an expanded-function or coding credential, a security qualification or a compliance certification, it carries no professional education hours, and it satisfies no licensing, permit, registration or payer training requirement.