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-S.3.4"/>
<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>S.3.4#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 provide the ability for the PHR Account Holder to tag records, data fields, or data classes that will not display intelligibly unless viewed by condition-based Authorized PHR Users under conditions specified by the PHR Account Holder. Examples of a condition-based Authorized PHR User include: An individual that the PHR Account Holder specifies, an Emergency Care provider, or a PHR Account Holder's smartphone that is accessed within an Emergency Department.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.3.4#02</span>
</td>
<td style="padding-left: 4px;">
<span>MAY</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system MAY provide the ability for the PHR Account Holder to manage data visibility at differ degrees of data discoverability by masking, hiding, and/or de-identifying data according to user preference, organizational policy, and/or jurisdictional law. For example: medication information may be masked with asterisks; mental health records may be undiscoverable by those who do not have a need-to-know. Examples of data-masking visibility conditions include: type of healthcare provider (e.g., administrator versus clinician), location of care being received (e.g., a local clinic versus an Emergency Department), time (e.g., weekday versus weekend for a provider), past healthcare service received (e.g., earlier substance abuse therapy; therapy regarding significant weight loss).</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.3.4#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 authenticate systems that are requesting personal health information to ensure the requesting system has the ability to protect masked data according to the PHR Account Holder's preferences and consent, organizational policy, and/or jurisdictional law.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.3.4#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 transmit data to other systems that support the ability to protect masked data.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.3.4#05</span>
</td>
<td style="padding-left: 4px;">
<span>MAY</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system MAY provide the ability to render a notification to the PHR Account Holder that masking selected information may result in unintended consequences or medical harm (e.g., by providing information that is incomplete for a physician who is engaged in the medication-ordering process).</p>
</div></span>
</td>
</tr>
</table>
</div>
</text>
<url value="http://hl7.org/ehrs/Requirements/PHRSFMR2-S.3.4"/>
<version value="0.1.0"/>
<name
value="S_3_4_Manage_Data_Masking_for_Sensitive_or_Selective_Information"/>
<title
value="S.3.4 Manage Data Masking for Sensitive or Selective 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 PHR Account Holder or designee needs the ability to protect sensitive information by masking specific content without deleting the information.
Example(s): The PHR Account Holder wants to make the fact of Sexually Transmitted Disease or pregnancy known if and only if she arrives at an emergency room unconscious."/>
<statement>
<key value="PHRSFMR2-S.3.4-01"/>
<label value="S.3.4#01"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability for the PHR Account Holder to tag records, data fields, or data classes that will not display intelligibly unless viewed by condition-based Authorized PHR Users under conditions specified by the PHR Account Holder. Examples of a condition-based Authorized PHR User include: An individual that the PHR Account Holder specifies, an Emergency Care provider, or a PHR Account Holder's smartphone that is accessed within an Emergency Department."/>
</statement>
<statement>
<key value="PHRSFMR2-S.3.4-02"/>
<label value="S.3.4#02"/>
<conformance value="MAY"/>
<conditionality value="false"/>
<requirement
value="The system MAY provide the ability for the PHR Account Holder to manage data visibility at differ degrees of data discoverability by masking, hiding, and/or de-identifying data according to user preference, organizational policy, and/or jurisdictional law. For example: medication information may be masked with asterisks; mental health records may be undiscoverable by those who do not have a need-to-know. Examples of data-masking visibility conditions include: type of healthcare provider (e.g., administrator versus clinician), location of care being received (e.g., a local clinic versus an Emergency Department), time (e.g., weekday versus weekend for a provider), past healthcare service received (e.g., earlier substance abuse therapy; therapy regarding significant weight loss)."/>
</statement>
<statement>
<key value="PHRSFMR2-S.3.4-03"/>
<label value="S.3.4#03"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to authenticate systems that are requesting personal health information to ensure the requesting system has the ability to protect masked data according to the PHR Account Holder's preferences and consent, organizational policy, and/or jurisdictional law."/>
</statement>
<statement>
<key value="PHRSFMR2-S.3.4-04"/>
<label value="S.3.4#04"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to transmit data to other systems that support the ability to protect masked data."/>
</statement>
<statement>
<key value="PHRSFMR2-S.3.4-05"/>
<label value="S.3.4#05"/>
<conformance value="MAY"/>
<conditionality value="false"/>
<requirement
value="The system MAY provide the ability to render a notification to the PHR Account Holder that masking selected information may result in unintended consequences or medical harm (e.g., by providing information that is incomplete for a physician who is engaged in the medication-ordering process)."/>
</statement>
</Requirements>