SurgiHub holds surgical bookings, consent forms and clinical correspondence. This page sets out how that information is stored, who inside your practice can reach it, and what is kept. Where we don't yet have a documented answer, this page says so rather than reassuring you.
Patient data is hosted in Australia on AWS. Every record carries the practice it belongs to, and a request that arrives without one is refused rather than answered.
No chat, document or record can be deleted by any user. Removed items are hidden and retained.
Each staff member sees what their role requires. Patients' personal details are hidden from those who don't need them.
Patient data is hosted in Australia on Amazon Web Services. Every patient-related record carries the practice it belongs to, and separation is enforced centrally in SurgiHub's data-access layer rather than left to each individual query: the practice is applied automatically to every read and every write, and a request that arrives without a practice context is refused outright rather than answered with another practice's data. A write that names a different practice from the one making the request is rejected rather than quietly redirected. The database schema reinforces all of this, because records in one practice cannot be linked to records in another.
Data is encrypted in transit and at rest. Traffic to the platform is served over HTTPS, terminating on an AWS load balancer, with plain HTTP redirected; traffic to the chat service is encrypted the same way. Data at rest is encrypted with AES-256 using AWS Key Management Service, and that covers the database volume, its automated backups, its snapshots and its replicas.
This matters in the three practice arrangements SurgiHub supports. A solo surgeon's practice is invisible to everyone outside it. A group practice shares one patient database and one set of administrators deliberately, so every surgeon in the group sees the group's list. Independent surgeons operating under a shared brand and a shared roof keep completely separate data, each practice invisible to the others.
Messages between your patients and your practice, and between your team members, are carried by CometChat, a specialist chat service. Those messages are stored on CometChat's infrastructure rather than in the SurgiHub database, and that infrastructure is in the United States. CometChat's standard regions are the United States, Europe and India; Australia is not offered as a standard region. Dedicated hosting in a nominated region may be available by separate commercial arrangement.
We state this plainly rather than let you discover it later, because chats in SurgiHub carry wound photographs, symptom reports and clinical advice. That makes them part of the health record rather than incidental correspondence, and it means part of your patients' health information is held offshore. The protections CometChat provides are set out below, and the compliance consequence is dealt with under Privacy and compliance.
What CometChat holds by way of assurance:
Chats are never deleted. The subscription is configured so that conversations are retained permanently, which is what a medical record requires.
Separation inside the chat service is enforced separately from the database, because a third-party service does not inherit it. Each practice has its own conversation with a patient, identified by that practice and that patient, so a patient treated by two practices has two conversations and not one shared thread. Every conversation is private: membership is the access boundary, and membership is set by SurgiHub when the conversation is created — the patient, the staff member who created the record, the practice owner, and a system account. Nobody can add themselves, and knowing or guessing a conversation's identifier gains no access. Where surgeons in a practice operate independently, the surgeon is part of the identifier too, so they are separated from each other as well.
The database is backed up automatically, and the backups are held in Australia and encrypted to the same standard as the database itself. Point-in-time recovery is active, so the database can be restored to any moment within the retention window rather than only to the last nightly copy. Retention is currently thirty-five days. Restoration is not assumed to work: a restore was performed and verified on 10 August 2026.
Access is role-based. Each staff member sees what their role requires, and patients' personal details are hidden from those who do not need them.
Patients see their own journey. A patient may nominate one next of kin, who receives view-only access — they can follow the journey but cannot change anything. There is more detail for patients in the patient help centre.
Patients maintain their own contact details, and they can also edit their own name and date of birth. That is deliberate: a patient is the person most likely to notice a misspelt name, and the alternative is a change request sitting in someone's queue. It does mean that where a booking has to match a hospital form, your own record is the one to check against it rather than the patient's profile.
Every staff member has a role, and each role arrives with a default level of access to each part of the platform. Those defaults are then adjusted per person where a practice needs it — so a role is a sensible starting point rather than a cage.
Access is set feature by feature, at four levels:
| Level | What it means |
|---|---|
| Edit | View, create, edit and delete within that feature |
| View only | Can see the feature but cannot change anything |
| No access | No visibility of the feature at all |
| Custom | Set at the group level, so items inside a group can differ from one another |
Six groups, each with its own items: Platform (web and mobile access) · Calendar & Booking (calendar, consults visibility, booking details, surgery, patient pathway, patient details, billing, documents and files, scheduled messaging) · Users (patients, staff, roles and permissions) · Chats · Library (pathways, surgery templates) · Settings (staff roles, implants, equipment, flags, status templates, message templates).
Surgeon · Anaesthetist · Assistant · Clinical · Manager · Internal Staff · Associate · Commercial · Financial. Every new practice is created with all nine, and your practice can add roles of its own beyond them where none of the nine fits how you work.
Patients and their next of kin sit outside this scheme: a patient sees their own journey, and a next of kin sees it view-only.
Your practice does not start from a blank grid. It arrives with a preset configuration we have chosen, which your administrator can then alter, feature by feature and person by person. The defaults themselves are not published here, because they are a starting point to be adjusted to how your practice actually works rather than a public specification. The point of this section is narrower: access is limited by role, and those limits can be adjusted per person.
SurgiHub does not yet keep an audit trail that your practice can read. Records carry their own creation and change timestamps, and some workflows keep a status history — who a booking was assigned to, when a consent form was signed — but there is no log of who viewed which patient record, when a permission was changed, or when an export was taken. We would rather tell you that than let a security questionnaire discover it. Specifying and building that log is on the development schedule, and the design questions are which events are captured, what is held against each one, how long it is kept and who may read it.
The SurgiHub connector is the intended exception, and it is not yet released. The connector is the controlled way in for a practice's own AI assistant and tools, and it is being built with its own access log, so that every retrieval and every filing made through it would be recorded against the practice's connector credential, with the time and what was read or filed. A connector credential would reach only its own practice's records. A connector guide will set out how to use AI on patient information while keeping it in Australia and out of model training, and the terms will place responsibility for where retrieved information goes with the practice that retrieved it.
While your subscription is active, your records are kept. Nothing ages out and nothing is pruned.
If your subscription ends, your records are held for a further twelve months before they are destroyed. You are prompted during that period to take a copy, and you are given one. The intent is that no practice can reasonably say its records were held to ransom, and equally that SurgiHub does not become the indefinite unpaid custodian of a departed practice's records.
Our twelve months is a handover window, not a substitute for your own record-keeping. Medical record retention in Australia is a legal obligation measured in years, and it rests with your practice, which is why the final export comes with an acknowledgment that the obligation has passed to you.
Templates and pathways remain the property of the practice that built them. The education material you write, the procedure templates you configure and the pathways you design are yours, not ours. SurgiHub acquires no right to reuse or redistribute them, and a surgeon leaving a group practice does not take the library with them.
Your practice is not deleted, because these are health records. Access closes, the data remains intact, and for twelve months at no charge you may ask us for a complete export: patients, procedures, consents, files, conversations, templates, everything. At the end of that period we deliver a final export, you acknowledge that the record-keeping obligation now rests with you, and our copy is destroyed. If you would rather we kept the archive, that is available for a modest annual fee.
One thing worth saying plainly about the mechanism: the export is produced by us on request rather than by a button you press yourself. It is a commitment in our terms rather than a screen, and the commitment is what protects you.
SurgiHub is the data repository, not the arbiter. A departing surgeon receives nothing directly from the system: removing their membership ends their access, and there is no self-service takeout for them to use on the way out. There are two doors and only two. The practice owner may ask us for an export confined to one surgeon's patients, and may choose whether to hand it over; whether they are obliged to is a matter for your partnership agreement, not our software. Separately, any patient may direct that their own record be sent wherever they choose. Patients hold that right under Australian privacy law regardless of what any practice would prefer, so it exists as a proper function rather than a favour.
SurgiHub is operated in Australia by Surgihub Pty Ltd (ACN 701 392 770), which is the entity that holds your practice's data and the entity accountable for it.
SurgiHub's privacy policy is published here and within the app. It sets out what personal and health information is collected and from whom, the purposes it is used for, that SurgiHub handles it on the instructions of the practice, who it is disclosed to including every overseas recipient, how long it is kept, how a person seeks access to or correction of their information, and how to complain.
SurgiHub holds itself to the Australian Privacy Principles. Your practice remains the entity with the primary relationship to its patients, and SurgiHub handles their information on your behalf and on your instructions. That division of responsibility is set out in the terms as well as here.
Because chat content is held in the United States, patient health information is disclosed outside Australia. That disclosure is named in the privacy policy, and SurgiHub remains accountable for how the information is handled by the overseas service under its contractual position with CometChat.
Any suspected breach is assessed promptly, and every affected practice is notified without undue delay and with enough detail to meet its own obligations to its patients. Where a breach is likely to result in serious harm, SurgiHub notifies the Office of the Australian Information Commissioner and affected individuals as the notifiable data breaches scheme requires. Practices are told even where that threshold is not met, because a practice would rather hear it from us than not at all.
SurgiHub holds no security certification of its own and does not claim one. Its two main infrastructure providers do: AWS for hosting, and CometChat for chat as set out above. A supplier's certificate is not ours, and this page will keep making that distinction.
Two services hold your practice's data: Amazon Web Services, which hosts the database and your files in Australia, and CometChat, which carries and stores chat in the United States. Behind them sit the ordinary delivery services any application needs, being SMS, system email, push notifications and card payment for the subscription. We will give you the full list, naming each one and what it handles, on request. Two points worth making without being asked: SMS and system email are handled by Amazon's own services, so invitation text and next-of-kin updates do not leave the AWS boundary; and push notifications carry no patient name and no clinical detail, because their text passes through the Apple and Google notification services on the way to a phone.
Security and privacy enquiries go to admin@surgihub.com.au, which is read by a person. A straight answer, including "not yet", is more useful to both of us than a brochure.
Start a free trial and set your own templates up — every feature is available from the first day. If you would rather be walked through it, we'll come to you.
Register for your free trial or book a demonstration →