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 payer

5) Payer validates the digital credentials, signature artifacts and, where appropriate, delegation of rights

Provider Registration

1) 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 payer

4) Payer validates identity of all sending parties, delegation of rights and integrity of registration transaction

5) Payer processes transaction

6) Payer creates response and signs payload using its signing certificate

7) Registration Entity receives payer registration response, validates sending party and integrity of payload

8) Registration Entity takes appropriate action based on response

Secure eMDR Transaction

1) Payer creates eMDR and signs the payload using its signing certificate– Optional:

• Payer encrypts payload (PHI) with public key of intended recipient prior to signing

2) 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 certificate

5) Payer receives response, validates sending party and integrity of payload

6) 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 transaction

5) Payer creates response to transaction from (3) and signs payload using its signing certificate

6) Responding Entity receives payer eMDR submission response (5) validates sending party and integrity of payload

7) 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 dates

b) Can it be used for this purpose: intended use

c) Do we trust the certificate issuer : Chain to CA root certificate or Federal common policy CA

d) Do we trust the user: identity of holder

e) Has it been revoked: revocation list

2) Verify any assignment of rights

3) Compute hash of signed payload

4) Decrypt signed hash with public key

5) Verify that signed hash matches computed hash of signed payload

6) 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 Proofing

2) Credential Life Cycle Management

3) Authentication

4) Signing Process

5) Delegation of Rights

Identity Proofing – Individual Provider

1) Individual provider fills our application for Identity Proofing

2) Individual provider assembles required documents and picture IDs

3) Verification of identity process as part of:

a) CA/RA current level 4 defined process

b) Provider organization in-person verification processa) Credentialing (e.g. for delivery of services in a hospital)

b) HR process

c) 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 information

6) 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 record

8) Issues Proof of Identity to CA

Identity Proofing – Organization Provider1) Authorized representative fills our application for Identity Proofing

2) Authorized representative assembles required documents

a. Papers of incorporation

b. State license

c. Federal tax ID

d. 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 licensing

b) Payer review

c) 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 information

6) Verification of NPI or other Payer Identification

7) Issues verification to address of record

8) Issues Proof of Identity to CA

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

Individual or Organization

2) Purpose of digital credentials:

a. Signing

b. Encryption

c. Authorization

d. Direct

e. Other (e.g. ordering controlled substances)

3) Form factor

a) Software token (installed in server)

b) Hard token (ID card, USB token)

4) Reissue

a) Lost/compromised credentials

b) Renewal on expiration

5) Revocation Process

a) If identity is revoked then need to update accessible revocation list

Credential Process

1) Verify Identity Proofing

2) Issues appropriate credentials with some form of out-of-band notification

3) Install credentials in appropriate system (unless hard token)

4) Establish authorization process to access software token

5) Maintain security of token during its lifecycle

6) Renewal process on expiration

Authentication

Purpose of Authentication:

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

Methods:

1. Two factor to access the software token:a) Password

b) One time key

c) Hard token

d) biometric.• Do you need to access software token once per session or with each

use

Delegation of Rights

Methods for delegation:

1) Proxy certificates

a. Advantages1) Understood form and use

2) 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 certificate

2) Requires the delegation activity to be done with the specific proxy certificate

3) Revocation process – who and how is it handled

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

a. Advantages1) Understood form and use

2) Requires use of artifact (eg. SAML to convey delegation)

3) Easy to use (sign with own certificate and provide assertion as proof of right

4) Uses certificate verification to ensure identity of grantor and grantee

b. Disadvantages1) Revocation process – who and how is it handled

2) May not hold all required information without modification of standard