01
The inventory
Everything the system stores about a client.
A clinic asking this question deserves the list, not a reassurance. Here it is, kind by kind.
Identity and contact
Salutation, full name, mobile, email, date of birth, postal address, a free-text staff remark, marketing preferences for email and texts with where and when each was given, and whether the client is active.
Around the record
Household wallet and referral links, booking requests (including from people who aren't clients yet), the activity trail of who did what, staff notes on payments, Instagram names, handles and messages, gift voucher buyers' and recipients' details, and anything imported from your previous system.
The health record
Sixteen yes/no condition flags — allergies, asthma, diabetes, epilepsy, heart condition, pregnancy, recent operation and the rest. Three free-text fields: other health concerns, current medications, and previous intensive treatments. Skin type and preferred pressure. And a photo-publication preference with three settings — No, With eye, Without eye — which governs whether an identifiable image of a client's face may ever be published.
Treatment consents
A consent list your clinic edits, and a record of which consents a client has given and the date each was given. Where a clinic has consent forms on, every version of each form, and each signed form: the client's answers, any warnings they raised, their initials and signatures, and the signed PDF.
Images and documents
Before-and-after photographs filed against the visit, scanned consent documents, signature images, and rendered signed-agreement PDFs.
Signed agreements
A snapshot of exactly what the client was shown, a pointer to the versioned wording they agreed to, the signature, the staff member who raised the request, which enrolled tablet captured it, and the moment it was signed.
The visit record
Date, time, therapist, treatment and product names, a per-visit note for anything the team should know, a late-arrival flag with minutes, and visit status.
Money and balances
Store credit as expiry-dated lots, loyalty points and tier, prepaid courses of treatments and units, gift vouchers, deposits, and payments recording the method, the card's last four digits, the scheme, the authorisation code and the terminal receipt text. Where a clinic has Retail on, a client's product orders too: the items, their prices, and whether each order is held, paid or collected.
Messages
Full Instagram direct-message threads — text, attachment references, reactions and read state — stored beside the clinical record. The media files themselves stay on Meta's servers.
Staff
Display name, email, mobile, role and the date the account was created.
What never enters the system
Card numbers. The card is read by the payment terminal or by the processor's own hosted page. What comes back to us is the last four digits, the scheme and an authorisation code — never a number anyone could charge.
What we deliberately don't log
Recipient email addresses are kept out of the application's mail logs — the template and the outcome are recorded, not who it went to.
02
Access
Permissions that fail closed.
The question behind the question is usually "can my receptionist read a client's medical history?" Here is how the system decides.
Closed by default
Any part of the API that does not explicitly name the roles allowed to reach it is administrator-only. Forgetting to write a rule locks a door rather than leaving one open.
Role comes from the session
A person's role is read from their signed sign-in token, never from anything their browser sends. A staff member cannot ask to be treated as an administrator.
Unexpected fields are refused
A request carrying a field the endpoint did not ask for is rejected outright rather than quietly ignored — which is what keeps narrow write permissions narrow.
The client app sees eight fields
Your clients' own app is served a hand-written list of eight profile fields and no health information at all — no medical history, no consents, no staff remark, no wallet bookkeeping.
Two front desks, no clobbering
A record someone is editing is locked while they hold it, and a save that began from stale data is refused rather than applied over the top.
Signing tablets carry no account
A tablet is enrolled once with a single-use code that expires in fifteen minutes. Its credential is minted on the server, never displayed, stored only as a hash, and revocable on its next request.
We can see it too
Morning Room can reach your records, and you should know how. When you ask us for help, a named Morning Room person may be given a staff login in your clinic, with the access that role carries; ask and we remove it. Our engineer can reach the hosting account that runs the service. Neither is used for anything except answering you and keeping the service running.
03
The trail
Who did what, and when they did it.
A clinical and financial record is only as good as your ability to say afterwards who touched it. Corrections are recorded as corrections — nothing is quietly rewritten.
The name on the entry is real
The staff member stamped on a ledger entry is resolved from their signed-in session — not chosen from a dropdown, not sent by the browser. An audit trail cannot work the other way.
Read-only over the API
There is exactly one endpoint that reads the activity trail, restricted to administrators and managers, and none anywhere that edits or deletes an entry.
Retracted, not erased
A payment keyed in error stays on file marked Voided and out of the totals, with the note appended to rather than cleared, store credit returned and any voucher reactivated — all in one transaction.
Merges leave a manifest
Joining two clients into one household wallet writes down everything that moved, and can be reversed exactly — credit lot by lot with its original expiry dates — while nothing has been touched since.
A signed agreement is pinned to what the client saw
Not a tick and a date. The record holds a snapshot of everything displayed on the tablet, a pointer to the versioned wording, the signature image, the rendered PDF, the moment of signing and which enrolled tablet captured it. Signing is a one-way transition, so a double-tap cannot double-sign, and a signed agreement is never discarded when the purchase behind it is removed.
04
Storage
Where the photographs actually live.
Encrypted on write
Photos, consent scans, signature images and signed PDFs are written with AES-256 encryption and no public-read permission — including on the path that re-files a photo library, so moving a photo never silently drops it.
Short-lived links only
Files are read back through links the API mints after checking the caller's role. They expire after fifteen minutes by default, and the front-desk app never holds a permanent address to a client's file. Product photos and suppliers' leaflets, which hold nothing about a client, are on a public address.
Filenames can't escape
An uploaded filename is sanitised before it becomes part of a storage key — anything containing a slash or a parent-directory hop is rejected.
Credentials aren't in the app
The record itself lives in a managed PostgreSQL database, reached with credentials supplied by the environment rather than written into the software.
Being straight about one thing
A short-lived link is a bearer link. The permission check happens once, at the moment the link is minted — so for as long as it lives, anyone holding it can fetch that file. That is exactly why they are short, and why the front-desk app is never given a permanent address to a photograph.
Morning Room clinics are hosted in Sydney, Australia (AWS ap-southeast-2).
The servers, the database, the files and the model behind AI match are all there. A few services may handle data outside Australia: Google's Firebase, for sign-in and push notifications; Anthropic's Claude, which reads a consent form you upload into a draft; and the address lookup at the front desk. The table below says what reaches each.
05
Sub-processors
Everyone else who touches it.
Running a clinic on any software means other companies handle some of the data. Most vendors make you ask. Here is the list, and what actually reaches each one.
Who
What for
What reaches them
Health or identifying
Amazon Web Services
Hosting, database and file storage
Everything — the clinical record, photographs, scanned consents, signed PDFs, message threads and money records
Both
Amazon SES
Reminders, confirmations, statements, payment requests, vouchers, signed agreements, shop orders and email campaigns (on the way)
Client name, email address, appointment details and treatment names
Both — a treatment name reveals health
Firebase Authentication
Staff and client sign-in
Staff email addresses; client mobile numbers. Google may store these outside Australia
Identifying
Firebase Cloud Messaging
Push notifications to the client app
Notification text: appointment times, amounts and order numbers, never a treatment, and a per-device token. Google may handle these outside Australia
Identifying
Meta · Instagram
The direct-message channel
The whole conversation, by definition — anything typed into it. Inbound media never leaves Meta's servers
Identifying; health if typed
Windcave
Card payments, online and at the terminal
Amount, currency, your clinic's name and internal booking and payment references. No client name, no treatment. Card details go to them, never through us
Neither
MultiTXT
Reminder, confirmation and payment-request texts
Client mobile number and the message body from your own template
Identifying
Google Places
Address autocomplete at the front desk
The address text as a staff member types it, from their browser
Identifying
Photon (komoot)
Address suggestions at the front desk, for a clinic without a Google key
The address text as a staff member types it, from their browser, to a service in Germany
Identifying
Xero
Your clinic's own Xero, only if you connect it
Each day's takings as one journal: amounts under your account codes, with counts such as "14 visit payments, 2 packages sold". No client names, no treatment names
Neither
Anthropic
Reading a blank consent form you upload into a draft, only if you use consent forms
The blank form you upload: a PDF, a Word file's text or a photo of a page. No client's answers, record or name. Handled outside Australia
Neither
Google Fonts
The typeface in clinic emails and the staff handbook
The reader's IP address and browser, when an email is opened
Identifying
Google reCAPTCHA
Bot checks during client app sign-in
Signals from the device and browser signing in
Identifying
Nager.Date
New Zealand public holiday dates
The year and the country. Nothing about anyone
Neither
This list is reconstructed from what the software actually calls, and we update it when the software starts calling something new. Ask and we'll send it to you as a document. If your clinic turns a channel off — no Instagram, no texts — that row stops applying to you.
06
Absences
What isn't in the building.
Some of the strongest things you can say about a system holding health data are the things it doesn't do.
No trackers
None of the four applications ships an analytics tool, an error-reporting service or a session-replay recorder. No page pulls a tracking script.
No client data to AI
AI match's model runs inside Morning Room itself. The one outside AI, Anthropic's Claude, reads only the blank consent forms a clinic uploads to import, so no client record, message or note is sent to any AI service, and nothing is trained on them.
The kiosk talks to nobody
The signing tablet reaches your own clinic's Morning Room servers and nothing else, and its fonts are bundled.
No card numbers
They never enter the system, so there is nothing here for anyone to steal and nothing for you to be liable for.
No names to the processor
What the card processor sees is an internal record number — a payment-request number, or a visit number at the terminal. Not a person.
No passwords stored
There is no password column and no password hashing anywhere in the system. Sign-in is handled entirely by the identity provider.