# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-05T15:00:45Z", "synthesisSha256": "2935218567413d257bbd17e07bf457539bed90bc94e85f247adf0f752e90477b", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-ACT-014", "registryId": "vr.wm-act-014", "name": "Health Care Delivery", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Activities and processes", "industry": [ "Cross-industry" ], "domain": [ "ACT.HCR" ], "tags": [ "health", "care", "delivery", "act.hcr" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-act-014-health-care-delivery/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-act-014", "model": { "registry_id": "vr.wm-act-014", "model_id": "WM-ACT-014", "name": "Health Care Delivery", "entry_kind": "aggregate", "purpose": "Give an agent the system-side context needed to understand, populate, inspect and operate health care delivery: which provider organizations offer which services, through which authorized roles and at which physical, mobile, home or virtual locations; what capacity and readiness exist; how demand queues, allocations, referrals and transfers move people toward care; and how those records are stewarded, verified, measured and disclosed. Encounter lifecycle is delegated to the contained model WM-ACT-018; clinical, personal, workforce-qualification, organizational and estates facts stay with their owning models.", "scope_statement": "This model is the delivery-system aggregate: the standing capability to deliver named health services and the administrative records that show how that capability is published, quantified, allocated, coordinated, measured and governed. It holds offerings, bindings, availability, capacity, readiness, access conditions, queues, capacity commitments, referrals, transfers, delivery measures, disruption declarations and the stewardship, provenance, projection and retention metadata for its own records. It holds encounters only as external references plus delivery-side attribution keys. It is independent of storage format and access interface: JSON, YAML, Markdown, Git, MCP and MongoDB are projections of these semantics, not the semantics themselves.", "in_scope": [ "Service offerings: identity, classification, specialty and delivery modality (inpatient, outpatient, day, mobile, home, virtual), and the provider organization accountable for delivery.", "Bindings between an offering, its delivery locations and the authorized practitioner roles that staff it, carried as references to externally owned organization, place and person records.", "Published availability: operating hours and time zone, planned and unplanned exceptions, access channels, referral method and appointment-required flags.", "Operational capacity statements distinguishing physical stock, staffed and immediately available capacity, and surge or overflow capacity, plus point-in-time occupancy snapshots.", "Service readiness: tracer items across amenities, equipment, standard precautions, diagnostic capacity and commodities, and references to the external dependencies that constrain deliverability.", "Service-level access conditions: eligibility conditions, referral requirement, reach or catchment, languages, communication support and accessibility attributes.", "Demand and queue state: queue-entry registration, priority or urgency class, jurisdiction-bound waiting-clock rule bindings, and queue exits with reasons.", "Supply-side capacity commitment and the exceptions that release committed capacity.", "Referral routing, acceptance, redirection, rejection, expiry and closure, and inter-service transfer of delivery responsibility with milestones.", "Delivery measure specifications and result statements covering availability, readiness, utilization, waiting and continuity, with denominators, stratifiers and comparability caveats.", "Service disruption, diversion, capacity-breach and access-failure declarations with scope and restoration expectations.", "Stewardship and asserted authority per record class, attestation and verification of directory records, identity and time provenance, named disclosure projections, and retention and disposition instructions for this model's own records." ], "out_of_scope": [ "Encounter identity, status lifecycle, participants, actual timing, subject status and admission or discharge disposition, which belong to the contained model WM-ACT-018.", "Clinical content: diagnoses, observations, procedures, medications, care plans and personal longitudinal health episodes.", "Person identity, demographics, patient-recorded preferences and the consent decisions themselves.", "Practitioner qualification, licensure, registration and employment lifecycle, including establishment posts, contracts and rostering systems of record.", "Organization incorporation, ownership, accreditation award and legal-entity lifecycle.", "Facility construction, estates, asset and device lifecycle, and geospatial definition of sites.", "Patient-facing appointment booking records and scheduling workflow.", "Billing, coverage, claims and insurance adjudication.", "Evaluation and enforcement of access-control, consent or disclosure decisions at runtime.", "System audit trails, access logs and audit-event capture.", "Incident investigation, root-cause analysis and clinical outcome attribution arising from a declared disruption.", "Execution of deletion and disposition, and the setting of retention periods themselves.", "Inventory and stock levels of medicines, consumables and equipment." ], "boundary_notes": [ { "neighbor": "WM-ACT-018 Health Care Encounter (contained child model)", "distinction": "FHIR separates the planned event from the actual event and gives the actual encounter its own status set, participants, actualPeriod and discharge disposition. Those semantics are owned by the child model. This model carries an encounter reference plus delivery-side attribution keys (offering, delivery unit, location, fulfilled queue entry, consumed capacity commitment) and never restates encounter status, timing or disposition.", "source_refs": [ "SRC-005" ] }, { "neighbor": "Organization identity and legal-entity lifecycle model", "distinction": "FHIR states that Organization represents the conceptual grouping while Location records where a service occurs, and that the organization property on a record may not be the place of delivery. This model records an organization's participation in delivery, not its incorporation, ownership, accreditation award or partOf hierarchy of record.", "source_refs": [ "SRC-004" ] }, { "neighbor": "Place and site model", "distinction": "FHIR states that Location describes the physical structures managed or operated by an organization, and supports a 'kind' mode for a class of locations used in planning. This model binds offerings to delivery locations and may use class-level location references, but does not own site geometry, estates records or building lifecycle.", "source_refs": [ "SRC-003" ] }, { "neighbor": "Practitioner identity, qualification and licensure model", "distinction": "FHIR places personal qualifications on Practitioner and organizational participation on PractitionerRole, and omits address from PractitionerRole to prevent duplication of the location record. This model holds the role authorization period and its service and location bindings only; licensure state and its verification of record stay with the qualification model and the primary-source registry.", "source_refs": [ "SRC-002", "SRC-010" ] }, { "neighbor": "Scheduling and appointment model", "distinction": "FHIR distinguishes directory availability from bookable supply: HealthcareService works with Schedule to define actual availability, Slot represents available time within a Schedule, and Appointment reserves time and is administrative while the encounter carries clinical implications. This model owns supply-side capacity commitment and releases; it references booking records rather than reproducing them.", "source_refs": [ "SRC-001", "SRC-006" ] }, { "neighbor": "Clinical order and referral-content model", "distinction": "FHIR ServiceRequest carries the clinical need and may support a referral or transfer of care, while Task tracks execution of administrative work. This model holds the routing shell - source, target service, urgency, disposition - and references the coded clinical reason without copying clinical content.", "source_refs": [ "SRC-007" ] }, { "neighbor": "Audit trail model", "distinction": "FHIR distinguishes Provenance as a record-keeping assertion about why a resource exists from AuditEvent, created as events occur to track and audit system activity. This model asserts record provenance for its own artifacts; capture, retention and interpretation of the audit trail are owned elsewhere, and referencing an audit record grants this model no audit-trail semantics.", "source_refs": [ "SRC-009" ] }, { "neighbor": "Organizational quality management system", "distinction": "ISO 7101:2023 specifies requirements for a management system for quality in healthcare organizations and does not define delivery data elements. This model references applicable commitments and certification evidence held by the organization's management system rather than modelling management-system conformity itself.", "source_refs": [ "SRC-014" ] }, { "neighbor": "Population health survey and person-reported unmet need", "distinction": "Eurostat unmet-need indicators derive from EU-SILC, a household survey of persons aged 16 and over reporting their own assessment, with named methodological limits. This model holds service-side access-barrier attributes and may reference survey results as external evidence; it does not own person-reported need.", "source_refs": [ "SRC-016" ] }, { "neighbor": "Retention, disposition and access-authorization policy models", "distinction": "This model declares retention classes, tombstone requirements and projection constraints for its own records; the period-setting policy, the runtime access decision and the execution of disposition are owned by the adopting Dimension's policy models, and a reference to an evaluator or enforcement engine does not transfer those semantics here.", "source_refs": [ "SRC-009", "SRC-010" ] } ] }, "sources": [ { "id": "SRC-001", "title": "HealthcareService - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/healthcareservice.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 4, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T08:41:00Z", "relevance": "Defines the offered service distinct from the providing organization and the delivery location, with category, type, specialty, eligibility, availability, communication, referralMethod, appointmentRequired and endpoint; states that Schedule carries actual bookable availability." }, { "id": "SRC-002", "title": "PractitionerRole - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/practitionerrole.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 4, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T08:41:00Z", "relevance": "Defines a time-bounded set of roles, locations, specialties and services a practitioner may perform for an organization, and places personal qualifications on Practitioner instead, grounding the role-authorization boundary." }, { "id": "SRC-003", "title": "Location - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/location.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 5, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T08:47:00Z", "relevance": "Provides status and operationalStatus, mode instance versus kind, form, hoursOfOperation, managingOrganization, partOf and virtualService, grounding physical, class-level and virtual delivery-location bindings." }, { "id": "SRC-004", "title": "Organization - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/organization.html", "version_or_date": "FHIR v5.0.0 (R5), Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T08:52:00Z", "relevance": "Separates the conceptual organization hierarchy from the location where a service occurs and separates hierarchical partOf from non-hierarchical OrganizationAffiliation, grounding accountable-delivery-unit references." }, { "id": "SRC-005", "title": "Encounter - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/encounter.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 4, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T08:47:00Z", "relevance": "Establishes the actual-encounter status set, actualPeriod, class, serviceProvider, location and admission.dischargeDisposition, and that Appointment establishes the date while Encounter records the actual event; used here only to fix what the contained model WM-ACT-018 owns." }, { "id": "SRC-006", "title": "Appointment - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/appointment.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 3, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:06:00Z", "relevance": "Defines waitlist, booked, cancelled, noshow and fulfilled statuses, cancellationReason, requestedPeriod, priority and slot linkage, and states appointments are administrative while encounters carry clinical implications." }, { "id": "SRC-007", "title": "ServiceRequest - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/servicerequest.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 4, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:12:00Z", "relevance": "States that a ServiceRequest may share the information required to support a referral or transfer of care between practitioners or organizations, with status, intent, priority, performerType, performer and location elements, and separates request from Task execution tracking." }, { "id": "SRC-008", "title": "Measure - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/measure.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 4, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:24:00Z", "relevance": "Supplies the population criteria vocabulary (initial-population, denominator, denominator-exclusion, denominator-exception, numerator, numerator-exclusion, measure-observation), scoring, stratifier, supplementalData and improvementNotation, and separates the definition from the computed MeasureReport." }, { "id": "SRC-009", "title": "Provenance - FHIR v5.0.0", "organization": "HL7 International", "url": "https://hl7.org/fhir/provenance.html", "version_or_date": "FHIR v5.0.0 (R5), Maturity Level 4, Trial Use", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:31:00Z", "relevance": "Distinguishes occurred[x], the period during which the activity occurred, from recorded, the instant at which the activity was recorded, and separates Provenance as a record-keeping assertion from AuditEvent as system audit tracking." }, { "id": "SRC-010", "title": "National Directory of Healthcare Providers & Services (NDH) Implementation Guide", "organization": "HL7 International, Patient Administration Work Group", "url": "https://hl7.org/fhir/us/ndh/", "version_or_date": "1.0.0 STU1, generated 2025-04-10, based on FHIR R4 (4.0.1) and US Core 6.1.0", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T09:12:00Z", "relevance": "Specifies attestation and verification of directory data against primary sources such as licensure boards, periodic re-verification determined by the implementer, and validation against defined data models; motivates freshness and reliability metadata on directory records." }, { "id": "SRC-011", "title": "Service Availability and Readiness Assessment (SARA)", "organization": "World Health Organization", "url": "https://www.who.int/data/data-collection-tools/service-availability-and-readiness-assessment-(sara)", "version_or_date": "Reference manual version 2.2, published 2015-07-01", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T08:52:00Z", "relevance": "Defines service availability (infrastructure, workforce, utilization) and readiness domains (basic amenities, basic equipment, standard precautions, laboratory testing capacity, medicines and commodities), tracer items and the general service readiness index." }, { "id": "SRC-012", "title": "Quality health services: a planning guide", "organization": "World Health Organization", "url": "https://www.who.int/publications/i/item/9789240011632", "version_or_date": "Published 2020-11-17, ISBN 9789240011632", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:00:00Z", "relevance": "Frames quality action at national, district and facility levels with a health-systems approach, supporting the separation between organizational quality commitments and facility-level delivery records." }, { "id": "SRC-013", "title": "Service organizations and integration", "organization": "World Health Organization, Integrated Health Services", "url": "https://www.who.int/teams/integrated-health-services/clinical-services-and-systems/service-organizations-and-integration", "version_or_date": "Current page, accessed 2026-09-05 (no page date published)", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T08:59:00Z", "relevance": "Describes the Framework on Integrated, People-Centred Health Services: a continuum of services coordinated across levels and sites of care, first-contact primary care, effective referral and counter-referral systems and pathways guiding journeys through the system." }, { "id": "SRC-014", "title": "ISO 7101:2023 Healthcare organization management - Management systems for quality in healthcare organizations - Requirements", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/81647.html", "version_or_date": "First edition, published 2023-10", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T08:47:00Z", "relevance": "Published scope requires organizations to demonstrate ability to meet service-user, stakeholder, statutory and regulatory requirements and to create and maintain processes ensuring timely, safe, effective, efficient, equitable and people-centred care; anchors the quality-commitment dimension vocabulary." }, { "id": "SRC-015", "title": "Healthcare resource statistics - beds (Statistics Explained)", "organization": "European Commission, Eurostat", "url": "https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Healthcare_resource_statistics_-_beds", "version_or_date": "Data extracted June 2026; planned article update July 2027", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:00:00Z", "relevance": "Defines hospital beds as regularly maintained, staffed and immediately available for admitted patients, includes occupied and unoccupied beds, and excludes recovery trolleys, same-day-care beds and provisional or temporary beds; splits curative, rehabilitative, long-term and other beds." }, { "id": "SRC-016", "title": "Unmet health care needs statistics (Statistics Explained)", "organization": "European Commission, Eurostat", "url": "https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Unmet_health_care_needs_statistics", "version_or_date": "Last updated July 2025; source EU-SILC", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:24:00Z", "relevance": "Defines self-reported unmet need and the reason taxonomy including waiting list, cost, distance or transport, lack of time, fear and lack of knowledge, with reference population and comparability caveats used to bound access measurement claims." }, { "id": "SRC-017", "title": "Hospital Respiratory Data (HRD) Reporting, National Healthcare Safety Network", "organization": "Centers for Disease Control and Prevention (NCEZID/DHQP)", "url": "https://www.cdc.gov/nhsn/psc/hospital-respiratory-reporting.html", "version_or_date": "Last reviewed 2025-06-18; reporting effective 2024-11-01 under the FY 2025 IPPS/LTCH PPS Final Rule", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:18:00Z", "relevance": "Mandates weekly facility reporting of inpatient and ICU bed capacity and occupancy overall and by bed type, with staffed inpatient beds defined as currently set up, staffed and able to be used including surge, overflow and observation beds, and named facility types obliged to report." }, { "id": "SRC-018", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "July 2002, Proposed Standard (updated by RFC 9557)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T09:31:00Z", "relevance": "Requires seconds in partial-time, defines time-offset as 'Z' or a numeric offset, reserves '-00:00' for an unknown local offset, and permits second value 60 only in leap-second months; the normative basis for this model's timestamp rule." }, { "id": "SRC-019", "title": "HL7 FHIR R5 Encounter - scope, status, class, admission versus Appointment", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/encounter.html", "version_or_date": "5.0.0 (2023-03-26)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Defines the contained-child boundary: encounter status, class, subjectStatus, admission, EncounterHistory and jurisdictional variance in encounter grain belong to WM-ACT-018." }, { "id": "SRC-020", "title": "HL7 FHIR R5 Organization", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/organization.html", "version_or_date": "5.0.0 (2023-03-26)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Identifier, type, name, alias, partOf, active and OrganizationAffiliation semantics for the provider-registry layer." }, { "id": "SRC-021", "title": "HL7 FHIR R5 PractitionerRole", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/practitionerrole.html", "version_or_date": "5.0.0 (2023-03-26)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Role identifiers, period, code, specialty, location, healthcareService, availableTime; qualifications do not imply role; unnamed-occupancy pattern; split instances when availability differs." }, { "id": "SRC-022", "title": "HL7 FHIR R5 Location", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/location.html", "version_or_date": "5.0.0 (2023-03-26)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "status versus operationalStatus, mode instance|kind, type, partOf, hoursOfOperation, building/ward/room/bed, mobile clinic, ambulance, patient-home kind, and the boundary excluding body locations." }, { "id": "SRC-023", "title": "HL7 FHIR R5 HealthcareService - scope and SOA exclusion", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/healthcareservice.html", "version_or_date": "5.0.0 (2023-03-26)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Care service offering semantics: providedBy, offeredIn, location, category, type, specialty, eligibility, program, referralMethod, appointmentRequired, availability, active versus notAvailable, directory and costing examples." }, { "id": "SRC-024", "title": "HL7 FHIR R5 ServiceRequest - patient-specific request for a service", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/servicerequest.html", "version_or_date": "5.0.0 (2023-03-26)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Referral and transfer-of-care request semantics: identifier, requisition, status, intent, priority, performer, basedOn, replaces, encounter and subject references." }, { "id": "SRC-025", "title": "HL7 FHIR R5 Schedule", "organization": "HL7 International", "url": "https://hl7.org/fhir/schedule.html", "version_or_date": "5.0.0 (2023-03-26)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Schedule actors (HealthcareService, Practitioner, PractitionerRole, Location, Device), planning horizon and group-therapy seats as multiple slots." }, { "id": "SRC-026", "title": "HL7 FHIR R5 Slot - element definitions", "organization": "HL7 International", "url": "https://www.hl7.org/fhir/slot-definitions.html", "version_or_date": "5.0.0 (2023-03-26)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Slot status values busy|free|busy-unavailable|busy-tentative|entered-in-error, overbooked flag and serviceType as HealthcareService." }, { "id": "SRC-027", "title": "IHE Mobile Care Services Discovery (mCSD) v4.0.0 Volume 1", "organization": "IHE International", "url": "https://profiles.ihe.net/ITI/mCSD/volume-1.html", "version_or_date": "4.0.0 (2025-05-21)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Facility as a pairing of Location and Organization; Organization, Practitioner, PractitionerRole, Healthcare Service; ITI-90 Find Matching Care Services, ITI-91, ITI-130 feed; federated deployments with time-stamped updates and deprecation by status; HR capacity by facility and cadre; security considerations. Based on FHIR R4." }, { "id": "SRC-028", "title": "UNSD Classification of Health Care Providers (ICHA-HP), SHA 2011", "organization": "OECD/WHO/Eurostat via UNSD", "url": "https://unstats.un.org/unsd/classifications/Family/Detail/1037", "version_or_date": "SHA 2011", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Statistical classification of organisations contributing to provision of health care goods and services (HP.1-HP.9), used as provider class." }, { "id": "SRC-029", "title": "Classifying health workers (ISCO-08 mapping)", "organization": "World Health Organization", "url": "https://www.who.int/publications/m/item/classifying-health-workers", "version_or_date": "2019-07-31", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Five broad groupings of health workers mapped to ISCO-08 skill level and specialisation; basis for cadre and profession codes." }, { "id": "SRC-030", "title": "WHO Master Facility List Resource Package", "organization": "World Health Organization", "url": "https://www.who.int/publications/i/item/9789241516495", "version_or_date": "2019", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Uniquely identify, locate and contact a health facility; multiple hierarchies (administrative, supply chain, reporting); establishment and maintenance of a master facility list." }, { "id": "SRC-031", "title": "ISO 13940 System of concepts to support continuity of care (DIS ed.2 landing)", "organization": "ISO/TC 215", "url": "https://www.iso.org/obp/ui/en/#iso:std:iso:13940:dis:ed-2:v1:en", "version_or_date": "2015 published; DIS ed.2 in revision", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Scope statement that the standard does not standardise specific care processes; second edition adds social care. Full concept table was not retrieved (OBP blocked)." }, { "id": "SRC-032", "title": "NHS Data Model and Dictionary - REFERRAL TO TREATMENT PERIOD STATUS", "organization": "NHS England", "url": "https://www.datadictionary.nhs.uk/data_elements/referral_to_treatment_period_status.html", "version_or_date": "current dictionary page retrieved 2026-09-05", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "England profile for waiting-time clock status national codes (10, 11, 12, 20, 21, 30-34) including clock stops; explicitly not a universal state machine." }, { "id": "SRC-033", "title": "NHS England Waiting List Minimum Data Set (WLMDS)", "organization": "NHS England", "url": "https://www.england.nhs.uk/statistics/statistical-work-areas/rtt-waiting-times/wlmds/", "version_or_date": "WLMDS, from April 2024 publication note", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Weekly provider submission of open pathways, clock starts and clock stops; provider responsibility for accuracy; management information versus official statistics." }, { "id": "SRC-034", "title": "NHS England Digital - Organisation Data Service ORD API (catalogue entry)", "organization": "NHS England Digital", "url": "https://digital.nhs.uk/developer/api-catalogue/organisation-data-service-ord", "version_or_date": "ORD API, page retrieved via search 2026-09-05", "source_type": "registry", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-05T00:00:00Z", "relevance": "Master provider registry fields: ODS code, name, open/close/last-change dates, active/inactive status, address, succession and relationships. Full page fetch was blocked; fields taken from the catalogue search snippet." } ], "structure": { "bundles": [ { "id": "delivery-network", "name": "Delivery network", "description": "Who offers which health services, through which authorized roles, and at which physical, mobile, home or virtual delivery locations.", "rationale": "FHIR separates the offered service from the providing organization, the delivery location and the authorized practitioner role, and forbids duplicating address or qualification data across them. The delivery network is therefore a binding structure over externally owned entities, and it is the first thing an agent must resolve before any capacity, queue or flow question can be answered.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004" ], "layers": [ { "id": "provider-service-topology", "name": "Provider-service topology", "description": "The offered service, its classification and modality, and its bindings to an accountable provider organization and to delivery locations.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004" ], "findings": [ { "id": "service-offering-identity", "name": "Service offering identity and classification", "description": "The identity, classification, specialty and modality of a care service that a provider organization offers, held distinct from the organization that provides it and the place where it is delivered.", "source_refs": [ "SRC-001", "SRC-013" ], "questions": [ { "id": "q-service-identifier", "text": "Which identifier authoritatively distinguishes this service offering from every other offering of the same provider?", "kind": "identity", "answer_data": [ "Master-system service identifier and its issuing system", "Governed global identifier or IRI where one is published", "Dimension-minted UUID or ULID used only as a fallback" ] }, { "id": "q-service-classification", "text": "How is the offering classified by category, service type and specialty, and against which governed code systems?", "kind": "classification", "answer_data": [ "Service category code with code system and version", "Service type code with code system and version", "Specialty code with code system and version" ] }, { "id": "q-service-modality", "text": "Which delivery modalities does the offering support, and is each modality independently deliverable?", "kind": "definition", "answer_data": [ "Modality enumeration (inpatient, outpatient, day, mobile, home, virtual)", "Per-modality deliverable flag", "Constraints where a modality is only available with another" ] }, { "id": "q-service-status-period", "text": "What is the offering's active status and effective period, and what supersedes it when it is withdrawn or replaced?", "kind": "lifecycle", "answer_data": [ "Active flag and status code", "Effective period start and end", "Reference to the superseding offering record" ] } ], "data_elements": [ { "id": "de-service-offering-id", "name": "Service offering identifier", "description": "Identifier of the offering under the identity priority of this model.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-service-category-code", "name": "Service category code", "description": "Broad classification of the offering with code system and version.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-service-specialty-code", "name": "Service specialty code", "description": "Clinical specialty handled by the offering, coded against a governed terminology.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-service-modality", "name": "Delivery modality", "description": "Enumerated modality through which the offering is delivered.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-service-active-period", "name": "Offering effective period", "description": "Start and end of the period in which the offering is in active use.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "service-offering-entry", "name": "Service offering directory entry", "description": "The record of record for one offered service, carrying identity, classification, modality, status and effective period.", "media_or_form": [ "structured record", "directory entry", "catalogue row" ], "serial": false, "identity_strategy": "Keyed by the authoritative master-system service identifier and its issuing system; where none exists, a Dimension-minted ULID is recorded together with the system that minted it. No date component is used in the key.", "source_refs": [ "SRC-001", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "provider-location-binding", "name": "Provider and delivery-location binding", "description": "The binding of an offering to the accountable provider organization and delivery unit and to one or more delivery locations, including virtual, mobile and home delivery points, held as references.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004" ], "questions": [ { "id": "q-binding-accountable-unit", "text": "Which provider organization and internal delivery unit is accountable for the offering at each location?", "kind": "composition", "answer_data": [ "Provider organization reference and issuing system", "Delivery unit reference within the organization hierarchy", "Accountability start and end" ] }, { "id": "q-binding-location-set", "text": "At which physical, mobile, home or virtual locations is the offering delivered, and how is a virtual delivery point represented?", "kind": "spatial", "answer_data": [ "Location references with instance or class mode", "Location form (building, room, vehicle, area)", "Virtual service connection detail reference" ] }, { "id": "q-binding-cardinality", "text": "How are many-to-many bindings between offerings, locations and delivery units represented without duplicating the location or organization record?", "kind": "relationship", "answer_data": [ "Binding record identifier", "Referenced entity identifiers only, with no copied attributes", "Rule prohibiting local address, geometry or hierarchy fields" ] } ], "data_elements": [ { "id": "de-provider-org-ref", "name": "Provider organization reference", "description": "Reference to the externally owned organization accountable for delivery.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-delivery-unit-ref", "name": "Delivery unit reference", "description": "Reference to the internal unit within the provider hierarchy that delivers the offering.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-delivery-location-ref", "name": "Delivery location reference", "description": "Reference to a location where the offering is delivered, in instance or class mode.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-virtual-service-detail", "name": "Virtual delivery point detail", "description": "Connection detail for a virtual delivery point, referenced rather than restated.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "delivery-binding-record", "name": "Delivery binding record", "description": "The record binding one offering to one accountable delivery unit and one delivery location for a stated period.", "media_or_form": [ "structured record", "association row" ], "serial": false, "identity_strategy": "Composite key of offering identifier, delivery unit reference and location reference, resolved to a stable Dimension-minted ULID when the composite is not globally unique.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004" ] } ], "inline_only_rationale": null } ] }, { "id": "authorized-delivery-roles", "name": "Authorized delivery roles", "description": "The time-bounded authorizations under which practitioner roles deliver named services at named locations, and whether those authorizations actually cover operating periods.", "source_refs": [ "SRC-002", "SRC-010" ], "findings": [ { "id": "role-authorization-binding", "name": "Delivery role authorization", "description": "A time-bounded authorization for a practitioner role to deliver named services at named locations for a provider organization, referencing the person and their qualifications without restating them.", "source_refs": [ "SRC-002", "SRC-010" ], "questions": [ { "id": "q-role-authority", "text": "Under whose authority is a practitioner role authorized to deliver this service at this location?", "kind": "authority", "answer_data": [ "Authorizing organization reference", "Authorization instrument reference", "Scope limits attached to the authorization" ] }, { "id": "q-role-period", "text": "What is the authorization period of the role, and how are lapses, suspensions and renewals represented here without restating licensure?", "kind": "temporal", "answer_data": [ "Authorization period start and end", "Active flag with reason for inactivity", "Reference to the licensure record that governs eligibility to hold the role" ] }, { "id": "q-role-service-binding", "text": "Which services and locations does the role cover, and how is the role kept distinct from the person holding it?", "kind": "relationship", "answer_data": [ "Service offering references covered by the role", "Location references covered by the role", "Practitioner reference with no copied personal attributes" ] } ], "data_elements": [ { "id": "de-practitioner-role-ref", "name": "Practitioner role reference", "description": "Reference to the role record binding a person to an organization for delivery.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-role-authorization-period", "name": "Role authorization period", "description": "Period during which the practitioner is authorized to act in the role.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-role-specialty-code", "name": "Role specialty code", "description": "Specialty or functional role description, coded against a governed terminology.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-role-service-ref", "name": "Role service coverage reference", "description": "Service offerings that the role is authorized to deliver.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "role-authorization-record", "name": "Delivery role authorization record", "description": "The record of one role's authorization to deliver stated services at stated locations for a stated period.", "media_or_form": [ "structured record", "directory entry" ], "serial": false, "identity_strategy": "Keyed by the master-system role identifier where the workforce or directory system issues one; otherwise a Dimension-minted ULID bound to the practitioner reference, organization reference and authorization start.", "source_refs": [ "SRC-002", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "role-coverage-and-vacancy", "name": "Role coverage and vacancy state", "description": "A derived, time-bounded assertion of whether authorized roles cover an offering's operating periods, including uncovered periods, temporary cover and on-call arrangement references, expressed as delivery supply rather than as staff rostering.", "source_refs": [ "SRC-002", "SRC-011" ], "questions": [ { "id": "q-coverage-state", "text": "Is the offering covered by at least the minimum authorized roles for each operating period, and what state applies when it is not?", "kind": "state", "answer_data": [ "Coverage state code per operating period", "Minimum role requirement per period", "Uncovered period start and end" ] }, { "id": "q-coverage-gap-cause", "text": "What distinguishes an unfilled establishment post from a temporarily uncovered operating period, and which of the two is recorded here?", "kind": "definition", "answer_data": [ "Definition boundary statement", "Reference to the workforce system holding establishment posts", "Local scope limited to uncovered delivery periods" ] }, { "id": "q-coverage-evidence", "text": "What evidence and observation time support a coverage assertion, and how confident is it?", "kind": "evidence", "answer_data": [ "Observation instant of the coverage assertion", "Confidence grade", "References to the rota or availability records consulted" ] } ], "data_elements": [ { "id": "de-coverage-state", "name": "Coverage state", "description": "Coded state of role coverage for an offering over a stated period.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-coverage-observed-at", "name": "Coverage observation time", "description": "Instant at which the coverage state was observed or derived.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-coverage-confidence", "name": "Coverage confidence grade", "description": "Confidence attached to the derived coverage assertion.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-uncovered-period", "name": "Uncovered period", "description": "Period in which the minimum authorized role requirement was not met.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Coverage is a derived assertion computed from role authorizations, published availability and externally owned rota, contract and establishment records. It has no independent document of record in this model, so it is carried as inline state with its observation time and confidence. Creating an artifact would produce a second, weaker copy of the workforce system of record and would imply this model owns rostering." } ] } ] }, { "id": "availability-and-capacity", "name": "Availability and operational capacity", "description": "What the delivery network publishes as available, what it can actually deliver, and whether the inputs required to deliver are in place.", "rationale": "FHIR distinguishes published directory availability from bookable supply defined through Schedule, while Eurostat and CDC/NHSN define capacity counts on incompatible bases (staffed and immediately available versus set-up, staffed and usable including surge and overflow). WHO SARA adds readiness as a separate construct from availability. These three constructs must be kept apart or capacity questions cannot be answered safely.", "source_refs": [ "SRC-001", "SRC-011", "SRC-015", "SRC-017" ], "layers": [ { "id": "published-availability", "name": "Published availability", "description": "The operating hours, exceptions and access channels that the delivery network publishes, distinguished from bookable operational supply.", "source_refs": [ "SRC-001", "SRC-003" ], "findings": [ { "id": "service-availability-schedule", "name": "Published availability and access channel", "description": "The published operating hours, time zone, planned and unplanned exceptions, access channels, referral method and appointment-required flags of an offering at a location, distinguished from the bookable supply held by the scheduling system.", "source_refs": [ "SRC-001", "SRC-003", "SRC-006" ], "questions": [ { "id": "q-availability-hours", "text": "What are the published operating hours and time zone of the offering at each delivery location?", "kind": "temporal", "answer_data": [ "Days of week and open and close times", "IANA time zone identifier", "All-day or closed flag" ] }, { "id": "q-availability-exception", "text": "How are planned closures, holiday exceptions and unplanned suspensions of published availability represented?", "kind": "exception", "answer_data": [ "Exception period with start and end", "Exception reason description", "Whether the exception is planned or unplanned" ] }, { "id": "q-availability-vs-bookable", "text": "How does published availability differ from bookable supply, and which system of record owns each?", "kind": "definition", "answer_data": [ "Boundary statement separating published hours from bookable slots", "Reference to the scheduling system of record", "Rule that bookable slot inventory is never mirrored here" ] }, { "id": "q-availability-access-channel", "text": "Through which channels can the offering be reached, is a referral or appointment required, and by which method are referrals accepted?", "kind": "access", "answer_data": [ "Access channel enumeration", "Appointment-required flag", "Referral method codes and technical endpoint references" ] } ], "data_elements": [ { "id": "de-operating-hours", "name": "Operating hours", "description": "Published days and times at which the offering operates at a location, with time zone.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-availability-exception", "name": "Availability exception", "description": "A stated period in which published availability does not apply, with reason.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-appointment-required", "name": "Appointment required flag", "description": "Whether access to the offering requires a prior appointment.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-referral-method", "name": "Referral method code", "description": "Method by which the offering accepts referrals.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-access-channel", "name": "Access channel code", "description": "Channel through which the offering can be reached (walk-in, telephone, electronic referral, endpoint).", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "published-availability-statement", "name": "Published availability statement", "description": "The published statement of when and how an offering can be accessed at a location, suitable for a public directory projection.", "media_or_form": [ "structured record", "directory entry", "published statement" ], "serial": false, "identity_strategy": "Keyed by the delivery binding record identifier plus a version counter; supersession is recorded rather than the statement being edited in place.", "source_refs": [ "SRC-001", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "operational-capacity", "name": "Operational capacity", "description": "Quantified deliverable capacity and its point-in-time occupancy, with the definitional basis made explicit.", "source_refs": [ "SRC-015", "SRC-017" ], "findings": [ { "id": "capacity-statement", "name": "Capacity statement", "description": "A quantified statement of deliverable capacity for an offering at a location over a period, with capacity type, unit and an explicit basis distinguishing physical stock, staffed and immediately available capacity, and surge or overflow capacity.", "source_refs": [ "SRC-015", "SRC-017", "SRC-011" ], "questions": [ { "id": "q-capacity-unit", "text": "What capacity type, unit and quantity are asserted, and over which period or at which instant?", "kind": "measurement", "answer_data": [ "Capacity type code (beds, treatment places, sessions, procedures, contacts)", "Quantity with unit of measure", "Period start and end, or instant" ] }, { "id": "q-capacity-staffed-vs-physical", "text": "Does the quantity count physical stock, staffed and immediately available capacity, or surge and overflow capacity, and which definition profile applies?", "kind": "definition", "answer_data": [ "Capacity basis code", "Definition profile reference naming inclusions and exclusions", "Explicit statement on inclusion of surge, overflow, observation and same-day places" ] }, { "id": "q-capacity-source", "text": "Which system asserted the capacity, when was it observed, and when was it received here?", "kind": "provenance", "answer_data": [ "Source system identifier", "Observation time", "Ingestion time" ] }, { "id": "q-capacity-reporting-obligation", "text": "To which authority and on what cadence must this capacity be reported, and under which instrument?", "kind": "requirement", "answer_data": [ "Recipient authority reference", "Reporting cadence and due window", "Reference to the obligating instrument or rule" ] } ], "data_elements": [ { "id": "de-capacity-type", "name": "Capacity type code", "description": "The kind of capacity being quantified.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-015" ] }, { "id": "de-capacity-quantity", "name": "Capacity quantity", "description": "Numeric quantity with its unit of measure.", "value_kind": "quantity", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-017" ] }, { "id": "de-capacity-period", "name": "Capacity period", "description": "Period over which the capacity quantity holds.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "de-capacity-basis", "name": "Capacity basis code", "description": "Whether the quantity counts physical, staffed and immediately available, or surge capacity.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-017" ] }, { "id": "de-capacity-observed-at", "name": "Capacity observation time", "description": "Instant at which the capacity quantity was observed or asserted.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-018" ] } ], "artifacts": [ { "id": "capacity-statement-record", "name": "Capacity statement record", "description": "One immutable, versioned assertion of deliverable capacity for an offering, location, basis and period.", "media_or_form": [ "structured record", "periodic return", "reporting submission" ], "serial": true, "identity_strategy": "Keyed by the reporting entity's master-system submission identifier where one exists; otherwise by delivery binding identifier, capacity type, basis and period plus a monotonic sequence number that is not derived from a timestamp.", "source_refs": [ "SRC-017", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "capacity-occupancy-snapshot", "name": "Capacity occupancy snapshot", "description": "A point-in-time count of occupied and available capacity against a named capacity statement, with an explicit snapshot rule separating single-instant snapshots from period aggregations.", "source_refs": [ "SRC-017", "SRC-015", "SRC-003" ], "questions": [ { "id": "q-occupancy-snapshot-instant", "text": "At which instant is occupancy measured, and is the value a single-instant snapshot or an aggregation over a reporting period?", "kind": "temporal", "answer_data": [ "Snapshot instant with offset", "Snapshot versus aggregation flag", "Reporting period when aggregated" ] }, { "id": "q-occupancy-denominator", "text": "Which capacity statement is the denominator for an occupancy figure, and are surge and overflow units included in it?", "kind": "measurement", "answer_data": [ "Capacity statement reference", "Occupied count and available count", "Inclusion flags for surge and overflow units" ] }, { "id": "q-occupancy-suppression", "text": "When must small-number occupancy values be suppressed or aggregated before they are disclosed?", "kind": "privacy", "answer_data": [ "Suppression threshold", "Aggregation level applied", "Projection in which the rule applies" ] } ], "data_elements": [ { "id": "de-occupied-count", "name": "Occupied count", "description": "Number of capacity units occupied at the snapshot instant.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "de-available-count", "name": "Available count", "description": "Number of capacity units available at the snapshot instant.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-snapshot-instant", "name": "Snapshot instant", "description": "Instant to which the occupancy counts refer.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-017", "SRC-018" ] }, { "id": "de-capacity-statement-ref", "name": "Capacity statement reference", "description": "Reference to the capacity statement that provides the denominator.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "occupancy-snapshot-record", "name": "Occupancy snapshot record", "description": "One immutable occupancy observation against a named capacity statement at a stated instant.", "media_or_form": [ "structured record", "periodic return" ], "serial": true, "identity_strategy": "Keyed by capacity statement identifier plus a monotonic sequence number within the reporting cycle; the snapshot instant is an attribute and never the identifier.", "source_refs": [ "SRC-017" ] } ], "inline_only_rationale": null } ] }, { "id": "service-readiness", "name": "Service readiness", "description": "Whether the tracer inputs required to deliver an offering are present, and which external records those inputs depend on.", "source_refs": [ "SRC-011" ], "findings": [ { "id": "readiness-tracer-and-dependency", "name": "Readiness tracer items and input dependencies", "description": "The readiness of an offering expressed as tracer items across amenities, equipment, standard precautions, diagnostic capacity and commodities, together with references to the externally owned workforce, equipment, estates and commodity records those items depend on.", "source_refs": [ "SRC-011", "SRC-012" ], "questions": [ { "id": "q-readiness-tracer-set", "text": "Which tracer items must be present for this offering to count as ready, and to which readiness domain does each belong?", "kind": "requirement", "answer_data": [ "Readiness domain enumeration", "Tracer item list with present or absent status", "Domain-to-item mapping and profile reference" ] }, { "id": "q-readiness-assessment-method", "text": "By what method, on which date and by which assessor was readiness observed?", "kind": "evidence", "answer_data": [ "Assessment method identifier and version", "Assessment date and observation time", "Assessor reference" ] }, { "id": "q-readiness-dependency-ref", "text": "Which external inventory, workforce or estates records does a readiness item reference rather than restate?", "kind": "relationship", "answer_data": [ "Dependency reference with owning model", "Dependency kind", "Statement that stock levels and asset records are not held locally" ] }, { "id": "q-readiness-index-derivation", "text": "How is a composite readiness index derived from domain scores, and what does a missing domain do to it?", "kind": "measurement", "answer_data": [ "Index calculation rule and version", "Domain score inputs", "Handling of missing or not-applicable domains" ] } ], "data_elements": [ { "id": "de-readiness-domain", "name": "Readiness domain code", "description": "Domain to which a readiness tracer item belongs.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "de-tracer-item-status", "name": "Tracer item status set", "description": "Collection of tracer items with present, absent or not-applicable status.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-011" ] }, { "id": "de-readiness-index-score", "name": "Readiness index score", "description": "Composite readiness score derived from domain scores.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-readiness-assessed-at", "name": "Readiness assessment time", "description": "Instant at which the readiness assessment was performed.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-011", "SRC-018" ] } ], "artifacts": [ { "id": "readiness-assessment-record", "name": "Service readiness assessment record", "description": "One completed readiness assessment for an offering at a location, with tracer results, method and assessor.", "media_or_form": [ "structured record", "assessment return", "survey response set" ], "serial": true, "identity_strategy": "Keyed by the assessment programme's master-system assessment identifier where one exists; otherwise by delivery binding identifier, method version and a monotonic assessment sequence number.", "source_refs": [ "SRC-011" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "demand-access-allocation", "name": "Demand, access and allocation", "description": "The conditions under which people may reach an offering, the demand waiting for it, and the supply-side commitment of capacity against that demand.", "rationale": "FHIR carries eligibility, communication and referral requirements on the offering, and models waiting as an appointment status rather than as a governed clock. Eurostat records waiting lists, cost and distance as distinct reasons for unmet need. Access conditions, queue state and capacity commitment are therefore three separate concerns, and the waiting clock itself must be bound to a jurisdiction profile rather than assumed.", "source_refs": [ "SRC-001", "SRC-006", "SRC-007", "SRC-016" ], "layers": [ { "id": "access-conditions", "name": "Access conditions", "description": "Service-level eligibility, reach and accommodation attributes that determine who can obtain the offering and how.", "source_refs": [ "SRC-001", "SRC-016" ], "findings": [ { "id": "eligibility-and-entry-condition", "name": "Service eligibility and entry condition", "description": "The conditions under which a person may receive an offering, expressed as coded service-level conditions and references to governing policy, never as an individual eligibility determination.", "source_refs": [ "SRC-001", "SRC-013" ], "questions": [ { "id": "q-eligibility-condition", "text": "Which eligibility conditions and qualifying comments apply to the offering, and against which policy are they defined?", "kind": "constraint", "answer_data": [ "Eligibility condition codes", "Free-text qualifying comment", "Governing policy reference" ] }, { "id": "q-eligibility-authority", "text": "Which authority sets each eligibility rule, and in which jurisdiction or profile does it apply?", "kind": "authority", "answer_data": [ "Setting authority reference", "Jurisdiction or profile identifier", "Rule effective period" ] }, { "id": "q-eligibility-determination-owner", "text": "Where is an individual person's eligibility determination recorded, given that this model holds only the service-level rule?", "kind": "decision", "answer_data": [ "Owning model reference for personal determinations", "Boundary statement excluding personal adjudication", "Reference pattern used when a queue entry cites a determination" ] } ], "data_elements": [ { "id": "de-eligibility-code", "name": "Eligibility condition code", "description": "Coded condition qualifying access to the offering.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-eligibility-comment", "name": "Eligibility comment", "description": "Narrative qualifying the coded eligibility condition.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-eligibility-policy-ref", "name": "Eligibility policy reference", "description": "Reference to the externally owned policy that sets the condition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-referral-required", "name": "Referral required flag", "description": "Whether entry to the offering requires a prior referral.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Eligibility here is a service-level condition expressed as coded values and references to externally owned policy, carried on the service offering entry already declared as an artifact in this model. An additional artifact would either duplicate the policy instrument owned by the setting authority or imply that this model adjudicates individual eligibility, which is explicitly out of scope." }, { "id": "access-accommodation-and-reach", "name": "Access accommodation and reach", "description": "The reach of an offering over a population or area and the accommodations it provides, including languages, communication support, physical accessibility and remote or home delivery.", "source_refs": [ "SRC-001", "SRC-003", "SRC-016", "SRC-013" ], "questions": [ { "id": "q-access-reach-area", "text": "Which population or geographic area does the offering serve, and is service refused outside it?", "kind": "spatial", "answer_data": [ "Coverage area reference", "Population group reference", "Behaviour when a request originates outside the area" ] }, { "id": "q-access-communication", "text": "Which languages and communication supports are available, and are they available for every modality?", "kind": "access", "answer_data": [ "Communication language codes", "Interpretation or assistive support flags", "Per-modality availability of each support" ] }, { "id": "q-access-adjustment", "text": "Which physical-access and reasonable-adjustment attributes are asserted, and against which standard are they coded?", "kind": "requirement", "answer_data": [ "Accessibility attribute codes with code system", "Standard or profile against which they are asserted", "Verification status of each asserted attribute" ] } ], "data_elements": [ { "id": "de-communication-language", "name": "Communication language code", "description": "Language in which the offering can communicate with service users.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-coverage-area-ref", "name": "Coverage area reference", "description": "Reference to the area or population the offering serves.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-accessibility-attribute", "name": "Accessibility attribute code", "description": "Coded accessibility or accommodation characteristic of the offering or its location.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-010" ] }, { "id": "de-remote-delivery-supported", "name": "Remote delivery supported flag", "description": "Whether the offering can be delivered remotely or in the service user's home.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "These are descriptive attributes of the service offering and its delivery-location bindings, both of which are already declared as artifacts in this model. Representing them again as a separate artifact would fragment the directory record and create two competing systems of record for the same published fields, which is precisely what the directory verification rules are designed to prevent." } ] }, { "id": "queue-and-waiting", "name": "Queue and waiting state", "description": "Registered demand awaiting delivery, the rules that turn it into waiting time, and how it leaves the queue.", "source_refs": [ "SRC-006", "SRC-007", "SRC-016" ], "findings": [ { "id": "demand-registration-entry", "name": "Demand registration entry", "description": "A registered unit of demand awaiting delivery of a named offering, carrying listing time, priority or urgency class and requested service, and referencing the subject without inlining personal or clinical content.", "source_refs": [ "SRC-006", "SRC-007" ], "questions": [ { "id": "q-queue-entry-identity", "text": "Which identifier distinguishes a queue entry, and how are duplicate registrations for the same demand detected?", "kind": "identity", "answer_data": [ "Queue entry identifier and issuing system", "Duplicate-detection key set", "Merge or link reference when duplicates are found" ] }, { "id": "q-queue-priority-class", "text": "Which priority or clinical urgency class is assigned, under which scheme, and who may change it?", "kind": "classification", "answer_data": [ "Priority class code and scheme version", "Authorized changer role", "History of class changes with times" ] }, { "id": "q-queue-subject-reference", "text": "How is the subject of the demand referenced without inlining any clinical or demographic content?", "kind": "privacy", "answer_data": [ "Subject reference and issuing system", "Prohibited field list", "Pseudonymisation rule for operational projections" ] }, { "id": "q-queue-requested-service", "text": "Which offering, delivery unit or unnamed service pool is the demand registered against?", "kind": "relationship", "answer_data": [ "Requested offering reference", "Delivery unit or pool reference", "Named versus unnamed target flag" ] } ], "data_elements": [ { "id": "de-queue-entry-id", "name": "Queue entry identifier", "description": "Identifier of the registered unit of demand.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-requested-service-ref", "name": "Requested service reference", "description": "Reference to the offering the demand is registered against.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "de-listing-instant", "name": "Listing instant", "description": "Instant at which the demand was registered in the queue.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "de-priority-class", "name": "Priority class code", "description": "Priority or clinical urgency class assigned to the entry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-subject-ref", "name": "Subject reference", "description": "Reference to the person or group the demand concerns, held as a reference only.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "queue-entry-record", "name": "Queue entry record", "description": "The record of one registered unit of demand, its priority class, listing time, current state and exit.", "media_or_form": [ "structured record", "waiting list row" ], "serial": false, "identity_strategy": "Keyed by the provider's master-system waiting-list entry identifier where one exists; otherwise a Dimension-minted ULID. The listing instant is an attribute and is never used as the identifier.", "source_refs": [ "SRC-006", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "waiting-clock-rule", "name": "Waiting clock rule binding", "description": "The definition set that turns queue entries into waiting times: clock start event, pause or exclusion conditions, stop events and censoring. These rules are supplied by an adopting jurisdiction profile; no universal rule is asserted, and the national rule suites needed to fix them were not retrievable in this pass.", "source_refs": [ "SRC-006", "SRC-007", "SRC-016" ], "questions": [ { "id": "q-clock-start-event", "text": "Which event starts the waiting clock for this offering, and does a re-referral start a new clock or continue the existing one?", "kind": "definition", "answer_data": [ "Clock start event code and profile reference", "Re-referral behaviour rule", "Instant recorded as the clock start" ] }, { "id": "q-clock-pause-rule", "text": "Under what conditions does the clock pause or exclude days, and how are those periods evidenced?", "kind": "temporal", "answer_data": [ "Pause or exclusion reason codes", "Excluded period start and end", "Evidence reference for each excluded period" ] }, { "id": "q-clock-censoring", "text": "How are completed waits distinguished from ongoing waits that are still censored when a waiting time is published?", "kind": "measurement", "answer_data": [ "Completed versus censored flag", "Census instant for censored waits", "Rule for reporting the two populations separately" ] }, { "id": "q-clock-profile-binding", "text": "Which jurisdiction profile supplies the clock rules in force, and what happens to entries created under a superseded profile?", "kind": "validation", "answer_data": [ "Profile identifier and version", "Profile effective period", "Migration or recomputation rule for entries under a prior profile" ] } ], "data_elements": [ { "id": "de-clock-start-event-code", "name": "Clock start event code", "description": "Coded event that starts the waiting clock under the bound profile.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-clock-pause-reason", "name": "Clock pause reason code", "description": "Coded reason for a paused or excluded waiting period.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-clock-stop-event-code", "name": "Clock stop event code", "description": "Coded event that stops the waiting clock under the bound profile.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "de-waiting-profile-ref", "name": "Waiting profile reference", "description": "Reference to the jurisdiction profile version that supplies the clock rules.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "Clock rules are normative definitions issued by an adopting jurisdiction and are not records produced by this model. They are carried inline as a versioned rule binding so that every queue entry and waiting measure can name the profile under which it was computed, while the rule suite itself remains the artifact of the issuing authority. Declaring a local artifact would create an unverified copy of national rules that this model has no authority to publish." }, { "id": "queue-exit-and-removal", "name": "Queue exit and removal", "description": "How a queue entry leaves the queue - fulfilled, offered and declined, deferred, transferred, removed or expired - with reasons, permitted transitions and the effect on waiting measurement.", "source_refs": [ "SRC-006", "SRC-007" ], "questions": [ { "id": "q-queue-exit-state", "text": "Which terminal and non-terminal states may a queue entry take, and which transitions between them are permitted?", "kind": "state", "answer_data": [ "State enumeration with terminal flags", "Permitted transition matrix", "Actor role authorized for each transition" ] }, { "id": "q-queue-removal-reason", "text": "What reason vocabulary explains a removal that is not a fulfilment, and who may record it?", "kind": "event", "answer_data": [ "Removal reason code set", "Recording actor reference", "Whether the reason is service-initiated or subject-initiated" ] }, { "id": "q-queue-offer-refusal", "text": "How are offers, refusals and non-attendance recorded so that they do not silently reset the waiting measure?", "kind": "exception", "answer_data": [ "Offer and refusal event records with times", "Non-attendance handling rule under the bound profile", "Effect on the clock stated explicitly" ] } ], "data_elements": [ { "id": "de-queue-state", "name": "Queue entry state", "description": "Current coded state of the queue entry.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-queue-exit-reason", "name": "Queue exit reason code", "description": "Coded reason for the entry leaving the queue.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-queue-exit-instant", "name": "Queue exit instant", "description": "Instant at which the entry left the queue.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "de-fulfilling-reference", "name": "Fulfilling reference", "description": "Reference to the encounter, transfer or other record that fulfilled the demand.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Exits are coded state values, reasons and timestamps carried on the queue entry record already declared as an artifact in this layer. Declaring a separate exit artifact would split one lifecycle across two records of record and make the permitted-transition constraint unenforceable within a single artifact boundary." } ] }, { "id": "capacity-allocation", "name": "Capacity allocation", "description": "Supply-side commitment of capacity units against demand, and the exceptions that release them.", "source_refs": [ "SRC-001", "SRC-006" ], "findings": [ { "id": "capacity-commitment-and-release", "name": "Capacity commitment and allocation exception", "description": "The commitment of a capacity unit, authorized role and location to a queue entry or referral, and the exceptions that release the commitment, held as delivery supply and referencing rather than reproducing patient-facing booking records.", "source_refs": [ "SRC-001", "SRC-006" ], "questions": [ { "id": "q-commitment-binding", "text": "Which capacity unit, authorized role and location are committed, and against which queue entry or referral?", "kind": "process", "answer_data": [ "Committed capacity reference", "Role and location references", "Target queue entry or referral reference" ] }, { "id": "q-commitment-vs-booking", "text": "How does a supply-side capacity commitment differ from the patient-facing appointment record, and which model owns each?", "kind": "composition", "answer_data": [ "Boundary statement separating commitment from booking", "Appointment or slot reference held externally", "Rule prohibiting local storage of booking participant detail" ] }, { "id": "q-commitment-release", "text": "Which events release a committed capacity unit, and is the released capacity returned to the same period?", "kind": "exception", "answer_data": [ "Release event codes (cancellation, reschedule, non-attendance, reallocation)", "Release instant", "Whether the unit returns to the originating capacity period" ] } ], "data_elements": [ { "id": "de-commitment-id", "name": "Capacity commitment identifier", "description": "Identifier of the supply-side commitment.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-committed-capacity-ref", "name": "Committed capacity reference", "description": "Reference to the capacity statement and unit being committed.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-commitment-target-ref", "name": "Commitment target reference", "description": "Reference to the queue entry or referral the capacity is committed to.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "de-commitment-release-reason", "name": "Commitment release reason code", "description": "Coded reason for release of the committed capacity unit.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "capacity-commitment-record", "name": "Capacity commitment record", "description": "The supply-side record committing a capacity unit, role and location to a named queue entry or referral, and its release.", "media_or_form": [ "structured record", "allocation row" ], "serial": false, "identity_strategy": "Keyed by the provider's master-system allocation identifier where one exists; otherwise a Dimension-minted ULID linked to the capacity statement and target references.", "source_refs": [ "SRC-001", "SRC-006" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "care-flow-coordination", "name": "Care-flow coordination", "description": "Directed movement of demand and delivery responsibility between services, units and organizations, and the reference link to the encounters that result.", "rationale": "WHO's integrated people-centred services framework treats referral and counter-referral systems and coordinated pathways across levels and sites as constitutive of service delivery, and FHIR provides ServiceRequest as the carrier for referral and transfer-of-care requests while assigning the actual encounter to a separate resource. Coordination is therefore a first-class delivery concern that must stop at the encounter boundary.", "source_refs": [ "SRC-005", "SRC-007", "SRC-013" ], "layers": [ { "id": "referral-routing", "name": "Referral routing", "description": "Directed requests that another service take on delivery, and what happens to them.", "source_refs": [ "SRC-007", "SRC-013" ], "findings": [ { "id": "referral-request-and-routing", "name": "Referral request and routing", "description": "A directed request that a named or unnamed target service take on delivery, carrying source, target, urgency, routing method and a reference to the coded clinical reason held elsewhere.", "source_refs": [ "SRC-007", "SRC-001", "SRC-013" ], "questions": [ { "id": "q-referral-identity", "text": "Which identifier follows a referral across the sending and receiving organizations?", "kind": "identity", "answer_data": [ "Referral identifier and issuing system", "Receiving organization's local identifier and its linkage", "Rule for identifier continuity across organizational boundaries" ] }, { "id": "q-referral-target", "text": "Is the referral directed to a named offering, a delivery unit, a location or an unnamed pool, and how is that expressed?", "kind": "relationship", "answer_data": [ "Target reference with target kind", "Performer type code when the target is a pool", "Preferred location references" ] }, { "id": "q-referral-urgency", "text": "How is urgency expressed on a referral, and under which coded scheme?", "kind": "classification", "answer_data": [ "Priority code and scheme version", "Time target implied by the priority", "Authorized role for setting or changing priority" ] }, { "id": "q-referral-reason-boundary", "text": "How is the clinical reason for a referral referenced without copying clinical content into this model?", "kind": "privacy", "answer_data": [ "Reason reference with owning model", "Permitted coded reason category", "Prohibited narrative and attachment fields" ] } ], "data_elements": [ { "id": "de-referral-id", "name": "Referral identifier", "description": "Identifier of the referral request.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-referral-source-ref", "name": "Referral source reference", "description": "Reference to the requesting role, unit or organization.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-referral-target-service-ref", "name": "Referral target service reference", "description": "Reference to the offering, unit or pool the referral is directed to.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-007" ] }, { "id": "de-referral-priority", "name": "Referral priority code", "description": "Coded urgency of the referral.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-referral-reason-ref", "name": "Referral reason reference", "description": "Reference to the coded clinical reason held in the owning clinical model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "referral-record", "name": "Referral record", "description": "The delivery-side record of one directed referral, its routing, priority and current disposition.", "media_or_form": [ "structured record", "exchanged request message" ], "serial": false, "identity_strategy": "Keyed by the sending system's master referral identifier with its issuing system; a Dimension-minted ULID is used only where no exchanged identifier exists, and cross-organization linkage is recorded as an explicit identifier pair.", "source_refs": [ "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "referral-disposition-and-closure", "name": "Referral disposition and closure", "description": "The dispositions a referral can reach - acknowledged, accepted, redirected, rejected, withdrawn, expired, completed - with reasons, response-time expectations and chain preservation across redirections.", "source_refs": [ "SRC-007", "SRC-013" ], "questions": [ { "id": "q-referral-disposition-state", "text": "Which dispositions may a referral reach, and which actor is entitled to set each one?", "kind": "state", "answer_data": [ "Disposition state enumeration", "Authorized actor role per disposition", "Permitted transition matrix" ] }, { "id": "q-referral-redirection", "text": "When a referral is redirected, is it the same referral or a new one, and how is the chain preserved?", "kind": "lifecycle", "answer_data": [ "Same-record versus new-record rule", "Chain reference to the prior referral", "Rule for preserving the original clock start across the chain" ] }, { "id": "q-referral-response-time", "text": "What time targets apply between referral sent, acknowledged and accepted, and how is a breach recorded?", "kind": "temporal", "answer_data": [ "Sent, acknowledged and accepted instants", "Target intervals from the bound profile", "Breach flag with reason" ] } ], "data_elements": [ { "id": "de-referral-status", "name": "Referral status code", "description": "Current disposition of the referral.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-referral-status-reason", "name": "Referral status reason code", "description": "Coded reason for the current disposition, particularly rejection or expiry.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-referral-status-instant", "name": "Referral status instant", "description": "Instant at which the current disposition was set.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "de-referral-chain-ref", "name": "Referral chain reference", "description": "Reference to the prior referral in a redirection chain.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [], "inline_only_rationale": "Dispositions are coded states, reasons and instants carried on the referral record already declared as an artifact in this layer. A separate disposition artifact would divide one referral's lifecycle between two records of record and would break the guarantee that a single referral identifier resolves to a single current state." } ] }, { "id": "transfer-and-handoff", "name": "Transfer and handoff", "description": "Movement of delivery responsibility between services, units, locations or organizations, with milestones and the point at which responsibility passes.", "source_refs": [ "SRC-007", "SRC-013" ], "findings": [ { "id": "responsibility-transfer-milestone", "name": "Transfer of delivery responsibility", "description": "The record of delivery responsibility passing from a sending to a receiving service, unit or organization, with timestamped milestones, an explicit responsibility-transfer point and a continuity exception when the transfer fails.", "source_refs": [ "SRC-007", "SRC-013", "SRC-003" ], "questions": [ { "id": "q-transfer-parties", "text": "Which sending and receiving offering, delivery unit and location are party to the transfer?", "kind": "composition", "answer_data": [ "Sending offering, unit and location references", "Receiving offering, unit and location references", "Cross-organization flag" ] }, { "id": "q-transfer-responsibility-point", "text": "At which milestone does delivery responsibility pass from the sending to the receiving service?", "kind": "ownership", "answer_data": [ "Named responsibility-transfer milestone", "Instant at which responsibility passed", "Rule when the milestone is never reached" ] }, { "id": "q-transfer-milestone-times", "text": "Which milestones are timestamped, and what is recorded when a milestone is missing?", "kind": "event", "answer_data": [ "Milestone set with instants (requested, accepted, departed, arrived, failed)", "Missing-milestone marker with reason", "Source system for each milestone" ] }, { "id": "q-transfer-continuity-exception", "text": "What is recorded when a transfer fails or continuity of delivery is broken?", "kind": "exception", "answer_data": [ "Failure reason code", "Fallback receiving service reference", "Reference to the externally owned incident record, if one was raised" ] } ], "data_elements": [ { "id": "de-transfer-id", "name": "Transfer identifier", "description": "Identifier of the transfer of delivery responsibility.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-transfer-sending-ref", "name": "Sending party reference", "description": "Reference to the sending offering, unit or organization.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "de-transfer-receiving-ref", "name": "Receiving party reference", "description": "Reference to the receiving offering, unit or organization.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "de-transfer-milestone", "name": "Transfer milestone set", "description": "Collection of milestone codes with their instants and source systems.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "de-responsibility-transfer-instant", "name": "Responsibility transfer instant", "description": "Instant at which delivery responsibility passed to the receiving party.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "transfer-of-responsibility-record", "name": "Transfer of responsibility record", "description": "The record of one transfer of delivery responsibility with its parties, milestones and outcome.", "media_or_form": [ "structured record", "exchanged handoff message" ], "serial": false, "identity_strategy": "Keyed by the sending organization's master transfer identifier with issuing system; where a receiving organization issues its own, both identifiers are retained as an explicit pair rather than merged.", "source_refs": [ "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "encounter-flow-linkage", "name": "Encounter flow linkage", "description": "The reference boundary between delivery-system records and the encounters owned by the contained model.", "source_refs": [ "SRC-005" ], "findings": [ { "id": "encounter-reference-binding", "name": "Encounter reference and delivery attribution", "description": "The link from delivery-system records to encounters owned by WM-ACT-018, carrying only the external encounter reference plus delivery-side attribution keys such as the offering, delivery unit, location, fulfilled queue entry and consumed capacity commitment.", "source_refs": [ "SRC-005", "SRC-001" ], "questions": [ { "id": "q-encounter-ref-key", "text": "Which encounter identifier and issuing system are carried here, and how is the reference resolved?", "kind": "interoperability", "answer_data": [ "Encounter identifier and issuing system", "Resolution endpoint or model reference", "Behaviour when the reference cannot be resolved" ] }, { "id": "q-encounter-attribution-keys", "text": "Which delivery-side keys are attached to an encounter reference?", "kind": "composition", "answer_data": [ "Attributed offering reference", "Delivery unit and location references", "Fulfilled queue entry and consumed capacity commitment references" ] }, { "id": "q-encounter-field-prohibition", "text": "Which encounter fields must never be copied into this model, and what is the fallback when the contained model is unavailable?", "kind": "constraint", "answer_data": [ "Prohibited field list covering status, participants, actual timing and discharge disposition", "Degraded-mode rule stating that counts are marked incomplete rather than reconstructed", "Statement that this model never derives or asserts encounter state" ] }, { "id": "q-encounter-cardinality", "text": "Can one encounter satisfy more than one queue entry or referral, and how is that represented?", "kind": "relationship", "answer_data": [ "Cardinality rule between encounter references and delivery records", "Link record structure for many-to-many cases", "Rule preventing double counting in delivery measures" ] } ], "data_elements": [ { "id": "de-encounter-ref", "name": "Encounter reference", "description": "Reference to an encounter owned by the contained model WM-ACT-018.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-encounter-issuing-system", "name": "Encounter issuing system", "description": "Identifier of the system that issued the encounter identifier.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-fulfilled-queue-entry-ref", "name": "Fulfilled queue entry reference", "description": "Reference to the queue entry the encounter fulfilled, where applicable.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-consumed-commitment-ref", "name": "Consumed capacity commitment reference", "description": "Reference to the capacity commitment consumed by the encounter.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-attributed-offering-ref", "name": "Attributed offering reference", "description": "Offering to which the encounter is attributed for delivery-side counting.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "The encounter is owned by the contained model WM-ACT-018, which holds encounter identity, status lifecycle, participants, actual timing and discharge disposition. This finding is therefore pure reference data: an external identifier plus delivery-side attribution keys carried on records already declared as artifacts elsewhere. Declaring an artifact here would create a second, competing record of the encounter and would import lifecycle semantics that the containment relation assigns to the child model." } ] } ] }, { "id": "quality-and-performance", "name": "Quality, measurement and disruption", "description": "The quality commitments a delivery unit asserts, the computable measures used to describe delivery performance, and declarations that delivery is degraded.", "rationale": "ISO 7101:2023 requires organizations to maintain processes producing timely, safe, effective, efficient, equitable and people-centred care, and WHO's planning guide places quality action at national, district and facility levels; FHIR Measure supplies the computable population, stratifier and improvement-notation vocabulary; Eurostat and CDC define comparability limits. Measurement and commitment are separable from investigation, which is owned elsewhere.", "source_refs": [ "SRC-008", "SRC-012", "SRC-014", "SRC-016", "SRC-017" ], "layers": [ { "id": "quality-commitment", "name": "Delivery quality commitments", "description": "The quality-management standards, accreditations and service-level commitments a delivery unit asserts, held as references with the evidence of record held elsewhere.", "source_refs": [ "SRC-012", "SRC-014" ], "findings": [ { "id": "quality-commitment-reference", "name": "Quality commitment reference", "description": "The quality-management systems, standards and service-level commitments a delivery unit asserts over a named scope of offerings and sites, referencing certificates and policies issued and held by other parties.", "source_refs": [ "SRC-014", "SRC-012", "SRC-013" ], "questions": [ { "id": "q-quality-commitment-scope", "text": "Which quality management system or standard does the delivery unit assert, and over which scope of offerings and sites?", "kind": "authority", "answer_data": [ "Standard or management-system reference with edition", "Scope statement naming offerings and locations", "Asserting organization reference" ] }, { "id": "q-quality-dimension-claim", "text": "Which quality dimensions does a stated commitment address?", "kind": "quality", "answer_data": [ "Dimension codes (safe, effective, timely, efficient, equitable, people-centred, integrated)", "Commitment text or service-level target per dimension", "Level at which the commitment applies (national, district, facility)" ] }, { "id": "q-quality-certification-evidence", "text": "What evidence supports a certification or accreditation claim, and where is the certificate of record held?", "kind": "evidence", "answer_data": [ "Certificate reference and issuing body", "Validity period", "Statement that the certificate of record is held by the issuing body" ] } ], "data_elements": [ { "id": "de-quality-standard-ref", "name": "Quality standard reference", "description": "Reference to the asserted quality management standard or programme.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-quality-dimension", "name": "Quality dimension code", "description": "Coded quality dimension addressed by a commitment.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-012" ] }, { "id": "de-commitment-scope", "name": "Commitment scope statement", "description": "Statement of the offerings and locations a commitment covers.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-certification-evidence-ref", "name": "Certification evidence reference", "description": "Reference to the certificate or accreditation record held by the issuing body.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "Commitments here are assertions that reference externally issued certificates, management-system documentation and service-level agreements. The certificate is the issuing body's artifact and the management system is the organization's; reproducing either locally would create an unverifiable copy and would imply that this model conveys conformity, which it explicitly does not." } ] }, { "id": "operational-measurement", "name": "Operational measurement", "description": "Computable definitions of delivery measures and the result statements produced from them.", "source_refs": [ "SRC-008", "SRC-016", "SRC-017" ], "findings": [ { "id": "delivery-measure-specification", "name": "Delivery measure specification", "description": "The computable definition of a delivery measure: initial population, denominator, numerator and exclusion criteria, stratifiers, supplemental data, scoring method, unit and improvement notation, with inputs owned by other models named as references.", "source_refs": [ "SRC-008", "SRC-011", "SRC-015" ], "questions": [ { "id": "q-measure-population", "text": "What are the initial population, denominator, numerator and exclusion criteria of the measure?", "kind": "measurement", "answer_data": [ "Population criteria expressions with their type codes", "Exclusion and exception criteria", "Reference to the criteria library and its version" ] }, { "id": "q-measure-stratifier", "text": "Which stratifiers and supplemental data are required, and which are prohibited because they would re-identify small groups?", "kind": "privacy", "answer_data": [ "Required stratifier list", "Prohibited stratifier list with rationale", "Minimum cell size before a stratum may be published" ] }, { "id": "q-measure-input-ownership", "text": "Which measure inputs are owned by other models, and how are they resolved without recomputing their state?", "kind": "composition", "answer_data": [ "Input reference list with owning model", "Resolution mechanism and version pinning", "Statement that referenced record states are consumed as published, never derived here" ] }, { "id": "q-measure-improvement-direction", "text": "Is an increase or a decrease in the measure an improvement, and what scoring method and unit apply?", "kind": "definition", "answer_data": [ "Improvement notation code", "Scoring method (proportion, ratio, continuous variable, cohort)", "Scoring unit" ] } ], "data_elements": [ { "id": "de-measure-id", "name": "Measure identifier", "description": "Identifier and version of the measure specification.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "de-measure-population-criteria", "name": "Measure population criteria", "description": "Collection of population criteria with their type codes and expressions.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "de-measure-stratifier", "name": "Measure stratifier set", "description": "Collection of stratifier criteria applied to the measure.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-measure-scoring", "name": "Measure scoring code", "description": "Scoring method used to calculate the measure.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "de-measure-improvement-notation", "name": "Improvement notation code", "description": "Whether an increase or a decrease indicates improvement.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "measure-specification", "name": "Delivery measure specification", "description": "The versioned, computable definition of one delivery measure and its populations, stratifiers and scoring.", "media_or_form": [ "structured record", "computable specification", "published definition" ], "serial": false, "identity_strategy": "Keyed by the issuing authority's master measure identifier and version where one exists; otherwise a Dimension-minted ULID plus an explicit semantic version. Version is part of identity because results cite it.", "source_refs": [ "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "measure-result-and-comparability", "name": "Measure result and comparability", "description": "A computed result for a named measure version over a stated period and population, carrying computation provenance, input digests and explicit comparability caveats.", "source_refs": [ "SRC-008", "SRC-009", "SRC-015", "SRC-016", "SRC-017" ], "questions": [ { "id": "q-result-provenance", "text": "Which measure version, input artifacts and computation run produced this result?", "kind": "provenance", "answer_data": [ "Measure specification identifier and version", "Input artifact identifiers with content digests", "Computation run identifier and executing agent" ] }, { "id": "q-result-period", "text": "What reporting period and time zone does the result cover, and when was it computed and published?", "kind": "temporal", "answer_data": [ "Reporting period start and end with offsets", "Computation instant", "Publication instant" ] }, { "id": "q-result-comparability", "text": "Which definitional or coverage differences prevent this result from being compared with another jurisdiction or period?", "kind": "quality", "answer_data": [ "Definition profile identifiers for each compared series", "Coverage and completeness caveats", "Break-in-series markers" ] } ], "data_elements": [ { "id": "de-result-value", "name": "Measure result value", "description": "Computed value of the measure for the stated period and stratum.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "de-result-denominator", "name": "Measure result denominator", "description": "Denominator count used for the computed value.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-result-period", "name": "Measure reporting period", "description": "Period covered by the result, with explicit offsets.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "de-result-computed-at", "name": "Result computation instant", "description": "Instant at which the result was computed.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-018" ] }, { "id": "de-result-caveat", "name": "Comparability caveat", "description": "Stated limitation on comparing the result across places, periods or profiles.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-015" ] } ], "artifacts": [ { "id": "measure-result-statement", "name": "Measure result statement", "description": "One immutable computed result for a measure version, period and stratum, with provenance and caveats.", "media_or_form": [ "structured record", "published statistical statement" ], "serial": true, "identity_strategy": "Keyed by measure specification identifier and version, subject scope and reporting period, plus a monotonic run sequence number; the computation instant is an attribute and is never the identifier.", "source_refs": [ "SRC-008", "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "delivery-disruption", "name": "Delivery disruption", "description": "Declarations that delivery is degraded, diverted, suspended or over capacity.", "source_refs": [ "SRC-001", "SRC-003", "SRC-017" ], "findings": [ { "id": "delivery-disruption-declaration", "name": "Delivery disruption declaration", "description": "A declaration that delivery of named offerings at named locations is degraded, diverted, suspended or over capacity, with affected scope, timing, restoration expectation and escalation reference, stopping short of investigation and cause attribution.", "source_refs": [ "SRC-001", "SRC-003", "SRC-017", "SRC-013" ], "questions": [ { "id": "q-disruption-classification", "text": "What kind of disruption is declared, and against which severity scale?", "kind": "classification", "answer_data": [ "Disruption type code (outage, diversion, capacity breach, access failure)", "Severity scale identifier and level", "Whether the disruption is planned or unplanned" ] }, { "id": "q-disruption-scope", "text": "Which offerings, locations and populations are affected, and are alternatives named?", "kind": "state", "answer_data": [ "Affected offering and location references", "Affected population or area reference", "Alternative offering references, where designated" ] }, { "id": "q-disruption-window", "text": "When did the disruption start, when was it declared, and what restoration time is expected?", "kind": "temporal", "answer_data": [ "Disruption start instant", "Declaration instant", "Expected restoration instant with confidence" ] }, { "id": "q-disruption-escalation", "text": "To whom is the declaration escalated, and where is any resulting investigation record held?", "kind": "authority", "answer_data": [ "Escalation recipient references", "Notification obligation reference", "Reference to the externally owned investigation record" ] } ], "data_elements": [ { "id": "de-disruption-id", "name": "Disruption identifier", "description": "Identifier of the disruption declaration.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "de-disruption-type", "name": "Disruption type code", "description": "Coded kind of disruption declared.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-disruption-scope-ref", "name": "Disruption scope reference", "description": "References to the affected offerings, locations and populations.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-disruption-start", "name": "Disruption start instant", "description": "Instant at which the disruption began.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-018" ] }, { "id": "de-disruption-declared-at", "name": "Disruption declaration instant", "description": "Instant at which the disruption was declared and recorded.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-018" ] }, { "id": "de-restoration-estimate", "name": "Expected restoration instant", "description": "Expected instant of restoration to normal delivery.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] } ], "artifacts": [ { "id": "service-disruption-notice", "name": "Service disruption notice", "description": "One immutable declaration of disrupted delivery with its scope, timing, escalation and closure.", "media_or_form": [ "structured record", "published notice", "operational alert" ], "serial": true, "identity_strategy": "Keyed by the declaring organization's master incident-notification identifier where one exists; otherwise by delivery unit identifier plus a monotonic notice sequence number that carries no date component.", "source_refs": [ "SRC-017" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "governance-provenance-disclosure", "name": "Governance, provenance and disclosure", "description": "Who owns each record class, how records are verified, identified and timestamped, and under what constraints they are disclosed and retired.", "rationale": "The national directory guide requires attestation and verification against primary sources with implementer-set re-verification cadence, FHIR Provenance separates when an activity occurred from when it was recorded and separates provenance assertion from audit tracking, and RFC 3339 fixes the timestamp profile. These are the governance preconditions for an agent to trust, publish or retire any record in this model.", "source_refs": [ "SRC-009", "SRC-010", "SRC-018" ], "layers": [ { "id": "stewardship-and-provenance", "name": "Stewardship, verification and provenance", "description": "Ownership and asserted authority per record class, attestation and verification of directory records, and the identity and time rules applied to every record.", "source_refs": [ "SRC-009", "SRC-010", "SRC-018" ], "findings": [ { "id": "record-stewardship-and-authority", "name": "Record stewardship and asserted authority", "description": "Which actor owns each record class in this model, on what basis they assert authority to publish or amend it, in which jurisdiction or profile, and what happens to stewardship on merger, closure or service transfer.", "source_refs": [ "SRC-010", "SRC-004", "SRC-012" ], "questions": [ { "id": "q-steward-per-record-class", "text": "Which steward owns each record class in this model?", "kind": "ownership", "answer_data": [ "Record class enumeration", "Steward reference per class", "Delegation arrangements where stewardship is shared" ] }, { "id": "q-authority-basis", "text": "On what basis does a steward assert authority to publish or amend a record class?", "kind": "authority", "answer_data": [ "Authority basis reference (licence, contract, statutory duty, internal delegation)", "Effective period of the authority", "Limits on the assertion" ] }, { "id": "q-steward-handover", "text": "What happens to stewardship when a provider organization merges, closes or transfers a service?", "kind": "lifecycle", "answer_data": [ "Successor steward reference", "Handover instant and instrument", "Treatment of records created under the prior steward" ] } ], "data_elements": [ { "id": "de-record-class", "name": "Record class code", "description": "Class of record to which a stewardship assertion applies.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-steward-ref", "name": "Steward reference", "description": "Reference to the actor owning the record class.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-authority-basis-ref", "name": "Authority basis reference", "description": "Reference to the instrument on which authority is asserted.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-jurisdiction-profile", "name": "Jurisdiction profile code", "description": "Identifier of the jurisdiction profile under which the record class is governed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "Stewardship is an assertion attached to record classes and carried in the header of every artifact this model declares; it is not itself a document. The authorising instrument - licence, contract or statutory duty - is owned and published by the issuing authority, so a local artifact would either duplicate that instrument or create the false impression that this model confers authority." }, { "id": "directory-verification-and-attestation", "name": "Directory verification and attestation", "description": "Attestation by a responsible party that a directory record is accurate, and verification of attested fields against primary sources, with verification status, method, date and re-verification due date.", "source_refs": [ "SRC-010", "SRC-002" ], "questions": [ { "id": "q-attestation-actor", "text": "Who attested to the accuracy of a directory record, and at what instant?", "kind": "evidence", "answer_data": [ "Attesting actor reference and role", "Attestation instant", "Fields covered by the attestation" ] }, { "id": "q-verification-method", "text": "Against which primary source and by what method was an attested field verified?", "kind": "validation", "answer_data": [ "Primary source reference", "Verification method identifier", "Verification outcome per field" ] }, { "id": "q-verification-freshness", "text": "How stale may a verified field become before it must be re-verified or marked unreliable?", "kind": "temporal", "answer_data": [ "Maximum age per field class", "Next re-verification due date", "State applied when the due date passes" ] } ], "data_elements": [ { "id": "de-attestation-actor-ref", "name": "Attesting actor reference", "description": "Reference to the party attesting to record accuracy.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-attested-at", "name": "Attestation instant", "description": "Instant at which the attestation was given.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-010", "SRC-018" ] }, { "id": "de-verification-status", "name": "Verification status code", "description": "Status of verification for the attested fields.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-verification-source-ref", "name": "Verification source reference", "description": "Reference to the primary source used for verification.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-verification-due", "name": "Re-verification due date", "description": "Date by which the field must be verified again.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "verification-attestation-record", "name": "Verification and attestation record", "description": "The record of one attestation and its verification against primary sources for a named set of directory fields.", "media_or_form": [ "structured record", "verification log entry" ], "serial": false, "identity_strategy": "Keyed by the target directory record identifier plus the attesting actor reference and attestation sequence; the attestation instant is an attribute rather than part of the key.", "source_refs": [ "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "identifier-and-time-provenance", "name": "Identifier and time provenance", "description": "The identity assignment rules, the separation of event, observation and ingestion time, supersession linkage and the boundary between provenance held here and the externally owned audit trail.", "source_refs": [ "SRC-009", "SRC-018", "SRC-010" ], "questions": [ { "id": "q-identifier-priority", "text": "Which identifier is authoritative for a record when several systems issue one?", "kind": "identity", "answer_data": [ "Authoritative master-system identifier with issuing system", "Secondary governed global identifier or IRI", "Dimension-minted UUID or ULID used only as fallback" ] }, { "id": "q-time-triple", "text": "Which of event time, observation time and ingestion time does a given field carry, and are all three required?", "kind": "temporal", "answer_data": [ "Per-field time-kind declaration", "Rule requiring separate recording when the three differ", "Behaviour when only one time is available" ] }, { "id": "q-record-supersession", "text": "How is a superseded record version linked to its replacement and to the agent that made the change?", "kind": "provenance", "answer_data": [ "Supersedes and superseded-by references", "Changing agent reference and role", "Reason for the change" ] }, { "id": "q-provenance-vs-audit", "text": "What provenance must this model hold, and what belongs to the external audit trail?", "kind": "security", "answer_data": [ "Local provenance field set", "Reference to the audit model that owns access events", "Statement that referencing an audit record confers no audit-trail ownership" ] } ], "data_elements": [ { "id": "de-record-identifier", "name": "Record identifier", "description": "Authoritative identifier of the record under the identity priority rules.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-event-time", "name": "Event time", "description": "Instant or period at which the delivery fact occurred.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-018" ] }, { "id": "de-observation-time", "name": "Observation time", "description": "Instant at which the fact was observed, measured or asserted.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-018" ] }, { "id": "de-ingestion-time", "name": "Ingestion time", "description": "Instant at which this model received or recorded the fact.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-018" ] }, { "id": "de-supersedes-ref", "name": "Supersedes reference", "description": "Reference to the record version this record replaces.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-recording-agent-ref", "name": "Recording agent reference", "description": "Reference to the agent that recorded or amended the record.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Identity and time rules are normative constraints applied uniformly to every artifact this model already declares, and the resulting values are governance metadata carried in those artifacts' headers. A separate artifact would duplicate every record's key fields and create ambiguity about which copy is authoritative, which is the opposite of the rule's purpose." }, { "id": "directory-discovery-and-endpoints", "name": "Directory discovery, projections and endpoints", "description": "Consumers query where care is offered, hours, specialties and how to connect electronically. Public projections omit capacity, staffing, encounters and sensitive practitioner contacts. Endpoints describe connectivity; they do not grant this model ownership of the target FHIR server, XCA actor or audit log. Federated directories must preserve time-stamped updates and deprecation status rather than hard-delete.", "source_refs": [ "SRC-027" ], "questions": [ { "id": "directory-discovery-and-endpoints-q01", "text": "Which projection (public directory, professional referral search, internal network, capacity heatmap) is being served, and which finding classes are included or omitted?", "kind": "access", "answer_data": [ "projection (code)", "included_finding_ids (id[])", "omitted_finding_ids (id[])", "small_number_suppression (boolean)" ] }, { "id": "directory-discovery-and-endpoints-q02", "text": "What electronic endpoints are published for this organization or affiliation, with connection type, managing organization for support, and applicable network context?", "kind": "interoperability", "answer_data": [ "endpoint_id (identifier)", "connection_type (Coding)", "address (url)", "managing_organization_ref (reference)", "affiliation_context_ref (reference) - endpoint on Organization versus OrganizationAffiliation", "payload_type (CodeableConcept[])" ] }, { "id": "directory-discovery-and-endpoints-q03", "text": "For federated ingest, what is the source directory, last-update watermark, conflict-resolution policy, and deprecation status of each entry?", "kind": "provenance", "answer_data": [ "source_directory_uri (uri)", "update_watermark_time (date-time)", "conflict_policy_uri (uri)", "deprecated (boolean)", "refresh_interval (duration)" ] } ], "data_elements": [ { "id": "directory-discovery-and-endpoints-data01", "name": "endpoint_id", "description": "Identifier of a published electronic endpoint bound to an organization or affiliation.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-027" ] }, { "id": "directory-discovery-and-endpoints-data02", "name": "connection_type", "description": "Connection type of the endpoint; describes connectivity only, not ownership of the target system.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-027" ] }, { "id": "directory-discovery-and-endpoints-data03", "name": "projection", "description": "Named directory projection: public, professional or internal, determining included and omitted finding classes.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-027", "SRC-023" ] }, { "id": "directory-discovery-and-endpoints-data04", "name": "update_watermark_time", "description": "Last-update watermark for federated ingest, preserving time-stamped updates.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-027" ] } ], "artifacts": [ { "id": "directory-discovery-and-endpoints-artifact01", "name": "directory_endpoint_record", "description": "Electronic access point bound to an organization or affiliation. Not the target system's operational log. Populated by publishEndpoint and directoryQuery.", "media_or_form": [ "directory-record" ], "serial": false, "identity_strategy": "Keyed by endpoint_id within the managing organization's master system; falls back to governed IRI, then Dimension ULID.", "source_refs": [ "SRC-027" ] }, { "id": "directory-discovery-and-endpoints-artifact02", "name": "directory_projection_view", "description": "Named filtered view over provision records. Materialised only if the adopting Dimension stores views; otherwise derived. Populated by directoryQuery.", "media_or_form": [ "projection" ], "serial": false, "identity_strategy": "Keyed by projection name plus the source directory URI and update watermark it was derived from.", "source_refs": [ "SRC-027", "SRC-023" ] } ], "inline_only_rationale": null } ] }, { "id": "disclosure-and-retention", "name": "Disclosure and retention", "description": "Named projections with their permitted field sets and purposes, and retention and disposition instructions whose execution is delegated.", "source_refs": [ "SRC-010", "SRC-016", "SRC-017" ], "findings": [ { "id": "projection-and-disclosure-control", "name": "Projection and disclosure constraint", "description": "Named projections of this model - public directory, operational, and person-linked - with the fields each may contain, the purposes and recipient classes for which each is released, and the aggregation or suppression required before publication. Evaluation and enforcement of any release decision are owned by the access-authorization model.", "source_refs": [ "SRC-010", "SRC-016", "SRC-017" ], "questions": [ { "id": "q-projection-field-set", "text": "Which fields may appear in each named projection, and which are excluded by construction?", "kind": "access", "answer_data": [ "Projection identifier and name", "Allowed field list per projection", "Excluded field list with rationale" ] }, { "id": "q-projection-purpose", "text": "For which purpose and recipient class is each projection released?", "kind": "privacy", "answer_data": [ "Purpose codes", "Recipient class codes", "Conditions attached to release" ] }, { "id": "q-projection-minimisation", "text": "What aggregation or suppression must be applied before a capacity, queue or flow projection is published?", "kind": "requirement", "answer_data": [ "Minimum aggregation level", "Small-number suppression threshold", "Rounding or perturbation rule" ] }, { "id": "q-projection-enforcement-owner", "text": "Which model evaluates and enforces a release decision, given that this model only declares the constraint?", "kind": "authority", "answer_data": [ "Access-authorization model reference", "Statement that no evaluation or enforcement occurs here", "Failure behaviour when the evaluator is unavailable" ] } ], "data_elements": [ { "id": "de-projection-id", "name": "Projection identifier", "description": "Identifier of a named projection of this model.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-projection-field-allowlist", "name": "Projection field allowlist", "description": "Collection of fields permitted in the projection.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-projection-purpose", "name": "Projection purpose code", "description": "Purpose for which the projection may be released.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "de-projection-recipient-class", "name": "Recipient class code", "description": "Class of recipient entitled to receive the projection.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-suppression-rule", "name": "Suppression rule", "description": "Aggregation, suppression or rounding rule applied before publication.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "projection-definition", "name": "Projection definition", "description": "The versioned definition of one named projection: permitted fields, purposes, recipient classes and suppression rules.", "media_or_form": [ "structured record", "published view definition" ], "serial": false, "identity_strategy": "Keyed by a stable projection name within this model's namespace plus a semantic version; version is part of identity because published outputs cite the projection version they were produced under.", "source_refs": [ "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "retention-and-disposition-instruction", "name": "Retention and disposition instruction", "description": "The retention class assigned to each record class of this model, legal-hold marking, the tombstone that must survive deletion so that references from other models do not dangle, and the evidence of executed disposition. Periods and execution are owned externally.", "source_refs": [ "SRC-009", "SRC-010", "SRC-005" ], "questions": [ { "id": "q-retention-class", "text": "Which retention class applies to each record class in this model, and which policy sets its period?", "kind": "retention", "answer_data": [ "Retention class code per record class", "Retention policy reference and version", "Trigger event that starts the retention period" ] }, { "id": "q-legal-hold", "text": "How is a legal hold recorded, and what does it suspend?", "kind": "constraint", "answer_data": [ "Legal hold flag and scope", "Instrument imposing the hold", "Operations suspended while the hold is active" ] }, { "id": "q-tombstone-content", "text": "What must survive deletion as a tombstone so that references from other models do not dangle?", "kind": "requirement", "answer_data": [ "Minimum tombstone field set (identifier, record class, disposition instant, successor reference)", "Prohibited residual content", "Behaviour of resolvers encountering a tombstone" ] }, { "id": "q-disposition-evidence", "text": "What evidence proves that a disposition was executed, and which model holds that evidence?", "kind": "evidence", "answer_data": [ "Disposition evidence reference", "Executing model or Dimension policy reference", "Statement that execution is not performed by this model" ] } ], "data_elements": [ { "id": "de-retention-class", "name": "Retention class code", "description": "Retention class assigned to a record class of this model.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-retention-policy-ref", "name": "Retention policy reference", "description": "Reference to the externally owned policy that sets the retention period.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-legal-hold-flag", "name": "Legal hold flag", "description": "Whether a legal hold currently suspends disposition of the record.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "de-tombstone-record", "name": "Tombstone record", "description": "Minimal surviving structure left in place of a disposed record.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-009" ] }, { "id": "de-disposition-evidence-ref", "name": "Disposition evidence reference", "description": "Reference to the evidence that a disposition was executed by the owning policy model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "retention-disposition-instruction", "name": "Retention and disposition instruction", "description": "The instruction assigning a retention class, hold state and tombstone requirement to a record class of this model, for execution by the owning policy model.", "media_or_form": [ "structured record", "policy binding statement" ], "serial": false, "identity_strategy": "Keyed by record class code plus retention policy reference and instruction version; a Dimension-minted ULID is added when the same record class is governed by more than one jurisdiction profile.", "source_refs": [ "SRC-010" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "fn-register-service-offering", "name": "Register or version a service offering", "description": "Create or supersede a service offering entry with identity, classification, specialty, modality, status and effective period.", "inputs": [ "Provider organization reference", "Proposed classification, specialty and modality codes with code systems", "Master-system service identifier where issued" ], "outputs": [ "Service offering directory entry", "Assigned identifier under the identity priority", "Supersession link where an existing offering is replaced" ], "preconditions": [ "Steward for the directory record class is resolved", "Referenced organization resolves in its owning model", "Code systems and versions are declared" ], "effects": [ "A new or superseded offering entry exists with an explicit effective period", "Downstream bindings referencing the prior version are marked for re-verification" ], "source_refs": [ "SRC-001", "SRC-010" ] }, { "id": "fn-bind-service-to-location", "name": "Bind a service offering to a delivery unit and location", "description": "Create the binding between an offering, its accountable delivery unit and one or more physical, mobile, home or virtual delivery locations.", "inputs": [ "Service offering identifier", "Delivery unit reference", "Location references with instance or class mode" ], "outputs": [ "Delivery binding record", "Virtual delivery point reference where applicable" ], "preconditions": [ "Offering entry is active", "Location and organization references resolve in their owning models", "No local copy of address, geometry or hierarchy is supplied" ], "effects": [ "The offering becomes addressable at the bound locations for availability, capacity and queue records" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-004" ] }, { "id": "fn-bind-role-authorization", "name": "Record a delivery role authorization", "description": "Record that a practitioner role is authorized to deliver named offerings at named locations for a stated period.", "inputs": [ "Practitioner role reference", "Authorizing organization reference", "Covered offering and location references and authorization period" ], "outputs": [ "Delivery role authorization record", "Derived coverage inputs for the affected operating periods" ], "preconditions": [ "Practitioner and qualification records resolve in their owning model", "Authorization period start is supplied", "No licensure state is copied locally" ], "effects": [ "Coverage assertions for the affected offerings become recomputable" ], "source_refs": [ "SRC-002", "SRC-010" ] }, { "id": "fn-publish-availability-statement", "name": "Publish an availability statement", "description": "Publish or supersede the operating hours, exceptions, access channels and referral method for an offering at a location.", "inputs": [ "Delivery binding identifier", "Operating hours with IANA time zone", "Exceptions, access channels, appointment-required and referral-method values" ], "outputs": [ "Published availability statement", "Version supersession link" ], "preconditions": [ "Delivery binding is active", "Time zone is explicit", "Bookable slot inventory is not supplied" ], "effects": [ "The public directory projection can be regenerated from the new statement version" ], "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "fn-record-capacity-statement", "name": "Record a capacity statement", "description": "Record an immutable capacity assertion for an offering, location, basis and period, or an occupancy snapshot against an existing statement.", "inputs": [ "Delivery binding identifier", "Capacity type, quantity, unit, basis and period, or occupancy counts and snapshot instant", "Source system identifier, observation time and ingestion time" ], "outputs": [ "Capacity statement record or occupancy snapshot record", "Assigned serial identifier within the reporting cycle" ], "preconditions": [ "Capacity basis is declared as physical, staffed or surge", "Definition profile naming inclusions and exclusions is bound", "Timestamps carry seconds and an explicit offset" ], "effects": [ "A new immutable statement exists; prior statements are superseded rather than edited", "Utilization measures depending on the statement become recomputable" ], "source_refs": [ "SRC-015", "SRC-017" ] }, { "id": "fn-record-readiness-assessment", "name": "Record a service readiness assessment", "description": "Record tracer-item results, method, assessor and any composite readiness index for an offering at a location.", "inputs": [ "Delivery binding identifier", "Tracer item results by readiness domain", "Assessment method identifier and version, assessor reference and assessment time" ], "outputs": [ "Service readiness assessment record", "Composite readiness index where the method defines one" ], "preconditions": [ "Method version is declared", "External inventory and workforce dependencies are referenced rather than restated" ], "effects": [ "Readiness state for the offering is updated with a stated observation time and method" ], "source_refs": [ "SRC-011" ] }, { "id": "fn-register-demand-entry", "name": "Register a unit of demand", "description": "Register demand for an offering as a queue entry with listing instant, priority class and subject reference.", "inputs": [ "Requested offering, unit or pool reference", "Subject reference", "Priority class code with scheme version" ], "outputs": [ "Queue entry record", "Duplicate-detection result" ], "preconditions": [ "Waiting profile version is bound", "No clinical or demographic content is supplied", "Listing instant carries seconds and an explicit offset" ], "effects": [ "The entry counts toward queue depth and, under the bound profile, toward waiting measurement" ], "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "fn-transition-queue-entry", "name": "Transition a queue entry state", "description": "Move a queue entry between permitted states, recording exit reason, instant and any fulfilling reference.", "inputs": [ "Queue entry identifier", "Target state and reason code", "Acting role reference" ], "outputs": [ "Updated queue entry record with state history", "Clock effect statement under the bound profile" ], "preconditions": [ "Transition is permitted by the state matrix", "Acting role is authorized for that transition", "Effect on the waiting clock is stated explicitly rather than inferred" ], "effects": [ "Queue depth and waiting populations change", "Committed capacity may become eligible for release" ], "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "fn-commit-capacity", "name": "Commit or release capacity", "description": "Commit a capacity unit, role and location to a queue entry or referral, or release the commitment with a reason.", "inputs": [ "Capacity statement and unit reference", "Target queue entry or referral reference", "Release reason code where releasing" ], "outputs": [ "Capacity commitment record or release entry", "Updated available capacity for the affected period" ], "preconditions": [ "Capacity statement covers the target period", "Patient-facing booking detail is referenced, not stored", "Target reference resolves within this model" ], "effects": [ "Available capacity for the period is reduced or restored", "Allocation exception counts are updated" ], "source_refs": [ "SRC-001", "SRC-006" ] }, { "id": "fn-route-referral", "name": "Route a referral and record its disposition", "description": "Create a referral toward a named or unnamed target service and record acknowledgement, acceptance, redirection, rejection, expiry or completion.", "inputs": [ "Source role, unit or organization reference", "Target offering, unit or pool reference and priority code", "Disposition code, reason and instant when updating" ], "outputs": [ "Referral record with current disposition", "Chain reference where the referral is redirected" ], "preconditions": [ "Clinical reason is referenced, not copied", "Disposition is permitted for the acting role", "Cross-organization identifiers are retained as a pair rather than merged" ], "effects": [ "Referral flow counts and response-time measures are updated", "A redirection preserves the original chain and clock start" ], "source_refs": [ "SRC-007", "SRC-013" ] }, { "id": "fn-record-responsibility-transfer", "name": "Record a transfer of delivery responsibility", "description": "Record the parties, milestones and responsibility-transfer point for a transfer between services, units or organizations, including failed transfers.", "inputs": [ "Sending and receiving offering, unit and location references", "Milestone codes with instants and source systems", "Failure reason where the transfer did not complete" ], "outputs": [ "Transfer of responsibility record", "Continuity exception entry where applicable" ], "preconditions": [ "Responsibility-transfer milestone is named in advance", "Missing milestones are marked rather than imputed" ], "effects": [ "Delivery responsibility is attributed to the receiving party from the named instant", "Continuity measures are updated" ], "source_refs": [ "SRC-007", "SRC-013" ] }, { "id": "fn-link-encounter-reference", "name": "Link an encounter reference to delivery records", "description": "Attach an external encounter reference from the contained model to delivery-side attribution keys without importing encounter state.", "inputs": [ "Encounter identifier and issuing system", "Attributed offering, delivery unit and location references", "Fulfilled queue entry or consumed commitment reference" ], "outputs": [ "Encounter reference binding with attribution keys", "Unresolved-reference marker where the child model cannot be reached" ], "preconditions": [ "No encounter status, participant, timing or disposition field is supplied", "Cardinality rule for multi-target encounters is applied", "Child model reference format is known" ], "effects": [ "Delivery flow and utilization measures can cite the encounter without this model asserting encounter state", "Unresolved references are counted as incompleteness rather than reconstructed" ], "source_refs": [ "SRC-005", "SRC-001" ] }, { "id": "fn-compute-delivery-measure", "name": "Compute a delivery measure result", "description": "Execute a versioned measure specification over delivery records and referenced inputs to produce a result statement with provenance and caveats.", "inputs": [ "Measure specification identifier and version", "Reporting period with explicit offsets and stratifier selection", "Input artifact identifiers with content digests" ], "outputs": [ "Measure result statement", "Comparability caveat set and suppressed-stratum list" ], "preconditions": [ "All input digests resolve", "Referenced record states are consumed as published and are not derived here", "Minimum cell size is enforced before a stratum is emitted" ], "effects": [ "An immutable result exists citing measure version, inputs and computation instant", "Strata below the threshold are suppressed rather than published" ], "source_refs": [ "SRC-008", "SRC-009", "SRC-016" ] }, { "id": "fn-declare-disruption", "name": "Declare and close a delivery disruption", "description": "Declare that named offerings and locations are degraded, diverted, suspended or over capacity, and later record restoration.", "inputs": [ "Affected offering, location and population references", "Disruption type, severity and start instant", "Expected restoration instant and escalation recipients" ], "outputs": [ "Service disruption notice", "Restoration entry closing the notice" ], "preconditions": [ "Declaration instant is recorded separately from the disruption start instant", "Cause attribution and investigation are referenced, not asserted here" ], "effects": [ "Availability and capacity projections reflect the disruption for its duration", "Escalation recipients are identified for notification by the owning process" ], "source_refs": [ "SRC-017", "SRC-003" ] }, { "id": "fn-verify-directory-record", "name": "Attest and verify a directory record", "description": "Record an attestation of accuracy and the verification of attested fields against primary sources, with status and re-verification due date.", "inputs": [ "Target directory record identifier and field set", "Attesting actor reference and attestation instant", "Primary source reference and verification method" ], "outputs": [ "Verification and attestation record", "Per-field verification status and next due date" ], "preconditions": [ "Primary source is identified for each verifiable field", "Re-verification cadence for the field class is bound" ], "effects": [ "Directory records carry an explicit freshness state", "Fields past their due date are marked unreliable in published projections" ], "source_refs": [ "SRC-010" ] }, { "id": "fn-issue-retention-instruction", "name": "Issue a retention and disposition instruction", "description": "Assign a retention class, hold state and tombstone requirement to a record class of this model, for execution by the owning policy model.", "inputs": [ "Record class code", "Retention policy reference and version", "Legal hold state and tombstone field set" ], "outputs": [ "Retention and disposition instruction", "Tombstone template for the record class" ], "preconditions": [ "Retention period is set by the referenced policy, not by this model", "Tombstone field set preserves identifiers referenced by other models", "Execution owner is named" ], "effects": [ "Records of the class become eligible for disposition by the owning policy model", "A legal hold suspends eligibility until it is lifted" ], "source_refs": [ "SRC-010", "SRC-009" ] }, { "id": "fn-query-directory", "name": "directoryQuery", "description": "Find matching care services, facilities, roles and endpoints under a named projection.", "inputs": [], "outputs": [ "directory_projection_view" ], "preconditions": [ "projection authorised by the access sibling" ], "effects": [ "no change to the store", "autonomous read", "reversible: reads may be repeated without side effects" ], "source_refs": [ "SRC-027" ] }, { "id": "fn-deactivate-with-tombstone", "name": "deactivateWithTombstone", "description": "Inactivate a provision record with tombstone, succession identifiers and provenance. Does not physically destroy records and does not delete WM-ACT-018 encounters.", "inputs": [], "outputs": [ "record_tombstone" ], "preconditions": [ "master_system_id", "inactivation_authority" ], "effects": [ "record_tombstone created and active set to false", "confirmation-required", "not reversible: physical destruction is executed only by the adopting-Dimension retention policy" ], "source_refs": [ "SRC-027", "SRC-034" ] } ], "composition": [ { "target": "WM-ACT-018 Health Care Encounter", "relation": "CHILD", "purpose": "Encounter identity, status lifecycle, participants, actual timing, subject status and admission or discharge disposition are delegated entirely to the contained model. This model carries only the encounter reference plus delivery-side attribution keys (offering, delivery unit, location, fulfilled queue entry, consumed capacity commitment) and never reproduces encounter lifecycle, event semantics or clinical context.", "required": true, "source_refs": [ "SRC-005" ] }, { "target": "HL7 FHIR R5 delivery directory resource set (Organization, Location, HealthcareService, PractitionerRole)", "relation": "ALIGN", "purpose": "Alignment for interoperable projection of offerings, bindings, locations and role authorizations. Alignment is at the element and boundary level only; these resources are Trial Use, so no conformance is claimed and no FHIR resource lifecycle is adopted.", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-004" ] }, { "target": "HL7 National Directory of Healthcare Providers & Services Implementation Guide (STU1 1.0.0)", "relation": "ALIGN", "purpose": "Alignment for attestation, primary-source verification, re-verification cadence and validation vocabulary on directory records. The guide is built on FHIR R4 and US Core, so a projection must pin its version explicitly rather than assume R5 equivalence.", "required": false, "source_refs": [ "SRC-010" ] }, { "target": "HL7 FHIR R5 scheduling resources (Schedule, Slot, Appointment)", "relation": "REFERENCE", "purpose": "Bookable supply and patient-facing booking records are referenced, never mirrored. This model carries only the supply-side capacity commitment and its release, together with the external booking reference and its issuing system.", "required": false, "source_refs": [ "SRC-001", "SRC-006" ] }, { "target": "HL7 FHIR R5 ServiceRequest", "relation": "ALIGN", "purpose": "Binding for the referral and transfer-of-care request payload: status, intent, priority, performer type and location preference. Clinical reason and order content remain in the owning clinical model and are referenced by identifier only.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "HL7 FHIR R5 Measure and MeasureReport", "relation": "ALIGN", "purpose": "Binding for measure population criteria, stratifiers, scoring and improvement notation, and for the separation between a measure definition and a computed result. Measure logic libraries remain externally owned.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "IETF RFC 3339 timestamp profile", "relation": "ALIGN", "purpose": "Normative profile for every time value in this model: seconds are mandatory, an explicit numeric offset or 'Z' is required, and '-00:00' denotes an unknown local offset.", "required": true, "source_refs": [ "SRC-018" ] }, { "target": "ISO 7101:2023 healthcare quality management system", "relation": "ALIGN", "purpose": "Requirement-level alignment for the quality dimensions asserted in delivery commitments. Management-system conformity, internal audit and improvement processes remain owned by the organization's management system; this model references commitments and certification evidence only.", "required": false, "source_refs": [ "SRC-014" ] }, { "target": "Practitioner identity, qualification and licensure model (external owner; candidate ledger entry)", "relation": "REFERENCE", "purpose": "Persons, qualifications, registrations and licensure state are referenced from role authorizations. This model does not hold qualification lifecycle, primary-source licence verification of record, employment or rostering.", "required": true, "source_refs": [ "SRC-002", "SRC-010" ] }, { "target": "Organization identity and legal-entity lifecycle model (external owner; candidate ledger entry)", "relation": "REFERENCE", "purpose": "Provider organizations and their hierarchies are referenced as accountable delivery parties. Incorporation, ownership, affiliation and accreditation award lifecycle are not modelled here.", "required": true, "source_refs": [ "SRC-004" ] }, { "target": "Place and site model (external owner; candidate ledger entry)", "relation": "REFERENCE", "purpose": "Delivery locations are referenced in instance or class mode. Site geometry, estates records, building lifecycle and geocoding remain externally owned and are never copied into bindings.", "required": true, "source_refs": [ "SRC-003" ] }, { "target": "Personal health and clinical state model (external owner; candidate ledger entry)", "relation": "REFERENCE", "purpose": "Subjects of demand, referral reasons and clinical content are referenced by identifier. Diagnoses, observations, procedures, medications and personal health episodes are never inlined in queue, referral or transfer records.", "required": true, "source_refs": [ "SRC-007", "SRC-016" ] }, { "target": "General service offering model (external owner; candidate ledger entry)", "relation": "EXTEND", "purpose": "Specializes a generic service offering with health-delivery-specific bindings: clinical specialty, care modality, readiness tracers, referral method and eligibility conditions. Generic offering identity, authority, versioning and conflict handling remain in the target and are not restated here.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "Records retention and disposition policy model (external owner; adopting-Dimension policy)", "relation": "REFERENCE", "purpose": "Retention periods and the execution of disposition are owned by the referenced policy. This model issues retention-class assignments, hold markings and tombstone requirements only, and holds a reference to the evidence of executed disposition.", "required": true, "source_refs": [ "SRC-010", "SRC-009" ] }, { "target": "Access control, consent and disclosure authorization model (external owner; candidate ledger entry)", "relation": "REFERENCE", "purpose": "Projection definitions, purposes and recipient classes are declared here; the runtime access decision, its evaluation and its enforcement belong to the referenced model, and this reference confers no evaluation or enforcement semantics.", "required": true, "source_refs": [ "SRC-010" ] }, { "target": "Audit trail model (external owner; candidate ledger entry)", "relation": "REFERENCE", "purpose": "Access events, audit capture and audit retention are owned by the referenced model. This model holds record provenance (recording agent, occurrence and recording times, supersession) only; referencing an audit record grants no audit-trail semantics.", "required": true, "source_refs": [ "SRC-009" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must nominate a named steward for each record class (directory, availability, capacity, readiness, queue, commitment, referral, transfer, measure, disruption, governance) and record the authority basis under which that steward publishes or amends it.", "The adopting Dimension must bind one jurisdiction profile version supplying waiting-clock rules, capacity definition inclusions and exclusions, eligibility rules, accreditation expectations, retention periods and small-number suppression thresholds; no default is supplied by this model.", "The adopting Dimension must declare the master systems for organization, place, person and qualification references, and the resolution endpoint for the contained encounter model WM-ACT-018, before any binding, queue or flow record may be created.", "The adopting Dimension must declare which named projections it publishes and which access-authorization and retention policy models own evaluation and execution for them." ], "namespace_guidance": "Use a stable namespace of the form .healthCareDelivery... with lower-camel segments for logical addressing and lower-kebab-case for the stable local IDs used in this record. Namespace segments must not encode dates, organizational structure or storage technology, so that a move between JSON, Markdown, Git, MCP or MongoDB does not change any identifier. Code system identifiers, jurisdiction profile identifiers and measure specification identifiers are carried as separate qualified values and never folded into the namespace path.", "registry_links": [ "Registry entry vr.wm-act-014 in the world-model record plane, navigation path NAV.ACT.HCR, domain tags ACT.HCR.", "Containment edge WM-ACT-014 CONTAINS WM-ACT-018 recorded in planning/VERCY-MODEL-RELATIONS.csv; review state is candidate and must be confirmed before the boundary is treated as settled.", "Candidate reference edges to the person, organization, place, personal-health, access, retention and audit models are not yet present in the relation ledger and are recorded here as candidates requiring registration." ] }, "canon_and_patch": { "canonicalization_rules": [ "Serialize records with lexicographically sorted keys, UTF-8 encoding and no insignificant whitespace before hashing; the canonical form is storage-neutral and identical whether the record is projected to JSON, YAML, Markdown front matter or a document store.", "Carry every coded value as the triple of code system identifier, code and code system version; never as a bare display string, and never as a locally invented shorthand.", "Normalize time values to RFC 3339 with seconds and an explicit offset, preserving the originating offset rather than converting to UTC, because operating hours, snapshot instants and clock events are meaningful in local civil time.", "Represent references as the pair of issuing system identifier and identifier value; a reference is never canonicalized into a resolved copy of the target's attributes." ], "patch_rules": [ "Capacity statements, occupancy snapshots, readiness assessments, measure results and disruption notices are append-only: a correction is a new versioned record that supersedes the prior one, never an in-place edit.", "Directory records (offerings, bindings, availability, role authorizations) may be patched in place only for non-published fields; any change to a field carried in a public projection creates a new version and resets that field's verification status.", "Every patch records the changing agent, the reason, the ingestion time and a supersedes reference; a patch that cannot name an agent is rejected.", "A patch may never introduce a field prohibited by a boundary rule, in particular encounter status, timing or disposition fields, personal clinical content, or copied location, organization or qualification attributes." ], "compatibility_rules": [ "Adding an optional data element, an additional projection or a new coded value to an open value set is a minor version change.", "Narrowing cardinality, making an element required, removing a coded value, changing a capacity basis definition, changing a waiting-clock rule or changing measure population criteria is a breaking change requiring a major version and a stated migration path for existing records.", "Records remain valid under the model version and jurisdiction profile version in force when they were created; consumers must read both versions from the record rather than assume the current one.", "Alignment targets are versioned independently: a change in FHIR release, in the national directory guide or in a jurisdiction profile does not silently change this model, and any re-binding is an explicit, recorded change." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record for that record class - for example the provider organization's own service catalogue identifier, a national provider or facility registry identifier, or the sending system's referral identifier - always recorded together with its issuing system.", "Governed global identifier or IRI published by a recognized registry or terminology authority, used when no master-system identifier exists for the record class but a governed external identifier does.", "UUID or ULID minted by the adopting Dimension, used only when neither of the above exists; it must be recorded with the minting system and must never encode or be derived from a date, a sequence of dates or any time value." ], "timestamp_rule": "Every time value is an RFC 3339 date-time that includes seconds and an explicit numeric offset or 'Z'; the originating local offset is preserved rather than normalized away, and '-00:00' is used only to mean that UTC is known but the local offset is not. Event time (when the delivery fact occurred - the capacity period, the listing instant, the referral send, the disruption start) is recorded separately from observation time (when it was measured, assessed or asserted) and from ingestion time (when this model received it); where any two of the three differ, all applicable values are stored, and a record carrying only one must declare which kind it is. A date without a time is permitted only for genuinely date-granular fields such as a re-verification due date, and a date is never used as an identifier.", "serial_naming_rule": "Artifacts issued repeatedly for the same subject - capacity statements, occupancy snapshots, readiness assessments, measure results and disruption notices - are named //, where sequence is a monotonically increasing integer scoped to the subject and, where applicable, the reporting cycle. The sequence is never derived from a timestamp, and the reporting period or instant is carried as an attribute rather than as part of the name, so that late, corrected and re-issued returns can be ordered without ambiguity.", "integrity_rule": "Each artifact carries a content digest computed with a named algorithm over its canonical serialization, together with the identifier and version of the source system and of the model and jurisdiction profile in force. Derived artifacts - measure results and published projections - carry the digests of every input artifact; a derived artifact whose input digests cannot all be resolved is invalid and must be marked incomplete rather than published, and a tombstoned input makes dependent derivations unrecomputable rather than silently changed." }, "policies": [ "Reference, never replicate: organization, place, person, qualification, clinical and encounter facts are held as identifier pairs, and any locally copied attribute of those entities is a defect regardless of convenience.", "No universal defaults for jurisdiction-bound rules: waiting-clock definitions, capacity inclusions and exclusions, eligibility rules, retention periods and suppression thresholds must be supplied by a named, versioned profile, and a record that cannot name its profile is not publishable.", "Definitional basis travels with the number: no capacity, occupancy, waiting or utilization value may be stored or published without the basis code and definition profile that make it interpretable.", "Declare, do not enforce: this model declares projection constraints, retention classes and escalation recipients; evaluation, enforcement, notification delivery, audit capture and disposition execution are performed by the models that own them.", "Stop at the encounter boundary: delivery records may reference encounters and count them for flow and utilization, but any field asserting encounter state, timing, participants or disposition is rejected at write time.", "Autonomous actions: directory reads; ingest of attested master-system feeds; scheduled capacity census; slot updates from the owning provider.", "Confirmation-required actions: minting local identifiers; facility commissioning; disaster privileges; availability divert; referrals; waiting-list clock starts; tombstones.", "Forbidden actions: starting or stopping encounters; computing clinical quality measures; enforcing licences; writing audit stores.", "Regional licensing, eligibility, accreditation, anti-dumping, reporting and waiting-time rules are recorded as profile-specific facts and are never treated as universal axioms.", "Deletion is tombstone-first: status transition to inactive, closed, superseded or deprecated rather than silent erase, with the authoritative identifier, succession links, close event time and provenance retained." ], "crud": { "read": [ "Read is scoped by named projection: a reader resolves a projection definition version first, and receives only the fields that projection permits for their recipient class and purpose.", "Reads of capacity, queue and flow data below the bound suppression threshold return aggregated or suppressed values, never raw small-number counts.", "Every read of a derived value returns the measure or projection version, the input digests and the comparability caveats alongside the value.", "Resolution of an encounter reference is a read against the contained model WM-ACT-018; failure to resolve returns an incompleteness marker and never a locally reconstructed encounter." ], "create": [ "Creation requires a resolved steward, an authority basis, a bound jurisdiction profile version and an identifier assigned under the identity priority.", "Creation of a binding, queue entry, commitment, referral or transfer requires that all referenced entities resolve in their owning models at write time.", "Creation records ingestion time always, and event and observation time whenever they are known and differ from it.", "Creation of any record carrying a prohibited field - encounter state, clinical content, or copied organization, place or qualification attributes - is rejected rather than silently stripped." ], "update": [ "Append-only classes (capacity, occupancy, readiness, measure results, disruption notices) are never updated in place; a correction supersedes the prior version and both remain resolvable.", "Directory record updates that touch a published field reset that field's verification status and schedule re-verification against a primary source.", "Every update records the changing agent, reason and supersedes reference; state transitions are permitted only where the transition matrix and the acting role allow them.", "An update may not change a record's jurisdiction profile version retrospectively; a profile change produces a new record version with the new profile named." ], "delete": [ "This model does not execute deletion. It assigns each record class a retention class and a retention policy reference; the adopting Dimension's retention and disposition policy model owns the period, the trigger and the execution, and holds the evidence that disposition occurred.", "Records under an active legal hold are ineligible for disposition until the hold is lifted and the lifting instrument is recorded.", "Disposition of any record that other models may reference - offerings, bindings, queue entries, referrals, transfers, capacity statements and measure results - must leave a tombstone carrying the identifier and issuing system, the record class, the disposition instant, the retention policy reference and any successor reference, and nothing else; resolvers encountering a tombstone report a disposed record rather than a missing one.", "Entered-in-error records are marked as such and retained under their retention class rather than removed, so that superseded measure results and published projections remain explicable.", "Disposition of an input artifact does not retroactively alter a derived measure result or published projection; the derivation becomes unrecomputable and is flagged as such, and this model records that flag without asserting any audit or enforcement outcome." ] }, "roles": [ { "name": "Delivery network steward", "responsibilities": [ "Owns service offering entries, delivery bindings and role authorizations for a provider organization", "Ensures referenced organization, place and person records resolve and are not copied locally", "Initiates attestation and responds to failed verification" ] }, { "name": "Capacity and readiness reporter", "responsibilities": [ "Records capacity statements, occupancy snapshots and readiness assessments with an explicit basis and definition profile", "Meets the reporting cadence set by the obligating instrument and records late or corrected returns as new versions", "Declares source system, observation time and ingestion time for every submitted value" ] }, { "name": "Access and queue coordinator", "responsibilities": [ "Registers demand, maintains priority class and executes permitted queue transitions", "Applies the bound waiting-clock profile and records the clock effect of every offer, refusal and deferral explicitly", "Commits and releases capacity against queue entries and referrals" ] }, { "name": "Referral and transfer coordinator", "responsibilities": [ "Routes referrals, records dispositions and preserves the chain across redirections", "Records transfer milestones and the responsibility-transfer point, including failed transfers", "Links encounter references to fulfilled queue entries and consumed commitments without importing encounter state" ] }, { "name": "Measure and disclosure steward", "responsibilities": [ "Maintains versioned measure specifications and authorises result publication", "Applies suppression thresholds and records comparability caveats and break-in-series markers", "Maintains projection definitions and their permitted field sets, purposes and recipient classes" ] }, { "name": "Model maintainer", "responsibilities": [ "Maintains version bindings to FHIR releases, the national directory guide, ISO 7101 and the jurisdiction profile", "Runs the boundary check that rejects target-owned concepts before publication", "Registers relation-ledger edges and records unresolved boundaries as gaps rather than as settled structure" ] } ], "access": { "default_rule": "Deny by default. Every read and write resolves against a named projection or record class and an explicitly granted recipient class and purpose; the grant is owner-gated by the steward of that record class and evaluated by the external access-authorization model, which this model references but does not implement.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "The public directory projection - offerings, classifications, modalities, locations, published availability, access channels and referral methods - is readable without a person-linked grant, provided every field carries a current verification status.", "Public health and regulatory recipients may receive capacity, occupancy and readiness data under a named reporting obligation, at the aggregation level that obligation specifies, without subject-level access.", "Emergency access to operational availability and capacity may be granted under a break-glass provision defined by the adopting Dimension; this model records that the exception path exists and its required justification fields, while the decision and its logging belong to the access-authorization and audit models.", "Person-linked records - queue entries, referrals, transfers and encounter references - are never included in any public or aggregate projection, and no exception in this list overrides that.", "Practitioner home address and telephone are flagged as sensitive and suppressed from public directory projections because of privacy and safety risk.", "Capacity and waiting values that risk identifying individuals are aggregated with small-number suppression and a suppression threshold before public release.", "Costing present on internal directories is omitted from the public directory projection.", "Emergency credential verification may require role, registration and privilege facts to be readable to responders under a jurisdiction profile." ], "audit_requirements": [ "Every artifact records its recording agent, ingestion time and supersedes reference so that a change is explicable from the record itself; this is provenance and is distinct from the audit trail.", "Every published projection instance records the projection definition version, the suppression rule applied and the input digests, so that a disclosure can be reconstructed without consulting the audit trail.", "Capture, storage, retention and querying of access events belong to the external audit model; this model states the events that model is expected to receive (projection release, break-glass access, stewardship handover, retention instruction change) and claims no ownership of audit-trail semantics.", "Provenance for every write is emitted to the audit sibling; this model does not implement the audit store.", "Federated directory updates are time-stamped, with source directory URI, update watermark and deprecation status retained.", "Inactivation is recorded as a tombstone with identifier, succession, close event time and provenance instead of a silent erase.", "Capacity, staffing and status records carry reporter, event time and observation or ingestion time so that stale or unattributed reports are detectable." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and version", "Relations URL", "Jurisdiction profile URL" ], "read_order": [ "Read AGENTS.md first and resolve Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other file.", "Read the scope statement, in-scope and out-of-scope lists and boundary notes, and confirm the contained model WM-ACT-018 and the referenced person, organization, place, access, retention and audit models are resolvable.", "Read the bound jurisdiction profile version for waiting-clock rules, capacity definitions, eligibility, retention periods and suppression thresholds; stop and request it if it is absent, because no default exists.", "Traverse Bundle to Layer to Finding to Question to Artifact, treating each finding as either artifact-bearing or inline-only and never both.", "Apply the five-facet assessment (identity and class, direct properties, recognition and observation, capabilities and behaviour, context and evidence) and mark each answer as fact, hypothesis or unknown.", "Before any write, run the pre-write checks: identity priority, timestamp profile, prohibited-field rejection, reference resolution and profile version binding; after any write, run the post-write checks: digest recomputation, verification status, projection eligibility and boundary re-check.", "Escalate for confirmation rather than acting autonomously on publication of a projection, declaration of a disruption, change of a retention class or any write that would touch an out-of-scope concept." ] } }, "coverage": { "claim": "Merged model uses the Claude result as base (6 bundles, 16 layers, 27 findings, 17 artifacts, 16 functions, 18 sources from HL7, WHO, ISO, Eurostat, CDC and IETF) and adds one Grok finding plus two functions covering directory discovery, electronic endpoints and federated-ingest provenance. Coverage is defensible for the delivery-system boundary - offering identity, provider and location binding, role authorization, published availability, capacity and occupancy, readiness, access conditions, queue and waiting state, capacity commitment, referral routing, responsibility transfer, encounter reference, quality commitment, measurement, disruption and record governance. It is explicitly not universal: jurisdiction waiting-clock rule suites, ISO 7101 normative clauses, OECD comparative indicators and terminology value sets are unverified, and the Appointment, EpisodeOfCare, transport and social-care boundaries are unadjudicated.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Identity priority is fixed with the authoritative master-system identifier first, a governed global identifier second and a Dimension-minted UUID or ULID last; dates are excluded from identifiers, and every reference is an issuing-system and value pair. Grounded in the national directory guide's primary-source verification model and FHIR's identifier semantics." }, { "dimension": "lifecycle", "status": "covered", "notes": "Offering status and effective period, role authorization period, queue-entry state transitions, referral dispositions and transfer milestones are modelled locally. Encounter lifecycle is explicitly excluded and delegated to WM-ACT-018; organization, facility and qualification lifecycles are delegated to their owning models." }, { "dimension": "relationships", "status": "covered", "notes": "Offering-to-organization, offering-to-location, role-to-service, queue-to-service, referral-to-target, transfer-between-parties and encounter-reference cardinalities are all stated, with an explicit rule that many-to-many bindings carry references only and never copied attributes." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with mandatory seconds and explicit offset is bound as the timestamp profile, event time is separated from observation and ingestion time following FHIR Provenance's occurred versus recorded distinction, operating hours carry an IANA time zone, and snapshot instants are distinguished from period aggregations." }, { "dimension": "provenance", "status": "covered", "notes": "Source system, recording agent, three time kinds, supersession links and content digests are required on every artifact; the boundary between record provenance and the externally owned audit trail is stated using the FHIR Provenance versus AuditEvent distinction." }, { "dimension": "ownership", "status": "covered", "notes": "Stewardship is assigned per record class with an authority basis, jurisdiction profile and handover rule for merger, closure or service transfer. Six operating roles are defined with non-overlapping responsibilities." }, { "dimension": "validation", "status": "covered", "notes": "Attestation and primary-source verification with per-field status and re-verification due dates are modelled from the national directory guide; measure specifications carry computable population criteria, and pre-write and post-write checks are specified in the bootstrap read order." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with projection-scoped grants at bundle, layer, finding and artifact scope; public directory, regulatory reporting and break-glass exceptions are enumerated, with the explicit statement that evaluation and enforcement belong to the referenced access-authorization model." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention classes, legal hold, tombstone field sets and entered-in-error handling are declared locally, while period-setting and execution are delegated to the adopting Dimension's retention and disposition policy model, which also holds the evidence of execution." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignments are declared to FHIR R5 delivery and scheduling resources, FHIR Measure, the national directory guide and RFC 3339, with version pinning required and no conformance claimed. The R4 basis of the directory guide against the R5 basis of the core alignments is recorded as a conflict." }, { "dimension": "capacity and availability semantics", "status": "covered", "notes": "Published availability, bookable supply, capacity basis (physical, staffed, surge) and occupancy are held as four distinct constructs, with Eurostat and CDC/NHSN definitions cited and their incompatibility recorded as a conflict rather than harmonised away." }, { "dimension": "equity and accessibility", "status": "covered", "notes": "Reach, languages, communication support, accessibility attributes and access-barrier reasons are modelled at service level, grounded in the WHO integrated people-centred services framework and the Eurostat unmet-need reason taxonomy, with person-reported need explicitly left to the survey source." }, { "dimension": "waiting-time clock semantics", "status": "gap", "notes": "Clock start, pause, stop and censoring are modelled as a jurisdiction profile binding, but the national rule suites needed to validate the structure (NHS England RTT recording and reporting guidance; AIHW METeOR elective surgery waiting-time data elements) returned HTTP 403 or empty content and were not verified live. The finding is marked as profile-dependent and must not be treated as canonical." }, { "dimension": "quality management requirements", "status": "gap", "notes": "ISO 7101:2023 is cited for its published scope and quality dimensions only; the ISO catalogue page returned HTTP 403 and the normative clause text was not reviewed, so no clause-level requirement is asserted and the quality-commitment finding is deliberately reference-only." }, { "dimension": "comparative access and performance indicators", "status": "gap", "notes": "OECD Health at a Glance 2025 chapters on waiting times and unmet needs returned HTTP 403 across three URL forms and are not cited. Comparative indicator definitions are therefore supported only by Eurostat, which covers EU countries and self-reported measures, narrowing the evidence base for cross-country comparability claims." }, { "dimension": "security", "status": "not-applicable", "notes": "Transport security, authentication, key management and threat modelling belong to the platform and the access-authorization model. This model states only which fields are prohibited in which projection and which events the audit model is expected to receive." } ], "known_omissions": [ "Jurisdiction-specific waiting-time rule suites were not retrievable; the clock-rule finding is a profile binding, not a validated rule set.", "ISO 7101:2023 normative clauses were not reviewed, so no management-system requirement is mapped to a data element.", "OECD comparative access and waiting-time indicator definitions are absent from the evidence base.", "SNOMED CT and other terminology bindings for service type, specialty, priority and removal reason are named as required but no specific value sets are asserted, since no terminology source was verified in this pass.", "Cost, tariff, contract volume and commissioned-activity concepts are omitted; whether commissioned volume belongs to delivery capacity or to a contracting model is unresolved.", "Emergency and disaster surge governance beyond a disruption declaration - mutual aid, regional escalation tiers, mass-casualty triage capacity - is not modelled.", "Home-based and community delivery are supported as modalities but the visit-territory, travel-time and caseload constructs specific to domiciliary delivery are not elaborated.", "Pharmacy, laboratory, imaging and diagnostic services are treated as ordinary offerings; whether diagnostic turnaround belongs here or in a separate diagnostics model is unresolved.", "Patient transport and ambulance dispatch are neither included nor explicitly excluded and need adjudication against a transport or emergency-response model.", "Blood, organ and tissue inventory as specialised capacity.", "Ambulance offload-delay metrics and EMS vehicle tracking.", "Pharmacy dispensing queues distinct from outpatient waiting lists.", "Teaching-supervision matrices beyond a supervision_required flag.", "Network-adequacy travel-time calculation (insurance regulation).", "Price and costing on internal directories (FHIR mentions costing; no tariff model here).", "Virtual-ward and hospital-at-home operational telemetry.", "Correctional, military, veterans and indigenous health-system facility classes as first-class types.", "ISO/DIS 13940 social-care organisations; social-care delivery is a likely omission unless an adopting profile extends ICHA-HP.", "Prior-authorisation case records (constraint flag only).", "Evidence gap: ISO 7101:2023 normative clause text (facilities management, workforce, virtual care) - catalogue and table of contents only.", "Evidence gap: ISO 13940:2015 full concept definitions (healthcare actor, mandate, activity, encounter) - OBP blocked.", "Evidence gap: US NPPES NPI, CMS Provider of Services, Joint Commission privileging and EMTALA statute text - not live-fetched; treated as region profiles, not canon.", "Evidence gap: FHIR SANER implementation guide for hospital capacity measures - not fetched; capacity modelled from Location, Schedule, Slot and mCSD only.", "Evidence gap: SNOMED CT bindings for service and specialty - not live-fetched; the adopting profile must bind.", "Evidence gap: EU EHDS and TEFCA/QHIN directory rules - not fetched.", "Evidence gap: openEHR demographic model - not fetched.", "Evidence gap: WHO Emergency Medical Teams classification for field hospitals - flagged as a profile gap.", "Evidence gap: Da Vinci Plan-Net and Validated Healthcare Directory implementation guides - not fetched.", "Unresolved boundary: whether Appointment instances (named-person bookings) nest here, under WM-ACT-018, or under a future scheduling sibling; Slot and Schedule are in this model, the named Appointment resource is a hold.", "Unresolved boundary: whether EpisodeOfCare (longitudinal administrative grouping) belongs with WM-ACT-018, personal health or this shell; not modelled locally pending child-model adjudication.", "Unresolved boundary: whether inter-facility transport (ambulance offload, IHE/FHIR Transport) is a care-delivery service offering, a logistics sibling or an encounter movement; the EMS service offering is in scope, vehicle tracking is not.", "Unresolved boundary: social-care providers in ISO/DIS 13940 second edition versus SHA HP classifications.", "Hold: the CONTAINS WM-ACT-018 relation remains review_state candidate and the aggregate-shell versus WM-ACT-018 split is not yet adjudicated.", "Hold: independent Claude research and a no-tools adversarial audit have not run.", "Hold: https://ver.cy/model-agent-protocol.md and the specification, storage and interface URLs are publication dependencies.", "Hold: cross-jurisdiction profile testing is outstanding; retention periods, licensing rules, access exceptions and quality thresholds must be supplied by adopting-jurisdiction policy.", "Search and fetch budget: 6 searches and 12 fetches used; ISO OBP, the ISO 7101 HTML page and the NHS ODS full page failed or were challenged, so claims from those three rest on search snippets plus catalogue URLs." ], "conflicts": [ "Eurostat defines available hospital beds as regularly maintained, staffed and immediately available while excluding recovery trolleys, same-day-care beds and provisional or temporary beds; CDC/NHSN defines staffed inpatient beds as currently set up, staffed and usable and explicitly includes overflow, observation and active surge or hallway beds. The two counts are not interchangeable, which is why capacity basis and definition profile are mandatory fields rather than optional annotations.", "All FHIR R5 resources cited here carry Trial Use standards status at maturity levels 3 to 5. Alignment is therefore declared, and conformance is not claimed for any structure in this model.", "The HL7 national directory guide is built on FHIR R4 and US Core 6.1.0, while the delivery, scheduling and measurement alignments are to FHIR R5. A projection cannot satisfy both without an explicit version choice and mapping.", "FHIR separates published directory availability from bookable supply carried by Schedule and Slot, whereas several national reporting programmes publish a single figure described as capacity that is in fact an occupancy snapshot. This model refuses the conflation and stores them as separate artifacts.", "WHO SARA v2.2 dates from 2015 and assesses readiness at facility level using tracer items, while the FHIR alignments are service-level and resource-oriented. Mapping SARA domains onto per-offering readiness is approximate and is recorded as such.", "ISO 7101:2023 states requirements for an organizational management system and defines no delivery data elements, so it cannot be treated as a schema alignment; it is bound at requirement level only.", "The registry marks the CONTAINS edge to WM-ACT-018 as a candidate while this model treats the encounter boundary as strict. If the edge is later re-typed, the encounter-reference finding and the delivery-flow measures that depend on it must be re-adjudicated.", "FHIR R4 versus R5: IHE mCSD 4.0.0 is based on FHIR R4 while this research used FHIR R5 pages (HealthcareService.offeredIn, the Availability datatype, EncounterHistory replacing statusHistory). Alignment must be version-pinned per adopting profile.", "Location versus Organization for ward: FHIR treats Location as physical and Organization as conceptual, while IHE Facility is a pairing of both. Do not collapse them.", "ICHA-HP versus operational registries: SHA providers are expenditure-statistical classes, so a hospital (HP.1) may also deliver outpatient and long-term care functions; operational type codes will not be 1:1 with HP.", "Encounter aggregation: FHIR Encounter explicitly notes jurisdictional variance in what starts a new encounter. That variance is WM-ACT-018's problem; this parent must not pick a universal encounter grain.", "Waiting-time clocks: NHS RTT 18-week consultant-led clocks, cancer timed pathways, Polish statutory waiting lists and OECD waiting-time indicators are not equivalent. Record the methodology URI; do not universalise codes 10-34.", "active versus notAvailable: FHIR HealthcareService.active is not for holidays or maintenance, and Location.status versus operationalStatus is a second distinction. Agents must not treat all closures as inactivation.", "ISO 13940 social care: the DIS second edition explicitly adds social care and SHA HP.2 is residential long-term care, so whether social-care delivery belongs in this model is unresolved." ], "regional_assumptions": [ "Waiting-clock rules, priority and clinical urgency schemes, and removal-reason vocabularies are jurisdictional; none is assumed, and every queue entry and waiting measure must name its profile version.", "Capacity reporting obligations, cadences and recipient authorities are jurisdictional. The CDC/NHSN obligation cited is United States-specific and effective from 1 November 2024 for named facility types; it is evidence that such obligations exist, not a universal requirement.", "Bed and capacity definitions cited from Eurostat apply to EU statistical reporting and to a hospital-centric model; ambulatory, community, home and virtual delivery need locally defined capacity units that this model deliberately leaves open.", "Unmet-need measurement cited from EU-SILC covers private households and residents aged 16 or over in the EU and excludes institutional populations, so access measures built on it are not globally portable.", "Directory attestation and primary-source verification practices are drawn from a United States national directory guide; the existence and authority of licensure boards and equivalent primary sources vary by jurisdiction.", "Retention periods, legal-hold mechanisms, disclosure purposes and small-number suppression thresholds are set by national law and are supplied entirely by the adopting Dimension.", "Accreditation and quality certification regimes differ by country; this model records commitments as assertions with external evidence and makes no claim that any regime is in force.", "NHS ODS codes, the RTT status list and WLMDS cadence apply only when the adopting Dimension declares an England profile.", "NPI as a person-or-organization identifier applies only to a US profile and was not live-verified in this pass.", "Eligibility, licensing, accreditation, anti-dumping, Certificate of Need, network adequacy, CLIA, DEA, 340B, cancer two-week waits and statutory waiting-list statutes are profile-specific.", "Retention periods for medical and administrative records (commonly 7-30 years) are jurisdiction policy, not a global constant.", "Public-directory privacy of health-worker home contacts is required by IHE consideration, but the legal basis (HIPAA, UK GDPR and others) is jurisdictional." ], "adversarial_checks": [ "Checked that the aggregate root does not absorb encounter lifecycle: the encounter-reference finding is inline-only, prohibits encounter status, participant, timing and disposition fields, and its function marks unresolved references as incompleteness instead of reconstructing them.", "Checked that published directory availability is never conflated with bookable supply or with operational capacity: three separate findings with separate artifacts, and an explicit boundary note citing the FHIR HealthcareService and Schedule separation.", "Checked that practitioner qualifications, licensure and employment are referenced and not duplicated: the role authorization finding carries only the authorization period and its service and location bindings, following the FHIR split between Practitioner and PractitionerRole.", "Checked that person-linked queue, referral, transfer and encounter data are excluded from public and aggregate projections by construction, with the exclusion stated as a non-overridable access rule rather than a default.", "Checked that physical bed stock, staffed and immediately available capacity, and surge or overflow capacity are distinguishable, with capacity basis and definition profile mandatory because the Eurostat and CDC/NHSN definitions genuinely conflict.", "Checked that waiting-time semantics define clock start, pause, stop and censoring, and that the absence of verified national rule suites is declared as a gap rather than papered over with an invented default.", "Checked that virtual, mobile, home, emergency and cross-organization delivery are representable: modality is a required multi-valued element, locations may be instance or class mode, and virtual delivery points are referenced through their own detail structure.", "Checked that event, observation and ingestion times are distinct and that the timestamp rule literally requires RFC 3339 with seconds and an explicit offset or 'Z', with '-00:00' reserved for an unknown local offset.", "Checked that deletion execution is delegated to the retention policy model while tombstone content, legal hold and entered-in-error handling remain declared here, and that disposition of an input does not silently mutate a derived result.", "Checked that no bundle, layer, finding or function claims evaluation, enforcement or audit-trail semantics: the projection finding names the external evaluator, the disruption finding stops before cause attribution and investigation, and the provenance finding states that referencing an audit record confers no audit ownership.", "Checked that regional accreditation, licensing, eligibility and reporting rules are marked profile-specific: every such rule is bound to a named jurisdiction profile version, and the model supplies no defaults.", "Relation-ledger check against CONTAINS WM-ACT-018: encounter lifecycle, ADT, class, subjectStatus, EncounterHistory, admission and discharge operations and encounter evaluation or execution are owned by no bundle, layer, finding or function here; f-enc-nested-binding is inline binding only and bindNestedEncounter does not create or run encounters; referral and waiting entries point at encounter_instance_ref as a fulfilment parameter, not a reproduced lifecycle.", "No local ownership check: evaluation engines, encounter execution, licence enforcement and audit-trail stores are referenced but never implemented; every reference to an evaluator, enforcement engine or audit record is accompanied by an explicit non-ownership statement.", "Machine-gate preflight: identity_priority[0] names the authoritative master-system identifier; the timestamp rule contains RFC 3339, seconds and offset and splits event time from observation or ingestion time; the coverage checklist carries the ten mandatory dimensions; crud.delete carries retention, disposition, tombstone and a named execution owner; regional rules are marked profile-specific.", "Hazard sweep: unsafe disclosure of practitioner home contacts, identifiable small-number capacity, accepting demand the service cannot staff, and divert of emergency services where a profile forbids it are each bound to an access exception or a recorded constraint rather than left implicit.", "Failure-mode sweep: stale federated directory, missing clock start, capacity census without observation time, a duplicated encounter store and silent delete without tombstone are each detectable by the owned validation rules; recovery is tombstone, re-ingest or child-model correction, never a local encounter rewrite." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": { "contract_version": "1.0.0", "mode": "dual-provider", "effective_at": "2026-09-05T11:39:25Z", "scope": "Queued subject-model research from WM-XCT-037 onward", "active_providers": [ "claude", "grok" ], "waived_providers": [], "review_rule": "Claude and Grok results require comparison, separate no-tools adversarial adjudication, synthesis and validation before publication." }, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Both providers independently returned aggregate and the base scope statement supports it: the root is the standing capability to deliver named health services together with the administrative records that publish, quantify, allocate, coordinate, measure and govern that capability. It composes several record classes (offering, binding, availability, capacity, readiness, queue, commitment, referral, transfer, measure, disruption, governance) under one consistency and stewardship boundary, which is aggregate rather than entity or event. The registry value standalone-mm is a record-plane classification and is deliberately not carried into the subject-model kind. Encounter lifecycle stays with the contained model WM-ACT-018 as reference plus delivery-side attribution keys only." }, "decisions": [ { "concept": "Base provider selection", "disposition": "base = claude", "rationale": "Claude states a delivery-capability root with ten sourced boundary notes, each naming the neighbour model and the distinguishing evidence, and holds organization, place, person, qualification, clinical and encounter facts strictly as references. Grok is coherent but takes ownership of provider-registry, facility-master and practitioner-registration records that it simultaneously assigns to sibling models, which leaves the outer boundary ambiguous. Size was not the deciding factor; completeness of the boundary was." }, { "concept": "Aggregate root and entry kind", "disposition": "accepted as aggregate", "rationale": "Both providers agree, and the scope statement composes multiple record classes under one stewardship and consistency boundary. The record-plane value standalone-mm from the registry entry is not a subject-model kind and is excluded from this decision." }, { "concept": "Directory discovery, endpoints and federated ingest", "disposition": "accepted into stewardship-and-provenance", "rationale": "Endpoints and federated watermark, conflict-resolution and deprecation provenance are wholly absent from the base and are backed by IHE mCSD v4.0.0, a live-fetched tier-1 source. The wording is compatible with the base non-ownership and no-hard-delete policies, so it can be copied verbatim without contradicting the root." }, { "concept": "Projection-scoped directory query function", "disposition": "accepted", "rationale": "The base declares a projection-scoped read model but no read function, so agents have no declared discovery operation. The added function reads under a named projection and asserts no ownership of the referenced entities." }, { "concept": "Deactivate-with-tombstone function", "disposition": "accepted", "rationale": "The base delete policy mandates tombstones and forbids silent erase but declares no function that performs deactivation and writes the tombstone. The Grok function matches that policy verbatim and explicitly refuses physical destruction and encounter deletion." }, { "concept": "Provider organization registry, lifecycle, succession and affiliations", "disposition": "rejected", "rationale": "Grok f-prov-identity and f-prov-lifecycle-affiliation assert ownership of provider registry identity, open and close status, merger succession and partOf hierarchy. The base out-of-scope list and the Organization boundary note assign incorporation, ownership and legal-entity lifecycle to the organization model, so copying these verbatim would contradict the chosen boundary." }, { "concept": "Facility master identity, hierarchy and commissioning", "disposition": "rejected", "rationale": "Grok f-fac-identity-structure and f-fac-operation claim master facility list identity, campus-to-bed hierarchy and commissioning or closure events. The base assigns site geometry, estates records and building lifecycle to the place model and holds only offering-to-location bindings, so these findings contradict the root as written." }, { "concept": "Practitioner registration and privileging facts", "disposition": "rejected", "rationale": "Grok f-role-identity-authority carries registration, licence-to-practise and facility privileges as owned facts. The base explicitly excludes practitioner qualification, licensure and registration and keeps only the time-bounded delivery authorization, following the FHIR Practitioner and PractitionerRole split. The locum, unnamed-occupancy and disaster-credential ideas inside it are worth revisiting but cannot be imported inside this wrapper." }, { "concept": "Role placement at facilities, services and availability windows", "disposition": "rejected", "rationale": "Duplicates the base role-authorization-binding for service and location coverage and the base published-availability finding for availability windows, and would create a second directory record for the same fields, which the base inline-only rationales specifically forbid." }, { "concept": "Schedule and Slot as bookable capacity", "disposition": "rejected", "rationale": "Grok f-cap-schedule takes ownership of Schedule and Slot. The base boundary note cites the FHIR separation of directory availability from bookable supply and assigns Schedule, Slot and Appointment to the scheduling neighbour while keeping only supply-side capacity commitment and release. Importing it verbatim would directly contradict that note." }, { "concept": "Licence-to-operate and accreditation facts", "disposition": "deferred", "rationale": "A service-level authorization-to-operate precondition may be a genuine gap, since the base quality-commitment-reference covers certificates only as assertions. But the Grok finding is scoped to providers and facilities, entities the base does not own, and the base Organization boundary note explicitly excludes the accreditation award. Deferred to a boundary adjudication with the organization model rather than accepted or discarded." }, { "concept": "Waiting-list entry and waiting-time clock", "disposition": "rejected as a node, evidence deferred", "rationale": "Grok f-wait-demand collapses into one finding what the base splits across demand-registration-entry, waiting-clock-rule and queue-exit-and-removal, so copying it would create a competing queue record. Its underlying NHS England RTT and WLMDS sources are valuable because the base recorded exactly this as a 403 gap, so the evidence is routed to deferred research as a named England profile binding, not as canon." }, { "concept": "Availability exceptions, divert and anti-dumping override", "disposition": "rejected", "rationale": "Overlaps the base published-availability exceptions and the base delivery-disruption-declaration. The one genuinely distinct element, a profile-specific emergency-acceptance obligation that forbids divert, is cited to FHIR HealthcareService and ISO 7101, neither of which supports it, and Grok itself records the statute text as not live-fetched." }, { "concept": "Rostered coverage and on-call arrangements", "disposition": "rejected", "rationale": "The comparison already matches it to the base role-coverage-and-vacancy finding. The base deliberately carries coverage as a derived inline assertion so it does not become a weaker copy of the rostering system of record, and the Grok version adds an artifact-bearing quantified statement plus disaster-privilege questions that reach into the excluded qualification model." }, { "concept": "Parent binding to contained encounter instances", "disposition": "rejected", "rationale": "Duplicates the base encounter-reference-binding, which is stricter: it enumerates the delivery-side attribution keys, names the prohibited encounter fields and defines the fallback when the contained model is unresolvable. Two containment bindings would create competing parent-side semantics for the same CONTAINS edge." }, { "concept": "Reporting obligations, ownership, validation and retention", "disposition": "rejected", "rationale": "Duplicates the base record-stewardship-and-authority and retention-and-disposition-instruction findings, which already carry steward per record class, authority basis, handover on merger, retention class, legal hold, tombstone content and disposition evidence with a named external execution owner." }, { "concept": "Service offering identity, eligibility and booking constraints", "disposition": "rejected", "rationale": "Grok f-svc-offering and f-svc-constraints map onto the base service-offering-identity, provider-location-binding, eligibility-and-entry-condition and access-accommodation-and-reach findings with no material addition, and their costing question reaches into the excluded billing and tariff area." }, { "concept": "Eurostat versus CDC capacity definitions", "disposition": "retained as a recorded conflict, not blocking", "rationale": "Both providers surfaced the incompatibility between staffed-and-immediately-available beds and staffed beds including overflow and surge. The base resolves it structurally by making capacity basis and definition profile mandatory fields rather than harmonising the numbers, which is the correct treatment for a research draft." }, { "concept": "Service-layer merge", "disposition": "merge applied", "rationale": "The base service layers are the more complete set (dimension package, canon and patch, artifact rules, policies, CRUD, roles, access, bootstrap). Grok's distinctive contributions - federated conflict resolution, sensitive-contact suppression and the R4 versus R5 version-pin requirement - are compatible with the base and are carried as publication holds rather than as competing layer text." } ], "publicationHolds": [ "Source verification is incomplete: re-resolve all 18 base sources live with version pins before publication. The base research recorded HTTP 403 or empty responses for the ISO catalogue page, OECD Health at a Glance and the national waiting-time rule suites, and Grok recorded failures for ISO OBP, the ISO 7101 HTML page and the NHS ODS full page.", "The accepted finding and both accepted functions cite Grok SRC-009 (IHE mCSD v4.0.0 volume 1, 2025-05-21). That source must be imported into the merged source list and the source_refs remapped to the merged identifier; do not publish the imported node while its supporting source is absent from the merged evidence pack.", "Grok SRC-017 (NHS England Digital ORD API catalogue entry) rests on search snippets rather than a retrieved page. Live-verify it or reduce the deactivate-with-tombstone function's refs to the mCSD source before publication.", "Multi-profile validation is outstanding: bind and exercise at least two jurisdiction profiles across waiting-clock rules, capacity basis inclusions, eligibility, retention periods and small-number suppression thresholds. The model supplies no defaults, so a single-profile publication would misrepresent portability.", "Confirm the WM-ACT-014 CONTAINS WM-ACT-018 edge, currently review_state candidate in planning/VERCY-MODEL-RELATIONS.csv. If the edge is re-typed, the encounter-reference finding and every delivery-flow measure depending on it must be re-adjudicated. Register the candidate REFERENCE edges to the person, organization, place, personal-health, access, retention and audit models.", "Validate that the imported directory projection view artifact resolves as a derived instance of the base projection definition, carrying the definition version and input digests, and does not stand up as a second competing projection record of record.", "Pin the FHIR release explicitly: the base aligns to R5 while IHE mCSD 4.0.0 and the HL7 national directory guide are R4-based. A projection cannot satisfy both without a stated version choice and mapping.", "Publication dependencies remain open: the Specification, Storage type, Interface and Processes URLs required by AGENTS.md, and https://ver.cy/model-agent-protocol.md, are unverified.", "No terminology value sets are asserted for service type, specialty, priority, removal reason or provider class; neither provider verified a terminology source in this pass, so coded-value bindings must be supplied and verified by the adopting Dimension before publication." ], "deferredResearch": [ "Waiting-clock rule suites: the base recorded NHS England RTT and AIHW METeOR as unretrievable (403) and left waiting-clock-rule as a profile binding, while Grok retrieved NHS England RTT status and the WLMDS live. Re-verify those pages and fold them in as a named England jurisdiction profile bound to the base waiting-clock-rule finding, never as a universal state machine.", "Licence-to-operate versus accreditation award: adjudicate with the organization model whether a service-level authorization-to-operate precondition (CLIA, pharmacy authority, radiation licence) belongs to this aggregate as a deliverability constraint, or whether all such facts are referenced from the organization and place models as the base boundary note currently asserts.", "Schedule, Slot and Appointment ownership: the base assigns bookable supply to the scheduling neighbour while Grok holds Schedule and Slot locally. Adjudicate where slot-level bookable capacity sits relative to the base capacity-commitment-and-release finding before either model publishes.", "EpisodeOfCare and longitudinal administrative grouping: neither provider models it locally and both flag it as unresolved between WM-ACT-018, the personal-health model and this aggregate.", "Patient transport and ambulance dispatch: the base neither includes nor explicitly excludes it and Grok splits EMS service offering (in) from vehicle tracking (out). Adjudicate against a transport or emergency-response model, together with ambulance offload-delay measures.", "Provider affiliation and delivery-network topology: HIE, IDN and network membership with role codes and effective periods appears only in Grok and only inside a provider-registry wrapper this plan rejects. Determine whether delivery-network membership is a delivery fact belonging here or an organization-model relationship.", "ISO 7101:2023 normative clause text and OECD comparative access and waiting-time indicator definitions were unretrievable for both providers; both quality-commitment and comparability claims stay reference-only until the normative text is reviewed.", "Social-care delivery scope: ISO/DIS 13940 edition 2 adds social care and SHA ICHA-HP HP.2 is residential long-term care, leaving it unresolved whether social-care delivery is in this aggregate or an adopting-profile extension." ] }, "statistics": { "sources": 34, "bundles": 6, "layers": 16, "findings": 28, "questions": 98, "artifacts": 19, "functions": 18 } }