HL7 Personal Health Record System Functional Model, Release 2
2.0.1 - Normative

HL7 Personal Health Record System Functional Model, Release 2, published by EHR WG. This guide is not an authorized publication; it is the continuous build for version 2.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/phrsfm-ig/ and changes regularly. See the Directory of published versions

Requirements: S.4.1.2 Manage De-Identified Data Request Process (Function)

Official URL: http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-S.4.1.2 Version: 2.0.1
Standards status: Normative Active as of 2025-12-07 Computable Name: S_4_1_2_Manage_De_Identified_Data_Request_Process

Provide PHR Account Holder data in a manner that meets local requirements for de-identification.

Description I:

When the PHR Account Holder desires to share his/her information in a de-identified state, the PHR Account Holder can export the data in a fashion that meets requirements for de-identification in that locale or realm.

Example(s): If a person wants to participate in a study that will utilize de-identified data, then the system should provide the ability to de-identify this data according to the requirements of the study.

In Germany, when a PHR Account Holder’s subscription is cancelled, the PHR data may be maintained. But if the data is maintained, it must be maintained in a de-identified state or be pseudonymized (similar to the limited data set in the U.S. Privacy Rule).

Criteria N:
S.4.1.2#01 SHOULD

The system SHOULD provide the ability for the PHR Account Holder to de-identify his or her information as needed to meet the requirements of a study or other request.
S.4.1.2#02 SHOULD

The system SHOULD capture the source and date of a request for de-identified data.
S.4.1.2#03 SHOULD

The system SHOULD provide the ability to capture the date of transmission, data transmitted, and the target of the de-identified data.
S.4.1.2#04 SHOULD

The system SHOULD provide the ability to capture confirmation of the target’s receipt of the data.
S.4.1.2#05 SHOULD

The system SHOULD provide the ability to render the history of data transmissions.
S.4.1.2#06 SHOULD

The system SHOULD provide the ability to de-identify data according to organizational policy and/or jurisdictional law.