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

2.  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 openPASS Phase 1 Proposed Scope

3. openPASS HL7 SOA-PASS Service Functional Models and Platform Independent Models

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

5. openPASS Services in Architectural Context Health Service Bus PASS Common Service Patient Identifier Service Protected ResourceWorkstation UI Services Terminology Services HL7 V3 Services Admin Support Services Clinical Support Services Process EHR Registry EHR Repository Runtime Platform Messages PASS Services Infrastructure Service Terminology Service openPASS Services

6. PASSServiceInventory Terminology Service Inventory Network Layer Clinical Document Service Inventory UI Services Process Service Inventory UtilityServiceInventory Code Schema Policy Configuration Data Objects Generic Process/Service Message Transport Service Inventory Process Executive Services Messages- platform Messages- internet

7. CredentialIdentifierIdentity binds to Entity

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

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

10. Access Enforcement Point Resource Role Assertion Decision Identity x.509 Cert Policy 1 Policy 2 Service Invocation Consent Directive Policy n Policy Engine Consent Repository Interaction Policy

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

17. Typical Health Information Exchange (HIE) Federation Topology PHR 1 vHIN vHIN Authority HIE Credential Provider vHIN HIE Member Credential Provider A Healthcare Organization 1 Healthcare Organization 2 Healthcare Organization n HIE HCO Credential Provider vHIN HCO Human Resources Credential Provider A Employee 1 Employee 2 Employee n HCO HIE HCO I HIE HCO I HIE HCO I HIE HCO I HIE Authorization with Policy Decision Engine HIE Health Information Exchange with Access Enforcement A HIE Authority AA HIEHCO I HIE HCO I HIE HCO I HIE HCO I Identity Token HIE Member Token Healthcare Org Employee Token A Invokes submitAuditRecord Collects/Submits Tokens Standards: WS-*, SAML, PASS Consumes Tokens Standards: WS-*, SAML, XACML, PASS Issues Tokens Standards: WS-*, SAML, PASS

18. Other Authorization Decision Factors Typical Policy-Driven Access Control Topology PHR 1 vHIN Credential Provider n PHR 1 Authorization with Policy Decision Engine Credential Provider 1 User Digital Cert Validation Identity Provider Validation Service Identity Provider Validation Service User User Context PHR 1 Personal Health Record Service with Access Enforcement A Patient Context Consent Directive Service Session Context Other Authorization Decision Factors Runtime (assumes user authenticated ) Credential Provider 1 vHIN Credential Provider n vHIN Identity Provider vHIN Consent Directive vHIN PHR 1 Authority Credential Provider A A AAAAA AA I Patient Context vHIN Authority HCO I Identity Token Healthcare Org Employee Token A Invokes submitAuditRecord HCO I I 

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

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