Changing system must not cost a weekend of copy and paste

The key or the files

Terapeutbooking is EasyPractice under a Danish name, and the API is the same. The shortest way in is therefore a key: you create it in the old system under Settings → API with read access to clients, appointments, records and record files, and enter it with us. The server then fetches services, clients, appointments, clinical notes and record files and files them where they belong — with a trace back to the old id on every single record.

The key is stored encrypted in the clinician’s own folder while the move is running, used for that one job and deleted when it is done. It never appears in the log. The log gives counts — never names.

Not everyone has a key, and a clinic that has already given notice may only be able to reach the export. The second door is therefore the files: clients, appointments and records as CSV or Excel, uploaded to us one file at a time. It needs no key and no network; the rows go through exactly the same mappings as the key route, the run takes seconds, and the files are deleted afterwards.

The pace of the key route is set by the old system: 60 calls a minute, and we stay under it. For a clinic with a few hundred clients and records, allow half an hour or so, not a couple of seconds. That is fine — it happens once, and if the network or the power interrupts it, it carries on from where it left off.

Any file with one row per client

The file route is not tied to Terapeutbooking. If the old system can put out a table — CSV with commas, semicolons or tabs, or an Excel sheet — with one row per client, appointment or note, it can be used. The columns are guessed from the headings, in Danish and English: «First name», «E-mail», «Date». You correct where the guess was wrong, and that is all.

You do not see the whole table, but the columns, a sample of five rows and the counts. And you can look up any row you like and see it as it will look with us: a client record, an appointment with date, time, client and service, a note with date and text. A row that cannot be used — an appointment without a time — is marked as skipped before anything is run.

If the server has a language model, it can help guess the mapping. It sees only the headings and the shape of the values — letter or digit — never the values themselves. A name, a CPR number or a note is not sent to it.

• The least a file must contain. A client needs a name, or a first name and a surname. An appointment needs a start or a date, and a client: name, id or e-mail. A note needs a client and a text or a heading. A service needs a name. If that is missing, the file cannot be run, and the screen says what is missing.
• An id, even if the file has none. If the rows carry no id, one is made from what is there: name, e-mail and phone for a client, start, client and service for an appointment. The same file twice gives the same ids — and so not two of anything.
• Clients who only appear in the appointments. If a client is in the appointments file but not in the client file, she is created with what there is — the name — rather than the appointment becoming an anonymous block. The count afterwards says how many that applied to.

A file that is not in UTF-8 is read anyway — and a warning says that æ, ø and å were read as the Windows character set, so you can check the sample before you run.

What holds through both doors

• It can be run again. Every record remembers where it came from. If you run the move twice, there are not two of every client: the second time, what has changed is updated and the rest is left alone. Clients are matched on the old id, then on CPR number, then on e-mail or phone, then on name — one person, one record.
• Nothing is sent. Not one confirmation, not one text message. Appointments go in as what they are — history and upcoming times — and the clients have already been told about them by the old system.
• Appointments keep the status they have. Those in the past become «held» — or cancelled and no-show, if the old system said so. Those still to come become «confirmed».
• Notes become notes. Approved, with the old date and «Terapeutbooking» as the source, so no one believes they were written here. A draft stays a draft. Record files come across as they are — by the key route.
• Services are not bookable online by themselves. They are on the list with duration and price, but cannot be booked online until you switch that on yourselves. A service that can suddenly be booked by anyone because it was moved is not a decision anyone has taken.

The rules are the same whichever door you come in through. It is one mapping with two entrances, not two systems.

The export in Terapeutbooking — and the key

The export is made in Terapeutbooking under Settings → Import/Export (Indstillinger → Import/Eksport): clients, appointments and records, as CSV or Excel. The files can be downloaded for 24 hours, so make it on a day when you have time to upload them straight away. Services can be uploaded as a file of their own; if there is none, they are made from the appointments.

With us the files are uploaded one at a time, one per kind. The kind is guessed from the contents, and a new file of the same kind replaces the old one, so you can try again. Check the mapping, look up a few rows, and run. The counts afterwards say what became what: clients, new clients, appointments, notes, skipped.

If you choose the key instead: Settings → API in Terapeutbooking, a key with read access to clients, appointments, records and record files — and then in with us. If the key is rejected, make a new one in the same place and try again.

The two doors do not run at the same time. While a move with the key is in progress, the files cannot be run until it has finished.

What is not moved — and how far we are

• Invoices. The bookkeeping lives in the old system and with the bookkeeper, and an invoice that suddenly exists in two systems with two numbering sequences is an audit remark. If they need to be kept, they are exported from the old system as PDF.
• Record files only by the key route. The export files do not include the documents that were attached to the record. If you want them across, it has to be with the key.
• Colleagues’ calendars. The key fetches the clinician’s own calendar. Appointments in other clinicians’ calendars belong to other users and do not come across — they are counted, so you can see how many were left behind. Each clinician moves her own.

The status is the one shown on the system page: built, not in service. Both doors have been built and tried with export files, but neither has yet been run in service against a real clinic. That will stand here until it has happened — and no date is promised.