Directory and Trust Services (D&TS)

1. Develop common Abstract Model for POP Track, Technology Track • Purpose: • Document a common terminology that the group can use between the various tracks • Identify the top level use case and the actors from a POP, Technology perspective • Identify the policies and business processes that need to be developed in PoP • Policy/business process discussions will identify some requirements/constraints for the technical track • Identify the technical capabilities that would be needed to implement the use cases Directory and Trust Services (D&TS)

2. Directory and Trust Services – Abstract Model In-State Authorized Requestor Local HIO Local HIO State Level Directory and Trust Services (D&TS) Local Directory Service A1 Directory Services Directory Services Local Directory Responder A3 State Level Directory Responder A2 A4 A4 Provider Directory Provider Directory Out of State Authorized Requestor B2 State Level Trust Service B1 Examples of Authorized Requestor Configurations: Provider  EMR  State D&TS Provider  EMR  HIO  State D&TS Out of State Provider  EMR / HIO  Out of State HISP (e.g OR)  CA State D&TS D&TS Use Cases: (A1 – A4 ) Request to Find Provider Information: Authorized Requestor uses State Level Directory and Trust Services to locate Providers and their information (B1 – B2) Request to Participate in Federated Directory Services: A Local HIO within the state requests the State to federate directory requests from Authorized Requestors. This is not shown in the diagram.

3. State Level Directory Responder (SLDR): The set of services that the State provides to respond to directory requests from Authorized Requestors. Some example directory requests are as follows: • Find general Provider information using search criteria such as First Name, Last Name, Geographical area, Medical Specialty type etc. • Find the electronic address for the Provider to exchange medical information • Find the digital certificate for the provider’s DIRECT mailing address • Discover the Provider’s Electronic Service Address for Query / Response • Discover the certificates and protocols for a Provider’s Electronic Service Address • Authorized Requestor: Authorized Requestors are ones who can send directory requests to the State Level Directory Responder. Authorized Requestors can be people (providers, pharmacists, nurses etc), Automated Systems (EMR’s, HISP’s), Organizations (Health Plans, IDN’s) etc. Authorized Requestors can be In-State or Out-Of-State and are designated as “In-State Authorized Requestors” and “Out-Of-State Authorized Requestors”. • The exact mechanisms of authorizing requestors and validating them will be discussed in the PoP WG. • Local Directory Service: An organization that is providing local (“Within State”) directory services to a community of willing participants which may include providers, hospitals, labs etc. The term “Local” is used to signify they are internal to the state hosting the State Level Directory Responder. • A Local Directory Service has it’s own Directory Responder which is called as “Local Directory Responder”. • Examples of Local Directory Services may be provided by HIO’s, Service Providers, State Registries etc. • State Level Trust Service: The State Level Trust Service is the set of capabilities used to identity proof providers and organizations who elect to participate in the State Directory and Trust Services and are not affiliated with Local Directory Service(white space docs, docs in state agencies etc). For these providers the State Level Trust Service will also include capabilities to manage, revoke credentials based on policies. Abstract Model Terminology

4. Directory and Trust Services – Directed Exchange to Unknown Address Use Case - Description • Scenario Description: • An Authorized Requestor (Sender of the patient information) is planning to send a patient’s information to a provider that the requestor does not have a trust relationship with, and does not know the electronic address for the receiving provider. • Scenario Flow: • 1. Authorized Requestor obtains the required information about the receiving provider (Provider to whom the sender has to send the patient information) to formulate a query. • 2.(*) Authorized Requestor executes the D&TS Use Case (A1 – A4) : “Request to Find Provider Information” • D&TS is used to find the Provider’s electronic address • D&TS is used to ensure that the provider can be trusted (D&TS Identity proofing) • 3. Authorized Requestor uses the receiver’s electronic address to discover the receiver’s digital certificate using S&I PD Certificate Discovery Specifications. • (**) State D&TS will be used to find digital certificates for Providers who are not affiliated with any other HIO’s. • (*) : Services used for Step#2 is the primary set of services provided by D&TS. • (**) : State D&TS will also be used in Step #3 to find digital certificates for Providers who are not affiliated with any other HIO’s.

5. Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (D&TS Interactions in Step #2) In-State Authorized Requestor Local Directory Service Local HIO Local HIO State Level Directory and Trust Services (D&TS) A1 Directory Services Local Directory Responder Directory Services A3 State Level Directory Responder A2 A4 A4 Provider Directory Provider Directory Out of State Authorized Requestor

6. Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (D&TS Interactions in Step #2) In-State Authorized Requestor Local Directory Service Local HIO Local HIO State Level Directory and Trust Services (D&TS) A1 Directory Services Directory Services Local Directory Responder A3 State Level Directory Responder A2 A4 A4 Provider Directory Provider Directory Out of State Authorized Requestor • Protocols and Standards Required for Step A1: (Discussion points) • Expect the requests to happen as part of work flows synchronously • Synchronous protocols are better suited than asynchronous protocols • Transport: • SOAP or RESTful • Content Structure: • DSML v2 structure • Content Meaning: • LDAP + ISO 21091 • (ESI Data Model Elements) • Audit: • IHE ATNA • Security and Privacy: • Requestor Identity Validation: (Discussion points) • End Users or Systems can make the request • Would we have the same authentication mechanism for both • Will it work for both in-state and out-of-state requestors ? • Single Factor or Multi-factor (What level of assurance would we need) • Simple Accounts vs PKI vs Token based • Standards – SAML, Open ID, OAuth, OCSP, CRL’s • Message Integrity and Confidentiality: (Discussion points) • Mutual TLS • End to end encryption

7. Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (D&TS Interactions in Step #2) In-State Authorized Requestor Local Directory Service Local HIO Local HIO State Level Directory and Trust Services (D&TS) A1 Directory Services Directory Services Local Directory Responder A3 State Level Directory Responder A2 A4 A4 Provider Directory Provider Directory Out of State Authorized Requestor • State Level Directory Standards Discussion: • Implementation Standard: • Provider Information: IHE HPD: or HPDPlus or X12 • Trust and Policy Information: ??? • Digital Certificates: X.509 with LDAP/DNS for publishing • Technology Stack: • LDAP stack or Relational DB Stack • Audit: • IHE ATNA • To implement Step A2, a State Level Directory is required. • State Level Directory: (Discussion points) • What is the content of the state level directory • Provider Information • Trust Information • Policy Information • Digital Certificates

8. Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (D&TS Interactions in Step #2) In-State Authorized Requestor Local Directory Service Local HIO Local HIO State Level Directory and Trust Services (D&TS) A1 Directory Services Local Directory Responder Directory Services A3 State Level Directory Responder A2 A4 A4 Provider Directory Provider Directory Out of State Authorized Requestor • Security and Privacy: • Identity Validation between State and Local Directory Service : (Discussion points) • System to System Request • Simple Accounts vs PKI vs Token based • Standards – SAML, Open ID, OAuth, OCSP, CRL’s • Message Integrity and Confidentiality: (Discussion points) • Mutual TLS • If we use mutual TLS with PKI, then we need to establish a common root for both requestors and Local Directory Services. • End to end encryption • Metadata and Caching: • Relevant metadata/data that needs to be stored at the State Level to facilitate federation, what is cached vs what is not ? • Protocols and Standards Required for Step A3 are same as those in Step A1: • Transport: • SOAP or RESTful • Content Structure: • DSML v2 structure • Content Meaning: • LDAP + ISO 21091 • ESI Data Model Elements • Audit: • IHE ATNA • Metadata storage: • Use the State Level Directory to store the metadata • OR • Create a Directory Lookup capability using standards such as DNS / UDDI etc..

9. Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (D&TS Interactions in Step #2) In-State Authorized Requestor Local Directory Service Local HIO Local HIO State Level Directory and Trust Services (D&TS) A1 Directory Services Directory Services Local Directory Responder A3 State Level Directory Responder A2 A4 A4 Provider Directory Provider Directory Out of State Authorized Requestor Security and Privacy addressed in the previous steps. Protocols and Standards Required are covered in the previous steps.

10. DIRECT and State Directory and Trust Services • DIRECT specifications allow to send (push) messages to “Known” , “Trusted” recipients in a secure manner • “Known” recipients requires prior knowledge of who to send information and where to send the information • “Trusted” recipients implies that the recipient follows good practices when dealing with the data (for e.g HIPAA) and will honor the patient’s privacy and state laws and is not reusing information for purposes beyond treatment • State Directory and Trust Services provide: • Trust: • Policies to Identity proof recipients • Provide the required level of identity assurance commensurate with the type of information exchanged • Business Processes to request, revoke credentials, SLA’s for processes • Directory Lookup: • Provide a mechanism to discover recipients instead of requiring prior knowledge using a variety of search criteria • Certificate Discovery for DIRECT • D&TS publishes certificates for entities/individuals who are not affiliated with the Local Directory Services.

11. Directory and Trust Services – Directed Exchange to Known Address Use Case - Description • Scenario Description: • An Authorized Requestor (Sender) is planning to send a patient’s information to a provider that the requestor does not have a trust relationship with, but already knows the electronic address for the receiving provider. • Scenario Flow: • 1. Authorized Requestor formulates a query using the receiver’s electronic address to verify trust. • 2.(*) Authorized Requestor executes the D&TS Use Case (A1 – A4) : “Request to Find Provider Information” • D&TS is used to ensure that the provider can be trusted (D&TS Identity proofing) • 3. Authorized Requestor uses the receiver’s electronic address to discover the receiver’s digital certificate using S&I PD Certificate Discovery Specifications. • (**) State D&TS will be used to find digital certificates for Providers who are not affiliated with any other Local HIO. • (*) : Services used for Step#2 is the primary set of services provided by D&TS. • (**) : State D&TS will also be used in Step #3 to find digital certificates for Providers who are not affiliated with any other HIO’s.