How to choose practice management software for an osteopathy practice

A polished demonstration tells you what a product looks like when everything goes well. A sound selection process asks a different question: can the system support your real workflows while protecting sensitive information, surviving disruption and letting you leave with usable data?

Before publication or purchase: country-specific legal and professional requirements need local review. Use fictional data during trials unless a properly governed processing arrangement is already in place.

1. Start with workflows, not a feature list

Map a representative week: booking, arrival, record keeping, documents, payment, invoices, reminders, access requests, temporary cover and closing a patient record. Mark what must work on mobile, across more than one location or with several team roles.

Sort requirements into essential, useful and unnecessary. More fields and automations are not automatically better. Collecting a detailed appointment reason before it is needed, for example, may increase the sensitivity of data without improving the service.

2. Clarify data-protection roles and contracts

Under the GDPR, the controller determines why and how personal data is processed; a processor acts on the controller’s documented instructions. The exact allocation depends on the service and context, but the relationship must be understood rather than assumed.

Ask for the processor terms, sub-processor list, processing locations, safeguards for transfers outside the EEA, incident assistance and what happens to data at the end of the contract. The European Data Protection Board’s small-business guide explains that controller–processor arrangements must be governed by a binding contract and that sub-processors require appropriate authorisation and equivalent protection.

3. Test access like a real practice

Create fictional roles such as owner, practitioner, temporary colleague, reception and administrator. Check that each person sees only what they need. Look for named accounts, strong authentication, timely revocation, session controls and an audit trail that records meaningful access and changes.

Do not accept “we support permissions” as proof. Ask the supplier to demonstrate a negative case: what exactly happens when a reception role tries to open clinical notes, or a former team member tries to sign in?

4. Ask for evidence of security and continuity

The GDPR requires security appropriate to risk. The EDPB frames this around confidentiality, integrity and availability, then asks organisations to identify measures, verify that they work and review them periodically.

Ask about encryption, patching, monitoring, backups, restoration tests, incident handling and remote support. A backup policy is not the same as evidence that restoration works. Clarify recovery objectives and how the practice operates during an outage.

5. Test the exit before signing

With fictional records, request an export of identities, appointments, records, documents, invoices, consent information and useful relationships between those data. Check whether the formats are documented and whether another system could realistically interpret them.

A collection of readable PDFs may help humans but still be inadequate for migration. The contract should state the export format, timing, cost, assistance, secure transfer, deletion process and evidence of deletion. This is contractual reversibility; it should not be confused with the GDPR right to data portability, which has a narrower scope.

6. Score proof, not promises

For every important criterion, record whether it was demonstrated, documented, merely stated or absent. Give security, continuity and exit criteria enough weight that an attractive interface cannot hide a blocking weakness.

Use the practice software scorecard to structure the first review. It is intentionally vendor-neutral and stores the assessment only in the current browser session.

Questions worth asking every supplier

• Which entity is contracting with the practice, and which sub-processors are involved?
• Where is data processed and how are international transfers governed?
• Can every team member use a named account with appropriate permissions?
• When was restoration last tested, and what evidence can be shared?
• What is included in a full export, in which formats, at what cost and within what time?
• How are security changes, incidents and sub-processor changes communicated?

Sources and review note

• EDPB — Data controller or data processor
• EDPB — Secure personal data
• European Commission — Processing data on an organisation’s behalf

Source review: 28 August 2026. This is a general evaluation framework, not legal or procurement advice.