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.3.8 Manage Requests for Release of Information (Function)

Official URL: http://hl7.org/ehrs/uv/phrsfmr2/Requirements/PHRSFMR2-S.3.8 Version: 2.0.1
Standards status: Normative Computable Name: S_3_8_Manage_Requests_for_Release_of_Information

Support requests for release of PHR Account Holder health record information.

Description I: Either the PHR Account Holder or the authorized designee may receive formal requests to release some or all of the PHR information. These requests may be ad hoc, or may also be routine, recurring requests that may be episodic or longer term. These requests may be related to patient care, administrative process, law enforcement or legal action. An auditable record of these requests and associated fulfillment(s) should be maintained by the system. The system should provide an accounting of PHR disclosures of the Release of Information Requests in accordance with user role, organizational policy and/or jurisdictional law.
Criteria N:
S.3.8#01 SHOULD The system SHOULD provide the ability to capture information regarding any individual or entity who requests PHR Account Holder data (including the identity of the requestor, stated reason for the request, the requestor's intended use of the data, date of the request, and the date of the PHR Account Holder's response to that request) according to user role, organizational policy, and/or jurisdictional law.
S.3.8#02 SHOULD The system SHOULD provide the ability to capture the Authorization or Consent associated with the request for release of information according to user role, organizational policy, and/or jurisdictional law.
S.3.8#03 MAY The system MAY provide the ability to manage the fulfillment status of requests.
S.3.8#04 SHOULD The system SHOULD manage recurring, standing requests for PHR information.
S.3.8#05 MAY The system MAY provide the ability for the PHR Account Holder to control access by adding password protection, purpose-of-use protection, and/or intention-of-use protection to PHR Account Holder-defined exported records.
S.3.8#06 SHOULD The system SHOULD provide the ability to render PHR Account Holder identifying information on each page of the reports generated.
S.3.8#07 MAY The system MAY provide the ability to export PHR records to a variety of PHR Account Holders using various platforms without needing special viewing software.
S.3.8#08 SHOULD The system SHOULD conform to function S.3.4 (Manage Data Masking for Sensitive or Selective Information) when masking any PHR data provided.
S.3.8#09 SHOULD The system SHOULD provide the ability to transmit electronic responses with unstructured and structured health record information.
S.3.8#10 MAY The system MAY conform to function TI.5.1 (Application, Structured-Message, and Structured-Document Interchange Standards) to enable data extraction in standard-based formats.