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
| Active as of 2024-01-31 |
<Requirements xmlns="http://hl7.org/fhir">
<id value="PHRSFMR2-PH.1.1"/>
<meta>
<profile value="http://hl7.org/ehrs/StructureDefinition/FMFunction"/>
</meta>
<text>
<status value="extensions"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<table id="statements" class="grid dict">
<tr>
<td style="padding-left: 4px;">
<span>PH.1.1#01</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHOULD present a user guide or training material to assist the PHR Account Holder in installing, initializing, registering, or operating their PHR.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.1#02</span>
</td>
<td style="padding-left: 4px;">
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>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.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.1#03</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>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).</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.1#04</span>
</td>
<td style="padding-left: 4px;">
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHALL provide the ability to uniquely identify a PHR Account Holder.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.1#05</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>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.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.1#06</span>
</td>
<td style="padding-left: 4px;">
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>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.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.1#07</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>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.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.1#08</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>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.</p>
</div></span>
</td>
</tr>
</table>
</div>
</text>
<url value="http://hl7.org/ehrs/Requirements/PHRSFMR2-PH.1.1"/>
<version value="0.1.0"/>
<name value="PH_1_1_Identify_and_Maintain_a_PHR_Account_Holder_Record"/>
<title
value="PH.1.1 Identify and Maintain a PHR Account Holder Record (Function)"/>
<status value="active"/>
<date value="2024-01-31T14:45:34+00:00"/>
<publisher value="EHR WG"/>
<contact>
<telecom>
<system value="url"/>
<value value="http://www.hl7.org/Special/committees/ehr"/>
</telecom>
</contact>
<description
value="The PHR Account Holder must be confident that the system can reliably and uniquely identify them and provide access to their health record. Nothing precludes the PHR Account Holder from having more than one PHR such as a tethered PHR-S with their Primary Care Provider and a separate self-maintained PHR. The following functions apply to a single PHR system (PHR-S)."/>
<statement>
<key value="PHRSFMR2-PH.1.1-01"/>
<label value="PH.1.1#01"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD present a user guide or training material to assist the PHR Account Holder in installing, initializing, registering, or operating their PHR."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.1-02"/>
<label value="PH.1.1#02"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="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."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.1-03"/>
<label value="PH.1.1#03"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="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)."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.1-04"/>
<label value="PH.1.1#04"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL provide the ability to uniquely identify a PHR Account Holder."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.1-05"/>
<label value="PH.1.1#05"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="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."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.1-06"/>
<label value="PH.1.1#06"/>
<conformance value="SHALL"/>
<conditionality value="true"/>
<requirement
value="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."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.1-07"/>
<label value="PH.1.1#07"/>
<conformance value="SHOULD"/>
<conditionality value="true"/>
<requirement
value="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."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.1-08"/>
<label value="PH.1.1#08"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="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."/>
</statement>
</Requirements>