> For the complete documentation index, see [llms.txt](https://docs.nerovasystems.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nerovasystems.com/guides/verticals/medicine/dependents-and-booking.md).

# Dependents and booking

The dependents pattern end to end: create a child patient as a subject, book an appointment for them with clinical intake, and echo the subject back on every read.

## The pattern

The account holder is the client: they own the WhatsApp number, the mandate, and the payment relationship. The patient is the subject: the person the appointment is for. A parent booking a checkup for their child is one client, one subject, one appointment that references both.

## Create the dependent

When the concierge learns the appointment is for someone new ("it's for my daughter"), Nerova collects your `subjectFields` on a trusted surface and calls [create subject](https://docs.nerovasystems.com/documentation/provider-api/operations/create-subject) under the parent's client record (`POST v1/clients/{id}/subjects`):

```json
{
  "fields": {
    "full_name": "Zoe Mokoena",
    "date_of_birth": "2019-04-12",
    "relationship": "child"
  }
}
```

Your platform validates against its own schema as the authority (a malformed `date_of_birth` is your `400` to raise), creates the patient record under the client, and returns the subject with a stable `externalSubjectId`. Nerova uses that identifier from then on; returning subjects are found via [list subjects](https://docs.nerovasystems.com/documentation/provider-api/operations/list-subjects) instead of being re-created.

## Book for the dependent

The booking request carries the client, the subject reference, and the intake answers, with sensitive answers collected off-channel per the [previous page](/guides/verticals/medicine/sensitive-intake.md):

```json
{
  "externalServiceId": "svc_new_patient",
  "externalStaffId": "staff_007",
  "startTime": "2026-09-04T08:30:00+00:00",
  "client": {
    "name": "Lerato Mokoena",
    "phone": "+27830000000",
    "email": null,
    "externalClientId": "client_5501"
  },
  "externalLocationId": null,
  "notes": null,
  "subject": { "externalSubjectId": "subj_2044" },
  "intakeResponses": {
    "reason_for_visit": "school checkup",
    "allergies": "penicillin"
  },
  "reason": "first visit for my daughter"
}
```

`subject` is only ever sent to platforms that declared a subject capability; a salon-shaped platform never sees the field. Requires the `Idempotency-Key` header. Full field semantics are on the [create appointment reference](https://docs.nerovasystems.com/documentation/provider-api/operations/create-appointment).

## Your side of the contract

* **Validate the subject.** An unknown `externalSubjectId` is a `400` with an `invalid_request` envelope, not a silent fallback to booking for the account holder.
* **Store and echo.** The appointment must return the same `subject.externalSubjectId` on every read. Conformance proves it with `subjects.appointment_round_trip`.
* **Echo intake verbatim and refuse undeclared keys**, exactly as in the [salon booking page](/guides/verticals/beauty-and-nails/booking.md): `intake.appointment_round_trip` and `intake.undeclared_key_refusal` apply here too.

## Prove it on a test tenant

On a test tenant on your Live key, run the full arc: create the dependent, book the new-patient consult for them, read the appointment back, and confirm the subject and intake echo. Then run conformance: the subject checks (`manifest.subject_vocabulary`, `manifest.subject_fields`, `subjects.list`, `subjects.create_verify`, `subjects.appointment_round_trip`) and the intake checks must all be green before the practice platform certifies. From here, go-live is the universal path in [zero-to-live step 10](/guides/zero-to-live/step-11-go-live.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nerovasystems.com/guides/verticals/medicine/dependents-and-booking.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.