Responses via the iPad app responses are always processed (i.e. sent to your PMS) automatically — without any further steps on your part. That's because, at the time they're started, we already know the appointment, patient & practitioner.
Responses captured via the web, on the other hand, trigger a search in your PMS for any patient that matches the entered information (unless they're identity-verified of course — the patient is already known in that case). After that, the system looks at your Inbox settings to determine if we should process the response through to your PMS automatically.
This article dives into the details of how it works, and in which situations automatic processing cannot occur.
How we match
Previously, we'd try to perform an action on the patient that most closely matched the response. This worked well most of the time, but this would cause issues sometimes (e.g. updating a parent's record with a child's information).
Because identity-verified forms are now the preferred way of ensuring that forms are processed automatically to the correct patient with certainty, we've reduced how aggressively we perform automatic processing on public web responses.
Since June 2026, patient matching on public form responses works as follows:
We look for an existing patient whose details match the response exactly. A confident match is either:
an exact first and last name, plus a matching date of birth, email, or mobile number, or...
an exact first and last name alone, when the patient's record has no date of birth, email, or mobile to check against. Whatever of those details the response does carry is saved onto the record, so their next response matches with certainty, or finally...
an exact first name, plus a matching date of birth, plus a matching email or mobile number — and a very close surname. In this case we'd assume this surname to be a typo so it won't stand in the way of an automatic update.
When comparing names
Preferred names count — If the patient's record is under Johnny and they enter Jonathan with preferred name Johnny — or the other way around — that's still an exact name match. We check the name and preferred name / nickname fields on both the response and the record.
Formatting doesn't matter — Capitalisation, accents, apostrophes, hyphens and spacing are ignored. E.g. O'Brien and OBrien, or Anne-Marie and Anne Marie, are considered the same.
Close names are never guessed — A close-but-different first name (e.g. Aidan vs Aiden) is never updated automatically.
What happens next
Exactly one confident match → the response updates that patient.
No match at all → a new patient is created.
Anything less clear-cut → the response is left in your inbox with the candidates we found, for you to pick the right patient (or create a new one). This happens when:
more than one patient could match
the name matches, but the patient's record has identifying details (a date of birth, email, or mobile) that the response didn't include
the name matches, but a detail we could compare didn't agree (say, a different email address)
the first name is close-but-not-exact to a patient who agrees on surname and date of birth or contact details — likely a typo or a preferred name, possibly a sibling, so we ask you
the first name is different, but the surname, date of birth and contact details all agree
A patient whose details contradict the response — a different date of birth, or a clearly different first name with nothing else lining up — is treated as a different person, and a new patient is created.
This means that there may be a few more responses sitting in your inbox awaiting processing, but it also means the wrong patient will never be updated accidentally.
When responses are sitting in your inbox, you can see their matches below the summary of the form, like this:
When there are no matches
If there were no matches found for the Response, and automatic processing is enabled, then automatic processing will schedule a new patient to be created.
☝️ Sometimes automatic processing can't occur. In these instances the Response is kept in the Inbox with an error message showing, and notification will be sent out to whoever should receive them. From there, it will need to be processed manually.
Automatic processing doesn't always occur
Sometimes automatic processing of public web form responses can't occur. For instance, if it's not enabled in the Inbox settings. There are a couple of other special cases worth mentioning.
Practitioner Signatures
When a practitioner signature is required on a Response, automatic processing cannot proceed.
Treatment Notes
Forms are configured to create a draft Treatment Note by default during their processing:
Because only practitioners can create Treatment Notes in Cliniko, we need to use on of your connected practitioner API keys to create the Treatment Note from the Response. For iPad app Form filling, we already know the practitioner, so this is easy enough to do.
If we have a next appointment
For public web form responses, we do an extra check for the patient's "next appointment" during the matching process. The image below shows a next appointment that's been found for a particular match.
If we find a next appointment, and we have a connected API key for the practitioner on that appointment, we know we can use the practitioner from that appointment to create the Treatment Note, and thus automatic processing can go ahead.
If we don't have a next appointment
In the case that we don't have a next appointment, and a Treatment Note should get created, then the Response will still be processed automatically if you're the only practitioner in your clinic:
If there's more than one practitioner in the clinic, a Treatment Note needs to be created, and there's no next appointment, then automatic processing will not occur.
Sometimes workflow is skipped
When a Treatment Note is to be created, and we know which practitioner to use to create the Note, but they don't have their API key connected via the Finger-Ink portal, treatment note creation will be skipped.
This can still be performed manually at a later date, and you'll get notified via email when/if this happens.