The ARV segment is used to communicate the requested/required type of access restrictions from system to system, at both the person/patient and the encounter/visit level.
The Access Restrictions segment (ARV) sent after the MSH acts as a manifest and declares the privacy and security classification (i.e the confidentiality level), the sensitivity (i.e. access restriction reason) and provides handling instructions (e.g. what the data can be used for, what must be done to protect it and what may not be done with the data). The segment is optional and can repeat.
A person/patient may have the right to object to any or all of his/her information to be disclosed. In addition, the patient may request that protected information not be disclosed to family members or friends who may be involved in their care or for notification purposes.
A realm or organization may have certain privacy policies.
A patient may have the right to opt out of being included on facility directories.
In an international context, a physician may be culturally obligated to protect the patient's privacy.
Any "opt-in" or "opt-out" restrictions are communicated in ARV-3 - Access Restriction Value. This segment replaces PD1-12 and PV2-22, which have been deprecated in V2.6. The ARV segment is optional and as of 2.9 is sent immediately following the MSH segment to allow declaration of access restrictions for specific data elements (ARV-9 – Access Restriction Message Location), that are different from the overall security level declared in the Message Header Segment. The ARV segment can repeat, so that different security attributes across message elements can be declared.
The individual system security may want to utilize the Access Restriction Value along with the Access Restriction Reason and with the Confidentiality Code from Code defined in the Security Classification Tag (ARV-7)in order to implement the appropriate type of protection for the identified data. Each system has the flexibility to incorporate/map the access values into their security system appropriately; the actual implementation for access to protected data is determined by the individual system. The Access Restriction Values supported by an enterprise/system would be defined and determined by that organization.
It is expected that these access restriction values would be utilized in combination with other system security information (e.g., patient locations, user department, caregiver-patient relationships, other access restriction parameters) to determine user access.
System implementers should carefully control access to the restriction codes and values, as they themselves hold sensitive information.
|2||02144||Access Restriction Action Code||SHALL||[1..1]||CNE|
|3||02145||Access Restriction Value||SHALL||[1..1]||CWE|
|4||02146||Access Restriction Reason||[0..*]||CWE|
|5||02147||Special Access Restriction Instructions||=||[0..*]||250||ST|
|6||02148||Access Restriction Date Range||[0..1]||DR|
|7||03512||Security Classification Tag||SHALL||[1..1]||CWE|
|8||03513||Security Handling Instructions||[0..*]||CWE|
|9||03514||Access Restriction Message Location||[0..*]||ERL|
|10||02470||Access Restriction Instance Identifier||
Definition: This field contains the number that identifies this segment. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.
Definition: This field contains a code defining the action to be taken for this segment. It allows access restriction information to be sent to delete or update previously sent access restrictions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.
The intent of this table is to declare the applicable patient consent directive, organizational policy or jurisdicitonal law.
As examples in the US this could be HIPAA Authorizations for Disclosure, HIPAA Notice of Privacy Practice or 42 CFR Part 2.
Definition: This field is used to convey the reason for the restricted access. Repeat of the Access Restriction Reason is allowed to accommodate communication of multiple reasons for an access restriction. Refer to User-defined Table 0719 – Access Restriction Reason Code in Chapter 2C, Code Tables, for suggested values.
Definition: Used to convey specific instructions about the protection of the patient's information which must be rendered to end users in accordance with patient consent directive, organizational policy, or jurisdictional law. For example, in US law 42 CFR Part 2, disclosed information made with patient consent must include a renderable “Prohibition on re-disclosure” warning (§ 2.32) In addition, organizational policy may require that some or all of the ARV field privacy tag values be rendered to end users, e.g., marking a consult note with “Restricted Confidentiality” or with sensitivity tags such as “VIP” or “EMP” for employee of the organization.
This field may also be used to specify instructions about the release of information to family and friends (e.g., "Do not release information to patient's brother, Adam Everyman"). These instructions may be in conjunction with other fields (as elected by the system).
Definition: This element defines the date from which an access restriction commences until the date it is specifically rescinded.
Definition: This field defines the security classification (as defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995) of an IT resource, in this case the message, which may be used to make access control decisions. Use of this field supports the business requirement for increasing or decreasing the level of confidentiality (classification or declassification) for a given message.
Refer to Externally-defined HL7 Table 0952 – HL7 Confidentiality Classification. Use of this table is recommended. The codes in this table are comprehensive non-overlapping hierarchical codes: Very Restricted > Restricted > Normal > Moderate > Low > Unrestricted. Restrictions to a comprehensive, non-overlapping set of codes is required for purposes of access control system algorithms such as Bell–LaPadula Mode, which is used to adjudicate access requests against privacy policies. See Chapter 2C, Code Tables, for suggested values.
Definition: This field is repeatable and conveys instructions to users and receivers for secure distribution, transmission, and storage; dictates obligations or mandated actions; specifies any action prohibited by refrain policy such as dissemination controls; and stipulates the permissible purpose of use of an IT resource. It is used where MSH-27 or MSH-28, which may be the compliation of all Security Handling Instructions across all labels, are used, but differ from the appliable ones for the data identified in this ARV segment.
Refer to Externally-defined Table 0953 – Security Label Handling Instructions in Chapter 2C, Code Tables, for suggested values. – Use of this table is recommended.
Definition: This field is optional and repeating and identifies the location in a message related to the identified access restricted data. If multiple repetitions are present, the listed access restrictions apply to all listed places.
Note: Realm, business and policy rules will determine to what level the restrictions need to be supported. For example in a lab result exchange setting identifying elements more granular than the result at the segment level (i.e.OBX) is not expected, while in other settings more granular settings may apply.
Definition: This field carries the unique identifier for this access restriction and is conditionally required when ARV-2 is NOT valued ‘S’ to support the use of action code for tracking changes when using dynamic mode. This instance identifier is persistent between messages. Implementation guides may restrict what mode to use, which will affect the effective optionality of this field.