HL7 For Comment Ballot

helplessweedElectronics - Devices

Nov 15, 2013 (4 years and 1 month ago)

86 views


Page
1

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013



Unique Ballot ID:
PRIV_SEC_CLASS_SYS_R1_O2_2013JAN





HL7 Healthcare Privacy and Security
Classification System

Release 1

January 2013


HL7
For Comment

Ballot


Sponsored by:

Security Work Group


Co
-
chairs:

John “Mike” Davis, Bernd Blobel, John Moehrke, Trish Williams

Modeling and Vocabulary Facilitators:

John “Mike” Davis, Kathleen Connor




Copyright © 2013 Health Le
vel 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. R
eg.
U.S. Pat & TM Off
.
Use of this material is governed by HL7's
IP Compliance Policy
.



Page
2

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


Table of Contents

Introduction

................................
................................
................................
................................
......
3

Definitions

................................
................................
................................
................................
........
4

Components of the
Label based Model
................................
................................
...........................
5

Access Control Policy Models
................................
................................
................................
......
5

Multi
-
Level Policies (Hierarchical):
................................
................................
...............................
5

Compartment
-
Based Policies:

................................
................................
................................
.....
5

Context
-
Based Controls:

................................
................................
................................
..............
5

Health Care Classification System Core Structure

................................
................................
.........
6

Table 1: Health Care Classification System Security L
abels

................................
.....................
6

HCS Field Descriptions
................................
................................
................................
....................
7

Field 1: Confidentiality

................................
................................
................................
..................
7

Conf
identiality Label Guideline 1:
................................
................................
.............................
8

Confidentiality Label Guideline 2

................................
................................
..............................
8

Field 2: Sensitivity

................................
................................
................................
.......................
8

Sensitivity Guideline 1:

................................
................................
................................
.............
8

Sens
itivity Guideline 2:

................................
................................
................................
.............
8

Field 3: Integrity

................................
................................
................................
...........................
9

Integrity Guideline 1:
................................
................................
................................
.................
9

Field 4: Compartment
................................
................................
................................
...................
9

Compartment Guideline 1:
................................
................................
................................
........
9

Fiel
d 5: Handling Caveats and Labels

................................
................................
........................
9

Handling Caveat Guideline 1:
................................
................................
................................
...
9

Handling Caveat Guideline 2:
................................
................................
................................

10

Handling Caveat Guideline 3
................................
................................
................................
..

10

Access Control Decision Information

................................
................................
............................

10

Figure 2: Types of Resource Access Control Information
................................
........................

11

HCS Conformance

................................
................................
................................
.........................

11

References

................................
................................
................................
................................
.....

11



Page
3

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


Introduction

A security label, sometimes referred to as a confidentiality label, is a structured representation of the
sensitivity of a piece of informat
ion. 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)

Org
anizations typically have one or more security policies that provide for the compartmentalization of
data into

groupings that are to be protected and handled in the same way. The security policy defines
the protection to be applied to each compartment.

The

aspects of security expressed by a security policy, indicated in a security label, include the following:




Th
e level of protection to be given to data stored on a system;



W
ho is authorized to access data, processes or resources;



Se
curity markings required

to be shown on any display or print of the material;



Ro
uting and enciphering requirements for data transmitted between systems;



Re
quirements for protection against unauthorized copying;



M
ethods for storage of data;



En
ciphering algorithms to be used;



M
etho
ds of authenticating entities;



W
hether operations on the object are to be audited;



W
hether preventing repudiation of receipt of an object by recipients is required;



W
hether, and whose, digital signatures are required to authenticate the data.


When data is

held on an Information Technology (IT) system, or when it is transmitted electronically
between systems,

the data are
labeled

to indicate the security compartment to which the data belongs
and thus how the data is to be

handled for security. The label may

be separately identifiable from the
protected information but is logically bound to it.


The integrity of the labels, and the integrity of their binding to the information, must be assured. This
allows IT systems

and networks to make security
-
relevant
decisions, such as access control and routing,
without the need to access the

information that is being protected. The security label may be associated
with each data object in an IT system, such as

documents, electronic mail messages, display windows,
dat
abase entries, directory entries and electronic forms.

The

labels are intended for use when objects are stored, moved around (particularly between systems),
and when they are

being handled by applications that act on labels, including applications that cr
eate
new objects from existing ones.

When
labeled

data is to be passed between different security domains,
the domains should agree on a security policy to

be applied to that data. If the labels specified by the
policy applied within a domain differ from t
he labels specified by the

policy for shared data, then the
policy for the shared data shall specify how to translate between the two sets of labels.


Labels alone are not sufficient to ensure the security of information. The security policy that applies
to
the information

needs to be enforced by each organization while the
labeled

information is within the

Page
4

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


scope of their control. All the

organizations, individuals and IT systems that process an item of
information are presumed to know the security policy

for that information.

Organizations that exchange information need to establish trust in one another to be satisfied that

information will be handled according to agreed security policies. This trust is usually established
through a formal

agreement.

(ITU
-
T X.841)

There are two principal models that apply to the HCS. The first is the
Biba Integrity Model

developed by
Kenneth J. Biba in 1977
, is a formal
state

transition system

of
computer security

policy that describes a
set of
access control

rule
s designed to ensure
data integrity

(Biba). The second is the
Bell

LaPadula
Model

of
computer security policy

that describes a set of access control rules which use security labels
on objects and clearances for subjects (Bell).
In both the Biba model and the Bell and LaPadula model,
the security label is an attribute of the data.

In general, the security label associated with the data
remains constant. Since the security label is an attribute of data, it should be bound to the data.

Definitions


Term

Definition

Access
(Security)
Level


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


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)

Clearance

Initiator
-
bound
access control information (
ACI
)

that can be compared with
security labels of targets. ISO
-
10181
-
3

Confidentiality

The property that information is not made available or
disclosed

to
unauthorized individuals, entities, or processes (ISO 7492
-
2)

Compartmentalization

A division of data into isolated blocks with separate security controls for the
purpose of reducing
risk.

(ISO 2382
-
8
)



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.

Compartment

A security label tag that "segm
ents" an IT resource by
used to indicate

that
access and use is restricted to members of a defined community or project.


Healthcare
Classification System
(HCS)

A defined
system

for the classification, declassification, and handling of health
care and health care related information.


Page
5

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


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 Label

The marking bound to a resource CCITT Rec. X.800 and ISO/IEC 7498
-
2


The means used to associate a set of security attributes with a
specific
information object as part of the data structure for that object. NIST SP 800
-
53
/

ISO
-
10181
-
3 Access Control

S
ystem

Sensitivity

The characteristic of a resource which implies its value or importance and may
include its vulnerability

(ISO 7492
-
2)

Components of the Label based Model

The basic features of a label
-
based classification system include (Adapted from ISO 10181
-
3):

a)

This system makes use of security labels which can be assigned to subjects and resources, and data
passed between systems,

b)

This system is most convenient when there are many initiators accessing many targets and only a
coarse granularity of access control is required,

c)

This system, given certain policy restrictions, can be used to control the flow of data within a
security doma
in. Security labels also may be convenient for providing access control between
security domains,

d)

The allowed operations are not explicitly included in the initiator
-
bound or target
-
bound ACI, but
are defined as part of the security policy.

Access Control
Policy Models

Security labels support a number of policy models. From a security labeling perspective within this
health care security system, the most important models are: (Adapted from Ford)

Multi
-
Level

Policies

(Hierarchical)
:

A multi
-
level policy ope
rates by assigning to each target a
classification level, from a hierarchy of levels. Each user is assigned a clearance level from the same
hierarchy. The targets assignment reflects it sensitivity. The
user’s

assignment reflects general
trustworthiness ba
sed, for example, on an investigation of a person's background.


Compartment
-
Based Policies
:

In a compartment
-
based policy, sets of targets are associated with a
name
d

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.


Context
-
Based Controls:

Context
-
based controls allow an access control policy to specify that access
to a target will depend upon external factors such as:

(a)

T
he time of day,

(b)

The current location of the user,

(c)

The communication path used between subject and resource; and/or

(d)

The strength of the authentication method used in confirming the identity of the subject.


Page
6

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


Included in context
-
based controls are concepts suc
h as the purpose of use for which the resource
information is requested or allowed. Obligations are also a form of context policy requiring acceptance
by the subject in the context of particular circumstances.

Health Care Classification System Core Structu
re

This health care classification
system
adopts the core structure contained in NIST FIPS PUB 188. Figure

1
, illustrates the
general
structure of the
NIST
label
structure
as consisting of a set of fields. Each field
comprises a globally unique Tag Set Name, plus a set of security tags.

Field
1
Field n
Field i
Tag Set Name
Tag b
Tag a
Tag m
Security Label

Figure
1

NIST Standard Security Label

The
HCS defines

a quadruplet (4
-
tuple) of
re
source
label fields
plus one handling label field
as follows:



Confidentiality

(Hierarchical)
,



Sensitivity

(Compartment)
,



Integrity

(

Hierarchical),

and



Compartment

(Compartment)




Handling Caveat (
Contextual
)

These
defin
e

the classification of each labeled item and constituent components (inner envelope, cover
sheet, body, and section(s) and sub
-
sections or segments).



Table
1
: Health Care Classification System Security Labels

Security Label
Field
i

Label Definition

Notes

Confidentiality


Securi ty l abel metadata cl assifying an IT resource
(data, i nformati on object, servi ce, or system
capabi l ity) according to i ts l evel of sensi ti vi ty, whi ch
i s based on an anal ysis of appl i cable pri vacy pol ici es
and the ri sk of
fi nanci al, reputati onal, or
other

harm
Fi el d type: Mul ti
-
Level
(Hi erarchi cal ). Onl y one
cl assification val ue i s permi tted on
the header of an IT resource. It
must be hi gh water mark (most

Page
7

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


Security Label
Field
i

Label Definition

Notes

to an i ndi vi dual that coul d resul t from unauthori zed
di scl osure.
ii


restrictive).


In order
to access a classified
(tagged) IT resource, the user must
possess rights greater than or equal
to the IT resource classification.


[ISO/TS 22600
-
3:2009(E) A.3.2]

Sensitivity

Security label metadata categorizing the value,
importance, and vulnerability of

an IT resource
perceived as undesirable to share.



Field type: Category. ( Non
-
hierarchical)

In order to access
sensitivity

tagged
IT resource, the user must possess
“rights” corresponding to the
sensitivity tag(s).

Integrity

Security label
metadata
conveying

the
completeness, veracity, reliability, trustworthiness,
and provenance of an IT resource.



Field type: Multi
-
Level (Hierarchical).

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.

Field Type: Category

Handling Caveat

Security label metadata
conveying dissemination
controls, information handling caveats, purpose of
use, refrain policies, and obligations to which an IT
reso
urce custodian or receiver must comply.


Field Type: Contextual. Applies to all
information within scope of the
caveat

Classifier

Competent Authority who tags the information

Authority responsible for original
classification

Derivative
Classifier



Competent Authority who tags a portion of the
classified information


Declassification



Health care record retention policies (e.g., 85
years)

Document automatically declassified
and subject to request

HCS Field
Descriptions

This section explains the
components of

each member of the

HCS label
.

Field 1:
Confidentiality


Confidentiality

labels are access control decision information applied as resource attributes.


The
attributes are hierarchical with rights to higher levels providing read down and write

up but not write
down privileges. For information and access rights at lower levels of the hierarchy write up privileges
are not allowed. For example, a user with a Very Restricted clearance may read and write Very
Restricted data, read down and write u
p from lower levels, but may not write down to them. A user

Page
8

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


with Restricted privileges may read and write Restricted data, read down and write up from low levels,
but may not write down to them.

Confidentiality

Label
Guideline
1:


Apply
confidentiality

la
bels to identify categories of protected
information to which specific information object, cover sheet, section or segment belongs.

Note:

Confidentiality

labels are applied at the segment (entry), section, body, cover sheet levels of an
information object

including inner envelope layers wrapping the information object.

Confidentiality

Label
Guideline
2
: Apply
confidentiality

labels at the information object body level
to indicate the “high water mark” of all information contained within the information ob
ject and its
components.

Field 2:
Sensitivity

Confidentiality

labels are applied to data items
stored in an EHR
regardless of the data

type or

value
. On
the other hand, i
nformation
belonging to
a specific
category and
value
may
require

greater protections

than other information in the EHR. For example, sets of information associated with
the
HIV

condition

distinguishes them from other
information and may require the evaluation of specific security policies
for that category.

The sen
sitivity label policy operates by assigning to select resource one or more
labels from a list of such labels. The resource assignment reflects its sensitivity. Each user is assigned
sensitivity clearance levels from the same list.

S
ensitivity labeled se
ctions may contain multiple items within their individual sub
-
sections.


For
example, a summary Lab report sub
-

sections may contain many individual line items

for different types
of tests including HIV, Sickle Cell, etc. Anyone receiving such a report
must be cleared for HIV, and
Sickle Cell
, Label

markings of any type cannot be assumed to indicate anything about the results
(actual
data values)
other than the contents refer to HIV.

Sensitivity
Guideline
1:

Apply sensitivity labels to identify categori
es of protected information to
which a specific information object belongs but from which no diagnostic conclusion may be drawn.

Corollary to Sensitivity
Guideline
1:

Sensitivity labels are not to be interpreted as a “result”
but instead as a label for ea
ch instance of information of a particular sensitivity type.

Note:

In other words, lab data associated with HIV is tagged “HIV” whether or not the results are
positive or negative and no conclusion may be drawn regarding the result based on the informat
ion
label alone.

Sensitivity
Guideline
2:

These codes are not structured as a hierarchy (i.e., these are Non
-
hierarchical), and therefore, there is no concept of a high water mark to be applied.


Page
9

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


Field 3:
Integrity

Integrity

labeled sections may contain
multiple items within their individual sub
-
sections. Binary
integrity values such as “High” or “Low” allow for discrimination of segments containing such things as
unsigned notes, patient provided information or lab results. Evaluation of integrity label
s is a policy
matter providing segmentation of information potentially impacting patient safety.

Integrity
Guideline
1:

Apply integrity labels to identify categories of information for which diagnostic
conclusions may or may not be appropriate.

Field 4:
Compartment


In a compartment
-
based policy, sets of resources are associated with a named security compartment or
category, which isolates
them

from other resources. Users need to be given a distinct clearance for a
compartment to be able to access resour
ces in that compartment. (Ford)

Compartments encompass data items tagged for access to specific named groups. Being a member of
the group is sufficient to determine access. Compartments provide broad access to data items but do
not determine what fine
-
gr
ained rights a subject may have with respect to that resource (e.g. Role
based access control). Examples of compartments include, “For Pharmacy Personnel Only”, “Agent
Orange”, and “VIP”.

Compartment
Guideline
1:

Apply compartment labels to identify cate
gories of information groups
accessible only to subjects entitled access by virtue of group membership.

Field
5
:
Handling Caveats and Labels


Handling instructions are by definition action
s
.



For example, the following are examples of handling
instructio
ns:



Obligation. An operation specified in a policy or policy set performed in conjunction with the
enforcement of an authorization decision. The acceptance of an obligation may be implicit
(e.g., in an MOU, DURSA or contract) or explicit as in a returne
d response (e.g. a promise).



Routing

and communication path related

instruction
s
. For example, “Dr. Bob eyes only”.

Handling Caveat
Guideline
1
:


Apply handling caveats to obtain implicit or explicit acceptance of a
source rule required of a subject prio
r to use or access to any or all data encompassed by the obligation
or routing instruction.

Note 1:

For example, a handling caveat of

No

Redisclosure


is intended to evoke a subject’s implicit or
explicit agreement of the policy rule as a condition for receipt or access to the information object or
segments.

Note 2:

Inherent in the acceptance of an obligation is placing the obligation rule within the rule sets
associated with the applicable purpose of use.


Page
10

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


Handling Caveat

Guideline


2:

Apply purpose of use as an obligation type designating the policy rule
set that
is intended and authorized by the source to be applied for use or access by the subject to the
source information object.

Corollary to Handling Caveat
Guideline
2:

Nothing in Rule 2 should be interpreted as
either a prohibition or authorization for use fo
r other purposes other than the one
designated.

Note:

For example, information provided with a purpose of use of “Treatment” may be used for
“Payment” if payment policies so allow. In other words, a purpose of use handling caveat is not
exclusionary.
On the other hand, information provided for “Treatment” may not be available for
“Marketing” without a patient authorization if so required by subject policy.

Handling Caveat
Guideline
3
: Apply Handling Caveats as access control decision information to an
y
and all segments of an information object.

Note:

For example, data may be labeled with the “
No Redisclosure

attribute permanently affixed to all
data within an information object. Used as ACI,

No redisclosure


can be viewed as being in the same
categ
ory as NOFORN.

Handling caveats as ACI allow, in addition to use as an obligation, the retention of
information attributes needed to make future access control decisions.

Access Control Decision Information

ISO IEC 10181
-
3:1996 specifies key Target Access
Control Decision Information (ACDI), which are
representative of the Metadata Types that Access Control Systems use to match the clearance of an
Initiator with the classification of the Target.


Different Access Control Systems may use a subset of
these Me
tadata Types.



A Label
-
based System, which the HCS supports, focuses on matching the Target’s Classification with the
Initiator’s Clearance.


The Target’s Classification and Initiator Clearance are matched based on their
respective Security Labels, which are comprised of

Label Fields tagged with Confidentiality, Sensitivity,
Compartment and Integrity marking metadata.



In addition, the security labels are associated with Handling Caveat and Classifier Metadata, which apply
to the context of the labeled target.



Page
11

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


Target or Target Group
The identity of the entity to which
access is attempted
-------------------------------
EHR
,
Named Patient Record
,
Workflow
(
e
.
g
.
Orders
)
Key Target Access Control Information
Access Control Mechanisms
:

Capability
,
ACL
,
Label
,
or Context Based
Hierarchical Group
Hierarchical Group identities and the
accesses allowed or denied to them
-------------------------------
Organizational Headquarters
/
enterprise wide access
Geographical Sub
-
division
/
Sub
-
division access
,
Accesses restricted to Local Hospital
,
etc
.
Security Labels
Target tags to which access is
allowed
-------------------------------
Security Clearance
,
Confidentiality
Code
(
e
.
g
.
Very Restricted
)
,
Sensitivity Code
(
e
.
g
.
HIV
,
Sickle
Cell
)
Integrity Markings
Target integrity levels and accesses
allowed or denied to them
-------------------------------
Read Unsigned Progress Notes
,
etc
.
Policy Environment
:

Entity
,
Role
,
Rule
,
Attribute Based
Access Control
Adapted from
:
ISO
/
IEC
10181
-
3
Note
:
“Target” and OASIS “Resource” are
equivilent
Role
(
s
)
Role identities and the accesses
on the target allowed or denied
to them
-------------------------------
Structural
(
Coarse
-
grain
)
Roles
:
Oncologist
,
Dentist
,
etc
.
without
further qualifiers and
/
or
Functional
(
Fine
-
grain
)
Roles defined
by a named Permission Set
,
e
.
g
.
,
Role Name
::
{
Perm
1
,
Perm
2
...
PermN
}
Where permissions are

“actions”

allowed on specific


i
nformation
objects”
,
for example
:

WRITE

Progress Note
WRITE

Medication Order

SIGN

Prescription
Individual Initiator
Access Control Identity and Accesses
allowed or denied on target
-------------------------------
Connect
,
Access Control Lists
Functional Group
Healthcare Work Group identities and
accesses allowed or denied them
-------------------------------
Care Team can see assigned
patients
,
Pharmacy can see
“Pharmacy Only” data
,
Clinic
,
etc
.
Authorities
Individual authority identities and the
accesses allowed or denied to them
-------------------------------
Auditor
,
Certifications

Figure
2
:

Types of Resource Access Control Information

As can be seen from the figure, the security label is but one of multiple possible types of access control
information that may be used to control access t
o a protected resource. There is no intent to imply that
security labels
alone
are
sufficient for access control purposes.


HCS Conformance

HL7 Healthcare Classification System (HCS) R2 January 2013 For Comment Ballot provides guidance on
use of the hea
lth care classification system for creating security labels in accordance with
NIST FIPS PUB
188; NIST SP 800
-
53; ISO 2382
-
8; ISO
-
10181
-
3; ISO/TS 22600
-
3:2009(E), ISO/IEC 7498
-
2 and CCITT Rec.
X.800.

Conformance to the sections of the (the Health Care Cla
ssification System Core Structure; Table 1:
Health Care Classification System Security Labels; and HCS Field Descriptions), which are intended to be
moved forward to normative status,
is demonstrated by specification of
vocabulary for designating
security

label fields and their associated security tag sets.


Page
12

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


For purposes of illustrating conformance, the
HL7 Security Observation Vocabulary
is included
in the
Informative Example of HCS using HL7 Vocabulary.docx

as an adjunct document to the HCS.
Implementers may use codes from the
SecurityObservationType value sets to specify a security label
field type

In accordance with the HCS System security label field type. Security label
field tags

may be
selected from the associated SecurityObservationValue value set to populate the designa
ted security
label field.

References

ACP 332 INFOSEC Technical and Implementation Guidance for Labelling of NATO Information. March
2004.

(Biba) Biba, K. J. "Integrity Considerations for Secure Computer Systems"
, MTR
-
3153, The Mitre
Corporation, April
1977.

(Bell) Bell, D. E.
; LaPadula
, L. J. "Secure Computer System: Unified Exposition and Multics
Interpretation", MTR
-
2997, The MITRE Corporation, March 1976.

CCITT Rec. X.800 and ISO/IEC 7498
-
2

ESS (Extended Security Services)

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

(Ford)

Ford, Warwick, Computer Communications Security, Principles, Standard Protocols and
Techniques, Prentice Hall, 1994

(IETF RFC

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

Institute of Electrical and Electronics Engineers (IEEE) 802.10g Secure Data Ex
change (SDE) Security
Label.

International Organization of Standardization (ISO) SC
-
32 Security Label.

ISO 2382
-
8
Information technology
-

Vocabulary
-

Part 8:
Security,

1998

ISO 10181
-
1

Information technology. Open systems interconnection. Security frameworks for open
systems. Overview, Nov 1996

ISO 10181
-
3 Information technology
-

Open Systems Interconnec
tion
-

Security frameworks for

open
systems: Access control framework, 1996

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

ISO MHS X.411 Security Label.

ISO/IEC 15816 Security Information Objec
ts for Access Control

ITU X.411 Message Transfer System: Abstract Service Definition and Procedures, ISO/IEC 10021
-
4, 1988

ITU X.501 The Directory: Models, ISO/IEC 9594
-
2, 2008


Page
13

HL7 Heal thcare Pri vacy and Securi ty Cl assification System

© 2013 Heal th Level Seven
Internati onal. All ri ghts reserved.

January 2013


(ITU
-
T X.841)

Information technology


Security techniques


Security informat
ion objects for access control, OCT 2000

ITU X.812 INFORMATION TECHNOLOGY OPEN SYSTEMS INTERCONNECTION SECURITY FRAMEWORKS
FOR OPEN SYSTEMS: ACCESS CONTROL FRAMEWORK, 1995

Military Standard (MIL STD) 2045
-
48501 (Common Security Label).

National Institute o
f Standards and Technology (NIST) Federal Information Proc
essing Standard (FIPS)
188 Standard Security Label.

NIST SP 800
-
53 Recommended Security Controls for Federal Information Systems and Organizations

(NRC)
NRC, 1991, as cited in HISB, DRAFT GLOSSARY
OF TERMS RELATED TO INFORMATION SECURITY IN
HEALTH CARE INFORMATION SYSTEMS

President’s Council of Advisors on Science and Technology, Health Information Technology Report, Dec
2010

RFC 2634

Enhanced Secu
rity Services for S/MIME, P. Hoffman, June 1999

SDN 801c Access Control Concept and Mechanism: Revision C. May 1999

SDN.801 Reference Security Label.

XMLSPIF Version 2:

http://www.xmlspif.org/schem
a/xmlspif.xsd

(
XMPP)

Extensible Messaging and Presence Protocol (XMPP
)
XEP
-
0258: Security Labels in
XMPP

http://xmpp.org




i

FIPS

188:
Security Label Field r
epresents security attribute
-
A security
-
related quality of an object. Security attributes may be represented as
hierarchical levels, bits in a bit map, or numb
ers. Compartments, caveats, and release markings are examples of security attributes. Field
designation may be conveyed with HL7 SecurityObservationType codes.

ii

Standard definitions of Confidentiality include: “The property of data that indicates the ext
ent to which these
data have not been made available or disclosed to unauthorized individuals, processes, or other entities.” [ISO
7498
-
2:1989; ISO/IEC DIS 2382
-
8]; ITU_X.814 ISO/IEC 10181
-
5 p. i i i ]