electronic submission of medical documentation (esmd) sub-workgroup october 10, 2012
TRANSCRIPT
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