Additional Attachment Templates Presented to the Attachments Workgroup

1. Additional Attachment TemplatesPresented to the Attachments Workgroup December 10, 2013

2. Improper Payment • Medicare receives 4.8 M claims per day. • CMS’ Office of Financial Management estimates that each year • the Medicare FFS program issues more than$28.8 B in improper payments (error rate 2011: 8.6%). • the Medicaid FFS program issues more than $21.9 Bin improper payments (3-year rolling error rate: 8.1%). • Most improper payments can only be detected by ahumancomparing aclaimto the medical documentation. www.paymentaccuracy.gov • Medical Documentation Requests are sent by: • Medicare Administrative Contractors (MACs) Medical Review (MR) Departments • Comprehensive Error Rate Testing Contractor (CERT) • Payment Error Rate Measurement Contractor (PERM) • Medicare Recovery Auditors (formerly called RACs) • Claim review contractors issue over1.8 million requests formedical documentation each year. • Claim review contractors currently receive most medical documentation inpaperform or via fax.

3. esMD Background Healthcare payers frequently request that providers submit additional medical documentation to support a specific claim(s). Until recently, this has been an entirely paper process and has proven to be burdensome due to the time, resources, and cost to support a paper system. Before esMD: Review Contractor Request Letter Phase I of esMD was implemented in September of 2011. It enabled Providers to send Medical Documentation electronically Phase 1: Doc’n Request Letter electronic Phase 2: electronic Paper Medical Record The ONC S&I Framework Electronic Submission of Medical Documentation (esMD) initiative is developing solutions to support an entirely electronic documentation request. Provider electronic

4. esMD • Goals • Reduce administrative burden • Reduce improper payment • Move from “post payment audit” to prior-authorization or pre-payment review • Requirements • Move from paper to electronic communication • Replace “wet signatures” with digital signatures • Migrate to structured data from unstructured data 4

5. S&I Framework esMD Overview Registration Authority Certificate Authority Provider Directories Provider Entity Payer Entity Contractors / Intermediaries esMD UC 1: Provider Registration Includes Digital Signature Agent esMD UC 2: Secure eMDR Transmission Includes Digital Signature Provider (Individual or Organization) Payer esMD AoR Level 1 Digital Signature on Bundle Payer Internal System esMD AoR Level 2 Digital Signature on Document(s)

6. Wet Signatures • Standards and legal standing • Standards are based on legal precedence • Non-repudiation inherent in wet signature • Audit requirement • None • Often requires an attestation to determine validity • Timing of Signature • Applied at any time (timing policy cannot be enforced) • Fraud protection • none • Short of forensic evaluation of original signed document unable to determine when signing occurred

7. Electronic Signatures • Standards and legal standing • Standards are based on technology and legal precedence • Currently there are no technically mature techniques that provide the security service of nonrepudiation in an open network environment, in the absence of trusted third parties, other than digital signature-based techniques.(HHS) • Audit requirement • Require audit of signing system (e.g. EMR) installation, policies, and audit logs • May require an attestation to determine validity • Timing of Signature • Record of time of signing • Can be applied at any time – timing determined by EHR • Fraud protection • None/Limited – all required a physical audit and attestations

8. Digital Signatures • Standards and legal standing • International and US Federal standards • Standards based on cryptography • Audit requirement • Audit required as part of identity proofing and certificate issuance • Timing of Signature • Time stamp on document is evidence of when signing occurred • OCSP response is external evidence of timing and certificate validity • Signature when document is complete • Fraud protection • Absolute – assuming that PKI policies are followed

9. Author of Record Level 2 Requirements • Digital signature on documents for provenance (clinical and administrative) • Meets requirement for encapsulated non-repudiation • Note: electronic signature requires validation of system configuration and audit log review • Signature should be applied at time of document creation, modification, review (Administrative – must be applied prior to claim submission) • Multiple signatures on same “document” • Certificate must be validated at time it is used (OCSP or CRL) • Support for validated delegation of rights assertion • Signature and delegation of rights must travel with document • Signature bound to signed document for life-time of document • Supports transition from unsigned to signed documents over time • Example: Multiple signatures in a pdf document (decoupled from transport) 9

10. Provider with Signed Documents Document with embedded signature and delegation Accepted and stored by all regardless of AoR support Document Delegation Signature Signature and delegation only accepted by systems with AoR support May drop only signature and delegation or error on entire transaction 10

11. Signature on CDA Solution: Add “signatureText” attribute to Participation occurrences for legalAuthenticator and authenticator in the CDA Header to hold Digital Signature and Delegations of Rights Assertion artifacts -- exclude these Participation occurrences from the calculated digest CDA Document Section Text Entry Entry Entry Entry Authenticators and Digital Signatures Header Structured Body Structured Body Section Text Entry Entry Entry Entry CDA Document Unstructured Body Authenticators and Digital Signatures Header Unstructured Body e.g. PDF 11

12. Implication of Digital Signatures • Once signed, the content may not be altered without voiding the Digital Signatures • Digital Signatures will not work on anything where the structure will be altered • Must address individual contributions – do this through author participation, role and signature purpose

13. Today – Typical Response to CMS request for Documentation Documentation collected via EHR forms and templates and stored in the EHR Database Lab Orders/Results History of Present Illness Vital Signs EHR Forms/Templates Allergies Medications History and Physical Vital signs Visit Summary Orders / Treatment Textual reports CDA Document Authenticators and Digital Signatures Header esMD Phase 1 Unstructured Body PDF EHR Database PDF Demographics EHR generates PDF of all encounter information (typically) 13

14. Current Templates Use of Current Templates Create Structured CDA 1) Works for all sections and entry templates defined as SHALL or, depending on the certification requirements, SHOULD 2) Sections and entry templates defined as MAY are supported to various degrees, or not at all, by each EHR vendor 3) How does the provider meet documentation requirements? 4) Recipient of the document does not know if data does not exist, data is being withheld, or the implementation does not support the section/entry CDA Document Authenticators and Digital Signatures Header Structured Body Lab Orders/Results History of Present Illness Section Section Section Section Text Text Text Text Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Vital Signs EHR Forms/Templates Allergies Medications History and Physical Vital signs Visit Summary Orders / Treatment Textual reports EHR Database Demographics 14

15. Sign CDA Notes: Signer may authenticate and then review/sign multiple documents at one session Authentication via acceptable two factors -- something you know, something you hold, something you are (e.g. biometric), etc. CDA typically contains a subset of the encounter information Universal Time Long term validation CDA Document Header Authenticate Signing “Module” Structured Body Lab Orders/Results History of Present Illness Section Section Section Section Text Text Text Text Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Write Signature Digest Vital Signs EHR Forms/Templates Allergies Medications Authenticators and Digital Signatures History and Physical Vital signs Visit Summary Orders / Treatment Textual reports EHR Database Demographics Not in CDA 15

16. Create Complete CDA Prior to or at time of signing – create CDA from Complete Document Template CDA Document Create Structured CDA from Complete Document Template All Document sections and constrained entries are populated or use appropriate nullFlavor Ensures that all captured documentation is in the CDA prior to signing Authenticators and Digital Signatures Header Structured Body Lab Orders/Results History of Present Illness Section Section Section Section Text Text Text Text Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Vital Signs EHR Forms/Templates Allergies Medications History and Physical Vital signs Visit Summary Orders / Treatment Textual reports EHR Database Demographics 16

17. Sign CDA Notes: Signer may authenticate and then review/sign multiple documents at one session Authentication via acceptable two factors -- something you know, something you hold, something you are (e.g. biometric), etc. Universal Time Long term validation CDA Document Header Authenticate Signing “Module” Structured Body Lab Orders/Results History of Present Illness Section Section Section Section Text Text Text Text Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Write Signature Digest Vital Signs EHR Forms/Templates Allergies Medications Authenticators and Digital Signatures History and Physical Vital signs Visit Summary Orders / Treatment Textual reports EHR Database Demographics 17

18. Provider Setup for Digital Signatures • Individual provider supplies IDs and other information as part of credentialing or to a standalone Registration Authority (RA) • RA verifies credentials • Certificate Authority (CA) receives providers information from the RA • CA issues access information (e.g. hard token) to the individual provider • CA issues encrypted key to the signing application key store 1) Registration Authority 2) 3) 4) Certificate Authority 5) Provider Signing Application

19. Signing Process CDA Document • C-CDA created for activity to be signed (system or on demand) • Signer views list of documents (C-CDAs) to be signed • Signer reviews documents and indicates ready for signature and where appropriate role and signature purpose (will most likely be defaulted based on signer) • Signer authenticates to Signing Application • Signer signs list of all reviewed and accepted documents Digital Signatures Header Structured Body Lab Orders/Results History of Present Illness Section Section Section Section Text Text Text Text Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry Entry 1) Vital Signs EHR Forms/Templates Allergies Patient Visit Date Document Role Purpose Rev Ready James, Sandy 8/15/2013 Complete CDA MD Legal Authenticator Stanford, John 8/14/2013 Procedure CDA MD Legal Authenticator Stanford, John 8/15/2013 Complete CDA MD Co-Signer Medications X X History and Physical Vital signs Visit Summary Orders / Treatment Textual reports ... X X X Sign selected documents 5) 2) 3) Provider Signing Application 5) EHR Database Demographics 4)

20. New Templates • Documents • Complete Encounter Document (office visit, consult, home health) • Complete Hospitalization Document (hospital admit and discharge) • Complete Operative Note Document (operative note) • Complete Procedure Document (procedure note) • Time Boxed Document (shift, day, period) (for acute / long term care) • Sections • Additional Documentation Section (documents that do not have a place in the existing sections) • Externally Defined CDE Section (data collection using externally defined templates that produce name value pairs defined by external standards (NLM ...)) • Orders Placed Section (orders that are instantiated (moodCode RQO)) • Transportation Section (provider copy of transportation documentation)

21. Notes – Medicare NCD/LCD • Provider is not required to use a specific document template or even use a CDA at this time • Attachments rule may change this to require a CDA document • Provider is responsible for submitting all documentation required to justify that the services is medically necessary and appropriate • Signatures must be applied prior to billing -- based on policy • We are: • Not changing the content or use of the existing templates in CCDA R1.1 or R2 • Not requiring new data collection by provider – they should be documenting based on medical best practice (embodied in NCD/LCDs) • Creating templates that ensure that the CDA signed by a provider contains everything documented in the encounter. Provider can withhold information if provider deems appropriate and technology supports. • Creating Additional Attachment Templates that meet Medicare requirements and can be used by other payers or providers as they deem appropriate.