1 / 12

HIT Standards Committee Privacy and Security Workgroup

HIT Standards Committee Privacy and Security Workgroup. Dixie Baker, Chair Walter Suarez, Co-Chair June 22, 2011. Dixie Baker, SAIC Anne Castro, BlueCross BlueShield of South Carolina Aneesh Chopra, Federal Chief Technology Officer Mike Davis, Veterans Health Administration

brad
Download Presentation

HIT Standards Committee Privacy and Security Workgroup

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. HIT Standards CommitteePrivacy and Security Workgroup Dixie Baker, Chair Walter Suarez, Co-Chair June 22, 2011

  2. Dixie Baker, SAIC Anne Castro, BlueCross BlueShield of South Carolina Aneesh Chopra, Federal Chief Technology Officer Mike Davis, Veterans Health Administration Lisa Gallagher, HIMSS Chad Hirsch, Mayo Ed Larsen David McCallie, Cerner Corporation John Moehrke, General Electric Steve Findlay, Consumers Union Jeff Jonas, IBM Wes Rishel, Gartner Walter Suarez, Kaiser Permanente Sharon Terry, Genetic Alliance Privacy and Security Workgroup NEW MEMBER

  3. Agenda Provider Directory Standards Review through May HITSC meeting Activity since the May meeting Next topic: Stage 2 meaningful-use standards Recommendations

  4. Enterprise-Level Provider Directory (ELPD) Review:Need Identified by HIT Policy Committee • HIT Policy Committee identified need for national ELPD system that would provide the capability to search for and find “discoverable” information essential for enabling exchange of health information between enterprises – limited content to: • Basic entity information (e.g., name, address, human point-of-contact) • Externally accessible information describing exchange services (e.g., domains, message protocols, transport protocols, “inbox” locations) • Security credentials

  5. Enterprise-Level Provider Directory (ELPD) Review:Initial Focus and Recommendation to HITSC • ONC requested that HITSC address immediate need for standards and certification criteria to support EHR query of ELPD per HITPC policy recommendations • At May HITSC meeting, Privacy and Security Workgroup recommended tailored subset of IHE Healthcare Provider Directory (HPD) profile as standard to provide required functionality and content • HITSC Response • Recommendation was good representation of current state of applicable directory standards, but national ELPD capability may not be necessary for exchange • Direct Project approach of using domain name service (DNS) query to retrieve digital certificates may be good enough for the short term, with EHR query of ELPDs as a longer term vision • Recommended working with HIT Policy Committee and ONC to refine business requirements

  6. Provider Directory Activity Since May HITSC Meeting • ONC Standards and Interoperability (S&I) Framework launched work on provider directories, focusing primarily on community-based directories • Certificate discovery • Search & retrieval of provider information when provider address is known/not known • Alternatives for providing national-level functionality were suggested by members of both HITPC and HITSC • Broadly adopt Direct Project’s strategy of using Domain Name Service (DNS) to retrieve digital certificates • Create health top-level-domain (TLD) – something like <hospital>.MED to facilitate end-user search for information about trusted health exchange points • Use embedded microformats to standardize tagged data fields and vocabulary for providing directory information from a protected web page • Privacy and Security Workgroup considered these alternatives

  7. Results from Consideration of Alternatives • Lack a strong business case for creating health TLD – potential benefit would not justify significant effort required • Direct Project’s use of DNS to retrieve digital certificates is working well and has been generally accepted by participants in Direct pilot • Some browsers and email clients do not currently support query of DNS for digital certificates needed for secure email and secure web connections – though DNS specification does include the capability • DNS cannot be used to retrieve more general directory information, such as the transport standards supported, or rich content, such as specialties of provider organizations • Use of DNS for certificate retrieval, along with with publishing of web pages providing additional directory information as structured, encoded content warrants further consideration

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

  9. DNS + Structured & Encoded Web Content • 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”

  10. Next Topic: Privacy and Security for Stage 2 • Stage 2 measures are unlikely to significantly change required EHR privacy and security functionality or content • However, HITPC Privacy and Security Tiger Team has recommended policies that do imply new EHR privacy and security standards and functionality • Privacy and Security Workgroup has undertaken an examination of these recommended policies to identify new needs for EHR standards, implementation specifications, and certification criteria

  11. Example Privacy and Security Functionality Derived from Tiger Team Recommendations • Secure email and web transactions • Retrieval, validation, and use of intended recipient’s digital certificate to authenticate recipient • Strong protection of sender’s digital certificate • Use of sender’s digital certificate to authenticate sender and to digitally sign content • Support two-factor authentication for high-risk transactions, including e-prescribing of controlled substances • Detect and block programmatic attacks, and attacks from unauthorized entities • Enable consumers to securely download their own health information, including provenance, and to securely send their health information to a third party • Audit events on consumer portals • Require consumer to log into consumer portal before accessing health information • Standard metadata and vocabulary for data fields commonly used in patient matching (may be a Clinical Operations assignment)

  12. Summary • Recommendation: Recommend that S&I Framework team consider approach of structuring and encoding web content, using standard schema and vocabulary, for meeting need for nationwide access to directory information without requiring “national provider directory” • Will present initial recommendations for Stage 2 privacy and security standards, implementation specifications, and certification criteria at July meeting

More Related