Skip this Video
Download Presentation
Wednesday May 16, 2012

Loading in 2 Seconds...

play fullscreen
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

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