Map your dental software stack: PMS, CRM, booking and reporting

Disclosure. This site is published by the company behind Dental Mastery, which sells marketing and enquiry services to dental practices. No software vendor has paid to appear here, and none is ranked.

Most practices did not design their software. They collected it: a practice management system chosen years ago, a booking widget added by a website supplier, a CRM bought with a marketing package, a reporting tool someone trialled. Each was sensible on its own. Together they often mean the same patient typed in three times, and nobody sure which record is right.

Why map before you buy

A one-page map of your systems answers three questions that every purchase depends on: which system is the master record for each kind of data, which systems need to talk to each other, and who can see what. Without it, you are judging a new tool on its demonstration rather than on how it fits what you already run.

The six jobs software does in a practice

Think in jobs, not products. One product may do several of these, and some jobs may be done on paper.

1. Practice management system (PMS). The diary, patient records, clinical notes and charting, treatment plans, fees and payments, and NHS claims where relevant. This is the clinical and financial core.
2. Patient communication. Appointment reminders, recalls, confirmations and forms sent before a visit. Often built into the PMS, sometimes a separate service.
3. Online booking. Lets patients choose a slot without phoning. Some PMS vendors publish their own booking modules, for example Dentally Portal ^[4] and Software of Excellence's Online Booking for EXACT ^[6]. Others rely on a separate tool.
4. Marketing CRM. Tracks new-patient enquiries from first contact to booked consultation: who enquired, from which source, who called them back, and what happened. It handles people who are not yet patients, which a PMS is usually not built around.
5. Call tracking. Assigns phone numbers to marketing sources so that calls can be counted by where they came from, and often records whether each call was answered.
6. Reporting. Brings figures together: enquiries, bookings, attendance, treatment started, income and marketing cost. It may sit in the PMS, in the CRM, or in a separate dashboard.

Where patient data lives

Write down, for each system, what it holds. The distinction that matters most is between clinical records and contact or enquiry data.

The General Dental Council's standards say patient confidentiality covers everything learnt in a professional role, including personal details, medical history, what treatment patients are having and how much it costs ^[1]. The same standards say confidential information sent or stored electronically should be encrypted ^[1]. So "only marketing data" is not a free pass: a CRM note saying a named person is considering implants and was quoted a price is confidential patient information.

UK GDPR adds the principle of data minimisation: personal data must be adequate, relevant and limited to what is necessary for the purpose ^[2]. In practice, that means clinical records stay in the PMS, and other systems hold only what their job needs. A CRM needs a name, contact details, the enquiry source and the follow-up history. It does not need medical history or clinical notes.

Any supplier that holds personal data for you is processing it on your behalf. UK GDPR requires a written contract with each processor, setting out what is processed, why, for how long, and what happens to the data when the service ends ^[3].

How data should flow

A sound stack has one master record per kind of data, and flows in a clear direction:

• Enquiry to CRM. Website forms, tracked calls and social messages land in the CRM, with the source attached.
• CRM to PMS at booking. When an enquirer books, they become a patient in the PMS. From that point the PMS is the master record for that person's clinical and appointment data.
• PMS back to CRM, minimally. The CRM may need to know that the consultation was attended or that treatment started, so marketing can be judged on results. It does not need the treatment detail.
• Booking into the PMS diary. Online bookings should write into the real diary, not a copy someone re-enters.
• Everything to reporting, read only. Reporting tools read figures. They should not become a place where records are edited.

Vendors publish lists of integration partners. Dentally runs a partner marketplace ^[5] and Software of Excellence lists partners for EXACT ^[7]. A listing tells you an integration exists in some form. It does not tell you which fields move, in which direction, how quickly, or whether it works with your configuration. Treat every integration as a claim to test in a live demonstration with your own system. The CRM procurement questions set out how to run that test.

Drawing your own map

A sheet of A4 is enough. For each system, write:

• its name, what it costs, and when the contract renews;
• which of the six jobs it does;
• what personal data it holds, and whether any of it is clinical;
• who has a login, and at what permission level, including any outside agency;
• whether a data processing agreement is signed and filed;
• what it sends to or receives from other systems, and whether anyone has checked that it works.

Then draw arrows for every flow. Where an arrow is really a person copying data by hand, mark it. Those are the places where enquiries go missing and errors creep in, and they tell you what a new system would have to fix to be worth buying.

Questions before adding anything

• Which of the six jobs will it do, and is any current system already doing that job, or could it?
• Will it become the master record for anything? If so, what stops being the master?
• What is the smallest set of personal data it needs, and can you keep clinical records out of it?
• Which integrations does it depend on, and have you seen them working with your own system?
• Will the supplier sign a data processing agreement, and can you export everything if you leave?
• Who will own it day to day, and who will check that the data flowing through it is right?

Score each option against the same questions with the software requirements checklist. If one of the systems is a practice management system, the Dentally and EXACT evidence matrix shows what two vendors publish about their own products.

On the marketing side, this is the part of the stack I work on. At Dental Mastery, software compatibility is checked before an integration is proposed, and the enquiry capture and follow-up work starts from the systems a practice already runs.