Demo - The specification is a demo of MERT. For a full list of available versions, see the Directory of published versions

Receiver Responsibilities (Importing System)

A system claiming Receiver conformance to MERT SHALL:

1. Accept Must Support Elements

When an MS element is present in a received resource:

• The Receiver SHALL accept the element.
• The Receiver SHALL NOT discard the element solely because it does not natively support it.

2. Retain Must Support Data

Retention in MERT means the Receiver SHALL preserve the clinical meaning of MS elements.

Retention MAY occur in one of the following forms:

• Native structured fields
• Structured attribute/extension store
• Persisted source FHIR resource store
• Narrative or text-based representation that preserves the meaning
• Canonical internal representation capable of future export

If the Receiver does not have a native structured field:

• The Receiver SHALL preserve the information in a retrievable form.
• The Receiver MAY store the information as text, comment, or equivalent representation.

3. Handling Coded Data

If the Receiver does not support the original coding system:

• The Receiver SHALL preserve the human-readable meaning (e.g., display or text).
• The Receiver MAY map the code to a local coding system.
• The Receiver is not required to preserve the original coding in structured form.

4. Multi-Hop Data Exchange

MERT does not guarantee preservation of original structured codings across multiple system hops.

Systems SHOULD attempt to preserve structured data when feasible, but preservation of clinical meaning is the minimum requirement.

Data degradation across heterogeneous systems is recognized as an inherent limitation of current EMR interoperability.

5. Chart Creation Behavior

MERT import SHALL result in creation of a new patient chart or logically isolated record set. Automatic merging with an existing chart is not required and is outside the scope of MERT conformance.

6. Source Identifier Preservation

During a MERT import, the Receiver SHALL preserve the original identifier of each resource as assigned by the source system.

At minimum:

• The Receiver SHALL store the original source system identifier.
• The Receiver SHALL associate the identifier with the imported resource in a manner that maintains traceability.
• The stored identifier SHALL remain retrievable for audit, troubleshooting, or re-run processing purposes.

The Receiver MAY store the source identifier using:

• A dedicated external identifier field,
• A structured reference mapping table,
• A transaction-scoped reference system (e.g., RefSys / RefID model),
• Or an equivalent internal mechanism.

The Receiver SHALL NOT discard the original source identifier after successful import.

Preservation of the source identifier supports re-run safety, duplicate detection, audit traceability, and cross-system reconciliation.

7. Transaction Lifecycle Handling

When performing a MERT import, the Receiver SHALL:

• Process resources under a TransactionID lifecycle.
• Track record-level outcomes as Success, Skipped, or Failure.
• Allow re-run of a TransactionID only if finalization has not occurred.
• Ensure that re-run does not create duplicate records.
• Mark a TransactionID as non-rerunnable after finalization.

If an import fails before finalization:

• Successfully imported records SHALL remain in the system.
• No automatic rollback is required.

Re-run eligibility is determined solely by whether finalization has occurred.