Skip to end of metadata
Go to start of metadata

This is just a proposal at this point in time and has not been validated with the project team

Summary of Existing Thoughts

  • The FHIR base standard includes a discussion of Security Labels
  • The ARV segment is undergoing some significant changes in v2.9
    • New fields and new vocabulary links
  • A standard Confluence mapping page for ARV exists, but the concepts included in ARV are summarized below
  • ARV-1 Set ID
    • Optional 
    • Standard Set ID field - not particularly relevant here
  • ARV-2 Access Restriction Action Code
    • Required
    • Standard Add/Delete/Update values (table 0206)
  • ARV-3 Access Restriction Value
    • Required
    • The definition of the field and the related vocabulary has been updated in v2.9 (table 0717)
    • This field specifies the information to which access to sensitive information is restricted by applicable jurisdictional, organizational, patient privacy policy or law.
    • Vocab examples include HIPAA, GDPR, 42 CFR Part 2.  (The previous 0717 codes for specific topics such as HIV status, religion, all demographics etc have been deprecated and are replaced by 0719 sensitivity codes.)
    • These codes are available in v2.9 Chapter 2 Codes, https://terminology.hl7.org/builds/current/site/CodeSystem-v2-0717.html and can be located under ActPrivacyPolicy node of the ActCode system at http://hl7.org/fhir/v3/ActCode/cs.html.
    • This is the first of the ARV fields which we currently have mapped to Resource.meta.security
  • ARV-4 Access Restriction Reason
    • Required. May repeat.
    • Information Sensitivity codes replace previous codes in v2.9 (table 0719), and can be found at  http://build.fhir.org/v3/InformationSensitivityPolicy/vs.html
    • Covers the "what type of data" concept
      • eg. Genetic disease info, HIV/AIDS, race, etc
    • Also currently mapped to Resource.meta.security
  • ARV-5 Special Access Restriction Instructions
    • Required. May repeat.
    • The definition of the field has been updated in v2.9
    • v2.9 indicates the text needs to be rendered to users according to policy.
    • Examples include the 42 CFR Part 2 Prohibition against Redisclosure without Consent and the US Controlled Unclassified Information (CUI) codes assigned by US Federal Agencies along with designator's agency name and contact information.
  • ARV-6 Access Restriction Date Range
    • Optional
  • ARV-7 Security Classification Tag
    • Required
    • New in v2.9 (table 0952). See Confidentiality for list of codes.
    • Covers the confidentiality concept
      • Eg, restricted, normal, low, etc
    • Also currently mapped to Resource.meta.security
  • ARV-8 Security Handling Instructions
  • ARV-9 Access Restriction Message Location
    • Optional. May repeat.
    • New in v2.9
    • Points to the location in the message which the restrictions apply to
    • This will impact which resource the security labels are affixed to
  • ARV-10 Access Restriction Instance Identifier
    • Conditional
    • New in v2.9
    • Unique ID for the restriction
    • Standard ID field associated with having an Action Code in the segment

Things to consider

Many different concepts are mapped to Resource.meta.security. While this element is allowed to repeat, this means that different concepts are potentially present in this element without a clear indication of what the concept actually is (other than the coding system for the code). This is potentially very confusing for implementers.

All of the Security Label fields in ARV segment: are CWE and have HL7 Security Label vocabulary for them:

  • ARV-3 Access Restriction Value - This is the governing Privacy Policy or Consent Directive Code. If there are both, then use 2 ARV segments if necessary or use the alternate code for the Consent Directive type pertinent under the governing Privacy Policy. Still working this out.....

As with other CWE/CNE elements, there is the question of how to represent alternative codes. Should there be an extension to the Coding data type to allow for alternate IDs?

Outstanding Questions

  • The Security WG will take the lead on working with FHIR-I to ensure that the necessary security concepts are represented in FHIR. The v2-to-FHIR project will need to respond to that vision for R5 (or beyond) and make sure our guidance is clear (using extensions or such as necessary)

DRAFT of ARV to FHIR Rules

Rules on Constructing V2 security labels in ARV


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


ARV-3 Access Restriction Value [Cardinality = 1..1 Required]


To utilize ARV-3 as one or more security labels applicable to the message or to specific segments/fields, Populate with a single code for the policy represented by the Access Restriction Value from 0717 Table of codes specifying the policies governing the information to which access is controlled.  This policy drives the selection of the codes valuing:

  • ARV-7 Security Classification Tag [Cardinality = 0..1 Conditionally required if ARV-3 is populated] – the level of confidentiality protection required for the entire message or a segment/field identified using ARV-9 Access Restriction Message Location
  • ARV-4 Access Restriction Reason [Cardinality = 0..* Should be populated if ARV-3 is specific to the sensitivity of the entire message or to any ARV-9 segment/field e.g., HIV]
  • ARV-8 Security Handling Instructions [Cardinality = 0..* Should be populated if ARV-3 specifies handling instructions e.g., if ARV-3 is 42 CFR Part 2, then the Purpose of Use and a Refrain Code for no redisclosure without consent must be populated.  Probably need to state that this is “conditionally required” based on ARV-3 coded policy – I will submit a ballot comment to make this change.]

For example, if HIPAA is the policy, then HIV sensitive information will have ARV-7 valued with the confidentiality protection level of “normal” i.e., the norm for confidentiality protection in the US. However, if a state HIV law that preempts HIPAA governs HIV information in the message, the ARV-7 confidentiality code would be “restricted” indicating that additional levels of confidentiality protection are required by law.  In addition, while HIV sensitive information governed by HIPAA may have security handling instructions equivalent to all HIPAA governed information, HIV information governed under a law preempting HIPAA may have security handling instructions limiting the purpose of use and requiring patient consent for further disclosure.


  • No labels