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.4.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>S.4.1.2#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 de-identify his or her information as needed to meet the requirements of a study or other request.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.4.1.2#02</span>
</td>
<td style="padding-left: 4px;">
<span>SHOULD</span>
</td>
<td style="padding-left: 4px;" class="requirement">
<span><div><p>The system SHOULD capture the source and date of a request for de-identified data.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.4.1.2#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 the date of transmission, data transmitted, and the target of the de-identified data.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.4.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 capture confirmation of the target’s receipt of the data.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.4.1.2#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 to render the history of data transmissions.</p>
</div></span>
</td>
</tr>
<tr>
<td style="padding-left: 4px;">
<span>S.4.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 provide the ability to de-identify data according to organizational policy and/or jurisdictional law.</p>
</div></span>
</td>
</tr>
</table>
</div>
</text>
<url value="http://hl7.org/ehrs/Requirements/PHRSFMR2-S.4.1.2"/>
<version value="0.1.0"/>
<name value="S_4_1_2_Manage_De_Identified_Data_Request_Process"/>
<title
value="S.4.1.2 Manage De-Identified Data Request Process (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="When the PHR Account Holder desires to share his/her information in a de-identified state, the PHR Account Holder can export the data in a fashion that meets requirements for de-identification in that locale or realm.
Example(s): If a person wants to participate in a study that will utilize de-identified data, then the system should provide the ability to de-identify this data according to the requirements of the study.
In Germany, when a PHR Account Holder’s subscription is cancelled, the PHR data may be maintained. But if the data is maintained, it must be maintained in a de-identified state or be pseudonymized (similar to the limited data set in the U.S. Privacy Rule)."/>
<statement>
<key value="PHRSFMR2-S.4.1.2-01"/>
<label value="S.4.1.2#01"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability for the PHR Account Holder to de-identify his or her information as needed to meet the requirements of a study or other request."/>
</statement>
<statement>
<key value="PHRSFMR2-S.4.1.2-02"/>
<label value="S.4.1.2#02"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD capture the source and date of a request for de-identified data."/>
</statement>
<statement>
<key value="PHRSFMR2-S.4.1.2-03"/>
<label value="S.4.1.2#03"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to capture the date of transmission, data transmitted, and the target of the de-identified data."/>
</statement>
<statement>
<key value="PHRSFMR2-S.4.1.2-04"/>
<label value="S.4.1.2#04"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to capture confirmation of the target’s receipt of the data."/>
</statement>
<statement>
<key value="PHRSFMR2-S.4.1.2-05"/>
<label value="S.4.1.2#05"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to render the history of data transmissions."/>
</statement>
<statement>
<key value="PHRSFMR2-S.4.1.2-06"/>
<label value="S.4.1.2#06"/>
<conformance value="SHOULD"/>
<conditionality value="false"/>
<requirement
value="The system SHOULD provide the ability to de-identify data according to organizational policy and/or jurisdictional law."/>
</statement>
</Requirements>