Electronic Submission of Medical Documentation (esMD)

to

DirectTrust.org

December 3, 2014

Improper Payment

www.paymentaccuracy.gov

Medicare receives 4.8 M claims per day.

CMS’ Office of Financial Management estimates that each year (based on 2013 audit information)

o the Medicare FFS program issues more than $36.0 B in improper payments (error rate: 10.1%).

o $21.7 B of improper payment is due inadequate documentation to support payment for services billed

o $10.1 B of improper payment is due to services that were not medical necessary based on Medicare coverage policies

1.8 million Medical Documentation Requests are sent annually 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)

PCG/esMD Goals Prevent improper payment through

• prior-authorization (e.g. PMD)• pre-payment review

Minimize provider burden through• electronic communication of medical information (esMD)• structured data to facilitate review process• digital signatures to establish data integrity and provenance

Adopt/promote standards to facilitate information exchange• electronic transaction standards• Messaging standards• Content standards• Digital Signature standards

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.

CMS esMD Utilizes CONNECT

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

esMD Direction

esMD

ZPICs PERM MACs

Content Transport Services

RACs CERT

Baltimore Data Center

Medicare Private Network

PD

HISP

DirectDirect

EDITranslator

HIH or Provider

CONNECT

Providers & Intermediaries

EDI – X12

In Operation

In Development

Waiting

esMD Process Flow

The overall esMD process can be divided into three steps:

• A provider registers with a payer to receive electronic medical documentation requests (eMDRs)

1. Register to Receive eMDRs

• A payer sends an eMDR to a registered provider

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

7

S&I Framework esMD Initiative 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 RegistrationDigital signatures on transactions

esMD AoR Level 1 and Level 2Digital Signatures on Document Bundles

and Individual Documents

Certificate Authority

Registration Authority

Provider Directories

User Story • All Actors obtain and

maintain a non-repudiation digital identity

• Provider registers for payer services (see UC1)

• Payer requests documentation (see UC2)

• Provider submits digitally signed documents and/or document bundles to address request by payer

• Payer validates the digital credentials, signature artifacts and, where appropriate, delegation of rights

AoR -- Phased Scope of Work

9

Level 1 – Completed

Level 2 - Completed

Level 3 - TBD

Digital signature on aggregated documents

(bundle)

Digital signature to allow traceability of individual

contributions

Digital signature(s) on an individual document

• Focus is on signing a bundle of documents prior to transmission• Define transaction signature requirements and artifacts in

conjunction with for esMD UC 1 and UC 2

• Focus is on one or more contributors signing an individual document at the time of document creation

• Focus is on provenance of information with non-repudiation signatures on information at the point of creation

Digital Identities and AoR Workgroups

1. Identity proofing

2. Digital identity management

3. Digital signatures and artifacts

4. Delegation of Rights

5. Author of Record

10

General AoR Requirements

Solution must scale to all providers and payers minimize the operational impact required to establish , maintain

or use a digital identity provide for non-repudiation without resorting to audit logs or

validation of system configuration Standards – minimum required

Federal Bridge Certification Authority Medium Level NIST 800-63-2 Level 3 (in-person) /4 NIST 800-57 Part 1 (Revision 3 July 2012) X.509v3 Digital Certificates

Standards for Identity Proofing

Document Link Title & Version / Notes

FBCA X.509 Certificate Policy X.509 Certificate Policy for the Federal Bridge Certification Authority, Version 2.25

FICAM Roadmap and Implementation Guidance

Federal Identity, Credential, and Access Management Roadmap and Implementation Guidance, Version 2.0

NIST SP 800-63-2 Electronic Authentication Guideline

FBCA Identification Requirements for Medium Assurance Level

Level Identification Requirements

Medium (all policies)

Identity shall be established by in-person proofing before the Registration Authority, Trusted Agent or an entity certified by a State or Federal Entity as being authorized to confirm identities; information provided shall be verified to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant which is based on an in-person antecedent may suffice as meeting the in-person identity proofing requirement. Credentials required are one Federal Government-issued Picture I.D., one REAL ID Act compliant picture ID1, or two Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Non-REAL ID Act compliant Drivers License). Any credentials presented must be unexpired.

Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document.

For PIV-I, credentials required are two identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal Government-issued picture identification (ID). For PIV-I, the use of an in-person antecedent is not applicable.

Standards for Signing Credentials

Document Link Title & Version / Notes

FBCA X.509 Certificate Policy X.509 Certificate Policy for the Federal Bridge Certification Authority, Version 2.25

FICAM Roadmap and Implementation Guidance

Federal Identity, Credential, and Access Management Roadmap and Implementation Guidance, Version 2.0

Standards for Digital Signatures and Delegation of Rights

Standard and Link Issued by

FBCA X.509 Certificate Policy X.509 Certificate Policy for the Federal Bridge Certification Authority, Version 2.25

FIPS PUB 186-3 Digital Signature Standard

XML DigSig XML Signature Syntax and Processing (Second Edition), W3C Recommendation

OASIS SAML Assertions Assertions and Protocols for the OASISSecurity Assertion Markup Language(SAML), Version 2.0 All SAML v2.0 files

SummaryesMD initiative identifies Best Practice for:

1) Establishing the identity of providers

2) Registering providers for payer services

3) Secure transmission of electronic requests for documentation

4) Defining documentation requests standards

5) Addressing Author of Record requirements

6) Defining Digital Identity

a) Identity Proofing of all participants

b) Digital Credential Lifecycle,

c) Digital Signatures, and

d) Delegation of Rights Standards

7) Creating implementation guides for payers and providers for all required esMD processes and transactions

What drives CMS Direct Requirements?1. Federal Security Requirements

– FIPS (Federal Information Processing Standards)– FISMA (Federal Information Security Management Act)– NIST (National Institute of Standards)– FPKI (Federal Public Key Infrastructure)– FBCA (Federal Bridge Certification Authority)– HIPAA (Health Insurance Portability and Accountability Act)

2. Medicare FFS Relationship to Providers– No direct contractual relationship with providers– Providers register with NPPES (National Plan & Provider Enumeration

Systems) for NPI– Providers enroll with PECOS (Provider Enrollment, Chain and

Ownership System) for Medicare FFS

4. CMS requirements for communication of PHI to providers– Communication containing PHI must be sent to validated endpoint

• Mail address (on CLAIM) • Requested endpoint

Requirements for esMD Direct1) Identity-proof individual or organization at FBCA medium (e.g. NIST LOA3

with in-person requirement) “address owner”– Antecedent allowed based on FBCA guidelines– Validate NPI for all providers

2) X.509 v3 certificate (Direct Cert) from FBCA cross-certified CA issued under FBCA CP or equivalent

– Direct Cert must include NPI– Direct Cert must be address bound (not domain)

3) HISP must be inspected and accredited (details TBD)

4) Direct Cert must only be issued to accredited HISP

5) Direct “address owner” must be covered by a BAA with the HISP

6) Last mile and access must utilize an encrypted transport (should meet current FIPS/FISMA requirements -- e.g. TLS 1.1 minimum)

Best Practice (not current requirement)7) Separate signing and encryption Direct Certs

8) All Direct messages stored encrypted in HISP (including audit logs)

9) Two factor authentication for account access where one factor is a hard token