1 / 12

N wHIN Power Team

N wHIN Power Team. Provider Directories Deliberations. May 29, 2014. Provider Directory Deliberation Points. Limit certification requirement to focus on Direct messages to enable the exchange of patient information What to Certify

gay-keller
Download Presentation

N wHIN Power Team

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. NwHIN Power Team Provider Directories Deliberations May 29, 2014

  2. Provider Directory Deliberation Points • Limit certification requirement to focus on Direct messages to enable the exchange of patient information • What to Certify • At a minimum, EHR technology would need to be able to query external provider directories for the following information and electronically process the response returned in accordance with the Modular Specification Provider Directories Implementation Guide: •      Query for an individual provider’s Direct address; •      Query for an organizational provider’s Direct address; •      Query for relationships between individual providers and organizational providers • Authentication required for certification • Authentication of the directory service – Basic TLS handshake does this • Does query of a directory service include any data elements that would necessitate authentication of the client (queryer) as well? • Nothing sensitive in the data model beyond name and routing information ( address, email, fax, where to send patient record information) • Standards to recommend • TLS – basic server-only authentication or mutual authentication? • HPD+

  3. Mod Spec of HPD+(ISO 21091, IHE HPD Base + CP 601) • Endpoint addresses • include individual and organizational addresses • memberships between individuals and organizations • electronic service addresses, certificates associated with electronic services • Query • Based onDSML v2 • Supports “AND”, “OR”, “NOT”; “String” and “RegEX” match type • Transport and Application Protocols • SOAP 1.2 over HTTP based on the Web Services for IHE Transactions Appendix V in ITI-TF Vol2. • Synchronous Web Services • DSMLv2 with SOAP bindings over HTTP • Does not support REST at this time (on the current roadmap) • Security • Mutual TLS to protect message • No additional security controls specified for query • Limitations • No Discovery • No Incremental fetch

  4. Blank

  5. HITSC Tasking HITSC Tasking

  6. Functionality Recommended by HITPC IE WG • Search for provider: EHR systems have the ability to query external provider directories to discover and consume addressing and security credential information to support directed and query exchange • Respond to search: EHR systems have the ability to expose a provider directory containing EPs and EH addressing and security credential information Functionality Recommended by HITPC IE WG

  7. HITPC IE WG Recommendations Guidelines • Scope:Standards must address PD transactions (query and response) as well as minimum acceptable PD content to enable directed and query exchange • Continuity: Build on Stage 1 and 2 approaches and infrastructure for directed exchange where possible and allow use of organized HIE or cross-entity PD infrastructures where applicable and available (ie, remain agnostic to architecture and implementation approaches) • Simplification: Set goal of having PD query and response happen in a single (or minimal) set of transactions • External EHR system: An EHR system of another distinct legal entity, regardless of vendor • Transactions: • Querying systems must have ability to: • Present authenticating credentials of requesting entity • Validate authenticating credentials of provider directory holding entity • Present provider-identifying information • Securely transmit query message • Provider directory must have ability to: • Validate authenticating credentials of requesting entity • Present authenticating credentials to requesting entity • Match provider • Respond with unambiguous information necessary for message addressing and encryption or acknowledgement of non-fulfillment of request • Provider directories must have administrative capabilities to: •  Submit updated provider directory information (additions, changes, deletions) to external provider directories • Receive and process provider directory updates from external provider directories • Transaction details: • Provider directories should contain minimum amount of information necessary on EPs and EHs to address and encrypt directed exchange and/or query for a patient record messages HITPC IE WG Recommendations Guidelines

  8. Previous HITSC Recommendations Re Standards for Provider Directories Previous HITSC Recommendations Re Standards for Provider Directories

  9. May 12, 2011: Privacy & Security WG Recommendation for S&I Framework PD Activity 1 The Standards and Interoperability Framework team should select either REST or SOAP, as most appropriate within the context of the NwHIN standards currently being defined. 2 To support LDAP federation, a profile specifying a standardized way to federate LDAP directories is needed.

  10. P&S WG Response to Provider Directory Tasking June 22, 2011: Privacy & Security WG Response to Provider Directory Tasking DNS + Structured & Encoded Web Content: Concept • Organizations create public web pages containing directory information they wish to expose for search • Provider directory information is structured and encoded into the web page, using standard schema and vocabulary • Improves search engine indexing • Enables extraction of information into local systems (EHR, Exchange gateway, Direct HISP, etc.) • Organizations can obtain Extended Validation certificates to provide assurance of the authenticity of its web pages • Standard search engines provide a flexible and free Query Service • DNS is used to retrieve digital certificates for the published service address names which have been embedded in the web pages

  11. June 22, 2011: Privacy & Security WG Response to Provider Directory Tasking (cont.) DNS + Structured + Encoded Web Content: Recommendation • Benefits • Simple, widely available, and highly scalable web technology • Three leading search engines (Google, Bing, Yahoo!) have launched Schema.org metadata project to provide tools for building common vocabulary for structuring web page data • Organization maintains control over what information is exposed • Can start simple and build over time • Allows discovery of services and certificates using familiar names, without requiring advance knowledge of formal identifier (e.g., OID used in NwHIN Exchange, Direct Address) • Recommend that S&I Framework team consider this approach for meeting need for nationwide access to directory information without requiring “national provider directory”

  12. January, 2013: Response to Stage 3 RFC (PSWG + NwHIN PT)

More Related