(updated for esMD on 5-15-2013) electronic submission of Medical Documentation (esMD) HL7 Structured Documents and HL7 Attachments May 5-9, 2013 (updated for esMD on 5-15-2013)

Overview Background esMD Phase 1 – submit document images electronically S&I esMD Initiative Sending a secure eMDR to a provider Replace “wet signature” Move to structured documentation submissions

Improper Payment Medical Documentation Requests are sent by: 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 B in improper payments (3-year rolling error rate: 8.1%). Most improper payments can only be detected by a human comparing a claim to 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 over 1.5 million requests for medical documentation each year. Claim review contractors currently receive most medical documentation in paper form or via fax. 1. Medicare and Medicaid issue billions of dollars in improper payments every year. These are not fraudulent situations, but rather cases where the health care provider unintentionally fails to comply with the Medicare and Medicaid coverage, coding on Medicare and Medicaid coverage, coding the medical recasting(?) rules. 2. CMS hires Review Contractors to help find improper payments. Nurses and other clinicians at the review contractors look for these improper payments by comparing the claim to the medical documentation created by the provider of the time of service. 3. Hospitals, Physician Offices and other providers receive many requests for patient’s medical records every year from Medicare and Medicaid Review Contractors.

esMD Background Phase 1: Phase 2: Before esMD: Provider electronic 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. Review Contractor Provider Request Letter Paper Medical Record Phase 1: Doc’n Request Letter electronic Phase I of esMD was implemented in September of 2011. It enabled Providers to send Medical Documentation electronically The ONC S&I Framework Electronic Submission of Medical Documentation (esMD) initiative is developing solutions to support an entirely electronic documentation request. electronic Phase 2:

Goals of esMD 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

CMS esMD Utilizes eHealthExchange Medicare Administrative Contractors Medicare Recovery Auditors PERM CERT Structured Electronic Requests for Medical Documentation PDF PDF xml PDF CONNECT Compatible CMS Private Network Content Transport Services ECM CONNECT Compatible

Transport Standards CONNECT DIRECT X12 Core

Medicare Private Network Electronic Submission of Medical Documentation (esMD) Supporting Multiple Transport Standards and Provider Directory RACs ZPICs CERT PERM MACs Practice Management Systems and Claims Clearinghouse EDI – X12 Compatible Medicare Private Network EHR / HISP Direct Compatible EDI Translator Content Transport Services Direct ECM Internal PD HIH CONNECT Compatible Baltimore Data Center Federated External PD

esMD eMDR Process Flow The overall esMD eMDR process can be divided into three steps: A provider registers with a payer to receive electronic medical documentation requests (eMDRs) -- must have valid S&I Use Case 2 compliant directory entry with ESI supporting end point for eMDR profile 1. Register to Receive eMDRs A payer sends an eMDR to a registered provider’s current ESI obtained from designated PD 2. Send eMDRs A provider electronically sends medical documentation to a payer in response to an eMDR 3. Send Medical Documentation esMD Phase 2 esMD Phase 1

S&I Framework esMD eMDR Overview Provider Entity Payer Entity Payer 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 User Story All Actors obtain and maintain a non-repudiation digital identity Provider registers for esMD (see UC1) Payer requests documentation (see UC2) Provider submits digitally signed document (bundle) to address request by payer Payer validates the digital credentials, signature artifacts and, where appropriate, delegation of rights

AoR -- Phased Scope of Work Level 1 – Current Focus Digital signature on aggregated documents (bundle) 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 Level 2 - TBD Digital signature on an individual document 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 Level 3 - TBD Digital signature to allow traceability of individual contributions to a document 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

3. Signing and Delegation Sub-Workgroups 1. Identity Proofing Define required process for identity proofing of healthcare individuals and organizations for esMD Proof of identity requirements Allowed proofing processes 2. Digital Credentials Define required process for issuing and managing digital credentials for esMD Credential Life Cycle (issuance, maintenance and revocation) Credential uses (Identity, Signing, Proxy, Encryption, Data Integrity) Specific use credentials (e.g. Direct) 3. Signing and Delegation Define process, artifacts and standards for transaction and document bundle digital signatures and delegation of rights for esMD Signature and Delegation artifacts Workflow issues Delegation process Statement of problem and assumptions Review of Standards Recommended standards Operational/Implementation Considerations Analysis of Gaps in standards and policy Deliverables from all SWGs include:

Electronic Determination of Coverage (eDoC) Underlying Challenge: Enable provider capture of documentation and benefit determination based on payer rules Secure exchange of templates, decision support, and documentation between payers, providers, service suppliers and beneficiary Scope: Focus on defining the use case, user stories and requirements supporting a standards-based architecture Reuse of existing S&I Initiative efforts where possible Creation of structured data capture templates and supporting exchange standards Power Mobility Device as initial Use Case Outcome: Successful pilot of templates, decision support, information exchange standards over standard secure transactions for the purpose of determining coverage Validation with initial use case for Power Mobility Device 13

eDoC General Workflow Patient LCMP Physician Specialist / Service Provider Templates and Rules Payer 14

Related S&I Framework Initiatives Description Relationship Transitions of Care (C-CDA) Defines the electronic communication and data elements for clinical information exchange to support transfers of care between providers and between providers and patients Standards for the exchange of clinical information Provider Directories Defines transaction requirements and core data sets needed to support queries to provider directories to enable electronic health information exchange Electronic endpoints for participants in eDoC Structured Data Capture External template driven capture of structured data within the EHR Templates and workflow to capture payer required information Health eDecisions Decision Support to enable complex workflows based on externally provided rules that enable capture of information and provide guidance for physician ordering Decision support for data capture and preferred order management esMD Author of Record Standards for providing digital signatures to transactions and documentation. Standards for Digital Signatures on transaction and documents Longitudinal Coordination of Care Defines the electronic communication and data elements for clinical information exchange to support transfers of care between hospital or office based care and long term care or home based care C-CDA Standards for the documentation of patient condition and plans of care Direct a simple, secure, scalable, standards-based way for participants to send authenticated, encrypted health information Utilize Direct as a transport mechanism between providers, payers and suppliers ABBI provide consumers with automated updates to their health information in a human readable and machine readable format Provide determination of coverage decision to the beneficiary 15

eDoC Workgroup Structure Charter Use Case Harmonization Pilots Sub-Workgroups Structured Data Determine documentation requirements Evaluate appropriate clinical elements Clinical Vocabularies Define CCDA template Documentation Templates Define template requirements Define template workflow Define EHR data capture requirements Specify storage requirements Decision Support Define rules to guide documentation Define rules to present covered alternatives Determine workflow issues Consolidated CDA Structured Data Capture Health eDecision 16

Candidate Standards for eDoC “Attachments” Consolidated CDA (structured and unstructured body) Author of Record Digital Signatures for provenance Structured Data Capture for provider guidance and collection of additional Clinical Data Elements 17

Digital signature on bundle of documents Author of Record Level 1 Digital signature on bundle of documents Standards PKI: X.509v3 Signing Certificates (FBCA Medium) IHE DSG (XAdES) SAML Assertion for delegation of rights Environment Created as part of sending documents from provider to payer Validated upon receipt One signer (submitter) only for the full bundle of documents Delegation of rights as required to support authorization chain 18

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

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 20

The “A”rchitecture of the CDA CDA Document Header Structured Body Section Text Entry Section Text Entry 21

CDA Document Header Unstructured Body e.g. PDF 22

Approach Calculate digest over MSH and body with the exception of MSH – Authenticator and Legal Authenticator Any section used for the digital signature Three options for the signature Add to MSH (need to validate that this will work with all components) Add new digital signature section in standard name space Add new digital signature section in an alternate name space 23

The “A”rchitecture of the CDA CDA Document Digital Signatures Header Structured Body Section Text Entry Digital Signature Section Text Entry Alt Name Space -- Digital Signature Section Text Entry 24

Alt Name Space -- Digital Signature Section CDA Document Digital Signatures Header Unstructured Body e.g. PDF Alt Name Space -- Digital Signature Section Text Entry 25

Pros and Cons Header New Section New name space Yes Requires changes Works with Structured Yes Works with Unstructured Requires changes Pros Appears to be a CDA “standard” Can do anything with Structured Data – can provide text to show signatures Can do anything Cons May not include OCSP or Delegation Use with unstructured body Will not be recognized by standard CDA viewers (no “document is digitally signed by”) 26

HL7 September Ballot Cycle Project Scope Statement for Digital Signature in C-CDA accepted Primary Sponsor Work Group – Structured Documents Co-sponsor Work Group – Security and Attachments For September 2013 May 19 – Project Scope July 7 – Notification of Intent to Ballot July 14 – Initial content due July 21 – Preview content due July 28 – Reconciliation, Complete and Supporting Content August 4 – Final Content Deadline August 12 – Provisional Ballot Opening Note: updated on 5/17 at 1pm 27

The “A”rchitecture of the CDA CDA Document Header Body Section Text Entry 28

Consolidation C-CDA 9 Clinical Documents 60 Document Sections 66 Clinical Statements ~2100 Conformance Clauses 1 PDF Document 1 CDA R2 ~110 Sections ~200 Clinical Statements 3000+ Conformance Clauses 17 PDF Documents 29

C-CDA Document Templates Continuity of Care Document 1.1 History and Physical Consult Note Discharge Summary Diagnostic Imaging Report Procedure Note Operative Note Progress Note Unstructured Document 30

CCDA Issues What does the provider “sign” prior to billing? Based on current regulations cannot create something after they bill Must persist for at least the entire possible billing/challenge cycle Does this vary by payer and service? Consider the different venues of care Hospital Ambulatory Consultant Home Health Limited number of section are required for any of the “Document Templates Discharge and Consult may be ok No good template for ambulatory (sign multiple, still issues) New template for complete encounter? (ambulatory only?) 31

“C-CDA” for eDoC C-CDA used as is C-CDA Complete Encounter Document Template with SDC section C-CDA Variable Document Template with SDC section 32

Consolidated-CDA as is Use current version of C-CDA as the “container” for any and all medical and administrative observations that must be conveyed to CMS Two approaches Provider selects appropriate CDA Template and creates the CDA Payer specifies the appropriate CDA Template(s) for documentation User Story specific Any guidance regarding a specific user story only informs the provider to ensure that the information is complete for the section Pros No new standards work required for eDoC Cons Limited ability to support unique requirements (e.g. seven element order) Requires additional development effort to support inclusion of any item not part of the C-CDA templates (including optional sections and entries) Select Template (1 of 9) Template Required Sections (0-n of 60) Template Optional Sections (0-m of 60) Required Entries Optional Entries Sections and entries are all defined based on the nine “standard” CCDA templates 33

C-CDA Complete Encounter Define new Complete – CDA Template for any and all medical and administrative observations that must be conveyed to the payer for determination of coverage Complete CDA Define new Template with all sections and elements Required (SHALL or SHOULD) for the current encounter Defines section for SDC inclusion User Story specific Guidance regarding a specific user story can inform the provider to ensure that the information is complete for the section or Payer specific SDC template can assist the provider in ensuring that the documentation is complete Pros Only one format and template for eDoC documentation Cons New Template for C-CDA New SDC section May receive more documentation than is required to support the specific determination of coverage Select Template (Complete) Required Sections (60) (all are RE) Required Entries (66) (all are RE) Structured Data Capture Section All SDC clinical data elements associated with the encounter 34

Complete C-CDA

36

37

C-CDA support for Structured Data Capture Structured Data Capture for provider guidance and collection of additional Clinical Data Elements SDC Templates EHR defined Clinical Entry Templates and Forms EHR SDC EHR Database (discrete elements) C-CDA Document Type Required/Optional Required/Optional Entries Structured Data Capture Section All SDC clinical data elements associated with the encounter External SDC template library 38

C-CDA Variable Document Define new eDoC CDA (dynamic document templates) that permit provider to “select” only sections and documents required for a specific determination of coverage eDoC CDA Define new dynamic Document Template with all sections and elements optional and inclusion is driven by specific payer template for the specific user story Defines section for SDC inclusion User Story specific Specific payer template selects only sections /elements (?) required for the user story Guidance regarding a specific user story can inform the provider to ensure that the information is complete for the section or Payer specific SDC template can assist the provider in ensuring that the documentation is complete Pros Very specific selection of documentation required for a specific user story Cons New variable template – nothing like it today Structure to communicate and select based on coverage determination – this will need very specific work for SDOs, vendors, and payers All onus is on payer to determine what is “required” New SDC section Specific payer requirement Payer Required Sections (1-60) Payer Optional Sections (0-59) Payer Required Entries Payer Optional Entries Structured Data Capture Section All SDC clinical data elements associated with the encounter Entire “Template” is defined by payer for a specific user story 39

Orders We have a need to document and sign orders placed by a provider What is the best way to do this? The plan section appears to deal only with future orders There is no real orders section that we see -- 40