esMD Direction

Download Report

Transcript esMD Direction

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
www.paymentaccuracy.gov
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
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.
Before esMD:
Review Contractor
Request
Letter
Paper Medical
Record
Provider
Phase 1:
Phase I of esMD was
implemented in September of
2011. It enabled Providers to
send Medical Documentation
electronically
Doc’n
Request
Letter
electronic
The ONC S&I Framework
Electronic Submission of Medical
Documentation (esMD) initiative is
developing solutions to support an
entirely electronic documentation
request.
4
Phase 2:
electronic
electronic
CMS esMD Utilizes CONNECT
Medicare
Administrative
Contractors
CONNECT
Compatible
Structured Electronic
Requests for Medical
Documentation
xml
Medicare
Recovery
Auditors PERM
PDF
PDF
CMS Private Network
Content Transport Services
ECM
CONNECT
Compatible
CERT
PDF
esMD Direction
RACs
ZPICs
CERT
PERM
MACs
Providers &
Intermediaries
EDI – X12
Medicare Private Network
In Development
EDI
Translator
HISP
Waiting
Content Transport Services
Direct
Direct
esMD
Baltimore Data Center
PD
HIH or
Provider
In Operation
CONNECT
esMD Process Flow
The overall esMD process can be divided into three steps:
esMD Phase 2
7
esMD Phase 1
S&I Framework esMD Initiative Overview
Provider
Directories
Registration
Authority
Payer Entity
Contractors /
Intermediaries
User Story
Certificate
Authority
Provider Entity
esMD UC 1: Provider Registration
Digital signatures on transactions
Agent
Payer
Payer
Internal
System
Gateway
esMD UC 2: Secure eMDR Transmission
esMD AoR Level 1 and Level 2
Digital Signatures on Document Bundles
and Individual Documents
Provider
(Individual or
Organization)
• 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
Level 1 – Completed
Digital signature on
aggregated documents
(bundle)
•
•
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
Level 2 - Completed
Digital signature(s) on an
individual document
Level 3 - TBD
Digital signature to allow
traceability of individual
contributions
9
Digital Identities and AoR Workgroups
1.
2.
3.
4.
5.
Identity proofing
Digital identity management
Digital signatures and artifacts
Delegation of Rights
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
FBCA X.509 Certificate Policy
FICAM Roadmap and
Implementation Guidance
NIST SP 800-63-2
Title & Version / Notes
X.509 Certificate Policy for the Federal
Bridge Certification Authority, Version
2.25
Federal Identity, Credential, and Access
Management Roadmap and
Implementation Guidance, Version 2.0
Electronic Authentication Guideline
FBCA Identification Requirements for Medium Assurance Level
Level
Medium
(all
policies)
Identification Requirements
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. 11150136, 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
FBCA X.509 Certificate Policy
FICAM Roadmap and
Implementation Guidance
Title & Version / Notes
X.509 Certificate Policy for the Federal
Bridge Certification Authority, Version
2.25
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
Digital Signature Standard
FIPS PUB 186-3
XML DigSig
XML Signature Syntax and Processing
(Second Edition), W3C Recommendation
OASIS SAML Assertions
Assertions 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)
2)
3)
4)
5)
6)
Establishing the identity of providers
Registering providers for payer services
Secure transmission of electronic requests for documentation
Defining documentation requests standards
Addressing Author of Record requirements
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.
2.
4.
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)
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
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)
2)
3)
Separate signing and encryption Direct Certs
All Direct messages stored encrypted in HISP (including audit logs)
Two factor authentication for account access where one factor is a hard token