Custom Fields for Booking and Healthcare Applications

Every clinic, salon, and consultancy collects different data at booking time. A dental practice needs insurance carrier and policy number. A physiotherapy clinic needs injury location and referring physician. A hair salon needs stylist preference and service add-ons. A management consultancy needs project scope and billing contact.

Appointment scheduling platforms that ship with only Name, Email, Phone, and Date fields force every business into the same rigid form. The result is predictable: front desk staff maintain parallel spreadsheets, intake data gets lost between systems, and clinics switch to a competitor that lets them customize the booking experience.

Custom fields solve this. This article covers why booking and healthcare applications need them, what different sub-verticals require, the compliance considerations unique to this space, and how to ship them without building a form engine from scratch.

Why Booking and Healthcare Apps Need Custom Fields

The core booking flow (select a provider, pick a time slot, confirm) is universal. But the information collected alongside that booking varies dramatically by business type, specialty, and regulatory environment.

Consider how different businesses use the same scheduling platform:

A 2024 survey by PatientPop found that 68% of patients prefer to complete intake forms digitally before their appointment. But "intake form" means something entirely different for a dental practice versus a physiotherapy clinic versus a veterinary office.

Source: PatientPop

Your scheduling platform needs to let each business define what "intake" means for them.

Common Field Patterns by Sub-Vertical

Dental Clinics

Sunrise Dental Clinic in Portland collects all six of these fields at booking time. Without them, the front desk calls every patient 24 hours before their appointment to gather insurance details by phone.

Physiotherapy and Rehabilitation

Hair Salons and Beauty

A salon like Velvet Studio in Austin uses service type and hair length together to calculate appointment duration. A cut on short hair takes 30 minutes; highlights on extra-long hair take three hours. Without these fields, the booking system cannot allocate time slots correctly.

Consultancies and Professional Services

Compliance Considerations for Health Data

Booking and healthcare applications face compliance requirements that most other SaaS categories do not. Custom field implementations in this space must account for:

Data sensitivity classification. Not all custom fields carry the same risk. A patient's preferred contact method is low-sensitivity. Their insurance policy number is moderate. Their injury description or allergy list is protected health information (PHI) under HIPAA.

Field-level access control. A receptionist needs to see the insurance carrier and policy number. They do not need to see clinical notes from previous visits. Custom fields need access scoping so that different roles see different fields on the same booking record.

Audit trails. HIPAA and GDPR both require that access to patient data is logged. When Dr. Emily Chen views a patient's intake fields, when the front desk updates an insurance number, when a field value is deleted, each action needs a timestamped audit record.

Data retention and deletion. Patients have the right to request deletion of their data. Custom field values must support hard deletion (not just soft delete) when a data subject access request requires it.

Multi-tenant isolation. This is critical in healthcare. Sunrise Dental Clinic must never see data belonging to Cascade Physiotherapy, even if both are tenants on the same scheduling platform. Tenant isolation must be enforced at the data layer, not just the UI layer.

These requirements add significant engineering complexity to a custom field system. Building validation, storage, and retrieval is one thing. Building it with audit logging, access control, and tenant isolation is a substantially larger project.

How Kopra Solves This

Kopra provides the infrastructure layer for multi-tenant custom fields with the compliance features that booking and healthcare applications require.

Multi-tenant isolation is enforced at the data layer. Every query is scoped by clientId. There is no code path that returns data across tenant boundaries.

Audit logging is built in. Every create, update, and delete operation on field definitions and field values generates an audit log entry with the user ID, action, resource type, and timestamp.

Tenant self-service lets each clinic or salon configure their own intake fields through an embeddable configuration panel. Sunrise Dental adds their insurance fields. Velvet Studio adds their service type and stylist preference. Neither contacts your support team.

The embed model means custom fields appear inline in your booking form, styled to match your application. Patients and clients see a single seamless form, not a redirect to a third-party system.

The REST API gives your backend full access to custom field values for workflows: pre-appointment reminder emails that include the service type, insurance verification checks triggered by policy number submission, appointment duration calculation based on service and hair length.

Integration Example: A Booking Form with Kopra Custom Fields

Here is how a scheduling platform integrates Kopra custom fields into its booking confirmation step:

import { KopraSDK } from '@kopra-dev/sdk';

const sdk = new KopraSDK({
  currentTenant: 'sunrise-dental-portland',
  getToken: async (req) => {
    const res = await fetch('/api/kopra-token', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(req),
    });
    return res.json();
  },
  onFieldsSaved: (values) => {
    // values: { insurance_carrier: "Delta Dental", policy_number: "DDG-20260415-882", ... }
    console.log('Intake fields saved:', values);
  },
  autosave: {
    enabled: true,
    debounceMs: 1500,
  },
});

// Embed intake fields in the booking form for appointment booking-1042
await sdk.loadCustomFields('intake-fields-container', {
  fieldGroupKey: 'booking-intake',
  entityId: 'booking-1042',
});

The scheduling platform handles the time slot picker, provider selection, and confirmation flow. Kopra handles the intake fields. Each tenant sees their own field configuration. Field values are stored with full tenant isolation and audit trails.

On the backend, before the appointment:

# Fetch intake data to pre-populate the patient chart
curl "https://your-kopra-instance.com/api/tenants/sunrise-dental-portland/field-groups/INTAKE_FG_ID/entities/booking-1042/values" \
  -H "X-API-Key: kp_your_key"

# Search for all bookings missing insurance information
curl "https://your-kopra-instance.com/api/field-values/search?tenantId=sunrise-dental-portland&fieldKey=insurance_carrier&value=Self-Pay&page=1&pageSize=50" \
  -H "X-API-Key: kp_your_key"

The Alternative: Building It Yourself

Building custom intake fields for a multi-tenant scheduling platform requires:

Source: Appinventiv - Build vs Buy

After launch, maintenance runs 15-20% of the build cost per year. New field type requests from customers, validation edge cases, database performance tuning, and security patches are ongoing.

Your scheduling platform's competitive advantage is the booking flow, the calendar sync, the provider management, the patient communication. Not the custom field infrastructure underneath. Offloading the field layer lets your engineering team focus on the features that differentiate your product.

Free tier available at kopra.dev. No credit card required.