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
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
The “A”rchitecture of the CDACDA Document
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
The “A”rchitecture of the CDACDA Document
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
Structured Data Capture Section
All SDC clinical data elements associated with the encounter
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
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
• 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