Personal Health Record System Functional Model, Release 2
0.1.0 - CI Build

Personal Health Record System Functional Model, Release 2 - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

## Example Requirements: PH.1.1 Identify and Maintain a PHR Account Holder Record (Function)

Active as of 2024-01-31

PH.1.1#01 | SHOULD | The system SHOULD present a user guide or training material to assist the PHR Account Holder in installing, initializing, registering, or operating their PHR.
PH.1.1#02 | SHALL | The system SHALL provide the ability to store more than one unique identifier for each PHR Account Holder's record. For example, the PHR Account Holder may have received health information from multiple caregivers, each caregiver having a unique Patient Identifier for that PHR Account Holder (also known as an Account Number). When the PHR Account Holder shares information with an individual caregiver, the PHR Account Holder may desire to utilize the Patient Identifier that is known to that specific caregiver.
PH.1.1#03 | SHOULD | The system SHOULD provide the ability to capture, store, and integrate and/or link the PHR Account Holder's unique identifiers from multiple external sources (e.g., medical record number, insurance account number, or voluntary unique identifiers).
PH.1.1#04 | SHALL | The system SHALL provide the ability to uniquely identify a PHR Account Holder.
PH.1.1#05 | SHOULD | The system SHOULD provide the ability (through a controlled method) to capture, integrate, and/or link information that is determined to be the PHR Account Holder's information that is stored in external systems. Note: A controlled method enables the PHR Account Holder to choose a course of action from a limited set of actions. For example, the PHR-S could provide a controlled method by which the PHR Account Holder could choose to link to an external DICOM image, but import the Report regarding that DICOM image instead.
PH.1.1#06 | SHALL | IF health information has been incorrectly associated with a PHR Account Holder, THEN the system SHALL provide the ability to annotate the information as being erroneous (or as believed to be erroneous) in the PHR Account Holder's account in which it was incorrectly associated, and represent that information as being erroneous.
PH.1.1#07 | SHOULD | IF health information has been incorrectly associated with a PHR Account Holder, THEN the system SHOULD provide the ability to transmit information regarding the error to the source of the information according to organizational policy and/or jurisdictional law.
PH.1.1#08 | SHOULD | The system SHOULD provide the ability to archive, delete, and/or purge part or all of a PHR Account Holder's information (e.g., information that is obsolete, inactive, or nullified) according to user preference and/or consent, organizational policy (e.g., according to a statement of terms and conditions), and/or jurisdictional law.