Custom Patient Fields (Settings)

Why clinics add their own fields

ClinyPal's built-in patient record covers the fields almost every clinic needs — name, contact details, demographics. But every clinic also tracks a handful of things that are specific to how it operates: an internal reference number tied to another system, a preferred communication channel, a membership tier, or a flag your intake process relies on. Custom Patient Fields is where an Administrator adds those extra fields, and once added, they appear on every patient record in the clinic — new and existing alike.

Because these fields become part of every patient's record permanently, this page is restricted to Administrators. A field added here isn't a personal note or a one-off annotation — it's a structural change to what every staff member sees on every patient, so it's worth treating field design as a deliberate decision rather than an ad hoc one.

The Custom Patient Fields settings page showing a list of configured fields with drag handles for reordering.

Under the hood: the Dynamic Form Builder

This settings page is a thin, purpose-specific layer on top of ClinyPal's drag-and-drop Dynamic Form Builder — the same engine that powers Patient Form Templates and the intake Forms tab elsewhere in the product. Here, the builder is scoped specifically to fields that live on every patient's core record, rather than a form a patient fills out once.

This article only covers the patient-fields use of the builder — what field types are available, how required fields and ordering work, and how to think about field design. For the complete drag-and-drop mechanics of the builder itself, including how sections, conditional logic, and layout work when building a full form, see the dedicated article in the Clinical Tools category.

Choosing the right field type

When you add a custom field, you choose from the same field type palette the form builder offers elsewhere in the product:

The type you choose shapes how usable the data is later, not just how it looks on the form. A Multiple choice field with a fixed set of options is searchable and reportable in a way a Single line free-text field never will be — if you expect to filter or count patients by this field later, prefer the constrained option even if it takes a moment longer to define up front. Reach for Single line or Paragraph only when the answer genuinely varies too much to enumerate.

Designing fields that stay useful

The biggest risk with custom fields isn't getting the mechanics wrong — it's accumulating fields nobody looks at anymore. Every field you add appears on every patient record permanently, so it's worth applying a bit of discipline before adding one:

• <strong>Check for an existing built-in field first.</strong> If the information you want is already captured elsewhere on the record — contact details, address, referral source — a custom field duplicating it just creates two places that can disagree.
• <strong>Prefer constrained field types when you can.</strong> A dropdown or checkbox list is easier for staff to fill in consistently, and far easier to use later than a free-text field where every staff member phrases the same answer differently.
• <strong>Only mark a field Required if the record is genuinely incomplete without it.</strong> Overusing Required slows down every single patient creation, including the ones where the answer wouldn't actually change anything.
• <strong>Retire fields that stop being useful.</strong> A field kept around after the process it supported has changed is just noise on every patient's Details tab — it's worth periodically reviewing the list rather than only ever adding to it.

Adding and reordering fields

Where custom fields show up

Once saved, custom fields appear alongside the built-in demographic fields on every patient's Details tab, including patients who already existed before the field was added — those fields simply start out blank until someone fills them in.

Frequently asked questions