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.0 Personal Health (Function)

Active as of 2024-01-31

PH.0#01 | SHALL | The system SHALL capture, maintain, and render the explicit source of all data in the PHR-S (specifically including any metadata that identifies the author, creator, or custodian of the data). Satisfied by: https://www.hl7.org/fhir/meta.html
PH.0#02 | SHALL | The system SHALL provide the ability for the PHR Account Holder to control-access to the PHR Account Holder’s self-created data (including the intended and/or permitted use of the data) according to organizational policy and/or jurisdictional law (e.g., depending on the vendor’s terms-and-conditions-of-use agreement or the system's configuration parameters).
PH.0#03 | SHALL | The system SHALL audit each access to the PHR Account Holder’s data according to organizational policy and/or jurisdictional law.
PH.0#04 | SHOULD | The system SHOULD provide the ability for the PHR Account Holder to control access to the PHR-S by restricting the input of data from external sources.
PH.0#05 | SHOULD | The system SHOULD provide the ability for the PHR Account Holder to analyze and determine whether to accept or reject data arriving from an external source according to organizational policy and/or jurisdictional law.
PH.0#06 | SHOULD | The system SHOULD manage data arriving from an external source by accepting or rejecting the data based on predefined rules and according to organizational policy and/or jurisdictional law. For example, the PHR-S rejects data that was sent from the local clinic that has not been accepted by the PHR Account Holder after three months.
PH.0#07 | SHALL | The system SHALL provide the ability for the PHR Account Holder to control access to the PHR Account Holder's data by removing access to the PHR Account Holder's data according to organizational policy and/or jurisdictional law. Note: access to the PHR Account Holder's data could be controlled at a global and/or granular level.
PH.0#08 | SHALL | The system SHALL provide the ability to control access to the PHR Account Holder's data by restricting its use and/or disclosure according to user role, organizational policy, and/or jurisdictional law.
PH.0#09 | SHALL | The system SHALL transmit an indication that information has been withheld by the PHR Account Holder to any stakeholder with whom the information is shared according to organizational policy and/or jurisdictional law.
PH.0#10 | SHOULD | The system SHOULD NOT transmit an indication that information has been withheld by the PHR Account Holder to any stakeholder with whom the information is shared unless required according to organizational policy and/or jurisdictional law.
PH.0#11 | SHOULD | The system SHOULD provide the ability for the PHR Account Holder to capture, maintain, and render the reason that the PHR Account Holder is withholding certain information from the downstream user. For example, the PHR Account Holder could choose to not share information with members of his care team that inadvertently appears in his record (such as a record that has arrived from an unknown individual).
PH.0#12 | MAY | The system MAY render an indication regarding the sort order of a list according to scope of practice, organizational policy, and/or jurisdictional law. Note: Since the user's assumptions regarding the sort order of a given list might be a patient safety issue, and since there are many lists that could be presented in various sort orders within a PHR system, an indicator can be presented for any list whose sort order could result in a troublesome interpretation of that list.
PH.0#13 | MAY | The system MAY provide the ability for authorized users to configure a default sort order for given lists (e.g., to reduce the confusion when the same list is sorted by severity one day and then by date-of-onset the next day) according to scope of practice, organizational policy, and/or jurisdictional law.
PH.0#14 | MAY | The system MAY provide the ability to render lists in an ad hoc (dynamic, real-time) user-selected sort order (e.g., to reduce the confusion when the same list is sorted by severity one day and then by date-of-onset the next day by a different user) according to scope of practice, organizational policy, and/or jurisdictional law.
PH.0#15 | SHOULD | IF an organization and/or jurisdiction provides individuals with an option to transmit (or not transmit) an indication that information has been withheld, THEN the system SHOULD provide the ability for the PHR Account Holder to exercise that option.
PH.0#16 | SHOULD | IF the system has imported or received information from an external source that the PHR Account Holder identifies as possibly being incorrect, inappropriate, out-of-date, incomplete, skewed, undesired, or not preferred, THEN the system SHOULD provide the ability to mask that information according to user preference and/or consent, organizational policy, and/or jurisdictional law.
PH.0#17 | MAY | The system MAY provide the ability for the PHR Account Holder to present information that has been captured from an external system (but not yet stored) and determine to remove that information according to organizational policy and/or jurisdictional law. (Note: This "information staging" approach enables the PHR Account Holder to filter out unwanted (or incorrect) data, but also enables the PHR Vendor to log the arrival of the data and audit the corresponding action that the PHR Account Holder takes. The vendor is free to deposit the data into the PHR or keep it in a staging area outside the PHR Account Holder's account.)