1 / 31

HIT Standards Committee Privacy and Security Workgroup

HIT Standards Committee Privacy and Security Workgroup. Dixie Baker, Chair, Privacy and Security Workgroup Walter Suarez, Co-Chair, Privacy and Security Workgroup March 29, 2011. 1. Privacy and Security Workgroup. Dixie Baker, SAIC Anne Castro, BlueCross BlueShield of South Carolina

aideen
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, Privacy and Security Workgroup Walter Suarez, Co-Chair, Privacy and Security Workgroup March 29, 2011 1

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

  3. Agenda Standards Development Context Recommendations for Digital Signature Standard Requirements and Evaluation Criteria for Standard Need for Investigation Policy Questions for HIT Policy Committee Status Update on Recommendations for Standard for Enterprise-Level Provider Directories 3

  4. Standards Development Context Two needs for standards were assigned to Privacy and Security Workgroup: 1) digital certificates and 2) enterprise-level provider directories 4

  5. RECOMMENDATION #1:REQUIREMENTS AND EVALUATION CRITERIA FOR DIGITAL CERTIFICATE STANDARD 5

  6. Digital Certificate Basics A “digital certificate” is an electronic document that certifies that the subject (person or entity) has been issued a pair of encryption keys that are related in such a way that if one key is used to encrypt something (e.g., file, message, data stream), it can be decrypted only by someone holding the other key One key is published for anyone to see (“public key”) The other key is kept secret by the entity/person to whom the digital certificate has been issued (“private key”) Digital certificates are issued by a “certificate authority” (CA) – and digitally signed by the issuing CA CA certificates may be self-issued and self-signed certificates CAs periodically publish a “certificate revocation list (CRL)” that identifies those certificates that no longer are valid and that have not expired 6

  7. Digital Certificate Basics Digital certificates are used for a number of purposes, including: To authenticate the identity of an entity or person using a challenge-response mechanism To digitally sign a message or other transmitted content (“digital signature”) To share a secret key to be used to exchange private or sensitive information The trustworthiness of a digital certificate is dependent upon how much the user trusts the issuer of the certificate – which may be the top CA in a hierarchical PKI, the CA that issued the user’s own certificate, or any other trusted CA The practices used by a CA in issuing and managing certificates are described in its Certification Practice Statement (CPS) CPSs may be certified by organizations such as the European Telecommunications Standards Institute (ETSI) and WebTrust, or as meeting minimal standards established by specific communities, such as SAFE Bio-Pharma and Federal Bridge 7

  8. Digital Certificate Trust Models Trust Anchor (Root CA) Trust Anchor (Root CA) Trust Anchor (CA) Trust Anchor (CA) Trust Anchor (CA) Trust Anchor (CA) Trust Anchor (CA) PKI-1 Root CA user Bob trusts everyone in his PKI hierarchy User CA CA CA CA User User Alice User User User Bob user Alice trusts certificates issued by her own trust anchor and by other trust anchors she deems trustworthy User User User User User User “Multi-Root” Model (e.g., the Direct Project) Hierarchical PKI 8

  9. Digital Certificate Content Signature of CA that issued certificate Algorithm used by the CA to sign the certificate Version Serial number Name of the CA that issued certificate Period of time for which the certificate is valid Name of the subject to whom the certificate is issued The subject’s public key Optional extensions – such as the purposes for which the certificate may be used 9

  10. Recommended Requirements Digital certificates must conform to the X.509 V3 certificate profile defined in RFC 5280 (May 2008) Digital certificates to support Direct exchanges: MUST include the set of Basic Certificate Fields defined in Section 4.1 of RFC 5280 MUST include the Standard Extensions needed to support the simple mail transfer protocol (SMTP) with Secure/Multipurpose Internet Mail Extensions (S/MIME) MAY include additional Standard Extensions as defined in Section 4.2 of RFC 5280 Digital certificates to support NW-HIN exchanges: MUST include the set of Basic Certificate Fields defined in Section 4.1 of RFC 5280 MUST include the Standard Extensions needed to support mutually authenticated transport layer security (TLS) connections MAY include additional Standard Extensions as defined in Section 4.2 of RFC 5280 Certificate revocation lists (CRLs) MUST conform to the X.509 V2 CRL profile defined in Section 5 of RFC 5280 (which supports both Online Certificate Status Protocol (OCSP) and full CRL retrieval) Nothing in these requirements precludes the specification of a single standard for a certificate usable for both Direct and NW-HIN exchanges 10

  11. Recommended Evaluation Criteria Does the standard conform to the X.509 V3 profile defined in RFC 5280? Does the standard specify the Basic Certificate Fields and Extensions as REQUIRED for Direct exchanges? Does the standard specify the Basic Certificate Fields and Extensions as REQUIRED for NW-HIN exchanges? If the standard includes one or more additional Extensions, are these as specified in the Standard Certificate Extensions defined in RFC 5280? If the standard includes Extensions applicable only to Direct or NW-HIN exchanges, are the intended usage of these Extensions clear and unambiguous? Does the standard include X.509 V2 certificate revocation lists (CRLs) as defined in RFC 5280? Is the standard specified clearly and completely enough for a developer to implement? 11

  12. RECOMMENDATION #2:NEED FOR INVESTIGATION OF ALTERNATIVES FOR CROSS-CERTIFYING DIGITAL CERTIFICATE ISSUERS WITH FEDERAL BRIDGE CA 12

  13. All digital certificates used by federal agencies must link back to the Federal Common Policy Framework Certificate Authority (CA) and must include the assurance level under which the certificate was issued Four levels (rudimentary, basic, medium, high) correspond to NIST levels 1-4 Includes several “flavors” of medium assurance for software, hardware and Personal Identity Verification (PIV)-card-based certificates Certificates used to support exchanges between federal agencies and state agencies must be issued by a CA that is cross-certified with the Federal Bridge CA To enable health exchanges between the NW-HIN Exchange and federal health agencies, the NW-HIN managed Public Key Infrastructure (mPKI) is cross-certified with the Federal Bridge CA Bridging with Federal Certificate Authority 13

  14. Federal PKI Architecture* One-way, certifier-to-user relationship Two-way, certifier-to-certifier relationship (“cross-certification”) Federal Common Policy Framework CA Federal Bridge CA Certipath Bridge (Aerospace & Defense) SAFE Biopharma Bridge Non-Federal Bridges NwHIN mPKI 14 *Adapted from Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, Nov 10, 2009

  15. The Direct Project allows a “multi-root” model in which certificates are generated by CAs without a common root – such as Healthcare Interoperability Service Providers (HISPs) Both NW-HIN and Direct users will need to exchange health information with federal health agencies – most prominently the VA and CMS How feasible would it be to require that certificates used in Direct exchanges be obtained from CAs linked to a bridge or CA cross-certified with the Federal Bridge CA? Direct Exchanges with Federal Entities 15

  16. Notional Architecture with Direct Cross-Certification One-way, certifier-to-user relationship Two-way, certifier-to-certifier relationship (“cross-certification”) Federal Common Policy Framework CA Federal Bridge CA HISP CA HISP CA HISP CA HISP CA Certipath Bridge (Aerospace & Defense) Direct Bridge CA SAFE Biopharma Bridge Non-Federal Bridges NW-HIN mPKI 16 *Adapted from Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance, Nov 10, 2009

  17. Recommendation to ONC • To enable Direct users to exchange health information with federal health agencies, the HITSC Privacy and Security Workgroup recommends that the ONC investigate architectural and operational alternatives for cross-certifying Direct CAs with the Federal Bridge CA, including implications on cost, market dynamics, and complexity 17

  18. RECOMMENDATION #3:POLICY QUESTIONS FOR HIT POLICY COMMITTEE 18

  19. Certificate Trust Issue A digital certificate can be trusted only to the extent to which the user trusts the CA who issued the certificate Anyone can set themselves up as a CA and issue certificates Certificates used by Direct Project entities may be issued by any CA – and the decision of whether to trust the certificate is left up to the communicating entity’s trust relationship with the issuing CA (i.e., whether the CA is recognized as a “trust anchor”) To exchange information with federal entities (e.g., VA, CMS), the user will need to hold a certificate that was issued by a CA that is trusted by the Federal Bridge CA 19

  20. Recommended Policy Question for HITPC Policy and governance are needed around CAs who issue certificates for use in health exchanges, such as Direct Defining a mechanism for establishing the legitimacy and trustworthiness of a certificate authority Defining a minimum level of trustworthiness for CAs issuing certificates for Direct exchanges; for example: Is certification by WebTrust or ETSI sufficient for health information exchange? Does the CA need to meet the minimum standard defined for a trusted relationship with the Federal Bridge CA? 20

  21. SPECIFICATION OF REQUIREMENTS FOR ENTITY-LEVEL PROVIDER DIRECTORIES (ELPDs) 21

  22. HITPC APPROVED RECOMMENDATIONS RE ELPDs (1 of 4) 22 Extracted from HITPC Official Meeting Materials

  23. HITPC APPROVED RECOMMENDATIONS RE ELPDs (2 of 4) 23 Extracted from HITPC Official Meeting Materials

  24. HITPC APPROVED RECOMMENDATIONS RE ELPDs (3 of 4) 24 Extracted from HITPC Official Meeting Materials

  25. HITPC APPROVED RECOMMENDATIONS RE ELPDs (4 of 4) 25 Extracted from HITPC Official Meeting Materials

  26. ELPD Model ELPD Registration Process ELPD Query/Response ELPD ELPD Registrar ELPD National Registry System ELPD ELPD Registrar ELPD ELPD Registrar 26 Extracted from HITPC Official Meeting Materials

  27. Standards Requirements ELPD National Registry System ELPD ELPD Registrar Certification Criteria for EHRs to Support ELPD Messages (policy needs) ELPD Registrar Certification; ELPD Certification; Guidelines for Verification/ Validation; Registrar Reciprocity Standards for Query/Response Messages Standard for ELPD Submission to National Registry Standard for ELPD Structure and Content 27

  28. Standards Requirements We Need to Recommend (1 of 2) • ELPD Structure and Content • To support discoverability requirements (entity, information exchange capabilities, entity’s security credentials) • To support links with ILPDs (each ILPD entry will reference and point to one or more ELPD entries) • Minimum data set, definition of data elements that includes entity demographics, information exchange capabilities supported and security credentials • Submission to National Registry • Publication/posting protocol 28

  29. Standards Requirements We Need to Recommend (2 of 2) • ELPD Query • Query language • Messaging • EHR Certification Standards and Criteria 29

  30. Progress to Date (1 of 2) • Discussion of HITPC recommendations • Reviewed Testimony from September 30, 2010, Provider Directory Hearing • First priority should focus on a “thin layer of discoverability” for entity-level directories – not at the clinician level (important, but second order) • Reviewed related work • NW-HIN requirements for directory services (Avinash Shanbhag) • Department of Vermont Health Access (Hunt Blair) • The Direct Project (Arien Malec) • Veterans Health Administration (Mike Davis) 30

  31. Progress to Date (2 of 2) • HITPC Information Exchange Workgroup scheduled to present recommendations for individual-level provider directories (ILPDs) on April 13 • Clear need to specify separate standards for ELPDs and ILPDs, whild recognizing interdependencies and linkages between the two and use cases involving both • Requested HITSC leadership’s permission to delay delivery of ELPD requirements recommendations to enable us to consider both concurrently • Expect to deliver recommendations for both ELPDs and ILPDs to HITSC at May meeting 31

More Related