Wednesday May 16, 2012

1. Electronic Submission of Medical Documentation (esMD)Digital Signature and Author of Record Pre-Discovery Wednesday May 16, 2012

2. Agenda • Schedule and objectives • Scope of workgroup effort • Review of standards • Review options as explored in other initiatives

3. Schedule -- Original

4. Schedule – Amended and Proposed

5. Scope of workgroup effort • Identity proofing • Digital identity management • Encryption • Digital signatures • Delegation of Rights • Author of Record

6. Initiative Requirement Summary

7. Review of Standards and Solutions • Applicable Standards (overview) • Option and approaches for • Identify proofing • Digital identity management • Encryption • Digital signatures • Delegation of rights • Author of Record • Approach: Examples and then group input

8. Relevant Standards

9. Additional IHE and HITSP Standards • Identity Management • IHE PWP IETF: RFC‐2181, ‐2219, ‐2782 (DNS services) • IHE PWP IETF: RFC‐2251, ‐2252, ‐2253 (LDAP) • Non-repudiation • IHE XDM IETF Cryptographic Message Syntax, RFC‐2630, ‐3852 • IHE DSG ISO/TS‐17090, Health Informatics, Public Key Infrastructure • HITSP C26 ETSI Technical Specification TS 101 903: XML Advanced Electronic Signatures (XadES) • HITSP C26 ASTM Standard Guide for Electronic Authentication of Health Care Information: # E1762‐95(2003) • Secure Transmission • IHE ATNA FIPS 197, Advanced Encryption Standard • IHE ATNA FIPS PUB 180‐2 with change notice to include SHA‐224. • IHE ATNA IETF Transport Layer Security (TLS) Protocol: RFC 2246, RFC 3546 • IHE BPPC IHE ITI‐TF Cross Enterprise Document Reliable Interchange (XDR)

10. Summary Documents • Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance (ID: CSD5885) • 3/5/2012

11. Background: NIST E-Authentication Guidelines SP 800-63 Note: Other security frameworks have been developed and have been used in the private sector

12. National Health Information Network Exchange •  Authentication performed at the Gateway (machine) level, using certificates issued at the Exchange level • Gateways generally correspond to Participants (signatories to the DURSA) which may be Federal providers or agencies, IDNs, State or Regional HIOs, etc. • Behind the Gateway, Participants implement authentication and express the result of authentication in SAML assertions • Requirements for authentication defined at a high level in the DURSA, not otherwise standardized  See background section for relevant excerpts from the DURSA

13. DEA Level 3 – Factors from 800-63 Draft • Knowledge Tokens • Memorized Secret Token (password) • Pre-registered Knowledge Token (favorite ice cream flavor) • Look-up Secret Token (card with number in cells) • Out of Band Token (text message to cell phone) • Hard Tokens • Single Factor (SF) One Time Password (OTP) Device (SecureID fob) • Multi Factor (MF) OTP Device (OTP w/biometric unlock mechanism) • SF Cryptographic Device (FIPS verified crypto software) • MF Software Cryptographic Token (crypto software activated by password or biometric) • MF Cryptographic Device (crypto device activated by password or biometric) • Stringent identity proofing requirements • e.g., requires use of federally approved credential service providers (CSPs) or certification authorities (CAs) • The computer being used is not by itself a factor • A biometric adds to the factor count when activating a device but not when used directly

14. Identity Proofing and Authentication: The Process

15. Identity Proofing (Stakeholder) • Identity proofing compatible with requirements of the federal bridge (i.e. certification authorities cross-certified with the federal bridge) • Numerous certificate issuers have a variety of processes for ID proofing which needs to be further explored (i.e. notaries, raised seals, stamps, Lexis Nexis) • Identity proofing for organizations • Establish a responsible party within the organization taking responsibility for the information (person with authority to bind the organization, may include physical visits to verify identify) • Mix between individual and organization level authorization with IHEs in various states such as Oregon and Arizona

16. Identity Management (Stakeholder) • Digital certificates (X509, *assertion) • Work-level identity management • Individual level: single level/one-factor (password) • Within the context of an organization, an individual may be certified with a lesser approach than a digital certificate • General Applicability of tokens/certificates • One or multiple certificates/tokens per organization based on specific Use Case(s)? • DS4P: Requirement to be able to identify the organization and departments within an organization; therefore, multiple certificates may be needed for each organization for each department • Individual level may be needed depending on the Use Case * Indicates an item added during the meeting on 5/16

17. Encryption (Stakeholder) • Who • Author • Sending System • Third party • *Authority at source • What • Message (i.e.- HL7 2.x transported on MLLP) • *Routing/Header • *Transport • Metadata • Payload (if content neutral message) • Why • Protect from inappropriate use • Avoid tampering • *Non-repudiation • How • Secure transmission vehicles (VPNs) • Secure transmission protocols • *TLS (AES Encryption) • *Message and Transport Mechanisms * Indicates an item added during the meeting on 5/16

18. Signing (Stakeholder) • Who • Author • Sending System • Third party • *Authority at the source • What • Message • Metadata • Payload (if content neutral message) • *Assertions (i.e.- SAML holder of key, piece of metadata that goes along with a message) • Legal/Compliance vs. Technical • Why • Authenticity of a message (e.g. encrypt hash) • Authenticity of individual • As proof of identity • How • Operationally • Signature Artifact (characteristics) • *IHE Digital Signature Profile • *SMIME and detached signatures * Indicates an item added during the meeting on 5/16

19. Delegation of Rights (Stakeholder) • Who is delegating rights • What rights are they delegating • What is the process for delegation • *Proxy accounts for EHRs and HIEs • How is the delegation used and proved to a third party • e.g. Signature/Assignment Artifact (characteristics) • *Considerations • Transcriber/Nurses’ Agent vs. Author • Credentials of parent and proxy • Patient and healthcare proxy • Distinction between electronic and cryptographic signatures * Indicates an item added during the meeting on 5/16

20. Author of Record (Stakeholder) • Who is the Author • Contributor • Responsible party • Legal owner • What are they “signing” • Specific contribution • Final “document” • Assembled set of “documents” • Why • Verify authenticity of the content • Verify credentials of “author” • Legal proof of “author” • How • Operationally • Signature Artifact (characteristics)

21. Summary (Stakeholder)

22. Next Steps • Do we want an additional call next week 5/23 10am EDT to continue the pre-discovery process • Focus on issues and challenges • Consideration for technical, cost, regulatory, implementation and operational issues