1. Healthcare Provider Directories 2011-Jan-24 Eric Heflin Dir of Standards and Interoperability/Medicity

2. Audience/Scope Agenda –Introduction –Terms Used –Personnel White Pages (PWP) –Healthcare Provider Directories (HPD) –Cross-Enterprise User Assertions (XUA) –Relationships Between HPD and PWP –For More Information

3. Audience/Scope Audience –Senior healthcare IT technical executives –Architects –Implementers seeking a broad overview Scope –Broad context and guidance about the use of two IHE standard profiles for provider directories –Personnel White Pages and Healthcare Provider Directory Purpose –Provide reusable educational content

4. Introduction IHE has created two standards (profiles) for healthcare-related directories One profile targets people inside an enterprise The second profile targets people and organizations across enterprises This presentation introduces and compares both profiles

5. HPD / PWP Relationship Internet Organization A PWP Directory HPD Directory Organization B Local person lookup Cross organization person or organization lookup No local directory; Uses cross organizational directory lookup

6. HPD/PWP Terms Used Directory: A type of database, typically with a hierarchal structure, supporting queries to determine a list of matching subjects, or determining attributes about a subject. Healthcare Provider: Medical information entities such as physicians, medical laboratories, hospitals, dentists, pharmacists, nurses, diagnostic imaging professionals etc. This includes both individuals as well as organizations. LDAP (Lightweight Directory Access Protocol): A type of directory that is widely deployed, multi-vendor, and mature. HPD (Healthcare Provider Directory): An IHE profile and a specific instance of a directory with defined attributes and service interfaces. Defined in more detail in this presentation. PWP (Personnel White Pages): An IHE profile and a specific instance of a directory with defined attributes and service interfaces. Defined in more detail in this presentation. DSML (Directory Services Markup Language): An XML grammar for accessing LDAP directories. XUA: A method of expressing identity attributes across domains.

7. XUA Terms Used Assertion: A piece of data produced by a SAML authority regarding either an act of authentication performed on a subject, attribute information about the subject, or authorization data applying to the subject with respect to a specified resource. This Assertion is used in access control and audit trails. Federated Identity: A user’s identity is said to be federated between a set of Providers when there is an agreement between the providers on a set of identifiers and/or attributes to use to refer to the user. Identity Provider : A type of service provider that creates, maintains, and manages identity information for users and provides user authentication to other service providers within a federation, such as with web browser profiles. Security Assertion Markup Language (SAML): The set of specifications describing security assertions that are encoded in XML, profiles for attaching the assertions to various protocols and frameworks, the request/response protocol used to obtain the assertions, and bindings of this protocol to various transfer protocols (for example, SOAP and HTTP). Security Domain: An environment defined by a single set of security policies, including a set of people, equipment, facilities, procedures. A Security Domain may be a single enterprise or a collection of enterprises (e.g. IHE-XDS Affinity Domain). Principal: A person or system who makes use of a system and its resources for any purpose.

8. PWP – PERSONNEL WHITE PAGES

9. What Problem is Being Solved? PWP Problem Statement: The industry needs a standards-based method access to basic directory information on human workforce members to other workforce members within the enterprise.

10. PWP Definition Personnel White Pages Profile (PWP) provides access to basic human workforce user directory information. This information has broad use among many clinical and non-clinical applications across the healthcare enterprise. The information can be used to enhance the clinical workflow (contact information), enhance the user interface (user friendly names and titles), and ensure identity (digital certificates).

11. PWP Selected Use Cases Username query to determine user’s full name Determine a user’s organization identification Determine a user’s email address Determine a user’s name given his/her initials Determine a user’s name given his/her provider ID

12. PWP Scope Provide access to basic information about the human workforce members –Does not include Patients Defines method for finding the PWP Defines query/access method Defines attributes of interest Leverages an ISO standard

13. PWP Value Single Authoritative Knowledge Base –Reduce duplicate and unconnected user info database –Single place to update Name Changes New Phone Number Additional Addresses Enhance Workflow and Communications –Providing information necessary to make connections Phone Number Email Address Postal Address

14. PWP Actor Diagram Personnel White Pages Consumer DNS ServerPersonnel White Pages Directory Find Personnel White Pages [ITI-23] Query Personnel White Pages [ITI-24]

15. PWP Actors Three Actors –Personnel White Pages Consumer –DNS Server –Personnel White Pages Directory Two Transactions –Find Personnel White Pages [ITI-23] –Query Personnel White Pages [ITI-24] No Options

16. PWP Process Flow

17. PWP Security and Privacy Security and privacy for and PWP is established via other mechanisms –ATNA for node authentication and secure logging –EUA to authenticate users –XUA for access control –IT best practices Regional-specific legal, regulatory, policy, privacy, and security analysis is suggested See the HPD profile for an analysis X.509 keys can be stored in HPD or PWP directories

18. PWP References For more information on PWP, please see: –IHE ITI Technical Framework Profile http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev7-0_Vol1_FT_2010-08- 10.pdfhttp://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev7-0_Vol1_FT_2010-08- 10.pdf –IHE ITI Technical Framework Transactions http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev7-0_Vol2a_FT_2010-08- 10.pdfhttp://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev7-0_Vol2a_FT_2010-08- 10.pdf –Wiki Page http://wiki.ihe.net/index.php?title=Personnel_White_Pages –John’s 2004 PWP slide deck (URL??)

19. HPD – HEALTHCARE PROVIDER DIRECTORY

20. What Problem is Being Solved? HPD Problem Statement: The industry needs a standards-based method to support queries against, and management of, healthcare provider information that may be publicly shared in a directory structure.

21. HPD Definition HPD supports queries against, and management of, healthcare provider information that may be publicly shared in a directory structure. HPD directory structure is a listing of the following two categories of healthcare providers that are classified by provider type, specialties, credentials, demographics and service locations. –Individual Provider: A person who provides healthcare services, such as a physician, nurse, or pharmacist. –Organizational Provider: Organization that provides or supports healthcare services, such as a hospital, Healthcare Information Exchange (HIE), Managed Care, Integrated Delivery Network (IDN), and Association.

22. HPD Selected Use Cases Yellow pages lookup Query providers and their associations for Social Services Disability Determination Emergency Responders Identification in planning for an emergency event Provider Authorization and lookup during an emergency event Forwarding of Referral Documents to a Specialist Certificate Retrieval Language Retrieval

23. HPD Scope Designed to maintain a structured list of attributes for both organizations (such as clinics) and people (such as physicians) Allows extensibility Largely semantically interoperable Leverages ISO standard (21091) Designed to enable cross organizational directory access

24. HPD Value Single Authoritative Knowledge Base –Reduce duplicate and unconnected user info database –Single place to update Name Changes New Phone Number Additional Addresses Enhance Workflow and Communications –Providing information necessary to make connections Phone Number Email Address Postal Address

25. HPD Value Enhance User Interactions –Provide user friendly identities and lists List of members Displayable name of a user Initials query Contributes to Identity Management –Additional methods of identity cross verification Name, address, phone number, email Cross reference with Enterprise User Authentication identity –Future expansion likely will contain certificates

26. HPD Actor Diagram Provider Information Source Provider Information Directory Provider Information Consumer Provider Information Feed [ITI-59] Provider Information Query [ITI-58]

27. HPD Actors Three Actors –Provider Information Directory –Provider Information Consumer –Provider Information Source Two Transactions –Provider Information Query [ITI-58] –Provider Information Feed [ITI-59] One Option –Provider Information Feed [ITI-59]

28. HPD Options 28.2.1 Provider Information Feed Option When the Provider Information Feed Option is declared the Provider Information Directory shall support the Provider Information Feed [ITI-59] transaction

29. HPD Relationships

30. HPD Process Flow

31. HPD Organizational Provider

32. HPD Individual Provider

33. HPD Security and Privacy Security and privacy for HPD is established via other mechanisms –ATNA for node authentication and secure logging –EUA to authenticate users –XUA for access control –PWP for system users identification –IT best practices –LDAP authentication for attribute protection Regional-specific legal, regulatory, policy, privacy, and security analysis is suggested See the HPD profile for an analysis X.509 keys can be stored in HPD or PWP directories

34. HPD Standards Used LDAP DSML ISO/TS 21091

35. HPD References For more information on HPD, please see: –IHE Technical Framework http://www.ihe.net/Technical_Framework –ISO TS 21091:2005 – Requires purchase http://www.iso.org/iso/catalogue_detail.htm?csnumber=35647

36. XUA – CROSS-ENTERPRISE USER ASSERTION

37. XUA Definition XUA specifies the use of an existing standard (SAML 2.0) to carry cross-enterprise attributes identifying a person or system making a request Cross-Enterprise User Assertion provides a means to communicate claims about the identity of an authenticated principal (user, application, system...) in transactions that cross- enterprise boundaries. The XUA Profile supports enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, as well as others that may have chosen to use a third party to perform the authentication.

38. XUA Introduction XUA based on SAML 2.0 XUA++ enhances XUA to indicate several key SAML attributes A complete discussion of XUA can be found in other IHE documents (see references section) Here we primarily discuss the relationships between XUA and HPD/PWP

39. XUA PWP/HPD Relationship Organizations are responsible for identity proofing, authenticating, authorizing and managing end-users credentials compliant with local policy XUA / XUA++ attributes can be maintained in PWP and HPD directories Selected PWP and HPD attributes can be subsequently expressed in XUA Implies that users should never be removed from PWP or HPD directories; only depreciated to preserve log integrity

40. SUMMARY

41. HPD/PWP Comparisons AttributeHPDPWP IHE Profile DependencyNone Other DependenciesLDAP, DSMLLDAP Service InterfacesWeb ServicesLDAP API Secured ByChannel (TLS, VPN, ATNA) VLAN, LDAP authentication, TLS, ATNA Cross EnterpriseYesNo Contains human informationYes Contains organization informationYesNo Contains patient informationNo LDAP basedYes Directory location determinationPre-ConfiguredDNS Query for LDAP Dirs

42. Other IHE References General information about IHE can be found at: –http://www.ihe.nethttp://www.ihe.net Information about the IHE IT Infrastructure domain can be found at: –http://www.ihe.net/Domains/index.cfmhttp://www.ihe.net/Domains/index.cfm Information about the structure of IHE Technical Frameworks and Supplements can be found at: –http://www.ihe.net/About/process.cfm and http://www.ihe.net/profiles/index.cfmhttp://www.ihe.net/About/process.cfm http://www.ihe.net/profiles/index.cfm

43. Credits: –Selected content copied from other IHE sources including the ITI Framework Profiles, Transactions, Supplements, and educational materials Reviewers: –John, Karen, Rob, Geoff, will list all

45. What Problem is Being Solved? XUA Problem Statement: The industry needs a standards-based method to provide the initiating user’s identity in cross-enterprise transactions in a way that the responder can make access decisions and proper audit entries.

46. XUA Motivation The IHE profiles available today provided for distributed accountability that is tied together through the use of node-to- node authentication between systems that agree to handle access controls and audit trails. Access control policies are becoming more complex. Systems are often built on architectures that are loosely coupled such as n-tier web-services. The result is that the user is further away from the data. While an enterprise can impose a single authentication technology and a single personnel directory, multiple enterprises that participate in an affinity domain may not be able to impose a single authentication technology or personnel directory.

47. XUA Selected Use Cases 1 2 3

48. XUA Scope Designed to enable cross organizational user identification Supports federated as well as centralized identity management Decouples authentication implementation (Kerberos, PKI, biometrics, etc.) while allowing awareness of core attributes and context The context is essential for complex policy enforcement Supports requesters such as: IT systems, direct end-users, proxy end-users, medical devices, and health information exchange gateways Only provides identity attributes; doesn’t specific how access control decisions are to be made by the service provider XUA can be used by many different cross-enterprise transactions

49. XUA Trust Model A SAML Security Token Server (STS) is the primary trusted entity The receiver can validate a token issued by the STS

50. Why SAML 2.0? Open standard Supports homogenous and heterogeneous environments Can carry multiple user authentication assertions Identities are marked with the assurance level each provides Can carry additional attributes about the user such as email, role, address, preferences (from PWP or HPD) The identity information can be a pseudonym when appropriate to limit user exposure across enterprise boundries The assertion content can be defined by the service that will consume them A SAML Assertion to carry security tokens from one or more Authentication system including Kerberos and X.509 Assertion provides a unique identifier suited for audit trails. The system allows for each enterprise to manage their users independent of the transactions. The information necessary to build a SAML Assertion is only communicated at the time the transaction happens, not when the user is provisioned.

51. XUA Value Contributes to Identity Management

52. HPD Actor Diagram Provider Information Source Provider Information Directory Provider Information Consumer Provider Information Feed [ITI-59] Provider Information Query [ITI-58]

53. XUA Actors

54. EHR / XUA Profile Actor Diagram

56. HPD Actors Three Actors Two Transactions One Option

57. HPD Options 28.2.1 Provider Information Feed Option When the Provider Information Feed Option is declared the Provider Information Directory shall support the Provider Information Feed [ITI-59] transaction

58. HPD Process Flow

59. XUA Security and Privacy Security and privacy for XUA is established via other mechanisms –ATNA for node authentication and secure logging (no new ATNA audit events are defined by XUA) –EUA to authenticate users –PWP for system users identification –IT best practices Regional-specific legal, regulatory, policy, privacy, and security analysis is suggested X.509 keys can be stored in HPD or PWP directories