Palamond Docs

What Is Palamond

The care platform you build patient apps on, with one API and one rule.

Palamond is a clinical care platform for building patient-facing apps. You get one API with one rule:

FHIR is the record; endpoints are the actions.

  • The record is standard FHIR R4. Every piece of patient data (appointments, observations, care plans, tasks, orders) is a FHIR resource you read with FHIR search under /v1/fhir.
  • The actions are named endpoints. Booking a visit, starting an assessment, completing a task, accepting an agreement: each has exactly one endpoint, like POST /v1/appointments or POST /v1/tasks/{id}/complete.

For any operation exactly one path exists, so "which API do I use?" never comes up. When you try to write a resource the record plane does not own, the error names the endpoint that does.

What the platform does for you

Behind every action, Palamond runs the clinical workflow server-side: opening episodes, issuing tasks, routing clinician review, placing orders, recording consent. Your app renders the experience and calls the API; the platform keeps the care process consistent, safe, and auditable, no matter which app triggered it.

You do not run a backend for any of this. The endpoints are the whole integration surface.

Architecture

  Your app ──HTTPS──▶  Palamond API   ──▶  Platform automation
     ▲                 /v1/...  (actions)        │
     │                 /v1/fhir (record)         │
     └────────── read the updated record ◀───────┘
  1. Your app. A patient-facing client using @palamond/sdk. It signs the patient in and calls the API as them.
  2. The Palamond API. One HTTP surface: workflow endpoints plus the FHIR record. Access control scopes every call to the signed-in patient.
  3. Platform automation. Reacts to your actions server-side and advances the care workflow. Its results land as new FHIR resources you read back.

What you build against

  • The TypeScript SDK: @palamond/sdk ships the client, FHIR types, and the platform's code systems.
  • FHIR search over the patient's record: if you have used a REST API, you already know most of it.
  • The v1 endpoints, described by an OpenAPI document at /v1/openapi.json.

Start here

On this page