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

electronic submission of Medical Documentation (esMD)

HL7 Structured Documentsand

HL7 Attachments

May 5-9, 2013 (updated for esMD on 5-15-2013)

1. Background

2. esMD Phase 1 – submit document images electronically

3. S&I esMD Initiative

a) Sending a secure eMDR to a provider

b) Replace “wet signature”

c) Move to structured documentation submissions

Overview

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 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 formedical documentation each year.

Claim review contractors currently receive most medical documentation in paper form or via fax.

esMD Background

Phase I of esMD was implemented in September of 2011. It enabled Providers to send Medical Documentation electronically

4

Review Contractor

Provider

Request Letter

Paper Medical Record

Phase 1: Doc’n

Request Letter

electronic

electronic

electronicPhase 2:

Before esMD: 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.

The ONC S&I Framework Electronic Submission of Medical Documentation (esMD) initiative is developing solutions to support an entirely electronic documentation request.

Goals of esMD1) Reduce administrative burden

2) Reduce improper payment

3) Move from “post payment audit” to prior-authorization or pre-payment review

Requirements

4) Move from paper to electronic communication

5) Replace “wet signatures” with digital signatures

6) Migrate to structured data from unstructured data

CMS esMD Utilizes eHealthExchange

Content Transport Services

Structured Electronic Requests for Medical

Documentation

CONNECTCompatible

Medicare Recovery Auditors PERM

CMS Private Network

ECM

xml PDF PDF

CERT

PDF

MedicareAdministrative

Contractors

CONNECTCompatible

Transport Standards

7

CONNECT

DIRECTX12 Core

Electronic Submission of Medical Documentation (esMD) Supporting Multiple Transport Standards and Provider

Directory

ECM

ZPICs PERM MACs

Content Transport Services

RACs CERT

Baltimore Data Center

Medicare Private Network

Internal PD

EHR / HISP

DirectCompatible

Direct

EDITranslator

HIHCONNECT

Compatible

Practice Management

Systems and ClaimsClearinghouse

EDI – X12Compatible

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

9

S&I Framework esMD eMDR Overview

Provider EntityPayer Entity

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

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

11

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

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:

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

Electronic Determination of Coverage (eDoC)

13

eDoC General Workflow

Payer

Patient

LCMPSpecialist /Service Provider

Physician

Templates and Rules

14

Related S&I Framework Initiatives

Initiative 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

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

eDoC Workgroup

Charter Use Case Harmonization Pilots

Consolidated CDA Structured Data Capture Health eDecision

16

Candidate Standards for eDoC “Attachments”

1. Consolidated CDA (structured and unstructured body)

2. Author of Record Digital Signatures for provenance

3. Structured Data Capture for provider guidance and collection of additional Clinical Data Elements

17

Author of Record Level 1Digital signature on bundle of documents

1) Standards

a) PKI: X.509v3 Signing Certificates (FBCA Medium)

b) IHE DSG (XAdES)

c) SAML Assertion for delegation of rights

2) Environment

1) Created as part of sending documents from provider to payer

2) Validated upon receipt

3) One signer (submitter) only for the full bundle of documents

4) Delegation of rights as required to support authorization chain

18

Author of Record Level 2 Requirements1. 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

2. Signature should be applied at time of document creation, modification, review (Administrative – must be applied prior to claim submission)

3. Multiple signatures on same “document”

4. Certificate must be validated at time it is used (OCSP or CRL)

5. Support for validated delegation of rights assertion

6. Signature and delegation of rights must travel with document

7. Signature bound to signed document for life-time of document

8. Supports transition from unsigned to signed documents over time

Example: Multiple signatures in a pdf document (decoupled from transport)

19

Provider with Signed Documents

SignatureDelegationDocument

Document with embedded signature and delegation

Accepted andstored byall regardless of AoR support

Signature and delegation onlyaccepted by systems with AoR support May drop only signature and delegation or error on entire transaction

20

The “A”rchitecture of the CDACDA Document

Header

Structured Body

Section

Entry

Text

Section

Entry

Text

21

CDA Document

Header

Unstructured Body

e.g. PDF

22

Approach

1) Calculate digest over MSH and body with the exception of

a) MSH – Authenticator and Legal Authenticator

b) Any section used for the digital signature

2) Three options for the signature

a) Add to MSH (need to validate that this will work with all components)

b) Add new digital signature section in standard name space

c) Add new digital signature section in an alternate name space

23


Header

Structured Body

Section

Entry

Text

Digital Signature Section

Entry

Text

Digital Signatures

Alt Name Space -- Digital Signature Section

Entry

Text

24

CDA Document

Unstructured Body

e.g. PDF

Header Digital Signatures

Alt Name Space -- Digital Signature Section

Entry

Text

25

Pros and ConsHeader New Section New name space

Works with Structured Yes Yes Yes

Works with Unstructured Yes Requires changes Yes

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

• 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

HL7 September Ballot Cycle

27

Note: updated on 5/17 at 1pm


Header

Body

Section

Entry

Text

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 Templates1. Continuity of Care Document 1.1

2. History and Physical

3. Consult Note

4. Discharge Summary

5. Diagnostic Imaging Report

6. Procedure Note

7. Operative Note

8. Progress Note

9. Unstructured Document

30

• 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?)

CCDA Issues

31

“C-CDA” for eDoC

1. C-CDA used as is

2. C-CDA Complete Encounter Document Template with SDC section

3. C-CDA Variable Document Template with SDC section

32

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)

Consolidated-CDA as is

Select Template (1 of 9)

Template Required Sections (0-n of 60) Template Optional Sections (0-m of 60)

Required Entries Optional Entries Required Entries Optional Entries

Sections and entries are all defined based on the nine “standard” CCDA templates

33

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

C-CDA Complete Encounter

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

35

EHR DatabaseEHR Database

Clinical Information

Past Medical History

Medications

Physical Exam

Complete CDA

Other Data

36

37

C-CDA support for Structured Data Capture

EHR defined Clinical Entry Templates and Forms

EHR Database (discrete elements)

SDC Templates

EHR SDC

C-CDA Document Type

Required/Optional

Required/Optional Entries



External SDC template library

Structured Data Capture for provider guidance and collection of additional Clinical Data Elements

38

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

C-CDA Variable Document

Specific payer requirement

Payer Required Sections (1-60) Payer Optional Sections (0-59)Payer Required

EntriesPayer Optional

EntriesPayer Required

EntriesPayer Optional

Entries



Entire “Template” is defined by payer

for a specific user

story

39

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

Orders

40