Overview

The Patient Everything bundle is the FHIR representation of a patient’s full clinical history — every record Connective Health has assembled for that patient across all contributing sources, deduplicated and normalized. It is produced automatically whenever a new set of clinical data finishes processing for a patient; no separate request is needed. Unlike the Patient Summary bundle, no clinical relevance filtering is applied. If a record exists for the patient in a supported domain, it appears here.

Bundle Structure

The output is a single Bundle resource containing one entry per resource.

Field	Cardinality	Notes
`resourceType`	1..1	Always `Bundle`.
`type`	1..1	Always `collection`. The bundle is a plain set of resources — it is not a transaction, batch, or search result.
`id`	1..1	A newly generated UUID for each bundle. This changes every time the bundle is regenerated, unlike the resource `id`s inside it.
`entry.fullUrl`	1..1	Always `urn:uuid:{resource id}`. Because entries are addressed by their resource `id`, references between resources inside the bundle resolve locally.
`entry.resource`	1..1	The FHIR resource.
`entry.resource.meta.source`	1..1	Always `https://connectivehealth.io` on every resource in the bundle.
`timestamp`	0..0	Not set.
`total`	0..0	Not set (`total` only applies to search-result bundles).
`entry.request` / `entry.response`	0..0	Not set (these only apply to transaction/batch bundles).

Resources Included

Resource	US Core Profile	Description
Patient	US Core Patient	The patient’s demographics. Exactly one per bundle, and the `subject` of every other resource.
AllergyIntolerance	US Core AllergyIntolerance	Allergies, including the reaction manifestation and severity.
Condition	US Core Condition (Problems and Health Concerns)	The patient’s problem list.
Encounter	US Core Encounter	Visits and appointments. Each one carries its own encounter diagnosis as a contained `Condition`.
Procedure	US Core Procedure	Procedures performed.
CarePlan	US Core CarePlan	Assessment and plan-of-treatment narrative.
DocumentReference	US Core DocumentReference	Clinical notes, carried as a base64-encoded plain-text attachment.
Immunization	US Core Immunization	Vaccine administrations.
MedicationRequest	US Core MedicationRequest	Prescriptions.
Observation	US Core Laboratory Result Observation	Laboratory results.
Observation	US Core Vital Signs	Vital signs, including blood pressure panels.
DiagnosticReport	US Core DiagnosticReport (Report and Note)	Imaging and other diagnostic reports, with their results as contained `Observation` resources.

Condition appears in two roles. The problem list produces standalone Condition entries in the bundle, while each Encounter carries a separate encounter-diagnosis Condition contained inside it. See the Condition page for both.

Contained resources

Some resource types are never bundle entries of their own. They are emitted contained inside the resource that references them, and are therefore not assigned a stable id and not deduplicated:

Resource	Contained within
Practitioner	The `PractitionerRole` that references it.
PractitionerRole	Any resource that names a provider — `Encounter.participant`, `Observation.performer`, `DiagnosticReport.performer`, `Procedure.performer`, `MedicationRequest.requester`, `CarePlan.author`, `DocumentReference.author`, and `Condition.recorder`.
Location	The `PractitionerRole` for the facility where the activity took place.
Medication	The `MedicationRequest`, and only when the customer is configured to receive full `Medication` resources — see MedicationRequest.
Condition (encounter diagnosis)	The `Encounter` it is the diagnosis for.

Because contained resources have no id, the same real-world provider, facility, or drug product appears as a separate contained resource under every resource that references it. Only the top-level bundle entries listed under Resources Included are deduplicated.

Stable IDs

Every top-level resource is assigned a stable id derived from the clinical fields that identify it, so the same underlying record resolves to the same id in every bundle. See FHIR IDs for how that derivation works, and Deduplication for what happens when two source records produce the same id.

Resource	Derived from
Patient	The provider’s patient identifier system and value.
AllergyIntolerance	Patient, recorded date, allergen code, reaction manifestation code, and reaction severity code.
CarePlan	Patient, date, and the plan narrative text.
Condition (problem list)	Patient, recorded date, primary diagnosis code, rate code, and whether the problem is active. The “primary” diagnosis code is the ICD-10 code when one is available among the diagnosis codes, otherwise the source’s own primary code.
DiagnosticReport	Patient, date, report text, panel code, diagnostic type, result value, unit, and reference range.
DocumentReference	Patient, note date, note type code, and the note text.
Immunization	Patient, date, and vaccine code.
MedicationRequest	Patient, prescribed date, medication code, drug name code, directions (sig), strength value and unit, refills allowed, and initial fill quantity.
Observation (laboratory)	Patient, date, result code, value, unit, and reference range.
Observation (vital sign)	Patient, date, vital sign code, value, and unit.
Procedure	Patient, date, and procedure code.

Encounter is the only resource whose id is a pass-through of a source identifier rather than a hash. This keeps encounter ids recognizable and lets other resources reference them directly.

Deduplication

Because ids are derived from clinical content rather than from source row identity, two source records that carry the same clinically meaningful values produce the same id. Those duplicates are collapsed into a single bundle entry — so a record reported by two different contributing sources appears once, not twice.

Data Limits

To keep bundles bounded, each clinical domain is capped at a maximum number of resources. Records are ordered by their primary date, most recent first, and the cap keeps the most recent ones. There is no date cutoff — older data is included whenever the cap has not been reached, which for most patients means the entire history is present.

Domain	Cap
Laboratory results	5,000
Vital signs	5,000
Blood pressures	5,000
Allergies	1,000
Care plans	1,000
Diagnostic reports	1,000
Encounters	1,000
Immunizations	1,000
Medications	1,000
Notes	1,000
Problems	1,000
Procedures	1,000

Delivery

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

Welcome

Product

FHIR

Implementation

APIs

Patient Everything

Overview

Bundle Structure

Resources Included

Contained resources

Stable IDs

Deduplication

Data Limits

Delivery

​Overview

​Bundle Structure

​Resources Included

​Contained resources

​Stable IDs

​Deduplication

​Data Limits

​Delivery

Overview

Bundle Structure

Resources Included

Contained resources

Stable IDs

Deduplication

Data Limits

Delivery