MERT Pilot FHIR iGuide
current 
Demo - The specification is a demo of MERT. For a full list of available versions, see the Directory of published versions
Conformance Overview
This section defines the conformance expectations for systems implementing the MERT specification.
MERT distinguishes between:
- MERT Required elements – elements that SHALL be present in a conformant instance.
- MERT Must Support (MS) elements – elements that are optional in the data model but have defined exchange and retention obligations.
Conformance to MERT may be claimed in one or both of the following roles:
- Sender (Exporting System) – a system that generates and transmits MERT-conformant FHIR resources.
- Receiver (Importing System) – a system that receives and processes MERT-conformant FHIR resources.
Systems SHALL clearly identify which conformance role(s) they support.
Unless otherwise specified, all base FHIR R4 constraints remain in effect.
MERT recognizes that systems differ in their internal data models and storage capabilities. Conformance focuses on preservation of clinical meaning rather than guaranteed structural equivalence across systems.
MERT conformance assumes a transaction-scoped pull-based exchange model as defined in the Interactions section. Conformance does not imply point-in-time snapshot guarantees or automatic merging of imported charts with existing records.
Systems claiming MERT Sender conformance SHALL implement transaction-scoped retrieval using credentials as defined in the Interactions and Security sections.
Conformance Addendum – Exchange Model and Operational Constraints
The following statements clarify the operational and architectural expectations associated with MERT conformance.
1. Exchange Model
MERT conformance is based on a transaction-scoped pull-based exchange model, as defined in the Interactions section.
Systems claiming Sender conformance SHALL:
- Generate a TransactionID and associated credentials for authorized export.
- Expose resources for retrieval via standard FHIR RESTful endpoints scoped to that TransactionID.
Systems claiming Receiver conformance SHALL:
- Retrieve resources using the provided TransactionID credentials.
- Process resources using standard FHIR create (
POST) operations. - Update (
PUT) or conditional update operations are not required for conformance in this release.
Support for bundled document exchange, batch files, NDJSON bulk export, or transaction bundles is not required for MERT conformance unless explicitly defined in a future release.
2. Authorization Scope and Privacy
The TransactionID defines the authorization scope for data retrieval.
Senders SHALL restrict exposed data to:
- The patient chart(s) selected for export.
- The privacy scope of the exporting user at the time of retrieval.
Private data elements are excluded from MERT export in the current release.
Conformance does not permit privilege escalation through use of TransactionID credentials.
3. Non-Snapshot Semantics
MERT conformance does not require point-in-time snapshot guarantees.
Data retrieved under a TransactionID reflects:
- Data available in the source system at time of access.
- The current authorization and privacy state at time of retrieval.
Senders are not required to guarantee immutability of resources between export authorization and retrieval.
4. Chart Creation and Merging Behavior
MERT import SHALL result in creation of a new patient chart or logically isolated record set in the receiving system.
Automatic merging of imported data into an existing patient chart is outside the scope of MERT conformance.
Reconciliation and merging decisions remain the responsibility of the receiving clinician or organization.
5. Data Fidelity and Multi-Hop Transfers
MERT conformance requires preservation of clinical meaning, not guaranteed preservation of original structured coding across heterogeneous systems.
When data is transferred across multiple systems (e.g., EMR A → EMR B → EMR C), structural degradation may occur depending on downstream system capabilities.
Systems claiming conformance SHALL preserve clinical meaning but are not required to preserve original structured coding across multiple exchange hops.
6. Hosted Deployment Scope
MERT conformance in this release applies to hosted EMR systems only.
On-premise or self-hosted destination systems are outside the scope of this release.
7. Transaction Lifecycle Conformance
MERT conformance includes behavioral conformance to the transaction lifecycle defined in Section 11 (Transaction Finalization and Re-Run Semantics).
Systems claiming Receiver conformance SHALL:
- Process imports under a TransactionID lifecycle model.
- Track record-level outcomes as Success, Skipped, or Failure.
- Allow re-run of a TransactionID only if finalization has not occurred.
- Prevent duplicate record creation during re-run.
- Reject re-run attempts for finalized TransactionIDs.
MERT does not require full transaction rollback.
A transaction MAY contain a mixture of successful, skipped, and failed records and still be finalized.
Finalization is determined by completion of the import workflow, not by universal record success.
Conformance also includes adherence to the MERT transaction lifecycle model governing import processing, finalization, and re-run eligibility.