1. (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 )

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

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

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

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

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

7. Transport Standards
CONNECT
DIRECT
X12 Core

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22. CDA Document
Header
Unstructured Body
e.g. PDF 22

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

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

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

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

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

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

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

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

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

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

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

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

35. Complete C-CDA

36. 36

37. 37

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

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

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