Before You Replace a Clinic System: A Checklist

A clinic replaces its system once every seven to ten years, sometimes less. That is rare enough that no one on the staff is experienced at it, and significant enough that a mistake costs months of duplicated work. This list was written to serve as a worksheet, not to impress.

Step one: understand what is really broken

Before looking at a new system, it is worth writing three lines: what takes the most time today, what falls between the cracks most often, and what is impossible today. The distinction matters, because a new system solves the third kind well, solves the second partially, and often makes the first temporarily worse during rollout.

If the answer to all three questions is that the current system is slow, it is worth checking whether the problem lies in the software, the hardware, the network or the process. A replacement driven by slowness that originates in the process will repeat itself.

Step two: nine checks before signing

1. Language and direction on every screen, not the home page

Ask to see the ugly screens in Hebrew: a financial report, a lab-results table, an audit log, a printed prescription. These are the places where partial Hebrew support shows up. Check composite values in particular, such as blood pressure, reference ranges and negative amounts.

2. Printing and PDF documents

Printing is the point at which many systems break in Hebrew, because the print engine differs from the display engine. Ask for a real PDF of a prescription, a visit summary and an invoice, and open it yourself.

3. An Israeli calendar

A week that starts on Sunday, a short Friday, holidays and holiday eves, and a series of recurring appointments that knows how to skip a holiday. Ask how the clinic’s days off are defined and who can change them.

4. Israeli identifiers

A national ID number is stored as a string of nine digits with leading zeros, and validated by a check digit. Ask what happens when a patient arrives with a passport, a tourist, or an infant who has not yet been assigned a number.

5. Role-level permissions

Ask to see the permissions screen itself, not a description of it. Ask whether viewing of financial details can be limited to a particular role, and whether a secretary sees the full clinical record.

6. Audit log

Ask one question: if a patient asks to know who viewed their record over the past six months, how long will it take to produce the answer, and who produces it. If the answer involves contacting the vendor, that is a problematic answer.

7. Exporting your data

This is the check easiest to postpone and most expensive to skip. Demand it in writing: which data can be exported, in what format, how long it takes, and how much it costs. A general statement about export is not enough.

8. Existing integrations

List everything that talks to the system today: a lab, imaging devices, credit-card clearing, an accounting system, an SMS service. For each one — is there an interface, who maintains it, and what happens when it goes down.

9. Full three-year cost

Not just monthly usage fees. Add setup, data conversion, training, development hours for changes, storage of files and video, and the staff’s internal working time during the transition months. Compare that total, not the price per month.

Step three: run a real test case

A vendor demo is built on a happy path. Instead, bring three cases from your own clinic to the meeting, stripped of identifying details, and ask to run them end to end:

• A new patient who arrives without an appointment, is registered, is examined, receives a prescription and pays.
• An existing patient returning for follow-up, with a result that arrived from the lab between visits.
• A complicated case: a refund, a canceled invoice, or a correction to a signed record.

The third case is the important one. Correcting a mistake after closing is where the system’s true design is revealed.

What to demand in the contract

Clause	What to verify
Data ownership	The data belongs to the clinic, in any situation, including at the end of the engagement
Export on termination	A defined format, a defined schedule, and a cost defined in advance or no cost
Backup and restore	Frequency, location, and who actually performs a restore test and how often
Availability and support	Response hours, response time for a disabling failure, and a defined channel of contact
Security and privacy	A data processing agreement, where the data is stored, and who at the vendor can access it
Changes and additions	What is included in self-configuration and what requires paid development

Planning the transition itself

Three decisions worth making early. First, what moves and what stays: usually active patients, clinical records, medications and allergies, and future appointments move, while old financial history stays accessible for reading only. Second, when the transition happens: not in peak season, and not in the week before the vacation of whoever knows the system. Third, who the internal owner is: one person in the clinic through whom decisions pass.

Rule of thumb: plan a parallel run of two to four weeks, during which the calendar is already in the new system but the old system is still accessible for reading. This costs time, and it is far cheaper than discovering late that something is missing.

Who needs to sit at the decision table

Clinics tend to decide at the management level alone, and then discover resistance on the ground. Three roles must be involved before signing, each with a veto in its own domain. The front-desk staff, because they are the ones who will key in most of the data and absorb the daily friction; at least one clinician, because clinical documentation that does not fit the pace of work in the room will not survive; and whoever is responsible for the money, because a billing module that does not match how the clinic collects creates manual work every month, forever.

It is also worth deciding in advance what will happen with resistance. A veteran employee who says the old system is more convenient is usually right in the short term. The answer is not to convince them that they are wrong, but to agree in advance on a period — say six weeks — at the end of which you check again, on the basis of numbers rather than feelings.

Four recurring mistakes

• Choosing by demo. A demo measures the quality of the presenter. Your own test case measures the system.
• Postponing the export question. The only moment you have bargaining power over the exit terms is before signing.
• Switching in peak season. A busy month will turn every small glitch into a crisis.
• Migrating all the history. Expensive, slow, and usually unnecessary. Better to decide what is really needed as active data.

Three questions that reveal the most

What happened to the customer who left you, and how their export went. Which change to the system a clinic can make on its own, and which requires you. And what changed in the product over the past year. The answers teach more about the vendor’s approach than any presentation.

Back to the blog