AI in medical practices: administrative workflows and clear boundaries

Appropriate scope depends on your specialty, practice software and organisation. This guide covers administrative workflows and proposed acceptance tests. It does not describe a clinically validated application or an already verified integration. Sources checked on 26 September 2026.

Select a frequent task with a recognisable completion point. A callback request can work when required fields, responsible staff and processing states are defined. A prescription request can be collected administratively; this does not issue a prescription. For a question about test results, the process can establish identity and route the enquiry without disclosing results in an open dialogue.

The table shows, for five common patient enquiries, what AI can support administratively and what remains the practice's responsibility.

The wording must preserve these distinctions. “Your request has reached the team” is different from “Your prescription is ready”. Write down permitted statements and test them with practice staff before release.

Administrative messages may contain symptoms or indications of urgency. A system must not flatten those details into an ordinary category or independently reassure the patient. Establish a clinically approved procedure for handling such messages, including clear channel limitations and appropriate contact routes.

Avoid promises such as “the assistant recognises every emergency”. Classification can fail; dialects, poor connections and incomplete descriptions add difficulty. The practice must decide whether the channel is suitable for its intended task and which professionally reviewed information appears at entry.

The KBV guidance on AI use stresses human responsibility and assessment of the application. Administrative support, clinical decision support and a medical device are different procurement questions. Its older implementation dates should also not be reused as the current AI Act timetable.

Do not ask only for the name of a supported practice management system. Require evidence for the version, module, interface and exact action: can it create a task, read a calendar, write an approved appointment type and return confirmation?

An email sent to the practice is not a confirmed record in its management system. A working calendar connection also does not establish correct handling of consultation duration, room availability, staff and other resources. Where those rules are not reliably represented, limit automation to requesting an appointment for later confirmation by the team.

Define the authoritative case. Intake, task and appointment may have different identifiers, but their relationship must remain traceable. Repeated messages and lost acknowledgements must not cause duplicate appointments or disappearing callback requests.

A fictional patient asks for a callback and also requests a repeat prescription. The assistant identifies two enquiries, records the agreed secure contact route and creates a case. It acknowledges receipt without promising a clinical decision or a callback time the practice has not authorised.

The destination saves the callback, but confirmation of the additional prescription request fails. The process must not report that everything is complete. Internally, it shows the actual state: callback created, prescription request unresolved. Staff first check whether the second request already exists before creating it again.

If the patient asks for an update, staff find the same case rather than collecting the story again. The responsible professional subsequently records the clinical handling. Administrative receipt and medical processing remain separate states throughout.

For Germany, the Data Protection Conference describes requirements for outsourced appointment management. These include limiting data to what the appointment requires, clear provider roles and an alternative booking route. This does not automatically justify exporting the entire patient database in advance.

Specify the fields needed for each task. A callback assistant does not inherently need the full clinical history. Reminders are also a separate communication step: establish the relevant permission, recipient, content and way to stop the service.

Keep calendar information, treatment documentation and technical logs distinct. Professionally required documentation may have different retention requirements from a temporary import failure. The deletion design must reflect those differences instead of retaining every copy indefinitely.

Austria and Germany

In Austria and Germany, assess the particular processing of health data, professional confidentiality and the actual provider chain. A generic supplier statement that a product is “GDPR compliant” does not replace the contract or review of the intended workflow. For Austria, consider in particular the confidentiality provisions in section 54 of the Medical Act.

German statutory medical practices

For German statutory medical practices, the KBV explains its IT security requirements. Do not treat them automatically as Austrian or Swiss practice rules. Involve the practice’s IT support and the requirements that apply to its particular setting.

Switzerland

For Switzerland, the FDPIC’s outsourcing guidance retains responsibility with the outsourcing controller and highlights confidentiality obligations and processing locations. A promise of a Swiss server therefore does not complete the assessment.

Accessibility. Not every patient can use a chat interface or follow a long recorded message. Keep a suitable alternative contact route available. Test slow input, hearing or visual impairments and requests from an authorised representative. Establish appropriate authority before disclosing personal information to someone acting for the patient.

Work queue. Staff need a usable work queue showing open requests, priority under approved practice rules, ownership and case age. A summary should reveal its source and uncertainty. Clinically relevant original wording must not disappear behind a short AI interpretation.

Cover. Cover arrangements must allow another person to take over during holidays, illness or system failure. Turning off the automated channel must not prevent processing requests already saved. A technical restart must not empty the outstanding work queue or reset its ownership.

Which cases should the practice test?

Use synthetic cases covering five situations from a practice day:

• an ordinary request
• two enquiries in one message
• another patient’s identifier
• an unintelligible recording
• failure after a successful save

Add clinically approved checks for handling indications of urgency; passing an individual example is not evidence of complete emergency recognition.

What should the practice measure?

Measure more than the number of contacts accepted. Four measures matter for an administrative AI workflow in a practice:

• correct delivery of cases
• avoidable follow-up questions
• missed tasks
• actual staff handling time

Include correction work before claiming a reduction in workload.

What should the release record state?

The release record for an administrative AI workflow should state four things:

• which task the application supports
• what it may tell patients
• which systems were tested
• who approves changes

This keeps the process understandable after a software update or a change in the practice team.

These pages continue the planning of administrative AI workflows in a medical practice:

• AI automation: tasks, selection and implementation
• AI automation for medical practices
• Medical-practice phone assistants: administrative limits
• Data protection across a document-processing workflow
• AI workflow approvals: who checks which action?
• EU AI Act for SMEs: duties, deadlines and practical review in 2026