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
When a form response comes in via the public URL, we try to match it to an existing patient and process it automatically — updating that patient, or creating a new one when there's no match.
☝️ Responses filled in the app, and identity-verified forms, always process to the correct patient with certainty, so the below applies only to public web responses.
You can now choose how forgiving this matching is in inbox settings:
Relaxed (the default) — updates the closest matching patient, even when a detail or two isn't a perfect match.
Strict — only updates when the details line up exactly.
Whichever you choose, when we can't be confident the response is left in your inbox with the candidates we found, so you can pick the right patient (or create a new one).
Relaxed matching (the default)
Relaxed updates the closest matching patient even when the response isn't a flawless match. It will still match through:
a mistyped email, or one missing its .com.au
an added middle name, or given names in a different order
a mobile number written in a different format (e.g. +61… vs 0…)
A few things worth knowing:
An exact first and last name is enough on its own. Even if the form only asked for a name, we'll update the matching patient.
A date of birth that looks like a typo — off by a day, a transposed digit, or a swapped day and month — updates the patient and corrects the date rather than creating a duplicate. So does any differing date of birth when an email or mobile number matches, since the contact tells us it's the same person.
A surname typo, or a changed surname (for example after marriage), is fine — as long as enough else lines up.
A close-but-different first name is matched only when other details agree too; on its own it's left for you to decide.
A clearly different first name is treated as a different person, and an exact-name match is always shown to you for review rather than quietly duplicated.
Because relaxed is more forgiving, it can occasionally update the wrong record — for example a relative who shares a surname and contact details. This is why we recommend turning on backups, which let you undo a processing mistake.
Strict matching
Strict only updates a patient when the details match 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 details the response does carry are saved onto the record, so their next response matches with certainty, or finally…
an exact first name, a matching date of birth, and a matching email or mobile number — together with a very close surname. In that case we assume the surname is a typo, so it won't stand in the way of an automatic update.
Anything less is left in your inbox, so the wrong patient is never updated automatically. An added middle name, or given names in a different order, is held for you to confirm — never turned into a duplicate. And a close-but-different first name (e.g. Aidan vs Aiden) is never updated automatically.
When comparing names
These apply whichever mode you're in:
Preferred names count. If the 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 the preferred name / nickname fields on both the response and the record.
Formatting doesn't matter. Capitalisation, accents, apostrophes, hyphens and spacing are ignored. O'Brien and OBrien, or Anne-Marie and Anne Marie, are treated as the same.
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).
We'll leave it for you when, for example:
more than one patient could match
a detail we could compare didn't agree — for example a different email — or, in strict, the record holds a date of birth, email, or mobile that the response didn't include
the first name is close-but-not-exact to a patient who otherwise 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 clearly point to a different person — a different first name with nothing else lining up — is treated as a new patient.
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.