2. Direct Project November 2010

3. Direct Project What is Direct? A project to create the set of standards and services that, with a policy framework, enable simple, directed, routed, scalable transport over the Internet to be used for secure and meaningful exchange between known participants in support of meaningful use 3

4. Direct Project Why is there a need for Direct? Communication of health information among providers and patients still mainly relies on mail or fax Slow, inconvenient, expensive Health information and history is lost or hard to find in paper charts Current forms of electronic communication may not be secure Encryption features of off-the-shelf e-mail clients not often used in healthcare communications today Physicians need to transport and share clinical content electronically in order to satisfy Stage 1 Meaningful Use requirements. Need to meet physicians where they are now Direct will be one of the communication methods in the Nationwide Health Information Network Sources: http://www.flickr.com/photos/dougww/922328173/ http://www.flickr.com/photos/greenlagirl/154148230/sizes/o/ http://www.flickr.com/photos/kenjonbro/3418425029/sizes/m/ When current methods of health information exchange are inadequate:

5. Direct Project and other Information Exchange 10/16/2015 Nationwide Health Information Network Exchange Nationwide Health Information Network Exchange Nearby HIE EMR to EMR (HIE) EMR to EMR (HIE) Direct Project The Direct Project doesn’t replace other ways information is exchanged electronically today, but it might augment them. The Direct Project supports simple use cases in order to speed adoption, but other methods of exchange might be suited for other scenarios. The Direct Project was designed to coexist gracefully with existing protocols for data exchange. The Direct Project seeks to replace slow, inconvenient, and expensive methods of exchange (like paper, fax, or carrier pigeon) and provide a future path to advanced interoperability. Health information exchange: a puzzle with many pieces

6. Direct Project Secure Internet-based Direct Communications »Simple. Connects healthcare stakeholders through universal addressing using simple push of information. »Secure. Users can easily verify messages are complete and not tampered with in travel. »Scalable. Enables Internet scale with no need for central network authority. »Standards-based. Built on common Internet standards for secure e-mail communication. b.wells@direct.aclinic.org h.elthie@direct.ahospital.org

7. Direct Project Facilitates Meaningful Use »Patients : Health information Discharge instructions Clinical summaries Reminders »Public Health : Immunization registries Syndromic surveillance Laboratory Reporting »Other Providers/Authorized Entities: Clinical information Labs – test results Referrals – summary of care record 10/16/2015 b.wells@direct.aclinic.org D I R E C T Direct Project facilitates the communication of many different kinds of content necessary to fulfill meaningful use requirements. Examples of Meaningful Use Content 1) Get a Direct Address (e-mail-like) and a security certificate 2) Send mail securely using most e- mail clients OR contract with a HIO or HISP that performs authentication, encryption and trust verification on your behalf

8. Virtual Health Information Networks: Privacy-assured, Policy-driven OHT- PASS Project Feb. 2011 Don Jorgenson OpenPass  InterHIN

9. Introduction  Evolution of Health Information Networks  Impact of SOA  HL7 PASS  Security, Privacy and Governance  Virtual Health Information Networks  The InterHealthNet aka InterHIN

10. First Generation: Paper-based Health Information Network Evolution

11. Laboratory Receptionist Nurse Specialist Imaging Admin Doctor First Generation: Paper-based Health Information Network Evolution

12. Second Generation: Digital- local network Health Information Network Evolution

13. Laboratory Receptionist Nurse Specialist Imaging Admin Doctor Second Generation: Digital- local network Health Information Network Evolution

14. Patient is here Patient’s records are here… and here… Health Information Network Evolution

15. Patient is here Patient’s records are here… and here… Patient health information is not available where it is needed, when it is needed Health Information Network Evolution

16. The next generation of Health Information Network must: –Assure that patient information remains private is accessible at anytime, from anyplace is not tampered with –Interoperate across healthcare organization boundaries –Support automation of clinical and business processes –Meet regulatory requirements –Support the latest development and archictecture approaches--SOA

17. What does a Health Information Network do?  Provides:  Secure, Private and Interoperable Message Exchange  Context-aware, Policy-driven Access Control  Currency of Trust  Audit Support  Shared Message Metadata Semantics  Healthcare Grade*  Encryption  Digital Signature * Healthcare-Grade Systems/Components: capable of processing patient health information using healthcare standard terminologies, formats and protocols with high reliability while maintaining its confidentiality, integrity and availability.

18. Virtual Health Information Networks  Health information available to authorized users regardless of their location or time-of-day  Overlays a “healthcare-grade” virtual network over the physical network  Access policy enforcement assures privacy  Encryption and digital signatures assures security Virtual Health Information Network

19.  Key Benefits  Improves clinical and business process efficiency  Disentangles security from the healthcare application  Service-oriented to enable business process automation  Healthcare providers can be a member of any number of virtual health information networks  Virtual health information networks can have any number of members  Rapid deployment  Scalable Virtual Health Information Networks

20.  Have an “owner”  the vHIN Authority  Interoperable  Standards compliant  Within some context  Self-defensive  Context-aware, Policy-driven Access Control

21.  Benefits  Basic  Agility  Flexibility  Substitutability  Scalability  Reliability  Lower costs  Healthcare Critical  Implement complex clinical and business processes  Security and Privacy at Perimeter  Policy-driven, Context Aware Service Orientation

22. SOA ↔ Privacy Given SOA— Privacy is about the Health Information Network (HIN).  Two Types:  InterHealthNet – a healthcare organization’s “outward facing” Inter-Health Information Network  IntraHealthNet – a healthcare organization’s internal Intra-Health Information Network Health Information Network

23. InterHealthNet  Health Information Network  Policy-driven Access Control  Currency of Trust  Audit  Encryption  Digital Signature  Available  Reliable

24. IntraHealthNet  Health Information Network  Policy-driven Access Control  Currency of Trust  Audit  Encryption  Digital Signature  Available  Reliable Security/Privacy Perimeter IntraHealthNet

25. HL7 PASS Concept Diagram 0.1

26. Candidate Access Control Logical Architectures

27. Access Enforcement Resource Access Requirements Trusted Information Source requires Access Enforcement provides requires access toprotects is a kind of authorizes Access Policy drives Virtual HIN (vHIN) Resource Authority authenticates to managed by defines policy defines specifies uses is a kind of Access Decision Information Access Policy Decision Requestor Identity Provider Virtual Organization (VO) Policy Enforcement Point (PEP) «access» Security/Privacy Framework—vHIN-based

28. The InterHealthNet Hospitals Clinics Patients Physicians Imaging Clinical Research Projects Public Health Agencies Health Information Exchanges Pharmacies Virtual Health Information Networks (vHINs) Common Services Labs InterHealthNet Gateway Business Associates

29. InterHealthNet The InterHealthNet aka InterHIN Hospitals Clinics Patients Physicians Imaging Clinical Research Projects Public Health Agencies Health Information Exchanges Pharmacies Virtual Health Information Networks (vHINs) Common Services Labs InterHealthNet Gateway Business Associates

30. “This sharing is, necessarily, highly controlled, with resource providers and consumers defining clearly and carefully just what is shared, who is allowed to share, and the conditions under which sharing occurs. A set of individuals and/or institutions defined by such sharing rules form what we call a virtual organization (VO).” --Foster el al in “The Anatomy of the Grid” Security, Privacy and Grid Computing

31. 2 1 Radiologist Workstation Audit Service – IMS Image Analysis Service (IMS) Image Data Service (IDS) Authentication Service Trust Message Infrastructure Trust Infrastructure 1 1c 1 Request Image/Data 1b Privacy Policies 1 1b Authorization Service – IDS 2 Authorization Policies Authorization Service – IMS 1b 2 1a SSO Log In 1a 1c 1 1 12 1 12 21 121 1 1 21 1 1b 1a 1b 1a 1b 1a 1b 1a 1 Access Privacy Access «PEP» Audit Service – IDS Request Image/Data 2 21 2 2 Trust Token Flow 1a 1b 1c 1 111 1111 222 222 12 2 Authentication Trust Token Authentication Trust Token- Delegated Authorization Trust Token Audit Trust Token- Secure protocol Representitive Use Case

32. 6. Request 8. Resource (if Permit) Resource Decision Factor 2 5. Decision Decision Factor 1 Policy 1 Policy 2 Decision Factor n Policy m 2.Request Decision Policy Information Service «PIP» 3.Request Decision Information 4.Decision Information Policy Decision Service «PDP» Policy Enforcement Agent «PEP»«access» 7. Response 1. Request Resource Access Decision Policy Sources may include: Jurisdictions- National State Organization (custodial) hGrid 2.0 VO Consumer- Patient Delegate Patient- Privacy Preferences Access Decision Information Factors may include: Requestor- Identity Organization Role Purpose of request Time of request Privacy Preferences Policy Decisions (remote) Resource- Attributes Policy Decision Rules reference Decision Information Security, Privacy and Governance

33. Intermediary Access Policy Enforcement hGrid 2.0 Monitor Grid Policy Enforcement Resource Policy Enforcement Proxy Governance Control Points hGrid 2.0 Service Request/Response Security, Privacy and Governance

34. Intermediary Access Policy Enforcement hGrid 2.0 Monitor Grid Policy Enforcement Resource Policy Enforcement Proxy Governance Control Points hGrid 2.0 Service Request/Response Security, Privacy and Governance What’s the implementation platform/framework?

35. Questions? “I'm sorry. My responses are limited. You must ask the right questions.” - Dr. Alfred Lanning, hologram

36. Privacy Policy Reference Catalog—Project Scope  To develop representative privacy policy sets applicable in various healthcare information exchange scenarios in a structured natural language. These privacy policy sets would be analyzed in order to:  Identify policy patterns that can be organized into policy templates,  inform Access Decision Information (ADI) service specifications and source information models of attribute ontology issues,  inform security/privacy information model and ontology projects of privacy attribute issues,  identify the vocabulary necessary to support obligations as required by the policy templates,  illustrate tool requirements of privacy policy managers, authors, clients, and other stakeholders,  align privacy policy templates with access control policy structures,  establish an organized catalogue of standard privacy policies, built up from identified patterns.

37. design-time run-time Service Retirement Domain Analysis  Requirements  CIM Service Definition  Identification  Scope  Behavior  CIM, PIM Service Design  Interfaces  Interaction  PIM, PSM Service Design  Interfaces  Interaction  PIM, PSM Service Development  Implementation  Test/Approval Service Operation  Run  Monitor  Change/SLA Mgmt. FeedbackLifecycle Service Deployment  Install/Deploy  Delivery to host The diagram in Figure x was adapted for SAIF from “Towards a Consistent Service Lifecycle Model in Service Governance” by Niemann et al.

38. Access Enforcement Policy Decision Service Access Coordination 9. Decision Factors8. Decision Rules 3. Return Authentication Token 2. Request Authentication Status 6. Request Resource 11. Request Resource 13. Resource (if Permit) 12. Resource Identity Provider 1. Request Resource 14. Resource 5. Return Project Credential 4. Request Project Credential hGrid 2.0 Project 10. Return Decision Token: Deny, or Permit, or Permit with Provisions 7. Resource Access Decision Requested Policy Enforcement Flow Information Flow 1 1 2 3 2 1 2 Secure Message- hGrid profile of WS-Security SAML - hGrid profile of SAML WS-Trust - hGrid profile of WS-Trust Encryption - FIPS 140-2 validated encryption XACML - hGrid profile of XACML HL7 PASS Access DSTU