> 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/manifest-and-services.md).

# Declare the practice

Declare a medical practice manifest: patient subject vocabulary, subject fields for dependents, and services whose intake schemas separate standard from sensitive.

## The manifest

A practice platform declares the core nine, both subject capabilities, and `IntakeForms`. Declaring a subject capability makes `subjectVocabulary` required, and declaring `CreateSubjects` makes a non-empty `subjectFields` schema required; omitting either fails setup validation (`subject_vocabulary_missing`, `subject_fields_missing`) and the matching conformance checks.

```json
{
  "contractVersion": "2026-08-01",
  "providerName": "Meridian Health",
  "capabilities": [
    "ReadServices",
    "ReadStaff",
    "ReadSchedules",
    "ReadClients",
    "ReadAvailability",
    "ReadAppointments",
    "CreateAppointments",
    "RescheduleAppointments",
    "CancelAppointments",
    "ReadSubjects",
    "CreateSubjects",
    "IntakeForms"
  ],
  "subjectVocabulary": { "singular": "patient", "plural": "patients" },
  "subjectFields": [
    { "key": "full_name", "label": "Patient full name", "kind": "text", "required": true },
    { "key": "date_of_birth", "label": "Date of birth", "kind": "date", "required": true },
    { "key": "relationship", "label": "Relationship to account holder", "kind": "choice", "required": true, "options": ["self", "child", "spouse", "parent", "other"] }
  ]
}
```

`subjectVocabulary` is what Nerova calls your subjects everywhere it talks about them: the concierge asks "which patient is this appointment for?", not "which subject". Downstream channels render the dependent creation form directly from `subjectFields`, which is why `CreateSubjects` requires the schema: subject creation without fields is un-collectable.

## The service catalog

Clinical services carry the heavier intake. A new-patient consult asks for history; a follow-up asks almost nothing.

```json
[
  {
    "externalServiceId": "svc_new_patient",
    "name": "New patient consultation",
    "durationMinutes": 45,
    "price": { "amountCents": 95000, "currency": "ZAR" },
    "category": "Consultations",
    "description": "First visit, includes full history.",
    "intakeFields": [
      { "key": "reason_for_visit", "label": "Reason for visit", "kind": "text", "required": true, "options": null, "sensitivity": "standard" },
      { "key": "medical_history", "label": "Relevant medical history", "kind": "longText", "required": false, "options": null, "sensitivity": "sensitive" },
      { "key": "medications", "label": "Current medications", "kind": "longText", "required": false, "options": null, "sensitivity": "sensitive" },
      { "key": "allergies", "label": "Known allergies", "kind": "longText", "required": true, "options": null, "sensitivity": "sensitive" }
    ]
  },
  {
    "externalServiceId": "svc_follow_up",
    "name": "Follow-up consultation",
    "durationMinutes": 15,
    "price": { "amountCents": 45000, "currency": "ZAR" },
    "category": "Consultations",
    "description": "Review visit for an existing patient.",
    "intakeFields": [
      { "key": "reason_for_visit", "label": "Reason for visit", "kind": "text", "required": true, "options": null, "sensitivity": "standard" }
    ]
  }
]
```

The split matters: `reason_for_visit` is the one field a patient can comfortably answer in a WhatsApp chat, so it is explicitly opted into `standard`. Everything clinical is labeled `sensitive`, and the [next page](/guides/verticals/medicine/sensitive-intake.md) explains exactly what that buys.

Next: [Sensitive intake](/guides/verticals/medicine/sensitive-intake.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/manifest-and-services.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.