Privacy Policy

Last updated: 24 October 2026

Who we are

HyperCRM is practice management software operated by Hypermetron, the company behind it. Hypermetron is the entity your practice contracts with and the entity that invoices you, and it is the data controller for your billing and account relationship; your practice remains the controller of its own clinical records, with us as processor. For any privacy question, or to request our full legal entity and registration details, write to hello@hypercrm.app — a person answers.

We have not appointed a formal Data Protection Officer. Privacy requests go to the address above and are handled by the team that builds the product, not a ticket queue.

The two roles we play

This is the most important distinction in this policy, and it follows from how the product is built:

• Your patients' clinical data — your practice is the controller, we are the processor. Patient records, notes, appointments, uploaded files, imaging and invoices belong to the practice that entered them. We process them only to run the service, on your instructions. The Data Processing Agreement sets out those terms.
• Your account data — we are the controller. What we need to operate the service itself: staff names and email addresses, sign-in credentials, and any support correspondence. This policy governs that.

What we collect

Account data. Staff names and email addresses, passkey (WebAuthn) credentials, and the content of messages you send us. A member who signs in with a password or an emailed link does so through our authentication provider, Google (Firebase), which holds and checks the password; we never see or store it. Each person has their own login, so there is no shared practice password.

Practice data, on your behalf. Patient demographics, clinical notes, intake and consent responses, uploaded documents, imaging and 3D scans, appointments, invoices and the referrers you record (name, kind, phone, email and your notes). An uploaded image is resized to fit 2560 pixels, converted to WebP and stripped of its metadata on the way in, and the original file is not kept; PDFs and 3D scans are stored exactly as they arrive. This can include health data, which is special-category data under GDPR Article 9. We do not decide what goes in — your practice does.

Technical data. Server logs and security signals needed to keep the service running and to investigate abuse.

Phone calls, only if your practice uses the phone assistant. When someone rings a practice whose line HyperCRM answers, we keep the caller's number and a summary of the call written in fixed sentences we wrote, never in the caller's own words. We keep no audio and no transcript. The summary is deleted after 90 days. If the call becomes a booking, the patient's name, email and callback number go onto the appointment like any other booking. The call itself is heard live by our AI provider, outside the EU until data residency is in place for it, and the sub-processors page says who carries it.

Calendar connections, only if a practitioner turns them on. A practitioner can send their own appointments to a calendar of their choice. If they connect Google, we keep an encrypted refresh token (a long-lived key that lets us keep that calendar up to date), the email address of that Google account, and the id of the calendar we create there. If they use a private subscription link, we keep only a one-way hash of the link, never the link itself. Each event carries the patient's name, the service, the time, the chair or room, and, for a practice with more than one location, that location's name and address, plus a link back into HyperCRM that opens only after sign-in. A booking request that the practice has not yet confirmed shows "Booking request" and the service, without the patient's name. That is practice data, sent on your practice's instructions under the Data Processing Agreement.

Two fraud signals, and only if you use a referral code. Our referral programme pays a practice for recommending us, so it has to be able to tell a real recommendation from a practice referring itself for the reward. Where a practice signs up with a referral code we record two things about it, both described in full below:

• The IP address the signup came from, kept for 90 days. A code entered later in settings records no IP at all — only the signup itself does.
• A card fingerprint, once that practice starts paying. This is worth being precise about: a fingerprint is an opaque token Stripe gives us that identifies a card without revealing it. It is not a card number. We never see, receive or store your card number, expiry date or security code — those go straight to Stripe and stay there. The fingerprint's only use is comparing one referral against another, to see whether the same card is paying for both sides of a referral that claims to be between two independent practices.

Cookies and tracking

We run no advertising trackers. We do use one third-party analytics tool on this marketing website, and nothing of the kind inside the application. Sign-in uses short-lived bearer tokens rather than a tracking cookie. Three things set or store something, and all three are named here rather than left in a footnote:

• Google Analytics, through Tag Manager, on this marketing website only: which of our pages get read. It loads in a mode that stores nothing until you accept the cookie banner, and it is not present in the application, where it would be able to see a patient. Listed at sub-processors with everything else.
• Your answer to the cookie banner, remembered in your own browser so you are not asked again on every page.
• Google reCAPTCHA sets its own cookies on public booking and form pages, where it tells a person from a bot.
• hc_ref, which we set ourselves, if you arrive on this site by a referral link. It is first-party, lasts 90 days, and holds one thing: the referral code that was in the link. It exists because a clinician may follow a colleague's link days before signing up, and without it that recommendation is lost. It is sent to no one else and shared with no one. Until a practice is actually created it identifies nobody — it records that a code was followed, not who followed it — and it is read once, when someone finishes setting up a practice.

Why we are allowed to process it

Account data is processed to perform our contract with your practice, and on our legitimate interest in keeping the service secure. Clinical data is processed solely on your practice's documented instructions — your practice is responsible for its own lawful basis and, for health data, its own Article 9 condition.

The two referral fraud signals rest on legitimate interest, and we would rather name the interest than hide behind the phrase: a referral programme that cannot detect a practice referring itself pays out money it should not, and that money comes from the price everyone else pays. Both signals are limited to that purpose — they are never used to profile you, to market to you, or to work out where you are. You can object to either, at the address above; the referral is then decided without them.

Who else touches it

We do not sell personal data and we do not use your patients' data to train machine-learning models.

An AI app one of your team connects is a recipient you chose, not a sub-processor of ours. A member can connect an outside app, such as Claude or ChatGPT, to their HyperCRM account; that app then receives whatever patient data the member asks it about, under the member's own agreement with it and within their role's permissions. It is the same position as a calendar a practitioner connects: your practice stays the controller and decides whether it is appropriate.

We do share it with the service providers that make HyperCRM work. Every one of them is listed at sub-processors, along with what it handles and when it runs — six run for every practice, three only where you use SMS reminders or the phone assistant, and Stripe runs once your practice is on a paid plan. Beyond that list we disclose data only where the law compels us.

Some of those providers are based in the United States, so data reaches them there. They offer the standard transfer safeguards for EU data — Standard Contractual Clauses and, where applicable, EU–US Data Privacy Framework participation. If you need the transfer mechanism documented per provider for your own compliance file, ask us and we will provide what we hold.

Calendar sync goes where your practitioners choose. When a practitioner turns it on, their appointments go to their own Google account, or to whatever calendar app they subscribe with, such as Apple Calendar or Outlook. That provider is not our sub-processor. It acts under the practitioner's, or the practice's, own agreement with it, and it may hold data in the United States. Each practitioner decides for themselves whether to turn it on, and the practice owner can see in Settings → Team who has. Your practice remains the controller, and is responsible for telling its team when this is or is not appropriate for its patients. Anyone who holds a private subscription link can see those appointments, so it should be kept like a password. We read nothing back from these calendars.

How we protect it

In summary: a personal login for everyone with passkeys available, owner and staff roles, an audit log of every change to a record, private file storage reachable only through short-lived signed links, and encryption in transit and at rest. The security page explains each of those properly.

How long we keep it

While your account is open, we keep your data so the service works. After an account closes we keep it for 30 days so an accidental closure is recoverable and you have time to export, then we delete it.

A subscription lapsing is not a closure and deletes nothing. If you cancel, or simply stop paying, the account becomes read-only and we keep your data — indefinitely, with no timer running against you — because clinical records carry retention obligations that are your practice's and an unpaid invoice is not a reason to destroy them. Once a year we email the account owner to say the data is still there and to give the export link and the route to close. The deletion clock starts only when you close the account, which is always something you do deliberately.

The two referral fraud signals have their own, shorter limits, and they are enforced by a nightly job rather than by this paragraph. A signup IP is erased 90 days after the referral was recorded, whatever state that referral is in. A card fingerprint is kept only for the life of the referral record and goes when that record does, with the account it belongs to; the referring practice's own fingerprint is read at the moment of the comparison and never stored at all.

A record of each email we send is kept for 90 days. For every email the service sends or tries to send, we keep which kind of email it was, whether it went, the address with everything but its first letter and its domain hidden, the practice it was for, the account it went to when it went to one of our users, and the message id our email provider gave it. It never holds the subject or the content. We keep it so we can answer "did that email go out?", and a nightly job deletes each record after 90 days.

A phone call's summary is kept for 90 days, and the caller's number with the call row it belongs to. There is no audio and no transcript to keep. A booking made on the call is an appointment from then on, and lives as long as the rest of your practice data.

Calendar connections are deleted when they end. When a practitioner disconnects Google, is removed from the practice, or the account closes, we delete the HyperCRM calendar from their Google account, then the token and our records of it. If they had already removed our access in Google, they need to delete that calendar there themselves. When a patient is erased, we remove their name from their synced events in Google. If the practitioner's connection needs reconnecting at that moment, the name is removed once they reconnect. Apps that use a private link drop the name the next time they refresh. Copies the calendar company keeps itself, such as event history or notification emails, are outside our control. A private link that is turned off stops showing anything at once, and we delete its hash after 90 days.

Two caveats worth stating plainly. Clinical records are often subject to a legally mandated minimum retention period in the country where a practice operates — that obligation sits with the practice, and you should not rely on our recovery window to satisfy it. Export before you close. Backups roll off on their own cycle shortly after deletion.

Your rights

You may have rights to access, correct, delete, restrict, port or object to processing of your personal data.

If you are a patient, not a practice

You may have arrived here after booking with a practice on a website HyperCRM built for it, filling in one of its forms, or speaking to the assistant that answered its phone. In all three cases the practice holds your record and decides what happens to it; we run the software for them and act on their instructions. So the questions people usually want answered are the practice's to answer: what they hold about you, how long they keep it, and whether they will delete it. Ask them, and they can reach us if they need to.

What is ours to tell you: your details go to the practice you contacted and to the providers listed at sub-processors, and nowhere else. We do not sell anything, and we do not use what you write to train AI models. If you rang a practice and spoke to its assistant, there is a note on what is kept from that call under "How long we keep it" above.

For clinical data, your practice is the controller: patients should ask their practice, and we will help the practice answer. For account data, write to us at the address above. Beyond any legal right, practice data is exportable whenever you like — your patient list, your reports and the activity log to CSV, every file downloadable, no fee and no waiting period.

If you think we have handled your data badly, tell us first — but you are also entitled to complain to your national data protection authority.

Children

HyperCRM is a tool for clinics, not a service for children to use. Patients may of course be minors, and their records are entered by the practice under the practice's own lawful basis and consent processes.

Changes

This policy will change as the product does. The date at the top always reflects the current version, and we will tell account holders by email before a material change takes effect.