Electronic Submission of Medical Documentation (esMD)
1 / 22

Wednesday May 16, 2012 - PowerPoint PPT Presentation

  • Uploaded on

Electronic Submission of Medical Documentation (esMD) Digital Signature and Author of Record Pre-Discovery. Wednesday May 16, 2012. Agenda. Schedule and objectives Scope of workgroup effort Review of standards Review options as explored in other initiatives. Schedule -- Original.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Wednesday May 16, 2012' - orenda

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Wednesday may 16 2012

Electronic Submission of Medical Documentation (esMD)Digital Signature and Author of Record Pre-Discovery

Wednesday May 16, 2012


  • Schedule and objectives

  • Scope of workgroup effort

  • Review of standards

  • Review options as explored in other initiatives

Scope of workgroup effort
Scope of workgroup effort

  • Identity proofing

  • Digital identity management

  • Encryption

  • Digital signatures

  • Delegation of Rights

  • Author of Record

Review of standards and solutions
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

Additional ihe and hitsp standards
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)

Summary documents
Summary Documents

  • Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance (ID: CSD5885)

  • 3/5/2012

Background nist e authentication guidelines sp 800 63
Background: NIST E-Authentication Guidelines SP 800-63

Note: Other security frameworks have been developed and have been used in the private sector

National health information network exchange
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

Dea level 3 factors from 800 63 draft
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

Identity proofing stakeholder
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

Identity management stakeholder
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

Encryption stakeholder
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

Signing stakeholder
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

Delegation of rights stakeholder
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

Author of record stakeholder
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)

Next steps
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