Electronic Submission of Medical Documentation (esMD)

Sub-Workgroup

October 10, 2012

• esMD overall workflow• Provider registration• Secure transmission of electronic medical documentation requests• Author of Record Level 1 – bundle signatures• Verification • Examples of Digital Signatures and Delegation of Rights• Identity Proofing• Digital Credential Life Cycle

Agenda

Provider EntityPayer Entity

esMD Initiative Overview

PayerProvider

(Individual or Organization)

Contractors / Intermediaries Agent

Payer Internal System

Gat

eway

esMD UC 2: Secure eMDR Transmission

esMD UC 1: Provider Registration

esMD AoR Level 1Digital Identities Bundle Signatures

Certificate Authority

Registration Authority

Provider Directories

esMD Workflow

1) Provider, payers and intermediaries obtain and maintain a non-repudiation digital identity

2) Provider registers for esMD (see UC1)*3) Payer requests documentation (see UC2)*4) Provider submits digitally signed document (bundle) to address

request by payer5) Payer validates the digital credentials, signature artifacts and,

where appropriate, delegation of rights

Provider Registration1) Provider is authenticated

– Optional:• Provider delegates right to another entity to register for esMD• Registration Entity (Provider / Provider Agent / HIH) is authenticated

2) Registration Entity creates registration transaction and signs the payload using its signing certificate– Optional:

• Transaction entity adds delegation of rights artifact(s) to establish unbroken chain to provider that is the subject of the registration

3) Registration Entity sends send transaction to payer4) Payer validates identity of all sending parties, delegation of rights and integrity of

registration transaction5) Payer processes transaction6) Payer creates response and signs payload using its signing certificate7) Registration Entity receives payer registration response, validates sending party and

integrity of payload8) Registration Entity takes appropriate action based on response

Secure eMDR Transaction1) Payer creates eMDR and signs the payload using its signing certificate

– Optional:• Payer encrypts payload (PHI) with public key of intended recipient prior to

signing2) Payer creates transaction and send it to the address in the Provider

Directory ESI (Receiving Entity)3) Receiving Entity validates identity of payer, and integrity of eMDR payload

– Optional• Receiving Entity uses private key to decrypt payload (PHI)• Question -- Is the payload encrypted using the public key of the Receiving

Entity or the Provider?4) Receiving Entity creates response and signs payload using its signing

certificate5) Payer receives response, validates sending party and integrity of payload6) Payer takes appropriate action based on response

AoR -- Phased Scope of Work

7

Level 1 – Current Focus

Level 2 - TBD

Level 3 - TBD

Digital signature on aggregated documents

(bundle)

Digital signature to allow traceability of individual

contributions to a document

Digital signature on an individual document

• Focus is on signing a bundle of documents prior to transmission to satisfy an eMDR

• Define requirements for esMD UC 1 and UC 2 Signature Artifacts• May assist with EHR Certification criteria in the future

• Focus is on signing an individual document prior to sending or at the point of creation by providers

• Will inform EHR Certification criteria for signatures on patient documentation

• Focus is on signing documents and individual contributions at the point of creation by providers

• Will inform EHR Certification criteria for one or multiple signatures on patient documentation

AoR Level 1 -- Signature1) Provider is authenticated

– Optional:• Provider delegates right to another Signing Entity to sign responses to eMDR• Signing Entity is authenticated

2) Signing Entity creates document bundle and signs the payload using its signing certificate– Optional:

• If the Signing Entity is not the provider then the Signing Entity adds delegation of rights artifact(s) to establish unbroken chain to provider that is the subject of the eMDR

• If the Signing Entity is not the Responding Entity then the Signing Entity sends signed bundle and any delegation of rights artifacts to the Responding Entity (Do we need a delegation of rights from the Signing Entity to the Responding Entity if they are not the same – CMS does not appear to have a requirement other than an auditable trail)

3) Responding Entity (e.g. HIH) creates and sends the response to the eMDR to payer Payer validates identity of all sending parties, delegation of rights and integrity of document payload

4) Payer processes transaction5) Payer creates response to transaction from (3) and signs payload using its signing certificate6) Responding Entity receives payer eMDR submission response (5) validates sending party and integrity of payload7) Responding Entity takes appropriate action based on response

Discussion regarding encryption of payload by the Signing Entity – create graphic of this process for review next week

Propose other wording for “response”

Validation (assuming X.509 signing certificate)Recipient of transaction performs the following steps:1) Validate the X.509 Digital Certificate(s) by verify the following:

a) Is it current : inspect both notBefore and notAfter datesb) Can it be used for this purpose: intended usec) Do we trust the certificate issuer : Chain to CA root certificate or

Federal common policy CAd) Do we trust the user: identity of holdere) Has it been revoked: revocation list

2) Verify any assignment of rights 3) Compute hash of signed payload4) Decrypt signed hash with public key5) Verify that signed hash matches computed hash of signed payload6) If necessary, decrypt payload using recipients private key

Public Digital Certificate &Signature Artifact Example

1. Dr. Smith attaches signature artifact to Request to Register to Receive eMDRs

Registration RequestProvider Name: Dr. SmithNPI: 987654Service: Receive eMDRs

MetadataEncrypted Hash: H8K9QTPPublic Digital Certificate of Dr. Smith

checksum function

Hash: 987654 signing algorithm

Private Key of Dr. Smith

2. Payer verifies the Request came from Dr. Smith and has not been tampered with

Public Key of Dr. Smith

Registration RequestProvider Name: Dr. SmithNPI: 987654Service: Receive eMDRs

MetadataEncrypted Hash: H8K9QTPPublic Digital Certificate of Dr. Smith

checksum function

Hash: 987654

signing algorithm

Verify Identity

Hash: 987654Verify Integrity

10

Public Digital Certificate & Delegation of Rights Example (1/2)

1. Dr. Smith delegates the right to register his NPI to receive eMDRs to Medical Data, Inc.

Registration Request

Provider Name: Dr. Bob SmithNPI: 987654Service: Receive eMDRs

MetadataEncrypted Hash: H8K9QTPPublic Digital Certificate of Medical Data, Inc.Delegation of Rights ArtifactPublic Digital Certificate of Dr. Smith

2. Medical Data, Inc. includes their Signature Artifact, Dr. Smith’s Delegation of Rights Artifact, and both Public Digital Certificates in their Request to Register Dr. Smith to Receive eMDRs

Assertion of Rights

Dr. Bob Smith gives Medical Data, Inc. the right to register his NPI to receive eMDRs.Expiration Date: 1/1/2013MetadataEncrypted Hash: U37G90P

checksum function Hash: 123456 signing algorithm

Private Key of Dr. Smith

11

Public Digital Certificate & Delegation of Rights Example (2/2)

3. Payer verifies Medical Data, Inc. has the right to register Dr. Smith to receive eMDRs

Registration Request

Provider Name: Dr. Bob SmithNPI: 987654Service: Receive eMDRs

MetadataEncrypted Hash: H8K9QTPPublic Digital Certificate of Medical Data, Inc.Delegation of Rights ArtifactPublic Digital Certificate of Dr. Smith

Public Key of Dr. Smith

Assertion of Rights

Dr. Bob Smith gives Medical Data, Inc. the right to register his NPI to receive eMDRs.Expiration Date: 1/1/2013MetadataEncrypted Hash: U37G90P

checksum function Hash: 123456

signing algorithm Hash: 123456

Verify Right

12

Afternoon SWG Agenda

Workflow and options for 1) Identity Proofing2) Credential Life Cycle Management3) Authentication4) Signing Process5) Delegation of Rights

Identity Proofing – Individual Provider1) Individual provider fills our application for Identity Proofing2) Individual provider assembles required documents and picture IDs3) Verification of identity process as part of:

a) CA/RA current level 4 defined processb) Provider organization in-person verification process

a) Credentialing (e.g. for delivery of services in a hospital)b) HR processc) License process (State, DEA, other)d) FDA process e) Private Companies such as DAON

c) Public Notary (?)4) Records documents and biometric (picture / fingerprint)5) Validates documents to primary source and verifies and compares demographic information6) Verification of NPI or other Payer Identification (e.g verify address associated with NPI or

other Payer Identification) (Note: demographics / address must be maintained/updated prior to identity proofing as part of this process)

7) Issues confirmation to address of record8) Issues Proof of Identity to CA

Identity Proofing – Organization Provider1) Authorized representative fills our application for Identity Proofing2) Authorized representative assembles required documents

a. Papers of incorporationb. State licensec. Federal tax IDd. Motion by board of directors for representative to act on organizations behalf

3) Authorized representative with prior identity proofing and digital credentials submits documents and personal ID as part of identity process:

a) State licensingb) Payer reviewc) Accreditation by recognized organization (e.g. The Joint Commissions)d) Public Notary (?)

4) Records documents and biometric of representative (picture / fingerprint)5) Validates document to primary source and verifies and compares demographic information6) Verification of NPI or other Payer Identification7) Issues verification to address of record8) Issues Proof of Identity to CA

Digital Credential Life Cycle1) Based on acceptable Identity Proofing, CA issues requested digital credentials to

Individual or Organization2) Purpose of digital credentials:

a. Signingb. Encryptionc. Authorizationd. Directe. Other (e.g. ordering controlled substances)

3) Form factora) Software token (installed in server)b) Hard token (ID card, USB token)

4) Reissuea) Lost/compromised credentialsb) Renewal on expiration

5) Revocation Processa) If identity is revoked then need to update accessible revocation list

Credential Process

1) Verify Identity Proofing2) Issues appropriate credentials with some form of out-of-band

notification3) Install credentials in appropriate system (unless hard token)4) Establish authorization process to access software token5) Maintain security of token during its lifecycle6) Renewal process on expiration

AuthenticationPurpose of Authentication:

To access / use signing certificate to digitally sign documents, actions, transactions.

Methods:1. Two factor to access the software token:

a) Passwordb) One time keyc) Hard tokend) biometric.• Do you need to access software token once per session or with each

use

Delegation of RightsMethods for delegation:1) Proxy certificates

a. Advantages1) Understood form and use2) Does not require additional delegation artifacts (self contained)3) Holds information for active date, purpose, …

b. Disadvantages1) No general support for trust chain from proxy certificates to antecedent proxy certificate or end-user

certificate2) Requires the delegation activity to be done with the specific proxy certificate3) Revocation process – who and how is it handled

2) Delegation of Rights Artifacts (e.g SAML)a. Advantages

1) Understood form and use2) Requires use of artifact (eg. SAML to convey delegation)3) Easy to use (sign with own certificate and provide assertion as proof of right4) Uses certificate verification to ensure identity of grantor and grantee

b. Disadvantages1) Revocation process – who and how is it handled2) May not hold all required information without modification of standard