HL7 Electronic Health Record System Functional Model, Release 2.1.1
2.1.1 - International flag

HL7 Electronic Health Record System Functional Model, Release 2.1.1, published by HL7 International / Electronic Health Records. This guide is not an authorized publication; it is the continuous build for version 2.1.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/mvdzel/ehrsfm-fhir-r5/ and changes regularly. See the Directory of published versions

Requirements: POP.8 De-Identified Data Request Management (Function)

Official URL: http://hl7.org/ehrs/uv/ehrsfmr2/Requirements/EHRSFMR2-POP.8 Version: 2.1.1
Standards status: Normative Active as of 2025-10-31 Computable Name: POP_8_De_Identified_Data_Request_Management

Provide patient data in a manner that meets applicable requirements for de-identification.

Statement N:

Provide patient data in a manner that meets applicable requirements for de-identification.

Description I:

When an internal or external party requests patient data and that party requests de-identified data (or is not entitled to identified patient information, either by law or custom), the user can export the data in a fashion that meets the requirements for de-identification in that locale or realm.

An auditable record of these requests and associated exports may be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review.

A random re-identification key may be added to the data, to support re-identification for the purpose of alerting providers of potential patient safety issues. For example, if it is discovered that a patient is at risk for a major cardiac event, the provider could be notified of this risk, allowing the provider to identify the patient from the random key.

Criteria N:
POP.8#01
 dependent
SHALL

The system SHALL conform to function TI.1.8 (Patient Privacy and Confidentiality) when managing de-identified views of data according to scope of practice, organizational policy, and/or jurisdictional law.
POP.8#02
SHOULD

The system SHOULD provide the ability to de-identify extracted information.
POP.8#03
 dependent
SHOULD

The system SHOULD provide the ability for authorized users to tag data for de-identification according to scope of practice, organizational policy, and/or jurisdictional law.
POP.8#04
 dependent
SHOULD

The system SHOULD provide the ability for authorized users to transmit de-identified data to authorized recipients according to scope of practice, organizational policy, and/or jurisdictional law.
POP.8#05
 dependent
SHOULD

The system SHOULD provide the ability to transmit a re-identification key to recipients of de-identified data according to scope of practice, organizational policy, and/or jurisdictional law.
POP.8#06
 dependent
SHOULD

The system SHOULD provide the ability to edit discrete patient identifiers from all reports containing data on multiple patients according to scope of practice, organizational policy, and/or jurisdictional law (e.g., replace "John Smith" with "***").