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

1. 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 Overview, 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 Groups HL7 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, ReconciledPASS 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*

7. VA Security Services Logical Model Input

8. Example of System Components Pull Use Cases – Request/Response Asserts Credentials, POU, Requested Resource Requesting Organization/ Individual Servicing Organization Cross-Enterprise Authorization Patient Consent Protected Resource Local Authorization Decision Asserts Credentials, POU, Requested Resource Access Control System Organizational Policy • 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 Access Control System Document or Document Set • 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 Obligations C32 Document Query/Assembly Patient Consent Organizational Policy 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. Rules Engine

9. Example of Healthcare Classification Business Process Flow Model Requesting Organization Servicing Organization Document Set Delivered to Requesting Organization Policy Decision Determining Inclusion Organizational Policy Law Layered Security Service Clinical Knowledge Deny Deny Permit Permit Servicing Organization Policy Decision Clinicians Request Patient Record Document Assembly And Tagging Creation of Secured Inner Policy Wrapper Creation of Secured Outer Policy Wrapper Creation of Composite Document Set Local Authorization Decision Patient Consent Patient Consent Classification System Organizational Policy Organizational Policy

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