What Is Palamond
The clinical care platform for patient-facing apps, built on a single API where FHIR is the record and endpoints are the actions.
Palamond is a clinical care platform for building patient-facing apps. It exposes a single API, organized around one principle:
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. Starting an assessment, homing a new patient, completing a task, accepting an agreement: each has exactly one endpoint, such as
POST /v1/assessmentsorPOST /v1/tasks/{id}/complete.
Every operation maps to exactly one path, 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.
Everything else in these docs, the endpoint tables and FHIR examples included, builds on that split.
Read this first
- New to Palamond? Start with Quickstart for a working app flow in minutes.
- Trying to understand the API surface? Read API Overview before the endpoint reference.
- Looking for the full contract? Open the OpenAPI document at
/v1/openapi.json, where the path tree matches the SDK namespaces.
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. A patient-facing client using
@palamond/sdk. It signs the patient in and calls the API as them. - The Palamond API. One HTTP surface: workflow endpoints plus the FHIR record. Access control scopes every call to the signed-in patient.
- 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/sdkships 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
- Quickstart - Sign in and make your first calls in about ten minutes.
- Complete an Assessment - The end-to-end example: start an assessment and finish its tasks.
- The API - The two planes, errors, and limits.
- Building Patient-Facing Apps - Connect, authenticate, and read and write correctly.