Directory and Trust Services (D&TS)

1. Define an Abstract Model • 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 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 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) • Query InformationPolicy Discussion: • Multiple Issue to discuss: • Should the requestor just query based on basic search criteria like (Name, Zip code, Specialty etc) • Should the requestor point D&TS to a set of policies that need to be applied when determining the query result • Should the requestor send policy information as part of the query

7. Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (DTS Interactions in Step #2) • Query Information: The following are examples of the kinds of search criteria that the Sender would be submitting to the D&TS. • We need to identify the minimum required set for D&TS services. • Receiver’s name (First / Last Name) • Receiver’s affiliation (Practice Name if known) • Receiver’s Address (Zip code or City and Street) if known • Practice Specialty if known • Authorized Sender’s identity details (This might be useful to apply disclosure rules, where a particular receiver might not want to reveal their information to certain requestors) • Policy requirements of the sender (For e.g I will only share with signatories to HIPAA compliant BA, NIST Level 3, Current Licensed Provider) • Query Response Information: (Responses may contain information about multiple receivers) – S&I ESI Object Model identifies a number of attributes, highlighting some of the important ones. • Receiver’s information • Name, Affiliation, Practice Specialty • Receiver’s electronic address • DIRECT address (For the pilot but can be extended to other modes of exchangeand can be other electronic addresses) • Trust and Policy Information • Identify the level of policies that the receiver complies with and the level of assurance at which the identity has been proofed • Accounting of Disclosures audit record ID (or the entire record) • What is the receipt that you get back to document why you parameterized • your message the way did) • Metadata for Directory Federation: This is used determine if a Local Directory Service is likely to have a relevant response. This will reduce the number of Local Directory Services to which an incoming query will be federated. For e.g if we know the county information, then only Local Directory Services serving that county could be queried. • Local Directory Responder’s electronic address • Local Directory Service Area Details (Zip code or City and Street) • Provider’s information - ??

8. 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.

9. 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.