Skip to main content

​
Overview

The Patient Summary bundle is the FHIR representation of a curated view of a patient’s history — the subset of records judged clinically relevant, rather than everything on file. It is produced automatically alongside the Patient Everything bundle whenever a new set of clinical data finishes processing for a patient. The curation is targeted and configurable rather than one-size-fits-all: recency-based limits apply where recency matters (encounters), and clinical rules apply where relevance matters (chronic problems, active medications). See Basics for more on the curation philosophy. The bundle uses the same resource types, the same field mappings, and the same stable ID rules as the Patient Everything bundle. The differences are in which records are included and in some additional links between them — both covered under Differences from Patient Everything.

​
Bundle Structure

Identical to the Patient Everything bundle structure: a collection Bundle with a freshly generated UUID id, one entry per resource, each entry addressed as urn:uuid:{resource id}, and meta.source of https://connectivehealth.io on every resource. timestamp, total, entry.request, and entry.response are not set.

​
Resources Included

The same resource types are emitted contained rather than as their own bundle entries as in the Patient Everything bundle — Practitioner, PractitionerRole, Location, Medication, and the encounter-diagnosis Condition. See Contained resources.

​
Differences from Patient Everything

​
Which records are included

Because notes, care plans, and procedures are sourced from encounters in this bundle, a note or procedure whose visit was not selected for the summary will not appear — even if the note itself exists in the Patient Everything bundle.

​
Encounter linking

The summary groups related visits together, and that grouping is expressed in FHIR:
  • Each group’s original visit produces an Encounter with no partOf.
  • Each follow-up visit in the group produces its own Encounter whose partOf references the original visit’s Encounter.
Because Encounter.id is the source visit’s own identifier, these references are stable and resolve to another entry in the same bundle.
Encounter.partOf is only populated in the Patient Summary bundle. In the Patient Everything bundle every visit stands alone, so partOf is never set.

​
Back-references to the encounter

Resources that came from a visit point back at that visit’s Encounter. These links are only present in the Patient Summary bundle:

​
Encounter and diagnosis coding

Patient Everything publishes every code and translated code available for a visit, so an Encounter.type (and its contained encounter-diagnosis Condition.code) can carry several codings — one per code system. The Patient Summary publishes a single, pre-resolved code for each: one coding on Encounter.type and one on the contained encounter-diagnosis Condition.code. See Encounter for details.

​
Stable IDs

Identical to Patient Everything stable IDs — the same fields feed the same ids. A record that appears in both bundles therefore carries the same id in both, which means the two bundles can be compared or merged directly.
The encounter links described above are not part of any resource’s id. A note is assigned the same id whether or not it is linked to an encounter, so the same note has one id across both bundles.

​
Data Limits

The same per-domain caps described under Patient Everything data limits apply. They act as an upper bound on top of the curation rules, so in practice the curation — not the cap — determines the size of this bundle.

​
Delivery

Patient Summary bundles are pushed to customer cloud storage as described in Delivery, and a document.deliveryComplete webhook is sent once delivery succeeds.