Blog
What a surgical practice is actually shopping for
Search for software for a surgical practice and you get two unrelated products in the same list of results. Working out which one you are looking at is most of the decision.
Type software for a surgical practice into a search engine and the results will not agree with each other. Some of them manage operating lists, theatre utilisation and instrument trays. Others manage patients, appointments, documents and invoices. They use overlapping words, they cost wildly different amounts, and only one of them is likely to fix the thing that made you search in the first place.
The distinction is obvious once somebody points at it and close to invisible before that, which is why surgical practices routinely sit through a demonstration of the wrong category of product.
Two systems that share a vocabulary
Theatre and list management runs the operating side: which case is on which list, in which theatre, with which team and which tray, and whether the session over-ran. If you operate at a hospital or a private surgical facility, this is usually not yours to choose. It belongs to the facility, and you work inside whatever they already run.
Consulting-room practice management runs everything on either side of the operation: the patient who rang to ask about a consultation, the notes from that consultation, the signed consent, the date, the follow-up six weeks later, and the invoice for all of it. This part is yours. It is also the part most often being run out of a paper diary, a spreadsheet and an email inbox.
A surgeon with admitting rights at a private hospital typically has no say over the first and complete responsibility for the second. If that describes you, the thing you are shopping for is the second one, whatever words you typed into the search box.
A test for which one you need
Ask where the week actually goes wrong.
If the problem is that a list over-ran, that a case was cancelled for want of a bed, or that a theatre sat idle for forty minutes between cases — that lives in the facility's system. Practice management software will not touch it, and no amount of demonstration will change that.
If the problem is that nobody is certain whether a particular patient's consent was signed, that the six-week follow-ups exist mainly in one person's memory, or that invoices go out weeks late because the information needed to raise them sits in three different places — that is practice management, and it is buyable.
Most practices, asked this plainly, already know which of the two they are describing.
Why a surgical practice fits the software badly
Most practice management software is built around a repeating appointment. A physiotherapy patient comes six times over six weeks. A dental patient comes twice a year, indefinitely. The scheduling model assumes the next contact is another appointment in the same rooms.
A surgical episode does something else. One consultation. Then a gap — a week, or a year — while the patient decides, or waits for a date, or waits on an insurer. Then a procedure that does not happen in your rooms at all. Then a follow-up, often a second one, and then nothing.
That shape breaks three assumptions at once. The patient is active for months while having nothing booked. The most significant event in the episode happens somewhere your system cannot see. And the follow-up is generated by the procedure date rather than by the last appointment you hosted.
It is worth checking directly that whatever you are shown can hold a patient who is between things, because a system that only understands booked appointments will quietly lose them.
Consent is a records problem, not a feature
This comes up early in every conversation, and the honest answer is less exciting than the one people hope for.
Consent for a procedure is specific to that procedure, and its wording is a matter for you, your specialty association and your indemnity provider. It is not a matter for a software vendor with a template library. Anything shipping generic surgical consent wording is offering you a document you would rewrite before using it once — and the rewriting is the part that carries the risk.
What software can usefully do is narrower, and worth asking about in those narrower terms: hold the consent you wrote against the right patient, record that it was signed and when, and make it retrievable in the seconds before a clinic rather than the minutes after. Ask where a signed document lives and who can pull it back out, rather than accepting the words consent forms on a feature list as an answer.
Five questions worth asking in a demonstration
Not exotic ones. These are simply the places a general-purpose booking system stops fitting a surgical practice, and each has a demonstrable answer.
- Can a patient sit in the system for eight months with nothing booked, and still be found?
- Does a signed document attach to the patient, or to an appointment that may not exist?
- Can a follow-up be scheduled from a date that was never an appointment in this system?
- What does the record look like when the procedure happened somewhere you have no access to?
- Can you get everything back out, in a format you can read, without asking the vendor?
Ask for each one to be shown rather than confirmed. The gap between yes and here it is is where most of the disappointment in this category lives.
Where HyperCRM sits
On the consulting-room side, and only there. Consultation notes, documents held against the patient record, follow-up scheduling and invoicing, on one record per patient.
It does not do theatre lists, surgical planning or instrument tracking, and it has no view into the facility's system. If the thing going wrong in your week is on the theatre side, this is not the purchase — and it is better to read that here than to discover it in the third demonstration. If it is the consultation-to-follow-up loop, the half that is actually yours, that is the part this was built for.