HL7 Version 3 Standard:

apprenticegunnerInternet and Web Development

Oct 22, 2013 (3 years and 8 months ago)

326 views

V3_SECPRONT_R1_N2_2013SEP






HL7
Version 3
Standard:


Security and Privacy Ontology,

Release 1

September

2013


HL7 Normative Ballot


Sponsored by
:

Security Work Group

Community
-
Based

Collaborative Care (CBCC)

Work Group

Electronic Health Record (EHR)

Work Group

Service Oriented Architecture (SOA)

Work Group

Vocabulary

Work Group







Copyright © 2013 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
.

Use of this material is
governed by HL7's
IP Compliance Policy
.

Page
2

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


Principal Contributor and

Editor
:

Tony Weida

U.S. Department of Veterans Affairs /
Apelon, Inc.



Contributors:

Bernd Blobel

HL7 Germany


Kathleen
Connor

U.S. Department of Veterans Affairs / Edmond
Scientific Company


Mike Davis

U.S. Department of Veterans Affairs


John Moehrke

GE Healthcare



Security Co
-
chairs:

Bernd Blobel

HL7 Germany




Mike Davis

U.S. Department of Veterans Affairs




John Moehrke

GE Healthcare




Trish Williams

Edith Cowan University & HL7 Australia



CBCC Co
-
chairs:


Suzanne Gonzales
-
Webb

U.S. Department of Veterans Affairs

/
Dynamic
Research Corporation




Richard Thoreson

Substance Abuse and Mental Health
Services
Administration (SAMHSA)




M
ax Walker

Department of Health

(Australia)





Page
3

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


CO
NTENTS

Contents

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

3

Figures

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

7

1

Preface

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

8

1.1

Publication

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

8

1.2

Notes to Readers

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

8

1.3

Future Directions

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

9

1.4

Disc
laimers

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

9

1.5

Key Words

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

9

1.6

Conformance

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

9

1.7

Constraints

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

11

1.8

SAIF Ali
gnment

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

11

1.9

Acknowledgements

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

12

1.10

Ballot Statement of Scope

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

12

2

Introduction

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

17

3

Background

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

18

3.1

Composite Se
curity and Privacy Domain Analysis Model

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

18

3.2

Role
-
Based Access Control

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

18

3.3

HL7 RBAC Healthcare Permission Catalog

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

18

3.4

Ontologies

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

18

3.5

Types of Ontologies

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

19

3.6

Description Logics

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

20

3.7

OWL

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

21

3.8

SWRL

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

21

4

Scope and Objectives

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

23

Page
4

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


5

Use Cases

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

25

6

Modeling Approach
................................
................................
................................
.............................

26

6.1

Lang
uage

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

26

6.2

Precedence of Sources

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

26

6.3

Naming Conventions

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

26

6.3.1

Internationalized Resource Identifiers

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

26

6.3.2

Ontology Naming and Versioning

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

27

6.3.3

Class Naming

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

28

6.3.4

Individual Naming

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

28

6.3.5

Property Naming

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

29

6.4

Mo
deling Conventions

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

29

6.4.1

Redundant Universal Restrictions on Object Properties

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

29

6.4.2

Distinct Individuals

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

30

6.5

Design Patterns

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

30

6.6

Anno
tations

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

32

7

Ontology

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

34

7.1

Hierarchy of Sub
-
Ontologies

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

34

7.2

SecurityAndPrivacyOntology.owl

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

37

7.2.1

Overview

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

37

7.2.2

Class Hi
erarchies in SecurityAndPrivacyOntology.owl

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

37

7.2.3

Object Properties in SecurityAndPrivacyOntology.owl

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

39

7.2.4

Data Properties in SecurityAndPrivacyOntology.owl

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

41

7.2.5

Classes in SecurityAndPrivacyOntology.owl

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

43

7.2.6

Disjoint Cla
sses Axioms in SecurityAndPrivacyOntology.owl

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

68

7.3

ClinicalObservationOntology.owl

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

7
0

Page
5

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


7.4

CompartmentOntology.owl

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

71

7.5

ConfidentialityOntology.owl

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

71

7.6

CRUDEA_OperationOntology.owl

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

72

7.7

DataOperationOntology.owl

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

73

7.8

IntegrityOntology.owl

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

76

7.
9

ObjectOntology.owl

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

78

7.9.1

Classes Introduced in ObjectOntology.owl

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

78

7.10

ObligationOntology.owl

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

79

7.11

PaymentSourceOntology.owl

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

80

7.12

PermissionOntology.owl

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

82

7.13

PrivacyOperationOntology.owl

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

84

7.14

PurposeOfUseOntology.owl
................................
................................
................................
........

84

7.15

RBACOntology.owl

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

86

7.15.1

Classes Introduced in RBACOntology.owl

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

86

7.15.2

Classes Imported and Restricted in RBACOntology.owl

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

89

7.16

RefrainOntology.owl

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

91

7.17

RoleOntology.owl

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

92

7.18

R
outeOntology.owl

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

93

7.19

SensitivityOntology.owl

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

93

7.20

ServiceDeliveryLocationOntology.owl

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

94

7.21

SomewhereHospitalOntology.owl

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

98

7.21.1

Policy Examples

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

98

7.21.2

RBAC Examples
................................
................................
................................
....................

99

8

References

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

100

Appendix A.

SWRL Rules

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

103

Page
6

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


A.1
Static Separation of Duty Constraint Violation

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

103

A.2 Well
-
Formed RBAC Request

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

103

A.3 Inferring Access Control Information from Clinical Information

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

104

Appendix B.

Ontology Based Access Control Decisions

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

105

Appendix C.

Glossary of Terms

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

106

Appendix D.

Presentation of OWL CLass Expressions

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

108

Appendix E.

OWL Software

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

111

Appendix F.

Suggested Review Criteria

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

112

Introduction

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

112

Overall Considerations

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

112

Overall HL7 RBAC Representation

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

112

Hierarchy of Ontologies
................................
................................
................................
.........................

113

Each Ontology

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

113

Class Hierarch
y

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

114

Each Class

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

114

Property Hierarchy

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

115

Each Property

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

115

Each Annotatio
n

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

116

Individuals (Examples)

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

116

Each Individual

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

116

Miscellaneous

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

117



Page
7

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


FIGURE
S

Figure 1


An Architectural Approach to Ontology Systems

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

20

Figure 2
-

Hierarchy of Sub
-
Ontologies

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

35

Figure 3
-

Asserted Class Hierarchy (left) and Inferred Class Hierarchy (right) in
SecurityAndPrivacyOntology.owl

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

38

Figure 4
-

Object Properties introduced in SecurityAndPrivacyOntology.owl, ObjectOntology.owl and
RBACOntology.owl

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

41

Figure 5
-

Object Properties Connecting Selected Classes within the base
SecurityAndPrivacyOntology

.

41

Figure 6
-

Data Properties introduced in SecurityAndPrivacyOntology.owl

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

43

Figure

7
-

Selected Example Individuals in SomewhereHospitalOntology.owl

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

99

Figure 8
-

Selected Classes Corresponding to Individuals in
Figure 7

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

99



Page
8

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


1

PREFACE

1.1

Publication

This document

describes

the HL7
Security and Privacy Ontology
.

The ontology is
represented
via

OWL 2,
the

current version of the

Web Ontology Language

(1)
. The ontology

is

composed of several sub
-
ontologies
, each

delivered in
a
corresponding

“.owl”
file
using

the XML Serialization syntax
(2)
.

The
O
WL

representation

embodied in that

set of files

can be visualized

using
several types of tools,
including a
n
OWL
editor, a
n OWL

browser, or static HTML pages generated
from the ontology
.


As a convenienc
e for reviewers of this specification
, the Ontology Browser
(3)

software
is currently
hosted along with the HL7 Security and Privacy Ontology content and
is
available for browsing as
described on the HL7 Wiki page for the Security and Privacy Ontology:

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


More specifically, i
nstructions for using these hoste
d resources are detailed in the Hosted Browsing
section of that

W
iki page:


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

Hosting will continue for a limited time with support on an
“as available” basis.

1.2

Notes to Readers

Readers

of this edition are advised that:



This document is primary; the formal OWL representation of the ontology is secondary in the
sense that this
document
will prevail

in case of
inadvertent
conflict
.

Nonetheless, the intent is
to produce a single shared ontology for use across the HL7 constituency.



While this document
serves

to
introduce, motivate and explain

the ontology, the inherent
l
imitations of l
ine
ar
text

make it impossible to fully c
onvey the

richly interconnected, formal
logic
-
based

nature of the ontology itself.



A suitable
OWL
2
editor or
browser

for visualization
,

with the benefit

of
an
integrated
OWL 2

reasoner, is indispensable for navigating the structure of the ontology and

also

for
a
ppreciating
the lo
gical
consequences

of the expl
icit assertions

made in the
ontology.

For more information
on OWL software, refer to

Appendix E.




Any HL7 Security and Privacy
Ont
ology elements
derived from HL7 v
ocabu
lary artifacts are
intended to reflect the

most recently

harmonized version of
HL7 v3 Vocabulary as of this
writing. Spe
cifically, they are intended to be

consistent with

the content of this file:

http://gforge.hl7.org/gf/download/frsrelease/976/10265/hl7_rimRepos
-
2.42.1.zip

Page
9

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013




In th
is specification, the source of a class is specified as "de novo" in rare cases when that class is
not based on another
specification
. Similarly, the definition of a class is specified as "de novo"
when that definition is no
t based on an external source.



T
he core
of the HL7 Security and Privacy Ontology

is
based primarily on the
HL7
Composite
Security and Privacy Domain Analysis Model
(7)

and can thus be considered a domain ontology
as described in the literature
(5)
. The core
is

used to further derive application ontologies, for
example by introducing sub
-
ontologies based on HL7 vocabularies, etc.

1.3

Future Directions

Here is a partial list of possible future steps for the Security and

Privacy Ontology:



Integration with an

upper ontology could facilitate integration wit
h ontologies of other domains.



Integration with an
ontology
of Service Oriented Architecture (SOA)
could facilitate applicat
ions
based on such an

architecture.



While outs
ide the stated scope of the
HL7
Security and Privacy Ontology project chartered by
HL7, interest
was expressed in

aligning the ontology with existing digital rights management
standards such as ISO/IEC 21000
-
19: MPEG
-
21 Media Value Chain Ontology (MVCO).



L
imited effort has been made to map RBAC objects to external healthcare terminology
standards
,

such as
document types represented in
LOINC and
record types represented in
SNO
MED CT
, with limited success. Those mappings could be pursued.



The operation
classes could be organized in a class hierarchy.

1.4

Disclaimers

Examples
in this document and/or the ontology
are not
normative

unless explicitly
stated otherwise.

1.5

Key Words

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD

NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF
RFC 2119.

(4)


1.6

Conformance

Expectations of a conformant application of the HL7 Security and Privacy Ontology:

1.

A conformant

application MAY use other existing standards such as SAML or XACML.

2.

A conformant security and privacy policy authoring and management system
MAY

encode policy
rules, jurisdictional and organizational policies, and consent directive forms and instances by
invoking HL7 Security and Privacy Ontology terminology services
; it SHALL do so in a manner
logically consistent with
the Security and Privacy Ontology,
including

all pertinent policies and
consent directives as (if they were) represented according to the
Security and Privacy Ontology.

Page
10

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


3.

A conformant security labeling service
MAY

assign privacy and security metadata in accordance
with policy by invoking HL7 Security and Privacy Ontology terminology services
; it SHALL do so in
a manner logically consistent wi
th
the Security and Privacy Ontology,
including

all pertinent
policies and consent directives as (if they were) represented according to the Security and
Privacy Ontology
.

4.

A conformant clinical data repository
MAY

persist, manage, and retrieve privacy and

security
metadata in accordance with policy by invoking HL7 Security and Privacy Ontology terminology
services
; it SHALL do so in a manner logically consistent with
the Security and Privacy Ontology,
including

all pertinent policies and consent directives

as (if they were) represented according to
the Security and Privacy Ontology
.

5.

A conformant access control system SHALL rely on the
HL7 Security and Privacy Ontology
for
the
definition
s and relationships

of the terms and concepts that are necessary for mak
ing access
control decisions.

(Note that the
HL7 RBAC Healthcare Permission Catalog

is authoritative for
definitions of terms and concepts specified therein
; the

HL7 Security and Privacy Ontology
reproduces those definitions verbatim, defines
additional
terms and concepts, and adds
relationships, especially hierarchical relationships among concepts.
)
This conformance criterion

MAY encompass all access control system

components, inclu
ding the following:

a.

A conformant access control system policy administra
tion point
MAY

invoke HL7
Security and Privacy Ontology terminology services to support
encoding and
retrieval of
applicable policies
; it SHALL do so in a manner logically consistent with
the Security and
Privacy Ontology,
including

all pertinent policies
and consent directives as (if they were)
represented according to the Security and Privacy Ontology
.

b.

A conformant access control system policy information point
MAY

invoke HL7 Security
and Privacy Ontology terminology services to support retrieval of appli
cable initiator,
resource, context, and request access control decision information
needed

to generate
an access control decision
; it SHALL do so in a manner logically consistent with
the
Security and Privacy Ontology,
including

all pertinent policies and
consent directives as
(if they were) represented according to the Security and Privacy Ontology
.

c.

A conformant access control system policy decision point
MAY

invoke HL7 Security and
Privacy Ontology terminology services to support access control decisions
;

it SHALL do
so in a manner logically consistent with
the Security and Privacy Ontology,
including

all
pertinent policies and consent directives as (if they were) represented according to the
Security and Privacy Ontology
.


d.


A conformant access control sy
stem policy enforcement point
MAY

invoke HL7 Security
and Privacy Ontology terminology services to support access control enforcement within
the custodian enterprise, in transit and in intermediary systems, and in end user clients
;
it SHALL do so in a mann
er logically consistent with
the Security and Privacy Ontology,
Page
11

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


including

all pertinent policies and consent directives as (if they were) represented
according to the Security and Privacy Ontology
.

6.

HL7 Security and Privacy Ontology terminology services SHO
ULD be invoked by means of HL7
Common Terminology Services

2 (CTS2)

(5)
, or another suitable service implementation for
accessing the ontology content, such as a service supporting the OWL API
(
http://owlapi.sourceforge.net/
).


7.

HL7 Security and Privacy Ontology terminology services SHALL either be invoked directly, e.g.,
while making access control decisions, or used to develop an equivalent optimized
solution.

1.7

Const
raints

In accord with OWL, the
normative core SecurityAndPrivacyOntology can be extended, e.g., by
importing it into a new a new ontology then introducing additional classes and/or restrictions, but
relationships among existing classes canno
t be contradicted. A
s described in Section
7.1
, several sub
-
ontologies can also be replaced, in which case the replacement sub
-
ontology could effectively rearrang
e
the original.

OWL is designed to facilitate specification of additional restrictions (constraints) on existing
ontologies with fully consistent results. Therefore, HL7 Security and Privacy Ontology user communities,
such as national realms, MAY do so as
desired in accord with other conformance statements in this
specification.

In particular, future OWL ontologies can
import

the
core
Security and Privacy Ontology.
They
can

then specify additional entities, including additional classes and properties, as well as
additional restrictions on imported entities,
as long as the resulting ontologies are not inconsistent (in
purely logical
ways that an OWL reasoner can detect, but a
lso in ways that require human
understanding, e.g., how the Engli
sh names of OWL entities relate

to real world entities consistent with
our language skills

and world knowledge
). Likewise,
elements of
the user community
MAY

restrict an
y or
all of the relate
d sub
-
ontologies presented in this document. In addition, as long as the related sub
-
ontology is not normative, that sub
-
ontology
MAY

be replaced altogether.

1.8

SAIF Alignment

Alignment with the HL7 Services
-
Aware Interoperability Framework, known as SAIF
(6)
, was articulated
as a goal in the
HL7
Security and Privacy Ontology project scope statement. A well developed, standard
Security and Privacy Ontology will provide standard names, definitions and common semantics for
important
concepts shared across the field of healthcare IT security and privacy. Thus, it can be a
valuable shared
information resource

that strongly promotes reuse and interoperability of related
services. HL7 SAIF is focused on best practices for specifying in
teroperable services. So, the Security
and Privacy Ontology is well aligned with SAIF objectives in principle. To be sure, HL7 SAIF today does
not articulate any specific criteria for ontologies or their use. Nonetheless, in keeping with the goals of
Page
12

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


SA
IF, we ensure that traceability

of ontology classes

to the
Composite Security and Privacy Domain
Analysis Model

(CSP
-
DAM)

(7)

and other sources is documented in this specification and
also
recorded in
the ontology itself
by
means of annotation properties.
1

When and if HL7 SAIF begins to encompass
ontology
-
specific criteria, it will, of course, be important to ensure continued alignment as
needed
.

1.9

Acknowledgements

In addition to the listed contributors, the following
individuals are acknowledged for their contributions
during the development of this specification:



Security work group co
-
chair, Mike Davis, whose vision, guidance, and leadership have been
essential for moving this project forward.



Written reviews of ea
rlier drafts were provided by Jon Farmer, Cliff Thompson, and jointly by
Jaime Delgado, Eva Rodríguez, and Víctor Rodríguez.



Jon Farmer converted tabular data from the HL7 RBAC Healthcare Permission Catalog to OWL
format.




Martin Rose converted tabular
data from the VHA Structural Role Catalog to OWL format for an
earlier version of the ontology.



Jaime Delgado, Eva Rodríguez, and Víctor Rodríguez developed an alignment with ISO/IEC
21000
-
19: MPEG
-
21 Media Value Chain Ontology (MVCO).



Cecil Lynch prov
ided insight on alignment with the HL7
Services
-
Aware Interoperability
Framework (SAIF)
.



Steve Connolly led prior specification of use cases.

Co
-
chairs and members of the Security and Community
-
Based Collaborative Care (CBCC) work groups
contributed to

review and discussion during weekly teleconferences.

1.10

Ballot Statement of Scope

During May 2013 balloting, the HL7 Security and Privacy Ontology specification achieved quorum and
received sufficient votes for approval. However, substantive changes were ma
de in response to ba
llot
comments and other input, so

the specification is being re
-
balloted. The scope of re
-
balloting is
confined to substantive changes. The following table summarizes substantive changes since the last
balloted version.







1

This has been done using
source

annotations within the ontology itself.

Page
13

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


Section
No.

Section
Heading

Substantive Change(s)

1.6

Conformance



Added Clause 1



Modified Clauses 2, 3, 4, 5a, 5b, 5c and 5d by
changing SH
ALL to MAY and appending “; it
SHALL do so in a manner logically consistent
with
the Security and Privacy Ontology,
including

all pertinent policies and consent
directives as (if they were) represented
according to the Security and Privacy
Ontology.”



Rewor
ded Clause 7 as agreed during ballot
reconciliation

1.7

Const
raints



Clarified wording of conformance statement
that user communities, such as national
realms, MAY restrict (constrain) the ontology
in accord with OWL.

6.3.2

Ontology Naming

and Versioning



Updated lists of ontology files and IRIs in
acc
ord with revised hierarchy of sub
-
ontologies (see changes for Section
7.1
)



Added versioning of sub
-
ontologies

6.5

Design P
at
terns



Added CompartmentOntology.owl and
PaymentSourceOntology.owl to the table of
sub
-
ontologies derived from HL7 v3 value
sets

7.1

Hierarchy

of
Sub
-
Ontologies



Added CompartmentOntology



Generalized ClinicalConditionOntology to
ClinicalOb
servationOntology



Split OperationOntology into
DataOperationOntology and
PrivacyOperationOntology



Reorganized Permissions

o

Moved Permission class to
RBACOntology from PermissionOntology
(which is thus limited to example
permissions from the HL7 RBAC
Healthc
are Permission catalog and can
now be replaced accordingly)

o

Moved RBACOntology from below to
above PermissionOntology



Revised
Figure
2

to reflect the preceding
changes



Defined notions of
extensible
,
replaceable
,
and
dynamic

sub
-
ontologies



Added table indicating whether each sub
-
ontology is extensible, replaceable, and/or
dynamic

Page
14

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


Section
No.

Section
Heading

Substantive Change(s)

7.2.2

Class Hierarchies in
SecurityAndPrivacyOntology.owl



Updated
Figure
3
:

o

Moved ServiceDeliveryLocation under
Location

o

Changed color coding of Permission
class, per changes in
Section
7.1

7.2.3

Object

Properties in
SecurityAndPrivacyOntology.owl



Updated
Figure
4
:

o

Now using blue color coding for
ObjectOntology and instead of
PermissionOntology

o

Added object properties:
basedOnPrivacyPolicy,
belongsToHealthRecord,
hasCompartment

o

Renamed
hasClinicalCondition to
hasClinicalObservation, and similarly
renamed its range from
ClinicalCondition to ClinicalObservation

o

Refined domain of constrains property

o

Generalized range of hasSubject
property in accord with ballot
reconciliation

o

Changed color

coding of Permission
class, per changes in
Section
7.1

7.2.4

Data Properties in
SecurityAndPrivacyOntology.owl



Added hasWrittenSignatureRecorded
property



Removed isEnabled property in fa
vor of
using OWL logical negation per ballot
reconciliation

7.2.5.3

Compartment



New section

7.2.5.2

ClinicalObservation



Generalized and renamed ClinicalCondition
as ClinicalObservation

7.2.5.5.1

SeparationOfDutyConstraint



Converted from superclasses to equivalent
class

7.2.5.8

InformationReference



Replaced hasClinicalCondition restriction
with hasClinicalObservation



Added hasCompartment restriction



Added hasSubject restriction

7.2.5.12.1

ServiceDeliveryLocation



Regularized text definition by prefixing it
with “A service delivery location is …”



Added
Location as superclass

7.2.5.15.1

DataOperation



Specified that additional subclasses are
specified in DataOperationOntology.owl
(since OperationOntology.owl was split into
DataOperationOntology.owl and
PrivacyOperationOntology.owl)

Page
15

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


Section
No.

Section
Heading

Substantive Change(s)

7.2.5.15.2

PrivacyOperation



Specified that additi
onal subclasses are
specified in PrivacyOperationOntology.owl
(since OperationOntology.owl was split into
DataOperationOntology.owl and
PrivacyOperationOntology.owl)

7.
2.5.20

Consenter



Added hasWrittenSignatureRecorded
restriction

7.2.5.21

Policy



Removed isEnabled property in favor of
using OWL logical negation per ballot
re
conciliation

7.2.5.21.1

PrivacyPolicy



Added specifiesGrantee restriction

7.2.5.21.2

SecurityPolicy



Added second definition from
ISO/IEC
10746
-
3

7.2.5.21.3

BasicSecurit
yPolicy



Noted that this class is abstract (per ballot
reconciliation in accord with CSP
-
DAM)

7.2.5.21.4

CompositeSecurityPolicy



Added maximum cardinality restrictions on
types of composed security policies

7.2.5.23

PrivacyConsentDirective



Added basedOnPrivacyPolicy restriction



Removed isEnabled property in favor of
using OWL logical negation per ballot
reconciliation

7.2.5.24

PrivacyRule



Removed isEnabled property in favor of
using OWL logical negation per ballot
reconciliation

7.2.6

Disjoint Classes Axioms in
SecurityAndPrivacyOntology.owl



Updated list of top level primitives in accord
with revised class hierarchy



Added sentence: “In addition, the classes
defined as specializations of
BasicSecurityPolicy

are declared mutually
disjoint, namely
AuthorizationPolicy
,
ConstraintPolicy
,
DelegationPolicy
,
ObligationPolicy

and
RefrainPolicy
.”

7.3

ClinicalObservation
Ontology
.owl



Generalized from clinical conditions to
clinical observations, which may also include
medications, procedures, etc., and added
examples accordingly

7.4

Compartment
Ontology.owl



New section

7.5

ConfidentialityOntology.owl



Changed from dynamic to static stability per
Security WG discussion

7.6

CRUDEA_OperationOntology.owl



Made Append a sibling rather than child of
Update because

of Security WG decision to
defer operation class hierarchy



Disjointness declaration added



Modified conformance statements to
account for split of OperationOntology into
DataOperationOntology and
PrivacyOperationOntology

Page
16

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


Section
No.

Section
Heading

Substantive Change(s)

7.7

Data
OperationOntology.owl



DataOperationOntology.owl, along with
Privacy
OperationOntology, owl is split out of
OperationOntology.owl (which no longer
exists)



All children of DataOperation are now
siblings because of Security WG decision to
defer operation class hierarchy



Disjointness declaration added



Modified conformance statements to
account for split of OperationOntology into
DataOperationOntology and
PrivacyOperationOntology

7.9.1.1

RecordObject



Added belongsToHealthRecord restriction

7.11

PaymentSourceOntology



Example content replaced with content of
HL7 ActCoverageTypeCode value set

7.12

PermissionOntology.owl



Moved RBACOntology from below to above
PermissionOntology



Moved Permission class from
PermissionOntology to RBACOntology

7.13

Privacy
OperationOntology.owl



PrivacyOp
erationOntology.owl, along with
DataOperationOntology, owl is split out of
OperationOntology.owl (which no longer
exists)



Disjointness declaration added



Modified conformance statements to
account for split of OperationOntology into
DataOperationOntology
and
PrivacyOperationOntology

7.15

RBACOntology.owl



Moved RBACOntology from below to above
PermissionOntology



Moved Permission class from
PermissionOntology to RBACOntology




Page
17

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


2

INTRODUCTION

The HL7 Security and Privacy Ontology

serves to name, define
,
formally describe
,

and
interrelate

key
security and privacy concepts within the scope of Healthcare Information Technology (
Healthcare IT
).

S
ubsequent

sections of this document point out relevant background
material, highlight
the ontology’s

scope, objectives
,

and use cases
, then introdu
ce our modeling approach. Section
7

covers the ontology
itself.

R
eferences

follow in Section
8
.
Examples of
Semantic Web Rule Language (SWRL) rules are
covered in
Appendix A.

Ontology
-
based access control decisions are covered in
Appendix B.

A glossary
of

terms appears in
Appendix C.

A br
ief introduction to the presentation of OWL class expressions used
in this document is given in
Appendix D.

OWL software used to develop and test the ontology is
documented in
Appendix E.

Suggested review criteria

for the ontology (
as opposed to this document
)

are provided in
Appendix F.


Page
18

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


3

BACK
GROUND


T
his section briefly introduces

important background subjects necessary to understand the Sec
urity and
Privacy Ontology. This section
is
not

intended to provide sufficient backgrou
nd
knowledge
by itself.

Instead,
consult
the cited

references

for
further details

as
needed
.

3.1

Composite Security and Privacy Domain Analysis Model

T
he
Composite Security and Privacy Domain Analysis Model (CSP
-
DAM)

is the

key fo
undation for the
Security and Privacy Ontology, and the basis for the domain it covers.
While

the CSP
-
DAM was
represented using

the Unified Modeling Language (UML)
, the Security and Privacy Ontology is
represented using OWL

(see
3.7

below
)
.

Although UML and OWL have superficially related constructs,
e.g., both make significant us
e of
“classes”,

and those constructs do have similarities, readers familiar
with UML will to understand how they differ

as well
.

3.2

Role
-
Based Access Control

Role
-
Based Access Control (RBAC) is a flexible and popular
security
mechanism for
restricting
informa
tion system access to authorized users
. I
n particular
,

RBAC decides

whether
specific
users

can

be allowed

to perform

specific

operations

(i.e.,
act
ions)

on

specific

ob
jects

within the context of a

specific

session
.

To facilitat
e administration as well as

run
time access control, each user is assigned a set
of
role(s).
Each role, in turn,

is assigned

permission
(s) to
perform certain types of operations on certain
types of objects.

Different kinds of
constraints
can

further restrict the administrative assignment of
users to roles (e.g., to enforce static separation of duties) or the runtime
activation

of roles within
sessions (e.g.
,

to enforce dynamic separation of duties). The standard

RBAC reference is
ANSI/NCITS
359
-
2004
, the
American National Standard for Information Technology
-

Role Based Access Control

(8)
.

HL7 specifications have also referenced the work of Neumann and Strembeck
(9)
.

3.3

HL7 RBAC

Healthca
re Permission Catalog

T
he HL7 RBAC Healthcare Permission Catalog

(10)

is a normative part of the HL7 Version 3 standard.
To
fa
cilitate interoperability within

Healthcare IT, the catalog
standardizes names, identifiers and
definitions of
types of
RBAC
operations and
objects

(both record and workflow objects)
. The catalog
includes an appendix which lists “non
-
normative examples of ‘Standard’

Healthcare
permissions.


Those operations, obje
cts and permissions are

now

adopted

in
this specification
.

3.4

Ontologies

For our purposes,

the notion of

ontology

is adequately

defined
by Gruber
as follows

(11)
:

In the context of computer and information sciences, an ontology defines a set of
representational primitives with which to model a domain of knowledge or discourse. The
representational primitives are typically classes (or sets), attributes (or properties
), and
Page
19

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


relationships (or relations among class members). The definitions of the representational
primitives include information about their meaning and constraints on their logically consistent
application. In the context of database systems, ontology can
be viewed as a level of abstraction
of data models, analogous to hierarchical and relational models, but intended for modeling
knowledge about individuals, their attributes, and their relationships to other individuals.
Ontologies are typically specified i
n languages that allow abstraction away from data structures
and implementation strategies; in practice, the languages of ontologies are closer in expressive
power to first
-
order logic than languages used to model databases. For this reason, ontologies are

said to be at the "semantic" level, whereas database schema are models of data at the "logical" or
"physical" level. Due to their independence from lower level data models, ontologies are used for
integrating heterogeneous databases, enabling interoperabi
lity among disparate systems, and
specifying interfaces to independent, knowledge
-
based services. In the technology stack of the
Semantic Web standards, ontologies are called out as an explicit layer. There are now standard
languages and a variety of comme
rcial and open source tools for creating and working with
ontologies.

3.5

Types of Ontologies

The ontology literature describes different types of ontologies. Guarino
presented

top
-
level (upper
level), domain, task, and application ontologies
(5)
.
Blobel articulated a comprehensive Generic
Component Model (GCM) approach to systems
architecture as
illustrated in
Figure
1
,
with g
eneral, top
-
level, domain, application, and ICT (Information and Communication) ontologies

(13)
.
Our

core sub
-
ontology

presented in Section
7.2

can be considered a domain ontology covering the security and
privacy domains generally in correspondence to the CSP
-
DAM, and it can be used to further derive
application

ontologies. For exa
mple, our RBAC sub
-
ontology, presented in Section
7.15
, can thus be
seen as an application ontology.

Page
20

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013



Figure
1



An Architectural Approach

to Ontology Systems

3.6

Description Logic
s

Description Logic
s

comprise

a branch of
formal logic within the field of
knowledge representation
and
reasoning.
A description logic

focuses on describing
concepts

and
their instances, called individuals
, and
effectively reasoning about (i.e., drawing inferences from) those descriptions.
Each concept
ought to

represent
a distinct idea and denote

a set of possible individuals.


For example,
a description logic

can
describe an
Organization

concept

and inst
ances
of that concept
such as

(the fictitious)

Somewhere
Hospital
.
Description Logics enable

precise,

unambiguous
logical
description

of a concept’s intrinsic
attributes as well as its relationships with other concepts. A given
concept

(for example, repr
esenting a
set

of
organizations
) can be described succinctly by naming the
concepts

it specializes (
for example,
more general
sets

of
organizations
) and introducing its distinguishing characteristics.
Using a description
logic

reasoner, or inference engine, c
haracteristics of those more general concepts are
inherited

by
(i.e.,
inferred to be true of)
the more specific concept being described.
The logical consistency of an entire
set of
concepts

(such as our Security and Privac
y Ontology
) is automatically tested and enforced.
Moreover, logical consequences that are implicit in the given descriptions are made explicit.

The
classification
operation automatically organizes a set of previously unorganized
concepts

into a
n
inferred

taxonomy based on their logical descriptions. Each concept in the taxonomy is guaranteed to
be more specific than its parents (and other ancestors) as well as more general than its children (and
other descendants).

The Description Logic Handbook

is a d
efinitive reference
(12)
.


Readers

unfamiliar with formal logic
might

be surprised by
some of the
ways
that

description logics such
as OWL differ from other systems such as rela
tional databases.
Description logics

do not make a

Closed World Assumption


(CWA) that all relevant individuals are known.
Rather
, they assume that
Page
21

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


there
could

be any number of unknown instances of a class such as
Organization.
Also, they do not
make the


Unique Name Assumption


(UNA) tha
t different names always refer to different individuals.

Indeed,
HL7
and
Health Level 7 International

are different names for the same individual organiz
ation.
On the other hand,
World Wide Web Consortium

(W3C)

names a different organization.
Descriptio
n
logic

reasoners can sometimes infer that individuals are different based on their descriptions.
Additionally
,
using
description logic
,
one can expli
citly indicate that names such
HL7
and
W3C

refer to
different
individuals

or that multiple names refer to the same individual.

3.7

OWL


The Security and Privacy Ontology is represented via OWL 2, the most recent version of the Web
Ontology Language

known as OWL
.
OWL is the de facto standard language for formal, logic
-
based
ontol
ogies. It

is a W3C Recommendation
intended to support the emerging Semantic Web
(1)
.
Thus, it
features XML syntax and
uses Internationalized

Resource Identifiers (IRIs) to
name

ontolog
ies and their
constituent

entities
.
2

OW
L is based on description logics. We are
specifically using
a

subset of the full
OWL language which has been carefully
limited

to ensure decidable
reasoning

over OWL ontologies.

Note:

OWL refers to description logic concepts as
classes
.

OWL

properties include
object properties
, which describe relationships to individuals, and
data
properties
, which describe relationships to literals. In addition,
a
nnotation properties

(or just
annotations

for short)

can be used to express
arbitrary
metadata
about the ontology and its
constituents,
such as

authorship, provenance
, textual descriptions

and other comments.


In OWL 2,
punning
is the notion that
an IRI
can

denote different types of entities, e.g., both an individual
and a class, at the same

time. The semantics of punning, which has

certain

limitations,
are

discussed in
OWL 2 Web Ontology Language New Features and Rationale (Second Edition)
(13)
. Our usage of
punning is introduced in Section
6.5

below
.

For programmatic access to OWL 2 ontologies, the
aforementioned
OWL API is an open
-
source Java API

supported by leading
contemporary
OWL

2

reasoners.

3.8

SWRL

T
he S
emantic Web Rule Language

-

SW
RL

(14)
,

supp
lements
OWL with
expressive and convenient logical
inference rules.
A SWRL rule

refer
s

to an OWL ontology. In essence, OWL classes are unary predicates,
OWL properties are binary predicates, and OWL individuals are constants.

Although SWRL is
undecidable in general, we are able to make effective use of decidable

subsets, specifically the
“DL S
afe”




2


Classes, datatypes, object properties, data properties, annotation properties, and named individuals
are entities, and they are all

uniquely identified by an IRI.”

(20)

Page
22

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


(Description Logic Safe)
subset
of SWRL
supported

by contemporary
description logic

reasoners
. As
examples, w
e
can use
SWRL to
help enforce separation of duty constraints and to
validate ontology
-
based requests for access control decisions.

Som
e examples
of SWRL rules demonstrated with the
Security and Privacy Ontology
are given in
Appendix A.


Page
23

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


4

SCOPE

AND OBJECTIVES

This ont
ology
is meant
to

focus

on
the
security and privacy aspects of
Healthcare

IT
.

It is intended to
support descriptions of security policies, privacy policies, consent directives, resulting access control,
and related
ideas
.

Thus,
the core
ontology

starts with domain conc
epts from the foundational CSP
-
DAM. Other sub
-
ontologies
are derived from the core for application purposes
,
based on
sources such
as
HL7 vocabulary,
t
he HL7 RBAC H
ealthcare Permission Catalog
, and
t
he HL7 Healthcare Privacy and
Security Classification Sy
stem (HCS
).

The

HL7

Security and Privacy Ontology

addresses

several key objectives
:




Identif
y important

concepts

in the area of H
ealthcare
IT security and privacy.



Establish

s
tandardized names for
concepts

in the area of Healthcare IT security and privacy.



Give clear, precise
textual definitions

to
concepts
in the area of Healthcare IT security and
privacy
.




Constitute

an authoritative ontology, with concepts

that are
:

o

F
ormally
and unambiguously
defined

(
to the extent
practical)

using
OWL
.

o

C
lassified in a well
-
organized taxonomy

(class hierarchy)
.

o

O
therwise connected in

meaningful and useful ways.

o

M
utually

consistent
.



Support
consistent and effective H
ealthcare
IT

software

implementations
, especially

by

en
abling
security/privacy systems
, thus:

o

Providing

a sound basis for convenient, i
nteroperable specification of e
-
Policies and e
-
D
irectives
,
which
:



Are

e
xpressed at
suitable

levels of abstraction

(thus appropriate and stable over
time).



Can be rigorously
checked for coherence, compared, and combined if possible.

o

Achieving

sound

access control decisions
.



Inform other work of the HL7 Security and CBCC Work Groups, such as the
Composite Security
and Privacy Domain Analysis Model

(7)
.



Align

with
:


o

T
he HL7 Service
-
Aware Interoperability Framework (
SAIF
)
.

o

T
he HL7 RBAC H
ealthcare Permission Catalog.

o

T
he HL7 Healthcare Privacy and Security Class
ification System (HCS)

(17)
.

o

O
ther

H
ealthcare
IT

terminologies

such as

SNOMED

CT

and
the
HL7 vocabularies
, as
appropriate.
3





3

In fact, the ontology can serve as a unified framework showing how disparate HL7 vocabulary artifacts
in the area of security and privacy work together (or potentially do not); indeed it could serve as a
unified basis for
authoring those artifacts.

Page
24

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013



By offering a
rich, shared
, software
-
processable

vocabulary for access control and
privacy protec
tion
,

the Security and Privacy Ontology
seeks to

promote interoperability
and reuse
across organ
izations and
across
applications
.


Page
25

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


5

USE C
ASES

Several use cases for the

Security and Privacy Ontology
were drafted, reviewed in joint meetings of the
Security and CBCC work groups, and then published
on
the
HL7
Wiki:



Access Control Based on Category of Action




Access Control Based on Category of Object




Access Control Based on Category of Structural Role




Access Control Based on Category of Functional Role




Access Control Based on Multiple Role Values




Enable Design of Access Control System




Facilitate an Automated Decision Function


Note: the preceding use case na
mes are hyperlinked to the corresponding use case write
-
ups.


Page
26

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


6

MODELING
A
PPROACH

The
modeling approach includes use of the OWL 2 language, an agreed set of references,
collection
s

of
naming, versioning
and modeling conventions, design patterns, and metadata

annotations
.

6.1

Language

The Security and Privacy Ontology is represented via
OWL 2

(1)
.

We use OWL to define a taxonomy, or
generalization hierarchy, of classes
along with

individuals (instances of classes)
. Other pertinent l
ogical
relationships are captured via properties. Restrictions on properties constrain the instances of a class.
Property assertions connect related individuals.

6.2

P
recedence of
S
ources

The following sources have been consulted, especially for naming
purposes, in the following default
order of precedence:

1.

ISO/TS 22600
:

Health informatics


Privileg
e management and access control

(15)

(16)

(17)

2.

ISO/TS 21298: Health i
nformatics


Functional and structural roles
(18)

3.

HL7

Composite Security and Privacy Domain Analysis Model

(7)

4.

HL7 Version 3 Standard: Role
-
Based Access Control Healthcare Permission Catalog,
Release 2

(10)


5.

HL7
v3
Vocabulary

6.

American National Standard for Information Technology
-

Role Based Access Control

(8)

6.3

Naming C
onventions

Clear, concise, consistent, context
-
independent names
facilitate readability.

Several variations of
“camel case” naming are used
, as detailed
below

in Sections
6.3.2

through
6.3.5
.

In
upper camel case
,
each word begins with a capital letter

and words are concatenated without intervening spaces or special
characters.

In
lower camel case
,
the first word begins with a lowercase letter and any subsequent words
begin with capital letters,
again
without intervening spaces or special characters.

For example,
the
“PrivacyConsentDirective”

class name

is in upper camel case while

the

“hasPrivacyRule”

property name

is in lower camel case.

The use of lowerCamelCase visually distinguishes p
roperty names.

6.3.1

Internationalized Resource Identifiers

All OWL e
ntities are named with

International
ized Resource Identifiers, or IRIs

(19)
.
4

For
brevity
, we will
omit namespace prefixes

in this document
.

However, t
he OWL representation reflected in the




4

IRIs generalize the notion of URIs (Uniform Resource Identifiers).

Page
27

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


accompanying “.owl” files does
include prefixes
. T
he
HL7

domain

name is used for

the Security and
Privacy Ontology and i
ts constituents, specifically under

hl7.org/ontolog
y
.
5

6.3.2

Ontology Naming

and Versioning

Each sub
-
ontology is named in accord
ance

with the corresponding
text
file,
specifically

in
upper camel
case
suffixed with the word “Ontology” to avoid potential confusion with class names and
with the

“.
owl” extension. Currently, the files

are:



ClinicalObservation
Ontology
.owl




Compartment
Ontology.owl




ConfidentialityOntology.owl



CRUDEA_OperationOntology.owl




Data
OperationOntology.owl



IntegrityOntology.owl



ObjectOntology.owl



ObligationOntology.owl



PaymentSourceOntology.owl



PermissionOntology.owl




Privacy
OperationOntology.owl



PurposeOfUseOntology.owl



RBACOntology.owl



Refrain
Ontology
.owl



RoleOntology.owl



Route
Ontology
.owl



SecurityAndPrivacyOntology.owl



SensitivityOntology.owl




ServiceDeliveryLocationOntology.owl



SomewhereHospitalOntology.owl

Thus, the corresponding ontology IRIs are:



http://hl7.org/ontology/
ClinicalObservation
Ontology
.
owl



http://hl7.org/ontology/
Compartment
Ontology.owl



http://hl7.org/ontology/ConfidentialityOntology.owl



http://hl7.org/ontology/
CRUDEA_
OperationOntology.owl



http://hl7.org/ontology/
Data
OperationOntology.owl





5

This is compatible with the approach of the recently proposed HL7
Project on

OWL representation of
HL7 v3 Artifacts
; however, HL7
-
wide policy on
these IRIs

has not yet been adopted
.

Page
28

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013




http://hl7.org/ontology/Integrity
Ontology.owl



http://hl7.org/ontology/
ObjectOntology.owl



http://hl7.org/ontology/
ObligationOntology.owl



http://hl7.org/ontology/PaymentSourceOntology.owl



http://hl7.org/ontology/
PermissionOntology.owl




http://hl7.org/ontology/
Privacy
OperationOntology.owl



ht
tp://hl7.org/ontology/
PurposeOfUseOntology.owl



http://hl7.org/ontology/
RBACOntology.owl




http://hl7.org/ontology/
RefrainOntology.owl



http://hl7.org/ontology/
RoleOntology.owl



http://hl7.org/ontology/
RouteOntology.owl



http://hl7.org/ontology/SecurityAndPrivacyOntology.owl



http://hl7.org/ontology/
SensitivityOntology.owl




http://hl7.org/ontology/
ServiceDeliveryLocationOntology.owl



http://hl7.org/ontology/SomewhereHospitalOntology.owl

The first HL7
-
approved version of this

specification will be identified as version 1.0.0. Therefore, each
of
the preceding sub
-
ontologies

will

also

have a version IRI consisting of its ontology IRI followed by
“/1.0.0”
, for example
:

http://hl7.org/ontology/SecurityAndPrivacyOntology.owl/1.0.0

For any future versions of this specification, ontology IRIs and version IRIs will be managed in accord
with the OWL 2 specification
(20)
.

6.3.3

Class Naming

In OWL, the
built
-
in
root class is named
Thing
.
Our

classes
are named
using

u
pper

camel c
ase
.

Examples
include
Permission

and
PermissionCatalog.

However, classes corresponding to HL7 vocabulary concepts
retain the original HL7 names.

6.3.4

Individual Naming

Our
“made up”
i
ndividual names begin w
ith “I_”

followed by

upper camel c
ase
. Examples include
I
_SomewhereHospital

and
I
_Do
ct
orWelby
.
Names of episodic

instances
will

be suffixed with an
underscore followed by an integer. Common int
egers are used to correlate individuals used in a
common example.

For example,
during
I
_
Session_456
,

an access
event
named
I
_
Access
Event
_456
involves the
I
_
Create_456

operation on the
I
_
LaboratoryOrder_4
56

object.

In the special case of
punning

(13)
, where the same IRI designates both a class and an individual, c
lass
naming conventions are followed for that IRI.

Usage of punning is discussed in Section
6.5

below
.

Page
29

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


6.3.5

Property Naming

Properties are named using
lower camel case.
Examples inclu
de
constrains, hasPermission

and
occursWithinSession.

By default, property names are prefixed with
has.

Other prefixes are used to
improve clarity and/or distinguish multiple
properties

with the same range.

P
roperty names are usually
suffixed with the n
ame of the range class.

6.4

Modeling C
onventions

This subsection

explains several OWL modeling conventions adopted for the Security and Privacy
Ontology.

6.4.1

Redundant Universal R
estrictions

on Object Properties

We have chosen to place domain and range restrictions on all object properties
and data properties
as
shown in
Figure
4

below

and

Data Property Name

Domain

Range

Functional

allowedLoginTimeOfDay

UserIdentity

i
nteger

[>= 0, <
=
86400]



gove牮獔sm敏fD慹

䉡獩捓散畲etyPo汩cy

i
n瑥g敲

嬾㴠0Ⱐ,=
86400]



h慳a楧楴慬i楧n慴畲e

佲O慮楺慴楯n



P敲eon

b
慳收4䉩B慲a


h慳aom慩aName

佲O慮楺慴楯n

獴物sg


h慳䕦晥捴ive呩Te

Po汩cy



P物癡捹Con獥湴D楲i捴楶e




P物癡捹創Re

d慴a呩me



h慳䥤敮瑩晩敲

佢橥捴O



佲O慮楺慴楯n



P敲eon



Po汩cy



P物癡捹Con獥湴D楲i捴楶攠



啳敲䥤敮瑩ey

獴物sg


h慳a慭e

佲O慮楺慴楯n



P敲eon



Po汩cy



卥捵S楴iRo汥



啳敲䥤敮瑩ey

獴物sg


h慳aub汩捡瑩on啒U

Po汩cy



P物癡捹Con獥湴D楲i捴楶e

慮y啒U



h慳呩a敏晔f敡em敮e

䥮景牭a瑩tnR敦er敮捥

d慴a呩me



Page
30

HL7
Standard: Securi
ty and Privacy Ontology, Release 1

© 2013

Health Level Seven In
ternational. All rights reserved.

September 2013


Data Property Name

Domain

Range

Functional

hasWrittenSignatureRecorded

Consenter

boolean



汥l敬佦䅳獵牡r捥

䉡獩捓散畲etyPo汩cy



啳敲䥤敮瑩ey

楮瑥g敲


慵瑨敮瑩捡瑩onLev敬佦䅳獵牡r捥







楤敮瑩瑹P牯o晩fgL敶敬佦䅳eu牡r捥







瑨t牤P慲ayLev敬佦䅳獵牡rce

䉡獩捓散畲etyPo汩cy





u獩sg坯牫r瑡tion䥤

啳敲䥤敮瑩ey

獴物sg


Figure
6

b
elow
,
and described
in Section
7.2.1
.

For example, the
has
PrivacyConsentDirective

prope
rty
has a domain of
Person

and a range of
PrivacyConsentDirective
. This practice curbs unintended usage of
properties. N
ote that in OWL, domains and ranges are not merely constraints. They are logical
assertions which
can be
propagated respectively to th
e source and target classes of the
property

in
question.

We have also chosen to place corresponding universal restrictions on the domain
classes
. For
example, the
Person

class

restricts all values of its
hasPrivacyConsentDirective

property to be of type
PrivacyConsentDirective
.
While that restriction is redundant given the universal domain and range, it
clarifies the intent of the
UserIdentity
class

when viewed in isolation, and also promotes cross
-
checking
between universal and local restrictions, allowing an OWL reasoner to report any inconsistencies.

6.4.2

Distinct I
ndividuals

As mentioned earlier, OWL does not make a Unique Name Assumption (UNA) that

di
fferent

names
imply different individuals.
For example, OWL does not assume that different jurisdiction names such as
_UnitedStatesOfAmerica and _USA refer to different
individual
jurisdictions. Likewise, it does not
assume that
different
provider org
anization names such as _SomewhereHospital and
_ElsewhereHospital refer to different individuals.
In our inten
ded applications, we foresee little

need
to
take advantage of this flexibility

for potential synonyms
. On the contrary,
OWL reasoners
can
sometim
es obtain stronger inferences
when they know that differently named individuals
are

distinct.
Therefore, the set of sample individuals in our
example sub
-
ontology
,
SomewhereHospitalOntology.owl
,

are explicitly declared to be
mutually
different.

6.5

Design P
at
terns

This section

cover
s

the use of ontology design patterns in the Security and Privacy ontology.

It is
intended

to
help readers understand the modeling choices embodied in
the
patterns and reflected in