Skip to end of metadata
Go to start of metadata

Also see FHIR DS4P Parking Lot for FHIR specific Security Labeling issues and development areas.


Wish List

Ability for Classifier to sign the portion of related to a specific security label - i.e., delimited by the sec-label-basis extension (the policy being conveyed by this extension related elements).

While we can convey the Provenance related to a Classifier's classification/reclassification of a specific security label using the sec-label-related-artifact extension, which could include the Classifier's signature, that is NOT the same as signing this specific security label.  We would like to discuss the best approach for doing this with FHIR Security and other interested parties.

Below is an example of foundation security labeling specification on the need to make security labeling non-reputable and traceable to the Classifier from ISO 22600-3 p. 55:

A.3.4.2 Signed data encapsulation

Attributes and other sensitivity information may be bound to the digest of the target using the SignedData construct of ASTM E2084. In particular, the use of detached signatures (with the object conveyed separately from the signature structure) would be appropriate. Sensitivity information would be carried as signed attributes, with the originator of the information being the signer.

Cross Paradigm Security Labeling Topics

Assign Authorization Policies to Security Category

Mike would like to consider adding the following Security Policy codes to Security Category fields in the labels. 

That would entail adding AUTHPOL, ACCESSCONSCHEME, and DELEPOL to the Policy Tag Set.

However, that is currently used to convey the privacy policy that drives the Confidentiality level per Sensitivity code.

None of these Security Policies does that.  They seem to be adjunct considerations for enforcement of a Security Label.

Perhaps it would be better to create an additional Security Handling Tag Set, which along with POU, Obligation and Refrain, are instructions to the recipient's ACS.

AUTHPOL (authorization policy)


Authorisation policies are essentially security policies related to access-control and specify what activities a subject is permitted or forbidden to do, to a set of target objects. They are designed to protect target objects so are interpreted by access control agents or the run-time systems at the target system.

A positive authorisation policy defines the actions that a subject is permitted to perform on a target. A negative authorisation policy specifies the actions that a subject is forbidden to perform on a target. Positive authorisation policies may also include filters to transform the parameters associated with their actions. (Based on PONDERS)

ACCESSCONSCHEME (access control scheme)


An access control policy specific to the type of access control scheme, which is used to enforce one or more authorization policies.

Usage Note: Access control schemes are the type of access control policy, which is comprised of access control policy rules concerning the provision of the access control service.

There are two categories of access control policies, rule-based and identity-based, which are identified in CCITT Rec. X.800 aka ISO 7498-2. Rule-based access control policies are intended to apply to all access requests by any initiator on any target in a security domain. Identity-based access control policies are based on rules specific to an individual initiator, a group of initiators, entities acting on behalf of initiators, or originators acting in a specific role. Context can modify rule-based or identity-based access control policies. Context rules may define the entire policy in effect. Real systems will usually employ a combination of these policy types; if a rule-based policy is used, then an identity-based policy is usually in effect also.

An access control scheme may be based on access control lists, capabilities, labels, and context or a combination of these. An access control scheme is a component of an access control mechanism or "service") along with the supporting mechanisms required by that scheme to provide access control decision information (ADI) supplied by the scheme to the access decision facility (ADF also known as a PDP). (Based on ISO/IEC 10181-3:1996)

DELEPOL (delegation policy)


Delegation policies specify which actions subjects are allowed to delegate to others. A delegation policy thus specifies an authorisation to delegate. Subjects must already possess the access rights to be delegated.

Delegation policies are aimed at subjects delegating rights to servers or third parties to perform actions on their behalf and are not meant to be the means by which security administrators would assign rights to subjects. A negative delegation policy identifies what delegations are forbidden.

A Delegation policy specifies the authorization policy from which delegated rights are derived, the grantors, which are the entities which can delegate these access rights, and the grantees, which are the entities to which the access rights can be delegated. There are two types of delegation policy, positive and negative. (Based on PONDERS)

Referencing Policy Instances in a Security Label

V2 References to Policy Instances in ARV

Discussed need for V2 CR to enable URI references to consent directive, privacy, or security policies (e.g., related to authorization/delegation e.g., XACML rule).

C-CDA has Consent with id: SET<II>0..*. Check whether RIM II datatype permits URI.

With FHIR Extensions, we can link to the specific policies, but not clear how to do that with v2 or CDA.

FHIR Security Label Extensions

See use of the following proposed extensions in

US Regulatory Security Label Example Sandbox

Proposed relatedArtifact Security Label extension

This extension can be used to point to the location of the policy instance represented by a Security Label.

For example, it could point to the proposed FHIR Permission Resource, which may include the path to one or more sub-Resource elements to which this policy specifically applies.

<!--This relatedArtifact extension provides the location from which the governing consent directive may be retrieved by an authorized requester. The consent directive custodian must ensure that only the portion of the consent directive related to an authorized requester is returned because the full consent directive may include information about other sensitive information or consented parties about which the requester is not permitted to know. -->
     <extension url="">
      <label value="1"/>
      <type value="documentation"/>
      <citation value="Tricia L. Franklin MDHHS-5515 consent directive"/>

Proposed Must Display Security Label Extension

CUI and other policies, e.g., 42 CFR Part 2, DRAFT, or CONFIDENTIAL, require that certain information be displayed to end users.

Proposed mustDisplay Security Label extension

  <!--This is the "must display" extension indicating that the CUI tags must be displayed to end users as shown in text element.  -->
        <extension url="">
                <reference value=""/>
            <text value="**CUI//SP-HLTH/HLTH/PRVCY**\r\n\r\n ([Veterans Health Administration, Washington, DC 20420]("/>

Classifier Security Label Extension

If the policy being conveyed by the security label requires recording of who classified or changed the classification of the content, then we should include guidance on how to capture the classification role and directive associated with each instance of a label on content as those may change over time.

FHIR Security Label Structure


Sequencing multiple Security Label by order of the Tag Set.

Versioning updates to any Security Label, i.e., when one of the tags is updated/reclassified.


If the policy being conveyed by the security label requires recording of who classified or changed the classification of the content, then we should include guidance on how to capture the classification role and directive associated with each instance of a label on content as those may change over time.

FHIR accumulates the changing labels by methodology, not by policy.  However, CUI labels are perhaps a good candidate for including classification information, especially as there's no syntactical structure in for differentiating the first instance of a label from a later one.  

FHIR Security Label Structure rules to match the Security Name Tag Sets from HCS: We need to provide guidance in these IGs that each security label in a instances SHALL start with 1..1 Confidentiality label, and is the only code in the HCS Security Classification Name Tag Set. 

The next 0..* security labels SHALL be from the HCS Security Category Name Tag Set, which should be listed in the following order if included: Sensitivity codes, Policy Codes (privacy, security and consent directive policy), Compartment codes (e.g., Care Team), Provenance and Integrity codes.

The next 0..* security labels SHALL be from the HCS Security Control Name Tag Set:

  • POU
  • Obligation Policy
  • Refrain Policy
  • Privacy Marks

Granularity of Security Label Use

US Realm Steering Committee asked about whether there will be granular security labels. Answer is yes, but it's up to the policy domain to decide whether to use them and when.  E.g., Federal Agencies can decline to mark CUI at the portion level so a document might include both CUI and "Uncontrolled Unclassified Information" (U).

  • No labels