How to back up a medical practice running Medicus so it can actually be restored

The sentence we hear most often when taking over a new practice is: "We have a backup, it runs every night." The second most common, a few weeks later: "We tried to restore it and it didn't work." This article is about getting from the first sentence to a state where you never have to say the second.

What to back up in a practice

Practice management systems such as Medicus, SmartMEDIX or the pharmacy system Farmis (widely used Czech healthcare software) look like a single program, but in fact they consist of several parts, each of which needs to be backed up separately:

• The database. Patient records, clinical notes, prescriptions, care reported to insurers. In Medicus this is a Firebird database; other systems use Microsoft SQL Server or PostgreSQL. This is the one thing you cannot buy again.
• Attachments and documents. Scanned reports, images, PDFs from specialists. They often sit in a separate folder outside the database, and backups forget about them.
• Settings and licences. Insurance company code lists, print templates, certificates for eRecept and eNeschopenka (the Czech electronic prescription and electronic sick note systems), login details for portals. Without them you still have the data, but the practice cannot report care the next day.
• The server operating system. Not necessarily in the backup, but you must know how to rebuild it in an hour, not a week.

If you do not know exactly where your data lives, ask the system vendor. "The program handles that itself" is not a sufficient answer. You want the folder path and the database name.

The 3-2-1 rule, translated for a practice

The rule every solid IT operation follows is: three copies of the data, on two different media, one outside the building. In a practice this means:

1. Live data on the server or main computer.
2. A local backup on another device in the same building, typically network storage (NAS). This is the fastest to restore from when a disk fails or someone accidentally deletes a patient record.
3. A backup outside the practice. An encrypted copy on storage elsewhere: with your IT administrator, in a data centre or in the cloud. It protects against fire, flooding, theft and above all ransomware, which encrypts everything it can see on the network, including the local backup.

What is not enough: an external disk permanently plugged into the server. In a ransomware attack it gets encrypted along with everything else. A USB stick in a drawer that things are "copied to now and then" is not a backup either; it is a good intention.

How often

• The database every day, ideally at night after surgery hours. In larger practices also during the day, because a day's work by two doctors cannot simply be "done again".
• Documents and attachments every day, together with the database.
• Settings and licences after every change, and at least once a month.
• Keep several versions of backups, not just the latest. Errors in data often only appear after several days, and you need the state from last Tuesday, not from yesterday when the error was already in there.

A backup you have never restored from is not a backup

This is the most important paragraph in the whole article. A backup program can report "completed successfully" every night and at the same time:

• back up an empty folder because the vendor moved the data elsewhere during an update,
• produce a file that cannot be opened because the database was open at the moment of copying,
• write to a disk that has been full for weeks,
• run under a user whose password someone changed, and fail silently.

We have actually seen all four cases at clients. The only defence is a test restore: take the backup, restore it on another computer and open a patient record in it. Not once when it is set up, but regularly, at least once a quarter. Write down the result, including how long the restore took. That is a number you want to know before you need it.

What your IT administrator should watch, not you

A good backup is boring: it runs by itself and only speaks up when there is a problem. From whoever manages your IT, you should expect:

• Automatic freshness monitoring. Not "the program reports OK", but a check that the backup file on the target storage has today's date and a reasonable size. If the file is older than a day or suddenly half the size, an alert goes to the administrator, not to you.
• Silence is not proof. When your administrator tells you everything is fine, ask when they last saw a backup from your practice with their own eyes and when they last tried a restore.
• A written restore procedure. One page: where the backup is, how to load it, who to call. Someone in the practice should have it too, not just the administrator.
• Separation from the network. The off-site backup must be reachable in one direction only. The server may send the backup out, but nothing in the practice may be able to delete it.

A quick check for practice management

Answer five questions. If any answer is "I don't know", you have a topic for your next meeting with your IT administrator.

1. Where physically is the latest backup and how old is it?
2. Is there also a copy outside the building, and is it encrypted?
3. How many versions back can be restored?
4. When did we last try a restore and how long did it take?
5. Who gets notified if the backup does not run at night?

How we do it

At the practices and pharmacies we manage, a nightly backup of the database and documents runs to local storage, with an encrypted copy sent to our data centre in Brno. Every morning an automated check confirms that the backup exists, is fresh and has the expected size. If not, we find out, not the practice. We carry out test restores regularly and send the client the result in writing.

If you are unsure about even one of the five questions above for your practice, book a no-obligation consultation. We will go through what you have and tell you plainly what holds up and what does not.