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.2"/>
<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.2#01</span>
</td>
<td style="padding-left: 4px;">
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHALL capture the PHR Account Holder's demographic information.</p>
</div></span>
Satisfied by:<ol>
<li><a href="https://www.hl7.org/fhir/patient.html">https://www.hl7.org/fhir/patient.html</a></li>
</ol>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#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 store and retrieve the PHR Account Holder's demographic information as discrete data.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#03</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 import and/or receive the PHR Account Holder's demographic data from existing digital sources (including, for example, from a provider's EHR-S or a health plan system).</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#04</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 enter or update demographic data that has not been synchronized with other source systems.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#05</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 render a PHR Account Holder's demographic data according to user preference and/or consent, organizational policy, and/or jurisdictional law.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#06</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHOULD store historical values of demographic data (e.g., various residence addresses, or marital status changes).</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#07</span>
</td>
<td style="padding-left: 4px;">
<span>SHALL</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHALL present identifying information with any presentation of the PHR Account Holder's data (unless the information has been tagged as needing to be de-identified) according to organizational policy and/or jurisdictional law. For example, the PHR Account Holder's name ought to appear on each screen to help a mother distinguish the screen displays of the PHRs for each of her minor children. Another example is that the PHR Account Holder's name should not appear -- and the information should be de-identified -- when the information is being shared with a research organization.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#08</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>IF one PHR Account Holder has certain information in common with a second PHR Account Holder, THEN the system SHOULD provide the ability to auto-populate the second PHR Account Holder's information with certain common information from the first PHR Account Holder's account according to user role, organizational policy, and/or jurisdictional law. For example, a mother may auto-populate her infant's resident address information using her own resident address information.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#09</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 for the PHR Account Holder to annotate demographic data with text comments.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>PH.1.2#10</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 for the PHR Account Holder to control access to demographic information.</p>
</div></span>
</td>
</tr>
</table>
</div>
</text>
<url value="http://hl7.org/ehrs/Requirements/PHRSFMR2-PH.1.2"/>
<version value="0.1.0"/>
<name value="PH_1_2_Manage_PHR_Account_Holder_Demographic_Information"/>
<title
value="PH.1.2 Manage PHR Account Holder Demographic Information (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 system should maintain the current demographic data set that unambiguously defines the PHR Account Holder including personal attributes and contact information (including emergency contact, next-of-kin information, and insurance information sufficient to meet the information needs required to provide health care services, and if applicable, facilitate the need to locate family members in the event of an emergency or to expedite next-of-kin notification).
Example(s): Maintain current contact information, emergency contact information/next-of-kin information, and registration information including physical addresses, telephone numbers, and email addresses."/>
<statement>
<key value="PHRSFMR2-PH.1.2-01"/>
<label value="PH.1.2#01"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL capture the PHR Account Holder's demographic information."/>
<satisfiedBy value="https://www.hl7.org/fhir/patient.html"/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-02"/>
<label value="PH.1.2#02"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL store and retrieve the PHR Account Holder's demographic information as discrete data."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-03"/>
<label value="PH.1.2#03"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL provide the ability to import and/or receive the PHR Account Holder's demographic data from existing digital sources (including, for example, from a provider's EHR-S or a health plan system)."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-04"/>
<label value="PH.1.2#04"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to enter or update demographic data that has not been synchronized with other source systems."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-05"/>
<label value="PH.1.2#05"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL provide the ability to render a PHR Account Holder's demographic data according to user preference and/or consent, organizational policy, and/or jurisdictional law."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-06"/>
<label value="PH.1.2#06"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD store historical values of demographic data (e.g., various residence addresses, or marital status changes)."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-07"/>
<label value="PH.1.2#07"/>
<conformance value="SHALL"/>
<conditionality value="false"/>
<requirement
value="The system SHALL present identifying information with any presentation of the PHR Account Holder's data (unless the information has been tagged as needing to be de-identified) according to organizational policy and/or jurisdictional law. For example, the PHR Account Holder's name ought to appear on each screen to help a mother distinguish the screen displays of the PHRs for each of her minor children. Another example is that the PHR Account Holder's name should not appear -- and the information should be de-identified -- when the information is being shared with a research organization."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-08"/>
<label value="PH.1.2#08"/>
<conformance value="SHOULD"/>
<conditionality value="true"/>
<requirement
value="IF one PHR Account Holder has certain information in common with a second PHR Account Holder, THEN the system SHOULD provide the ability to auto-populate the second PHR Account Holder's information with certain common information from the first PHR Account Holder's account according to user role, organizational policy, and/or jurisdictional law. For example, a mother may auto-populate her infant's resident address information using her own resident address information."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-09"/>
<label value="PH.1.2#09"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability for the PHR Account Holder to annotate demographic data with text comments."/>
</statement>
<statement>
<key value="PHRSFMR2-PH.1.2-10"/>
<label value="PH.1.2#10"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability for the PHR Account Holder to control access to demographic information."/>
</statement>
</Requirements>