Rosetta Sync API

The Rosetta canonical data platform brings clinical data from multiple source systems together into one unified, versioned model. This site documents the external interface your application uses to read that data and stay in sync with it going forward.

source systems ──▶  Rosetta canonical layer  ──▶  you, via:
                                                     - the change feed (poll)
                                                     - the records API (on-demand read)
                                                     - webhook subscriptions (push)

All examples on this site use the placeholder base URL https://sync.example.com — substitute the base URL your Rosetta contact provides for your integration.

Resource types

Every canonical record has one of these resource types:

Resource type	What it represents
patient	The core demographic record every other resource type references.
encounter	A patient visit or stay, e.g. an inpatient admission or outpatient appointment.
condition	A coded clinical condition or diagnosis, attached to a patient and optionally an encounter.
coverage	A patient's insurance/payor coverage record.
procedure	A coded clinical procedure performed on a patient, optionally tied to an encounter.
observation	A named trend series for a patient, e.g. a repeated measurement over time.
assessment	One completed clinical assessment instrument, with its answers.
care-plan	A per-patient aggregate of care-plan items, planned assessments, and schedule entries.

The full shape of each resource type's payload — field reference, enum values, and worked examples — is documented in Data types. The API reference generated from this platform's OpenAPI specification (linked from this site's navigation) is the machine-readable complement.

Versioning and consistency

• Every canonical record carries a version that increases by one on every accepted write.
• Every record and event is safe to apply more than once: key your own storage on (canonicalId, version) and treat re-applying an already-seen version as a no-op.
• Records and events also carry an orgSlug identifying which organization they belong to. If your integration only ever serves one organization you can ignore this field; if you serve more than one, both the change feed and the records API accept an ?org=<slug> filter.

Ways to consume this API

• Getting started — a step-by-step quickstart that connects an application end to end.
• Authentication — how to authenticate every request.
• Change Feed — poll for every create/update in strict order, with the full record embedded in each event.
• Records API — read a specific record on demand, by id or by business identifier.
• Webhooks — register an endpoint to receive change-feed events by HTTP push instead of polling.
• Data types — the field reference, enum values, and worked examples for every resource type's payload shape.

How these docs are organized

Read them in this order for the fastest path from zero to a working integration:

1. Getting started — a four-step quickstart.
2. Authentication — how every request is authenticated.
3. Records API — read a record on demand.
4. Change Feed — poll for every create/update in order.
5. Webhooks — receive change-feed events by push instead of polling.
6. Data types — the field reference, enum values, and worked examples for every resource type's payload shape.
7. API Reference — the full per-resource-type schema, generated from this platform's OpenAPI specification (linked from this site's navigation).