Role of the HL7 Security and Privacy Ontology in HL7 Artifacts

Kathleen Connor VA (ESC)HL7 Security WG

March 6, 2012

Use of Security and Privacy Ontology

• Authoring, adjudication, and enforcement of security and privacy policies within and among enterprises as well as across multiple jurisdictional boundaries requires the use of rigorously defined privacy and security terminologies and the semantic structures by which they are conveyed

HL7 Security and Privacy Ontology

• The HL7 Security and Privacy Ontology is a domain specific Conceptual Data Model structured as an ontology rather than a UML model

• The Ontology plays a pivotal role as the “source of truth and logical soundness” for HL7 Security and Privacy artifacts, and is available for use by other SDOs– IHTSDO has already agreed to incorporate the S&P

Ontology as a concept hierarchy

Scope of Use

• Managing S&P Terminologies and validating their correct use within semantic structures requires that these be organized within an ontology

• Particularly important for complex machine readable rules used to automate privacy and security policies and the numerous models underlying the manner in which these are structured

S&P Terminology Service

• Terminology services implementing S&P Ontology are critical components for:– Security Access Control Systems– EHR Data Segmentation– Compliant Disclosure, Exchange, and Receipt of

Protected Information– Privacy Policy Administration Systems– Consent Directive Management Systems

What is the S&P Ontology?

• Identifies and defines OWL classes and interrelationships for key security and privacy concepts

• Enables computable and interoperability policies• Prerequisite to implementations that protect sensitive

health information• Design Time uses

– Policy authoring– Validation of completeness and consistency

• Run Time uses– Policy Adjudication (resolving multiple policies that may conflict)– Policy Bridging (using governance to manage rules from differing

policy contexts)– Policy Decisions

Ontological Relationships Change Semantics

• For example, a security systems may deploy both role-based and rule-based access control policies

• Each uses the same terminology, e.g., for structural roles, but with different associations to other classes within the policy.

• Under the role-based access control policy, a structural role may have a higher priority in the policy decision adjudication than it has in the rule-based access control decision adjudication where the sensitivity attributes of the user has precedence over the user’s structural role

• ISO/IEC 10181-3:1996 Information technology -- Open Systems Interconnection

TSC Guidance on Ballot LevelsCriteria for qualifying for a Normative Standard • To be considered for a normative standard, the proposed

standard must describe how conformance to the standard will be determined

• In addition, a normative standard is one which provides a mechanism for applying constraints to that standard – For instance, HL7 Version 2.x has an entire chapter devoted to

describing conformance to and applying constraints to the 2.x standard– HL7 Version 3 has a section on Refinement, Constraint and Localization

that serves the same purpose• Need to determine if Arden Syntax, CCOW, EHR FM, etc. can

meet this definition

Normative Ballot Track

The HL7 Security Work Group intends to ballot the Security and Privacy Ontology as a normative standard• Conformance criteria include use as

– The Security and Privacy Conceptual Data Model for all of the HL7 v.2 and v.3 security and privacy artifacts

– Source of logical definition for HL7 Security and Privacy vocabularies– For use by privacy and security system implementers as a Security and Privacy

Terminology Service in accordance with the HL7 Common Terminology Service R2 conformance criteria

• Refinement, Constraint and Localization– Ontology is highly modular enabling implementation of specific branches as

required for refinement, constraints, and localization, e.g., • The Structural Role branch without the clinical information categories• Administrative functional roles without the clinical functional roles• Realm specific Privacy Law codes specific to a jurisdiction

– Ontology provides guidance on applying constraints

Meeting HL7 Draft Criteria for Normative • From an HL7 perspective, constraints add further restrictions to a type of artifact (message, document,

value set, ontology, etc.) without allowing anything contrary to the specification of the constrained artifact. • OWL is extremely well suited to constraining ontologies in that way. For example:

– Using OWL, the S&P Ontology can be clearly and precisely constrained for a particular realm, a particular type of application, etc., using an additional sub-ontology for that realm, application, etc.

– An OWL reasoner can then determine whether the constraints are logically consistent with the original ontology, whether different sets of constraints are mutually consistent, etc.

– The modular design of the S&P Ontology promotes flexibility, so it would be relatively easy to substitute alternate sets of confidentiality and sensitivity classes

• The Security and Privacy Ontology September 2012 Normative Ballot will include a set of conformance clauses based on the S&P Ontology Project Scope statement 646 such as:– A conformant privacy and security policy authoring system, including electronic forms management, must

encode policies, including consent directives by invoking HL7 Privacy and Security Ontology terminology services

– A conformant clinical data repository must apply privacy and security metadata in accordance with policy by invoking HL7 Privacy and Security Ontology terminology services

– A conformant access control systems must invoke HL7 Privacy and Security Ontology terminology services to support policy decision and enforcement algorithms

• During the May and September ballot interim, the HL7 Security WG will develop, discussion and reach consensus on a comprehensive set of specific, testable conformance clauses

• Security WG will confer with the Conformance and Guidance for Implementation and Testing Work Group on HL7 conformance methodology.

Tony Weida’s Report on Security and Privacy OntologyFrom HL7 San Antonio WGM Jan 2012

So Much More than a Vocabulary

BACKGROUNDHL7 Security and Privacy Artifacts Leveraging the S&P Ontology

“Project Need” statement within the S&P Ontology Project Scope statement 646

• Providing security and protecting the privacy of electronic health records is a cornerstone to computable interoperability in enterprise and national electronic health record systems.

• The development and acceptance of a standard ontology of security and privacy concepts is needed to move toward this goal. This ontology will support multiple needs including:– Methods to describe security/privacy policy – Methods to improve the speed and efficiency of policy enforcement algorithms– Facilitation of efficient security and privacy management– Ontology driven privacy decision support– To provide a security and privacy viewpoint that can be mapped to other clinical

terminologies.

HL7 Security and Privacy Artifacts

• Role Based Access Control (RBAC) Healthcare Permission Catalog– Permission, operation, object, workflow, privacy

and security policy types, consent directive type, obligation, refrain, constraint, structural and functional role vocabularies

HL7 Version 3 Domain Analysis Model: Security, Release 1• The DAM provides the basis for semantic content

for HL7 v.3 Security and Privacy related artifacts• S&P Ontology reflects the DAM’s semantic content

requirements as a highly structured, comprehensive, and logically consistent set of terminologies that specifies interrelationship of concepts. This is critical for authoring, adjudicating, and enforcing machine readable privacy and security policies and patient consent directives

Consent Directive CDA

• HL7 Implementation Guide for Clinical Document Architecture, Release 2: Consent Directives, DSTU Release 1

• Provides support for alternative representations for expressing health information privacy consent directives in a standard form for the exchange of privacy policies that can be enforced by consuming systems (e.g., scanned documents, computable structured entries)

• Supports sending a computable representation of privacy consent directives using structured entries based on a mapping of the HL7 Version 3 Domain Analysis Model: Medical Records; Composite Privacy Consent Directive, Draft Standard for Trial Use (DSTU) Release 2 (CPCD DAM) to HL7 RIM attributes, or by using standard access control markup languages (XACML, XrML and others)

• It is expected that other SDOs will use the Privacy domain analysis model to create profiles (e.g., OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee) and that for encoding capabilities, formal policy languages will be used

PASS

• Privacy, Access and Security Services (PASS), Access Control Services, Conceptual Model, Release 1.0

• Draft Standard for Trial Use Ballot,HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) - Audit, Conceptual Level, Release 1

PASS Architecture FrameworkSAEAF-compliant

• Encompasses domain analysis models, domain information models, essential service components and supporting vocabularies for authentication, authorization and audit services required by a health information network

• Support other HL7 working groups by specifying security/privacy functional capabilities that are exposed through well-defined service interfaces

PASS Capabilities and Interfaces Could Invoke a Security and Privacy Ontology Terminology Service

• AC2-2: Support the capability to switch preplanned profiles of policy sets based upon purpose of use

• AC2-3: Enforce security and privacy policy based on contextual, action, target or initiator access control decision information

• AC2-9: Support exchange of security and privacy policy documents with other access control service

• AC2-10: Support enforcement of nested policy sets• AC2-11: Respond to a request for a machine-readable

policy document from another service.

PASS Semantic Signifiers (Normative)

• A semantic signifier is used to specify constraints on the information constructs that serve as payloads within service operations

• It is the identification of a named set of information descriptions that are supported by one or more operations

• The reference points for associated conformance statements occur at the computational model interface where the semantic signifier is specified as an input or output required by the contract

HL7 V3 Data Consent Messages• HL7 Version 3 Data Consent Model

RCMR_RM010001UV01– Consent Class, ActConsentType, Override Reasons,

Purpose of Use, Functional and Structural Roles, Context codes, Record Type, Information Access Codes

• HL7 Version 3 Shared Secret Model RCMR_RM010002UC01– ActConsentType, Record Type, Functional and

Structural Roles, Information Access Codes

HL7 V.2 Security and Privacy

• HL7 Version 2 Chapter 9 Privacy Consent Directive Segment

• HL7 Version 2 Code Tables• WG Project 874: – V2

code table versioning and alignment to V3 vocabulary model to migrate HL7 v2 code tables to HL7 v3 vocabulary where beneficial, i.e., where vocabulary is more comprehensive, consistent, and better structured.

HL7 V2 Privacy and Confidentiality Vocabu