Electronic Submission of Medical
Documentation (esMD)
Digital Signature and Author of
Record Pre-Discovery
Wednesday May 23, 2012
1
Agenda
1.
2.
3.
4.
5.
6.
Schedule and objectives
Scope of workgroup effort
Johnathan Coleman – lessons learned
Finish review and continue with – issues
Discussion of priorities
Scope of esMD AoR workgroup
2
Schedule – Amended and Proposed
Date
Objective(s)
Wednesday, May 2nd, 2012, 10 AM
(Week 1)
Identify the needs of other S&I initiatives, the
community at large, and esMD
Wednesday, May 9th, 2012, 10 AM
(Week 2)
Conduct a survey of details, options and
approaches to meeting the specific needs from
Week 1
Wednesday, May 16th, 2012, 10 AM
(Week 3)
Continue with effort from Week 2 and start to
identify operational, technical and cost issues
associated with various solutions
Wednesday, May 23rd, 2012, 10 AM Finish Week 3 effort and discuss priorities
(Week 4) – new, stakeholder decision
3
Scope of workgroup effort
1.
2.
3.
4.
5.
6.
Identity proofing
Digital identity management
Encryption
Digital signatures
Delegation of Rights
Author of Record
4
Initiative Requirement Summary
Encryption
Delegation
of Rights
Author
of
Record
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Org/Individual
Yes
Yes
Yes
Yes
Yes
Healthcare
Directories
Org/Individual
Yes
Yes
Yes
Yes
Audit?
LCC
Org/Individual
Yes
Yes
Yes
Yes
Yes
Query Health
Org/Individual
Yes
Yes
Yes
Transitions of
Care
Org/Individual
Yes
Yes
Yes
Identify Proofing
Digital Identity
Management
Signing
(Exchange Artifact)
DS4P
Org/Individual
Yes
Direct Project
Address/Server
esMD
Initiative
Yes
Mandatory
Optional with consequences
Optional
Future Uses
5
ICM-WG Report
Highlights from the Healthcare Information Technology Standards Panel,
Identity Credentials Management Working Group ICM-WG) Report to the
Security, Privacy and Infrastructure Technical Committee.
Original Report prepared by Co-Chairs Mike Davis (VA) and Richard Thoreson
(SAMHSA) in Jan 2008
Presented by Johnathan Coleman,
DS4P Initiative Coordinator
5/9/2012
6
ICM-WG Charter
The charter included a requirement to identify all issues
related to identity credentials that affect health information
exchanges and the interoperability of those exchanges,
including system and user authentication, identity
assertion, identity proofing, assertion validation, identity
credentials and privilege management, and others.
Addressed through 8 specific tasks (will discuss two tasks
today)
ICM-WG Tasks
1. Define terms of identity, credentials etc.
2. Define assurance levels (incl. strength of credentials and context).
3. Explore relationships between classic patient identity management
systems and the security focused identity management systems.
4. Examine threats to credentials, including identity theft, to help provide
the necessary level of assurance.
5. Changing of user attributes, revocation, etc.
6. Obtain input from patient identity experts.
7. List and recommend those areas that are within the scope of work of
the Committee and those that are outside the scope of work.
8. Potential Areas for “Manage Identity Credentials” Construct.
Task 2: Define Assurance Levels
Assurance level criteria as posited by the OMB M-04-04 and NIST Special Publication 800-63
OMB E-Authentication Guidance establishes
four assurance levels for
consistent application of E-Authentication
across gov’t
Level 1
Level 2
Little or no
confidence
in asserted
identity (e.g.
self
identified
user/
password)
Some
confidence
in asserted
identity (e.g.
PIN/
Password)
Level 3
E-RA tool assists agencies
in defining authentication
requirements & mapping
them to the appropriate
assurance level
Level 4
High
Very high
confidence confidence
in asserted
in the
identity (e.g. asserted
digital cert) identity (e.g.
Smart Card)
NIST SP800-63
Electronic
Authentication
technical guidance
matches technology
to each assurance level
Task 2: Define Assurance Levels
Accepted ICM-WG
Recommendations for
Assurance Levels:
1) Adopt NIST Special
Publication 800-63 as the
authoritative standard for
assurance levels.
2) Adopt the Liberty Identity
Assurance Framework as
interoperable identity
management vocabulary.
The Connecticut Health Information Security and Privacy Initiative (HISPI) provided
assurance levels were based upon NIST SP 800-63 mapped to health care risk.
Task 4: Threats to Credentials
Top threats facing Web services (according to WS-I)
No HITSP Specification Coverage
C26 Non-Repudiation (partial coverage
C19 (Entity Identity Assertion, and
TP20 Access Control)
No HITSP Specification Coverage
T17 Secured Communication Channel
T17 Secured Communication Channel
No HITSP Specification Coverage
NIST SP 800-95: Guide to Secure Web Services http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
)
Task 4: Threats to Credentials
OASIS SAML (1)
The Security and Privacy Considerations for the OASIS Security Assertion Markup
Language document outlines the threats faced when using SAML and provides guidance in
securing a SAML based architecture.
http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf
It is important to recognize that once a SAML assertion has been issued, it is not possible to
control its dissemination. An entity that receives a SAML assertion may pass it on to other,
potentially malicious entities as part of the system.
It is possible that a malicious entity may attempt to use SAML assertions in replay attacks
(in particular, authentication assertions and authorization decision assertions are likely to be
replayed). There are a number of techniques that can mitigate this threat, including:
– Encrypting the assertion will prevent a third party from viewing it, although a
malicious entity may attempt to resend the encrypted assertion.
– Signing the entire message rather than the assertion itself, using WS-Security in a
SOAP response or SSL/TLS in a HTTP response. This way, an attacker must
resend the whole message to be successful.
– Enforcing validity periods and ensuring that the issuance of the assertion is
reasonable. This will minimize the amount of time during which an attacker may
successfully execute a replay attack.
Task 4: Threats to Credentials
OASIS SAML (2)
If a SAML authority is publicly accessible, an attacker may send SAML queries to gain
information about the subjects within the system. Similarly, an attacker may construct a
malicious SAML authority.
–In each case, it is especially important that entities using SAML authenticate one another before
requesting or providing information about subjects within the SOA.
Unless implemented correctly, SAML deployments are vulnerable to a number of security
threats associated with stolen and/or forged artifacts.
Appropriately, the E-Authentication Initiative mitigates most threats to SAML by requiring
Transport Level Security (TLS) between Credential Service Providers (CSPs) and
applications. Properly implemented digital signature support would strengthen SAML’s
security in certain scenarios. Robust implementation of audit logs, event
analysis/correlation and other risk mitigation strategies may be even more important.
[Burton]
ICM Requirements/Gaps
Derived identity credential requirements for interoperability/risk
mitigation NOT met by other HITSP SPTC constructs:
Assurance of proper authentication and the binding of individual identity to credentials.
Assurance that the initial identification of individuals is correct by common trusted identity
proofing standards.
Common mechanisms for distributing credential information and changes to verifying entities.
Common interoperable vocabularies for describing individual attributes including credentialing,
roles and other attributes so that relying parties fully understand what is being attested.
Trust by the verifier in the authenticity of the issuing authority.
Assurance of the binding of the patient’s identity to a consent directive.
Assurance that the consent directive authoritatively expresses the patients actual desires
(purpose of use, context, full informed). [See ASTM E1762].
Note: Focus was on requirements for interoperability. Actual management of
identity and assignment of attributes within an enterprise was out of scope.
Relevant Standards
•
•
•
•
•
•
•
•
•
•
NIST SP 800-63, Electronic Authentication Guideline Version 1.0.1, September 2004
NIST SP 800-103, DRAFT An Ontology of Identity Credentials, Part I: Background and Formulation,
Oct 6, 2066
ASTM E2595-07, Standard Guide for Privilege Management Infrastructure, 2007
HITSP C19 Entity Identity Assertion
ISO/IEC 27001:2005, Information technology-Security techniques-Information security
management systems-Requirements, 2005
ISO/IEC 27002 Information technology -- Security techniques -- Code of practice for information
security
ISO/TS 21091:2005, Health Informatics-Directory services for security, communications and
identification
NIST FIPS PUB 201-1, Personal Identity Verification (PIV) of Federal Employees and Contractors,
Mar 2006
OASIS, Security Assertion Markup Language (SAML) v2.0, March 2005
17090-3:2008 Health informatics -- Public key infrastructure -- Part 3: Policy management of
certification authority
Questions?
Thank you!
Stakeholder Experience
1.
2.
3.
4.
5.
6.
Identity proofing (done)
Digital identity management (done)
Encryption (done)
Digital signatures (done)
Delegation of Rights (done)
Author of Record
17
Author of Record (Stakeholder)
1.
Who is the Author
– Contributor
– Responsible party
– Legal owner
2. What are they “signing”
– Specific contribution
– Final “document”
– Assembled set of “documents”
3. Why
– Verify authenticity of the content
– Verify credentials of “author”
– Legal proof of “author”
4. How
– Operationally
– Signature Artifact (characteristics)
18
Issues and Concerns
1.
2.
3.
4.
5.
6.
Identity proofing
Digital identity management
Encryption
Digital signatures
Delegation of Rights
Author of Record
19
Global Issues
1.
2.
3.
4.
5.
6.
7.
Standards
Adoption
Cost
Weaknesses
Multiplicity of solutions
Strength of solution
Value proposition
20
Identity Proofing (Issues)
1. Effort and cost involved in identity proofing
– Number of qualified organizations
– Standards
2. If organizational identity is assigned to an individual, what happens
when the individual leaves or changes role
3. Issues related to scope of Identity proofing for different applications
– Federal
– Commercial
– Direct
4. Other
21
Identity Management (Issues)
1. Issuance and management of digital certificates for large numbers
of individuals and entities
2. Types of certificates (signing, encryption)
3. Acceptance and use of alternatives to digital certificates
4. Revocation
5. Reissue on expiration
6. Certificates tied to specific uses
7. Issues with multiple uses of certificates
8. Format and storage of certificates
9. Access to certificates
10. Access to public certificates (keys)
11. “Trust anchors”
12. System support
* Indicates an item added during the
meeting on 5/16
22
Encryption (Issues)
1.
2.
3.
4.
5.
6.
End points for encryption-decryption
–
“Wire” (e.g. VPN)
–
Organization to Organization
–
System to System
–
Application to Application
–
Individual to Individual
–
Combinations
Standards
What is encrypted
–
Transport
–
Message
–
Payload
–
Artifacts
Purpose (privacy, avoid tampering)
System support
Legacy solutions
* Indicates an item added during the
meeting on 5/16
23
Signing (Issues)
1.
2.
3.
4.
5.
6.
7.
Standards
Adoption
Reliance on digital credentials, “trust anchors”
Signing in a multiparty exchange
Determining what should be signed
Persistence of Signature
System Support
* Indicates an item added during the
meeting on 5/16
24
Delegation of Rights (Stakeholder)
1.
2.
3.
4.
5.
6.
7.
Standard artifacts and constructs
Limitations and adoption of current “standards”
Use of digital Identities
Resistance to fraudulent use
Standards code set for types of assignments
Revocation
System support
* Indicates an item added during the
meeting on 5/16
25
Author of Record (Stakeholder)
1. Levels
1. Aggregation of documents (replace wet signature)
2. Individual documents
3. Individual contribution
2. How does signing work
1. Specific request to sign
2. On contribution
3. On completion
3. Proof of signature (encryption, artifact, …)
4. Persistence of signature (within and across organizations)
26
Summary Assumptions: esMD
 Provider Registration (UC1) and secure transmission of the eMDR
(UC2) requires:
– Cryptographic (or equivalent) verification of all participants
(providers, intermediaries and payers)
– Prevention of tampering
– Encryption of PHI contained in the eMDR
 Author of Record (AoR):
– Requires Cryptographic (or equivalent) verification of the
author/contributor of documentation submitted
– The more granular the AoR requirement, the more potential change
that is needed in EHRs to support/enforce the signing requirements
– The industry is not in a near-term position (12-24 months) to effect
changes in EHR necessary to support AoR at the original
contributor level
27
Summary Assumptions: General
 Other initiatives all require some form of
– Identity proofing
– Certificate (or equivalent) management
– Encryption
– Signing
 Several of the initiatives require
– Delegation of Rights
– Author of Record
 The industry has reasonable solutions for end-to-end encryption of
messages (VPN, TLS, S/MIME…)
 The industry has limited approaches to delegation of rights (SAML may
provide some support)
28
Proposed Scope of Author of Record (AoR) Workgroup
Identity proofing -- in scope
–
Needed for all identity management requirements
Digital identity management – in scope
– Needed for all signing and AoR requirements
Encryption – out of scope or limited scope
–
If limited scope, focus only on encryption of payload (eMDR) ?
Digital signatures – in scope
–
Required for all esMD transactions and AoR
Delegation of Rights – out of scope
–
–
This is an interesting problem – most likely needed, but limited industry solutions
in the near term – may need to create artifact
Eliminate from scope, but address in limited fashion if use case requires
Author of Record – Level 1 in scope for initial phase
–
–
–
Level 1 – replace wet signature on document bundle with digital signature
Level 2 – each document carries a digital signature
Level 3 – all contributions to a record / document carry a digital signature
29
Finally
• Thank you for participating
• All meeting notes will be posted on the AoR Workgroup
Wiki page
• No meeting next week – May 30th
• AoR Workgroup starts on June 6th at 10 am Eastern
30