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

Introduction

1. Background

The Medical Electronic Record Transfer (MERT) specification was developed through the Canada Health Infoway’s Vendor Innovation Program (VIP) as part of a vendor-led demonstration project focused on improving data portability and interoperability between EMR systems. The initiative was designed to demonstrate the feasibility of an approach to transferring clinically relevant patient information between EMR platforms while fostering discussion on the future of EMR-to-EMR interoperability and data portability in Canada. The project explored a standards-based approach for the secure transfer of patient records using HL7 FHIR and other pan-Canadian interoperability assets and serves as a tangible example of the innovation and public-good outputs generated through the VIP program.

Please note that this specification is not an Infoway-developed standard, implementation guide, or formally balloted pan-Canadian specification. While the work was funded and supported through Infoway's Vendor Innovation Program, the specification was not created through a formal standards development process or pan-Canadian consensus-based methodology.

As a public-good output of the VIP program, this specification is intended to act as a starting point for industry discussion, evaluation, and further refinement. Lessons learned through implementation and testing can help inform future collaboration among vendors, standards organizations, jurisdictions, clinicians, and other stakeholders. The concepts and artifacts contained within this specification may contribute to the evolution of a more mature and widely adopted interoperability specification in the future.

2. Purpose

Medical Electronic Record Transfer (MERT) is a FHIR R4–based implementation guide that defines how complete patient medical records can be securely and consistently transferred between Electronic Medical Record (EMR) systems in Canada.

MERT focuses on real-world EMR-to-EMR data portability to support continuity of care when patients move between providers, organizations, or jurisdictions.

Unlike summary-based exchange models, MERT defines a structured approach for transferring a patient’s full clinical chart, including demographics, clinical documentation, medications, allergies, conditions, observations, immunizations, documents, appointments, tasks, and related clinical data.

3. Scope of This Implementation Guide

This Implementation Guide (IG):

Defines FHIR R4 profiles for in-scope resources.
Establishes Must Support and Required expectations.
Specifies exchange behaviour between Sender and Receiver systems.
Defines security and authorization expectations.
Clarifies operational constraints such as chart creation and privacy handling.

This IG is intended for EMR vendors and technical implementers integrating MERT into production systems.

This guide does not define provincial policy, consent frameworks, or data-sharing agreements; those remain jurisdictional responsibilities.

4. Exchange Model Overview

MERT uses a transaction-scoped, pull-based exchange model.

When an export is authorized:

A TransactionID and Passphrase are generated.
The receiving system retrieves resources directly from the source FHIR endpoints.
Resources are retrieved individually using standard FHIR RESTful operations.
Data is processed using create (POST) operations in the receiving system.

MERT does not require:

Bundled document packages
Batch files
NDJSON bulk export
Full-dataset transaction bundles

The exchange model prioritizes interoperability, incremental retrieval, and alignment with standard FHIR server behavior.

Detailed exchange rules are defined in the Interactions section.

5. Design Principles

MERT is guided by the following principles:

5.1 Clinical Meaning Over Structural Identity

Conformance requires preservation of clinical meaning, not guaranteed preservation of original structured coding across heterogeneous systems.

5.2 Real-World Implementability

MERT is designed for practical adoption by hosted EMR systems. It reflects common EMR import workflows and avoids requiring architectural changes such as automatic chart merging.

5.3 No Automatic Chart Merging

Imports create a new patient chart or logically isolated record set in the destination EMR. Reconciliation and merging decisions remain the responsibility of the receiving clinician or organization.

5.4 Authorization-Based Privacy Enforcement

MERT does not define a separate privacy filtering layer.

Instead, data exposure is limited to the information that the exporting user is authorized to access within the source EMR at the time of retrieval.

The TransactionID scope reflects:

The selected patient chart(s); and
The exporting user’s access permissions.

The importing system cannot retrieve data beyond the exporting user’s authorization scope.

Privacy enforcement remains the responsibility of the source system.

5.5 Hosted EMR Scope

This release of MERT applies to hosted EMR systems. On-premise or self-hosted deployments are outside the current scope. Hosted environments provide a more consistent and controlled infrastructure, which supports predictable configuration of FHIR endpoints, security, and data exchange workflows required for MERT.

In contrast, on-premise or self-hosted deployments may introduce variability in server configuration, network accessibility, security controls, and system integrations. These variations can create barriers to establishing reliable and interoperable data transfer, and may require additional implementation effort beyond the scope of this release.

6. Relationship to Prior Initiatives

MERT builds upon lessons learned from prior EMR-to-EMR exchange initiatives, including:

Health New Zealand’s GP2GP model
OntarioMD’s Core Data Set (CDS) data portability specification

While those initiatives use different packaging and transport mechanisms, MERT adopts FHIR R4 as its canonical representation model and emphasizes transaction-scoped retrieval aligned with modern FHIR server capabilities.

7. Audience

This guide is intended for:

EMR vendors implementing Sender or Receiver capabilities
FHIR architects and developers
Interoperability program leads
Health IT integrators

Readers are expected to be familiar with:

HL7 FHIR R4
RESTful API concepts
EMR clinical workflows

8. Guide Structure

This Implementation Guide is organized into the following sections:

Scope – Defines in-scope and out-of-scope resources and boundaries.
Conformance – Defines Required and Must Support expectations.
Profiles – Provides detailed FHIR profiles and constraints.
Terminology – Defines coding systems and binding expectations.
Interactions – Defines exchange workflow and retrieval model.
Security – Defines authentication, authorization, and audit expectations.
Examples – Provides sample resource instances and flows.
Testing – Defines validation and verification expectations.