1. Electronic Submission of Medical Documentation (esMD) Sub-Workgroup October 10, 2012

2. 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

3. Provider Entity Payer Entity esMD Initiative Overview Payer Provider (Individual or Organization) Provider (Individual or Organization) Contractors / Intermediaries Agent Payer Internal System Gateway esMD UC 2: Secure eMDR Transmission esMD UC 1: Provider Registration esMD AoR Level 1 Digital Identities Bundle Signatures Certificate Authority Registration Authority Provider Directories

4. 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

5. 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

6. 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

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

8. AoR Level 1 -- Signature 1)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”

9. 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

10. Public Digital Certificate & Signature Artifact Example 1. Dr. Smith attaches signature artifact to Request to Register to Receive eMDRs Registration Request Provider Name: Dr. Smith NPI: 987654 Service: Receive eMDRs Metadata Encrypted Hash: H8K9QTP Public 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 Request Provider Name: Dr. Smith NPI: 987654 Service: Receive eMDRs Metadata Encrypted Hash: H8K9QTP Public Digital Certificate of Dr. Smith checksum function Hash: 987654 signing algorithm Verify Identity Hash: 987654 Verify Integrity 10

11. 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 Smith NPI: 987654 Service: Receive eMDRs Metadata Encrypted Hash: H8K9QTP Public Digital Certificate of Medical Data, Inc. Delegation of Rights Artifact Public 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/2013 Metadata Encrypted Hash: U37G90P checksum function Hash: 123456 signing algorithm Private Key of Dr. Smith 11

12. 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 Smith NPI: 987654 Service: Receive eMDRs Metadata Encrypted Hash: H8K9QTP Public Digital Certificate of Medical Data, Inc. Delegation of Rights Artifact Public 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/2013 Metadata Encrypted Hash: U37G90P checksum function Hash: 123456 signing algorithm Hash: 123456 Verify Right 12

13. Afternoon SWG Agenda Workflow and options for 1)Identity Proofing 2)Credential Life Cycle Management 3)Authentication 4)Signing Process 5)Delegation of Rights

14. 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 process a)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

15. Identity Proofing – Organization Provider 1)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

16. Digital Credential Life Cycle 1)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

17. 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

18. 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

19. Delegation of Rights Methods for delegation: 1)Proxy certificates a.Advantages 1)Understood form and use 2)Does not require additional delegation artifacts (self contained) 3)Holds information for active date, purpose, … b.Disadvantages 1)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.Advantages 1)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.Disadvantages 1)Revocation process – who and how is it handled 2)May not hold all required information without modification of standard