This page defines the conformance requirements for systems implementing the AeHIN MCCoD Implementation Guide. It covers conformance verbs, must-support obligations, document conformance, national extension guidance, and validation expectations.

Conformance Verbs

This IG uses the standard HL7 FHIR conformance verbs as defined in FHIR Conformance Rules :

Verb	Meaning
SHALL	Absolute requirement. Non-conformance is a validation error. Systems that do not meet a SHALL requirement are not conformant with this IG.
SHALL NOT	Absolute prohibition. Including the prohibited element or value is a validation error.
SHOULD	Recommended. Deviation is permitted but requires explicit justification. Non-conformance generates a warning, not an error. Systems that deviate from SHOULD requirements are still conformant but suboptimal.
SHOULD NOT	Discouraged. Inclusion is permitted but not recommended.
MAY	Optional. Systems may include or omit the element at their discretion.

Must Support

Elements marked Must Support (MS) in this IG have the following obligations:

• Sending systems: SHALL populate Must Support elements when the data is known and available. If the data is not available and the element is optional, the element MAY be omitted. If the element has a required cardinality (1..1 or 1..*), it SHALL always be populated.
• Receiving systems: SHALL be capable of processing and storing all Must Support elements without error. Receiving systems SHALL NOT discard or ignore Must Support elements.
• Displaying systems: SHOULD render Must Support elements in a human-readable form appropriate to the clinical context.

Must Support does not imply that an element will always be present — it means that when it is present, it must be processed, and when data is available, it must be sent.

Document Conformance

A conformant MCCoD document is a FHIR Bundle of type #document containing a Composition resource as the first entry, conforming to the MCCoDComposition profile.

A conformant MCCoD document SHALL:

• Have Bundle.type = #document
• Contain a Composition conforming to MCCoDComposition as the first Bundle entry
• Include a complete and valid Frame A section — at minimum one MCCoDCauseOfDeathCondition with linePosition = #a and exactly one MCCoDUnderlyingCauseOfDeath
• Have Composition.status set to #preliminary, #final, or #amended
• Reference a Patient resource representing the deceased as Composition.subject
• Reference a Practitioner or PractitionerRole resource as Composition.author
• Reference an Organization resource as Composition.custodian
• Have all error-level invariants satisfied — see Frame A invariants and Frame B invariants

A conformant MCCoD document SHOULD:

• Include Frame B General sub-section when any Frame B data is known
• Include Frame B Fetal/Infant sub-section (or provide emptyReason) when the deceased was an infant aged less than 28 days or was a stillbirth
• Include Frame B Women of Reproductive Age sub-section (or provide emptyReason) when the deceased was female aged 15–49 years
• Populate Condition.code.coding with an appropriate ICD-10 or ICD-11 code for all cause-of-death entries when electronic coding is available

Composition Status Lifecycle

The Composition.status element reflects the lifecycle state of the death certificate:

Status	Meaning	Typical Use
#preliminary	Certificate being completed, not yet signed	In-progress data entry; provisional cause of death
#final	Certificate certified and signed by practitioner	Completed and legally signed certificate
#amended	Certificate corrected after initial certification	Post-certification amendment (e.g. autopsy findings change cause)

When status = #amended, systems SHOULD preserve the original final certificate as a prior version and document the reason for amendment. Member countries MAY define amendment workflow requirements in their national implementation guide.

ICD Coding Conformance

Member countries SHALL declare which ICD version and system URI they use for cause-of-death coding in their national implementation guide. The following rules apply:

• When providing coded cause-of-death values, the coding.system SHALL be a recognised ICD system URI as declared in the national IG
• Condition.code.text SHALL always be present regardless of whether a coded value is provided — this is enforced by error-level invariants
• When ICD-11 and the DORIS tool are used, the MCCoDUnderlyingCauseOfDeath.extension[dorisDerived] SHALL be set to true and the underlying cause code.coding.system SHOULD be http://id.who.int/icd/release/11/mms
• When ICD-10 mortality coding rules are applied manually, dorisDerived SHALL be set to false

National Extensions

AeHIN member countries are expected to create national implementation guides that extend this regional IG to meet national requirements. National IGs:

• MAY define profiled versions of Patient, Practitioner, PractitionerRole, and Organization with national identifier systems and administrative fields
• MAY constrain the cause-of-death ValueSet binding to a specific ICD system URI
• MAY add national extensions to any profile in this IG
• SHALL NOT remove or relax any mandatory constraint (error-level invariant or 1..1 cardinality) defined in this regional IG
• SHALL NOT add codes to the mccod-manner-of-death-codes ValueSet at the national level — this ValueSet is required-bound and regional comparability depends on its stability. National codes may be added as additional codings but the regional code SHALL also be present.
• SHOULD declare the canonical URL of the regional AeHIN MCCoD IG as a dependency in their national IG package

Validation

Implementers SHOULD validate MCCoD documents against this IG using the HL7 FHIR Validator or equivalent tooling. The validator package for this IG can be downloaded from the Downloads page.

During validation, the following are expected for draft builds:

• Terminology server warnings for ICD-10 and ICD-11 system URIs — these occur because the public terminology server cannot expand open CodeSystem includes for ICD systems. These warnings are suppressed during draft builds and do not indicate a conformance failure.
• FHIRPath warnings for cross-resource invariants that use resolve() — these invariants traverse resource references and may not evaluate in all runtime environments. They are defined as warnings, not errors, for this reason.

Before formal publication, the validation: allow-any-extensions parameter will be removed and full terminology validation will be enabled.

Capability Statement

A formal CapabilityStatement for systems implementing this IG is planned for a subsequent version. At minimum, conformant systems should support:

• FHIR R4 (4.0.1)
• POST and GET operations on Bundle (document type)
• Search on Composition by subject, date, and status
• Search on Condition by subject and category to retrieve specific cause-of-death entry types