Getting Patient Data Out of a Booking Platform Before You Switch
Your obligations to patients under the Australian Privacy Principles do not transfer to a vendor because the vendor holds the database. If you cannot export, you cannot meet an access request. Test the export before you need it, not during the migration.
Vikas Thakur Founder, RockingWeb 8 min read 
Key Takeaways
- Your APP obligations follow the personal information, not the database. A vendor holding it does not make it their responsibility to your patient
- If your platform cannot export, you cannot reliably meet an access or correction request
- A usable export is CSV or JSON with stable identifiers, not a PDF report
- Test the export before you need it. During a migration you have the least time and the least leverage
- Ask about export before signing, because it is the one contract term nobody negotiates and everybody eventually needs
- In force. APP 12 access and APP 13 correction obligations apply now
Every clinic that has changed booking platforms has the same story, and it always starts the same way: the new system was chosen, the date was set, and then someone tried to get the data out.
The reason this goes badly is not usually vendor obstruction. It is that nobody tested the export while there was still time to react to what it contained.
Why This Is a Privacy Question, Not Just an Operations One
The framing matters, because “can I get my data out” sounds like a commercial convenience and it is not.
Under the Australian Privacy Principles, an APP entity must give an individual access to the personal information it holds about them on request, subject to exceptions, and must take reasonable steps to correct it where required. Those obligations attach to you as the health service provider that collected the information. They do not move to your booking vendor because your booking vendor runs the server.
So a platform you cannot export from is a platform that impairs your ability to comply. That is a materially different problem from an inconvenient migration.
| Obligation | Whose it is | What a bad export does to it |
|---|---|---|
| Access request (APP 12) | Yours | You cannot produce the information |
| Correction (APP 13) | Yours | You cannot show what was corrected |
| Retention and destruction | Yours | You cannot verify what still exists |
| Breach assessment | Yours | You cannot determine what was affected |
The last row is the one clinics underestimate. Assessing a suspected breach requires knowing what data existed and who it concerned. If you cannot enumerate your own records, you cannot make that assessment inside the timeframes the Notifiable Data Breaches scheme contemplates.
What a Usable Export Contains
The values are a build-experience pattern across common clinic platforms rather than a vendor benchmark. The consistent shape is that contact records export well and everything else degrades, with consent records and free-text notes the worst served.
That ordering matters because consent records are exactly what you need to prove you were entitled to contact someone, and notes are where staff put the context that makes a record intelligible.
A usable export has:
- Stable identifiers linking a patient across files, so an appointment row can be tied to a contact row
- A machine-readable format, CSV or JSON. A PDF is a picture of your data
- Timestamps in a documented timezone, ideally ISO 8601 with an offset
- Form submissions with their original field labels, not renumbered columns
- Consent and communication preferences as discrete fields, not free text
- Documentation of what each column means
What That Means for the Build
Run a full export today and open the files. Not a sample export, a full one. Open the CSVs in a text editor as well as a spreadsheet, because a spreadsheet silently reformats dates and truncates long fields, which hides exactly the problems you are looking for.
Check the joins. Take three patients and confirm you can trace each from contact record to appointment history to form submission using the identifiers provided. If you cannot, the export is a set of disconnected lists.
Confirm the character encoding. Australian clinic data contains apostrophes in surnames and occasionally non-Latin characters. An export that mangles them is producing incorrect patient records.
Diarise it. Platforms change their export tooling. An export that worked last year is not evidence about this year.
The first series is an illustrative pattern from migration projects, not survey data. The second is simply the recommendation: all four points, not one.
A Worked Example
Cosmetic clinic. A clinic switching platforms received an export of contacts and appointments in clean CSV, and consent records as a single free-text column containing strings like “SMS ok, email ok 2023”. Rebuilding structured consent from that text was not reliably possible, so the clinic re-consented its list rather than import records it could not stand behind. That cost list size and was the right call.
Dental practice. A practice discovered its export produced appointment dates with no timezone, generated on a US-configured server. Appointments near midnight were off by a day. Caught because someone opened the raw CSV and compared three known appointments against the diary. Had it not been caught, the migrated history would have been quietly wrong.
What to Check on Your Own Site
- Run a full export now. Do not wait for a reason.
- Open every file in a plain text editor, not only a spreadsheet.
- Trace three patients end to end across the exported files.
- Check date formats for a timezone indicator.
- Check whether consent and communication preferences came out as structured fields.
- Search your contract for “export”, “termination”, “data” and “transition”.
- If anything is missing, ask the vendor in writing and keep the answer.
The Enforcement Anchor
The OAIC’s determinations register covers access and correction complaints against health service providers, and APP 12 access complaints are a recurring category. What does not exist, that we can point to, is a published Australian determination turning specifically on a clinic being unable to answer an access request because its booking platform could not export.
The obligation is enacted and unambiguous. The specific fact pattern has not produced a published outcome yet, and it would be misleading to imply it has.
Where This Gets Hard
Legacy on-premise dental systems are the hardest case. Some hold data in proprietary formats with no documented export at all, and the practical route is a vendor-run extraction at a price. There is no clever technical answer to a closed binary format; it is a commercial negotiation.
The second difficulty is scope. A genuinely complete export may include free-text clinical notes, which raises its own questions about where that file then lives, who can read it, and how long you keep it. Exporting your data creates a new copy of sensitive information, and that copy needs the same protection as the original.
The regulator says you must provide access to personal information you hold on request; the build consequence is that your platform must be able to produce that information in a usable form; whether a specific export satisfies a specific request in your circumstances is a question for your medical defence organisation or your lawyer.
Status
In force. APP 12 and APP 13 have applied since 12 March 2014, as has the rest of the APP framework. The Notifiable Data Breaches scheme has applied since February 2018. None of this is pending commencement.
Frequently Asked Questions
Does my booking platform own the patient data in it?
Holding data is not the same as owning it, and for privacy purposes the question that matters is not ownership but who is the APP entity responsible to the patient. Your obligations under the Australian Privacy Principles follow the personal information you collected, and they do not transfer to a vendor because the vendor operates the database. If a patient asks you for access, the answer cannot be that your software will not export.
What should a usable export contain?
At minimum, patient contact records, appointment history with dates and types, form submissions with their timestamps, consent and communication preferences, and any notes fields your staff have used. Format matters as much as content: a PDF of a report is not a usable export, whereas CSV or JSON with stable identifiers is.
When should I test the export?
Before you sign, ideally, and otherwise at a calm moment well before any migration. An export tested during a switch is being tested at the precise moment you have the least leverage and the least time. Run a full export now and open the files.
What if the vendor charges for an export or refuses one?
Charging for a migration export is common and not automatically unreasonable. A refusal is a different matter, because it directly impairs your ability to meet access and correction obligations to your patients. Record the request and the response in writing, and treat the answer as material information about whether to stay on that platform.
Planning a Platform Change
If you are considering a switch, get in touch and we will run the export test and tell you what you can actually move before you commit to a date.
Sources
- OAIC - Australian Privacy Principles, including APP 12 access and APP 13 correction. Checked 10 August 2026.
- OAIC - Notifiable Data Breaches scheme. Checked 10 August 2026.
- OAIC - Health information and health service providers. Checked 10 August 2026.
Last reviewed: 10 August 2026.
Vikas Thakur
Founder of RockingWeb. 16 years building for companies like TPG, iiNet and Monadelphous, now focused on websites and marketing that comply with AHPRA's advertising guidelines and still book patients.
