HL7 Privacy and Security Logical Data Model, HL7 Normative ...

HL7_PRIVSEC_LM_R1_N1_2021JAN

HL7 Privacy and Security Logical Data Model, Release 1

HL7 Normative Ballot

January 2021

Sponsored by:

HL7 Security Work Group

HL7 Community Based Care and Privacy

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

http://www.hl7.org/legal/ippolicy.cfm?ref=nav

Page ii HL7 Privacy and Security Logical Data Model, Release 1

© 2021 Health Level Seven International. All rights reserved. January 2021 Ballot

IMPORTANT NOTES:

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit:

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

If you are the individual that obtained the license for this HL7 Standard, specification, or other freely licensed work (in each and every instance “Specified Material”), the following describes the permitted uses of the Material.

A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.

INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.

B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7’s License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement.

C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part.

NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7.

Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Materials. Licensee shall take no action contrary to, or inconsistent with, the foregoing.

Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”). Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third-Party IP right by the Licensee remains the Licensee’s liability.

Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology Owner/Contact

Current Procedures Terminology (CPT) code set

American Medical Association

https://www.ama-assn.org/practice-management/cpt-licensing

SNOMED CT SNOMED International

http://www.snomed.org/snomed-ct/get-snomed-ct or info@ihtsdo.org

Logical Observation Identifiers Names & Codes (LOINC)

Regenstrief Institute

International Classification of Diseases (ICD) codes

World Health Organization (WHO)

NUCC Health Care Provider Taxonomy code set

American Medical Association. Please see www.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services)

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

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

https://www.ama-assn.org/practice-management/cpt-licensing

http://www.snomed.org/snomed-ct/get-snomed-ct

mailto:info@ihtsdo.org

http://www.nucc.org/

HL7 Privacy and Security Logical Data Model, Release 1 Page iii


Acknowledgements

Privacy and Security Logical Data Model Contributor Table

John “Mike” Davis, VHA Security Architect

Project; Authoring Lead, Principal Contributor

Publishing Facilitator

Bernd Blobel, HL7 Germany

Beth Pumo, Kaiser Permanente

Sponsoring HL7® Security Work Group Cochairs

John Moehrke, By Light Trish Williams

Professor of Digital Health Systems

Flinders University School of Computer

Alexander Mense, Fachhochschule Technikum

Wien, Vienna

Kathleen Connor, Book Zurman,

Contributor

Chris Shawn, VHA

Project and Authoring Co-lead, Contributor

Co-sponsoring HL7® Community Based Collaborative Care [CBCP] Work Group

Cochairs

Suzanne Gonzales-Webb, Book Zurman Johnathan Coleman, Security Risk Solutions

David Pyke, Ready Computing, Contributor Ioana Singureanu, Book Zurman Inc.

Contributor

mailto:mikedatsd@cox.net

mailto:JohnMoehrke@gmail.com

mailto:patricia.williams@flinders.edu.au

mailto:alexander.mense@hl7.at

mailto:kathleen.connor@bookzurman.com

mailto:Christopher.Shawn2@va.gov

mailto:suzanne.webb@bookzurman.com

mailto:jc@securityrs.com

mailto:david.pyke@readycomputing.com

Page iv HL7 Privacy and Security Logical Data Model, Release 1


Table of Contents

1 INTRODUCTION .................................................................................................................1

2 COMPOSITE SECURITY AND PRIVACY LOGICAL DATA MODEL (LDM) .................1

2.1 Overview .........................................................................................................................1

2.2 Background .....................................................................................................................1

2.3 UML Notation .................................................................................................................1

3 LOGICAL DATA MODEL (LDM) ......................................................................................3

3.1 Purpose and Use ..............................................................................................................3

3.2 Relation to Other Models .................................................................................................4

4 INFORMATION ANALYSIS ...............................................................................................5

4.1 Information Analysis Overview .......................................................................................5

4.2 Stakeholder Viewpoint (Overview) ..................................................................................5

4.2.1 Requestor Viewpoint: ................................................................................................5

4.2.2 Custodian Viewpoint: ................................................................................................6

4.2.3 Subject of Care Viewpoint: ........................................................................................6

4.2.4 Engineering Viewpoint: .............................................................................................6

4.2.5 Security Policy Viewpoint: ........................................................................................6

4.3 Operation Classes ............................................................................................................8

4.3.1 Class: Access .............................................................................................................8

4.3.2 Class: Collection ........................................................................................................9

4.3.3 Class: Disclosure .......................................................................................................9

4.3.4 Class: Use ..................................................................................................................9

4.4 Initiator Classes ...............................................................................................................9

4.4.1 Class: Initiator ...........................................................................................................9

4.4.2 Class Initiator-Bound ACI .......................................................................................10

4.4.3 Class: Access Request ACI ......................................................................................11

4.4.4 Class Operand ACI ..................................................................................................11

4.4.5 Class: OperationType (Abstract) ..............................................................................13

4.4.6 Class: Permission (RBAC) .......................................................................................13

4.4.7 Class: PermissionCatalog .........................................................................................13

4.4.8 Class: SecurityRole (Abstract) .................................................................................13

HL7 Privacy and Security Logical Data Model, Release 1 Page v


4.4.9 Class: SecurityClearance ..........................................................................................14

4.4.10 Class: SecurityRelationship ...................................................................................15

4.5 Security Policy Classes ..................................................................................................15

4.5.1 Class: AuthorizationPolicy .......................................................................................16

4.5.2 Class: Basic Policy ..................................................................................................16

4.5.3 Class: Composite Policy ..........................................................................................17

4.5.4 Class: Constraint Policy ...........................................................................................18

4.5.5 Class: Contextural Information ................................................................................18

4.5.6 Class: DelegationPolicy ...........................................................................................19

4.5.7 Class: Location Policy .............................................................................................19

4.5.8 Class: ObligationPolicy............................................................................................19

4.5.9 Class: Functional Role .............................................................................................20

4.5.10 Class: Policy (Abstract) ........................................................................................20

4.5.11 Class: RefrainPolicy..............................................................................................21

4.6 Role-Based Access Control Classes ...............................................................................21

4.6.1 Class: Functional Role .............................................................................................21

4.6.2 Class: Permission .....................................................................................................22

4.6.3 Class: PermissionCatalog .........................................................................................22

4.6.4 Class: SecurityRole (Abstract) .................................................................................22

4.7 Attribute-Based Access Control Classes ........................................................................23

4.7.1 Class: ABAC Attributes ...........................................................................................25

4.8 Relationship-Based Access Control Classes ...................................................................26

4.8.1 Class: Relationship-Based Access Control ...............................................................26

4.9 Custodian Viewpoint .....................................................................................................26

4.9.1 Healthcare Provider Use Cases ................................................................................27

4.10 Custodian Classes .......................................................................................................28

4.10.1 Class: ClinicalDocument .......................................................................................28

4.10.2 Class: DataIntegrity ..............................................................................................28

4.10.3 Class: Diagnosis ...................................................................................................29

4.10.4 Class: Encounter ...................................................................................................29

4.10.5 Class: HealthRecord..............................................................................................29

Page vi HL7 Privacy and Security Logical Data Model, Release 1


4.10.6 Class: InformationReference .................................................................................29

4.10.7 Class: Subject of Record .......................................................................................30

4.10.8 Class: InformationObject ......................................................................................30

4.10.9 Class: Target .........................................................................................................30

4.10.10 Class: Target-Bound ACI ...................................................................................32

4.10.11 Class: PublicServices .........................................................................................32

4.10.12 Class: Section ....................................................................................................33

4.10.13 Class: SubjectOfRecord (Abstract) .....................................................................33

4.10.14 Class: Individual ................................................................................................33

4.10.15 Class: Consenter ................................................................................................33

4.10.16 Class: Population ...............................................................................................34

4.10.17 Class: Clinical Condition....................................................................................34

4.11 Privacy Policy Viewpoint ...........................................................................................34

4.12 Privacy Policy Classes ................................................................................................35

4.12.1 Class: Authority (Abstract) ...................................................................................36

4.12.2 Class: Grantee (Abstract) ......................................................................................36

4.12.3 Class: PrivacyPolicy .............................................................................................36

4.12.4 Class: PrivacyRule ................................................................................................37

4.12.5 Class: ProviderOrganization..................................................................................37

4.13 Privacy Consent Directive Viewpoint .........................................................................38

4.14 Subject of Care Consent Directive Classes ..................................................................39

4.14.1 Class: ConsentDirective ........................................................................................39

5 COMPUTATIONAL VIEWPOINT ....................................................................................40

5.1 Computational Model and Viewpoint ............................................................................40

5.2 Overview .......................................................................................................................40

5.3 Information View ..........................................................................................................41

5.4 Computational View ......................................................................................................42

HL7 Privacy and Security Logical Data Model, Release 1 Page vii


List of Figures

Figure 1: Information Analysis Overview ....................................................................................5

Figure 2: Security Policy Class Hierarchy ...................................................................................7

Figure 3 Authorization (Role-based Access Control) Classes ......................................................8

Figure 4 ABAC Security Domain ..............................................................................................23

Figure 5 Information Reference Classes ....................................................................................27

Figure 6: Privacy of Clinical Documents ...................................................................................28

Figure 7 Privacy Policy Structure Overview Diagram ...............................................................35

Figure 8 Consent Directive Overview Diagram .........................................................................38

Figure 9 Logical Data Model Class Overview ...........................................................................41

Figure 10: Access Control Model ..............................................................................................42

List of Tables

Table 1: ISO 20903 Comparing Data Model Levels ....................................................................4

List of Appendices

Appendix A: Terms and Definitions .......................................................................................44

Appendix B: Citations .............................................................................................................54

Appendix C: HIMSS Interoperability Defined ......................................................................55

Appendix D: Related Standards .............................................................................................56

HL7 Privacy and Security Logical Data Model, Release 1 Page 1


1 INTRODUCTION

This standard describes a Logical Data Model (LDM) for security and privacy that may be

used to create implementations which serve a variety of purposes including regulation and

compliance.

This LDM is intended to meet the challenges of identifying the information and system

behaviors required to implement technological controls enforcing healthcare security and privacy

policy. The model supports the reuse of security standards to enforce access control policies

required by jurisdictional and organizational privacy policies as well as subject of care consent

directives. It focuses on the information required to support authorization and access control.

Note: Diagrams in this document are presented as representational examples and are neither

intended to fully represent pictorially all included classes nor completely illustrate all possible

class elements. Individual instances of access control will apply classes as relevant to a particular

request, trust environment and security policy.

2 COMPOSITE SECURITY AND PRIVACY LOGICAL DATA MODEL

(LDM)

2.1 Overview

The wide use of electronic and/or personal health records present significant challenges for the

protection of individually identifiable health information. Use of these systems enables rapid

access to and automatic exchange of millions of healthcare records and vast quantities of protected

information that previously could not occur in paper-based systems. Security controls

commensurate with expected threats and risks in this environment need to be put into place to

protect this information.

Currently national and state/province legislation, regulations, and/or privacy policies are

already in place or are being developed to protect individuals from the misuse of identifiable health

information and to prevent abuse and unauthorized disclosure. In addition, healthcare

organizations are identifying a variety of security policies intended to ensure the proper use of

computer systems and the protection of sensitive data and resources.

The information describing these policies requires standard and interoperable representations

so that security and privacy protections can be enforced across heterogeneous systems using

automated controls.

2.2 Background

This document extends the HL7 Version 3 Domain Analysis Model: Composite Security and

Privacy, Release 1 dated May 2020. The May 2020 Domain Analysis Model itself was a re-release

of the original HL7 Domain Analysis model balloted DSTU in Jan 2012. This document revises,

updates and replaces sections 1.1-1.5 of the May 2020 informative Domain Analysis Model with

a normative Logical Data Model.

This LDM model identifies the information and system behaviors required to optimize the use

of security standards and technology in healthcare exchange. It is aligned with:

2.3 UML Notation

Page 2 HL7 Privacy and Security Logical Data Model, Release 1


This LDM makes use of UML class and use case diagrams to convey the scope of information,

structure, and semantics. A detailed description of the classes, attributes and relationships that are

specific to each information analysis viewpoint (Security Policy, Healthcare Provider, Privacy

Policy and Privacy Consent Directive) is included in the Information Analysis (section 1) of this

publication.



3 LOGICAL DATA MODEL (LDM)

3.1 Purpose and Use

The use of Electronic Health Record Systems and the wide use of electronic and/or personal

health records requires that medical information be protected from abuse and unauthorized

disclosure. Currently, national and state/province legislation, regulations, and/or privacy policies

are in place or are being developed, to protect individuals from the misuse of their Protected

Information.

This Logical Data Model (LDM)1 is focused on the need for systems to implement electronic

interoperability standards to allow the exchange of Protected Information (including individually

identifiable health information, IIHI) and to enforce interoperable and computable privacy policies

and consent directives using a variety of robust security infrastructure components. Accordingly,

this specification adopts the meaning and purpose of interoperability as defined by the Health

Information Management Systems Society (HIMSS). See Appendix C.

A LDM represents an abstract description of a subject area of interest designed to provide a

generic representation of a class of system or capability and to suggest a set of approaches to

implementation. This LDM is intended to be complete enough to enable the development of

downstream platform-independent models such as HL7 RIM-based information and services

models. An LDM may also be used to constrain other standards for use in healthcare (e.g., to

constrain access control markup standards). The structure of a LDM supports:

Common understanding of business data elements and requirements,

A foundation for designing a database,

Avoiding data redundancy and thus preventing data & business transaction inconsistency,

Data re-use and sharing,

Reduction in development and maintenance time and cost,

A logical process reference and impact analysis.2

1 A logical data model or logical schema is a data model of a specific problem domain expressed independently of a

particular database management product or storage technology (physical data model) but in terms of data structures

such as relational tables and columns, object-oriented classes, or XML tags. This is as opposed to a conceptual data

model, which describes the semantics of an organization without reference to technology.

https://en.wikipedia.org/wiki/Logical_schema 2 Adapted from Wikipedia Logical schema https://en.wikipedia.org/wiki/Logical_schema

https://en.wikipedia.org/wiki/Data_model

https://en.wikipedia.org/wiki/Physical_data_model

https://en.wikipedia.org/wiki/Conceptual_data_model

https://en.wikipedia.org/wiki/Conceptual_data_model

https://en.wikipedia.org/wiki/Logical_schema

https://en.wikipedia.org/wiki/Logical_schema



3.2 Relation to Other Models

Table 1: ISO 20903 Comparing Data Model Levels



4 INFORMATION ANALYSIS

The following discussion offers a harmonized view of the information required to support the

interoperability needs of healthcare providers as defined by the business use cases specified in

Annex A. It identifies the main information (e.g., classes, attributes, associations) required to

support security and privacy policies governing protected information exchanged across

interoperable Electronic Health Record Systems.

4.1 Information Analysis Overview

Figure 1: Information Analysis Overview

shows how sections within the harmonized LDM are organized and mapped to the Stakeholder

and Engineering viewpoints of the Reference Model-Open Distributed Processing (RM-ODP).

These viewpoints represent different aspects of Privacy and Security. The Stakeholder viewpoint

describes the business requirements and semantics of the model while the Engineering viewpoint

describes the mechanisms and functions required to support security.

Figure 1: Information Analysis Overview

4.2 Stakeholder Viewpoint (Overview)

The Requestor, Custodian and Subject of Care of Section 1 form the core of this LDM and are

the principal actors supporting Section 2’s Computational Model.

4.2.1 Requestor Viewpoint:

The Requestor is the representation of a requesting authority domain. In an information

exchange, Initiators (members of the Requestor Domain) attempt to access information from

another entity, the Custodian Domain (information owner). In general, an Initiator will present

their request along with various attributes (validated by the Requestor Domain) that clarify what

is being requested (ACI about or bound to the request) and other ACI about or bound to the

initiator. Typically, this initial request will be done in accordance with a joint Requester/Custodian

inter-domain trust framework policy.3

3 See for example, HL7 Version 3 Standard: Privacy and Security Architecture Framework, Release 1, July 2020,

Volume 1: Trust Framework for Federated Authorization, Conceptual Model



4.2.2 Custodian Viewpoint:

The Custodian Domain is responsible for protecting information under its jurisprudence as the

information owner. The Responder (member of the Responder domain holding the requested

information) evaluates various policy rules (internal and associated with the federated domain trust

contract if available) for determining whether or not the Initiator is trustworthy and the presented

ACI is sufficient to authorize the disclosure of the requested information. In so doing, the

Responder may also consider policies/preferences of the Subject Care.

4.2.3 Subject of Care Viewpoint:

The Subject of Care (aka patient) submits their personal privacy preferences rules and values

for inclusion in the Custodian Domain privacy policy. This may be in the form of a consent

directive and opt-out or any type of communication between the patient and their healthcare

provider regarding patient originated exclusions regarding disclosure of their healthcare

information.

4.2.4 Engineering Viewpoint:

The three components of the engineering viewpoint include: role-based access control

(RBAC), attribute-based access control (ABAC) and relationship-based access control (ReBAC).4

At runtime, specific access control policy rules are constrained to specific access control

decision information (ADI) and InformationResource values and are evaluated against access

requests and ADI supplied by initiators as well as information retained from prior decisions, the

context in which the access request is made, and the impact of any patient policy preferences

included in the Jurisdiction/Organization privacy policy.

4.2.5 Security Policy Viewpoint:

This section describes the Security Policy viewpoint and includes diagrams, class, attribute,

and relationship descriptions for the information required by security policies intended to address

the use case of a Requestor obtaining patient information from an independent external Custodian

via some manner of electronic health information exchange.

Personal Health Records should possess the functional and technical capability to enable

healthcare consumer control of the collection, access, use, and disclosure of their individually

identifiable health information (IIHI) according to the type of information, type of provider, and

purposes/circumstance of the collection, access, use, or disclosure. The consumer control

capability must remain associated with the IIHI as it travels through the electronic health

information exchange such that consumer control is supported when IIHI is further disclosed.

Thus, the consumer control of IIHI capability must span Electronic Health Records and Personal

Health Records. Personal Health Records should possess the functional and technical capability to

enable healthcare consumer control of the collection, access, use, and disclosure of their IIHI

according to the type of information, type of provider, and purposes/circumstance of the collection,

access, use, or disclosure. The consumer control capability must remain associated with the IIHI

as it travels through the electronic health information exchange such that consumer control is

4 See HL7 Version 3 Standard: Healthcare Access Control Catalog, Release 3, October 2016 for discussion of these

three access control mechanisms.



supported when IIHI is further disclosed. Thus, the consumer control of IIHI capability must span

Electronic Health Records and Personal Health Records.

Nevertheless, the principal function of a healthcare exchange is to provide the timely delivery

of patient healthcare information for their treatment and care. It is therefore the responsibility of

the Healthcare provider to ensure that external Information Initiators are properly identified and

that assurances can be had that the information is being delivered to only those entities that have a

legitimate need and can be counted upon to protect the information received in accordance with

existing policy.

Figure 2: Security Policy Class Hierarchy

Figure 2 Security Policy Class Hierarchy, focuses on the relationship between the privacy

viewpoint and the security viewpoint. The diagram shows that a Privacy Policy may be enforced

or implemented using a BasicPolicy consisting of Authorizations, Delegations, Refrains and

Obligations. A Patient Consent Directive is implemented by constraining a default Privacy Policy.

Therefore, a ConstraintPolicy may be used to implement/enforce a Privacy Consent Directive. This

model is aligned with ISO 22600 and is extended and refined to meet the specific use case

documented in Section II. If a security policy and a privacy policy is related in the same use case

context (e.g., both dealing with the Individual's privacy preferences) then the equivalent security

is a CompositePolicy. Similarly, a ConsentDirective would correspond to a ConstraintPolicy. If

policies with different concepts and concept representation should be interconnected, MetaPolicy

as specified in ISO 22600-2, is indicated.



Figure 3 Authorization (Role-based Access Control) Classes

Figure 3 identifies the classes used to describe role-based access control policies. According to

ISO/TS 21298 “Health informatics – Functional and structural roles,” structural roles bind entities

to entities (such as organizations) thereby describing a characteristic the entity has (including

qualifications, etc.); while functional roles bind entities to activities/actions thereby describing the

entity as actor. A structural role can enable/facilitate/legally permit a functional role as

prerequisite, requirement, or facilitator (e.g., qualification). Finally, functional role defines the

access control decision. Both structural and functional roles are bound to policies.

4.3 Operation Classes

The following specialization classes of the abstract class OperationType are intended to define

specializations of actions/operations as defined in relevant policies. In general, the OperationType

describes the action performed on the target object.

4.3.1 Class: Access

This class represents those operations that deal with access to Protected Information (PI).

Multiplicity Notes

'Access.code' of type 'AccessOperation'

[0...1] Coded attribute that specifies a type of access operation.



4.3.2 Class: Collection

This class represents those operations that deal with collecting PI.

Multiplicity Notes

'Collection.code' of type 'CollectOperation'

[0...1] Coded attribute that specifies a type of collection operation.

4.3.3 Class: Disclosure

This class represents those operations that deal with disclosure of PI.

Multiplicity Notes

'Disclosure.code' of type 'DiscloseOperation' with

[0...1] Coded attribute that specifies a type of disclosure operation.

4.3.4 Class: Use

This class represents those operations that deal with the use of PI for various purposes.

Multiplicity Notes

Attribute 'Use.code' of type 'UseOperation'

[0...1] Coded attribute that specifies a type of use operation.

4.4 Initiator Classes

The following classes are used to describe Requestor Initiator the user roles, permissions, and

the relationships between the various roles and permissions standardized by the permission

catalog.

4.4.1 Class: Initiator

This class is used to specify the attributes identifying the user (Requestor) of a system used to

access Protected Information.

Multiplicity Notes

Attribute 'InitiatorName' of type 'String'

[1] This attribute specifies the Initiator’s name.

Attribute 'Initiator.initiator.Id' of type 'ID'

[0..1] This attribute is used to represent the Initiator’s identifier.

Attribute ‘Initiator.location’ of type ‘Location’

[1] Identifier of the initiator’s specific system, workstation or terminal or specific physical location.

Association 'Initiator.securityRole' of type 'SecurityRole'

[1..*] This association references the Initiator’s role specified in the policy.



Multiplicity Notes

Association ‘Initiator.HierarchicalGroup’” of type’ Hierarchical Group’

[0..1] Identifier of the hierarchical group in which membership is asserted.

Association ‘Initiator.FunctionalGroup’ of type ‘FunctionalGroup’

[0..1] Identifier of the functional group in which membership is asserted.

Attribute ‘SensitivityMarkings’ of type ‘Sensitivity’

[0..*] Identifier of the sensitivity markings to which membership is asserted.

Attribute ‘IntegrityMarkings’ of type ‘IntegrityCodeList’

[0..1] Identifier of the integrity markings to which membership is asserted.

Attribute ‘Secure Interaction Policy’ of type ‘Purpose Code’

[1] Purpose of Use (POU) of the request.

4.4.2 Class Initiator-Bound ACI

Forms include security labels, capabilities, and access control certificates. Initiator-bound ACI

is not necessarily delivered by the initiator.

Multiplicity Notes

Attribute ‘Initiator-BoundACI.accessControlInformation’ of type ‘String’

[0..*] Initiator ACI

Attribute ‘Initiator-BoundACI.targetAccessControlID’ of type ‘AccessId’

[0..*] A target access control identity and the accesses allowed on the target (i.e., a capability).

Attribute ‘Initiator-BoundACI.location’ of type ‘Location’

[1] A location



Multiplicity Notes

Association ‘Initiator-BoundACI.group’ of type ‘HealthcareWorkGroup’

[0..1] Healthcare Work Group Membership

Association ‘Initiator-BoundACI.hierarchicalGroup’ of type ‘HierarchicalGroup’

[0..1] Organizational Headquarters, Geographical Sub-division, Local Hospital, etc.

Attribute ‘Initiator-BoundACI.role’ of type ‘FunctionalRole’

[0..*] Granted set of competencies and/or performances which is associated with a task.

Class: Request-Bound ACI (Request Context)

Access request-bound ACI may contain initiator ACI, target ACI and contextual information.

Multiplicity Notes

Association ‘TargetName or TargetGroup’ of type ‘String’

[0..*] The Initiator/Target pairs allowed to take part in an access

Association ‘Target of type ‘String’

[1...*] Targets allowed to take part in an access

Association ‘Initiators’ of type ‘String’

[1..*] Initiators allowed to take part in an access

4.4.3 Class: Access Request ACI

Asserted ACI about an Access request. May be specified in Trust Framework policy.

Attribute Multiplicity Notes

Attribute ‘AccessRequestACI.operationClass’ of type ‘OperationClass’

[0..*] Allowed class of operation (e.g. read, write)

Attribute ‘AccessRequestACI.operationIntegrityLevel’ of type ‘IntegrityCodeList’

[1] Integrity level required for use of operation.

Attribute ‘AccessRequestACI.operationDataType’ of type ‘DataType’

[1] Data type of the operation.

4.4.4 Class Operand ACI



Multiplicity Notes

Attribute ‘OperandACI.sensitivityMarking’ of type ‘Sensitivity’

[0..*] Access request operand.

Attribute ‘OperandACI.integrityMarking’ of type ‘IntegrityCodeList’

[0..*] Access request operand.



4.4.5 Class: OperationType (Abstract)

This abstract class specifies permissions assigned by a Requestor organization to specific users

which may then be asserted in an information request to a Resource (Target). The permissions may

be required by the Resource prior to providing access to Protected Information.

Multiplicity Notes

Attribute 'OperationType.operationCode' of type 'ActionOperation'

[0..1] This attribute identifies the operation that is either allowed or prohibited by the permission.

4.4.6 Class: Permission (RBAC)

This class corresponds to a Role-Based Access Control (RBAC) permission. It specifies an

information object and action/operation allowed on that object. A permission contains one

operation and precisely one information reference.

Multiplicity Notes

Attribute 'Permission.id' of type ' '

[1] This attribute is used to specify the unique identifier of the permission.

Association 'Permission.informationObject' of type 'InformationObject”

[1] This association identifies the information resources specified by a permission.

Association 'Permission.operationType' of type 'OperationType”

[1] This association identifies the action or operation that is specified by a permission.

4.4.7 Class: PermissionCatalog

The permission catalog specifies a set of standard permissions. The permission catalog is the

subject of separate HL7 standards. This reference is intended to show it relates to the rest of the

information classes required to support the use cases.

4.4.8 Class: SecurityRole (Abstract)

ISO/TS 22600-2 – Heath Informatics – Privilege Management and Access Control defines

methods for managing authorization and access control to data and/or functions. It accommodates

policy bridging. Privilege management and authorization may be based on roles that individual

actors or groups of individual actors play. ISO-22600-2 specifies a Role as 'set of competencies

and/or performances which is associated with a task.' A SecurityRole is a specialization of the

Basic class that defines a group of policies (authorization, obligation, delegation, and refrain

policies). A 'SecurityRole' is an abstract class that is equivalent to 'Role.’ FunctionalRole and

StructuralRole are specializations of the abstract SecurityRole class.

Multiplicity Notes

Attribute 'SecurityRole.authorityIdentifierName' of type 'String'

[1] This attribute is defined by ISO 22600-2 as 'String.'



Multiplicity Notes

Association 'SecurityRole.permission' of type 'Permission'

[*] This association specifies the permissions included in the role.

Attribute 'SecurityRole.roleDescription' of type 'ConceptDescription'

[1] This attribute is defined by ISO 22600-2 as 'ConceptDescription.'

Attribute 'SecurityRole.roleIdentifier' of type 'InstanceIdentifier'

[1] This attribute is defined by ISO 22600-2 as 'Set of InstanceIdentifier.'

Attribute 'SecurityRole.roleIdentifierID' of type 'ObjectIdentifier’

[1] This attribute is defined by ISO 22600-2 as 'ISO ObjectIdentifier.'

Attribute 'SecurityRole.roleName' of type 'InstanceIdentifier'


4.4.9 Class: SecurityClearance

Attribute based access control is based on classifying data and then assigning users access

permissions (e.g., permission) to that data. A SecurityClearance is a specialization of the Basic

class that defines a group of policies (authorization, obligation, delegation, and refrain policies).

Multiplicity Notes

Attribute 'SecurityClearance.authorityIdentifierName' of type 'String'

[1] This attribute is defined as 'String.'

Association 'SecurityClearance.permission' of type 'Permission'

[*] This association specifies the permissions included in the clearance.

Attribute 'SecurityClearance.clearanceDescription' of type 'ConceptDescription'


Attribute 'SecurityClearance.classificationIdentifier' of type 'InstanceIdentifier'




Multiplicity Notes

Attribute 'SecurityClearance.clearanceIdentifierID' of type ‘ObjectIdentifier’


Attribute 'SecurityClearance.clearanceName' of type 'InstanceIdentifier'


4.4.10 Class: SecurityRelationship

Relationship-based access control is based on identifying clinical relationships to individuals

(e.g., Primary Care Provider/Care Team) and then assigning users access permissions to that data

based on relationships to the Subject of Record. A SecurityRelationship is a specialization of the

Basic class that defines a group of policies (authorization, obligation, delegation, and refrain

policies).

Multiplicity Notes

Attribute 'SecuritRelationship.authorityIdentifierName' of type 'String'

[1] This attribute is defined as 'String.'

Association 'SecurityRelationship.permission' of type 'Permission'

[*] This association specifies the permissions included in the clearance.

Attribute 'SecuritRelationship. description of type ‘ConceptDescription'


Attribute 'SecurityRelationship.relationshipIdentifier' of type 'InstanceIdentifier'


Attribute 'SecurityRelationshipt.relationshipIdentifierID' of type ‘ObjectIdentifier’


Attribute 'SecurityRelationship. relationshipName' of type 'InstanceIdentifier'


4.5 Security Policy Classes



The following classes are based on security policy requirements as well as the hierarchy

specified by ISO 22600-2.

4.5.1 Class: AuthorizationPolicy

AuthorizationPolicy is a specialization of a BasicPolicy and is used to describe an authorization

policy that may be exchanged across domains. An instance of AuthorizationPolicy specifies

'permitted actions' according to ISO 22600-2. A positive (or negative) AuthorizationPolicy defines

the actions ('OperationType') that a subject is permitted (or forbidden) to perform on a target.

Actions encoded using the 'OperationType' class represents the operations defined in the interface

of a target object. The following are attributes of an AuthorizationPolicy:

Multiplicity Notes

Attribute ‘AuthorizationPolicy.levelOfA

ssurance’ of type ‘INT’

[0...1] Level of Assurance (LoA) refers to the degree of certainty that (1) a resource owner has that a person's physical self has been adequately verified before credentials are issued by a registration authority, and (2) a user owns the credentials they are subsequently presenting to access the resource. LoA is relevant to authentication, authorization, and access control. A BasicPolicy requires the level of assurance as indicated within the AuthorizationPolicy specialization.

Attribute

‘AuthorizationPolicy.enable’

of type ‘Boolean’

[1...1] This attribute is used to specify if the policy enables or declines an authorization. If this attribute is set to 'true', the policy authorizes the actions and conditions pertaining to the resources referenced by the policy. Otherwise, the authorization is declined.

4.5.2 Class: Basic Policy

This is the base class for a variety of policy types. It extends the abstract Policy class and

provides additional attributes. This class may be used to instantiate specific policies. ISO-22600-

2 specifies a Security Policy as 'plan or course of action adopted for providing computer security'.

BasicPolicy is a specialization of the abstract Policy class and inherits all its attributes. It also

defines additional attributes and associations:

Multiplicity Notes

Association 'BasicPolicy.informationReference' of type 'InformationReference'

[*] This association references the attributes of the information referenced in the policy.



Multiplicity Notes

Association 'BasicPolicy.operationType' of type 'OperationType'

[*] This association refers to the operation associated with the policy.

Attribute 'BasicPolicy.purposeOfUse' of type 'PurposeCode'

[0...1] This attribute is used to specify the purpose to permit a specific type of action/operation according to the policy. The vocabulary analysis section provides additional illustrative values for the concept embodied by this attribute.

Attribute 'BasicPolicy.route' of type ' '

[1] This attribute specifies whether access to protected information may only be granted for a specified route of access. For example, access may be restricted to remote users using a Virtual Private Network (VPN). The route is a context qualifier as specified by ISO/IEC 10164-9.

Association 'BasicPolicy.securityRole' of type 'SecurityRole'

[*] This association references the user role specified in the policy defined as a granted set of competencies and/or performances which is associated with a task.

Attribute 'BasicPolicy.timePeriod' of type 'Time'

[*] This attribute specifies that access may be allowed only during specific time periods of the day (e.g., 9 am to 5 pm).

Attribute ‘BasicPolicy.integityMarkings’ of type ‘IntegrityCodeList’

[0..*] Target integrity levels to which access is allowed.

Attribute ‘BasicPolicy.securityLabels’ of type ‘String’

[0..*] Target tags(security attributes) to which access is allowed.

Attribute ‘BasicPolicy.relationships’ of type ‘Relationships’.

[0..*] Relationships to which access is allowed, Primary Care Provider, Care Team, etc.

4.5.3 Class: Composite Policy

This class is the focal class for electronic privacy policies. It contains a set of basic policies

that work together to enforce a privacy policy, organizational standard operating procedure, or a

privacy consent directive. Its basic characteristic is that it contains other policies. An instance of a

CompositePolicy may include several Authorization, Delegation, Refrain, or Obligation policies.

A CompositePolicy is specialization of the abstract Policy class and inherits all its attributes and

associations. In addition to the attributes, it inherits from its base class ('Policy'), this type of class

contains the following association and attribute:



Multiplicity Notes

Attribute 'CompositePolicy.combiningAlgorithm' of type ' '

[1] This attribute is used to specify the policy combining algorithm that is used to process the contained policies.

Association 'CompositePolicy.containedPolicy' of type 'BasicPolicy'

[1..*] This association specifies the policies contained in a CompositionPolicy.

4.5.4 Class: Constraint Policy

A constraint policy is intended to constrain an existing policy. For example, a ConstraintPolicy

instance may be used to represent a privacy consent directive that sets specific ‘limitations’ on a

default organizational policy regarding substance abuse data (e.g., 42 CFR Part 2). A policy

(BasicPolicy or CompositePolicy) can be constrained by the use of profiles for tailoring a policy

instance. Complex constraints (e.g., an OCL expression) may be applied and managed separately.

For this definition and for management purposes, it is possible to separate externally defined

constraints and specify a 'ConstraintPolicy' with clearly defined associations to the constrained

policy according to component model principles. Effectively, the result of applying constraints is

just another CompositePolicy.

Multiplicity Notes

Attribute 'ConstraintPolicy.constraint' of type ' '

[*] This attribute identifies the type of constraint expression.

Association 'ConstraintPolicy.constrainedPolicy' of type 'CompositePolicy’

[1] This association identifies the policy that is constrained by the ConstraintPolicy.

4.5.5 Class: Contextural Information

Information about or derived from the context in which an access request is made (e.g., time

of day).


‘ContextualInformation.timePeriod’ of type “Time”

[1] Period of time for wich the access request is valid.

‘ContextualInformation.route’ of type ‘ ‘

[1..*] Specified path by which information must travel.

‘ContextualInformation.location’ of type ‘Location’

[1] Location of requested information

‘ContextualInformation.status’ of type ‘String’

[1] Status of the request.




‘ContextualInformation.authenticationMechanism’ of type ‘ ‘

[1..*] Allowable mechanisms by which an Initiator may be authenticated.

4.5.6 Class: DelegationPolicy

A delegation policy is intended to assign access rights to a specific individual or organization

(a grantee). ISO 22600-2 defines delegation as 'conveyance of privilege from one entity that holds

such privilege, to another entity'. A DelegationPolicy 'defines what authorizations can be delegated

to whom'.

Multiplicity Notes

Association 'DelegationPolicy.grantee' of type 'Grantee'

[*] The person or organization that is the subject of delegation. This is the entity that receives the privilege granted by the DelegationPolicy.

4.5.7 Class: Location Policy

Access may be granted only to initiators on specific end-Initiator systems, workstations, or

terminals or only to initiators in a specific physical location. This class is required to support

Initiator authorization as specified by Custodian business requirements.

Multiplicity Notes

Association 'Location.providerOrganization' of type 'ProviderOrganization'

[1] This association identifies the organization where the location is scoped.

Attribute 'Location.workstationId' of type 'ST'

[*] Association 'Functional Role.rolePermissions' of type 'Permission' with cardinality of [*]

This association identifies the permissions that are associated with a functional role.

4.5.8 Class: ObligationPolicy

An obligation policy may be used to specify additional privacy preferences specified by an

Individual/patient. An ObligationPolicy may be specified in addition to a ConstraintPolicy to fully

describe an Individual's access control preferences. In some cases, an obligation policy may be

used to indicate that the receiver of an information object may not be allowed to re-disclose or

persist that information object indefinitely. According to ISO 22600-2, ObligationPolicy instances

'are event-triggered and define actions to be performed by manager agent'.

Multiplicity Notes

Attribute 'ObligationPolicy.eventCode' of type 'ObligationCode'

[*] This attribute identifies the action required before completing a step in the workflow. We assume it is coded concept but in today's implementations



Multiplicity Notes

it is primarily an ad-hoc rule reference (e.g., the name of a data base stored procedure). An obligation may be associated with the release of an object. For example, it may require a signature. This information is passed as rule for an application to enforce. In other cases, it may require that an audit record be created.

4.5.9 Class: Functional Role

Functional Roles can be grouped according to their authorization to access Protected

Information (PI) and perform various operations on healthcare information. For example, a

healthcare provider in Organization A is authorized to access PI from Organization B (when

Organization A and B have entered into a trusted relationship) if that provider is associated with

the Functional Group whose permissions grant access per that FunctionalRole. In summary, the

functional role defines the access control decision. A functional role is bound to a policy.

Multiplicity Notes

Attribute 'Functional Role.name' of type 'String

[0...1] This attribute is used to represent the user role name, if specified.

Attribute ‘Functional Role.roleCode’ of type ‘FunctionalRoleCode’

[0..1] The functional role may specify that the user is part of the healthcare team that is directly involved in the Individual’s care. This attribute refers to a functional role assigned by an organization to computer users.

Association 'Functional Role.rolePermissions' of type 'Permission'

[*] This association identifies the permissions that are associated with a functional role.

4.5.10 Class: Policy (Abstract)

This is the abstract policy class from which all concrete policy classes in this model are derived

and instantiated. Because this class is abstract, it cannot be instantiated as a security policy for

healthcare, however, it specifies the properties reused by all policies. ISO 22600-2 specifies a

policy as 'set of legal, political, organizational, functional and technical obligations for

communication and cooperation'.

Multiplicity Notes

Association 'Policy.authority' of type 'Authority'

[1...1] This attribute reflects the type code for the HL7 RIM ActPolicyClass. The ActPolicyClass.act PolicyType represents a mandate, obligation, requirement, rule, or expectation about the activity or behavior of another party, or the manner in which an act is executed.



Multiplicity Notes

Attribute 'Policy.description' of type 'String'

[1] This attribute specifies the narrative description of the policy.

Attribute 'Policy.effectiveTime' of type 'IVL<TS>'

[1] This attribute specifies the period of time (e.g., start date, end date) during which the privacy policy described by a Policy is in effect.

Attribute 'Policy.uri' of type 'URL' [0..1] This attribute specifies the location of published policy.

Attribute 'Policy.statusCode' of type ' '

[1] This attribute indicates whether the policy is active or not.

4.5.11 Class: RefrainPolicy

A refrain policy is used to indicate that a specific action is prohibited based on specific access

control attributes (e.g., purpose of use, information type, user role, etc.). It is a specialization of

the “BasicPolicy” class. It does not have any additional attributes but implies different behavior.

ISO 22600-2 species that a RefrainPolicy 'defines actions the subjects must refrain from

performing.'

When healthcare providers access, use, collect and disclose Protected Information, it must be

done in accordance with organizational policies and Individual privacy consent directives. As

illustrated by the Privacy Use Cases documented in Annex A, a healthcare provider either sends

(as 'Information Sender (Custodian) ') or receives Protected Information to support treatment,

transfer of care and continuity of care. The information systems that healthcare providers use must

ensure policies are automatically enforced based on explicit, standard-based qualifiers of Protected

Information when they exchange information.

Figure 6 shows how a healthcare provider may play the role of an Information Requestor or

Information Sender (Custodian).

4.6 Role-Based Access Control Classes

If one considers a set of (target identity, operation type) pairs as initiator-bound ACI, and

target identities as target-bound ACI, under an appropriate access control policy, one obtains

what is essentially a capability scheme. (Role-Based Access Control)

4.6.1 Class: Functional Role

Functional Roles can be grouped according to their authorization to access Protected

Information (PI) and perform various operations on healthcare information. For example, a

healthcare provider in Organization A is authorized to access PI from Organization B (when

Organization A and B have entered into a trusted relationship) if that provider is associated with

the Functional Group whose permissions grant access per that FunctionalRole. In summary, the

functional role defines the access control decision. A functional role is bound to a policy.



Multiplicity Notes

Attribute 'Functional Role.name' of type 'String

[0...1] This attribute is used to represent the Initiator role name, if specified.

Attribute ‘Functional Role.roleCode’ of type ‘RoleCode’

[0..1] The role may specify that the Initiator is part of the healthcare team that is directly involved in the Individual’s care. This attribute refers to a functional role assigned to computer Initiators by their organization.

Association 'Functional Role.rolePermissions' of type 'Permission'

[*] This association identifies the permissions that are associated with a functional role.

4.6.2 Class: Permission

This class corresponds to a Role-Based Access Control (RBAC) permission. It specifies an

information object and action/operation allowed on that object. A permission contains one

operation and precisely one information reference.

Multiplicity Notes

Attribute 'Permission.id' of type 'Id'

[1] This attribute is used to specify the unique identifier of the permission.

Association 'Permission.informationObject' of type 'InformationObject’

[1] This association identifies the information resources specified by a permission.

Association 'Permission.operationType' of type 'OperationType’

[1] This association identifies the action or operation that is specified by a permission.

4.6.3 Class: PermissionCatalog

The permission catalog specifies a set of standard permissions. The permission catalog is the

subject of separate HL7 standards. This reference is intended to show it relates to the rest of the

information classes required to support the use cases.

4.6.4 Class: SecurityRole (Abstract)

ISO/TS 22600-2 – Heath Informatics – Privilege Management and Access Control defines

methods for managing authorization and access control to data and/or functions. It accommodates

policy bridging. Privilege management and authorization may be based on roles that individual

actors or groups of individual actors play. ISO-22600-2 specifies a Role as 'set of competences

and/or performances which is associated with a task.' A SecurityRole is a specialization of the

class CompositePolicy that defines a group of policies (authorization, obligation, delegation, and

refrain policies). A 'SecurityRole' is an abstract class that is equivalent to 'Role.’ FunctionalRole

and StructuralRole are specializations of the abstract SecurityRole class.



Multiplicity Notes

Attribute 'SecurityRole.authorityIdentifierName' of type 'String'

[1] This attribute is defined by ISO 22600-2 as 'String.'

Association 'SecurityRole.permission' of type 'Permission'

[*] This association specifies the permissions included in the role.

Attribute 'SecurityRole.roleDescription' of type 'ConceptDescription'


Attribute 'SecurityRole.roleIdentifier' of type 'InstanceIdentifier'


Attribute 'SecurityRole.roleIdentifierID' of type 'ObjectIdentifier'


Attribute 'SecurityRole.roleName' of type 'InstanceIdentifier'

[1] This attribute is defined by ISO 22600-2 as 'CodedSimpleValue.'

4.7 Attribute-Based Access Control Classes

If one considers what are commonly called “clearance” and “classification” as initiator-

bound ACI and target-bound ACI, respectively, under an appropriate access control policy, one

obtains what is essentially a label-based scheme (Attribute-Based Access Control).

Figure 4 ABAC Security Domain



References:

HL7 Healthcare Privacy and Security Classification System (HCS), Release 2, June 2019

Guide to the HL7 Healthcare Privacy and Security Classification System (HCS) Release 2,

January 2014

According to NIST Special Publication 800-162, Guide to Attribute-Based Access Control

(ABAC) Definitions and Considerations, 02 August 2019, ABAC is a logical access control

methodology where authorization to perform a set of operations is determined by evaluating

attributes associated with the subject, object, requested operations, and, in some cases,

environment conditions against policy, rules, or relationships that describe the allowable

operations for a given set of attributes.



4.7.1 Class: ABAC Attributes

This class corresponds to those ABAC clearances which may be required by an Initiator in

order to access correspondingly classified Custodian-owned PI. See HL7 Healthcare Classification

System (HCS).5

Multiplicity Notes

Attribute ‘Initiator.clearance’ of type ‘Confidentiality”

[1..1] This attribute references the Initiator Confidentiality value asserted in an information request.

Attribute ‘Custodian.classification of type ‘Confidentiality

[1..*] The minimum Confidentiality attribute value required to allow access to requested information as specified by Custodian policy (higher values acceptable).

Attribute ‘Initiator.clearance of type ‘Sensitivity ’

[0..*]

This attribute references Initiator Sensitivity value(s) asserted in an information request.

Attribute ‘Custodian.classification of type ‘Sensitivity’.

[0..*]

The Sensitivity value(s) required to allow access to requested information as specified by Custodian policy.

Attribute ‘Initiator.clearance’ of type ‘Compartment’.

[0..*] This attribute references Initiator Compartment value(s) asserted in an information request.

Attribute ‘Custodian.classification of type ‘Compartment’.

[0..*] The Compartment value(s) required to allow access to requested information as specified by Custodian policy.

Attribute ‘Initiator.integrity’ of type ‘Integrity’.’

[0..*] This attribute references Initiator Integrity value(s) asserted in an information request.

Attribute ‘Custodian.clearance’ of type ‘Integriy’.

[0..*] The Integrity value(s) required to allow access to requested information as specified by Custodian policy.

Attribute ‘Initiator.handling caveat.purposeofuse’ of type ‘PurposeCode’

[1..*] This attribute is used to specify the Security Purpose of Use6 for requested information as asserted by the Initiator.

5 HL7 Healthcare Privacy and Security Classification System (HCS), Release 1

When an initiator is a human user (or an initiator process represents a human user), the label bound to the initiator

often is called a clearance. In these cases, the label bound to the IT resource is called a classification. 6 Security Controls (Handling Caveats) are instructions about mandatory and prohibited actions (obligations and refrain policies) within a permitted use context or “purpose of use”. Handling caveat labels convey dissemination controls and information handling caveats such as obligations and refrain policies to which an IT resource custodian or receiver must comply. Assign handling caveats as access control decision information (ADI) to an

http://www.hl7.org/implement/standards/la.cfm?file=/documentcenter/private/standards/v3/PRIV_SEC_CLASS_SYS_R1_2014APR_R2019JUN.zip



4.8 Relationship-Based Access Control Classes

If one considers an initiator identity as initiator-bound ACI, and a set of (initiator

identity.subjectofcare.relationship type) pairs and optionally a set of

(initiator.clearance/classification type pairs) as target-bound ACI, under an appropriate access

control policy, one obtains what is essentially a Relationship-based (ReBac) access control

scheme.7

Per NIST Special Publication 800-162 described above, ABAC includes the concept of

relationships. The viewpoint is that ReBac by itself may be insufficient to provide adequate

security and must be under-pinned by foundational underpinning of subject, object, and requested

operations which can then also include relationships as an additional access-control factor. ReBac

allows for greater granularity of control than provided by Clearance/Classification pairs alone.

4.8.1 Class: Relationship-Based Access Control

Multiplicity Notes

Association 'InitiatorIdentity.relationship' of type 'Relationship'

[1..*] This association references the Initiator relationship(s) to the Subject of Care.

Association

‘Custodian.securityAttribute’ of type ‘Relationship’

[1..*] This association references the allowed relationship(s) specified in the Custodian policy.

Association 'InitiatorIdentity.securityAttribute' of type 'Clearance'

[1..*] This association references the Initiator clearance(s) specified in the ABAC policy.

Attribute ‘Classification’ of Type ‘String’

[1] This attribute is used to specify information tagging by reference to HL7 HCS Security Sensitivity, Compartment and Integrity Labels including Handling Caveats for .Purpose of Use, Obligations and Refrains.

4.9 Custodian Viewpoint

This section demonstrates how security and privacy policies may be used computationally to

determine how Individual health records should be protected when exchanged between healthcare

information resource as required by policy to obtain an end user’s implicit or explicit acceptance of a source rule

prior to use or access. HL7 Healthcare Privacy and Security Classification System (HCS), Release 1. (A)dditional attributes for use in access control decision making. Such attributes might include, for example, handling and distribution caveats compartment indicators, timing constraints, and/or initiator

identification information. Warwick Ford –Computer Communications Security.

7 https://link.springer.com/chapter/10.1007/978-3-662-43936-

4_19#:~:text=Relationship%2Dbased%20access%20control%20(ReBAC,access%20requester%20and%20the%20ta

rget

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


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

https://link.springer.com/chapter/10.1007/978-3-662-43936-4_19#:~:text=Relationship%2Dbased%20access%20control%20(ReBAC,access%20requester%20and%20the%20target





providers and organizations. Examples are provided showing techniques for enforcing the privacy

of clinical documents and instantiating a policy intended to protect substance abuse records.

4.9.1 Healthcare Provider Use Cases

When healthcare providers access, use, collect and disclose Protected Information, it must be

done in accordance with organizational policies and Individual privacy consent directives. As

illustrated below, a healthcare provider either sends (as 'Information Sender (Custodian)') or

receives Protected Information to support treatment, transfer of care and continuity of care. The

information systems that healthcare providers use must ensure policies are automatically enforced

based on explicit, standard-based qualifiers of Protected Information when they request

information from, or disclose information to, other organizations or covered entities. Figure 6

shows how a healthcare provider may play the role of an Information Requestor or an Information

Sender.

Figure 5 Information Reference Classes

Figure 5 demonstrates how a system may use the coded attributes of a clinical document to

enforce the appropriate privacy policy. Note that the information references in the privacy policy

structure are referring to precise, coded attributes that would appear in the header or body of a

clinical document and the coding scheme and process/protocols will have to ensure that a

document has either been fully classified or not yet classified. In other words, the clinical document

will have to differentiate between 'no code' because none were applicable, and 'no code' because

the clinical document has not yet been codified.



Figure 6: Privacy of Clinical Documents

4.10 Custodian Classes

A custodian is defined as 'an individual or organization that collects, uses, or discloses

Protected Information (PI) for the purposes of care and treatment, planning and management of

the health system or health research.8

The following classes describe the protected managed object classes that represent the

Protected Information characteristics identified in Annex A - Business Use Cases. These classes

are used to specify the type of information/resource that is the subject of a policy. These classes

refer to the information artifacts that use standard-based structures and vocabularies.

4.10.1 Class: ClinicalDocument

This class is used to illustrate some of the contents of a clinical document that may be

referenced by a security policy.

Multiplicity Notes

Attribute ‘ClinicalDocument.instanceID’ of type ‘instanceID’

[1] This is the unique identifier describing the instance of a ClinicalDocument.

4.10.2 Class: DataIntegrity

Data integrity is an implied privacy concept, but it is explicit in security policy specifications.

8 Security Glossary HL7 2008(c), Version 3



4.10.3 Class: Diagnosis

Identification of a condition, disease, disorder, or problem by systematic analysis of the

background or history, examination of the signs or symptoms and evaluation of the research or test

results.

4.10.4 Class: Encounter

An interaction between an Individual/patient and care provider(s) for the purpose of providing

healthcare-related service(s).

4.10.5 Class: HealthRecord

This class is used to store a reference to the health record that is the subject of the consent rules

in the privacy Consent Directive.

Multiplicity Notes

Attribute 'HealthRecord.recordId' of type 'oid'

[0..1] The id of the record that is the target of a privacy consent directive.

Attribute 'HealthRecord.recordLocation' of type 'String'

[0..1] The location of the record that is the target of a privacy consent directive.

4.10.6 Class: InformationReference

This class and its associations specify the attributes of the Protected Information referenced by

a policy.

Multiplicity Notes

Attribute 'InformationReference.category' of type 'CategoryType'

[0..1] Information category (e.g., medication, allergies, laboratory).

Attribute 'InformationReference.confidentialityIndicator' of type 'ConfidentialityCode'

[0..1] The confidentiality indicator is a coded attribute that assigns access controls on Individual health records based on the information or type of access.

Attribute ‘InformationReference.dataIntegrity’ of type ‘IntegrityCodeList’

[0..1] The integrity indicator is a coded attribute that assigns access contols on individual health records based on the integrity values of an information object.



4.10.7 Class: Subject of Record

Multiplicity Notes

Attribute 'InformationReference.sensitivity' of type 'Sensitivity'

[0..1] This is a coded attribute that describes the sensitivity of an information artifact. Sensitivity is a characteristic of a resource which implies its value or importance and may include its vulnerability [ISO 7498-2:1989]. Sensitivity may be associated with the Subject of Record or information artifact.

4.10.8 Class: InformationObject

This class represents a reference to specific type of information object that may be referenced

by a policy. This information object refers to the types of objects that may be used in a permission

(e.g., a category of lab orders, document types, etc.)

Multiplicity Notes

Attribute 'InformationObject.code' of type 'ObjectCode'

[0..1] Coded attribute that identifies the type of object referenced in the policy.

Attribute 'InformationObject.sensitivity' of type 'Sensitivity'

[0..1] This is a coded attribute that describes the sensitivity of an information artifact. Sensitivity is a characteristic of a resource which implies its value or importance and may include its vulnerability [ISO 7498-2:1989]. Sensitivity may be associated with the Subject of Record or information artifact.

4.10.9 Class: Target

This class represents Information Objects subject to access control.

Multiplicity Notes

Attribute ‘Target.name’ of type ‘String'

[1..*] The information entity referenced in an access control request. See Information Object.

Attribute ‘Target.accessControlIdentity’ of type ‘AccessControlId’

[*] The identity of an access control service (e.g. an access enforcement function)

Attribute ‘Target.sensitivityMarking’ of type ‘Sensitivity’

[0..*] Security label metadata that “segments” an IT resource by categorizing the value, importance, and vulnerability of an IT resource perceived as undesirable to share.



Multiplicity Notes

See HL7 Healthcare and Privacy Classification (HCS) System.

Attribute ‘Target.integrityMarking’ of type ‘IntegrityCodeList’

[0..*] Metadata that "segments" an IT resource by conveying the completeness, veracity, reliability, trustworthiness, and provenance of an IT resource

See HL7 Healthcare and Privacy Classification (HCS) System.

Attribute ‘Target.containerID’ of type ‘Id’

[1] Identiy of the container that encompasses a target



4.10.10 Class: Target-Bound ACI

Forms include labels and access-control lists. Target-bound ACI is not necessarily delivered

by the target.

Multiplicity Notes

Attribute ‘Target-BoundACI.initiatorAccessControlIdentity’ of type ‘Id’

[0..*] Individual initiator access control identities and the accesses on the target allowed or denied to them.

Attribute ‘Target-BoundACI.hierarchicalGroupAccessControlIdentity’ of type ‘HierarchicalGroup’

[0..*] Hierarchical group membership access control identities and the accesses on the target allowed or denied to them.

Attribute ‘Target-BoundACI.functionalGroupAccessControlIdentity’ of type ‘FunctionalGroup’

[0..1] Functional group membership access conrol identities and the accesses on the target allowed or denied to them.

Attribute ‘Target-BoundACI.RoleAccessControlIdentity’ of type ‘Role’

[0..*] Role access control identities and the accesses on the target allowed or denied to them.

Attribute ‘Target-BoundACI.AuthoritiesAccesses’ of type ‘Authorities’

[0..*] Authorites and the accesses authorized to them.

4.10.11 Class: PublicServices

This class references the public service program that produced the information. This may be

an important criterion in privacy policies -especially jurisdictional policies. This class is specified

to draw a clear distinction between the privacy policies that affect patients who receive healthcare

services paid by public programs versus private insurance or self-pay.

Multiplicity Notes

Attribute 'PublicServices.type' of type 'PublicCoverageType'

[0..1] This attribute specifies the type of public program that provided coverage for the services documented in the electronic health records. Policies governing services rendered by some public programs may operate under more restrictive confidentiality constraints than others. Example: Substance Abuse and Mental Health Services Administration (SAMHSA) under CFR 42 Part 2.



4.10.12 Class: Section

A section is a context that subdivides the body of a clinical document. Document sections are

typically used for human navigation, to give a reader a clue as to the expected content. Document

sections are used to organize and provide consistency to the contents of a document body.

4.10.13 Class: SubjectOfRecord (Abstract)

This abstract class represents the type of subject of record: Individual/patient or population.

4.10.14 Class: Individual

This class is intended to capture the properties of an Individual/'Patient' who is the subject of

a privacy ConsentDirective. See 'Actors' specified in the Use Case Analysis for additional detail.

The consenter may be the person whose preferences it represents (the Individual/patient) or their

designated Substitute Decision Maker (SDM).

Multiplicity Notes

Attribute 'Individual.keywordDigitalId' of type 'Integer'

[0...1] This is a private attribute. A private attribute is one that is accessible only to the class itself --it cannot be used by any outside class. This keyword/shared secret may be used by a patient to provide temporary access to their electronic health records. This attribute is required to support HL7 Security and Privacy Domain Analysis Model Security use case P.12 which originated in Canada.

4.10.15 Class: Consenter

This class is intended to capture the properties of a Consenter/Substitute Decision Maker – see

'Actors' in Section 3.1.

Multiplicity Notes

Association ‘Consenter.relationship’ of type ‘RelationshipCode’

[0..*] Individual who signs the patient Consent Directive. May be the Subject of Care or other authorized person (e.g. holder of Power of Attorner, Spouse, etc.)

Attribute ‘Consenter.recordLocation’ of type ‘String’

[0..1] Location of consent.

Attribute ‘Consenter.signatureRecorded’ of type ‘Boolean’

[0..1] If a digital signature is allowed by policy, this attribute indicates whether a signature was captured.

Attribute ‘Consenter.name’ of type ‘String’

[0..1] Name of consenter



4.10.16 Class: Population

This class specifies that the target of a policy may be an entire population. This class may be

used to specify a privacy policy that applies to a specific group or population.

Multiplicity Notes

Attribute 'Population.description' of type 'String'

[0..1] Text description of the population covered by the privacy policy.

Attribute 'Population.type' of type 'PopulationCode'

[0..1] Type of population affected by the policy.

4.10.17 Class: Clinical Condition

This class is used to represent the health condition(s) associated with the policy. Conditions

when specified, are coded concepts expressed in a standard vocabulary (e.g., LOINC, SNOMED

CT, etc.). These may include indications of 'substance abuse' or 'HIV-related' illnesses, etc. An

obligationCode may be implemented as a 'condition.'

4.11 Privacy Policy Viewpoint

The Privacy Policy viewpoint describes the attributes of a privacy policy that may be

exchanged between systems in a semantically-interoperable manner across organization

boundaries. The information model described here embodies the analysis of information

requirements provided by business stakeholders. The following assumptions have been made for

the analysis of electronic policies: 1. Platform-independence - electronic Privacy Policies must be

exchanged between a variety of systems using different means of decoding and evaluating the

electronic privacy policies. Security infrastructure systems often employ unique and proprietary

approaches for their enforcement mechanism; therefore, the electronic Privacy Policy must be

expressed in a platform-independent way allowing ample flexibility for use in these systems. 2.

Standard-based - electronic Privacy Policies must use standard structures and terminology to

ensure interoperability across a variety of systems and organizations.



Figure 7 Privacy Policy Structure Overview Diagram

Figure 7 Privacy Policy Structure Overview Diagram9 shows the elements of a privacy policy from

a jurisdictional or organizational standpoint. Electronic privacy policies are exchanged in a

platform-independent, semantically interoperable, and standard-based way. A privacy policy is

intended to safeguard protected Information10 from unauthorized use and disclosure. This diagram

illustrates the Privacy Policy structure specified in the 'Composite Privacy LDM - Draft Standard

for Trial Use'.

4.12 Privacy Policy Classes

The following classes support the definition of privacy policies. While these classes are reused

in the other viewpoints, they were initially specified to support the needs of privacy policy makers

to define computer-ready policies.

9 Adapted from HL7 Version 3 Domain Analysis Model: Composite Security and Privacy, May 2020 10 Protected Information is information that is protected by a security policy. In healthcare, this includes a variety of

clinical and administrative information that can be identified as belonging to a specific healthcare individual.

Individually identifiable health information (IIHI) is a sub-type of Protected Information. Security Glossary HL7

2008(c), Version 3



4.12.1 Class: Authority (Abstract)

This abstract class is used to designate the authority that issues the policy. Authority is an

organization (either Jurisdictional or Provider) that is responsible for the Privacy Policy. This is

the authority that grants authorizations described in the privacy policy. This class is consistent with

the 'Security Authority' specified by the ISO/IEC 15816 standard as 'the entity accountable for the

administration of a security policy within a security domain'.

Multiplicity Notes

‘Authority.domain’ of type ‘String’

[0...1] This attribute represents the registered domain name of the healthcare organization that issues a specific privacy policy used to uniquely identify the Authority.

4.12.2 Class: Grantee (Abstract)

This class is used to delegate specific rights to a grantee (such as an Individual or

Clearinghouse). The 'Grantee' is not necessarily an authority; the Grantee may be an Individual,

Substitute Decision Maker, or an organization. For example, in the case of substance abuse related

information, under certain conditions the authority to grant, withhold, or withdraw consent to the

disclosure of the information is granted to the Individual. In another example, a Clearinghouse

may act as an agent/proxy for a provider organization as an intermediary and therefore can be a

grantee as well.

4.12.3 Class: PrivacyPolicy

This is the focal class for electronic privacy policies. It contains a set of rules that are intended

to be enforced by security systems and are used as the basis for Individual privacy consent

directives. This class encapsulates the location of a human-readable version of the Electronic

Privacy Policy. The human-readable version is accessible to any authorized system and user via

the supplied URI.

Multiplicity Notes

‘PrivacyPolicy.policyId’ of type ‘oid’

[1...1] This attribute specifies the unique identifier of for a privacy policy.

‘PrivacyPolicy.description’ of type ‘String’

[0...1] This attribute is a narrative description of the privacy policy.

‘PrivacyPolicy.uri of type ‘String’

[0...1] This attribute specifies the location of published policy.

‘PrivacyPolicy.authority’ of type ‘Authority’

* This is an association to the Authority that issued the policy.



4.12.4 Class: PrivacyRule

A PrivacyRule specifies the permission allowed to a user type by the consenter for a specific

type of information. The person consenting may be either the subject of the record (the Individual)

or the Individual's designated Substitute Decision Maker. One or more PrivacyRule instances

comprise a privacy Consent Directive or PrivacyPolicy. A PrivacyRule is equivalent to a

BasicPolicy. A specific individual’s privacy consent directive consists of several rules that map to

BasicPolicy instances. A PrivacyRule, from the Privacy viewpoint perspective, is equivalent to a

BasicPolicy from a Security viewpoint perspective.

BasicPolicy instances comprise a CompositePolicy and PrivacyRule instances are grouped

together to form a ConsentDirective.

Multiplicity Notes

‘PrivacyRule.obligation’ of type ‘ObligationCode’

[0...1] This coded attribute specifies a pre-defined obligation associated with a policy or consent.

‘PrivacyRule.purposeOfUse’ of type ‘PurposeCode’

[0...1] This attribute is used to specify the purpose to permit a specific type of action/operation according to the policy. Some

examples include: Treatment, Payment, Public Health, Research

‘PrivacyRule.effectiveTime’ of type ‘dateTime’

[1...1] This attribute specifies the date/time when the Privacy Policy comes into effect.

‘PrivacyRule.enable’ of type ‘Boolean’

[1...1] Based on its value, this attribute describes whether the operation is enabled (allows

disclosure) or disabled (prohibits disclosure)

4.12.5 Class: ProviderOrganization

Multiplicity Notes

'ProviderOrganization.address' of type ' AD'

[*] Organization address.

'ProviderOrganization.name' of type ' ST'

[0...1] Organization name.

‘ProviderOrganization.providerId’ of type ‘UUID’

[0...1] Unique provider identifier.

'ProviderOrganization.providerType’ of type ' ProviderTaxonomy'

[0...1] The provider type may be based on the provider's specialty or certification. This attribute is intended to be coded.

The run-time functional relationships among Initiator ADI, Target ADI, and Policy (patient

policy has been included as part of PrivacyPolicy). The model illustrates the Initiator making a

query for information from a Target (InformationResource Class) under control of an Information

Owner (not shown).



Based on an underlying Initiator/Information Owner mutual trust framework, the central

Access Control Decision Function (AEF and ADF) evaluates all relevant ADI (including

contextual and retained ADI) using the policy rules in effect in order to make and enforce a

response decision (i.e., whether the information should be released, and the request fulfilled or

not).

The decision is based upon evaluating policies some of which derive from the shared trust

framework, those belonging to the Information Owner and those which include accepted patient

policy preferences/consent.

4.13 Privacy Consent Directive Viewpoint

Figure 8 Consent Directive Overview Diagram11

A Privacy Consent Directive is defined as 'an instruction regarding consent and contextual

conditions to collect, use, and/or disclose Personal Health Information.' This definition is adapted

from the British Columbia, E-Health (Personal Health Information Access and Protection of

Privacy) Act, S.B.C. 2008, c. 38, s. 1. A Consent Directive is also referenced as a 'Data Consent'

to be distinguished from other types of consents including consent to receive a procedure or

service. In the United States, Consent Directives are the consumer-based set of options regarding

the consumer's preferences in regard to the control (access, use, disclosure, collection, etc.) of their

electronic health records.12

11 Adapted from HL7 Version 3 Domain Analysis Model: Composite Security and Privacy, May 2020 12 Security Glossary HL7 2008(c), Version 3.



The Consent Directive viewpoint describes the structure and attributes of privacy consent

directives issued by Individuals in the context of a default/existing privacy policy. These privacy

consent directives are intended to be exchanged as messages or documents containing structured

content. Figure 1.4 describes the structure of those directives as specified by an Individual in order

to stipulate additional privacy rules.

As seen here, the privacy consent directive references one or more policies and contains a set

of consent rules. The privacy consent directive is expressed using a permission, information

category and user role, similar to the way privacy policy rules are described. This is not surprising

considering that an Individual's privacy consent represents a further constraint of default privacy

policies applicable in that territory.

4.14 Subject of Care Consent Directive Classes

The following section details the classes derived from analyzing the information required to

convey a privacy consent directive.

4.14.1 Class: ConsentDirective

This is the focal class representing a set of privacy consent directives issued by a Subject of

Care consenter on behalf of self or someone else. This is the root or entry class into the privacy

ConsentDirective structure.

The privacy ConsentDirective may be published to a registry. If an Individual’s privacy

consent directive is published, a URL/URI is made available for reference. The Individual may

use this URI to allow providers access to the privacy consent directive created by the consenter.

Multiplicity Notes

'ConsentDirective.documentImage' of type ' base64Binary'

[0...1] This optional attribute references a signed paper document containing the Individual's privacy consent directive.

'ConsentDirective.effectiveTime' of type ' dateTime'

[1...1] This attribute specifies the date when the policy/consent is in effect.

'ConsentDirective.expirationTime' of type ' dateTime'

[0...1] This attribute specifies when the privacy

consent directive automatically expires. A privacy consent directive may be revoked prior to its expiration date.

'ConsentDirective.id' of type ' oid'

[1] This attribute specifies a unique identifier that refers to a specific privacy Consent Directive instance. This id or the published URI may be used to lookup the Individual's privacy consent directives in order to apply them to the collection, access, use or disclosure of health records.

'ConsentDirective.reasonCode' of type ' '

[1] This attribute is used to specify the reason for revoking a privacy Consent Directive (e.g., requested vs. correction/error). An error would



Multiplicity Notes

be a discrepancy between the intent of privacy Consent Directive (as communicated by the Consenter) and that which was entered into the Consent Directive Management System (CDMS).

'ConsentDirective.statusCode' of type ' '

[1] This attribute indicates whether the privacy consent directive is active or not.

'ConsentDirective.uri' of type ' String'

[0..1] If a specific privacy consent directive (for an Individual) is published, this attribute provides the means to locate and download the privacy consent directive from a registry.

5 COMPUTATIONAL VIEWPOINT

5.1 Computational Model and Viewpoint

The computational viewpoint is modeled after the access control concepts of . [ISO 10181-

3/ITU X.812]. The interaction between the Initiator and an information Custodian is assumed to

be between independent entities exercising pre-negotiated interoperability criteria. Such features

involve transport, syntactic and semantic interoperability following Health Information and

Management Systems Society definitions (See Appendix C).

The precise nature of these interactions may vary considerably depending upon use case (health

information exchange, research, etc.). In many cases, the rules of the exchange will be facilitated

by a formal Trust Framework whereby the requirements of secure exchange (e.g, required ADI)

are specified between Initiator and Organization (data manager). While a formal trust framework

is not a requirement of the model, it is assumed that the entities will have agreed to some equivalent

mutual understanding of how the exchange and protection of received information will progress

including any enduring obligations on the part of the recipient.13

5.2 Overview

This section describes the actors and processes of the LDM Computational View from the

perspective of access control.

The fuel for access control services is information…specifically access control information.

Which is any information that is needed to evaluate the rules of attempted access to a protected

resource. It involves information about the:

Requestor (Initiator)

Resource (Target) and,

Request context.

13 See HL7 Version 3 Standard: Privacy and Security Architecture Framework, Release 1, July 2020, Volume 1: Trust

Framework for Federated Authorition, Conceptual Model

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




In access control, it is up to healthcare management services and trust agreement policy to

determine which set of attributes a requester must possess in order to access protected health care

information. Information attributes are linked to associated health care policies that the access

decisions must support.

In addition, Custodian access control policies are used to evaluate a variety of request scenarios

to ensure the proper use of computer systems and the protection of sensitive data and resources.

The information describing these policies requires standard and interoperable representations as

well so that security and privacy protections can be enforced across heterogeneous systems using

automated controls.

5.3 Information View

Figure 9 Logical Data Model Class Overview



Figure 9 describes elements of a security policy from the perspective of a Custodian Domain

Access Control Decision Function (ADF) (i.e., the authority for making an access control decision.

It also illustrates alignment with ISO 22600. It details the classes, attributes, and associations

representative of the conceptual viewpoints (Requestor Policy, Custodian Policy, Patient Policy)

that constitute the computational classes of the LDM.

Red-framed classes represent the policies of the organization/jurisdiction. These policies

contain statements which if evaluated successfully, indicate that the conditions allowing

for a response have been verified. This process of verification and validations follows the

general evaluation of propositions such as: “If X then Accept, else Deny”

Green-framed classes represent information/data which may be provided by either the Initiator the Custodian or the Patient

Purple-framed classes indicate all other classes

Retained Information is information kept from one request instance to another

Contextual Information is specific to the particular conditions of the current request

Required data supporting a request may be referenced to a pre-existing trust framework

negotiation. Patients may also submit preferences related to the use and disclosure of their own

information. Patient preferences are incorporated into the organization’s privacy policy.

5.4 Computational View

Figure 10: Access Control Model



Figure 10 illustrates the activities, ADI and classes involved in computing a response to an

Initiator’s request. Actors in the Computational View workflow are illustrated using LDM Class

Diagrams from Section 1.

1. Trust Framework. Prior to any access request, both the Initiator and the

Jurisdiction/Organization (Healthcare Provider) agree to conduct information exchange and establish the policy that define the conditions under which an access can take place.

2. Initiator. An Initiator makes a request for protected healthcare information access to an

external Healthcare Provider Target. As part of the request, the initiator provides certain

Access Request Decision and Initiator Access Control Decision Information ACI such a

role, clearance, relationship, etc.

3. Healthcare Provider. The receiving Healthcare Provider validates the requester’s identity

and ACI, along with using other internal ADI used to make an Access Control Decision.

Certain contextual information about or derived from the context is established such as

ADI derived from target-bound ACI. Additionally, ADI is derived from operand-bound

ACI.

4. Access Control. The Organization’s Access Control Decision Function makes access

control decisions by applying access control rules to an access request, ADI (that portion,

possibly all ACI made available to the ADF including access request bound ADI, ADI of

initiators, targets, or that retained from prior decisions), and the context in which the

access request was made.

5. Access Enforcement (Grant or deny access). Finally, the Access Control Enforcement

Function (AEF) acting as part of the access path between Initiator and Target, enforces

the decision made by the ADF.

Summary Workflow

The Initiator submits an Access Request to a Healthcare Organization consistent with the pre-

agreed Trust Framework including:

The operations and operands that form part of the attempted access

ACI about the operands, operand-bound ACI, and request ACI (including any access

control tokens).

Processing

Target information (InformationReference) ADI relevant to the request is collected,

Any ContextualInformation and RetainedInformation ADI from previous requests is collected,

Access Control Policy relevant to the decision environment is collected.

The Access Control Decision Function (ADF) then computes a decision as to whether or not

the request meets the requirements of the corresponding (Access Control) Policy.

Enforcement

The AEF enforces the ADF decision by providing a Response back to the Initiator (either

providing or denying the Initiator’s Request) including any Obligations.



Appendix A: Terms and Definitions

Access Control Terms

The following terms are from International Telecommunication Union (ITU) X.812

INFORMATION TECHNOLOGY –OPEN SYSTEMS INTERCONNECTION –SECURITY

FRAMEWORKS FOR OPEN SYSTEMS: ACCESS CONTROL FRAMEWORK dated 11/95

access control certificate A security certificate that contains ACI.

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

Access Control Decision Function (ADF) A specialized function that makes access control decisions by applying access control policy rules to an access request, ADI (of initiators, targets, access requests, or that retained from prior decisions), and the context in which the access request is made.

Access Control Enforcement Function (AEF) A specialized function that is part of the access path between an initiator and a target on each access request and enforces the decision made by the ADF.

Access Control Information (ACI) Any information used for access control purposes, including contextual information.

access control policy The set of rules that define the conditions under which an access may take place.

access control token A security token that contains ACI.

access request The operations and operands that form part of an attempted access.

access request access control decision information

Access request ADI. ADI derived from access request-bound ACI.

access request access control information Access request ACI. ACI about an access request.

access request-bound access control information

Access request-bound ACI. ACI bound to an access request.

clearance Initiator-bound ACI that can be compared with security labels of targets.



contextual information Information about or derived from the context in which an access request is made (e.g., time of day).

initiator An entity (e.g., human user or computer-based entity) that attempts to access other entities.

initiator access control decision information Initiator ADI. ADI derived from initiator-bound ACI.

initiator access control information Initiator ACI. ACI about an initiator.

initiator-bound access control information Initiator-bound ACI. ACI bound to an initiator.

operand access control decision information Operand ADI. ADI derived from operand-bound ACI.

operand access control information/operand ACI

ACI about the operands of an access request

operand-bound access control information Operand-bound ACI. ACI bound to the operands of an access request.

retained ADI ADI which has been retained by an ADF from earlier access control decisions for use in future access control decisions.

target An entity to which access may be attempted.

target access control decision information Target ADI. ADI derived from target-bound ACI.

target access control information Target ACI. ACI about a target.

General Terms

The following terms are defined relative to this Logical Data Model.

Requestor Domain An authority that administers a group of Initiators with a common set of rules.

that can make requests for information from a Custodian. A Requestor Domain may have many Initiators.

Initiator The entity member of a Requestor Domain that can make information requests from an information Custodian Domain.

Domain A group of that can be accessed and administered with a common set of rules.



Subject of Care The subject of an information request who may also specify/request personal access control policy to be enforced by a Custodian.

Custodian: An individual or organization that collects, uses, or discloses Protected Information (PI) for the purposes of care and treatment, planning and management of the health system or health research. Security Glossary HL7 2008(c), Version 3

Privacy Consent Directive: A patient’s instructions regarding consent and contextual conditions to collect, use, and/or disclose Personal Health Information.' This definition is adapted from the British Columbia, E-Health (Personal Health Information Access and Protection of Privacy) Act, S.B.C. 2008, c. 38, s. 1. A Consent Directive is also referenced as a 'Data Consent' to be distinguished from other types of consents including consent to receive a procedure or service. In the United States, Consent Directives are the consumer-based set of options regarding the consumer's preferences in regards to the control (access, use, disclosure, collection, etc.) of their electronic health records.

Protected Information (PI): Protected Information is information that is protected by a security policy. In healthcare, this includes a variety of clinical and administrative information that can be identified as belonging to a specific healthcare individual. Individually identifiable health information (IIHI) is a sub-type of Protected Information.

Purpose of Use Reason for performing one or more operations on information, which may be permitted by source system’s security policy in accordance with one or more privacy policies and consent directives. Description: The rationale or purpose for an act relating to the management of personal health information, such as collecting personal health information for research or public health purposes.

Concept Relationships: Specializes: _ActHealthInformationManagementReason Generalizes (derived):



Information Object An abstract data model used to specify information about real-world objects.

Healthcare Classification System Glossary

The following terms are from the “HL7 Healthcare Privacy and Security Classification System (HCS), Release 1, 2019” (cited here in entirety for completeness)

Term Note that hyperlinked terms are either links back to text or to related terms.

Definitions and Descriptions Note that where no source is specified, the terms are defined in the context of HCS. Some entries are authoritative descriptions about the use of the term and may contain the term being defined in this glossary. These descriptions are not considered definitions.

Access (Security) Level The combination of a hierarchical security classification and a security category that represents the sensitivity of an object or the security clearance of an individual. [ISO 2382-8] A level associated with an individual who may be accessing information (for example, a clearance level) or with the information which may be accessed (for example, a classification level). [HIPAA

Security Glossary]

Access Control Decision Information (ADI)

The portion (possibly all) of the ACI made available to the ADF in making a particular access control decision. [ISO 10181-3/ITU X.812]

Access Control Information (ACI)

Any information used for access control purposes, including contextual information. [ISO 10181-

3/ITU X.812]

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

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








Access Control Service A service that provides the basic operational aspects of access control such as making ADI available to access decision components and performing access control functions. The service also provides security labeling and privacy and security protection functions.

The service, known as an Access Control Service (ACS), requires the following information:

Access policy rules, Contextual information needed to interpret ADI,

Initiator, target, and access request ADI,

Security labeling rules and vocabulary,

Transform rules and services.

ACS generates information made available to other elements includes transformed information response to an information request as well as handling caveats. [HL7 PASS-Security Labeling Service]

Classification Child concept: Security Classification

Confidential protection of data elements by segmentation into restricted and specifically controlled categories set by policies. [Adapted from ASTM E-1986]

Clearance Initiator-bound access control information (ACI) that can be compared with security labels of targets. [ISO 10181-3/ITU X.812]

Permission granted to an individual to access data or information at or below a particular security level. [ISO/IEC 2382-8:1998]

Clinical attribute Any clinical characteristic that binds a health care relevant parameter to a clinical element by a rule. Parameters may include authorship, category of information, terminological characteristics, history of permutations, integrity, and provenance, as well as the relationship to and inclusive of associated clinical facts necessary to provide context essential for applying security labels. [PCAST] discusses attributes that provide context to clinical data elements such as patient demographics.]

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

Clinical element A clinical object that has been disaggregated into the smallest possible data element suitable for use in a healthcare context. [PCAST p. 70 description of clinical elements as the smallest clinical data units that make sense to exchange and aggregate.]

Clinical fact A healthcare data IT resource comprised of a clinical element associated or “tagged” with at least one clinical attribute such as a clinical information category, patient information, and provenance. A clinical fact is a type of “tagged data element.” [PCAST p. 89 “Tagged data element: Data accompanied by metadata describing the data.”]

Clinical rule A computational algorithm used for assigning a clinical attribute to a clinical element.

Compartment A security label tag that "segments" an IT resource by indicating that access and use is restricted to members of a defined community or project.


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







A set of categories in a security label. [Sandhu]

Compartment-based policies

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

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

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

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

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

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

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

GWU]

Healthcare Privacy and Security Classification System (HCS)

A defined scheme for the classification and handling of health care and healthcare related information.

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

Data, service or system component. [XACML]

The term resource embraces (e.g., information resources, processing resources, communication resources, and physical resources). [Ford]

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

Metadata Data about other data. [ISO 14721]





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

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

Information that characterizes data, such as contextual information. [PCAST]

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

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

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

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

Privacy The claim of individuals, groups or institutions to determine for themselves when, how, and to what extent information about them is communicated to others. [Westin] This definition is foundational for Privacy Act of 1974 (P.L. 93579; 5 U.S.C. § 552a).

Freedom from intrusion into the private life or affairs of an individual when that intrusion results from undue or illegal gathering and use of data about that individual. [ISO/IEC 2382-8]

The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed. [ISO 7498-2]

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

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

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

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

Provenance

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


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

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

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






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

PROV-Overview]

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

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

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

evidence to support Authenticity. [ISO 14721)

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

Characteristic of a subject, resource, action or environment that may be referenced in a predicate or target. [ XACML]

Security Classification The determination of which specific degree of protection against access the data or information requires, together with a designation of that degree of protection. Examples: "Top secret", "secret", "confidential". ISO 2382-8/T-REC-X.812-199511-I!!PDF-E

Security Label Synonymous with Target Label

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

The means used to associate a set of security attributes with a specific information object as part of the data structure for that object [ISO 10181-3/ITU X.812]

Access control information associated with the attribute values being accessed. [ISO/IEC 9594-

2:2008/ITU X.501]

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

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

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


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


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






The marking bound to a resource (which may be a data unit) that names or designates the security attributes of that resource. NOTE - The marking and/or binding may be explicit or implicit. [ISO

7498-2/CCITT Rec. X.800]

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]

Security labels may be used to associate security-relevant information with attributes within the Directory. Security labels may be assigned to an attribute value in line with the security policy in force for that attribute. The security policy may also define how security labels are to be used to enforce that security policy. A security label comprises a set of elements optionally including a security policy identifier, a security classification, a privacy mark, and a set of security categories. The security label is bound to the attribute value using a digital signature or other integrity mechanism. [ISO/IEC 9594-2:2008/ITU X.501]

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

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

A security label is a type of PCAST Metadata Tag defined as “information that characterizes data, such as contextual information.”

Security (Labeling) Policy

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

Security label rule A computational algorithm used for assigning a security label to an IT resource such as a clinical fact.

Security Policy Information File (SPIF)

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

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

Security Tag A type of Security Metadata

Information unit containing a representation of certain security-related information (e.g., a restrictive attribute bit map). [NIST FIPS PUB 188]

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

Sensitivity The characteristic of a resource which implies its value or importance and may include its vulnerability. [ISO/IEC 7498-2:1989/CCITT Rec. X.800]

Sensitivity Label Security labels which support data confidentiality models, like the Bell and LaPadula model. The sensitivity label tells the amount of damage that will result from the disclosure of the data and also indicates which measures the data requires for protection from disclosure. The amount of



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


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


http://www.xmlspif.org/?page_id=51







damage that results from unauthorized disclosure depends on who obtains the data; the sensitivity label should reflect the worst case. [IETF RFC 1457]

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

Target

A target is a resource subject to access control. [Ford]

The set of decision requests, identified by definitions for resource, subject and action that a rule, policy or policy set is intended to evaluate. [XACML]

A target is an IT resource for which an initiator seeks access.

Target Label Synonymous with Security Label

A security label can be used as target ACI to protect a target. Access rules define the access permissions (operations) granted given the security label of the initiator and the security label assigned to a target. If the security policy requires that the ACI held in the security label are used for target ACI, then overall flow of data in and out of that target can be controlled. Hence, the overall flow of data in and out of targets may be analyzed for security domains applying the same security policy. Targets can be created within other targets. The security label of the containing target limits the security labels that may be assigned to the contained target under the rules for the appropriate security policy. Examples of targets to which labels may be applied include: OSI n-entities; Directory Service entries; files held in a file store; database entries. [ISO 10181-3/ITU X.812]

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





Appendix B: Citations

Attribute-Aware Relationship-Based Access Control for Online Social Networks,

https://link.springer.com/chapter/10.1007/978-3-662-43936-

4_19#:~:text=Relationship%2Dbased%20access%20control%20(ReBAC,access%20requester%

20and%20the%20target.






Appendix C: HIMSS Interoperability Defined

What is Interoperability?

It is the ability of different information systems, devices, and applications (systems) to access,

exchange, integrate and cooperatively use data in a coordinated manner, within and across

organizational, regional, and national boundaries, to provide timely and seamless portability of

information and optimize the health of individuals and populations globally.

Health data exchange architectures, application interfaces and standards enable data to be

accessed and shared appropriately and securely across the complete spectrum of care, within all

applicable settings and with relevant stakeholders, including the individual.

Four Levels of Interoperability

Foundational (Level 1): Establishes the inter-connectivity requirements needed for one

system or application to securely communicate data to and receive data from another

Structural (Level 2): Defines the format, syntax and organization of data exchange including at the data field level for interpretation

Semantic (Level 3): Provides for common underlying models and codification of the

data including the use of data elements with standardized definitions from publicly

available value sets and coding vocabularies, providing shared understanding and

meaning to the user

Organizational (Level 4): Includes governance, policy, social, legal and organizational

considerations to facilitate the secure, seamless and timely communication and use of

data both within and between organizations, entities and individuals. These components enable shared consent, trust and integrated end-user processes and workflows

https://www.himss.org/resources/interoperability-healthcare

https://www.himss.org/resources/interoperability-healthcare



Appendix D: Related Standards

ANSI/INCITS 359-2012 (R2017) Information Technology - Role Based Access Control,

OASIS SAML and XACML Profiles,

ITU-T Rec. X.812 (11/95) Information technology-Open Systems Interconnection-Security frameworks for open systems: Access control framework,

ISO/IEC 15816:2002 (R2018) Information technology — Security techniques — Security information objects for access control,

ISO 22600-1:2014 (R2020) Health informatics — Privilege management and access control — Part 1: Overview and policy management,

HL7 Version 3 Standard: Healthcare (Security and Privacy) Access Control Catalog, Release 3,

HL7 Version 3 Standard: Privacy, Access and Security Services (PASS); Access Control, Release 1,

HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling Service, Release 1 (SLS),

HL7 Version 3 Standard: Privacy and Security Architecture Framework (PSAF), Release 1

HL7 Healthcare Privacy and Security Classification System (HCS), Release 1

HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1

Standard: Healthcare (Security and Privacy) Access Control Catalog, Release 3

HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling Service, Release 1 (SLS)

HL7 Privacy and Security Architecture Framework

HL7 Healthcare Privacy and Security Classification System (HCS), Release 1, June 2019

HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1

Standard: Healthcare (Security and Privacy) Access Control Catalog, Release 3

HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling Service, Release 1 (SLS)

HL7 Privacy and Security Architecture Framework















HL7 Privacy and Security Logical Data Model, HL7 Normative ...

Documents

HL7 Guidelines

Delphi HL7 Guide · Delphi HL7 Guide 2-18 Introduction...

“Reducing Clinician Burden” Project Overview · HL7 EHR...

HL7 Specifications ADT-MDM - HL7 Reference

HL7 Tutorial

The HL7 Evolution: Comparing HL7 versions 2 and 3

NMI HL7 Case Notification Implementation Guidebook ... ·.....

HL7 ---- N5

HL7 European Office · HL7 EUROPE NEWS HL7 European Office....

CDISC & HL7 · CDISC & HL7 The Strategy of Cooperation...

Catching FHIR - HL7 › wp-content › uploads › 2015 ›....

Parte_1_Introduccion HL7