Data types

Every record from the Records API and every event from the Change Feed or Webhooks carries a resource-type-specific payload — payload on a record, record on a change-feed or webhook event. This section documents each of those payload shapes in depth: every field, every enum value, a full synthetic example, and guidance for consuming it correctly. Start here for the primitives every payload is built from, then jump to the page for the resource type you're integrating.

How payloads are delivered

The same payload shape appears in three envelopes, depending on which surface you're reading from. Here is one patient payload shown in all three, so you can see how the envelope changes but the payload itself does not:

As a Records API item (Records API):

{
  "id": "f3024f2e-0583-4759-a9b8-c534e6763391",
  "resourceType": "patient",
  "version": 1,
  "payload": {
    "identifiers": [{ "system": "urn:michels:pid", "value": "1234567" }],
    "familyName": "Mueller",
    "givenNames": ["Anna"],
    "birthDate": "1980-05-01",
    "gender": "female"
  },
  "updatedAt": "2026-07-14T04:32:56.082Z",
  "orgSlug": "default",
  "identifiers": [{ "system": "urn:michels:pid", "value": "1234567" }]
}

As a change-feed event (Change Feed):

{
  "sequence": 1,
  "resourceType": "patient",
  "canonicalId": "f3024f2e-0583-4759-a9b8-c534e6763391",
  "operation": "create",
  "version": 1,
  "occurredAt": "2026-07-14T04:32:56.082Z",
  "orgSlug": "default",
  "record": {
    "identifiers": [{ "system": "urn:michels:pid", "value": "1234567" }],
    "familyName": "Mueller",
    "givenNames": ["Anna"],
    "birthDate": "1980-05-01",
    "gender": "female"
  }
}

As a webhook delivery (Webhooks), the identical event embedded in events[]:

{
  "deliveryId": "1b2c3d4e-5f60-4718-9a2b-3c4d5e6f7a8b",
  "subscriptionId": "8d9e4a9a-9c2b-4a9e-8c9d-4f6b0a2e6f11",
  "attempt": 1,
  "events": [
    {
      "sequence": 1,
      "resourceType": "patient",
      "canonicalId": "f3024f2e-0583-4759-a9b8-c534e6763391",
      "operation": "create",
      "version": 1,
      "occurredAt": "2026-07-14T04:32:56.082Z",
      "orgSlug": "default",
      "record": {
        "identifiers": [{ "system": "urn:michels:pid", "value": "1234567" }],
        "familyName": "Mueller",
        "givenNames": ["Anna"],
        "birthDate": "1980-05-01",
        "gender": "female"
      }
    }
  ]
}

Whichever envelope you read a payload from, it validates against the same field reference on that type's page.

Shared building blocks

Four small shapes recur across every resource type's fields. Each resource-type page links back to these definitions instead of re-explaining them.

Identifiers

A business identifier scoped to an identifier system — e.g. a patient's MRN, or an encounter's visit number in the source system.

Field	Type	Required	Description
system	string	yes	The identifier's namespace, e.g. urn:michels:pid.
value	string	yes	The identifier's value within that namespace.

{ "system": "urn:michels:pid", "value": "1234567" }

This is exactly what the Records API's ?identifier=<system>|<value> lookup matches on: pass the same system and value, pipe-separated.

Source references

A reference to another resource, expressed in source-system terms rather than a canonical id — e.g. an encounter's patientRef.

Field	Type	Required	Description
sourceSystem	string	yes	The source system the referenced record came from.
resourceType	resource-type enum	yes	One of the ten resource types.
sourceId	string	yes	The referenced record's id within that source system.

{ "sourceSystem": "michels", "resourceType": "patient", "sourceId": "pat-1" }

A field like patientRef does not carry the canonical id directly — it is resolved at ingest time. To correlate a source reference to the canonical record it points at, look up the canonical record whose identifiers contain a matching business identifier for that source system.

Coded concepts

A coded value from an external terminology system, with an optional human-readable display string — e.g. a condition's code.

Field	Type	Required	Description
system	string	yes	The terminology system's URI, e.g. an ICD-10 code system.
code	string	yes	The code within that system.
display	string	no	Human-readable label for the code.

{
  "system": "http://fhir.de/CodeSystem/bfarm/icd-10-gm",
  "code": "I10",
  "display": "Essential hypertension"
}

system + code together are the semantic key — treat them as the value to match, compare, or store. display is convenience text for showing to a human; two events for the same system/code may carry slightly different display text, so don't key logic on it.

Timestamps

Every canonical timestamp field accepts any ISO-8601 datetime with an offset on input (whatever offset the source system reported) and is always normalized to a Z-suffixed UTC string on output:

input:  "2026-07-10T10:30:00+02:00"
output: "2026-07-10T08:30:00.000Z"

Because every timestamp field is normalized the same way, two events reporting the same instant — even if their source systems used different offsets — always produce the identical output string. You can safely rely on string equality when comparing timestamps for the same instant, without parsing dates yourself.

Not every date-shaped field on every type is one of these normalized timestamps — some resource types (see observation and care-plan) carry source-provided date or schedule strings that are not run through this normalization. Each field table calls that out explicitly where it applies.

The resource types

Type	What you'll find on the page
patient	The core demographic record every other resource type references via patientRef.
encounter	A patient visit or stay, from the provider or a rosetta-app therapy case.
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.
admission	One completed admission form snapshot from a therapy discipline.
discharge	One completed discharge report snapshot from a therapy discipline.