Electronic Submission of Medical Documentation (esMD) to DirectTrust.org December 3, 2014

Improper Payment  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 It enabled Providers to send Medical Documentation electronically 4 Review Contractor Provider Request Letter Paper Medical Record Phase 1: Doc’n Request Letter electronic Phase 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 CONNECT Compatible Medicare Recovery Auditors PERM CMS Private Network ECM xml PDF CERT PDF Medicare Administrative Contractors CONNECT Compatible

esMD Direction esMD ZPICs PERM MACs Content Transport Services RACs CERT Baltimore Data Center Medicare Private Network PD HISP Direct EDI Translator 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: esMD Phase 2 esMD Phase 1 7

S&I Framework esMD Initiative Overview Provider Entity Payer Entity Payer Provider (Individual or Organization) Provider (Individual or Organization) Contractors / Intermediaries Agent Payer Internal System Gateway esMD UC 2: Secure eMDR Transmission esMD UC 1: Provider Registration Digital signatures on transactions esMD AoR Level 1 and Level 2 Digital 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 Level 3 (in-person) /4  NIST Part 1 (Revision 3 July 2012)  X.509v3 Digital Certificates

Standards for Identity Proofing Document LinkTitle & 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 Electronic Authentication Guideline

FBCA Identification Requirements for Medium Assurance Level LevelIdentification 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 , 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 LinkTitle & 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 LinkIssued by FBCA X.509 Certificate Policy X.509 Certificate Policy for the Federal Bridge Certification Authority, Version 2.25 FIPS PUB 186-3Digital Signature Standard XML DigSig XML Signature Syntax and Processing (Second Edition), W3C Recommendation OASIS SAML AssertionsAssertions and Protocols for the OASIS Security Assertion Markup Language (SAML), Version 2.0 All SAML v2.0 files

Summary esMD 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 Direct 1)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) 1)Separate signing and encryption Direct Certs 2)All Direct messages stored encrypted in HISP (including audit logs) 3)Two factor authentication for account access where one factor is a hard token