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

Interactions

1. Overview of Exchange Pattern

MERT uses a transaction-scoped pull model for data exchange.

When an authorized export is initiated in the source system, the system generates:

TransactionID (functions similarly to a client identifier)
Passphrase (functions similarly to a client secret)
Host URL (the FHIR base endpoint where data can be retrieved)

The importing system uses these credentials to authenticate and retrieve resources from the source system using standard FHIR RESTful endpoints.

MERT does not rely on:

Bundled documents
Batch files
Single NDJSON exports
Full-dataset transaction bundles

Instead, resources are retrieved individually as standard FHIR JSON resources under a shared TransactionID authorization scope.

Implementation note: MERT is implemented as a real-time retrieval (pull) workflow to accelerate implementation and avoid the complexity of creating and storing separate, point-in-time snapshots. Snapshot-based behaviour may be considered in future phases.

2. Transaction Lifecycle

2.1 Export Initialization

When a user initiates an export:

The system validates authorization.
A TransactionID is generated.
A Passphrase is generated.
The dataset scope is determined based on the patient(s) selected and the exporting user’s access permissions.

The TransactionID defines the authorization scope for subsequent retrieval. It does not imply immutability of the underlying data; resources may change between authorization and retrieval.

2.2 Export Revocation

MERT supports controlled invalidation of export credentials prior to their expiration.

The Sender SHALL provide a mechanism allowing the exporting physician or authorized administrator to revoke an active TransactionID.

When a TransactionID is revoked:

The Sender SHALL immediately deny any further data retrieval attempts associated with that TransactionID.
The Receiver SHALL receive an appropriate HTTP error response (e.g., 401 Unauthorized or 403 Forbidden).
The export SHALL be considered permanently invalid and SHALL NOT be resumed.

Revocation SHALL NOT delete audit records associated with the TransactionID.

2.3 Import Retrieval

The importing system:

Connects to the Host URL provided by the exporter.
Authenticates using the TransactionID and Passphrase.
Retrieves resources by type using standard FHIR queries scoped to the TransactionID.
Processes resources using standard FHIR create (POST) operations.

3. Dataset Scope, Privacy & Access Control

The TransactionID binds to the specific patient chart(s) selected for export and the privacy scope of the exporting user.
By default, private data elements are excluded from MERT exports. The exporting system will not expose private patient details in the initial MERT MVP.
The importing system can only retrieve resources that are both within the TransactionID scope and permitted by the exporting user's access permissions at the time of retrieval.
The importing system cannot elevate its privileges or retrieve additional data beyond that scope.

(Privacy enforcement rules and how private elements are determined are defined normatively in the Conformance and Security sections.)

4. Resource Retrieval Model

Resources are retrieved as individual FHIR JSON resources conforming to MERT profiles.
Standard RESTful endpoints are used; paging and retries are supported.
No ID remapping or transformation of references is performed during exchange.
The exchange is designed for hosted EMR targets only; on-premise/self-hosted destination EMRs are out of scope for the initial release.

5. Transaction Scope Discovery and Completion

5.1 Patient Scope Discovery

The Sender SHALL provide a capability to retrieve the list of Patient resources authorized under a given TransactionID.

This Patient list defines the complete patient scope of the transaction.

The Receiver SHALL begin retrieval by obtaining the list of Patients associated with the TransactionID.

5.2 Retrieval Strategy

The retrieval model is patient-rooted and iterative.

For each Patient within the TransactionID scope, the Receiver SHALL:

Query the supported resource types (e.g., Observation, Condition, Encounter, Procedure, DiagnosticReport, MedicationRequest, etc.) associated with that Patient.
Retrieve all pages of results for each resource type.
Process the resources using standard FHIR create (POST) operations.

System-level resources (e.g., Practitioner) that are not strictly patient-scoped MAY be retrieved independently as required.

5.3 Completion Criteria

An import is considered complete when:

All Patients within the TransactionID scope have been processed; and
For each Patient, all supported resource queries return no additional results.

Implementations MAY provide additional confirmation mechanisms (e.g., per-patient counts or resource summaries) to assist in validating completeness, but such mechanisms are not required for conformance.

6. Referential Integrity and Resource Linkage

All resources use standard FHIR references (e.g., Reference(Patient), Reference(Practitioner)).
References are preserved exactly as represented in the source system. No remapping occurs.
Because retrieval is authorization-scoped and live, the availability of referenced resources is subject to:
- The privacy scope associated with the TransactionID
- The exporting user's access permissions at time of retrieval
- The current state of the source system (resources may be created/modified/deleted between export authorization and retrieval)
Implementations SHOULD be designed to tolerate cases where a referenced resource is not retrievable due to authorization constraints or data changes.
Receiving systems SHALL process resources as provided and SHOULD apply local validation and reconciliation policies when referenced resources are missing.

Cross-referencing is maintained between the following resource types (examples; not exhaustive):

Practitioner
Patient
Observation
Condition
AllergyIntolerance
Appointment
Composition
MedicationStatement
MedicationRequest
DiagnosticReport
DocumentReference
Task

7. Recommended Import Order (Implementation Guidance)

Systems implementing MERT import may process incoming resources in different sequences depending on their internal data models, persistence mechanisms, and reference resolution strategies. The MERT specification does not mandate a specific processing order.

However, implementers may wish to consider processing resources in a structured sequence that resolves core references early and reduces the likelihood of dependency failures during import.

Prior to implementing an import workflow, implementers are encouraged to evaluate how their system manages resource dependencies and reference resolution. In particular, systems may wish to consider:

Resource dependencies – identifying which resources are referenced by others (for example, Patient, Practitioner, or Organization references that appear in clinical resources).
Reference resolution strategy – determining whether referenced resources must exist prior to import, can be created dynamically during processing, or can be resolved in a later reconciliation step.
Database or domain model constraints – understanding whether the internal data model requires certain entities to be created before others in order to maintain referential integrity.
Transaction handling – deciding whether the import process will run as a single transaction, multiple staged transactions, or a queued/background processing model.
Error handling and retry behavior – determining how the system should respond when referenced resources are missing or when partial imports occur.

Based on this analysis, implementers may choose to establish a predictable import sequence that processes foundational resources earlier and dependent clinical resources later. Adopting a consistent processing order can help minimize reference resolution issues, simplify error handling, and improve the reliability of the import workflow.

The MERT specification intentionally allows flexibility in how receivers implement this process, provided that imported resources are ultimately stored and linked correctly within the receiving system.

While FHIR servers can technically resolve references regardless of load order, practical experience suggests loading resources in dependency-aware order to reduce validation errors.

Recommended import sequence (guidance, not normative):

Practitioner
Patient
Observation
Condition
AllergyIntolerance
Appointment
Composition
MedicationStatement
MedicationRequest
DiagnosticReport
DocumentReference
Task

Receiving systems may choose an alternate strategy (e.g., staged ingest + reconciliation) provided they handle referential gaps per the guidance above.

8. Import Requirements and Behaviour

Receiving systems must support standard FHIR create operations (POST).
Update operations (PUT) are not required for the initial MERT implementation.
No custom FHIR server extensions are required for standard ingestion of MERT resources.
The MERT import workflow will create a new chart in the destination EMR for each import; no automatic merging with existing destination charts will be performed. Reconciliation and merging of incoming data into any existing chart is the responsibility of the receiving clinician/organization.

9. Data Fidelity and Multiple-Hop Transfers

MERT aims to preserve high fidelity during a single transfer between two systems. However, receiving systems may have limitations (fields not supported, different data models, or business rules) that cause loss or transformation of certain elements.
If data is later exported from an intermediate system (EMR B) to another system (EMR C), portions of the original information from EMR A may be lost or altered depending on EMR B’s ability to fully preserve the content. Over multiple transfers, this can produce apparent data degradation. Implementers should be aware of this behaviour and plan reconciliation/validation activities accordingly.

10. Completion, Validation and Error Handling

An import is considered complete when all resource types expected for the TransactionID scope have been retrieved and processed, or when the importer and exporter agree a transfer is complete (per application-level status).
Implementations SHOULD provide optional validation mechanisms such as expected counts, profile conformance checks, and referential integrity reports to assist receivers in verifying completeness and quality.
Importers SHOULD implement robust retry and partial-failure handling; exporters SHOULD provide idempotent endpoints or resource versioning to facilitate safe retries.

11. Transaction Finalization and Re-Run Semantics

MERT imports implement a transaction-based lifecycle governed by completion of the import workflow and execution of a finalization step. Re-run eligibility is determined solely by whether finalization has occurred.

11.1 Record Processing Model

During a MERT import:

Each individual FHIR resource instance (record) retrieved under a TransactionID SHALL be attempted as part of the import run.
Each record SHALL result in one of the following outcomes:

Record Outcomes

Success – Record successfully created in the destination system.
Skipped – Record intentionally skipped (e.g., already successfully imported during a prior run of the same TransactionID).
Failure – Record failed to import due to validation, processing, authentication, or system errors.

No additional record-level states are defined.

If the import process is interrupted before reaching completion (e.g., authentication error, runtime exception, infrastructure failure), the TransactionID SHALL NOT proceed to finalization.

Interruptions may include, but are not limited to:

Authentication failure (e.g., correct TransactionID but incorrect Passphrase, expired or revoked credentials)
System-level exceptions (e.g., application crash, service restart, database connectivity failure)
Transport or retrieval failures (e.g., network interruption, timeout, incomplete pagination)
Fatal workflow errors that halt the overall import process

In such scenarios:

The TransactionID SHALL remain in a non-finalized state.
Successfully imported records SHALL remain in the system.
The TransactionID SHALL remain eligible for re-run.

If the import workflow reaches the final record without interruption, the TransactionID SHALL proceed to finalization. Finalization eligibility is determined by completion of the import workflow, not by the success of individual records. A transaction MAY contain a mixture of Success, Skipped, and Failure outcomes and still be finalized.

11.2 Finalization Step

The finalization step represents the terminal stage of a MERT import.

When finalization executes:

The TransactionID SHALL be marked as Finalized (terminal state).
Any temporary or transfer-facilitating records created solely to support the import process SHALL be deactivated, soft-deleted, or otherwise removed from active operational use within the destination system.
Imported patient chart data and clinically relevant records SHALL remain intact and accessible.
The TransactionID SHALL become non-rerunnable.

Temporary or transfer-facilitating records may include artifacts created for identity resolution, linkage, or import continuity. Such artifacts SHALL NOT remain as active operational entities after finalization unless clinically relevant.

11.3 Re-Run Behavior

Re-run eligibility is determined solely by whether the TransactionID has reached finalization.

Case A – Finalization Not Reached

If the finalization step has not executed:

The TransactionID MAY be re-run.

During re-run:

Records previously imported successfully SHALL be identified and marked as Skipped.
Only records not yet successfully imported SHALL be attempted.
No duplicate records SHALL be created.

This enables safe recovery from mid-import interruption without data duplication.

Case B – Finalization Reached

If finalization has executed:

The TransactionID SHALL be considered terminal.
Any attempt to re-run the same TransactionID SHALL result in an error indicating that the transaction has already completed and cannot be re-run.

Re-running a finalized transaction is prohibited to prevent duplicate data creation.

11.4 Failure Handling and Recovery

If a MERT import fails and finalization is not reached:

No automatic rollback SHALL occur.
Successfully imported records SHALL remain in the system.

The system SHALL log:

The TransactionID
Failed records
Associated error details

If repeated re-runs of the same TransactionID do not resolve the issue:

The exporting and importing parties SHOULD coordinate to identify affected records or patient charts.
A new export MAY be initiated for only the unresolved charts or records.

11.5 Explicit Non-Requirements

MERT does not require:

Full transaction rollback
Automatic deletion of partially imported charts
Automatic duplicate reconciliation across different TransactionIDs

12. Non-normative Implementation Notes

The IG’s normative requirements related to access control, privacy exclusion of private fields, hosted-only scope, and chart-creation behaviour are described in the Conformance and Security sections.
Examples and sample retrieval sequences are provided in the Examples section to help implementers operationalize this behaviour.