What to demand in a clinic software demo

Every clinic software demo is run by the vendor, on the vendor's data, along a path the vendor has walked a thousand times. Nothing goes wrong in it, because nothing in a demo is allowed to go wrong. The way to learn something is to ask what the software does on a bad day: when the bill was wrong, when two people tapped at once, when somebody opened a file they had no business opening, when you decide to leave. The list below is useful even if you buy from somebody else.

Money, and why it comes first

A clinic's records can be rebuilt from paper and memory. Its money cannot. So the billing questions carry more weight than the feature list, and they are the ones a public product page tends not to answer: the one vendor product page we checked leads with encryption strength and a certification, and neither of those says anything about whether a receptionist can quietly change a bill she has already handed over.

This is how our own billing is built, and the code is the citation rather than the claim. An issued invoice refuses edits and tells you to void and reissue. Voiding is the admin's alone and needs a written reason, and where money had already been collected it writes a compensating entry into the same ledger the day end reads, so the cancelled bill stays where it was and the day end lands where it should. Settling is a guarded flip from issued to paid, so a double tap loses cleanly instead of collecting twice. Bill numbers come from a transaction level advisory lock keyed on the clinic and the year, so only the bills that could actually collide wait on each other, and the lock releases when the transaction commits.

Who can see which patient records

Ask this as a matrix, not as a yes. We have roles is true of everything sold. The question is which role can open which record, and whether anybody has written it down where you can read it.

The strong version of that last answer is not a policy, it is a refusal the application cannot talk its way past. On a managed database the application usually connects as the owner of the table, so revoking rights achieves nothing and a trigger is the only thing that holds. Ours reads:

CREATE OR REPLACE FUNCTION forbid_audit_log_mutation() RETURNS trigger AS $$
BEGIN
  IF current_setting('elaior.audit_wipe', true) = 'on' THEN
    IF TG_OP = 'DELETE' THEN
      RETURN OLD;
    END IF;
    RETURN NEW;
  END IF;
  RAISE EXCEPTION 'AuditLog is append-only';
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER audit_log_append_only
  BEFORE UPDATE OR DELETE ON "AuditLog"
  FOR EACH ROW EXECUTE FUNCTION forbid_audit_log_mutation();

That shape is what to ask for. The one exemption is a transaction scoped setting with a single call site, so the routine that wipes a demo clinic can still run while every other statement the service could issue is refused. Ours also files a row when somebody opens or downloads one named record, throttled so a reload does not count as a second look, and deliberately not for list views and searches, which would bury the feed in rows nobody reads. Who may read the trail is a separate question: ours is kept off the clinic's own permission matrix, because the trail names every actor including the admin reading it.

Leaving

Ours is four self serve downloads, patients, visits, billing and expenses, restricted to the owner account because the dumps carry every patient's phone number, plus a monthly workbook for the accountant. The writer emits a byte order mark so a Windows spreadsheet renders Indian names correctly, and puts an apostrophe in front of any cell a spreadsheet would otherwise execute as a formula.

Three more, if they are still in the room

• What happens after five wrong passwords on one staff account? A lockout ladder on the account is a different thing from a rate limit on an address, and only one of them survives a restart and protects a named doctor's login. Ours counts the failures on the account itself and runs the same ladder the patient portal already had.
• When a visit is deleted by mistake, is it gone or is it marked? Ask to see the record immediately after the delete, and ask who can undo it.
• One login, several clinics: what stops a query crossing between them? A real answer names the clinic identity that every read filters on, not a screen that hides the other rows.

None of these are trick questions. A vendor who has built the boring parts answers each one in a sentence and enjoys being asked. A vendor who has not will steer back to the feature list, and that is your answer.