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.

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).

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.

The system SHOULD provide the ability to transmit data to other systems that support the ability to protect masked data.

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).