HL7 Security Service Oriented Architecture Domain Analysis Model (SSOA DAM)

Kathleen Connor VA (ESC)June 12, 2012

2

Topics

• Review and request approval of new HL7 Project Scope Statement:– HL7 Security Service Oriented Architecture Domain

Analysis Model (SSOA DAM)• Discuss:

– Purpose & Scope– Co-Sponsors– Inputs

3

Scope

• Provide unified end2end conceptual information and behavioral model for HL7 Services supporting the Security and Privacy Domain

• Harmonize HL7 Security and Privacy Artifacts• Supports traceability and conformance

statements for derivative logical and physical models to ensure semantic interoperability

4

HL7 Security WG Inputs• HL7 Confidentiality Code Refactoring Project – Draft for

Comment “Health Care Security and Privacy Classification System ”

• Composite Security and Privacy Domain Analysis Model v1_r2 (post 2010May ballot reconciliation)

• HL7 Security and Privacy Ontology• Role Based Access Control (RBAC) Role Engineering Ove

rview, N1 Sept 2009 HL7 ballot site• HL7 RBAC Permission Catalog• HL7 RBAC Constraint Catalog• HL7 RBAC Role Engineering Process (supporting data• HL7 Privacy and Security Vocabulary

5

Co-Sponsoring Work GroupsHL7 Service Oriented Architecture Work Group• Align and extend PASS

– Privacy, Access and Security Services (PASS), Healthcare Audit Services, Release 1.0 V3_PASS_AUDITSERV_R1_D1_2010SEP.pdf

– Privacy, Access and Security Services (PASS), Access Control Services, Conceptual Model, Release 1.0 Draft Standard for Trial Use Ballot, Reconciled PASS Alpha - Access Control Conceptual Model Release 1.0 - Post-Ballot Reconciliation.pdf

HL7 CBCC Work Group• Align and incorporate:• Consent Directive v.2, v.3, and CDA artifacts, including

Harmonization of HL7 Privacy and Security Vocabularies with v.2

6

Additional Inputs

• Data Segmentation for Privacy Implementation Guide

• Query Health Envelope• VA Security Service Logical Model

– Support for Data Segmentation and Health Care Security and Privacy Classification System

– VA VAPii Reference Model• FHIMS• OASIS XSPA• WS*

VA Security Services Logical Model Input

7

Example of System Components

8

Requesting Organization/Individual

Servicing Organization

Access Control System• Policy Enforcement Point (PEP)• Context Handlers (CH)• Policy Information Point (PIP)• Policy Decision Point (PDP)• Policy Authority Point (PAP)• XACML Policies for Healthcare• SAML Handler

Access Control System• SAML Validator• Policy Enforcement Point (PEP)• Context Handlers (CH)• Policy Information Point (PIP)• Policy Decision Point (PDP)• Policy Authority Point (PAP)• XACML Policies for Healthcare

Document Query/Assembly

Pull Use Cases – Request/Response

Healthcare Classification System

• Rules Engine• Evaluates domain rules and facts• Performs tagging of source document and components• Sets handling Information at document and/or composite document set levels.

Asserts Credentials, POU, Requested Resource

Cross-Enterprise Authorization

Local Authorization Decision

Rules Engine

Asserts Credentials, POU, Requested Resource

Patient Consent Organizational Policy

Obligations

C32

Patient Consent

Organizational Policy

Document orDocument Set

Protected Resource

9

Example of Healthcare Classification Business Process Flow Model

CliniciansRequestPatient Record

LocalAuthorizationDecision

ServicingOrganizationPolicyDecision

DocumentAssemblyAndTagging

Creationof SecuredInnerPolicy Wrapper

Creationof SecuredOuterPolicy Wrapper

Permit Permit

Deny

Creation ofCompositeDocument Set

Deny

PatientConsent

OrganizationalPolicy

PatientConsent

OrganizationalPolicy

Requesting Organization Servicing Organization

Layered Security Service

Classification System

Document SetDelivered toRequesting Organization

ClinicalKnowledge

Policy DecisionDetermining InclusionOrganizational Policy Law

10

Example of Behavioral Model

11

Key HL7 Privacy and Security Vocabulary Inputs

12

SAIF compliant Domain Analysis Model

Definition:• Domain Analysis Model(DAM) is a collection of artifacts at the

conceptual level that represents a well-defined subject-area-of-interest

• The static/informational and dynamic/behavioral semantics must be of use to domain experts and non-technical

• Semantics of a DAM must also be of sufficient robustness to enable the development by architects, designers, and developers of “down-stream” logical artifacts/models which are traceable from the original DAM (conceptual-level) artifacts

• Overarching Purpose – A representation of the static and/or dynamic semantics of a subject-area-of-

interest (i.e. a “domain”) in a manner that enables harmonization of the various perspectives of the stakeholders in the domain while also providing the foundations required to build logical and implementable representations of the domain

13

Decision: SSOA DAM Ballot Status

• Normative or DSTU Ballot if DAM is Conformant

• Informative Ballot if DAM is relevant to stakeholders but not conformant

14

Additional Conformant DAM Requirements

• Declare the rationale for creating or extending the DAM, including reference to uses cases or capabilities intended to be achieved using the DAM.

• Be understandable by the reader without requiring access to other content protected by intellectual property rules.

• Focus on the conceptual-level semantics • Contain references to other material used to create it. • Have a traceable path to each domain requirement statement.• Contain specific conformance statements that provide implementers of the DAM a testable,

verifiable metric for determining whether the DAM-derived logical model is, in fact, conformant with the source (conceptual level) DAM.

• Be understandable by subject matter experts that were not present during the development. • MAY specify data type bindings either specifically or as exemplar bindings: if so, the

definitions must be contained in the model or referenced from a publically available source. • MAY indicate logical constraints useful in generating traceable logical artifacts as needed.

15

Normative or DSTU DAM

• Must include the defined domain’s static (informational) and dynamic (behavior) semantics

• A DAM that is submitted for either DSTU or NORMATIVE balloting must contain specific conformance statements that enable traceable logical models to be evaluated for the “derivational correctness,” i.e. their COMPLIANCE to the semantics of the source DAM

• Must have at least 2 traceable logical models that have been derived from it