Download presentation
Presentation is loading. Please wait.
Published byBrenda Holderness Modified over 10 years ago
1
Directory and Trust Services (D&TS) 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
2
Directory and Trust Services – Abstract Model 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. State Level Directory and Trust Services (D&TS) Directory Services Provider Directory Local HIO State Level Directory Responder Directory Services Provider Directory Local HIO Local Directory Responder Local Directory Service In-State Authorized Requestor Out of State Authorized Requestor A1 A3 A4 A2 A4 State Level Trust Service B2 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
3
Abstract Model Terminology 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 providers DIRECT mailing address Discover the Providers Electronic Service Address for Query / Response Discover the certificates and protocols for a Providers 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 (EMRs, HISPs), Organizations (Health Plans, IDNs) 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 its own Directory Responder which is called as Local Directory Responder. Examples of Local Directory Services may be provided by HIOs, 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.
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 patients 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 Providers electronic address D&TS is used to ensure that the provider can be trusted (D&TS Identity proofing) 3. Authorized Requestor uses the receivers electronic address to discover the receivers 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 HIOs. (*) : 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 HIOs.
5
Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (D&TS Interactions in Step #2) #DescriptionSecurity and Privacy Controls Applicable PoliciesBusiness Processes Required A1Requestor submits a request to SLDR to find details about a Provider using available query elements Requestor Identity Validation, Message Integrity, Message Confidentiality, Audit Log 1.Legal Agreements for interstate exchange 2.Policies to authorize requestors 3.Minimum Query Elements necessary to use D&TS 1.In-State Requestor Onboarding (Entity/Individual) 2.Out of State Requestor Onboarding (Entity/Individual) 3.SLDR Endpoint Discovery and Configuration A2Lookup Directory to check if the requested provider is found (Check for providers not affiliated with Local Directory Service) 1.Accounting of Disclosures 2.Provider attributes stored including policy attributes 1.Identify use cases that will be supported + Search Criteria for each use case 2.Provider Onboarding process for unaffiliated providers A3If Provider information is not found in Step A2, Send Routing requests to the Local Directory Service Requestor Identity Validation, Message Integrity, Message Confidentiality, Audit Log 1.Legal Agreements for intrastate federation (Participation agreement) 2.Data Elements required for directory federation and sensitivity of the data 1.Local Directory Service Onboarding process for Federation 2.SLAs for Federated PDs 3.Error Handling and Notifications A4Send Responses back to Requestors Message Integrity, Message Confidentiality, Audit Log 1.Disclosure Notices, Purpose of Use of the disclosed information. 2.Data Elements that can be revealed 3.What is the threshold for the number of results if any 1.Error Handling and Notifications 2.Exception handling required by organizations 3.Process to handle information about multiple providers State Level Directory and Trust Services (D&TS) Directory Services Provider Directory Local HIO State Level Directory Responder Directory Services Provider Directory Local HIO Local Directory Responder Local Directory Service In-State Authorized Requestor Out of State Authorized Requestor A1 A3 A4 A2 A4
6
Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (D&TS Interactions in Step #2) Query Information Policy 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 OptionProsCons Requestor queries based on basic search criteria without any policy information The requestor can apply policies locally and does not need to explicitly specify in each query or expose them to other organizations Control is in the hands of the requestor Handling policies in small practices will be difficult unless there are simple, easy and intuitive ways of dealing with it as part of the workflow Too much data might be returned when not necessary Requestor points D&TS to a set of policies that need to be applied when determining the query result Requestor workflows will be simplified because they have to take care of policies infrequently (once during onboarding and every time there is a change) D&TS has to apply these policies as part of the query / response procedures accurately D&TS has to either have access or store these policies to apply during the processing Requestor sends policy information as part of the query D&TS does not have to access or store another policy registry during execution Systems used within the workflows have to append the policy information which is more static than the search criteria and then send the query to D&TS Might require vendor support to perform this action
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. Receivers name (First / Last Name) Receivers affiliation (Practice Name if known) Receivers Address (Zip code or City and Street) if known Practice Specialty if known Authorized Senders 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. Receivers information Name, Affiliation, Practice Specialty Receivers electronic address DIRECT address (For the pilot but can be extended to other modes of exchange and 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 Responders electronic address Local Directory Service Area Details (Zip code or City and Street) Providers 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 patients 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, SLAs 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 patients 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 receivers 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 receivers electronic address to discover the receivers 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 HIOs.
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.