This page documents the alignment of the AeHIN MCCoD Implementation Guide with the WHO SMART Guidelines framework. It is explicit about what has been implemented, what is partially implemented, and what is planned for future versions — to give implementers an accurate picture of the current state of alignment.

WHO SMART Guidelines Framework

The WHO SMART Guidelines framework provides a layered approach to making WHO normative guidelines computable and implementable. The framework defines five layers (L1–L5), of which the first three are most relevant to this IG:

Layer	Name	Description
L1	Narrative Guidelines	WHO normative guidance in human-readable form — the source clinical and policy content that all lower layers derive from
L2	Structured Guidelines / Data Adaptation Kit (DAK)	Structured, non-software-specific representation of the L1 content: personas, workflows, data dictionary, decision logic, indicators, and functional requirements
L3	Machine-readable Guidelines	Technology-specific computable representation — FHIR profiles, logical models, value sets, CQL decision logic, and test data derived from L2
L4	Executable Guidelines	Validated and tested software components ready for deployment
L5	Dynamic Guidelines	Operational guidelines with real-world feedback loops

Adopted Architecture

This IG adopts the WHO SMART Guidelines three-layer architecture as its primary design framework. The mapping for the AeHIN MCCoD context is:

Layer	AeHIN MCCoD Content	Status
L1	WHO International Form of Medical Certificate of Cause of Death; ICD-10 mortality coding rules (Vol. 2); ICD-11 mortality coding rules and DORIS methodology	Referenced. L1 sources are documented and linked in this IG. No L1 content is authored by AeHIN — it is sourced from WHO normative publications.
L2	AeHIN MCCoD data dictionary (Frame A and Frame B), derived from the openEHR death_summary archetype. Persona descriptions (certifying practitioner, mortality coder, civil registrar). Workflow outline.	Partially implemented. The data dictionary component is implemented as FHIR Logical Models (see below). Personas are described in this IG. Full DAK components — BPMN workflows, DMN decision logic, indicators, and functional requirements — are planned for a subsequent version in collaboration with AeHIN member countries.
L3	FHIR R4 profiles, logical models, value sets, code systems, extensions, invariants, and example instances. All derived from the L2 data dictionary with explicit element-level mappings.	Implemented. All L3 FHIR artifacts are defined in this IG. Note: full WHO SMART L3 compliance would additionally require CRMIShareableStructureDefinition conformance and CQL-expressed decision logic. These are planned for a future version.

L2 Data Dictionary — FHIR Logical Models

The most significant L2 contribution of this IG is the pair of FHIR Logical Models for Frame A and Frame B. These serve as the computable data dictionary — the L2 artifact that bridges between the WHO MCCoD form (L1) and the FHIR profiles (L3).

Unlike informal data dictionaries in spreadsheet or narrative form, these logical models are:

• Computable: Expressed in FHIR StructureDefinition format, processable by FHIR tooling
• Mapped: Every element carries three explicit mappings — to the WHO MCCoD form field, to the openEHR death_summary archetype path, and to the target FHIR profile element
• Technology-neutral: The logical models use FHIR primitive types (string, integer, boolean, CodeableConcept) without FHIR resource-level constraints, making them interpretable independently of the FHIR L3 profiles
• Traceable: Every FHIR profile element can be traced back to its logical model element and from there to the WHO MCCoD form field and the openEHR archetype

The two logical models are:

• MCCoDFrameAModel — Frame A data dictionary: causal chain (lines a–d), underlying cause of death, and contributing conditions (Part 2)
• MCCoDFrameBModel — Frame B data dictionary: general medical data (surgery, autopsy, manner, external cause), fetal/infant death, and women of reproductive age

L2 Personas

The WHO SMART Guidelines L2 DAK includes generic persona descriptions for the health workers involved in the guideline's implementation. For the MCCoD context, three primary personas are identified:

Persona	Role in MCCoD Process	FHIR Representation
Certifying Practitioner	The licensed medical practitioner (physician) who examines the deceased, determines the cause of death chain, and signs the MCCoD form. Responsible for the clinical accuracy of Frame A and the supplementary information in Frame B.	Composition.author — Reference to Practitioner or PractitionerRole (base FHIR, unconstrained)
Mortality Coder	A trained coder who applies ICD mortality coding rules (or the DORIS tool for ICD-11) to select the underlying cause of death from the completed certificate. May or may not be the certifying practitioner.	MCCoDUnderlyingCauseOfDeath.recorder — Reference to Practitioner or PractitionerRole (base FHIR, unconstrained)
Civil Registrar	The civil registration authority that receives the completed MCCoD, registers the death, and transmits mortality data to national statistics offices. Responsible for data quality oversight.	Composition.custodian — Reference to Organization (base FHIR, unconstrained)

Full persona specifications — including educational background, digital literacy assumptions, system access patterns, and use case scenarios — are planned for the L2 DAK in a subsequent version.

L2 Workflow — Outline

The high-level MCCoD workflow involves the following stages. Detailed BPMN process diagrams are planned for the L2 DAK in a subsequent version.

1. Death event: Patient dies in a healthcare facility or is brought in deceased.
2. Clinical examination: Certifying practitioner examines the deceased, reviews clinical history, and determines the cause of death chain.
3. Frame A completion: Certifying practitioner documents the causal chain (lines a–d), time intervals, and Part 2 contributing conditions.
4. Frame B completion: Certifying practitioner records supplementary data (surgery, autopsy, manner, external cause, fetal/infant details, pregnancy status) as applicable.
5. Certification: Practitioner signs the certificate (Composition.status = #final).
6. Mortality coding: Mortality coder applies ICD rules or DORIS to select the underlying cause of death. The MCCoDUnderlyingCauseOfDeath resource is created or updated with the selected code and the dorisDerived flag.
7. Registration: Civil registrar receives the completed document Bundle and registers the death.
8. Statistical reporting: Underlying cause of death code is transmitted to national mortality statistics systems.

What This IG Does Not Claim

To maintain accuracy, the following are explicitly not claimed for this version (0.1.0):

• Full WHO SMART L3 compliance: Full L3 compliance as defined by WHO would additionally require all profiles to conform to CRMIShareableStructureDefinition and CRMIPublishableStructureDefinition, and would require decision logic expressed in CQL. These are planned for a future version.
• Full L2 DAK: The nine L2 DAK components include BPMN process workflows, DMN decision logic tables, indicators and metrics, and detailed functional requirements. Only the data dictionary and persona outline have been implemented in this version.
• WHO endorsement: This IG has been designed to align with WHO SMART Guidelines principles and uses WHO source documents as L1. It has not been formally reviewed or endorsed by WHO.
• CQL decision logic: ICD mortality coding rules and DORIS selection logic have not been expressed as CQL in this version. The dorisDerived extension supports recording whether DORIS was used, but does not implement DORIS rules computably within this IG.

Future Alignment Roadmap

The following SMART alignment enhancements are planned for subsequent versions, in collaboration with AeHIN member countries:

• Full L2 DAK authoring: BPMN workflow diagrams, DMN decision tables for ICD mortality coding rule selection, indicator definitions (e.g. completeness rate, timeliness), and functional requirements specification
• CRMIShareableStructureDefinition and CRMIPublishableStructureDefinition conformance for all profiles, adding the hl7.fhir.uv.crmi dependency
• CQL expression of DORIS-equivalent ICD-11 mortality coding rules for computable underlying cause selection guidance
• Formal alignment review with the WHO SMART Guidelines team