Privacy policy

1. Who we are, and who is responsible for what

Careforms is operated in Australia and is bound by the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs).

When a disability or aged-care provider ("the Provider") uses Careforms to collect intake information from a prospective client, the Provider is the entity collecting that information. Careforms is the software that carries it from the client to the Provider. We do not retain a copy — see section 3.

2. What we collect from providers

Account information, which we do store:

• Business name, ABN, mailing address and support phone number.
• Administrator email address, used for sign-in and for delivering submissions.
• An optional logo, held in Cloudflare R2 object storage in the APAC region.
• Your form configuration: which questions you've switched off and any wording you've changed.
• Sign-in records: hashed session tokens, hashed magic-link tokens, and the IP address and browser user agent of sign-in requests, for account security.
• An audit log of administrator actions, such as issuing or revoking a link.
• Billing details are held by Stripe, not by Careforms. We store only the Stripe customer and subscription identifiers and your current plan status. We never see or store card numbers.

3. What we collect from people filling in one of our forms

A Provider can put three forms in front of somebody, and what is collected depends on which one:

• An enquiry form, published at a web address the Provider can put on their own website or a flyer. Four to six questions: a name, how to reach somebody, and what they are looking for. Anyone can open it and nobody is sent a link, so the person filling it in need have no existing relationship with the Provider at all.
• An intake form, sent to a prospective client as a single-use link. This is the long one. A completed intake contains identifying details, contact details, NDIS information where applicable, health-adjacent information the Provider needs in order to deliver safe support, and consent declarations.
• A first-visit form, sent the same way, asking a few things a Provider needs before a first appointment.

Careforms does not retain any of it. Whichever form it was, when somebody submits it their answers exist only in memory for the duration of that single request. Within that request we send them to the Provider and — if an email address was given — send a copy to the person who filled the form in. The answers are then discarded. Nothing is written to our database, and nothing is written to our file storage.

For an intake or first-visit form we also render a completed PDF inside that same request, and it is what both emails carry. An enquiry form produces no PDF at all — a handful of questions and a phone number do not need a document, so none is made and none is attached to either copy.

The Provider chooses what accompanies their copy. In addition to the PDF, wherever there is one, they may switch on a JSON file and a spreadsheet (CSV) row; both contain the full text of the answers, and both are produced in that same request and kept by nobody but the Provider. The Provider also chooses where their copy goes: their sign-in address always receives it, and they may add up to three further addresses of their own, each of which must confirm from its own mailbox before anything is sent to it.

Providers on our Elite plan may additionally nominate a webhook — an address in their own systems that we post the same JSON to as the submission is processed. We attempt this at most twice, within the same request, and we do not retry afterwards, because we hold no copy to retry from. Where a Provider uses a webhook, they decide what the receiving system does with the information and where in the world it is held; that disclosure is theirs to make and to describe in their own privacy notice, not ours.

The consequence, stated plainly: once the request finishes, the only copies of a client's answers are the ones held by the Provider and the one in the client's own inbox. We cannot retrieve, resend, export or produce them, because we do not have them. That is true regardless of which formats or destinations a Provider has chosen — those change who receives a copy, never whether we keep one.

One copy can exist outside those two emails, and it is on the person's own device. While an intake or first-visit form is being filled in, the answers entered so far are saved in that browser's local storage, so that closing the tab or losing signal does not cost someone the whole form. It never leaves the device and is never sent to us except as the final submission.

That draft is removed as soon as the form is successfully sent. If a form is never finished, the draft is discarded once the link expires — and the form offers a “Clear saved answers” control at every step for anyone who wants it gone sooner, which matters most on a shared or borrowed device. Clearing the browser's site data removes it too.

An enquiry form saves nothing on the device. The draft belongs to a link, and an enquiry has none, so there is no draft to clear and nothing left behind — which matters most on exactly the surface a person is most likely to be using somebody else's phone to reach.

Because the enquiry form is open to anyone, some submissions of it are asked to complete a challenge — a small “confirm you are human” check from Cloudflare Turnstile. To score it, the submitter's IP address is sent to Cloudflare along with the answer to the challenge. It is used to decide whether that one submission is automated and is retained by neither Cloudflare on our behalf nor by us. No challenge runs on an intake or first-visit form, which is behind a link instead.

4. What we retain about a submission

For each submission we keep one record. It contains no name, no contact details and none of the answers — those exist only in the two emails and are never stored by us. The record contains:

• Internal identifiers: submission ID, event ID, the Provider's account ID, and the ID of the link used — which is empty for an enquiry, because there was no link.
• Which form it was: enquiry, intake or first visit.
• The time of submission, and the person's own device timezone and clock reading.
• Coarse request metadata: country, network operator (ASN), the Cloudflare data centre and ray ID, browser user agent, accept-language, and the page and site the request came from. We do not retain the submitter's IP address, city or region.
• Whether a document was produced for this submission or not.
• The funding type and services the form was for, and whether the client or a representative completed it.
• Email delivery status for each recipient, how many attempts it took and when the last one was made. Recipient addresses are not recorded.
• Where the Provider uses a webhook: whether that delivery succeeded, how many delivery attempts were made and the HTTP status their system returned. Neither the address nor anything their system sent back is recorded.
• SHA-256 hashes of the submitted content and of the record itself, so the Provider can verify that what reached them has not been altered. The content hash is printed on the PDF itself, so it is available whether or not they receive the JSON file.
• A one-way HMAC fingerprint of the email address and phone number given, keyed with a secret unique to that Provider. This lets a Provider see that the same person submitted twice. It contains no part of the address or number, and fingerprints cannot be compared across Providers.
• Where that fingerprint came from: whether the address was typed in by the person filling the form, or was the address the Provider sent the link to. It is a single word about provenance and never an address.

We describe these records as pseudonymised rather than de-identified, and the difference is worth stating plainly. The fingerprints are not reversible by anyone who obtains them on their own — but the key that produces them is held by us, alongside them, so we could confirm whether a particular address or number appears in a Provider's records. Nobody else can, and neither we nor the Provider can read an address or a number out of the record itself.

5. Why we collect it

So Providers can issue branded intake forms and receive a tidy record without paper or spreadsheets. So we can deliver and bill for the service. So there is a tamper-evident trail for dispute and incident response. We do not sell personal information, do not share it for advertising, and do not use client-intake content to train AI models.

6. Where it lives

The account database runs on Cloudflare D1 in the Oceania region. Object storage is Cloudflare R2 in the APAC region and holds Provider logos only. Email is delivered by Resend, which processes the message — including the completed PDF and JSON attachment — in transit. Payments are processed by Stripe. Submissions of the public enquiry form may be scored by Cloudflare Turnstile, a distinct Cloudflare product with its own processing, as described in section 3. Careforms itself runs on Cloudflare's global edge network.

7. How long we keep it

• Client intake answers: not retained at all (section 3).
• Pseudonymised intake and first-visit records: retained for the life of the Provider's account, as the audit trail for links they issued. They are the only record that a form was completed, so they go when the account does and not before.
• Pseudonymised enquiry records: deleted 400 days after the enquiry. An enquiry is not a link anybody issued and not an intake that happened — somebody asked a question and may never have become a client — so it is not held for the life of an account they have no relationship with. The window is a little over a year rather than exactly one, so that a Provider can still see that somebody enquiring this March is the same person who enquired last March.
• Sign-in tokens: magic links expire after 15 minutes and are purged after 24 hours. Sessions expire after 30 days and expired rows are purged.
• Billing webhook payloads from Stripe: purged after 90 days.
• Records of administrator actions (who issued or revoked a link, and when), which include the administrator's email address, IP address and browser: purged after 400 days.
• Provider account data: retained while the account is open. On closure, contact us and we will delete it. That means deleted, not deactivated: the account record, every link, every pseudonymised submission record, the administrator's sign-in history, our copy of Stripe's billing notifications, and the per-account key described above. Destroying that key is what makes the fingerprints unreadable everywhere rather than only here, because it is the only thing that could ever have read them. Links already sent to clients stop working. What survives is one line recording that an account was closed and when, containing no name, address or IP.
• Accounts that were never subscribed: if a sign-up is never completed with a subscription and no link is ever issued, we close the account after 90 days and release the web address it reserved.
• Closed accounts: deleted 30 days after they are closed, however they were closed, on the same terms as above. The gap is deliberate — for that month a closure can be undone if it was a mistake, and after it there is nothing left to undo it with. Nothing stays closed indefinitely.

Providers are responsible for their own record-keeping obligations — including the seven-year retention expected under the NDIS Practice Standards — over the copies in their own systems. Careforms is not a system of record for those obligations.

8. Your rights

Under the Privacy Act you may request access to, or correction of, personal information held about you.

If you filled in one of our forms: contact the Provider it was for — the business whose name and logo were on it. They hold your submission; we do not. We cannot provide you a copy of your answers, and we cannot delete them from the Provider's records on your behalf. That is the same answer whether they sent you a link or you found their enquiry form yourself.

If you are a Provider: email support@careforms.com.au to access, correct or delete your account information.

9. Notifiable data breaches

We operate an incident-response process aligned with the Notifiable Data Breaches scheme. In an eligible breach we will notify affected individuals and the Office of the Australian Information Commissioner as soon as practicable, and in any case within 30 days of becoming aware.

10. Contact

Email support@careforms.com.au. If you are not satisfied with our response you may complain to the Office of the Australian Information Commissioner at oaic.gov.au.