Cascade Protocol Core Vocabulary
Core vocabulary for schema versioning, data provenance, identity management, and patient demographics across all Cascade Protocol applications
This vocabulary defines cross-cutting concepts used by all Cascade Protocol health data applications: schema versioning, data provenance, patient demographics (PatientProfile), and supporting identity classes (Address, PharmacyInfo, AdvanceDirectives). Domain-specific vocabularies (e.g., pots:, ecg:, glucose:) import this core vocabulary.
Data Provenance
Classification of how health data was generated or collected
Consumer-Generated
Data generated directly by the user through personal devices (non-clinical setting).
Clinical-Generated
Data generated in a clinical setting under healthcare provider supervision.
Device-Generated
Data generated by a consumer health device (Apple Watch, blood pressure cuff, etc.) without clinical supervision.
Self-Reported
Data manually entered by the patient (symptom logs, medication adherence, intake form fields).
Consumer Wellness
Aggregated wellness data from consumer platforms (Apple Health, Google Fit).
EHR-Verified
Data imported from a verified Electronic Health Record system (Epic MyChart, Cerner, etc.).
Scanned Document
Data extracted from a scanned or photographed clinical document.
AI-Extracted
Data extracted from clinical documents using AI/NLP processing.
Schema Version
Semantic version of the ontology schema used to serialize this data (format: major.minor.patch)
Classification of how this data was generated (consumer vs clinical)
Creator WebID
Solid WebID URI of the user who created this data
Data Source
Identity and reliability metadata for a data-producing device, app, or system. Examples: Apple Watch, MyChart EHR, manual user entry.
Source Name
Human-readable name: 'Apple Watch Series 10', 'MyChart', 'Manual Entry'
Source Bundle Identifier
App bundle identifier (e.g., 'com.apple.health'). Maps to HKSource.bundleIdentifier on Apple platforms.
Source Reliability Tier
Reliability classification: 'clinical' (lab equipment, EHR), 'medical_device' (FDA-cleared BP cuff), 'consumer_device' (smartwatch, fitness tracker), 'self_reported' (manual entry). Tiers inform display and conflict resolution — they do not imply clinical validity.
Source Metric Coverage
A wellness metric this source provides. Use multiple triples for multiple metrics (e.g., two triples linking to health:restingHeartRate and health:heartRateVariability). Preferred over comma-separated strings for proper RDF graph traversal.
Source Organization
Organization that provided this record (e.g., 'Kaiser Permanente', 'Mayo Clinic'). Populated from FHIR meta.source or contained Organization reference during clinical record import.
Source Device Name
Device or app that recorded this measurement (e.g., 'Apple Watch Series 9', 'Omron BP Monitor'). Populated from HealthKit HKSource contributing app/device name.
Sub-Concern
Classifies a vocabulary class by its functional role within a vocabulary. Values are vocabulary-specific strings (e.g., 'summary', 'intake', 'analytics', 'identity', 'app-config', 'structural', 'deprecated'). Used for documentation generation, migration planning, and vocabulary organization.
Added in Schema Version
Records which schema version introduced this data element. Used by serializers to annotate when a class or property was first emitted.
Cascade URI
Stable identifier URI for a Cascade data element. Used across vocabularies to mint persistent identifiers for supplements, medications, and other resources. CANONICAL FORM OF A MULTI-VALUED IDENTITY INPUT (v3.6, NORMATIVE). An implementation that derives a record's identifier from the record's own content hashes a set of named content fields. Since health v2.6 and clinical v1.14 made the code fields (icd10Code, snomedCode, testCode, labCategory) 0..* to match FHIR R4 CodeableConcept.coding, one of those fields can hold several values, and a hash taken over an unordered field is only stable if the field is first put into a canonical form. Without one, two exports of the SAME record that list the same codings in a different order mint two different identifiers and the record silently splits in two. The canonical form of a multi-valued identity input is: 1. Discard members that are null or empty after trimming; trim each surviving member. 2. Deduplicate the survivors. 3. Sort ascending by Unicode code point. (Code point, not locale collation: a locale-dependent order would make identity depend on the machine.) 4. Join with a single separator character that the implementation fixes and documents. U+002C COMMA is the RECOMMENDED separator and new implementations MUST use it. 5. A one-element sequence MUST canonicalize to exactly the bare scalar form. 6. A sequence with no surviving member is treated as an absent field, exactly as a null scalar is. THE THREE INVARIANTS, which are normative independently of the separator and are what the conformance vectors check: ORDER INDEPENDENCE Shuffling the members of a multi-valued identity input MUST NOT change the identifier. SCALAR AGREEMENT A field holding exactly one value MUST mint the same identifier whether it is spelled as a scalar or as a one-element sequence. This is what keeps every identifier written before the fields became 0..* exactly where it is. DUPLICATE INDEPENDENCE Repeating a member MUST NOT change the identifier. SCOPE, AND THE ONE PLACE THIS RULE MUST NOT BE APPLIED. It governs identity inputs whose source element is a SET: FHIR CodeableConcept.coding and the repeating code fields named above. It MUST NOT be applied to an input whose source order carries meaning, because sorting there merges records that the source deliberately distinguished. FHIR name[0] is the primary name, and a component or note list is a sequence, not a set. An implementation that already hashes such a list in document order MUST keep doing so; widening this rule to cover it is a data change, not a canonicalization. MIGRATION. An implementation that already ships a fixed separator other than U+002C at an existing identity site KEEPS that separator. Changing it re-mints every identifier the site has ever produced, which is precisely the harm this rule exists to prevent; the cross-implementation contract is the three invariants above, not the byte string. Adding the dedupe and the sort where they are missing moves an identifier only for a record that carried duplicate or unsorted members, which is the defect being corrected.
Canonical form of multi-valued identity inputs stated in core v3.6
Notifications Enabled
Whether the user has enabled push notifications across Cascade apps.
Preferred Units
User's preferred unit system: 'metric' or 'imperial'.
Patient Profile
Health-specific patient demographics and identity extensions. Designed to complement a Solid-compatible foaf:Agent identity profile (linked via rdfs:seeAlso). Stored at /profile/health.ttl. Contains health-relevant demographic data that is always private.
Date of Birth
Patient date of birth for age calculation and screening eligibility. FHIR-aligned: fhir:Patient.birthDate.
Gender Identity
Patient-reported gender identity. Values: woman, man, non_binary, other, prefer_not_to_say. SNOMED CT mapped via US Core genderIdentity extension.
Biological Sex
Biological sex for clinical calculations and screening recommendations. Values: male, female, intersex.
Age Group
Computed demographic classification for screening recommendations. Values: pediatric (0-17), young_adult (18-39), adult (40-64), senior (65+). Computed from dateOfBirth at serialization time.
Emergency Contact Name
Full name of the patient's emergency contact person.
Emergency Contact Relationship
Relationship of emergency contact to the patient. Values: spouse, parent, child, sibling, partner, friend, caregiver, other.
Emergency Contact Phone
Phone number of the patient's emergency contact person.
Has Address
Links to a structured postal address. Used by PatientProfile and PharmacyInfo.
Marital Status
Patient's marital status. Values: single, married, domesticPartnership, divorced, separated, widowed, preferNotToSay. FHIR-mapped via HL7 v3 MaritalStatus value set (MaritalStatus.fromFHIR()).
Race/Ethnicity
Patient's self-reported race/ethnicity using OMB standard categories. Multi-value: each selected value becomes a separate RDF triple with the same predicate (e.g. cascade:raceEthnicity "asian", "white"). Values: americanIndianAlaskaNative, asian, blackAfricanAmerican, hispanicLatino, nativeHawaiianPacificIslander, white, other, preferNotToSay. Elevated PHI sensitivity. FHIR-mapped via US Core race/ethnicity OMB category codes.
Has Preferred Pharmacy
Links to the patient's preferred pharmacy for prescriptions. Deprecated v2.2 — use cascade:preferredPharmacy (blank-node linking) instead.
Has Advance Directives
Links to the patient's advance directive declarations. Elevated PHI sensitivity. Deprecated v2.2 — use cascade:advanceDirectives (blank-node linking) instead.
Computed Age
Patient age in years, computed from dateOfBirth at serialization time. App-layer convenience property.
Profile ID
Unique identifier (UUID) for the patient profile instance. Used for traceability and deduplication.
Pharmacy Address
Pharmacy address as a single text string. Simplified alternative to using a nested cascade:Address blank node for PharmacyInfo.
Emergency Contact
A patient's emergency contact person. Used as a blank node within cascade:PatientProfile. Properties: cascade:contactName, cascade:contactRelationship, cascade:contactPhone.
Contact Name
Full name of a contact person. Used within cascade:EmergencyContact blank nodes.
Contact Relationship
Relationship of the contact to the patient: spouse, parent, child, sibling, partner, friend, caregiver, other.
Contact Phone
Phone number for a contact person. Used within cascade:EmergencyContact blank nodes and also for general contact use on PatientProfile.
Links a PatientProfile to an EmergencyContact blank node.
Advance Directives
Links a PatientProfile to an AdvanceDirectives blank node.
Preferred Pharmacy
Links a PatientProfile to a PharmacyInfo blank node.
Address
Links an entity to an Address blank node. Used by PatientProfileSerializer.
Preferred Language
Patient's preferred language for medical communication. NOTE: In the two-document Solid WebID Profile model, this should be emitted as dct:language in /profile/card.ttl (IdentityProfileSerializer), NOT in /profile/health.ttl (PatientProfileSerializer). This property is defined for backward compatibility but SER1 will remove it from PatientProfileSerializer.
Structured postal address reusing FHIR Address semantics. Used by PatientProfile and PharmacyInfo.
Street Address
Street line(s) of the address. Simplified alias of cascade:addressLine for flat serialization patterns.
City
City name. Simplified alias of cascade:addressCity for flat serialization patterns.
State
State or province. Simplified alias of cascade:addressState for flat serialization patterns.
Postal Code
ZIP or postal code. Simplified alias of cascade:addressPostalCode for flat serialization patterns.
Country
Country name or ISO 3166-1 code. Simplified alias of cascade:addressCountry for flat serialization patterns.
Address Use
Purpose of the address: home, work, temp, old. Aligns with FHIR Address.use.
Address Type
Type of address: postal, physical, both. Aligns with FHIR Address.type.
Address Text
Full address as a single text string. Aligns with FHIR Address.text.
Address Line
Street address line. Repeatable for multi-line addresses. Aligns with FHIR Address.line.
Address City
City name. FHIR-aligned equivalent of cascade:city. Aligns with FHIR Address.city.
Address District
District or county. Aligns with FHIR Address.district.
Address State
State or province. FHIR-aligned equivalent of cascade:state. Aligns with FHIR Address.state.
Address Postal Code
Postal or ZIP code. FHIR-aligned equivalent of cascade:postalCode. Aligns with FHIR Address.postalCode.
Address Country
Country name or ISO code. FHIR-aligned equivalent of cascade:country. Aligns with FHIR Address.country.
Pharmacy Info
Preferred pharmacy for prescriptions. Manual entry only (no Apple Health import source). Linked from PatientProfile via cascade:hasPreferredPharmacy.
Pharmacy Name
Name of the pharmacy.
Pharmacy Phone
Phone number of the pharmacy.
Patient-reported advance directive declarations. Elevated PHI sensitivity. Linked from PatientProfile via cascade:hasAdvanceDirectives.
Has Living Will
Whether the patient has a living will on file.
Has Power of Attorney
Whether the patient has a healthcare power of attorney on file.
Has DNR
Whether the patient has a do-not-resuscitate order on file.
Advance Directive Notes
Optional free-text notes about advance directives.
Source System
INGESTION AXIS. The import batch a record entered the Pod through (e.g. 'Apple Health export', 'primary-care'). It records HOW AND WHEN data arrived, NOT where it came from, and it MUST NOT be used as a source identity: one batch commonly carries records from several organizations, and one organization commonly arrives in many batches. Use cascade:sourceIdentity for origin.
Source Identity
ORIGIN AXIS. The canonical, transport-independent identity of the organization a record came from. Two records that a FHIR export and a C-CDA document of the SAME health system produced carry the same value here, which is what makes it usable as a reconciliation key where clinical:sourceEHR (a display label) and cascade:sourceSystem (an ingestion batch) are not. VALUE FORM. A scheme-prefixed token, so a consumer can always tell how much the producer actually knew: org:{slug} an organization was derivable. {slug} is the normalized form below. ns:{namespace} no organization was derivable, but the record's identifiers have an assigning authority: the FHIR server base URL, or the C-CDA <id> root OID. Records agree on origin only if they agree on the namespace. transport:{label} LAST RESORT. Nothing in the document named or located an organization, so the value restates cascade:sourceSystem, honestly prefixed. It is not an origin claim, and a consumer must treat two transport: values as 'origin unknown' rather than as evidence of a shared source. THE SLUG NORMALIZATION, which both transports must implement identically: 1. The input is either an organization NAME (a C-CDA custodian/author organization name, a FHIR Organization.name or an institution-looking performer display) or a HOST (the registrable domain of the source FHIR endpoint). 2. HOST: lowercase; drop a leading 'www.'; drop the public-suffix label(s), keeping the registrable name label ('fhir.meridianhealth.example' -> 'meridianhealth'). Then repeatedly strip any generic organization word that forms a whole prefix or suffix of that label ('meridianhealth' -> 'meridian'), never stripping to fewer than three characters. 3. NAME: lowercase; fold diacritics to ASCII; replace every run of non-alphanumeric characters with a single space; split on spaces. 4. Drop generic organization words, legal-form words and pure-number tokens from the token list. Generic means institution-or-specialty vocabulary that names no particular organization: health, healthcare, system(s), service(s), medical, medicine, center/centre, hospital(s), clinic(s), care, group, associates, association, network, partners, physicians, practice, regional, community, memorial, university, institute, foundation, laboratory/laboratories/lab(s), diagnostics, imaging, radiology, pathology, family, urgent, primary, specialty, and the specialty names cardiology, oncology, orthopedics, pediatrics; legal-form means inc, llc, llp, ltd, plc, corp, corporation, co, pc, pa, pllc; and the English stopwords of, and, the, for, at, in, on, a, an. 5. If no token survives step 4, use the whole normalized string with separators removed, so an organization named only in generic words still gets a stable identity. 6. The slug is the FIRST surviving token. 'Meridian Health System' and 'meridianhealth.example' both give 'meridian'; 'Providence Health and Services Washington and Montana' and 'providence.org' both give 'providence'. WHY THE LEADING TOKEN AND NOT ALL OF THEM. The two failure directions are not symmetric. Collapsing two different organizations onto one identity suppresses comparisons between their records, so duplicates simply remain in the Pod: visible, and recoverable later. Splitting ONE organization across two identities lets records the organization deliberately kept apart be compared and merged, which destroys content. So the normalization is deliberately biased toward collapsing, and regional and specialty qualifiers ('... Washington and Montana', '... Cardiology') are dropped rather than being allowed to split a system. WHAT IT IS NOT. It is not a registry key and does not attempt to resolve two organizations that name themselves differently in different documents with no shared token; it canonicalizes what the documents themselves state. It is not a display value: show clinical:sourceEHR. It is not the transport: that is cascade:sourceSystem.
Reconciliation Status
The outcome of reconciliation for this record. Value is one of the cascade:ReconciliationStatus named individuals: cascade:Canonical, cascade:Merged, cascade:ConflictResolved, cascade:UnresolvedConflict.
Closed enumeration of possible reconciliation outcomes.
Canonical
Record is unique — no matching record found across other source systems.
Merged
Record was deduplicated from two or more identical or near-identical source records.
Conflict Resolved
Conflicting values across source records were resolved automatically using a trust-priority or merge strategy.
Unresolved Conflict
Conflicting values could not be automatically resolved (trust scores too similar). Requires manual clinical review.
Within-Source Duplicate
Record is a duplicate of another record within the same source system (e.g. same condition recorded across multiple clinical encounters). Suppressed from cross-system reconciliation output during Pass 1 deduplication.
Merged From
Links a reconciled record to the source record URIs that were merged into it. Used together with prov:wasDerivedFrom for semantic interoperability.
Conflict Resolution Strategy
The strategy used to resolve a conflict. Value is one of the cascade:ConflictResolutionStrategy named individuals: cascade:TrustPriority, cascade:MergeValues, cascade:FlagUnresolved.
Closed enumeration of reconciliation resolution strategies.
Trust Priority
The record from the highest-trust source system is selected as canonical.
Merge Values
The canonical record is built by taking the winner's fields and filling any gaps from lower-trust sources.
Flag Unresolved
The conflict could not be automatically resolved. Record is tagged cascade:UnresolvedConflict for manual clinical review.
Conflict Field
The predicate URI on which a conflict was detected during reconciliation (e.g. health:status, health:resultValue). Stored as a URI reference, not a prefixed name string.
Conflict Description
Removed v2.7. Was informational prose describing conflicting values per source system. Replaced by cascade:conflictDetail structured blank node (v2.5), which uses rdfs:comment on the blank node for human readability.
Conflict Detail
Links a reconciled record to a structured cascade:ConflictDetail blank node describing the per-system values that conflicted. The blank node carries an rdfs:comment with a human-readable summary.
A structured representation of conflicting values across source systems for a single property. Used as a blank node linked from cascade:conflictDetail.
Conflict For
The predicate URI on which the conflict was detected (e.g. <https://ns.cascadeprotocol.org/health/v1#status>). Links a cascade:ConflictDetail to the conflicting property.
System Value
Links a cascade:ConflictDetail to a blank node representing one source system's value for the conflicting property. Each participating source system has its own cascade:systemValue blank node.
For System
The name of the source EHR system (e.g. 'primary-care', 'specialist') within a cascade:systemValue blank node.
Data Absent Reason
Why this record's primary value is absent. Semantics are exactly FHIR R4 Observation.dataAbsentReason (https://hl7.org/fhir/R4/observation-definitions.html#Observation.dataAbsentReason): it explains the absence of the record's VALUE, and it is meaningful only when that value is in fact absent. A record that carries a value MUST NOT also carry this property. VALUE SET. One of the 15 codes of http://terminology.hl7.org/CodeSystem/data-absent-reason, as gathered by the value set http://hl7.org/fhir/ValueSet/data-absent-reason: unknown, asked-unknown, temp-unknown, not-asked, asked-declined, masked, not-applicable, unsupported, as-text, error, not-a-number, negative-infinity, positive-infinity, not-performed, not-permitted. MAPPING FROM HL7 v3 NullFlavor, which is what a C-CDA document writes (http://terminology.hl7.org/CodeSystem/v3-NullFlavor, OID 2.16.840.1.113883.5.1008). An importer reading a nullFlavor attribute MUST map it as follows and MUST NOT write the raw nullFlavor code into this property: UNK -> unknown a proper value applies but is not known ASKU -> asked-unknown the source was asked and did not know NASK -> not-asked the information was never sought NAV -> temp-unknown not available now, expected later NAVU -> unknown not available, with no expectation of later MSK -> masked withheld for security or privacy NA -> not-applicable known to have no proper value OTH -> unsupported the real value is outside the permitted value domain NI -> unknown no information, and no reason given NINF -> negative-infinity PINF -> positive-infinity Any other nullFlavor maps to "unknown", which is the code that asserts only that a value was expected and is missing. WHAT THIS IS NOT. It is not an interpretation, and it is not a substitute for one: an absent interpretation on a record whose value IS present is recorded on the interpretation property itself, whose value set accepts the same data-absent-reason codes. It is not a validation finding: absence of this property means only that the producer said nothing about why a value is missing.
Layer Promotion Status Value
Closed enumeration of Layer 2 promotion states for converted FHIR records.
Layer Promotion Status
Indicates whether a record has been fully mapped to Cascade Layer 2 vocabulary or is preserved as a Layer 1 FHIR passthrough pending future mapping.
Fully Mapped
Record has been fully mapped to Cascade Layer 2 vocabulary.
Pending Layer 2 Promotion
Record is preserved as Layer 1 FHIR passthrough. Full Layer 2 vocabulary mapping has not yet been defined. Original FHIR JSON is retained in cascade:fhirJson for round-trip export.
Original FHIR JSON
Preserves the complete original FHIR resource JSON for Layer 1 passthrough records. Always stored as plain xsd:string (FHIR JSON is always valid UTF-8). Used for lossless round-trip export. Self-contained — survives reconciliation without sidecar file dependencies.
FHIR Resource Type
FHIR R4 resourceType of the source record. Populated on Layer 1 passthrough records.
Source Record Date
Minimal date projection triple for Layer 1 passthrough records. Copied from effectiveDateTime, date, period.start, or created field if present.
User Resolution
A patient's recorded decision for resolving a data conflict between two source records.
Pending Conflict
An unresolved conflict between two or more records from different sources, awaiting user resolution.
Conflict ID
A deterministic string identifier for a conflict, derived from the record type and identity fields. Stable across re-imports.
Resolution
The user's resolution decision. One of: kept-source-a, kept-source-b, kept-both, manual-edit.
Kept Record
The record that was kept as the canonical version after conflict resolution.
Discarded Records
Records that were discarded during conflict resolution.
User Note
Optional free-text note from the patient about their resolution decision.
Candidate Records
The conflicting records in a PendingConflict, awaiting user resolution.
Detected At
When the conflict was first detected during import.
Auto Resolved
True when a conflict was automatically resolved by applying a stored user resolution preference.
Document Type
The type of clinical document. Values: summarization, progress-note, discharge-summary, consultation-note, operative-note, history-physical.
Section Code
LOINC code of the originating C-CDA section for this record.
Source Record ID
The original source system record identifier (e.g., C-CDA <id> element value) preserved for provenance.
Health Record
Abstract base class for all patient health records. Both clinical:ClinicalRecord and clinical:SocialHistoryRecord subclass this. Enables cross-domain consent scoping and pod path policies.
AI Extraction Activity
An LLM-powered extraction activity that produced one or more clinical records from unstructured narrative text. Link from record to activity via prov:wasGeneratedBy. The record itself carries cascade:dataProvenance cascade:AIExtracted (existing DataProvenance marker).
Confidence score 0.0-1.0 from the extraction model.
Model identifier used for extraction, e.g. 'qwen3.5-4b-q4_k_m'.
The C-CDA section name from which the narrative text was extracted (e.g. 'medications', 'problems').
True if extraction confidence < 0.85 and record should enter the patient review queue.
True if a C-CDA section contains only narrative text (no structured entries); signals the P5.3 LLM extraction pipeline.
AI Discarded Extraction
A low-confidence extraction (confidence < 0.50) retained in the patient's pod at pod/analysis/discarded-extractions.ttl. Not auto-imported. Patient can review and rescue into the review queue.
Type of entity that was discarded: medication | condition | lab | socialHistory | vital.
C-CDA section name from which the discarded extraction originated.
Timestamp when the extraction was discarded by the pipeline.
Confidence score that caused the discard (< 0.50).
Social History Consent
Consent scope for social history data. Patient can share clinical/ pod without exposing social-history/. Subject to 42 CFR Part 2 for substance use disorder records.
Advisory Application Activity
An activity that applied a Cascade Advisory Patch to a pod. The activity joins to advisory provenance via prov:used <advisory-iri> and prov:used <matched-record-iri>, recording both the patch source and the record it was matched against. Use prov:wasGeneratedBy on records produced or modified by the patch.
AI Generation Activity
An LLM-powered generation activity that produced narrative or summary content (e.g., checkup:VariantNarrative chunks). Sibling of cascade:AIExtractionActivity: extraction pulls structured records out of unstructured text, generation produces new prose. Records the model identifier, prompt version, temperature, and a cascade:trigger value indicating why the generation ran. Link from generated content to activity via prov:wasGeneratedBy.
Prompt Version
Identifier of the prompt template version used for this generation, e.g. 'variant-narrative-v2.1'. Pair with cascade:extractionModel for full reproducibility.
Generation Temperature
Sampling temperature used during generation (typically 0.0-1.0). Recorded for reproducibility and to distinguish deterministic from creative outputs.
Trigger
The reason this generation activity ran. One of the cascade:GenerationTrigger named individuals: cascade:InitialGeneration, cascade:RegenerationAfterReclassification, cascade:AudienceRetargeting.
Generation Trigger
Closed enumeration of reasons an AIGenerationActivity may run.
Initial Generation
First-time generation of a narrative or summary chunk. No prior version existed.
Regeneration After Reclassification
Regeneration triggered because an upstream classification (e.g., variant pathogenicity, condition status) changed and the prior narrative is now stale.
Audience Retargeting
Regeneration triggered to retarget existing content for a different audience (e.g., patient-facing vs. clinician-facing) without any underlying classification change.
Applied Triples Count
Total number of triples the advisory's CAP body inserted into the pod for this single match. Lets a downstream auditor verify CAP profile constraint C5 (≤ 64 inserted triples per match) at activity-record-read time without re-parsing the patch body. Recorded by the cascade-cli applier (Phase 4 TASK-4.5) on every successful application.
AI-Asserted
Content surfaced by a general-purpose AI assistant in a patient-directed conversation (e.g. ChatGPT, Claude), NOT grounded in clinical sources. MUST be applied to evidence:Assertion instances imported from AI conversations so they can never be mistaken for clinically-extracted data (cascade:AIExtracted) or verified records (cascade:EHRVerified). Marks content that must be evidence-checked before any reliance.
Proxy Agent
A person operating a patient's Pod on the patient's behalf (e.g. a parent for a minor child, a caregiver for a dependent adult). Distinct from the patient (cascade:PatientProfile). Records who is acting and under what authority and scope.
Acts For Patient
The patient (WebID) on whose behalf the proxy acts.
Proxy WebID
Proxy Relationship
Relationship of the proxy to the patient. Reuses the cascade:contactRelationship value space: parent, guardian, caregiver, spouse, child, other.
Proxy Scope
Authority scope, e.g. 'full', 'read-only', 'investigation-only'. Composable with cascade:consentScope (data-sensitivity), which it does not replace.
Proxy Granted At
Proxy Revoked At
Export Manifest
Provenance and completeness metadata for a complete pod export: when it was generated, which schema versions it uses, how many records of each kind it contains, and which provenance layers are represented. Consumers should read this before processing individual resources.
Added in core v3.4; emitted since schema 1.3
Record Summary
Per-domain record counts for one partition of a pod export. Modelled on void:Dataset because it is a statistical description of a dataset subset; each count property is a subproperty of void:entities scoped to a particular void:class.
Interaction Scenario
A clinically significant interaction that can only be detected by correlating resources of differing provenance, for example an EHR-prescribed drug against a self-reported supplement against a lab value. Cascade-specific: no ratified vocabulary models cross-provenance correlation as a first-class thing.
Patient Profile Version
Version of the patient profile structure used in this export, independent of cascade:schemaVersion.
Provenance Layers
Ordered list of the cascade:DataProvenance values represented anywhere in this export. Lets a consumer tell, before reading any resource, whether the export contains device data, EHR data, self-reported data, or a mixture.
Clinical Summary
Record counts for the clinical partition of this export.
Wellness Summary
Record counts for the wellness partition of this export.
Device Sources
Ordered list of the devices that contributed data to this export, each a prov:Agent.
Interaction Scenarios
Ordered list of cascade:InteractionScenario entries flagged in this export.
Domain
Which partition of the export this summary describes, for example 'clinical' or 'wellness'.
Notes
Free-text commentary on a summary or manifest section.
Condition Count
Number of condition records in this partition.
Medication Count
Number of medication records in this partition.
Allergy Count
Number of allergy records in this partition.
Lab Result Count
Number of laboratory result records in this partition.
Immunization Count
Number of immunization records in this partition.
Coverage Count
Number of insurance coverage records in this partition.
Supplement Count
Number of supplement records in this partition.
Vital Sign Days
Number of distinct days covered by vital sign records in this partition. A day count, not a record count.
Heart Rate Days
Number of distinct days covered by heart rate history. A day count, not a record count.
Blood Pressure Days
Number of distinct days covered by blood pressure history. A day count, not a record count.
Activity Days
Number of distinct days covered by activity history. A day count, not a record count.
Sleep Days
Number of distinct nights covered by sleep history. A night count, not a record count.
Involved Resources
Ordered list of the pod resources an agent must read together to detect this interaction.
Severity
Severity of the flagged interaction: low, moderate, high, or critical.
Requires Cross-Provenance
True when detecting this interaction requires correlating resources of different cascade:dataProvenance. The distinguishing property of this class: a single-source consumer cannot find it.
Source Type
Mechanism a reading arrived through, for example healthKit, bluetoothDevice, manualEntry. Describes the transport, NOT the trustworthiness of the data; that is cascade:dataProvenance.
Data Types
Comma-separated list of the data types a device contributed, for example 'heartRate, activity, sleep'.
Version
Version string of a software agent or generator recorded in provenance.
Date
Timestamp a reading or snapshot applies to. Note that health:date is a second, equivalent spelling emitted by a different serializer for the same purpose; readers of history containers must handle both.
Sample Count
Number of underlying samples aggregated into a single reading. A daily resting heart rate of 68 derived from 142 samples is a stronger observation than one derived from 2, and consumers should be able to tell the difference.
LOINC Code
LOINC reference for an observation, as an IRI.