120 likes | 215 Views
Abstract Model Top Level Use Cases Terminology Top Level Use Cases Standards Mapping – Policies – Business Process Matrix Relationship between DIRECT and State Directory and Trust Services DIRECT Certificate Discovery and State Directory and Trust Services S&I ESI and State PD
E N D
Abstract Model • Top Level Use Cases • Terminology • Top Level Use Cases • Standards Mapping – Policies – Business Process Matrix • Relationship between DIRECT and State Directory and Trust Services • DIRECT Certificate Discovery and State Directory and Trust Services • S&I ESI and State PD • HITPC Recommendation and State Directory and Trust Services - TBD • NwHIN Governance and State Directory and Trust Services - TBD • BPMN Diagrams / Technical Views - TBD • Implementation Guidance and Specifications - TBD Directory and Trust Services
Directory and Trust Services – Abstract Model Local HIO Local HIO Local HIO Local HIO / In-State Provider State Level Directory and Trust Services Directory Services Local Directory Responder Directory Services Cross State Trust Anchor CA A5 In-State Authorized Requestor A2 A6 A1 Provider Directory Provider Directory Local Directory A6 State Level Directory Responder Out of State Authorized Requestor A3 A4 B3 Federated HIO’s Directory Metadata Authoritative State Directory B1 B4 C3 State Designated CA DTS Use Cases: (A1 – A6 ) Request to Find Provider Information: Authorized Requestor uses State Level Directory Service to locate Providers and their information (B1 – B4) Request to Participate in Federated Directory Services: A Local HIO within the state requests the State to federate directory requests from Authorized Requestors (C1 - C3) Request to delegate directory Services: A Local HIO or In-State Provider delegates the Directory Services to the State B2, C2 State Designated RA C1
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 • Authoritative State Directory: The Authoritative State Provider Directory represents the data that is maintained for each provider or a healthcare organization who is “Identity proofed” by the State Level Directory and Trust Services. The Identify proofing is dictated by policy options used to validate the identity and is represented by the NIST Identity Assurance Level. The • 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 transaction details. • Local HIO: An organization that is providing local (“Within State”) health information exchange 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 HIO may have it’s own Directory Responder and Provider Directory which are called as “Local Directory Responder” and “Local Provider Directory” respectively. In this case a Local HIO may ask the State Level Directory Responder to federate incoming directory requests based on certain metadata. • A Local HIO on the other hand may not host any directory services and may delegate all responsibilities to the State Level Directory Responder. • Federated HIO’s Directory Metadata: A Local HIO who requests the state to federate incoming directory requests will provide certain metadata to facilitate the federation. This metadata is designated as Federated HIO’s Directory Metadata. Typically this metadata includes the Local HIO’s Directory Responder’s end point, geographical areas served by the HIO’s, domain names, Practices served by the HIO all of which is only used for routing and filtering purposes. • State Designated RA: The State Designated Registration Authority (RA) is the set of services that are used to validate the credentials of providers or organizations requesting to participate in the State Level Directory and Trust Services as either In-State Authorized Requestors or Local HIO’s. • State Designated CA: The State Designated Certificate Authority (CA) is the set of services that are used to issue, manage, and revoke Digital Certificates to Providers or Organizations participating in the State Level Directory and Trust Services. • Cross State Trust Anchor CA: The Cross State Trust Anchor CA is the authority that issues Digital Certificates for organizations in multiple states. This would serve as a common root for the organizations willing to participate in the State Level Directory and Trust Services across state lines. Each state or organization may have an internal CA that roots to the Cross State Trust Anchor and fulfills the role locally. For e.g State Designated CA used for managing State Level Directory and Services digital certificates. Abstract Model Terminology
Directory and Trust Services – Directed Exchange to Unknown 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, and does not know the electronic address for the receiving provider. • Scenario Flow: • 1. Authorized Requestor obtains the required information about the receiving provider to formulate a query. • 2.(*) Authorized Requestor executes the DTS Use Case (A1 – A6) : “Request to Find Provider Information” • DTS is used to find the Provider’s electronic address • DTS is used to ensure that the provider can be trusted (DTS 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 DTS will be used to find digital certificates for Providers/HIO’s who delegate that responsibility to the State DTS. • (*) : Services used for Step#2 is the primary set of services provided by DTS. • (**) : State DTS will also be used in Step #3 to find digital certificates for Providers / HIO’s who delegate that responsibility to the State DTS by executing DTS Use Case (C1-C3) ”Request to delegate directory Services”.
Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (DTS Interactions in Step #2) State Level Directory and Trust Services Local HIO Local HIO Local HIO Cross State Trust Anchor CA Directory Services Directory Services Directory Services A5 In-State Authorized Requestor A2 A6 A1 Directory Provider Directory Provider Directory A6 State Level Directory Responder Out of State Authorized Requestor A3 A4 Federated HIO’s Directory Metadata Authoritative State Directory
Directory and Trust Services – Directed Exchange to Unknown Address Use Case - (DTS Interactions in Step #2) • Query Information: • Receiver’s name (First / Last Name) • Receiver’s affiliation (Practice Name if known) • Receiver’s Address (Zip code or City and Street) • Practice Specialty if known • Authorized Requestor’s identity details • Query Response Information (Responses may contain information about multiple recievers) • Receiver’s information • Name, Affiliation, Practice Specialty • Receiver’s electronic address • DIRECT address • Identity Assurance Information (Trust Information) • Identity Assurance Level • Federated Directory Metadata • Local HIO Directory Responder’s electronic address • HIO Service Area Details (Zip code or City and Street)
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 DTS Use Case (A1 – A6) : “Request to Find Provider Information” • DTS is used to ensure that the provider can be trusted (DTS 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 DTS will be used to find digital certificates for Providers/HIO’s who delegate that responsibility to the State DTS. • (*) : Services used for Step#2 is the primary set of services provided by DTS. • (**) : State DTS will also be used in Step #3 to find digital certificates for Providers / HIO’s who delegate that responsibility to the State DTS by executing DTS Use Case (C1-C3) ”Request to delegate directory Services”.
Directory and Trust Services – Request to Participate in Federated Directory Services State Level Directory and Trust Services Local HIO Local HIO Local HIO Local Directory Responder Directory Services Directory Services Federated HIO’s Directory Metadata Provider Directory Provider Directory Local Directory B4 B3 State Designated CA B2 B1 State Designated RA
Directory and Trust Services – Request to delegate PD Services Local HIO / In-State Provider State Level Directory and Trust Services Authoritative State Directory C1 C3 State Designated CA C2 State Designated RA
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 • DTS publishes certificates for entities/individuals who delegate their directory services to the state.
DIRECT Certificate Discovery and State Directory • DIRECT specifications call for the use of “DNS” to certificate discovery to sign and encrypt DIRECT message content • S&I PD Initiative calls for “Hybrid” approach using DNS and LDAP for certificate discovery to sign and encrypt DIRECT message content • State Directory and Trust Services will use the hybrid approach to publish and discover certificates for entities who delegate directory services to the State • When State Directory publishes certificates of the user or entity the S&I PD hybrid approach can be used for the purposes of certificate discovery • When the State PD does not have the certificate, the Local HIO or Provider must take care of publishing the certificate appropriately for discovery (This is the case for Federated Local HIO’s)
S&I ESI Data Model and State PD • ESI Data Model calls for a set of data elements to be exchanged in the discovery of Provider information including their electronic service information which includes information such as • End point address • Protocols • Security profile • Integration profile • State PD use cases have to be analyzed to determine the subset of elements that should be used for the provider information and be provided back during the directory response to a request.