Clinical Spine

The clinical spine is Palamond's answer to a hard question: when should a patient's request actually turn into treatment? Rather than let any intake flow directly to a prescription, the platform routes every journey through a governed sequence of gates. Treatment becomes active only when a real condition has been assigned, the patient is eligible for it, and the patient has consented.

You rarely author these gates yourself, but understanding them tells you what state a patient is in and what your app should show next.

The front door is an assessment, not a treatment

A patient enters through an assessment (a scoped intake such as "Skin concern" or "Thyroid and energy"), never through a drug or a program. An assessment gathers data (questionnaires, labs, vitals). It is deliberately one-time and cannot schedule future care. That temporal limit is what keeps treatment out of the front door.

An assessment is published as a PlanDefinition whose type marks it as an assessment. It is fronted by a public HealthcareService your app lists from the catalog with GET /v1/protocols.

The gates

From the assessment, the spine advances through these steps. Each is a Task your app or a clinician acts on; the journey's state is derived from which step tasks exist and their status.

1. Intake. The patient completes the scoped assessment. Your app starts it with POST /v1/assessments, records answers as a QuestionnaireResponse, and submits measurements by completing the assessment's tasks. See Complete an Assessment.
2. Review (condition). A clinician reviews the intake and assigns a Condition from the catalog. This is a human clinical act, not an automatic mapping from the intake. The assessment never pre-binds candidate conditions.
3. Eligibility. Once a condition is assigned, the platform computes which treatment options the patient is a candidate for. Eligibility is the intersection of three things: candidacy for the condition, the intrinsic safety of each option (contraindications, interactions, prerequisites), and the patient's own data.
4. Selection. The clinician selects among the eligible options. A guideline-preferred default is shown as a label, never a preselection.
5. Consent. The patient is offered a consent bundle (the chosen treatment plus its monitoring commitment) and accepts, declines, or counters. Only acceptance activates care.

Only after consent does a CarePlan (an active protocol) come into being. Until then, nothing is treating the patient.

Key resource shapes

Condition is standard FHIR, coded with ICD-10-CM. It is the pivot of the whole spine: no active care exists without one. Patients never write a Condition; a clinician assigns it during review, and it then appears in the record. This is what you read back:

{
  "resourceType": "Condition",
  "subject": { "reference": "Patient/…" },
  "code": {
    "coding": [{ "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "L70.0", "display": "Acne vulgaris" }]
  }
}

The consent bundle is a proposal RequestGroup composed against pinned versions of the chosen protocol, treatment option, and condition. Acceptance instantiates exactly that pinned set, so a version published later never silently changes an in-flight offer. Decline and counter are first-class outcomes that route back to review.

Active care is a CarePlan that instantiates the chosen protocol, created only after consent.

What this means for your app

• The patient enters through POST /v1/assessments, never by picking a treatment. See Complete an Assessment.
• Read the spine's tasks to know where the patient is and what to prompt next. When the patient finishes a step, complete its task with POST /v1/tasks/{id}/complete.
• Show a proposed care plan (an offered consent bundle) as a distinct "proposed" state with accept and decline actions.
• Never try to shortcut a patient from intake to treatment. The gates exist so that care activates safely and auditably, and the API will not let you skip them.

Next

• Episode Lineage - The join key that ties the whole journey together.
• Care Plans - Working with active and proposed plans.
• Consent - Reading and recording consent.