← Catalogue
World Models · legacy example

Personal Health

The health status and care of one person: conditions, observations, encounters with care providers, medications, treatments and care plans, gathered as a record that belongs to the person it describes. It is its own meta-model because person-grain health facts have the strictest custody requirements in the catalogue and a clinical structure of their own, distinct both from population-level health (B14) and from any register that merely certifies a health fact.

AI YAMLAGENTS.mdSource
IDworld.b10-personal-health
Version history0.2.0-legacy
CategoryReference example
IndustryCross-industry
Domainsociety
Tagspersonal, health
Data structure

Bundles and layers

Bundle

healthState

What is currently and historically true of the person's health

Layers

condition`: diagnosed and self-reported conditions with course and resolution · `observationAndResult`: measurements, test results and findings · `allergyAndRisk`: allergies, intolerances and standing risk factors

Bundle

care

What is done about the person's health

Layers

encounter`: contacts with care providers, from visit to admission · `medicationAndTreatment`: prescriptions, administrations and procedures · `carePlan`: agreed goals and coordinated activities across providers

Bundle

custody

The person's control over the record

Layers

recordCustody`: the record as the person's property, provider contributions as entries into it · `disclosureControls`: scoped grants, emergency access and donation of de-identified data

Findings

Catalogue-native findings must describe the information grouped by each layer. This legacy version does not declare them separately.

Questions & artifacts

Questions, artifact requirements and serial naming rules are required by Vercy vNext; they remain unassigned in this reference version.

Service layers

How this specification operates

Dimension & namespace

  • REFERENCE `world.person` (H1): the subject of the record is the person entity governed in its own model
  • REFERENCE `world.identityRegister` (R4): record custody and provider access bind to anchored identities and keys
  • COMPOSE `world.publicHealthAndEpidemiology` (B14): consented or legally mandated notifiable facts flow upward de-identified and at cohort grain, never as the person's record
  • REFERENCE `world.attestationCertificateAndLicense` (R5): immunization and fitness certificates are issued as attestations grounded in record entries
  • REFERENCE `world.socialProvisionAndBenefit` (B13): care-need assessments may read granted extracts when the person applies for care services
  • MIX-IN `world.audit` (S4): every read, contribution and disclosure carries the audit facet
  • imports: hl7-fhir (ALIGN): condition, observation, encounter, medication and care-plan resource semantics
  • imports: snomed-ct (REFERENCE): clinical terms as an externally governed code scheme
  • imports: who-icd (REFERENCE): diagnosis classification as an externally governed code scheme

Canon, patches & standards

  • REFERENCE `world.person` (H1): the subject of the record is the person entity governed in its own model
  • REFERENCE `world.identityRegister` (R4): record custody and provider access bind to anchored identities and keys
  • COMPOSE `world.publicHealthAndEpidemiology` (B14): consented or legally mandated notifiable facts flow upward de-identified and at cohort grain, never as the person's record
  • REFERENCE `world.attestationCertificateAndLicense` (R5): immunization and fitness certificates are issued as attestations grounded in record entries
  • REFERENCE `world.socialProvisionAndBenefit` (B13): care-need assessments may read granted extracts when the person applies for care services
  • MIX-IN `world.audit` (S4): every read, contribution and disclosure carries the audit facet
  • imports: hl7-fhir (ALIGN): condition, observation, encounter, medication and care-plan resource semantics
  • imports: snomed-ct (REFERENCE): clinical terms as an externally governed code scheme
  • imports: who-icd (REFERENCE): diagnosis classification as an externally governed code scheme

Artifact formats & serial data

Format-independent core. Concrete artifact formats and naming prefixes are not declared in this legacy version.

Policies & accepted processes

  • `careProviderAccessContract`: a scoped, time-limited grant by the person letting a provider read and contribute to defined parts of the record
  • `emergencyAccessContract`: break-glass access to the emergency subset, always fully audited and notified to the person afterwards
  • `researchContributionContract`: the person's voluntary donation of de-identified extracts under stated purposes and revocability

Read / add / edit / delete

CRUD procedures and interface bindings are not declared in this legacy version.

Ownership, roles & access

The person owns the record outright, with the strictest default settings in the catalogue: nothing is visible to anyone until the person grants it. All access, including provider contributions and emergency use, is granted through the S1/S2 access and consent models and is fully auditable by the person via S4.

Existing assembly

Objects, relationships, events and projections

Objects

  • `healthRecord`: the person's whole health folder; key attributes: subjectRef, custodyStatus, coverageSpan
  • `condition`: a state of ill or noteworthy health; key attributes: code, onsetAt, course, resolvedAt, severity
  • `observation`: a single measured or noted finding; key attributes: code, value, unit, observedAt, method
  • `allergyIntolerance`: a standing adverse-reaction risk; key attributes: agent, reactionKind, criticality, verifiedAt
  • `encounter`: one contact between the person and a care provider; key attributes: providerRef, kind, startedAt, endedAt, reason
  • `medication`: a medicine prescribed or taken; key attributes: code, dosage, startedAt, endedAt, prescriberRef
  • `treatment`: a procedure or therapy performed or planned; key attributes: code, performedAt, outcome, performerRef
  • `carePlan`: an agreed program of care; key attributes: goals, activities, period, participants

Relationships

  • `healthRecord` -> aggregates -> `encounter` (one-to-many): the record collects all encounters of its subject
  • `observation` -> madeDuring -> `encounter` (many-to-one): findings arise in a care contact
  • `condition` -> evidencedBy -> `observation` (many-to-many): diagnoses rest on findings, findings can support several conditions
  • `treatment` -> addresses -> `condition` (many-to-many): therapy targets one or more conditions
  • `medication` -> prescribedDuring -> `encounter` (many-to-one): prescriptions trace to the contact that produced them
  • `carePlan` -> coordinates -> `treatment` (one-to-many): a plan sequences treatments and activities

Events

  • `conditionDiagnosed`: a condition was identified and entered into the record
  • `observationRecorded`: a measurement or finding was added
  • `encounterClosed`: a care contact concluded and its content was filed
  • `medicationPrescribed`: a medicine was ordered for the person
  • `treatmentAdministered`: a procedure or therapy was carried out
  • `carePlanAgreed`: the person and providers settled a plan of care
  • `allergyIdentified`: a standing adverse-reaction risk was established
  • `conditionResolved`: a condition was recorded as ended

Projections

  • `patientSummaryView`: current conditions, medications, allergies and recent encounters; omits deep history and provider notes
  • `emergencyView`: blood-relevant facts, critical allergies and active medications only; omits everything else
  • `researchView`: de-identified, cohort-ready extracts; omits identifiers, free text and rare-trait combinations that could re-identify
  • `selfView`: the complete record with its full access history, visible only to the person