Registering a patient is not just collecting a name and phone. It is the first compliance event of the relationship: identity verified, consents captured, contact preferences agreed, marketing permission collected (or not), payer linked, and the patient record made findable for everyone who will touch it next. This article walks the full intake and the most common edge cases.

Where it lives#

Patients → + New patient: full intake form.
Booking → New booking → + New patient: shortcut from a phone booking, identical form embedded in the booking flow.
Tablet / kiosk: a patient can self-register on the tablet for the first visit (subset of fields, reception completes the rest).
Web form / lead conversion: a lead converting to patient inherits captured fields, reception only fills the gaps.

Required vs optional at intake#

Required to save a patient#

Full name (first, last).
One contact channel (phone or email).
Year of birth (full date if known).
Sex (clinical, drives reference ranges for vitals and labs).
Branch of primary care (used for default routing).

Required before booking the first session#

Full date of birth (so age-based service eligibility works).
Mobile phone (so confirmation messages can land).
Emergency contact (one name + one phone).
Marketing-consent answer (yes / no / not asked). Yes is required for campaigns.

Required before the first paid invoice#

Government ID number (or passport for foreign patients), per tenant policy.
Address (for invoice and regulator).
Payer information (self-pay or insurance).

Useful for regulated tenants (UAE NABIDH and similar)#

Emirates ID for residents.
Nationality.
Insurance policy details.

These fields feed the NABIDH ADT A04 register message. The system does not block the save if they are missing — instead the NABIDH integration sends a partial A04 and logs the gap. Tenant policy decides whether the registration form should require them before save.

Duplicates, what the system catches and what it doesn't#

Today the duplicate gate is one rule: