Consider an illustrative example, not a client case. Someone sends an appointment enquiry through a practice website in the evening. The next morning they call, but the line is busy. Later they speak with reception and arrange a visit. The appointment is in the practice diary; the website enquiry is still in an inbox; the missed call has left no useful record. When the person arrives, a receptionist has to reconstruct what was asked and what was already said.

If this happens repeatedly, the issue is not simply how fast a chatbot replies. It is where information is recorded, who owns the next step and how the practice notices a request that has not been resolved.

What changes when you connect tools and processes

A chatbot is a conversational program. It can answer a question and collect information; what happens to that information depends on its configuration and its connections to other tools. An integrated project starts with a different set of questions: where is the request recorded, who reviews it, which updates may be automated, and what happens when a connection fails?

A CRM (customer relationship management system) holds contacts, enquiries and the status of follow-up. Practice management software runs the daily work: often the diary, patient records, services and billing. An integration allows information to move between authorised tools without someone copying it by hand. The technical connection alone does not resolve a missed enquiry. Reception still needs a shared process for checking and closing it.

AI may be one component of that process. It is not a reason to give a system unrestricted access or to remove human decisions from clinical work.

What OpenAI's announcement does, and does not, show

On 1 September 2026, OpenAI announced an Epic connection and a separate Healthcare Public Data plugin for ChatGPT for Healthcare. Its release notes describe Epic access as read-only and dependent on administrator configuration, each user's Epic access and existing permissions. OpenAI says the Epic connection is not currently available to individual users.

Healthcare Public Data is a different plugin. OpenAI also describes it for eligible individual ChatGPT for Clinicians users in the United States. It queries public sources, not patient charts (OpenAI announcement). Neither announcement establishes availability for an Italian practice, compatibility with its management software, an active Studio Bonanno capability, or a partnership between Studio Bonanno and OpenAI or Epic.

The useful lesson is more modest: identify the source, permission, purpose and limits of a connection before proposing it.

Six organisational uses worth examining

These are possible workflows, not a catalogue of features already active at Studio Bonanno. Each depends on the practice's tools, permissions and decisions. None covers diagnosis, clinical triage or treatment.

Answers and enquiries

Logistical questions. The problem: reception repeatedly answers questions about opening hours and access. The prerequisite is practice-approved information that someone keeps current. A system could suggest answers from those texts; a person reviews uncertain questions and corrects the source. The limit is firm: no answers about symptoms, test results or medication. This is a possible area for Claudia AI, discussed further in our virtual receptionist guide.

Collecting and assigning enquiries. Requests from a website, phone, messaging channel and email may sit in different places. A shared queue is a possible aim if the channels can be connected.

  • Prerequisite: a CRM, even a simple one, and assignment rules agreed with the practice.
  • Possible system step: record the enquiry and suggest an owner under those rules. Reception checks exceptions, decides and replies.
  • Limit: some channels may not expose the required information. Incorrect classifications must remain visible and correctable.

Support for appointment requests. Availability and requests may live in separate tools. This is only an option if the practice and its software provider allow the necessary access.

  • Prerequisite: authorised, documented and tested access to availability.
  • Possible system step: show available times or simply collect a preference, depending on the verified capability. Reception checks and confirms the appointment.
  • Limit: an enquiry is not a confirmed booking. If the diary cannot be accessed, the step stays manual.

Reminders and communications

Reminders and replies. A reply to a service reminder may arrive in a channel that reception is not watching. The prerequisites are accurate appointment and contact details, an available channel and a review of the conditions for that use of the data. A system might send a service reminder and collect the reply. Reception handles changes and ambiguous responses. Clinical follow-up remains with a healthcare professional. Promotional messages serve a different purpose and need a separate assessment; our guide to GoHighLevel and GDPR discusses the distinction.

The limit: a channel and the CRM may not exchange information. Do not assume a reply will update a record or that a message can be sent automatically. This example does not include clinical messages or patient campaigns.

Summaries and reporting

A reception handover summary. Open enquiries are not always visible in one place. The prerequisites are consistent statuses and authorised access. A system could compile an operational list; reception checks that it is complete and sets priorities. Missing or stale data makes the summary unreliable.

An aggregate report for the practice owner. Without a shared view it is hard to see which enquiries remain unresolved. First define what “received”, “in progress” and “closed” mean, and collect data for that purpose. A system could count requests by channel and status. A person checks anomalies and interprets the figures. The report alone does not prove an improvement and should not become a list of clinical details.

Where the chosen platform is GoHighLevel, our article on practice automations covers individual workflows. Here the question is how authorised tools and people work together.

Checks to make before starting

Information quality. A system that quotes outdated opening hours or assigns work to someone who has left can multiply mistakes. List what it is allowed to say and do, and decide who keeps that list current.

Permissions. Define who may see what, both inside the practice and at each supplier. Give a workflow only the access it needs. If it proposes appointment times, it does not need to read a clinical record.

Actual integration options. Practice management software may offer a documented, enabled API, usable periodic exports, or no permitted connection. These are examples, not an exhaustive menu. Ask the provider early. If no connection is available, some steps remain manual and the proposed project changes accordingly.

A named human owner. Every automation needs someone with time to inspect its queue and exceptions. An unreviewed queue can hide unanswered requests instead of resolving them.

Failure handling. A broken connection, a wrong classification or an unexpected reply needs a route to a person. Agree it before launch.

Data handling. An apparently administrative enquiry can reveal health information. Before connecting tools, define the purpose, necessary data, access, retention and security. The practice must establish suppliers' actual roles and any agreements required. The GDPR addresses health data, processors and, where the risk warrants it, impact assessments. The EDPB guidance on controller and processor roles calls for an assessment of the facts, not a role assigned by the title of a contract. Check whether the existing privacy notice describes the proposed processing.

The Italian Data Protection Authority's clarification of 7 March 2019 distinguishes processing necessary to provide healthcare from other uses such as promotion. It is a historical source, not a complete assessment for a new AI project. Service reminders, clinical follow-up and marketing must be assessed by their actual purpose and context. The practice and the relevant professionals need to evaluate the specific project; a supplier's contract or assertion alone is not proof that the processing is appropriate.

When an integration is the wrong first step

If no one has defined who does what and when, AI can add uncertainty. Unreliable source information can spread errors. If a simple rule-based assignment would solve the problem, assess that first: it may be easier to control than an AI component.

A realistic first step

Choose one narrow process, such as appointment enquiries from one channel. Agree how to measure the starting position: requests received, requests without an outcome and time to first handling. Without a comparable baseline, it is hard to judge change.

Test with synthetic data and one person responsible for review. Agree the duration, operational measures and criteria for continuing around the practice's actual tools; do not assume an improvement or a timetable. Our custom development page explains this staged approach.

To assess what can realistically connect in your practice, request a review of your current process and tools.

Frequently asked questions

Do we have to replace our practice management software?

Not necessarily. First check whether the current system allows a direct connection, permitted exports or neither. Replacing it is a separate project, with its own costs and risks, to decide for broader reasons.

Can AI make decisions about patients?

Within the scope described here, no. These proposed uses are organisational and do not make clinical decisions. Diagnosis, clinical priority and treatment stay with qualified professionals; people must know when and how to reach a person.

Does patient data go into AI models?

It depends on the project. To produce a response, an AI service may process information sent to a model even if the supplier does not use it to train that model. Processing and training are different questions. Before using real data, the practice must know what is transmitted, to whom, for what purpose, where it is handled, how long it remains available and whether the supplier uses it for training or other purposes. The first test uses synthetic data only. If these conditions cannot be made clear and checked, do not activate the workflow with patient data.