openPASS Open Privacy, Access and Security Services “Quis custodiet ipsos custodes?”

1. openPASS Open Privacy, Access and Security Services “Quis custodiet ipsos custodes?”

2. openPASS Phase 1 Proposed Scope • Phase 1 openPASS Services are intended to provide the basic capabilities that allow a patient or provider to request access to patient health information from a protected resource and, based upon the security and privacy policies applied by the resource, have that access either be granted or denied. • To accomplish this objective, Phase 1 openPASS Services must provide at least basic functionality for • Patient Identity Resolution • Provider Identity Authentication, Assertion and Validation • Provider Credential Assertion • Point-to-Point and Message-based Document/Message Transport • Policy-driven Access Control Decisions and Enforcement • Audit Event Record Generation and Submission to Audit Logging Services

3. openPASS HL7 SOA-PASS Service Functional Models andPlatform Independent Models

4. Guiding Principles • Service Orientation • Focus on gaps in existing standards or adaptation to service environment • Platform Independent • Policy-driven • Composable

5. Health Service Bus openPASS Services in Architectural Context Workstation Protected Resource PASS Common Service Infrastructure Service Process EHR Repository Patient Identifier Service Terminology Service UIServices Clinical SupportServices TerminologyServices EHR Registry HL7 V3Services Admin SupportServices openPASS Services PASS Services PASS Services PASS Services Runtime Platform Messages

6. Generic Process/Service UIServices ProcessServiceInventory Messages- platform Process Executive Services Data Objects UtilityServiceInventory ClinicalDocumentServiceInventory Messages- internet PASS ServiceInventory Policy TerminologyServiceInventory Configuration MessageTransportServiceInventory Schema Code Network Layer

7. Credential Identifier Identity Entity binds to binds to binds to

8. Subprojects • Federated Identity Resolution • Policy-driven Access Control • Audit

9. Typical Health ID Federation Topology • Benefits • Supports mutlple Identity Providers • Supports pseudonymisation DescriptionLocates and returns User’s “authoritative” Identity Provider Health ID Resolution Service • Gaps • Metadata Exchange Schema • Token Schema • SFM • HIDN Federation Agreements • Reference Implementation A HIDN vHIN User User Context Login Service Identity Provider 1 Authentication Service Identity Provider 2 Authentication Service Identity Provider n Authentication Service A A A A A Identity Provider 2 vHIN vHIN Authority A Invokes submitAuditRecord

10. Policy Identityx.509 Cert Policy 1 Policy Engine Role Assertion Policy 2 Consent RepositoryInteraction Decision Policy n Consent Directive Access Enforcement Point Resource Service Invocation Service Invocation

16. Typical Health ID Federation Topology(Standards Domains) Locates and returns User’s Identity Provider Health ID Resolution Service Unique ID Service A A UID vHIN WS-*, PASS-IDF HIDN vHIN User User Context Login Service Identity Provider 1 Authentication Service Identity Provider 2 Authentication Service Identity Provider n Authentication Service A I A A A I A Identity Provider 2 vHIN WS-*, SAML vHIN Authority I Identity Token A Invokes submitAuditRecord

17. Typical Health InformationExchange (HIE) Federation Topology I I I I I I HCO HCO HCO HCO HCO HCO HIE HIE HIE HIE HIE HIE vHIN Authority I Identity Token Collects/Submits TokensStandards: WS-*, SAML, PASS HIE HIE Member Token HCO Healthcare Org Employee Token A Invokes submitAuditRecord HIE Health Information Exchangewith Access Enforcement HIE AuthorizationwithPolicy DecisionEngine HIE Authority Consumes TokensStandards: WS-*,SAML, XACML,PASS A A I HCO HIE A PHR 1 vHIN HIE CredentialProvider vHIN Healthcare Organization 1 Healthcare Organization 2 Healthcare Organization n HIEMember Credential Provider HIE HIE HIE A HIE Issues TokensStandards: WS-*, SAML, PASS Employee 1 Employee 2 Employee n HCOHuman ResourcesCredential Provider HCO HCO HCO A HCO HCO CredentialProvider vHIN

18. PatientContext Typical Policy-Driven Access Control Topology Runtime (assumes user authenticated) Credential Provider n Consent Directive Service Other Authorization Decision Factors Identity Provider Validation Service Credential Provider 1User Digital Cert Validation Other Authorization Decision Factors A A A A A ConsentDirective vHIN CredentialProvider n vHIN CredentialProvider 1 vHIN IdentityProvider vHIN UserContext PatientContext SessionContext HCO A I A PHR 1 vHIN PHR 1 Personal Health Record Servicewith Access Enforcement User PHR 1 AuthorizationwithPolicy DecisionEngine PHR 1 AuthorityCredential Provider I A A I HCO A  I Identity Token vHIN Authority HCO Healthcare Org Employee Token A Invokes submitAuditRecord

19. openPASS Architecture PHR vHIN Identity Provider Credential Provider HIDN vHIN Standards: WS-*, PASS Standards: WS-*, PASS-IDF Standards: WS-*, SAML Standards: WS-*, SAML, PASS Standards: WS-*, OASIS, PASS Standards: WS-*, HL7 PASS Context Service Health ID Resolution Service Identity ProviderAuthentication Service Credential Provider AccessControlAuthorization Service PersonalHealth Record Service A A A A A A Login Identifier Redirect- Identity Provider Identifier, Assertions I Verified Identity Token Request PHR Access Request Privacy Policy Request Credential C Verified Credential Request User Role C User Role Assertion Request PHR Access,submit credentials I C C Access Granted- Redirect Access PHR A Invokes PASS submitAuditRecord or equivalent

20. Reference implementations Code Base Review and refactor WS, Java, .NET components Commercialization issues Policy Agents for major web and application servers Development Plan