hl7 version 3 standard: privacy, access and security ... · page 2 hl7 standard: privacy, access...

ANSI/HL7 V3 PASS SECURITY LABELSRV, R1-2014

6/20/2014

HL7 Version 3 Standard: Privacy, Access and Security Services;

Security Labeling Service, Release 1

June 2014

Sponsored by: Security Work Group

Services Oriented Architecture Work Group

PASS Alpha Project Lead Don Jorgenson (Inpriva, Inc.) mailto:[email protected]

Authors Patrick Pyette (Perimind) mailto:[email protected]

John Mike Davis (Department of Veterans Affairs) mailto:[email protected]

Kathleen Connor (Department of Veterans Affairs) mailto:[email protected]

Bernd Blobel mailto:[email protected]

Copyright © 2014 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

mailto:[email protected]





HL7 Standard: Privacy, Access and Security Services (PASS) – Security Labeling Service, Release 1.0 © 2014 Health Level Seven, Inc. All rights reserved June 2014

IMPORTANT NOTES: HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm. If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material. A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7. INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7. B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

http://www.hl7.org/implement/standards/index.cfm

http://www.hl7.org/legal/ippolicy.cfm


Acknowledgements This ballot was developed with support from the Substance Abuse and Mental Health Services Administration (SAMHSA) and the Department of Veteran’s Affairs (VA). In addition to the listed authors, the following individuals are acknowledged for their contributions during the development of this document, or previous versions that formed the basis for this document:

John Moehrke (GE Healthcare) mailto:[email protected] Richard Thoreson (SAMHSA) mailto:[email protected]




Table of Contents 1 PREFACE .......................................................................................................................................................................... VI

1.1 NOTES TO READERS - ACRONYM TABLE AND GLOSSARY ............................................................................................... VI 1.2 CONFORMANCE TERMS ................................................................................................................................................. VII 1.3 QUOTATIONS FROM AUTHORITATIVE SOURCES ............................................................................................................ VII 1.4 BASE DOCUMENT AND SUPPORTING HL7 STANDARDS .................................................................................................... 1

2 INTRODUCTION ................................................................................................................................................................ 2 2.1 SCOPE .............................................................................................................................................................................. 3 2.2 STATEMENT OF NORMATIVE COMPONENT ....................................................................................................................... 3

3 BUSINESS VIEWPOINT (INFORMATIVE) ................................................................................................................... 4 4 SLS RELEVANT PASS-ACS USE CASES ....................................................................................................................... 5

4.1 USE CASE AC-1: ENFORCE ACCESS CONTROL DECISION ................................................................................................ 6 4.2 USE CASE AC-6: REQUEST ATTRIBUTES.......................................................................................................................... 6

5 SECURITY LABELING AND PRIVACY AND SECURITY PROTECTIVE SERVICES USE CASES (NORMATIVE) ........................................................................................................................................................................... 8

5.1 SECURITY LABELING SERVICE (SLS) INTERFACE DETAILS .............................................................................................. 9 5.1.1 Use Case AC-1a: Assign Resource Security Labels and Return Security Label ADI............................................. 10

5.2 PRIVACY AND SECURITY PROTECTIVE SERVICE (PPS) INTERFACE DETAILS .................................................................. 11 5.2.1 Use Case AC-1b: Enforce Privacy and Security Protection Obligation ................................................................ 12

6 DATA SEGMENTATION BUSINESS REQUIREMENTS (NORMATIVE) .............................................................. 15 6.1 HEALTHCARE DATA SEGMENTATION AND MANAGEMENT BUSINESS REQUIREMENTS .................................................. 17

6.1.1 Healthcare Data Segmentation Business Requirements ........................................................................................ 18 6.1.2 Healthcare Security Labeling Business Requirements ........................................................................................... 22 6.1.3 Healthcare Privacy and Security Protective Service Requirements ....................................................................... 26

7 PASS-SLS INFORMATIONAL VIEWPOINT (NORMATIVE) .................................................................................. 27 7.1 BUSINESS RULES AND CONSTRAINTS ............................................................................................................................. 27 7.2 INFORMATION MODEL ................................................................................................................................................... 27 7.3 FHIR SECURITY LABEL VALUE SET LINKS .................................................................................................................... 29

8 PASS-SLS SEMANTIC SIGNIFIERS (NORMATIVE) ................................................................................................. 30 8.1 SECURITY LABEL ADI SELECTOR (INFORMATIVE) ........................................................................................................ 30 8.2 SECURITY LABEL ........................................................................................................................................................... 30

8.2.1 Dynamic Model ...................................................................................................................................................... 34

9 COMPUTATIONAL VIEWPOINT ................................................................................................................................. 34 9.1 OVERVIEW ..................................................................................................................................................................... 34 9.2 CAPABILITIES ................................................................................................................................................................. 34

9.2.1 Enforce Access Control Decision ........................................................................................................................... 34 9.2.2 Get Access Decision Information ........................................................................................................................... 35

9.3 COLLABORATION ANALYSIS .......................................................................................................................................... 35 9.3.1 Access Control ....................................................................................................................................................... 35


9.3.2 Security Labeling Service Capability Collaboration (Normative) ......................................................................... 37 9.3.3 Policy Management ................................................................................................................................................ 40

10 CONFORMANCE (NORMATIVE) ............................................................................................................................. 40 10.1 RESOLVE SECURITY LABEL ADI REQUEST................................................................................................................. 41 10.2 APPLY PRIVACY AND SECURITY PRIVACY PROTECTIVE MECHANISMS ...................................................................... 41

11 ENGINEERING VIEWPOINT ..................................................................................................................................... 42 11.1 ODP FUNCTIONS ........................................................................................................................................................ 42 11.2 PHYSICAL DISTRIBUTION FUNCTIONS ........................................................................................................................ 42 11.3 COMMUNICATION FUNCTIONS .................................................................................................................................... 42 11.4 PROCESSING FUNCTIONS ............................................................................................................................................ 42 11.5 STORAGE FUNCTIONS ................................................................................................................................................. 43 11.6 ENGINEERING ROLES .................................................................................................................................................. 43

12 APPENDIX A: GLOSSARY OF TERMS .................................................................................................................... 44

13 APPENDIX B - RELATED STANDARDS .................................................................................................................. 53

14 REFERENCES ................................................................................................................................................................ 53

List of Figures Figure 1 Security Domain View ___________________________________________________________________________ 5 Figure 2 Boundary View of the Access Control Service with SLS and PPS ___________________________________________ 8 Figure 3 Security Labeling Service _________________________________________________________________________ 9 Figure 4 Privacy and Protective Services ___________________________________________________________________ 12 Figure 5 Data Segmenting EHR Conceptual Components ______________________________________________________ 16 Figure 7 HCS Security Label Vocabulary [Available for download] _______________________________________________ 28 Figure 8 Attribute Requisitioning and Provisioning ___________________________________________________________ 30 Figure 9 Security Label [Available for Download] ____________________________________________________________ 31 Figure 10 Access Control Roles and Capabilities ____________________________________________________________ 37 Figure 11 Capability Collaborations for Security Labeling and Privacy and Security Protective Services _________________ 38 List of Tables Table 1 Acronyms ......................................................................................................................................................................... vi Table 2 Security Labeling Service Requirements ......................................................................................................................... 10 Table 3 PASS-ACS Obligation Requirements ............................................................................................................................... 13 Table 4 Privacy and Security Protective Service Requirements ................................................................................................... 14 Table 6 Security Label Management and Service Requirements ................................................................................................ 22 Table 7 Privacy and Security Protective Service Requirements ................................................................................................... 26 Table 8 FHIR Security Label Value Set Links ................................................................................................................................ 29 Table 9 Details of the Security Label business concepts and attributes ...................................................................................... 32 Table 10 Enforce Access Control Decision ................................................................................................................................... 34 Table 11 Get Access Control Information ................................................................................................................................... 35 Table 12 Resolve Security Label ADI Request .............................................................................................................................. 41 Table 13 Apply Privacy and Security Privacy Protective Mechanisms......................................................................................... 41 Table 14 Glossary of Terms ......................................................................................................................................................... 44


1 Preface The PASS-SLS extends and refines the PASS-ACS by the addition of two new independent but related services:

• Privacy and Security Protective Service (PPS), which drills down on the obligations sent with access control decisions, which the PASS-ACS declared out of scope for future work

• Security Labeling Service (SLS), which leverages the HCS to further define Resource ADI provided as input to access control decisions and to the PPS in support of fulfilling obligations required for access control enforcement

1.1 Notes to Readers - Acronym Table and Glossary Acronyms are provided here for use throughout the document rather than introducing them in the narrative. Detailed definition, background, and usage notes about these terms and others used in this document are located in Appendix A: Glossary of Terms. First use of terms are italicized and linked to their definitions

Table 1 Acronyms

Acronym Terms with Hyperlinks to their Definitions ACI Access Control Information

ACIC Access Control Intercept Component ACIS Access Control Intercept Service ACS Access Control Service ADI Access Control Decision Information CFM Clinical Fact Management CFS Clinical Fact Service

DAM HL7 Version 3: Composite Security and Privacy Domain Analysis Model (DAM) DSTU HCS HL7 Version 3: Healthcare Privacy and Security Classification System (HCS) Normative

PAP Policy Administration Point

PASS-ACS HL7 Version 3: Privacy, Access and Security Services - Access Control (PASS-ACS) DSTU

PASS-SLS HL7 Version 3: Privacy, Access and Security Services - Access Control (PASS-SLS) Normative

PDP Policy Decision Point

PEP Policy Enforcement Point

PHI Protected Health Information

PIP Policy Information Point

PPS Privacy and Security Protective Service

SLM Security Labeling and Privacy Protection Management

SLS Security Labeling Service

SLSG Security Labeling Service Guide

http://www.hl7.org/dstucomments/ex_showdetail.cfm?dstuid=74

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=345

http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=200



SPO HL7 Version 3: Security and Privacy Ontology (SPO)

WI Working Interoperability

1.2 Conformance Terms

The key words "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY"1, and "NEED NOT" in this document are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide (http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm).

1.3 Quotations from Authoritative Sources

Where this specification quotes from authoritative sources that form the basis for the use case analysis, readers should not expect full alignment of terms used but should expect that the terms are consistent with or conceptually equivalent.


HL7 Security Labeling Service Conceptual Model – Release 1.0 1 Normative Ballot Reconciled January 2014 Ballot © 2014 Health Level Seven, Inc. All rights reserved.

1.4 Base Document and Supporting HL7 Standards

The Privacy, Access and Security Services (PASS) Security Labeling Services Conceptual Model [PASS-SLS] extends the Conceptual Model for the HL7 Version 3: Privacy, Access and Security Services - Access Control (PASS-ACS).1

The Informational Viewpoint section of this document references, draws upon, and elaborates on previous and concomitantly developed HL7 standards:

• HL7 Version 3: Role-based Access Control Healthcare Permission Catalog (RBAC) Normative specification for healthcare permissions, which are the Subject ADI inputs to access decision process.

• HL7 Version 3: Medical Records; Data Access Consent (V3 Consent Directive) Normative specification for patient consent directive messages, which are policy input to access decision process.

• HL7 Version 3: Composite Security and Privacy Domain Analysis Model (DAM) DSTU specification for information artifacts required to communicate and execute policies for access control and authorization.

• HL7 Version 3: Security and Privacy Ontology (SPO) Normative specification for a formal vocabulary embodying security and privacy policies, permissions, security labels, privacy and security protective mechanisms, consent directives, and access control concepts.

• HL7 Version 3: Healthcare Privacy and Security Classification System (HCS) Normative specification for construct of healthcare security labels.

SLS provides a SAIF Service Functional Model to support implementation of:

• HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), a specification in 2nd Normative ballot providing implementation guidance for segmenting healthcare information in accordance with privacy and security policies

• HL7 Implementation Guide for CDA®, Release 2: Consent Directives (Consent CDA) Normative specification for patient consent directive documents, which are policy input to access decision process.

It is critical to note that this specification is NOT providing implementation guidance for a service, document, or messaging for access control purposes; rather it is an unconstrained conceptual

1 The document originally supported the HL7 Services Aware Enterprise Architecture Framework (SAEAF), under which the PASS-ACS project was governed. In the interim between the balloting of the initial PASS-ACS and this extension to that document, the governing SAEAF framework was retitled as the Services-Aware Enterprise Architecture Framework (SAIF). Further context is given in the overview section below, but one key point to note is that the extended specification encompasses at the conceptual level, all of the viewpoints originally identified by the SAEAF as later articulated by the

HL7 Service-Aware Interoperability Framework: Canonical Definition Specification, Release 2

Draft Standard for Trial Use May 2012.










http://www.hl7.org/documentcenter/public_temp_B8610DCD-1C23-BA17-0CE1393AFCC80C7B/standards/dstu/SAIF_CANON_DSTU_R2_2012MAY.pdf



specification of the domain material.

2 Introduction The purpose of the Security Labeling Service Conceptual Model (PASS-SLS) is to describe the conceptual-level viewpoints associated with the business requirements for Resource labeling and for enforcement of data segmentation obligations, which relate to the content, structure, and functional behavior of information important to the Access Control area of the Privacy, Access, and Security (PASS) domains within the healthcare environment. As such, PASS-SLS is a detailed extension of the PASS Access Control Service Conceptual Model (PASS-ACS) as described in the base PASS-ACS DSTU Release 1.0 [January 2010] specification which this document references. Specifically, this document seeks to define the detailed business requirements for Security Labeling Service (SLS) and Privacy and Security Protective Service (PPS) by which an Access Control Service (ACS) decides whether access should be allowed and enforces those decisions including related data segmentation obligations. This document comprises the four viewpoints identified by the Services-Aware Enterprise Architecture Framework (SAIF) at the conceptual level: Business, Informational, Computational, and Engineering.

The goal of all SAIF artifacts is to ensure “working interoperability” (WI) between implementations, whether they be document-, message-, or service-based. The concept of working interoperability can be described as “the deterministic exchange of data/information in a manner that preserves shared meaning”. Starting at the conceptual level (this document), the goal is to ensure that specifications are “implementable in a variety of deployment contexts, in a repeatable, comprehensible manner”. The explicit specification of any transform that may be required to allow interoperability between implementations is one of the keys to WI.

The Business viewpoint identifies the business context and scoping for the specification, and contains the following artifacts: The use cases and scenarios that have been used to scope the work; A set of traceable requirements – informational, functional, and non-functional that have been

extracted from the use cases and scenarios, or driven out from subsequent analysis. A business object model that identifies objectives and business entities, including the roles that

those entities have in executing processes to achieve the stated objectives. The Informational Viewpoint presents the object model representing the unconstrained information requirements of the system – the major entities and their relationships to each other. This viewpoint also identifies vocabulary concepts that are appropriate for the domain. Artifacts in this viewpoint include: A static model, containing the information objects and invariant schema

A dynamic model, identifying allowable state changes to the information objects.

The Computational viewpoint presents the functional behavior of an ACS grouped so that they are distributable and may be exposed through service interfaces. It documents the collaboration analysis performed, identifies service roles and responsibilities, and groups the service capabilities and operational semantics into contracts and profiles.


The Engineering viewpoint identifies and captures any relevant platform capabilities, and documents any essential requirements for the distribution of any of the functionality identified.

2.1 Scope

The PASS-SLS presents the information and capabilities required to provide SLS and PPS to protected Resources in a distributed healthcare environment, where interoperability requirements arise. A pre-requisite to any access control activity is the management of policy. This document references the PASS-ACS consideration of behavior associated with the lifecycle of those policies. While identified in the document, the capabilities and semantic information associated with managing the rules associated with security labeling services and managing the policies associated with privacy and security protective services in the context of obligations as a whole are out of scope. Subsequent work will be required to elaborate these.

2.2 Statement of Normative Component

The majority of behavior identified in the Security Labeling Service is healthcare specific, and therefore considered as normative content. Normative content for the SLS are the following items, which are marked as Normative at the Section Headers:

• Section 5 - Security Labeling and Privacy and Security Protective Services Use Cases • Section 6 - Data Segmentation Business Requirements • Section 7 - PASS-SLS Informational Viewpoint • Section 8 - PASS-SLS Semantic Signifiers • Section 9.3.2 - Security Labeling Service Capability Collaboration • Section 10 - SLS Conformance

Specifically:

• The semantic content unique to healthcare in the Access Control business domain specific to PASS- SLS as specified in this document or in referenced specifications, in particular, the use of the HCS vocabulary.

• SLS and PPS Use Cases and Business Requirements described in Section 5. • The specific contracts which result from combining behavior with the semantic content in

Sections 5 – 8. • The conformance profiles, which group specific contracts into service components at the

conceptual level.


3 Business Viewpoint (Informative) Identified within the Business Viewpoint are the business issues, models, processes, and roles associated with the SLS and PPS components of the Access Control sub-domain of Privacy, Access, and Security Services.

Security labels are meta-data conveying constraints on the use of a labeled Resource, which are used as Resource ADI by a PDP to match against a Service Requester’s clearance (role and other ADI) in order to render an access decision with the applicable obligations required by policy. Security labels classify constraints on the WHO, HOW, WHEN, WHERE, and WHY – or in other words, on the actor (which is not necessary a person) and the context – for accessing and using a Resource.

The constraining rules are defined in policies that require security labels as ADI given Service Requester inputs. These policies are stored in policy repositories and administered in PAP. Concepts and their interrelations provided in policies to describe Resources, and related rules are represented using appropriate ontologies and terminologies. Security labels are used to manage access and use of Resources, such as protected health information (PHI) by deploying the following processes:

• A Service Requestor initiates an access request by communicating the Subject information (ID, authentication, assigned roles, request related local policies (obligations, promises, etc.)) to the PEP via an ACIS

• PEP invokes PDP to provide the decision • To respond, the PDP processes related Policy2 retrieved from the PAP, and requests that PIP retrieve ADI

required by the applicable Policy • PIP retrieves the ADI needed from ACI repositories as well as from:

o Cached Subject and Resource ACI o Security Label ADI from the SLS

• PDP returns an Access Decision and Obligations to PEP • PEP sends Obligations to PPS to apply to security labeled resources, which include instructions about how

to compose an aggregation of security label resources into a response to the Service Requester’s query with the PPS calculated high water marks and any policy required privacy marks.

Based on the access decision, the PEP provides the modified request (permit, modify, deny) to the data Resource and controls the correspondingly constrained response, thereby also enforcing that all policies (obligations, promises) are met.

2 This specification collapses the terms such as privacy or security rules or policies to the term “Policy”, which indicates that any policy or security rule or policy set has been, as a precondition, adjudicated to create a single Policy applicable to a particular request per ISO/TS 22600 Privilege management and access control.


Figure 1 Security Domain View

Figure 1 illustrates these concepts. In this figure, a security domain consists of domain users (Subjects); domain data objects (Resources) and the governance and security policies that unite them. Resources are tagged with labels indicating their security value or confidentiality. When a Subject is a human user (or a Subject process representing a human user), the label bound to the Subject often is called a clearance. In these cases, the label bound to the data object (Resource) is called a classification. (ISO 10181-3:1996 Access Control Framework/ITU X.812)

An access control decision is made by comparing Resource Security Label fields, e.g., the Resource’s Security Label confidentiality to the confidentiality value in the Subject’s Clearance. If a Subject’s Clearance confidentiality level is equal to or superior to the Resource confidentiality level, then access can be granted, subject to any remaining obligations (actions that must be performed prior to the actual release of the protected Resource).

4 SLS Relevant PASS-ACS Use Cases . The use cases presented in this section were selected from several identified during the PASS-ACS project work For the PASS-SLS, only the following two of the PASS-ACS use cases are replicated in this document to provide context. The boundary diagrams below [Figures 2, 3, and 4] illustrate the relationships that the Access Control Service and the Policy Management Service have with their external stakeholders and each other.

http://www.itu.int/rec/T-REC-X.812-199511-I/en


4.1 Use Case AC-1: Enforce Access Control Decision

4.1.1.1 Description

Invoke a function to decide whether to allow access to a Resource based upon currently active policies and ensure that the decision is enforced, logging the results.

4.1.1.2 Assumptions

• Each request contains a set of Requestor attributes including: A unique identity, A set of authorization claims or credentials, which can be validated, A set of attributes which provide additional context for the request. These attributes may include, but

are not limited to: The intended purpose of use which the Requestor has for the Resource(s), Whether the request is a “break-glass” request, Whether an emergency condition exists.

Each request contains a mechanism to uniquely identify the Resource(s) that are the target of the request, Each request contains the operation that is being requested to be performed on the Resource(s).

4.1.1.3 Actors

Service Requestor (via a Protected Resource or its supporting infrastructure)

4.1.1.4 Trigger Event

The use case is triggered when a request is issued to access a Protected Resource

4.1.1.5 Pre-conditions

At least two security domains have been established (Domain A and Domain B). Security Domains are defined as separate entities each with a set of Subjects and information Objects, and a common security policy (NIST Special Publication 800-33). The domains may exist within one enterprise or may include multiple domains as this concept can be extended by aggregation.

A trust relationship has been established between Domain A (Security Domain A) and Domain B (Security Domain B).

Post-conditions The requested operation has either been permitted or denied.

4.2 Use Case AC-6: Request Attributes

4.2.1.1 Description

Requests are made to ADI Providers (external components) for Requestor (User), Resource, Client, and environment attributes associated with an access control request.


4.2.1.2 Assumptions

Mechanisms exist that allow attribute requests to be forwarded to the correct provisioning services.

4.2.1.3 Actors

Service Requestor (indirectly) Access Decision Information Provider (secondary)


The use case is triggered by the execution of the Request Access Control Decision use case.


Security and/or privacy policies which make reference to external ADI have been implemented. A Service Request has resulted in a policy as identified above being evaluated

4.2.1.6 Post-conditions

The set of attributes required to evaluate the policy has been retrieved.


5 Security Labeling and Privacy and Security Protective Services Use Cases (Normative)

Figure 2 Boundary View of the Access Control Service with SLS and PPS

Figure 2 illustrates the boundary view of the access control service extended with SLS and PPS. The SLS extend existing access decision information provider capabilities by including security classification information about a Resource corresponding to clearances needed for access to protected information.

This section describes detail level use case components extending the PASS-ACS 2.6 Use Cases and 2.7 Requirements and Interfaces.


5.1 Security Labeling Service (SLS) Interface Details

The HL7 PASS-SLS applies HCS conformant labels to clinical information objects based on access control policies. Once labeled, access control systems can process clinical objects using the label tags as Resource ADI. Access decisions are made by matching the Resource security labels to clearances or other attributes specified by the Access Control Policy, which are derived from applicable organizational and jurisdictional privacy, security, and trust policies, including patient privacy consent directives.

Access Control Policy can be dynamic, particularly because of the volatility of trust and patient preferences; as a result, HCS labels must be capable of being applied at runtime (rather than being permanently stored with information objects). This runtime approach ensures labeled Resource ADI is aligned with the most current policy including policies of the trust framework controlling the information exchange between sender and receiver.

Figure 3 Security Labeling Service

The SLS evaluates the clinical information objects, including clinical tagging and provenance, submitted to determine the appropriate security labels to be assigned for access control. The SLS is supported by a Security Label Management System, which establishes, provisions, and manages the security tagging vocabularies and security labeling rules needed to support jurisdictional, organizational privacy, security, and trust policies including patient consent directives.


5.1.1 Use Case AC-1a: Assign Resource Security Labels and Return Security Label ADI

Invoke a function to request application of Resource security labels and return security label ADI.

5.1.1.1 Assumptions

Each request contains a set of Resource ADI, which is returned as security label ADI SLS can obtain security labeling policies from a Security Label Management Service SLS can access the requested Resource(s) SLS can evaluate which security labeling policies apply to a requested Resource SLS can access a Security and Privacy Ontology Service as directed by the security labeling policy

5.1.1.2 Actors

Resource ADI Provider Security Labeling Policy Manager Security and Privacy Ontology Services external to SLS in the location(s) specified by the Security Labeling

Policy Manager


The use case is triggered when a request is issued to apply Resource security labels and return security label ADI.


Security Label Management Service has been configured and is available to provide policies directing the SLS on the required structure of a security label for each Resource including which security label fields to populate and which value sets from which to draw the security label tag codes

Security and Privacy Ontology Service has been configured and is available to provide the SLS with the codes from current security label value sets required to populate Resource security label field.


• Requested Security Label ADI has been returned to the ADI provider

• Security labeled Resource is available to PPS to apply privacy and security mechanisms as request by the PEP based on the access control decision and obligations returned by the PDP.

NOTE: PASS-ACS specifies interface AC1-2: Request access control decision information (ADI, i.e.: policy attribute values) from another service. PASS-SLS further specifies sub-parts to this interface requirement in AC1-2a to enable the retrieval of Resource Security Label ADI and applicable security labels as PIP provided Resource ADI input to PDP.

Table 2 Security Labeling Service Requirements


ID Security Labeling Service Requirement Text Implied Capability

AC1-1 Provide access control decision information (ADI, i.e.: policy attribute values) to another service.

AC1-2 Request access control decision information (ADI, i.e.: policy attribute values) from another service.

The ability to request or retrieve attributes / information / tokens / decision factors.

AC1-2a Request Resource Security Label ADI The ability to request and retrieve attributes used to label Resource for access control decisions (ADI).

AC1-2b Request Security Label Policy The ability to request policies dictating which security labels must be assigned to the Resource that is the target of the Subject’s request.

AC1-2c Submit Security Label Policy The ability to retrieve and apply policies dictating which security labels must be assigned to the Resource that is the target of the Subject’s request.

5.2 Privacy and Security Protective Service (PPS) Interface Details

HCS relevant obligations are conditions that must be met prior to the release of information. Once an access control decision has been made, then the decisions and any associated obligations are provided to an access control enforcement point. The access control enforcement point tasks appropriate obligation services such as encryption of the response for enforcement. One of the most important of these with respect to HCS is the PPS illustrated below.


Figure 4 Privacy and Protective Services

The PPS enforces obligations by applying various transforms to the Resource being returned in the response. Such transforms may include, for instance, masking, redaction, shedding, shifting, annotations, anonymization, pseudonymization, or other methods to additionally protect or restrict access to all or part of a Resource. The PPS applies these transforms to security labeled Resource based upon rules. Once the obligation rules are applied, the PPS marks the final transformed Resource with humanly readable labels or privacy marks. The privacy marks are provided at the portion level (i.e., the element, segment, section, or page level) and overall level (high water mark) as specified by the transform template in use. The PPS is supported by its own Protective Services Management Sub-System3 which establishes the type of transformations to be applied based upon rules. These rules are determined in advance or dynamically at runtime, in accordance with environmental conditions and the Trust Framework in effect. Once the PPS transforms are complete, the resulting content is ready to be sent to the recipient.

5.2.1 Use Case AC-1b: Enforce Privacy and Security Protection Obligation

Invoke a function to ensure that the decision and associated obligations are enforced by means of privacy and security protective mechanisms.

5.2.1.1 Assumptions

Each PDP to PEP response contains an access control decision and [0…1] set of obligations based on the matching of the Subject’s clearance with Resource ADI including: Security label handling caveat ADI is assigned to the Resource by the SLS in order for the PEP to enforce the

access control decision such as: Mandatory obligation codes specifying required privacy and security protections such as:

Encryption during transit Requirement that receiver encrypt the Resource when it is stored in the end-user system (encryption

at rest) Disclosure of the minimum necessary information in the Resource in accordance with the access

decision Redaction of information in a Resource which is not be disclosed Masking of information in a Resource, which may only be decrypted by authorized end-users De-identification of information in a Resource by various means such as anonymization,

pseudonymization, shedding and shifting. Refrain policy codes specifying prohibited operations on the Resource such as: Prohibition against collection or integration of a Resource Prohibition against using the Resource for purposes other than stipulated by the assigned purpose of

use codes 3 The capabilities of the Protective Services Management Sub-System are described in the Data Segmentation Business Requirement Security Labeling and Privacy Protection Management.


Prohibition against relinking deidentified Resource Prohibition against further disclosure of the Resource without author or patient consent Prohibition against disclosing the Resource without establishing an MOU or validation of shared Trust

policies at run time Privacy Marking policies specifying human readable security labels such as:

Allowed purpose(s) of use Resource confidentiality Integrity reliability and status, e.g., whether the Resource has been attested to Provenance, e.g., whether information in the Resource is patient sourced For authorized end users, the sensitivity of the Resource so that the end users are informed about

how to handle the information in the Resource, e.g., not to discuss the information with unauthorized individuals.

Composition of Resource aggregates to ensure that the aggregate security labels and privacy marks are the “high water mark” or most restrictive security classification (confidentiality) and integrity levels, and for authorized users, the list of sensitivity types for information contained within the aggregated Resource.

5.2.1.2 Actors

Policy Enforcement Point (PEP) and Privacy and Security Protective Service (PPS)


The use case is triggered when PEP requests Privacy and Security Protection Obligation Enforcement.


Policy Decision Point (PDP) has returned an Access Control Decision and Obligations to the PEP.


PPS returns Privacy and Security Protected Resource, which is one or more Resources, composed with required security labels and privacy marks. Details on obligations include the following requirements adopted from PASS-ACS:

Table 3 PASS-ACS Obligation Requirements

Requirement Text Implied Capabilities


AC1-3

Provide the capability to return both a response and its associated obligation policy following a request for information.

Obligations provide the capability to return a data use policy with the requested data. The assurance of this policy can be none, Medium (e.g. an OASIS obligation), or Strong (e.g Digital Rights Management envelope).

AC1-5

Provide the capability to receive and enforce obligations associated with a return response to an information request.

The analysis and processing of Obligations were out of scope for the January 2010 ballot but in scope for the January 2014 ballot.

ACG-2

Provide the capability to ensure that protected information is accessible only by entities possessing authorizations that meet or exceed healthcare information security and privacy policy access control decision attributes.

Match Subject clearance with Resource security label to determine access decision and obligations.

PASS-ACS obligation-related services are modeled by drilling down on the Enforce Access Control Decision and Request Attribute Use Case components to the Security Labeling Service (SLS) and Privacy and Security Protective (PPS) and as illustrated in Figure 2: Boundary View of the Access Control Service with PPS and SLS, which updates the PASS Illustration 3 Boundary View of the Access Control Service.

Details on PPS service requirements are described in Table 4, which follows below. Table 4 Privacy and Security Protective Service Requirements

ID Privacy and Security Protective Service Requirement Text

Implied Capability

AC2-3 Enforce security and privacy policy based on contextual, action, target (Resource), or Subject (service requester) access control decision information.

Implement separation of duties and other policies, i.e. cardinality, time of day, work station, etc.

AC2-3a Enforce Resource Obligation Enforce privacy and security protection obligations on Resources per policy such as mask, redact, anonymize, and apply human readable versions of security labels as privacy markings. Resulting privacy and security protected Resources are provided to PEP for end user access.

AC2-3b Apply Resource Protections Enforce Resource Obligation Request triggers the application of privacy and security protective mechanisms to target Resource.

AC2-3c Apply Resource Privacy Marks Enforce Resource Obligation Request triggers the application of human readable privacy marks to target Resource.

AC2-3d Request Privacy and Security Protective Obligation Policy

PPS requests the obligation policies dictating privacy and security mechanisms to be applied.

AC2-3e Submit Privacy and Security Protective Obligation Policy

Retrieved obligation policies are applied to render privacy and security protected Resources.


6 Data Segmentation Business Requirements (Normative) Data Segmentation is defined as the “Process of sequestering from capture, access or view certain data elements that are perceived by a legal entity, institution, organization or individual as being undesirable to share.” [Goldstein GWU]. At the Conceptual Service Functional Model level, data segmentation is accomplished by the SLS and PPS components within an ACS. As described in the HL7 HCS, healthcare information in its most granular form is a semantically meaningful atomic unit of healthcare information or “clinical fact, which is comprised of a data element (e.g., class such as a medication, procedure, diagnosis) and the minimum set of data attributes (class properties) and associated clinical facts (e.g., provenance, author, patient, diagnosis, insurance or program coverage) required by policy to provide context required for security labeling purposes. As depicted by steps 1 and 2 in Figure 5 below, healthcare providers, in the course of Clinical Administration, generally decide what constitutes a clinical fact for their domain, which may be more or less complex depending on clinical practice requirements. These steps are described in detail next in Section 6.1 Healthcare Data Segmentation and Management Business Requirements where the Clinical Rules Manager is the conceptual EHR Clinical Fact Management (CFM) component that provides the ability to: Define and manage clinical attributes assigned to clinical elements to generate clinical facts (CFM 1.1.1) Manage rules for aggregating, disaggregating, persisting, and retrieving clinical facts for security label

assignment (CFM 1.1.2)


Figure 5 Data Segmenting EHR Conceptual Components

(Available for Download)

The clinical facts generated by the Clinical Fact Service (CFS) are inputs into the Security Labeling Service depicted in Figure 5 Step 4. CFS is the EHR component with the capability to execute rules for assigning standard clinical attributes to structured and unstructured clinical elements stipulated by CFM. These clinical facts are the “Resources” to which access control is applied to ensure that authorized users access information based on clearance parameters such as their roles, need to know, or relationship to the patient. The Resource attributes and related clinical facts comprise the set of security access control information from which a subset will be drawn, based on access control policy, to be assigned as security labels for evaluation as ADI. As depicted at Figure 5 Step 3, the Security Labeling Management (SLM) is the EHR component with the capability to manage rules for assigning security labels to clinical facts and providing privacy protections. In Figure 5 Step 7, the PDP requests Resource ADI from a PIP, which may in turn invoke an ADI Service. The ADI Service may collect ADI from external ADI providers for both the requesting Subject and the Resource, including the SLS. As described in the business requirements, the SLS will locate the Resource being requested and assign a security label to the most granular components (clinical facts) based on access control policies. As depicted in Figure 5 Step 6, the security label is assigned to the Resource with tags designating the security label confidentiality classification; categories of sensitivity, governing privacy policies, “need to know” compartments, integrity, and provenance; and handling caveats, including obligations (mandates), refrain policies (prohibitions) and privacy marks (required human readable security labels that alert the end user about governing policies and

http://gforge.hl7.org/gf/download/docmanfileversion/7049/9824/SecurityLabelingServicev4JMD.pptx


patient preferences).

6.1 Healthcare Data Segmentation and Management Business Requirements

The Data Segmentation Business Requirements tables below details all of the informational, functional, and quality requirements identified through review and analysis of the scenarios and use cases presented above. These are summarized in the Data Segmentation Business Requirements Diagram [Figure 6] and described in the following three Business Requirements lists:

Healthcare Data Segmentation Requirements [Table 5] Healthcare Security Labeling Requirements [Table 6] Healthcare Privacy and Security Protective Service Requirements [Table 7]

Note: Where the requirements in Tables 5, 6, and 7 below identify healthcare-specific functionality or semantic content, those requirements are reflected in the Conformance section of this document.


Figure 6 Data Segmentation Business Requirements

6.1.1 Healthcare Data Segmentation Business Requirements

Table 5 below summarizes all of the informational, functional, and quality data segmentation business requirements identified through review and analysis of the data segmentation scenarios and use cases presented above.

Table 5 Data Segmentation Business Requirements


Requirement Title Requirement Text Guidance RQT

Data Segmentation Services Data Segmentation Management and Services

Provide the ability to use clinical and security metadata tagging, conversion (such as redaction or de-identification), and encryption (such as masking) to segment clinical facts.

1

Manage Clinical Metadata

Clinical Fact Management (CFM)

Capability to manage rules for assigning standard clinical attributes to the structured and unstructured clinical elements that are required for assigning security labels, and for aggregating, disaggregating, persisting, and retrieving clinical facts for security label assignment.

The system SHALL provide the ability to associate any attestable content added or changed to an EHR with the content's author (HL7 EHR-S)

1.1

Define and manage clinical attributes assigned to clinical elements

Provide the ability to manage rules for assigning standard clinical attributes to the structured and unstructured clinical elements that are required for assigning security labels.

The Clinical Metadata Management (CMM): Provisions the ability to define rules about: Types of clinical metadata such as: • Clinical information category • Patient demographics and coverage • Provenance, including

• Provider identifier, specialty, and author, authenticator, per-former, or other roles

• Service delivery location and healthcare facility type

• Encounter type • Indication for an order • Record type

• Integrity status, confidence, and data alterations

Assigning clinical metadata to clinical

1.1.1



elements including: • The source of this metadata, i.e.,

where it is captured in an EHRS • Workflow triggers affecting integ-

rity status, such as before and af-ter legal authentication

• Terminology and version with which these are conveyed as re-quired by business context (e.g., SNOMED or ICD-10 diagnosis codes)

• Any transformations required in order to assign them to clinical el-ements in different business con-texts, e.g., codes used for billing a service may be different from codes used to order the service

Manage rules for generating and storing clinical facts

Provide the ability to manage rules for aggregating, disaggregating, persisting, and retrieving clinical facts for security label assignment.

1.1.2

Clinical Metadata Services

Clinical Fact Services Capability to execute rules for assigning standard clinical attributes to structured and unstructured clinical elements stipulated by Clinical Fact Management.

The system SHOULD provide the ability to retrieve both the information and business context data within which that information was obtained (HL7 EHR-S).

1.2

Assign standard clinical attributes to clinical elements

Provide the ability to assign applicable clinical attributes encoded with standard terminologies to standard structured and unstructured clinical elements as required for assigning security labels.

The system is able to accurately and sufficiently encode unstructured data, including CDA narrative blocks, as referenceable from structured data. Any narrative content, which if encoded would require a security label, must be encoded as one or more structured clinical facts. • This ensures that unstructured data

1.2.1



such as text from a clinician's dic-tated note can be assigned security labels at the clinical fact level.

• This enables the access control sys-

tem (ACS) to restrict access to and disclosure of unstructured clinical facts based on the security labels on the structured clinical facts. Au-thorized users will be able to view only the tagged unstructured clini-cal facts for which they have clear-ance.

• This enables the EHR to render the

security labels on unstructured clin-ical facts that are assigned to the associated structured data. Ren-dering the security labels assigned to unstructured clinical facts en-sures that the user is aware of the patient’s privacy concerns and alerts the user to the level of confi-dentiality.

Generate and store clinical facts

Provide the ability to persist clinical elements with assigned standard clinical attributes as clinical facts that are required for security label assignment.

1.2.2

Retrieve Clinical Facts

Provide the ability to retrieve clinical facts as required for security label assignment.

1.2.3


6.1.2 Healthcare Security Labeling Business Requirements

Table 6 below summarizes all of the informational, functional, and quality security labeling business requirements identified through review and analysis of the scenarios and use cases presented above.

Table 5 Security Label Management and Service Requirements

Requirement Title Requirement Text Guidance RQT Manage Security Labeling

Security Labeling and Privacy Protection Management (SLM)

Capability to manage rules for assigning security labels to clinical facts and providing privacy protections.

SLM provisions rules for the security labeling services for retrieving clinical elements and associated clinical metadata, assigning clinical information category, provenance, patient, and policy metadata as standards based security labels per jurisdictional, organizational, and patient consent directive privacy policies. The SLM controls the rules for redaction, masking, and security label tagging of clinical facts, which may be used to construct, for example, a CCDA for disclosure. Appropriate security labels are applied as metadata on the CCDA envelope, and at the CCDA header, section, and entry level, which instruct the receiver on how to comply with policies that govern the disclosure.

1.3

Manage privacy policies for clinical fact segmentation

Provide the ability to establish, translate, reconcile, and store privacy policies, including consent directives, as input to security labeling rules.

Once privacy policies are recorded in the consent engine, consent preferences are translated into an access control policy language so that the PDP/PEP can allow or deny access to the relevant information, or deny access but allow an override. (GWU)

1.3.1

Manage rules for automatic assignment of security labels

Provide the ability to manage rules for automatic assignment of security labels to clinical facts.

For example, a patient may restrict disclosures to a health plan concerning treatment for which the individual has paid out of pocket in full. (HITECH)

1.3.2


Manage rules for manual assignment of security labels

Provide the ability to manage rules for a user to manually override a security label automatically assigned to a clinical fact, e.g., based on professional judgment, policy, or an approved patient request.

Examples of the types of sensitive clinical facts governed by privacy policies include sensitive conditions under USC Title 38 Article 7332, 42 CFR Part 2, H.R. 493, the Genetic Information Non-discrimination Act of 2008 (GINA). The “right to forget” (i.e., to have PHI expunged) in France.

1.3.3

Manage privacy protective rules

Provide the ability to manage rules for automatic masking, redaction, and de-identification of clinical facts.

1.3.4

Manage handling caveats

Provide the ability to manage rules for automatic assignment of handling caveats in security labels assigned to clinical facts.

This capability enables Security Labeling and Privacy Management to determine the appropriate handling caveats to assign to tagged clinical facts to ensure that that the custodian and receiving systems comply with permissible purpose of use, obligations for protection of clinical facts, and refrain policies prohibiting certain uses and disclosures per jurisdictional, organizational, and patient consent directive privacy policies.

1.3.5



Security Labeling Service

Security Labeling Service (SLS)

Capability to execute rules for assigning security labels to clinical facts by applying security classification, sensitivity, integrity, category, and handling instructions markings to healthcare system output (data views, reports and messages) prior to access or disclosure.

The system provides the ability to mask parts of the electronic health record (e.g. medications, conditions, sensitive documents) from disclosure according to scope of practice, organizational policy or jurisdictional law (HL7 EHR FM Capability). Security Labeling Service (SLS): Provisions security labeling services based on security rules linking risk of harm resulting from unauthorized disclosure of a clinical fact in accordance with jurisdiction, organizational and privacy policy. Provides for the tagging of clinical facts with security classification, sensitivity, integrity, category, and handling instructions according to rules that bind security labels to clinical facts. The SLS Retrieves clinical facts from EHR or extracts them from source document. SLS invokes security label tag values, which are a subset of each clinical fact's access control information (ACI) from the Access control service Policy Information Point (PIP). The SLS also invokes the governing privacy policies and patient consent directive from the Policy Administration Point (PAP) to control user access and disclosure. SLS applies labeling rules and document transforms.

1.4

Retrieve and automatically assign security labels to clinical facts

Provide the ability to retrieve a clinical fact for automatic assignment of a security label.

1.4.1


Enable security labeling of clinical facts at the time of entry

Provide the ability for a user to manually override a security label automatically assigned to a clinical fact based on professional judgment, policy, or an approved patient request.

As a privacy choice, a patient might choose to hide even the existence of certain data, for example the fact that he/she had received treatment at a particular facility. (PCAST) For another example, a patient may restrict disclosures to a health plan concerning treatment for which the individual has paid out of pocket in full. (HITECH)

1.4.2

Bind security labels to clinical facts

Provide the ability to bind security labels to clinical facts retrieved for automatic or manual labeling to ensure integrity.

In addition to the default set of privacy tags, providers can mark individual data elements as confidential at the time the information is entered into the record; this allows providers to engage in a dialogue with patients regarding their preferences during the course of a clinical encounter. (GWU)

1.4.3

Persist security labels associated with clinical facts

Provide the ability to persist security labels associated with clinical facts.

This capability enables the security labeling service to automatically assign handling caveats per privacy policies for purpose of use, obligations, and the Refrain policies, and any privacy marks required to be displayed to end users.

1.4.4

Update security label per policy changes

Provide the ability to update security labels based on changes in policy, such as the revocation of a consent directive.

This capability enables the updating of security labels per policy changes assigned to clinical facts over which the custodian has control both intra and inter-enterprise via out-of-band notification, sending previous receivers updated clinical fact with revised security labels, or requiring receivers of masked clinical facts to obtain new keys by asserting clearances that match the revised security labels.

1.4.5


Enable security label enforcement by access control services

Provide the ability to invoke access control services to enforce security labels.

1.4.6

6.1.3 Healthcare Privacy and Security Protective Service Requirements

Table 7 below summarizes all of the informational, functional, and quality privacy and security protective service business requirements identified through review and analysis of the scenarios and use cases presented above.

Table 6 Privacy and Security Protective Service Requirements

Requirement Title Requirement Text Guidance RQT Privacy and Security Protective Service

Privacy and Security Protective Services (PPS)

Capability to enable and reverse privacy protective services such as redacting, masking, de-identifying, and applying privacy marks to clinical facts in accordance with transform rules.

The service accepts obligations resulting from an access control decision and clinical facts as input to generate information response to a query.

1.5

Mask clinical fact Provide the ability to mask and unmask clinical facts.

PPS Service provides clinical fact masking required to enforce privacy policies, e.g., a patient’s ability to mask health information from specific providers.

1.5.1

Redact clinical facts Provide the ability to redact clinical facts and maintain a link to the original clinical fact.

1.5.2

De-identify clinical facts

Provide the ability to deidentify clinical facts using techniques such as shedding, anonymization, and pseudonymization, and to maintain a link to the original clinical fact per policy.

1.5.3

Reverse privacy protective mechanisms

Provide the ability to unmask a clinical fact with a "shared secret" key based upon user clearance or other trigger, e.g., emergency or other specific situation.

The system provides the ability to override a mask in emergency or other specific situations according to scope of practice, organizational policy or jurisdictional law. (HL7 EHR FM ability)

1.5.4


Display Privacy Mark

Provide the ability to render security label fields required by policy to be displayed to end users.

1.5.5

7 PASS-SLS Informational Viewpoint (Normative) 7.1 Business Rules and Constraints

None identified in PASS-ACS. PASS-SLS Section 6 Data Segmentation Business Requirements entail development of implementation specific business rules to meet applicable policies and business practices, but these are out of scope for this specification.

7.2 Information Model

Information Models provide the basis for semantic content for PASS-SLS. Previous and concomitant work that has been developed by other projects listed in the Base Standards list at the beginning of this document is leveraged herein. In particular, the HCS security label vocabulary is adopted in whole as part of the SLS specification.


«HL7ObservationClass»SecurityObservation

«Abstract Concept» +_SecurityObservation«HL7ValueSet» +v:SecurityObservation+_SecurityClassificationObservation+_SecurityCategoryObservation+_SecurityControlObservation+_SecurityIntegrityObservation

«HL7ObservationType»SecurityObservationType

«Abstract Concept» +_SecurityClassificationObservationValue«HL7ValueSet» +v:ConfidentialityCode

«HL7ObservationValue»SecurityClassificationObservationValue

«Abstract Concept» +_SecurityControlObservationValue«HL7ValueSet» +v:SecurityControlObservationValue«HL7ValueSet» +v:Obligation«HL7ValueSet» +v:RefrainPolicy«HL7ValueSet» +v:POU«HL7ValueSet» +v:GeneralPOU

«HL7ObservationValue»SecurityControlObservationValue«Abstract Concept» +_SecurityCategoryObservationValue

«HL7ValueSet» +v:SecurityCategoryObservationValue+v:InformationSensitivityPolicy+v:ActPrivacyLaw+v:LOINC Sensitivty Information Type+v:Compartment+v:USPrivacyLaw+v:ConsentDirectiveType

«HL7ObservationValue»SecurityCategoryObservationValue

«HL7ConceptCode» +U (unrestricted)«HL7ConceptCode» +L (low)«HL7ConceptCode» +M (moderate)«HL7ConceptCode» +N (normal)«HL7ConceptCode» +R (restricted)«HL7ConceptCode» +VR (very restricted)

«HL7ValueSet»v:Confidentiality

«HL7ActCodeSystem» +_PrivacyPolicy«HL7ValueSet» +v:PrivacyPolicy

«HL7ObservationValue»ActPrivacyPolicyType

«HL7ActCodeSystem» +_USPrivacyLaw (US Realm)«HL7ValueSet» +v:USPrivacyLaw (US Realm)«HL7ConceptCode» +42CFRPart2«HL7ConceptCode» +CommonRule«HL7ConceptCode» +HIPAANOPP«HL7ConceptCode» +HIPAAPsyNotes«HL7ConceptCode» +HIPAASelfPay«HL7ConceptCode» +Title38Section7332

«HL7ObservationValue»ActUS PrivacyLawPolicy

«HL7ActCodeSystem» +_ActInformationSensitivityPolicy«HL7ValueSet» +v.ActInformationSensitivityPolicy«HL7ConceptCode» +ETH«HL7ConceptCode» +GDIS«HL7ConceptCode» +HIV«HL7ConceptCode» +PSY«HL7ConceptCode» +SDV«HL7ConceptCode» +SEX«HL7ConceptCode» +SCA«HL7ConceptCode» +STD«HL7ConceptCode» +TBOO

«HL7ObservationValue»ActInformationSensitivityPrivacyPolicyType

«HL7ActCodeSystem» +_EntityInformatonSensitivityPolicyType«HL7ValueSet» +v:EntityInformationSensitivityPolicyType«HL7ConceptCode» +DEMO«HL7ConceptCode» +DOB«HL7ConceptCode» +GENDER«HL7ConceptCode» +LIVARG«HL7ConceptCode» +MARST«HL7ConceptCode» +RACE«HL7ConceptCode» +REL

«HL7ObservationValue»ActEntityInformationSensitivityPrivacyPolicyType

«HL7ActCode» +_InformationSensitivityPolicy«HL7ValueSet» +v:InformationSensitityPolicy«HL7ConceptCode» +ADOL«HL7ConceptCode» +CEL«HL7ConceptCode» +DIA«HL7ConceptCode» +DRGIS«HL7ConceptCode» +EMP«HL7ConceptCode» +PRD«HL7ConceptCode» +PRS

«HL7ObservationValue»ActSensitivityPrivacyPolicyType

«HL7ActCodeSystem» +_RoleInformationSensitivityPolicy«HL7ValueSet» +v:RoleInformationSensitivityPolicy«HL7ConceptCode» +B«HL7ConceptCode» +EMPL«HL7ConceptCode» +LOCIS«HL7ConceptCode» +SSP

«HL7ObservationValue»ActRoleInformationSensitivityPrivacyPolicyType

«HL7ActCodeSystem» +_PrivacyLaw«HL7ValueSet» +v:PrivacyLaw

«HL7ObservationValue»ActPrivacyLawPolicy

«HL7ActCode» +_ConsentDirective«HL7ValueSet» +v:ConsentDirective«HL7ConceptCode» +EMRGONLY«HL7ConceptCode» +OPTIN«HL7ConceptCode» +OPTOUT«HL7ConceptCode» +NOPP

«HL7ObservationValue»ActConsentDirectiveType

«HL7ActCode» +_ActConsentType«HL7ValueSet» +v:ActConsentType«HL7ConceptCode» +ICOL«HL7ConceptCode» +IDSCL«HL7ConceptCode» +INFA«HL7ConceptCode» +IRDSCL+RESEARCH

«HL7ObservationValue»ActConsentType

«HL7ActCodeSystem» +c:Compartment«HL7ValueSet» +v:Compartment«HL7ConceptCode» +HRCOMPT«HL7ConceptCode» +RESCOMPT«HL7ConceptCode» +RMGTCOMPT

«HL7ObservationValue»Compartment

«HL7ActCodeSystem» +_LOINCSensitiveInformation«HL7ValueSet» +v:LOINCSensitiveInformation

«HL7ObservationValue»LOINCSensitiveInformationType

«HL7ActCodeSystem» +_PurposeOfUse (POU)«HL7ValueSet» +v:PurposeOfUse«HL7ConceptCode» +TREAT«HL7ConceptCode» +CAREMGT«HL7ConceptCode» +CLINTRL«HL7ConceptCode» +ETREAT«HL7ConceptCode» +POPHEALTH«HL7ConceptCode» +HPAYMET«HL7ConceptCode» +CLMATTCH«HL7ConceptCode» +COVAUTH«HL7ConceptCode» +COVERAGE«HL7ConceptCode» +ELIGDTRM«HL7ConceptCode» +ELIGVER«HL7ConceptCode» +ENROLLM«HL7ConceptCode» +REMITADV«HL7ConceptCode» +HOPERAT«HL7ConceptCode» +HACCRED«HL7ConceptCode» +HCOMPL«HL7ConceptCode» +HDECD«HL7ConceptCode» +HDIRECT«HL7ConceptCode» +DONAT«HL7ConceptCode» +FRAUD«HL7ConceptCode» +GOV«HL7ConceptCode» +HLEGAL«HL7ConceptCode» +MEMADMIN«HL7ConceptCode» +HOUTCOMS«HL7ConceptCode» +PATADMIN«HL7ConceptCode» +PERFMSR«HL7ConceptCode» +HPRGRP«HL7ConceptCode» +HQUALIMP«HL7ConceptCode» +PATSFTY«HL7ConceptCode» +RECODMGT«HL7ConceptCode» +HSYSADMIN«HL7ConceptCode» +TRAIN«HL7ConceptCode» +HMARKT«HL7ConceptCode» +PUBHLTH«HL7ConceptCode» +DISASTER«HL7ConceptCode» +THREAT«HL7ConceptCode» +HRESCH«HL7ConceptCode» +CLINTRCH«HL7ConceptCode» +PATRQT«HL7ConceptCode» +FAMRQT«HL7ConceptCode» +PWATRNY«HL7ConceptCode» +SUPNWK

«HL7ObservationValue»ActHealthInformationPurposeOfUseReason

«HL7ConceptCode» +COVERAGE«HL7ConceptCode» +ETREAT«HL7ConceptCode» +TREAT«HL7ConceptCode» +HPAYMT«HL7ConceptCode» +HOPERAT«HL7ConceptCode» +HMARKT«HL7ConceptCode» +PUBHLTH«HL7ConceptCode» +HRESCH«HL7ConceptCode» +PATRQT

«HL7ObservationValue»v:GeneralPurposeOfUse

«HL7ActCodeSystem» +_SecurityPolicy«HL7ValueSet» +v:SecurityPolicy

«HL7ObservationValue»ActSecurityPolicy

«HL7ActCodeSystem» +_ObligationPolicy«HL7ValueSet» +v:ObligationPolicy«HL7ConceptCode» +AOD«HL7ConceptCode» +ANONY«HL7ConceptCode» +AUDIT«HL7ConceptCode» +AUDTR«HL7ConceptCode» +CPLYPOL«HL7ConceptCode» +CPLYCC«HL7ConceptCode» +CPLYCD«HL7ConceptCode» +CPLYJPP«HL7ConceptCode» +CPLYOPP«HL7ConceptCode» +CPLYOSP«HL7ConceptCode» +DEID«HL7ConceptCode» +DELAU«HL7ConceptCode» +ENCRYPT«HL7ConceptCode» +ENCRYPTR«HL7ConceptCode» +ENCRYPTT«HL7ConceptCode» +ENCRYPTU«HL7ConceptCode» +MASK«HL7ConceptCode» +MINEC«HL7ConceptCode» +REDACT«HL7ConceptCode» +HUAPRV«HL7ConceptCode» +PSEUD«HL7ConceptCode» +PRIVMARK

«HL7ConceptDomain»ActObligationSecurityPolicyType

«HL7ActCodeSystem» +_RefrainPolicy«HL7ValueSet» +v:RefrainPolicy«HL7ConceptCode» +NOAUTH«HL7ConceptCode» +NOCOLLECT«HL7ConceptCode» +NODSCLCD«HL7ConceptCode» +NOINTEGRATE«HL7ConceptCode» +NOLIST«HL7ConceptCode» +NOMOU«HL7ConceptCode» +NOORGPOL«HL7ConceptCode» +NOPERSIST«HL7ConceptCode» +NORDSCLCD«HL7ConceptCode» +NORDSCLW«HL7ConceptCode» +NORELINK«HL7ConceptCode» +NORESUE«HL7ConceptCode» +NOVIP«HL7ConceptCode» +ORCON

«HL7ConceptDomain»ActRefrainPolicy

«Abstract Concept» +_SecurityControlObservationType

«HL7ObservationType»SecurityControlObservationType

«Abstract Concept» +_SecurityCategoryObservationType

«HL7ObservationType»SecurityCategoryObservationType

«Abstract Concept» +_SecurityClassificationObservationType

«HL7ObservationType»SecurityClassificationObservationType «HL7 Concept Domain» -d:SecurityIntegrityObservationType

«Abstract Concept» +_SecurityIntegrityObservationType«HL7ValueSet» +v:IntegrityObservationType+integrityStatus+provenance+integrityConfidence+dataIntegrity+dataAlteration

«HL7ObservationType»SecurityIntegrityObservationType

«HL7 Concept Domain» +d:IntegrityStatusValue«Abstract Concept» +_IntegrityStatusValue«HL7ValueSet» +V:DocumentCompletion+authenticated+dictated+documented+incomplete+in progress+legally authenticated+pre-authenticated

«HL7ObservationValue»IntegrityStatusValue

«HL7 Concept Domain» +d:ProvenanceValue«Abstract Concept» +_ProvenanceValue«HL7ValueSet» +v:ProvenanceValue

«HL7ObservationValue»ProvenanceValue

«HL7 Concept Domain» +d:DataIntegrityValue«Abstract Concept» +_DataIntegrityValue«HL7ValueSet» +v:DataIntegrityValue+cryptographicHashFunction+digitalSignature

«HL7ObservationValue»DataIntegrityValue «HL7 Concept Domain» +d:IntegrityConfidenceValue

«Abstract Concept» +_IntegrityConfidenceValue«HL7ValueSet» +v:IntegrityConfidenceValue+highly reliable+reliable+uncertain reliability+not reliable

«HL7ObservationValue»IntegrityConfidenceValue

«Abstract Concept» +_ProvenanceAssertionValue«HL7ValueSet» +v:ProvenanceAssertionValue+clinician asserted+non-clinical healthcare professional asserted+professional asserted+patient asserted+substitute decision-maker asserted+patient acquaintance asserted+device asserted#payer asserted

«HL7ObservationValue»ProvenanceAssertionValue

«Abstract Concept» +_ProvenanceSourceReportedByValue«HL7ValueSet» +v:ProvenanceSourceReportedByValue+clinician reported+non-clinical healthcare professional reported+professional reported+patient reported+substitute decision-maker reported+patient acquaintance reported+device reported+payer reported

«HL7ObservationValue»ProvenanceSourceReportedByValue

«HL7 Concept Domain» +d:Provenance«Abstract Concept» +_Provenance

«HL7ObservationType»Provenance

«HL7 Concept Domain» +d:IntegrityConfidence«Abstract Concept» +_IntegrityConfidence

«HL7ObservationType»IntegrityConfidence

«HL7 Concept Domain» +d:IntegrityStatus«Abstract Concept» +_IntegrityStatus

«HL7ObservationType»IntegrityStatus

«HL7 Concept Domain» +d:DataIntegrity«Abstract Concept» +_DataIntegrity

«HL7ObservationType»DataIntegrity

«Abstract Concept» +_DataAlterationValue«HL7ValueSet» +v:DataAlterationValue+redacted+masked+pseudonymized+anonymized

«HL7ObservationValue»DataAlterationValue

«Abstract Concept» +_DataAlteration«HL7ValueSet» +v:DataAlteration

«HL7ObservationValue»DataAlteration

Figure 6 HCS Security Label Vocabulary [Available for download]

http://gforge.hl7.org/gf/project/security/docman/HL7%20Healthcare%20Classification%20System/


7.3 FHIR Security Label Value Set Links

Table 8 below includes convenient links available in FHIR to HCS code systems and value sets, which include all the codes from which SLS and PPS implementations SHALL select security label field and tag values used in documents, messages, and FHIR Resources.

NOTE: The complete HCS security label vocabulary is available in a spreadsheet maintained on HL7 gforge.

Table 7 FHIR Security Label Value Set Links

Security Label Card. Value Sets Description

Confidentiality Classification

0..1 Confidentiality Security label metadata classifying an IT Resource (clinical fact, data, information object, service, or system capability) according to its level of sensitivity, which is based on an analysis of applicable privacy policies and the risk of financial, reputational, or other harm to an individual or entity that could result if made available or disclosed to unauthorized individuals, entities, or processes. Example Uses: Unrestricted, Normal, Very restricted

Sensitivity Category

0..* InformationSensitivityPolicy Security label metadata that "segments" an IT Resource by categorizing the value, importance, and vulnerability of an IT Resource perceived as undesirable to share. Example Uses: STDs, Psychiatric care, Celebrity status

Compartment Category

0..* Compartment Security label metadata that "segments" an IT Resource by indicating that access and use is restricted to members of a defined community or project Note: this is a different use of "Compartment" to the Patient Compartment use. Example Uses: Research, HR records.

Integrity Category

0..* SecurityIntegrityObservationValue Security label metadata that "segments" an IT Resource by conveying the completeness, veracity, reliability, trustworthiness, and provenance of an IT Resource Example Uses: Anonymised, signed, patient reported

US Privacy Law 0..* ActUSPrivacyLaw Security label metadata that “segments” an IT Resource by indicating the legal provisions to which the assignment of a Confidentiality Classification complies in the US. Other jurisdictions may develop realm-specific privacy law or policy category codes for use in security labels in their domains.

Handling Caveat 0..* SecurityControlObservationValue Security label metadata conveying dissemination controls and information handling instructions such as obligations and refrain policies to which an IT Resource custodian or receiver must comply. This type of handling caveat SHALL be assigned to a clinical fact if required by jurisdictional or organizational policy, which may be triggered by a patient consent directive Example Uses: do not disclose, various restrictions on use, and policy marks

http://www.hl7.org/implement/standards/fhir/security-labels.html

http://gforge.hl7.org/gf/download/docmanfileversion/7721/11283/HL7%20Healthcare%20Privacy%20and%20Security%20Classification%20Vocabulary%20Table.xlsx

http://www.hl7.org/implement/standards/fhir/v3/vs/Confidentiality/index.html

http://www.hl7.org/implement/standards/fhir/v3/vs/InformationSensitivityPolicy/index.html

http://www.hl7.org/implement/standards/fhir/v3/vs/Compartment/index.html

http://www.hl7.org/implement/standards/fhir/extras.html#compartment

http://www.hl7.org/implement/standards/fhir/v3/vs/SecurityIntegrityObservationValue/index.html

http://www.hl7.org/implement/standards/fhir/v3/vs/ActUSPrivacyLaw/index.html

http://www.hl7.org/implement/standards/fhir/v3/vs/SecurityControlObservationValue/index.html


8 PASS-SLS Semantic Signifiers (Normative) A semantic signifier is used to specify constraints on the information constructs that serve as payloads within service operations. It is the identification of a named set of information descriptions that are supported by one or more operations. The reference points for associated conformance statements occur at the computational model interface where the semantic signifier is specified as an input or output required by the contract.

8.1 Security Label ADI Selector (Informative)

Purpose The Attribute Selector type/value pairs are specific coded Security Label attributes, which can be assigned to a Resource Security Label. A generic request/response semantic structure allows for a flexible and extensible set of attributes as shown in Figure 8, below.

Figure 7 Attribute Requisitioning and Provisioning

This semantic signifier will be constrained by the information models provided by the HL7 DAM and HCS, and supported by terminology services with the HL7 SPO.

8.2 Security Label

Purpose A Security Label, which may be sent or retrieved as a message, FHIR Resource, or document, or as metadata assigned to any electronic artifact at the granular and aggregated level, encapsulates access control decision information needed to inform an access control decision. A Security Label consists of four first-order business concepts: Security Label Header, Security Classification Label Field, Security Category Label Field(s), and Security Control Label Field(s) as identified in the HCS. Each Security Label Field is associated with one or more types of tag values, which are populated with HCS-specified vocabulary in accordance with applicable policy as determined by the PDP. Details of the Security business concepts and attributes are illustrated in Figure 9 and described in Table 9 (below).


Figure 8 Security Label [Available for Download]

http://gforge.hl7.org/gf/download/docmanfileversion/7871/11489/SLS%20%2b%20NIST%20v3.pdf


Table 8 Details of the Security Label business concepts and attributes

Concept Attribute Description Conformance

Security Label Header

SHALL be present.


Security Label ID A unique identifier associated with a specific security label.

SHALL be valued.


Security Label Policy ID A unique identifier associated with a specific security label policy, which dictates the fields and associated field tag value vocabulary.

SHALL be valued.


Security Label Policy Effective Time

The time within which the Security Policy is in effect. Recommended.

SHOULD be valued.

Security Classification Label Field

HL7 Security Classification Observation Code

SHALL be present.

Security Classification Label Value

HL7 Confidentiality Code

Labeled Resource level of confidentiality.

SHALL be valued. If present, SHALL be valued with specified HCS vocabulary.

Security Category Label Field (abstract)

N/A If present, the abstract Security Category Label Field is specialized by 1…* Security Category Label Field types.

MAY be present. If present, SHALL be valued with specified HCS vocabulary.

Security Category Sensitivity Label Field

HL7 Information Sensitivity Code

Labeled Resource sensitivity per policy.


Security Category Privacy Policy Label Field

HL7 ActPrivacyLaw Codes; HL7 ActUSPrivacyLaw Code for US domain

Privacy policy governing labeled Resource.


Security Category Compartment Label Field

HL7 Compartment Code

“Need to know” permission for Resource access.











Security Category Integrity Label Field

HL7 Integrity Codes Indicators of a Resource trustworthiness and reliability; mechanisms used to ensure that the Resource has not been tampered with or altered in unexpected manner.


Security Category Provenance Label Field

HL7 Provenance Codes Indicators of a Resource source, authority, and context.


Abstract Security Handling Caveat Label Field

N/A If present, the abstract Security Handling Caveat Label Field is specialized by 1…* Security Handling Caveat Label Field types.


Security Handling Caveat Purpose of Use Label Field

HL7 Purpose of Use codes

Specific permission about how a Resource may be used to which a sender or a receiver must comply.

SHALL be valued if required by policy. If present, SHALL be valued with specified HCS vocabulary.

Security Handling Caveat Obligation Label Field

HL7 Obligation Codes Mandatory Resource handling instructions to which a sender or a receiver must comply.


Security Handling Caveat Refrain Label Field

HL7 Refrain Policy Codes

Prohibitions against actions that may be performed on a Resource to which a sender or a receiver must comply.


Security Handling Caveat Privacy Mark Field

N/A Human readable security labels, which are rendered in the graphic user interface on accessed electronic information.

SHALL be populated with human readable text if required by policy.

NOTE: The complete HCS security label vocabulary is available in a spreadsheet maintained on HL7 gforge.

http://gforge.hl7.org/gf/download/docmanfileversion/7721/11283/HL7%20Healthcare%20Privacy%20and%20Security%20Classification%20Vocabulary%20Table.xlsx


8.2.1 Dynamic Model

PASS-SLS references and adheres to PASS-ACS Dynamic Model as foundational, but does not further specify.

9 Computational Viewpoint 9.1 Overview

A computational viewpoint on an SAIF/RM-ODP system and its environment is a specification that enables distribution of the functional behavior of the system into service components which interact at interfaces. In the computational viewpoint, applications and business process realizations consist of configurations of interacting service components reflecting business roles participating in service collaborations.

9.2 Capabilities

This section describes each of the behaviors that have been identified from the requirements. The attributes of Accountability Type, Role, and Dependencies [Tables 10 and 11] act to provide input to determining what collaborations may be required to ensure that any contract associated with the capability is fulfilled.

9.2.1 Enforce Access Control Decision Table 9 Enforce Access Control Decision

Name Enforce Access Control Decision Description Accepts a request to access a Resource and invokes Policy Decision Points

to provide decisions and obligations. Based upon those decisions the service allows or prevents the request to be fulfilled.

Accountability Type Authorization Role Policy Enforcement Point (Access Enforcement Function) Obligations To enforce access control decisions made by Policy Decision Points by

allowing or refusing requests to access protected Resources. Community Indirectly, all Protected Resources Prohibitions Dependencies Request Access Control Decision

Submit Audit Record Precondition Constraints Post Conditions The requested Resource has been made available to the requestor. Exception Conditions Requestor does not have the authority to access the requested Resource. Relationship to levels of conformance


9.2.2 Get Access Decision Information Table 10 Get Access Control Information

Name Get Access Control Decision Information (ADI) Description Accepts a request to return ADI Accountability Type Attribute Role Policy Information Point Obligations To provide ADI that matches the incoming criteria. Community Used by Policy Decision Point Prohibitions Dependencies <<External>> Client Attributes used as ADI

<<External>> Resource Attributes used as ADI <<External>> User Attributes used as ADI <<External>> Environment Attributes used as ADI <<External>>Security Labels used as ADI

Preconditions Constraints Post Conditions The requested ADI has been returned Exception Conditions One or more ADI identifiers are unknown.

One or more ADI attribute values are unavailable. Requestor does not have the authority to invoke the capability.

9.3 Collaboration Analysis

This section discusses the interactions between capabilities classified by roles. It also identifies the obligations associated with those roles as well as the interdependencies of the capabilities.

9.3.1 Access Control

Figure 10: Access Control Roles and Capabilities, on the following page shows a static representation of the relationships between various roles participating in the execution of “Enforce Access Control Decision” behavior and associates capabilities with accountabilities in order to provide additional basis for profile development. The roles named in the illustration correspond to those identified in the PASS-ACS Business Viewpoint (Authorization Reference Model) in order to ensure consistency and traceability between artifacts. The following conventions have been used to create the diagram [Figure 10]:

• Each role is identified as a particular collection of related capabilities.


• The stereotype for each port identifies the accountability type for its associated behavior. • The dependency arrows point to the provider of the capability. • Binding semantics are identified on the dependency connectors and the associated arrows

indicate the source and destination of each of those information components. Note that the illustration shows an Access Control Intercept, with an embedded Policy Enforcement Point. This is consistent with the representation of Access Control functions contained in ISO 10181-3:1996 Access Control Framework/ITU X.812.




Figure 9 Access Control Roles and Capabilities

9.3.2 Security Labeling Service Capability Collaboration (Normative)

The following sequence diagram [Figure 11] illustrates the collaborations necessary to complete the “Security Labeling and Privacy and Security Protective” capabilities, which are new detailed collaborations for this specification, extending PASS-ACS. These collaborations fulfill the SLS use cases described above in Section 5. Note that the lifelines or objects identified represent business roles rather than specific components.


Figure 10 Capability Collaborations for Security Labeling and Privacy and Security Protective Services

(Available for Download)

http://gforge.hl7.org/gf/download/docmanfileversion/7876/11506/SLS%20Collab%20%2b%20Trust%20ADI.pdf


9.3.2.1 Collaboration Steps

1. Service Requestor makes a request for a Protected Resource and includes the Requestor’s identity and credentials. The request is intercepted by an Access Control Intercept Component (ACIC) acting as a proxy for the Resource.

2. ACIC forwards request to internal PEP to enforce an access control decision and provides an authorization request to the PEP. The authorization request includes the Access Request Message consisting of Requestor identity and credentials including clearance and asserted trust ADI, the Resource identifier(s), and the operation requested.

3. PEP requires Request Policy Decision and Submit Audit Record capabilities to be supplied in order to fulfill its role. This set of capabilities is exposed by the business roles of PDP and External Audit Service, respectively. The PEP requests a policy decision to be made by the PDP. The PDP is provided with Access Request Message that the PEP received, augmented with any additional contextual information that the PEP can provide.

4. PDP must have a policy to evaluate. If the PDP requires more than any internally available policy, it invokes Get Access Control Policy behavior from a Policy Provider (PAP), and sends policy selection criteria based on the information provided by the PEP so that the PAP can determine which policy(s) to return.

5. During the evaluation of the Policy, the PDP requests additional information from the Access Decision Information Service (PIP) that is referred to in the policy, but not provided by the PEP or cached earlier.

6. PIP invokes a set of behaviors on external services to obtain the additional ADI4 specific to: a. The Subject exercising the Service Requester capabilities beyond those asserted in the

Access Request Message b. Run-time currency and reliability of Trust Policy information asserted by the Service

Requester or the PAP

4 The PIP request to ADI providers is modeled after ISO 10181-3:1996 Access Control Framework/ITU X.812 [page 20] 8.2.3 Supporting mechanisms: Two mechanisms may be used to obtain the initiator-bound ACI from which the ADI required in the Decide Access facility is derived: a) Using authentication If access control is based on an individual initiator’s identity, then this identity can be validated using authentica-tion, either directly or indirectly. If access control is based on a group or role identity, the authenticated identity is a parameter to an Acquire initiator-bound ACI facility used to obtain a validated group or role. b) Using access control certificates or access control tokens The initiator obtains an access control certificate or access control token (or both) using the Acquire initiator-bound ACI facility. This access control certificate or token is then bound to an access request by the initiator using the Generate Access request-bound ACI facility and finally is verified by the ADF using the Verify Bound ACI and Derive ADI facility. The acceptability of the certificate authority identified in an access control certificate, or the initiator in the case of an access control token, is determined as part of the Verify Bound ACI and Derive ADI facility.



c. Additional Environmental or Contextual ADI beyond what the PEP provided d. Resource ADI generally applicable to the Resource Type, e.g., the resource

environmental control values such as location, workstation, device types, time of day, or number of authorized requesters in the timeframe

e. Resource ADI specific to the Resource instance, which are the Security Label ADI required to make an Access Control Decision, such as indicators of applicable sensitivities (e.g., medications for sensitive conditions) and privacy policies (e.g., the program governing Resource access such as 42 CFR Part2)

7. To provide security labels on ADI submitted, the SLS evaluates the PIP ADI request to select the applicable Security Labeling Policy. SLS constructs a Security Label for each resource that includes the Security Label Fields valued with codes from the value sets to which those fields are bound by the Security Labeling Policy. (See PASS-SLS Informational Viewpoint.) SLS returns the labeled ADI for further action by the PIP.

8. Once the ADI has been obtained from the PIP, the PDP can evaluate the applicable policy and render a decision. Depending upon the policy semantics, the decision may include one or more obligations that will be returned to the PEP to enforce.

9. PEP requests the PPS to enforce applicable PDP obligations. 10. PPS retrieves the security labeled Resources cached by the SLS for packaging, and:

a. Performs obligatory modifications such as ensuring the only the minimum necessary information from the Resource is packaged

b. Performs obligatory transformations based upon established rules and templates. Aggregates and composes the Resource(s) in to the required output format, e.g., as a CDA Document or HL7 v.2 message

c. Applies obligatory privacy and security protective mechanisms such as masking and encryption Applies human readable Privacy Marks, which represent the encoded Security Label tags required to be rendered in humanly consumable form to entry-level, portion and overall, amalgamating the encoded Resource Security Labels assigned to each aggregated Resource level to generate the “high water mark” Security Label to be assigned

11. PPS returns the Privacy and Protected Resource to the PEP. 12. PEP returns Access Control Enforcement response to ACIC 13. ACIC returns Privacy Protected Resource to Service Requester/Subject 14. As a result of this service invocation, the PEP has an obligation to generate audit event

information, and ultimately to provide that audit information to a component acting as an Audit Service for the PEP.

9.3.3 Policy Management

SLS references PASS-ACS on this topic.

10 Conformance (Normative) The SLS references the PASS-ACS Conformance requirements and adds those SLS and PPS specific


contracts and profiles that will be necessary for WI. In the computational viewpoint, there exists a reference point at any interface of any service component. A conformance statement is a statement that identifies conformance points of a specification and the behavior which must be satisfied at these points. Each reference point can become a conformance point based on conformance assertions made by referencing specifications in other viewpoints or less abstract specifications at a platform independent or platform specific level.

A contract can apply at a given reference point in a system. Conformance relies on evaluating the inter-actions between roles against their contractual obligations. In that case, it specifies the functional behav-ior which can be expected at the reference point.

Conceptual-level conformance statements will only occur in standards which are intended to constrain some feature of a real implementation, so that there exists, in principle, the possibility of testing. The following contract specifications and conformance profiles constitute conceptual conformance state-ments.

10.1 Resolve Security Label ADI Request Table 11 Resolve Security Label ADI Request

Capability Name Request Security Label ADI Description Accepts request to return ADI

Inputs Security Label ADI Selector Outputs Security Label ADI Selections

Miscellaneous notes Healthcare-specific

requirements satisfied AC1-2 Request Security

Label ADI from another service.

The ability to request or retrieve attributes / information / tokens / decision factors.

AC1-2a

Request Resource Security Label ADI

The ability to request and retrieve attributes used to label Resource for access control decisions (ADI).

AC1-2b

Request Security Label Policy

The ability to request policies dictating which security labels must be assigned to the Resource that is the target of the Subject’s request.

AC1-2c

Submit Security Label Policy

The ability to retrieve and apply policies dictating which security labels must be assigned to the Resource that is the target of the Subject’s request.

10.2 Apply Privacy and Security Privacy Protective Mechanisms Table 12 Apply Privacy and Security Privacy Protective Mechanisms

Capability Name Request Privacy & Security Protection Obligation Enforcement Description Accepts request to return Privacy and Security Protected Resource

Inputs Labeled Resource and PDP PPS Obligations

Outputs Privacy and Security Protected Resource


Miscellaneous notes

Healthcare-specific requirements

satisfied

AC2-3 Enforce security and privacy policy

Implement separation of duties and other policies, i.e. cardinality, time of day, work station, etc.

AC2-3a

Enforce Resource Obligation

Enforce privacy and security protection obligations on Resources per policy such as mask, redact, anonymize, and apply human readable versions of security labels as privacy markings. Resulting privacy and security protected Resources are provided to PEP for end user access.

AC2-3b

Apply Resource Protections

Enforce Resource Obligation Request triggers the application of privacy and security protective mechanisms to target Resource.

AC2-3c

Apply Resource Privacy Marks

Enforce Resource Obligation Request triggers the application of human readable privacy marks to target Resource.

AC2-3d

Request Privacy and Security Protective Obligation Policy

PPS requests the obligation policies dictating privacy and security mechanisms to be applied.

AC2-3e

Submit Privacy and Security Protective Obligation Policy

Retrieved obligation policies are applied to render privacy and security protected Resources.

11 Engineering Viewpoint This section identifies the infrastructure that is required to support functional distribution of an ODP system at the conceptual level. SLS references as foundational and adheres to the PASS-ACS engineering viewpoint.

11.1 ODP Functions

The ODP Functions are specified by the Reference Model and are intended to provide broad categories of functions to be considered. At the conceptual level, the majority of these functions would not necessarily be filled.

11.2 Physical Distribution Functions

N/A

11.3 Communication Functions

N/A

11.4 Processing Functions

N/A


11.5 Storage Functions

N/A

11.6 Engineering Roles

N/A


12 Appendix A: Glossary of Terms The following table identifies terms used in this document that are specific to the subject domain. A more complete list of definitions is available in the HL7 Security and Privacy Ontology.

Table 13 Glossary of Terms

Term Definition Source

Access (Security) Level The combination of a hierarchical security classification and a security category that represents the sensitivity of an object or the security clearance of an individual. [ISO 2382-8]

ISO 2382-8

A level associated with an individual who may be accessing information (for example, a clearance level) or with the information which may be accessed (for example, a classification level).

HIPAA Security Glossary]

Access Control A means of ensuring that the Resources of a data processing system can be accessed only by authorized entities in authorized ways

ISO/IEC 2382-8, definition 08.04.01

Access Control Decision Information (ADI)

The portion (possibly all) of the ACI made available to the ADF in making a particular access control decision.

ISO 10181-3:1996 Access Control Framework/ITU X.812 3.4.2

Access Control Information (ACI)

Any information used for access control purposes, including contextual information. ISO TS 22600-1:2006

Contextual information might include source IP address, encryption strength, the type of operation being requested, time of day, etc. Portions of ACI may be specific to the request itself, others may be associated with the connection via which the request is transmitted, others (e.g., time of day) may be "environmental".

OASIS

Access Control Intercept Component (ACIC)

An Access Control System component that intercepts an initiator request for access to a resource on behalf of the resource per policy.

The component orchestrates the request processing and response by invoking one or more PEPs to request policy decisions from associated PDPs, and returning via the PEP a protected resource generated by the PPS.

PASS- SLS based on ISO 10181-3:1996 Access Control Framework/ITU X.812

Access Control Intercept Service (ACIS)

Services provided by the ACIC to PEP requesting an access request decision and retrieval of any authorized protected resource for return to the initiator.

PASS- SLS based on ISO 10181-3:1996 Access Control Framework/ITU X.812

Access Control Service (ACS)

A service that provides the basic operational aspects of access control such as making access control decision information (ADI) available to access decision components and performing access control functions. The service also provides security labeling and privacy and security protection functions. The service, known as an Access Control Service (ACS), requires the following informa-tion: Access policy rules, Contextual information needed to interpret ADI, Initiator, target, and access request ADI, Security labeling rules and vocabulary, Transform rules and services. ACS generates information made available to other elements includes transformed in-formation response to an information request as well as handling caveats.

Attribute Characteristic of a Subject, Resource, action or environment that may be referenced in a predicate or target.

OASIS XACML

Attribute set The complete collection of parameters that in total describe the relevant characteristics of a clinical fact. These include, clinical attributes, security labels and provenance: For example, the patient's name and birthdate, diagnosis code, the applicable privacy rules and policies, including any patient's pre-consented privacy choices security label classification and sensitivity codes, and the data source (provider).

PASS- ACS

Attribute Directory A source of attribute data items. PASS- ACS

Audit record Data structure used to record audit events. PASS- ACS

http://wiki.hl7.org/index.php?title=Security_and_Privacy_Ontology

http://aspe.hhs.gov/admnsimp/nprm/seclist.htm















Authorization A process of granting rights, which includes the granting of access rights. ISO TS 22600-1:2006

Authorization/attribute access control

Access control based on values of access control information. PASS- ACS

Behavior The manner in which activity is exhibited. PASS- ACS

Break glass An administrative control which allows an authorized individual to access information under specific, declared circumstances.

PASS- ACS

Business context Enterprise requirements. PASS- ACS

Capability, functional Capacity to exhibit a relevant behavior PASS- ACS

(Security) Classification A security label which binds access control information (ACI) to a target. (See Clearance)

ISO 10181-3:1996 Access Control Framework/ITU X.812

The determination of which specific degree of protection against access the data or information requires, together with a designation of that degree of protection. Examples: "Top secret", "secret", "confidential

ISO/IEC 2382-8

Clearance Subject-bound access control information (ACI) that can be compared with security labels of targets. (See Classification)


Clinical attribute Any clinical characteristic that binds a health care relevant parameter to a clinical element by a rule.

HL7 Version 3: Healthcare Privacy and Security Classification System (HCS)

Clinical element A clinical object that has been disaggregated into the smallest possible data element suitable for use in a healthcare context.

PCAST

Clinical fact A clinical fact is a clinical element and at least one associated attribute or attribute set. These individual pieces are called "tagged data elements," because each unit of data is accompanied by a mandatory "metadata tag" that describes the (clinical) attributes, provenance, and required security protections of the data.

PCAST

Clinical rule A computational algorithm used for assigning a clinical attribute to a clinical element. HL7 Version 3: Healthcare Privacy and Security Classification System (HCS)

Compartmentalization A division of data into isolated blocks with separate security controls for the purpose of reducing risk. [ISO 7498-2]

Example: The division of data relative to a major project into blocks corresponding to subprojects, each with its own security protection, in order to limit exposure of the overall project risk.

ISO/IEC 2382-8:1998 Information technology – Vocabulary – Part 8: Security

ISO 7498-2]

Compartment (1) Security label metadata that "segments" an IT Resource by indicating that access and use is restricted to members of a defined community or project.

2. A set of categories in a security label.

Lattice-Based Access Control Models, Sandhu 1993

Compartment-based policies

In a compartment-based policy, sets of targets are associated with a named security compartment or category, which isolates them from other targets. Users need to be given a distinct clearance for a compartment to be able to access targets in the compartment.


Compatible Non contradictory (not necessarily identical) PASS- ACS

Composable Capable of being combined with other like components to form a new capability PASS- ACS





















Confidentiality Privacy metadata classifying an IT Resource (data, information object, service, or system capability) according to its level of sensitivity, which is based on an analysis of applicable privacy policies and the risk of financial, reputational, or other harm to an individual or entity that could result if made available or disclosed to unauthorized individuals, entities, or processes.

Usage Notes: Confidentiality codes are used in security labels and privacy markings to classify IT Resources based on sensitivity to indicate the custodian or receiver obligation to ensure that the protected Resource is not made available or redisclosed to individuals, entities, or processes (security principals) per applicable policies. Confidentiality codes are also used in the clearances of Subjects requesting access to protected Resources.

Map: Definition aligns with ISO 7498-2: Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. [HL7 Confidentiality code system 2.16.840.1.113883.5.25 and value set 2.16.840.1.113883.1.11.10228]


Consent, patient Permission granted, withdrawn, or withheld by an individual, usually for the collection, access, use, or disclosure of personal information or individually identifiable health information for a given purpose.

PASS- ACS

Consistent time A mechanism to synchronize the time base between multiple actors and computers. IHE Volume 1 (ITI TF-1): Integration Profiles

Constraint (authorization) A limitation on an access control rule PASS- ACS

Data Segmentation Process of sequestering from capture, access or view certain data elements that are perceived by a legal entity, institution, organization or individual as being undesirable to share.

Goldstein GWU

Decision, access control Finite result of evaluating an access control policy for a given set of Access Control Information

PASS- ACS

Decision, policy See Decision, access control PASS- ACS

Dependency Requirement to consult another entity PASS- ACS

Directive, patient consent An instruction regarding consent to collect, use, and/or disclose Individually Identifiable Health Information

PASS- ACS

Discovery Act of seeking and finding a target PASS- ACS

Document, clinical Documentation of clinical observations and services

Domain A collection of Resource consumers, information and functional Resources, and the policy that binds them.

PASS- ACS

Emergency access Access permitted by policy when an emergency condition exists PASS- ACS

Environment Surrounding space PASS- ACS

Environmental variables Those aspects of policy required for an authorization decision that are not contained within static structures, but are available through some local means to a privilege verifier (e.g. time of day, or current account balance).

ISO TS 22600-3:2006

Event Occurrence of a condition PASS- ACS

Event, security relevant Event that is included in security policy PASS- ACS

Granularity Level of detail PASS- ACS

HL7 Composite Security and Privacy Domain Analysis Model (DAM)

The model described in this publication contains a harmonized analysis of the security and privacy system requirements of healthcare organizations and their clients. This domain analysis model is intended to meet these challenges by identifying the information and system behaviors required to implement technological controls enforcing healthcare security and privacy policy. The model is intended to support the reuse of security standards to enforce access control policies required by jurisdictional and organizational privacy policies as well as individual client consent directives. It focuses on the information required to support authorization and access control use cases detailed in Annex A - Security and Privacy Use Cases

HL7 Version3: Security and Privacy Domain Analysis Model (DAM), DSTU

HL7 Healthcare Privacy and Security Classification System (HCS)

A defined scheme for the classification and handling of health care and healthcare related information. Guidance document describing the use of a Healthcare Privacy and Security Classification System (HCS) suitable for automated “tagging” and segmentation of protected health care information for security and privacy logical access purposes.






http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf

http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf











HL7 Security and Privacy Ontology (SPO)

A domain ontology encompassing the healthcare IT security and privacy domains providing a single, formal vocabulary embodying the concepts in each domain as well as concepts shared between the two. The concepts identified and defined in this ontology will be primarily drawn from those concepts contained in the Security and Composite Privacy DAMs. The concepts in this ontology will be extended in order to bridge to standard ontologies in associated domains such as enterprise architecture, clinical care and biomedicine. This project will: - Support modeling and analysis of the unified Security-Privacy DAM - Identify areas where reference value sets are needed Existing terminologies, where applicable, will be utilized and/or extended. Where appropriate terminologies are not available, they will be developed to meet the needs of the models. Concepts covered by security and privacy domains which are relevant to this ontology include, but are not restricted to, security and privacy policies, consent directives, and access control.

HL7 Version 3: Security and Privacy Ontology (SPO)

High water mark Rule that when information is combined from several targets, the result is assigned the highest classification level.

Warwick Ford

Individually Identifiable Health Information

Information that is a subset of health information, including demographic information collected from an individual, and (1) is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and (a) that identifies the individual; or (b) with respect to which there is a reasonable basis to believe the information can be used to identify the individual.

NIH HIPAA Privacy Rule Dictionary

Integration The act of bringing together data and/or capabilities from two or more independent applications, within the same enterprise or across multiple enterprises.

PASS- ACS

Interaction Participation in joint activity. PASS- ACS

Interface Point where interchange of data takes place. PASS- ACS

Interoperability Ability to coordinate operations in a meaningful way. PASS- ACS

Machine readable Capable of being processed by a computer in a meaningful way. PASS- ACS

Maintenance Administration to ensure acceptable operation. PASS- ACS

Management services Functions needed to conduct establishment, review, and maintenance. PASS- ACS

Metadata Data about other data. [ISO 14721] ISO 15489-1

Data describing context, content, and structure of records and their management through time. [ISO 15489-1]

NISO

Structured information that describes, explains, locates, and otherwise makes it easier to retrieve and use an information Resource. (NISO)

PCAST

Information that characterizes data, such as contextual information. PCAST

Security labels are a type of security metadata that is associated with a security object/IT Resource and considered a security attribute.

Named Tag Set Field containing a Tag Set Name and its associated set of security tags. NIST FIPS PUB 188

Object Any system Resource subject to access control, such as a file, printer, terminal, database record.

An object is an entity that contains or receives information. The objects can represent information containers (e.g., files or directories in an operating system, and/or columns, rows, tables, and views within a database management system) or objects can represent exhaustible system Resources, such as printers, disk space, and central processing unit (CPU) cycles. (NOTE: Synonymous with IT Resource.)

ANSI RBAC

An entity to which access is controlled. Examples: A file, a program, an area of main storage; data collected and maintained about a person.

ISO/IEC 2382-8:1998

Obligation/promise Constraint dealing with required behavior PASS- ACS

An operation specified in a rule, policy or policy set that should be performed by the PEP in conjunction with the enforcement of an authorization decision.

OASIS XACML

Permission An operation on an object [INCITS 359-2004]




http://privacyruleandresearch.nih.gov/dictionary.asp

http://privacyruleandresearch.nih.gov/dictionary.asp

http://www.itl.nist.gov/fipspubs/fip188.htm



Policy A set of legal, political, organizational, functional and technical obligations for communication and cooperation

ISO TS 22600-1:2006

Policy Decision Point (PDP) A system entity that makes authorization decisions for itself or for other system entities that request such decisions.

OASIS XACML

Policy Enforcement Point (PEP)

A system entity that requests and subsequently enforces authorization decisions. OASIS XACML

Policy Information Point (PIP)

The system entity that acts as a source of attribute values. OASIS XACML

Policy Administration Point (PAP)

The system entity that creates a policy or policy set. OASIS XACML

Policy administration Management of policy rules PASS- ACS

Policy, nested Policy rules stated in a hierarchical fashion PASS- ACS

Predicate A statement about attributes whose truth can be evaluated. OASIS XACML

Privacy (1) The claim of individuals, groups or institutions to determine for themselves when, how, and to what extent information about them is communicated to others. [Defined by uses this definition from A.F. Westin, Privacy and Freedom (1968). Basis for Privacy Act of 1974 (P.L. 93579; 5 U.S.C. § 552a).]

(2) The right of an individual to live free of intrusive monitoring of their personal affairs by third parties not of their choosing.

Canada Infoway EHR Privacy and Security

Freedom from intrusion into the private life or affairs of an individual when that intrusion results from undue or illegal gathering and use of data about that individual.

ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-199511-I!!PDF-E

The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed.

ISO/IEC 7498-2:1989/CCITT Rec. X.800

The quality or state of being hidden from, or undisturbed by, the observation or activities of other persons, or freedom from unauthorized intrusion; in healthcare-related contexts, the right of a patient to control disclosure of protected health information.

AHIMA Master Glossary, 3rd Edition

Individual's or organization's right to determine whether, when, and to whom, personal or organizational information is released. Also, the right of individuals to control or influence information that is related to them, in terms of who may collect or store it, and to whom that information may be disclosed.

HITSP Glossary

[T]he right to control access to one's person and information about one's self. The right to privacy means that individuals get to decide what and how much information to give up, to whom it is given, and for what uses." June 13, 2002, speech to the Freedom of Information and Protection of Privacy Conference

Privacy Commissioner of Canada June 13, 2002

Privacy Mark Human readable security labels, which are rendered in the graphic user interface on accessed electronic information, are called “privacy marks.” The act of enabling the rendering of a privacy mark is called “privacy marking”.

IEEE Security Glossary Compendium 93- CESG Memorandum No.1 Issue 1.2 Oct 1992

If present, the privacy-mark is not used for access control. The content of the privacy-mark may be defined by the security policy in force (identified by the security-policy-identifier) which may define a list of values to be used. Alternately, the value may be determined by the originator of the security-label.

ISO 22600-3 Section A.3.4.3

[1] A marking applied to information, indicating the estimated damage to the national interest that would be caused by its unauthorised disclosure, and used to determine the minimum standards of protection that should be applied. [2] A component of a security clearance and/or security class used for computing access rights and controlling information flow. Human readable word or phrase acting as an indicator of all or part of the security constraints that apply to a document so marked.

NOTE: Per this source, a label is a machine readable representation of a marking.

IEEE Security Glossary Compendium 93- CESG Memorandum No.1 Issue 1.2 Oct 1992

Privacy and Security Protective Service

Capability to enable and reverse privacy protective services such as redacting, masking, de-identifying, and applying privacy marks to clinical facts in accordance with transform rules. The service accepts obligations resulting from an access control decision and clinical facts as input to generate information response to a query.

HL7 PASS-SLS Security Labeling Service Business Requirements

Profile A named set of cohesive capabilities PASS- ACS

https://knowledge.infoway-inforoute.ca/EHRSRA/doc/EHR-Privacy-Security-Requirements.pdf

https://knowledge.infoway-inforoute.ca/EHRSRA/doc/EHR-Privacy-Security-Requirements.pdf

http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.812-199511-I!!PDF-E&type=items






http://ahimapress.org/Gloss3142/

http://ahimapress.org/Gloss3142/

http://www.hitsp.org/Handlers/HitspFileServer.aspx?FileGuid=fbd8c2af-1c67-460c-a1f0-2cd6655d0f2d

http://www.tbs-sct.gc.ca/pgol-pged/piatp-pfefvp/course1/mod1/mod1-2-eng.asp



http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=159342










Profile, conformance Profile that specifies compliance with a specification PASS- ACS

Profile, functional Named list of a subset of the operations defined within this specification which must be supported in order to claim conformance to the profile.

PASS- ACS

Protected Health Information (PHI)

Individually identifiable health information that is transmitted or maintained in any form or medium (electronic, oral, or paper) by a covered entity or its business associates, excluding certain educational and employment records.

H. Rept. 104-736 - HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996

Provenance The history of the ownership of an object, especially when documented or authenticated. For example, references to a type of equipment, standard clinical procedure, attestable content author, data source, provider or other clinical facts.

PCAST

Information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness.

W3C PROV-Overview

Provenance of a Resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that Resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance.

W3C Provenance XG Final Report

The records describing the possession of, and changes to, components, component processes, information, systems, organization, and organizational processes. Provenance enables all changes to the baselines of components, component processes, information, systems, organizations, and organizational processes, to be reported to specific actors, functions, locales, or activities.

NIST SP800-53 DRAFT Security and Privacy Controls for Federal Information Systems and Organizations

Metadata used to trace and verify the creation of data, how it has been used or moved among different databases, as well as altered throughout its lifecycle.

Data provenance is information that helps determine the derivation history of a data product, starting from its original sources. Data product or dataset refers to data in any form, such as files, tables, and virtual collections. […] Two important features of the provenance of a data product are the ancestral data products from which this data product evolved, and the process of transformation of these ancestral data product(s), potentially through workflows, that helped derive this data product.

Simmhan, Plale, Gannon, A Survey of Data Provenance in e-Science

The information that documents the history of the Content Information. This information tells the origin or source of the Content Information, any changes that may have taken place since it was originated, and who has had custody of it since it was originated. The archive is responsible for creating and preserving Provenance Information from the point of Ingest; however, earlier Provenance Information should be provided by the Producer. Provenance Information adds to the evidence to support Authenticity.

ISO 14721:2003 Space data and information transfer systems -- Open archival information system -- Reference model

Provisioning Supplying of items to a membership class PASS- ACS

Purpose of use Stated intent for access to privacy data PASS- ACS

Repository, directive Source of policy directives PASS- ACS

Repository, policy Source of policy rules PASS- ACS

Role, functional Named set of permissions controlling fine-grained accesses within a Resource such as an application

PASS- ACS

Resource Any data, information object, operation, process, service, or system capability. An IT Resource that is assigned a security label is sometimes referred to as a “security object”. An IT Resource that is represented as a requested security object of a Subject’s access request is sometimes referred to as a “target”.

Data, service or system component. OASIS XACML

The term Resource embraces, e.g., information Resources, processing Resources, communication Resources, and physical Resources. [Ford]

Warwick Ford

An object that is the target of security controls, including data, information, record, system file, service, or capability).

HL7 RBAC

http://www.gpo.gov/fdsys/pkg/CRPT-104hrpt736/html/CRPT-104hrpt736.htm





http://www.w3.org/TR/2012/WD-prov-overview-20121211/

http://www.w3.org/2005/Incubator/prov/XGR-prov-20101214/

http://www.w3.org/2005/Incubator/prov/XGR-prov-20101214/

http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-53-Rev.%204





http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=24683








Role, structural Named set of permissions controlling coarse-grained access at the outer boundary of a Resource such as an application

PASS- ACS

Rule-based access control Access control based on evaluation of a set of rules. PASS- ACS

Scalable Ability to be successfully applied to a range of sizes and/or complexities PASS- ACS

Schema Format specification with meaningful components. PASS- ACS

Security Attribute A security-related quality of an object. Security attributes may be represented as hierarchical levels, bits in a bit map, or numbers. Compartments, caveats, and release markings are examples of security attributes.

NIST FIPS PUB 188

Characteristic of a subject, Resource, action or environment that may be referenced in a predicate or target.

OASIS XACML

Security classification The determination of which specific degree of protection against access the data or information requires, together with a designation of that degree of protection. Examples: "Top secret", "secret", "confidential".

ISO 2382-8

Security Domain A set of elements, a security policy, a security authority and a set of security-relevant activities in which the set of elements are subject to the security policy for the specified activities, and the security policy is administered by the security authority for the security domain.

ISO/IEC 10181-1 3.3.20

Security label

Synonymous with

Note to Readers: In the definitions below, “security label” is defined as both a verb: “means used to associate security attributes” as in “security labeling”, and as noun: “the markings bound to a Resource”. As a noun, the term is sometimes considered synonymous with “security metadata” and “security tag.” As a verb, the term is sometimes considered synonymous with “tagging”. However, authoritative security standards sometimes use the term “security label” for both the classification given to IT Resources and the classification level in a Subject’s clearance. In addition, some authoritative standards use the term “marking bound to a Resource” to refer to both computable security labels and the human readable rendering of security label fields better known as “privacy markings”.

A security label can be used as target ACI to protect a target. Access rules define the access permissions (operations) granted given the security label of the Subject and the security label assigned to a target.

If the security policy requires that the ACI held in the security label are used for target ACI, then overall flow of data in and out of that target can be controlled. Hence, the overall flow of data in and out of targets may be analyzed for security domains applying the same security policy. Targets can be created within other targets. The security label of the containing target limits the security labels that may be assigned to the contained target under the rules for the appropriate security policy. Examples of targets to which labels may be applied include: OSI n-entities; Directory Service entries; files held in a file store; database entries.

ISO 10181-3:1996 Access Control Framework/ITU X.812 p. 24

The means used to associate a set of security attributes with a specific information object as part of the data structure for that object.


A security label, sometimes referred to as a confidentiality label, is a structured representation of the sensitivity of a piece of information. A security label is used in conjunction with a clearance, a structured representation of what information sensitivities a person (or other entity) is authorized to access and a security policy to control access to each piece of information.

XMPP Core

Sensitivity labels are security labels which support data confidentiality models, like the Bell and LaPadula model. The sensitivity label tells the amount of damage that will result from the disclosure of the data and also indicates which measures the data requires for protection from disclosure. The amount of damage that results from unauthorized disclosure depends on who obtains the data; the sensitivity label should reflect the worst case.

IETF RFC 1457

A security label comprises a set of elements optionally including a security policy identifier, a security classification, a privacy mark, and a set of security categories. The security label is bound to the attribute value using a digital signature or other integrity mechanism.

ISO/IEC 9594-2:2008 (E)


http://www.itu.int/rec/T-REC-X.810/recommendation.asp?lang=en&parent=T-REC-X.810-199511-I









Security Labeling Policy The definition of which classification and category values are used and how security labels are checked against clearances.


Security Labeling Rule A computational algorithm used for assigning a security label to a clinical element/attribute.


Security Labeling Service Capability to execute rules for assigning security labels to clinical facts by applying security classification, sensitivity, integrity, category, and handling instructions to healthcare system output (data views, reports and messages) prior to access or disclosure.


Security Logic Software specification of security actions and conditions. PASS- ACS

Security Policy Information File (SPIF)

A construct that conveys domain-specific security policy information. ISO/IEC 15816

An XML schema, that provides a high level representation of a security labeling policy in a generic and open fashion.

Open XML SPIF

Segmentation The process of sequestering from capture, access or view certain data elements or “datatypes” (clinical information categories) that are perceived by a legal entity, institution, organization, or individual as being undesirable to share.

HL7 Health Care Classification System

Sensitivity The characteristic of a Resource which implies its value or importance and may include its vulnerability.

ISO 7498-2

Sensitivity Label Security labels which support data confidentiality models, like the Bell and LaPadula model. The sensitivity label tells the amount of damage that will result from the disclosure of the data and also indicates which measures the data requires for protection from disclosure. The amount of damage that results from unauthorized disclosure depends on who obtains the data; the sensitivity label should reflect the worst case.

IETF RFC 1457

Service Consumer An individual entity [such as on an Electronic Health Record (EHR)/personal health record (PHR) system] that needs to make a service request of a Service Provider.

HL7 PASS-SLS Security Labeling Service

Service Provider (SP) The system providing a protected resource and relies on the provided security service. HL7 PASS-SLS Security Labeling Service

Service User Synonymous with Service Consumer. HL7 PASS-SLS Security Labeling Service

Structured Information Information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information Resource.

National Information Standards Organization (NISO)

Subject

An actor whose attributes may be referenced by a predicate. OASIS XACML

An active entity that can access objects. Example: A process that involves execution of a program.

ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-199511-I

The security principal invoking a system capability (Service Requester) or using a system capability or resource (Service Consumer). If the Service Requester is also the Service Consumer, then this security principal is the target of PIP Subject ADI request. If the Service Requester’s use of the system is to disclose a system resource, then the Requesting security principal and the Receiving security principal, which consumes the disclosed resource, are targets of PIP Subject ADI requests.

Synchronized Policy Mutual modification of policy to achieve compatibility. PASS- ACS

Tag Set Name Numeric identifier associated with a set of security tags. NIST FIPS PUB 188

Target The set of decision requests, identified by definitions for Resource, subject and action that a rule, policy or policy set is intended to evaluate.

OASIS XACML

A target is a Resource subject to access control. Warwick Ford

A target is an IT Resource for which a Subject seeks access.

Trust Entity X is said to trust entity Y for a set of activities if and only if entity X relies upon entity Y behaving in a particular way with respect to the activities.

ISO/IEC 10181-1 3.3.28

The characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions about a set of subjects and/or scopes.

OASIS WS-Trust 1.3



http://www.faqs.org/rfcs/rfc1457.html



http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html



The characteristic whereby one entity is willing to rely upon a second entity to execute a set of actions and/or to make a set of assertions about a set of principals and/or digital identities. In the general sense, trust derives from some relationship (typically a business or organizational relationship) between the entities. With respect to the assertions made by one entity to another, trust is commonly asserted by binding messages containing those assertions to a specific entity through the use of digital signatures and/or encryption.

OASIS WS-Federation Language 1.2

Working Interoperability (WI)

The deterministic exchange of data/information in a manner that preserves shared meaning.

HL7 Services-Aware Interoperability Framework (SAIF). Previously named SAEAF (Services-Aware Enterprise Architecture Framework)

http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223174931

http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223174931









13 Appendix B - Related Standards The following standards are referenced and provide foundational components for this work: ISO/IEC 10181-3:1996 – Information Technology – Open Systems Interconnection – Security

Frameworks for Open Systems: Access Control Framework ISO 22600 series – Policy Management and Access Control – Basic Access Control Model OASIS XACML 2.0 Specification – Terminology HL7 Version 3: Privacy, Access and Security Services - Access Control (PASS-ACS) DSTU HL7 Version 3: Role-based Access Control Healthcare Permission Catalog (RBAC) Normative HL7 Version 3: Medical Records; Data Access Consent (V3 Consent Directive) Normative HL7 Version 3: Composite Security and Privacy Domain Analysis Model (DAM) DSTU HL7 Version 3: Security and Privacy Ontology (SPO) Normative HL7 Version 3: Healthcare Privacy and Security Classification System (HCS) Normative PASS-SLS provides a SAIF Service Functional Model to support implementation of:

o HL7 Version 3: Implementation Guide: Data Segmentation for Privacy (DS4P) Normative o HL7 Version 3: Implementation Guide for CDA®, Release 2: Consent Directives (Consent

CDA) Normative

14 References (Westin) A.F. Westin, Privacy and Freedom (1968). (ACP 332) Allied Communications Publications 332 INFOSEC Technical and Implementation

Guidance for Labelling of NATO Information, March 2004 (ACP 122) Allied Communications Publications Allied Communications Publications 122 (F)

Information Assurance for Allied Communications and Information Systems Combined Communications-Electronics Board (CCEB)

ASTM E1986 - 09 (2013) Standard Guide for Information Access Privileges to Health Information (Bell) Bell, D. E., LaPadula, L. J. (Bell) "Secure Computer System: Unified Exposition and Multics

Interpretation", MTR-2997, MITRE Corporation, March 1976 (Biba) Biba, K. J. "Integrity Considerations for Secure Computer Systems", MTR-3153, Mitre

Corporation, April 1977 (CAPCO) Controlled Access Program Coordination Office Intelligence Community Classification

and Control Markings Implementation Manual May 12, 2008 (FIPS 188) FIPS 188, Standard Security Label for Information Transfer (Ford) Warwick Ford, Computer Communications Security, Prentice Hall, ISBN 0-13-799453-2,

1994 (GWU) Mellissa M. Goldstein, JD et al, Data Segmentation in Electronic Health Information

Exchange: Policy Considerations and Analysis, George Washington University Medical Center, September 29, 2010

(HIPAA Security Glossary) Addendum 2 HIPAA Security and Electronic Signature Standards



https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml








http://jcs.dtic.mil/j6/cceb/acps/acp122/ACP122F.pdf



http://csrc.nist.gov/publications/history/bell76.pdf

http://csrc.nist.gov/publications/history/bell76.pdf

http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA039324

http://info.publicintelligence.net/DNI-ClassificationManual.pdf

http://info.publicintelligence.net/DNI-ClassificationManual.pdf

http://csrc.nist.gov/publications/fips/fips188/fips188.pdf

http://www.amazon.com/Computer-Communications-Security-Principles-Techniques/dp/0137994532?SubscriptionId=AKIAJFQLXBCY7MGG3ULQ&tag=xlebooks-20&linkCode=xm2&camp=2025&creative=165953&creativeASIN=0137994532#reader_0137994532

http://www.healthit.gov/sites/default/files/privacy-security/gwu-data-segmentation-final-cover-letter.pdf

http://www.healthit.gov/sites/default/files/privacy-security/gwu-data-segmentation-final-cover-letter.pdf



Glossary of Terms (Definition of Access Level from NRC, 1991, as cited in HISB, Draft Glossary of Terms Related to Information Security in Healthcare Information Systems)

(HITECH) 45 CFR Parts 160 and 164 Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Non-discrimination Act; Other Modifications to the HIPAA Rules

(HL7 EHR-S FM) HL7 EHR-System Functional Model, R1.1 July 18, 2012 [Back to document] (HL7 RBAC R2) HL7 Version 3 Standard: Role-based Access Control Healthcare Permission Catalog,

Release 2 (revision of ANSI/HL7 V3 RBAC, R1-2008) February 2010 (HL7 RBAC v1.3) HL7 Role-Based Access Control (RBAC) - HL7 Role-Based Access Control (RBAC)

v1.3 September 2007 (HL7 RBAC Constraint Catalog) HL7 RBAC Constraint Catalog v1.38 (IEEE 802.10g) Institute of Electrical and Electronics Engineers 802.10g Secure Data Exchange

(SDE) Security Label (IETF RFC 1457) RFC 1457 - Security Label Framework for the Internet (IHE-AC_WP) IHE IT-Infrastructure White Paper: Access Control, IHE International, 2009,

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf

(IHE) Risk Assessment Cookbook: Preparing the IHE Profile Security Section (Risk Management in Healthcare IT Whitepaper) Revised 2008-11-10

(ISO 10021-2) ISO 10021-2 Message Transfer System: Abstract Service Definition and Procedures. Equivalent: ITU X.411

(ISO/IEC 10181-1:1196) ISO 10181-1 Information technology: Open systems interconnection Security frameworks for open systems. Overview, Nov 1996. Equivalent: Equivalent ITU X.810: Information technology - Open Systems Interconnection - Security frameworks for open systems: Overview

(ISO/IEC 10181-3:1996) ISO 10181-3 Information technology - Open Systems Interconnection - Security frameworks for open systems: Access control framework, 1996. Equivalent: ITU X.812: Information technology - Open Systems Interconnection - Security frameworks for open systems: Access control framework

(ISO 14721) ISO 14721:2003 Space data and information transfer systems -- Open archival information system -- Reference model (OAIS). This reference model is defined by recommendation CCSDS 650.0-B-1 of the Consultative Committee for Space Data Systems

(ISO 15489-1) ISO 15489-1:2001, Information and documentation -- Records management -- Part 1: General, 2001

(ISO 22600-3) ISO 22600 PMAC Part 3, Health informatics. Privilege management and access control. Implementations, Jan 2010

(ISO/IEC 2382-8) ISO/IEC 2382-8 Information technology -- Vocabulary -- Part 8: Security 1998 Equivalent: T-REC-X.812-199511-I!!PDF-E

(ISO/IEC 7498-2) ISO/IEC 7498-2:1989 Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 2: Security Architecture. Equivalent: CCITT Rec. X.800

(ISO/IEC 9594-2) ISO/IEC 9594-2:2008 The directory: Models. Equivalent: ITU X.501

https://www.federalregister.gov/articles/2013/01/25/2013-01073/hipaa-privacy-security-enforcement-and-breach-notification-rules







http://www.hl7.org/search/viewSearchResult.cfm?search_id=312541&search_result_url=%2Fdocumentcenter%2Fpublic%2Fwg%2Fsecure%2FStds%5F20070919%5FSW%2022%2E3%5FHL7%20RBAC%20Role%20Engineering%20Process%20v1%2E3%2Edoc

http://www.hl7.org/search/viewSearchResult.cfm?search_id=312541&search_result_url=%2Fdocumentcenter%2Fpublic%2Fwg%2Fsecure%2FStds%5F20070919%5FSW%2022%2E3%5FHL7%20RBAC%20Role%20Engineering%20Process%20v1%2E3%2Edoc

http://www.hl7.org/search/viewSearchResult.cfm?search_id=312541&search_result_url=http%3A%2F%2Fgforge%2Ehl7%2Eorg%2Fgf%2Fdownload%2Fdocmanfileversion%2F5577%2F7157%2FHL7%5FRBAC%5FConstraint%5FCatalog%5Fv1%2E39%5FPOST%5Freconciliation%5FJAN%5F2010%2Edocx





http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_Cookbook_2008-11-10.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Whitepaper_Security_Cookbook_2008-11-10.pdf

http://www.std.com/obi/Standards/ISO/iso10021-2_2.asc









http://public.ccsds.org/sites/cwe/rids/Lists/CCSDS%206500P11/Attachments/650x0p11.pdf




http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.501-200508-S!!PDF-E&type=items


(ISO/IEC 10021-2) ISO/IEC 10021-2:2003 Information technology -- Message Handling Systems (MHS): Overall architecture – Sections about Security Labels. Equivalent: ISO MHS X.411

(ISO/IEC 15816) ISO/IEC 15816:2001(e) Information technology – Security techniques –Security information objects for access control. Equivalent ITU-T X.841 10/2000

(ISODE Access Control) ISODE - Access Control using Security Labels and Security Clearances (ISODE Security Policy) ISODE - Security Policy, Security Label and Security Clearance

Infrastructure (ISODE Security Label) Using Isode Security Label Server for EDRMS (ISODE SPIF) ISODE - Why do I need a SPIF and what format should I choose? (NISO) National Information Standards Organization Understanding Metadata (NIST FIPS 188) NIST FIPS 188 - Standard Security Label for Information Transfer (NISTIR 5308) NISTIR 5308 General Procedures for Registering Computer Security Objects

December 1993 (NIST SP 800-53) NIST Special Publication 800-53 Recommended Security Controls for Federal

Information Systems February 2005 (PCAST) President’s Council of Advisors on Science and Technology, “Realizing the Full Potential

of Health Information Technology to Improve Healthcare for Americans: The Path Forward”, December 2010

(IETF RFC 1457) IETF RFC 1457, Security Label Framework for the Internet (Informational) May 1993

(RFC 2634) IETF RFC 2634 Enhanced Security Services for S/MIME P. Hoffman June 1999 (SDN.801) SDN.801 Reference Security Label (SDN.801C) SDN.801C Access Control Concept and Mechanism: Revision C May 1999 (Sandhu) Sandhu, Ravi S. (1993) "Lattice-based access control models". IEEE Computer 26 (11): 9–

19. doi: 10.1109/2.241422. (Simmhan) Yogesh, L. Simmhan, et al, A survey of data provenance in e-science, Newsletter ACM

SIGMOD Record, Volume 34 Issue 3, Pages 31 - 36, ACM New York, NY, USA, September 2005 (W3C PROV_O) W3C, PROV-O: The PROV Ontology, W3C Candidate Recommendation, 11

December 2012 (XACML) Organization for the Advancement of Structured Information Standards (OASIS)

eXtensible Access Control Markup Language (XACML) Version 3.0 August 10, 2010 (XMPP Core) IEFT RFC 6120 Extensible Messaging and Presence Protocol: Core March 2011 (XMPP IM) IETF RFC 6121 Extensible Messaging and Presence Protocol: Instant Messaging and

Presence March 2011 XML SPIF Version 2

http://www.std.com/obi/Standards/ISO/iso10021-2_2.asc


http://www.isode.com/whitepapers/security-labels-clearance.html

http://www.isode.com/products/security-policy-infrastructure.html

http://www.isode.com/products/security-policy-infrastructure.html

http://www.isode.com/whitepapers/security-label-server-for-edrms.html

http://www.isode.com/whitepapers/why-spif.html

http://www.niso.org/standards/resources/UnderstandingMetadata.pdf


http://csrc.nist.gov/publications/nistir/ir5308.txt

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated-errata_05-01-2010.pdf

http://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf

http://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf


http://rfc2634.openrfc.org/

http://www.winlab.rutgers.edu/~trappe/Courses/AdvSec05/access_control_lattice.pdf

http://en.wikipedia.org/wiki/IEEE_Computer

http://en.wikipedia.org/wiki/Digital_object_identifier

http://dx.doi.org/10.1109%2F2.241422

http://pti.iu.edu/sites/default/files/simmhanSIGMODrecord05.pdf

http://trdf.sourceforge.net/provenance/ns.html

http://trdf.sourceforge.net/provenance/ns.html

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf

http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf

http://xmpp.org/rfcs/rfc6120.html



http://www.xmlspif.org/SCHEMA/XMLSPIF.XSD