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

Security

This section defines the security expectations for systems implementing the MERT specification.

MERT is designed for secure, transaction-scoped retrieval of FHIR resources between hosted EMR systems. Security controls apply to authentication, authorization, transport protection, credential lifecycle management, and auditability.

1. Transport Security

All MERT exchanges SHALL occur over secure transport.

HTTPS using TLS is REQUIRED.
Systems SHALL validate server certificates.
Plain HTTP connections SHALL NOT be permitted.

Additional transport-layer protections (e.g., mutual TLS, IP allowlisting, network segmentation) MAY be implemented according to organizational policy but are not required for basic conformance.

2. Authentication Model

MERT uses a transaction-scoped credential model.

When an authorized export is initiated, the Sender generates:

TransactionID – a unique identifier for the authorized export.
Passphrase – a secret associated with that TransactionID.
Host URL – the FHIR base endpoint for retrieval.

The TransactionID and Passphrase together function as access credentials for retrieval of scoped data.

Systems claiming Sender conformance SHALL:

Generate TransactionIDs that are unique and non-predictable.
Generate Passphrases with sufficient entropy to prevent guessing or brute-force attacks.
Associate each TransactionID with a defined authorization scope.

Systems claiming Receiver conformance SHALL:

Authenticate using the provided TransactionID and Passphrase.
Protect credentials from unauthorized disclosure.
Avoid logging passphrases in plaintext.

The specific mechanism for presenting credentials (e.g., HTTP header, authorization scheme) is implementation-defined but SHALL be transmitted securely over TLS.

3. Authorization and Scope Enforcement

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.
Data permitted for MERT exchange under current release rules.

Private data elements are excluded from MERT export in the current release.

The importing system SHALL NOT be able to:

Retrieve data outside the TransactionID scope.
Escalate privileges beyond the exporting user’s access rights.

Authorization enforcement SHALL occur at the source system.

Because MERT uses real-time retrieval, authorization is evaluated at time of access.

4. Non-Snapshot and State Considerations

MERT does not require snapshot immutability.

Data retrieved under a TransactionID reflects:

The state of the source system at time of access.
The current authorization and privacy configuration.

If exporting user permissions change after TransactionID creation, retrieval behavior SHALL reflect current authorization state.

5. Credential Lifecycle Management

Senders SHALL implement lifecycle controls for TransactionID credentials.

Implementations SHALL define:

Expiration time (TTL) for TransactionIDs.
Revocation mechanisms.

Implementations SHOULD define:

Maximum failed authentication attempt thresholds.
Rate limiting protections.

Senders MAY invalidate a TransactionID:

After successful completion of import.
Upon expiration.
Upon detection of suspicious activity.

Receivers SHOULD complete retrieval within the defined credential validity window.

5.1 TransactionID Expiration

Each generated TransactionID and associated Passphrase SHALL have a maximum validity period of seven (7) days (168 hours) from the time of issuance.

After the expiration period:

The Sender SHALL reject all authentication or retrieval attempts associated with the expired TransactionID.
The rejection SHALL return an appropriate HTTP status code (e.g., 401 Unauthorized or 403 Forbidden).
The expired TransactionID SHALL NOT be reactivated.

Senders MAY implement shorter expiration periods based on local security policy, but SHALL NOT exceed seven (7) days for MERT conformance.

5.2 TransactionID Revocation

The Sender SHALL provide a mechanism to explicitly revoke or cancel a previously issued TransactionID prior to its expiration.

Upon revocation:

The TransactionID SHALL immediately become invalid.
All subsequent authentication or retrieval attempts using the revoked TransactionID SHALL be rejected.
Revocation SHALL take effect in real time and SHALL NOT depend on system restart or scheduled cleanup processes.

Revocation is intended to support scenarios including, but not limited to:

Accidental issuance of credentials
Incorrect recipient details
Security concerns identified after export initiation

6. Audit Logging and Traceability

Both Senders and Receivers SHALL maintain audit logs sufficient to trace MERT exchanges.

6.1 Sender Audit Requirements

Senders SHALL log:

Export initiation event (who, when).
TransactionID creation.
Authentication attempts (success and failure).
Retrieval activity (at minimum, resource type counts or access events).
Revocation or expiration events.

6.2 Receiver Audit Requirements

Receivers SHALL log:

Retrieval initiation.
Authentication success/failure.
Resource processing results.
Chart creation identifier.
Import completion status.

Audit logs SHALL protect sensitive information and SHALL NOT expose passphrases.

6.3 Revocation Audit Requirements

Senders SHALL log all TransactionID revocation events.

Audit entries SHALL include, at minimum:

TransactionID
Date and time of revocation
Identity of the user or system performing the revocation
Optional reason for revocation (if captured by the system)

Revocation events SHALL be retained according to the organization’s audit retention policy.

7. Data Minimization and Privacy Protection

MERT follows a principle of minimum necessary data exchange.

Only data within the authorized TransactionID scope SHALL be exposed.
Private data elements are excluded from exchange in the current release.
Receivers SHALL preserve clinical meaning of received data but SHALL NOT infer or reconstruct excluded private elements.

Attachment handling (e.g., DocumentReference content) SHALL respect the same authorization and privacy constraints.

8. Operational Security Considerations

Implementations SHOULD consider:

Rate limiting to prevent brute-force attacks.
Monitoring for anomalous retrieval patterns.
Secure storage of TransactionID credentials.
Separation of authentication and application logs.
Alerting for repeated authentication failures.

Organizations remain responsible for securing data at rest within their own systems.

9. Scope Limitations

This release of MERT:

Applies to hosted EMR systems only.
Does not define OAuth profiles, SMART-on-FHIR integration, or mutual TLS as mandatory.
Does not define end-to-end encryption beyond transport-layer TLS.
Does not mandate specific key management infrastructure.

Future releases may extend the security model.