Choosing and Running Practice Management Software

Practice management software is organised around the episode of care. The patient exists because there is a chart. The chart exists because there was, or will be, a clinical encounter. Every other record in the system hangs off that spine.

That is the correct design for a clinical system. It becomes a constraint the moment you start asking commercial questions.

Try three of them against your current system.

Which people enquired in the last ninety days and never booked. What has your practice said to a given patient in the last year that was not an appointment reminder or a recall. Which acquisition channel produced patients who are still attending three years later.

Most systems cannot answer any of the three. Not because the software is poor, but because a person who never booked has no chart, a conversation that was not an appointment has no encounter to attach to, and the channel someone came from is not clinical information.

The clinical record holds diagnosis, treatment, prescriptions, outcomes, correspondence and consent. It is organised by encounter. It is governed by retention rules and duty of care. Access to it is restricted by clinical role, correctly and by design.

The commercial record holds enquiries, conversations, complaints, stated preferences, how the person found you, what they were quoted, what they declined, who in their household also attends, who they referred, and why they stopped coming. It is organised by relationship over time rather than by encounter.

The same person appears in both. The two systems answer different questions, and neither is a substitute for the other.

Communication. Clinical and appointment communication is transactional. It is triggered by calendar state, it is templated, and it is effectively one-way. It tells someone that an appointment exists. Relationship communication is segmented, conversational, threaded across channels, and measured by response. A reminder system asked to run a reactivation campaign will send the same message to everyone on a list and record nothing about who replied.

Workflow. A clinical system routes work by encounter. A commercial system routes work by owner, stage and follow-up date. There is no natural home in a PMS for a task that says someone needs calling back on Thursday about a treatment plan they have not accepted.

Reporting. A clinical system counts activity. A commercial system counts conversion, retention and value over time.

Access. Front desk, marketing, patient experience and finance teams all need a view of the person. Very few of them should have a view of the chart.

Software evaluation focuses almost entirely on what a system can do. Demonstrations are built around workflows, screens and features. The question that determines what the system is worth to you in year four is a different one. What can you get back out, in what shape, how often, and who controls the tap.

This is rarely on the scoring matrix. It should be, because every analysis you will ever want to run, every integration you will ever want to build, and every migration you will ever be forced into depends on the answer.

"Do you have an API" is not the question. It is one of at least six different answers, and they are not interchangeable.

Manual export. Someone clicks a button and gets a CSV. Useful for one-off analysis. Useless as infrastructure, because it depends on a person remembering.

Scheduled bulk export. A nightly or hourly drop of full tables to a location you control. This is what you need if you intend to build any kind of reporting warehouse. It is the least glamorous capability and the most valuable.

Read API. Query specific records on demand. Good for integrations that need to look something up. Poor for analysis, because pulling three years of appointments one record at a time through a rate-limited endpoint is not practical.

Write API. Push data in. Separate permission, separate risk, frequently not offered even when read access is.

Webhooks and event streams. The system tells you when something happened. This is the only mechanism that gives you near-real-time reaction, and the only one that captures events rather than states.

Direct database or read replica access. Complete and fast. Rare, usually reserved for on-premise deployments or large accounts, and increasingly withdrawn as vendors move to cloud hosting.

Most organisations need at least three of these. Many buy a system that offers one.

Beyond the obvious patient demographics and appointment records, the list that matters includes financial transactions at line level, the communications log, recall and waiting list state, treatment plans including the ones not accepted, referral and acquisition source, user and rota data, document metadata, consent and opt-out state, and the audit log.

Two categories are almost always forgotten and almost always missed later.

Documents and images. These are commonly stored separately from the structured data, sometimes by a third party. An export of the database that does not include the files is a partial export. Ask specifically.

The audit log. Who did what and when. It is the only record of how your operation actually behaved, and it is the first thing excluded from a standard export.

Every report your practice management system produces rests on definitions that somebody at the vendor chose, probably years ago, for reasons that were never written down.

You will make hiring decisions, marketing decisions and capacity decisions on those numbers. They will go into board packs and lender conversations. Very few buyers ever ask what the numbers mean.

The question is not whether the reports are accurate. They usually are, against their own definitions. The question is whether their definitions match yours.

New patient. Is someone new when they first book, when they first attend, or when a chart is first created. A practice with a high first-appointment cancellation rate will see wildly different new patient numbers depending on which is used. If the definition is booking-based, your acquisition figures include people who never walked through the door.

Active patient. Seen in the last twelve months, eighteen, twenty-four. Some systems let you configure this. Some do not. Your patient base can shrink by a third on paper because a threshold changed.

Utilisation. The numerator is usually booked minutes. The denominator is the interesting part. Does it include unopened sessions, lunch breaks, admin time, annual leave, or the hours a room sat empty because nobody was rostered. Two systems can report 68 per cent and 91 per cent for the same clinic on the same day and both be internally correct.

No-show rate. Does a patient who cancels forty minutes before count as a cancellation or a failure to attend. Does an appointment that was rescheduled twice and then missed count once or three times.

Revenue. Recognised on the date of service, the date of invoice, or the date of payment. All three are legitimate. They produce different monthly trend lines, and the gap between them widens with the proportion of insurer work you do.

Industry benchmarks for utilisation, no-show rates and recall compliance circulate widely and are quoted with confidence. They are aggregated across organisations running different systems with different definitions. Treating them as directly comparable to your own numbers is a reasonable thing to want to do and a difficult thing to do correctly.

Every scheduling system encodes a theory of how care is delivered. The most common one is simple. An appointment is one patient, with one provider, in one time slot.

That theory holds for a single-handed practitioner in one room. It starts to break the moment anything else is true.

Consider a clinic where two treatment rooms share one specialist piece of equipment, an assistant is required for certain procedures but not others, a clinician supervises two chairs simultaneously, group sessions run on Thursdays, rooms need fifteen minutes of turnaround between certain appointment types, and one provider works across three sites on a rotating pattern.

None of that is exotic. All of it is difficult to represent in a system built on the simple theory.

The immediate cost is workflow friction. Staff invent workarounds. They create dummy provider columns to represent rooms. They block out time with fake appointments. They keep a paper sheet for equipment.

The durable cost is data. Anything the system cannot represent as a first-class object, it cannot report on.

Room utilisation is the classic example. If rooms are not modelled as bookable resources, you will never know your estate utilisation. You will know how busy your clinicians were, which is a different question, and you will make property decisions without the number that matters most.

The same applies to equipment, assistants, and any shared constraint. If it is not in the model, it is invisible in the analysis, and it will be invisible for as long as you run the system.

More configurability is not automatically better. A scheduling engine that can express anything will express a great many things inconsistently, because twelve receptionists will interpret it twelve ways. The useful question is whether the model can represent your actual operating constraints, not whether it can represent every conceivable one.

Appointment reminders are usually evaluated on a single criterion. Do they go out.

They do. Every system in the market sends them. The differences that matter are elsewhere, in a set of questions almost nobody asks during procurement, and they concern ownership rather than function.

Whose number does the message come from. Where does a reply go. Whose domain is the email sent from. Where is the record of what was sent. And who holds the list of people who have asked you to stop.

Patients reply to text messages. They reply to confirm, to ask a question, to cancel, and to tell you they have moved.

Many reminder services send from a shared pool number or an alphanumeric sender ID that cannot receive messages. The replies go nowhere. The patient believes they have cancelled. Your calendar still shows them booked, and you record a failure to attend against someone who did exactly what they were asked to do.

Where replies are received, the next question is where they land. A shared inbox that nobody owns is functionally the same as no inbox. Find out whether replies attach to the patient record, whether they generate a task, and who is responsible for clearing them.

If your appointment emails are sent from the vendor's domain, the sending reputation being built belongs to the vendor. It is shared with every other practice on the platform, and you cannot take it with you.

If they are sent from your domain, you need the authentication records configured correctly, and you inherit responsibility for the reputation. That is more work and considerably more control.

The same logic applies to SMS. A dedicated number that you own can be ported to another provider. A number allocated from a vendor pool cannot. If patients have saved that number in their phones over five years, that is a real asset sitting on somebody else's balance sheet.

There is a distinction between messaging that serves the appointment and messaging that serves the relationship. The first is triggered by calendar state, templated, and largely one-way. It is what a practice management system is built to do, and most do it well.

The second is segmented by behaviour, conversational, measured by response, and attributable to an outcome. Systems designed for the first are rarely capable of the second, and asking them to attempt it usually produces the worst of both.

The financial module in a practice management system is built to do three things well. Raise charges, take payments, and reconcile the ledger. Most do all three competently.

Attribution is a different discipline, and it is rarely designed for. Attribution is the ability to connect a pound of revenue to the thing that caused it.

Ask your system what revenue each provider generated last quarter. Then ask which appointment types were most profitable per hour of room time. Then ask what the average lifetime value is of a patient acquired through a particular channel.

The first question is usually answerable. The second sometimes. The third almost never.

Payments post at account level, not appointment level. A patient pays £340 against a balance built from three visits. Unless the system allocates that payment to specific charges, you can report cash received but not revenue per appointment or per provider.

Household and guarantor accounts confuse the subject. A parent pays for three children. Revenue attributed to the account holder rather than the person treated will distort every per-patient metric you run.

Insurer payments arrive late and in bulk. A single remittance covers ninety patients across four months and is posted as one transaction. Splitting it back out to the originating episodes is a specific capability. If the system does not do it, your revenue-by-month line and your activity-by-month line will never agree.

Discounts, write-offs and credits. These are frequently applied at account level with a free-text reason. That makes it impossible to analyse where margin is leaking.

Who gets the credit. An appointment booked by one clinician and delivered by another, or a plan prescribed by one and carried out over six visits by a second. The system attributes to whichever field it was designed around, and it is often not the one you would choose.

Revenue can be recognised on the date of service, the date of invoice, or the date of payment. Each is legitimate for different purposes. The gap between them is large in any practice with significant insurer or plan-based income.

What matters is knowing which basis a given report uses, and whether you can switch. A board pack that quietly mixes two bases across different reports is a common and difficult problem to spot.

Every patient database contains duplicates. This is not a failure of discipline. It is what happens when humans type names under time pressure, people marry and change surnames, children are booked under a parent's details, online booking creates a record before anyone checks, and a second site enters the same family independently.

A practice of any size will have between two and eight per cent duplication. Larger groups that have grown by acquisition run higher.

Duplicates are usually discussed as a tidiness problem. They are actually three separate problems, and only one of them is about tidiness.

The clinical problem is that a clinician may be looking at half a history. The commercial problem is that every per-patient metric you calculate is wrong by the duplication rate, in a direction you cannot easily determine. The structural problem is that if the identifier you use to join your PMS to anything else is unstable, every integration you build inherits the instability.

This is the part that gets missed.

At some point you will connect your practice management system to something else. A reporting warehouse, a customer platform, a patient app, a review tool. All of those connections depend on a key that reliably identifies the same person in both systems.

So the questions are: is the patient identifier permanent, is it exposed through the API and in exports, and what happens to it when two records are merged.

If merging retires one identifier, every external system holding that identifier now points at nothing. If merging generates a third identifier, both external references break. If the system reuses identifiers after deletion, you have a genuinely difficult problem, because an external record can silently attach to the wrong human being.

Configuration is usually treated as a setup task. It happens under time pressure, during implementation, often delegated to whoever has capacity, and it is almost always shaped by the question "how do we get live on Monday" rather than "what will we want to measure in 2029".

Appointment types, cancellation reasons, treatment codes, statuses, custom fields and picklists are all decided in that window. Every one of them becomes a permanent constraint on what you can analyse.

Nobody thinks of this as a data decision at the time. It is the most consequential data decision in the whole project.

The clearest example is the cancellation reason.

If cancellation reason is a free-text box, you will accumulate fifty thousand records containing "pt called", "pt called to cancel", "cx", "unwell", "sick", "poorly", "work", "at work", "couldn't get out of work" and two thousand blanks. You will never be able to answer what proportion of your cancellations are avoidable, which is the only reason you collect the field.

If it is a picklist with six options, you can answer it on day one.

The same trade-off applies everywhere. Structured data is harder to enter and trivial to analyse. Free text is the reverse. The decision about which fields deserve structure is made once, quickly, and lives for the life of the system.

Appointment types are the backbone of nearly every operational report you will run. Getting the granularity wrong in either direction causes damage.

Too few and you cannot segment. A single "consultation" type tells you nothing about the difference between a first assessment and a six-month check.

Too many and staff choose wrong. When a receptionist faces a dropdown of ninety options with similar names, under pressure, with a queue, they will pick the one nearest the top or the one they used last time. The data is now worse than if you had ten options, because it looks precise and is not.

There is a second trap in naming. Appointment types are usually named for scheduling convenience, using internal abbreviations and duration codes. Those names then appear in every report, every export and every board pack for the next decade.

Practice management systems are built around an assumed organisational shape. Usually it is a single site, with a fixed group of clinicians, one price list, one brand and one set of rules.

Most of them then add multi-site capability later. There is a meaningful difference between a system designed for multiple locations and a system that has had multiple locations bolted onto it, and the difference is invisible in a demonstration of a single site.

It becomes visible the first time you try to run a central function, consolidate a report, or absorb an acquisition.

Is a patient one record across sites, or one record per site. This determines whether you can see a complete history when someone attends a second location, whether your patient count is real, and whether cross-site referral is measurable. Both designs exist in the market and vendors rarely volunteer which they use.

Can one clinician work across sites in one diary. A peripatetic specialist who covers three locations needs a single view of their week. Where the system requires a separate diary per site, double-booking becomes a manual discipline.

Can you report across sites in one view, without exporting. Consolidated reporting is frequently available only in a higher tier, or only through a separate analytics product, or not at all. Where it does not exist, the group finance function rebuilds it in a spreadsheet every month, in perpetuity.

Is configuration global, per site, or both. Appointment types, price lists, document templates and communication content. You will want some of these standardised and some local. A system that forces all-or-nothing on this makes one of those two things painful forever.

This one is genuinely non-obvious, and it is worth thinking about carefully.

Pricing models in this market vary. Per user, per concurrent user, per clinician, per site, per patient record, or a flat platform fee. Each creates a different incentive inside your organisation.

Per-user pricing creates pressure to share logins at the front desk. Shared logins destroy the audit trail, make it impossible to attribute an action to a person, and remove any ability to analyse individual performance or identify training needs. The cost saving is visible on the invoice. The cost is not.

Per-site pricing makes a small satellite location disproportionately expensive, which can quietly shape estate decisions.

Per-clinician pricing changes the calculation on part-time and locum staff.

None of these models is wrong. The point is that the pricing structure will influence operational decisions, and it is better to notice that deliberately than to discover it in a review three years later.

Online booking appears on every requirements list as a single line item with a yes or no answer. It is then evaluated on whether the interface looks reasonable.

For most healthcare businesses it is the top of the acquisition funnel. It is the point at which a person who has decided to consider you either becomes a patient or leaves. A ten per cent difference in completion rate is a ten per cent difference in new patient volume, achieved without spending anything more on marketing.

Almost nobody measures it, because almost no practice management system reports on it.

Abandonment. How many people started a booking and did not finish, and at which step they stopped. This is standard measurement in every other online transaction. In practice management software it is frequently not captured at all.

Searches that found nothing. Somebody looked for a Saturday appointment with a particular clinician in the next two weeks and there was none. That event is the single most valuable piece of capacity intelligence a practice can hold. It tells you what demand exists that your rota does not serve. Most booking modules discard it without recording it.

Where they came from. If the booking page is hosted on a vendor domain, or embedded in a frame, campaign tracking parameters are often lost at the boundary. Your analytics then attribute the booking to the vendor's site rather than to the campaign that paid for it.

What they nearly booked. The appointment type selected before the person changed their mind.

Not every practice needs a heavily instrumented booking funnel. A single-site practice with a waiting list and no acquisition problem has other priorities, and over-engineering this is a real risk.

The distinction worth drawing is between organisations where new patient volume is the constraint and organisations where capacity is. For the first group, this is one of the highest-value areas in the entire system and one of the least examined.

Every number your organisation will ever report comes from somebody typing it in.

That somebody is usually at the front desk, at the busiest moment of the week, with a queue of four people, a ringing phone and a clinician waiting for an answer. Whatever the software asks of them in that moment determines the quality of everything downstream.

This is not a training issue, although it is always described as one. It is a design issue, and it is measurable during evaluation if you look for it.

Defaults get selected. If an appointment type dropdown opens on a particular value, that value will be over-represented in your data by a wide margin. The same applies to cancellation reasons, referral sources and status fields. The first option in any list becomes the most common answer in your reporting, regardless of what actually happened.

Optional fields get skipped. A field that takes two extra clicks will be left blank under pressure. The referral source field is the classic casualty. It is the field with the highest commercial value and the lowest completion rate in most practices, and the reason is almost always that it sits two tabs away from the booking screen.

Mandatory fields get garbage. The obvious response to low completion is to make the field mandatory. What follows is a field that is one hundred per cent complete and entirely meaningless, because staff enter whatever clears the validation fastest.

Workarounds become policy. Booking into a dummy patient record to block time. Recording a cancellation by deleting the appointment. Writing operational information into a clinical note because there is nowhere else. Each of these is a rational response to friction and each one removes data permanently.

Logins get shared. Where signing in is slow, or licences are counted per user, a shared login appears. The audit trail stops being able to answer who did anything.

Exit terms are negotiated at the point of maximum weakness, which is the point at which you have already decided to leave.

At that moment you have no leverage, a deadline, and a vendor with no commercial reason to make the process easy. Whatever the contract says is what you get.

The point of maximum leverage is before signature, when you are a prospect and the vendor wants the deal. Almost nobody uses it, because discussing the end of a relationship while starting one feels awkward and nobody wants to sour a procurement.

The average tenure of a practice management system is long, often ten years or more. That is precisely why the exit terms matter. Ten years of accumulated records is the most valuable asset the business holds, and the terms governing it were agreed in a document nobody has read since.

Clinical record retention periods run for years, and in some categories decades, beyond the point at which a patient stops attending. Those obligations attach to you, not to the vendor.

This creates a problem that surprises people. When you leave a system, you may still be legally required to be able to produce records held in it. If the export does not fully preserve them in a readable form, you are left paying a maintenance licence on a dormant system for an extended period, purely so the data remains accessible.

That cost is real, it is ongoing, and it is entirely determined by how good the export is.

What happens if the vendor is acquired or ceases trading. Source code escrow is the traditional answer and is rarely practically useful for hosted software. A data escrow arrangement, or a contractual commitment to a final export in an insolvency scenario, is more relevant.

Where the data physically sits, and who the sub-processors are. Messaging, document storage, backup and analytics are frequently handled by third parties. Each one is a separate export question and a separate data protection question.

Whether the vendor asserts any rights over derived or aggregated data. Some agreements permit the vendor to use anonymised data for benchmarking or product development. This may be entirely acceptable to you. It is better to know.

Most migrations get the clinical record right. Charts, notes, medications, documents, images. PMS migrations are good at this, and it is table stakes.

Appointment history is where migrations can quietly fail. The chart comes across. The record of how the patient actually used your practice does not.

You can spot it in about two minutes. Open the new system after go-live and pull appointment volume by month for the last three years. If there is an enormous spike in the month you switched, the history did not migrate properly.

Ten thousand appointments all dated the same week means every historical visit was stamped with the import date instead of the date it happened.

A timeline, not a list.

In your current system you can look at any week from last year and see who came in, who they saw, what they came in for, when they came in, and who never showed up. That view is the patient journey and clinic room utilisation. It is essential data.

A bulk import gives you a stack of appointment records sitting on a patient chart with no usable dates. The data is technically present, but it is not useful.