additional attachment templates presented to the attachments workgroup n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Additional Attachment Templates Presented to the Attachments Workgroup PowerPoint Presentation
Download Presentation
Additional Attachment Templates Presented to the Attachments Workgroup

Loading in 2 Seconds...

play fullscreen
1 / 21

Additional Attachment Templates Presented to the Attachments Workgroup - PowerPoint PPT Presentation


  • 130 Views
  • Uploaded on

Additional Attachment Templates Presented to the Attachments Workgroup. December 10, 2013. Improper Payment. Medicare receives 4.8 M claims per day. CMS ’ Office of Financial Management estimates that each year

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Additional Attachment Templates Presented to the Attachments Workgroup' - mieko


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
improper payment
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 Bin improper payments (3-year rolling error rate: 8.1%).
  • Most improper payments can only be detected by ahumancomparing aclaimto 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 over1.8 million requests formedical documentation each year.
  • Claim review contractors currently receive most medical documentation inpaperform or via fax.
esmd background
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

Phase I of esMD was implemented in September of 2011. It enabled Providers to send Medical Documentation electronically

Phase 1:

Doc’n Request Letter

electronic

Phase 2:

electronic

Paper Medical Record

The ONC S&I Framework Electronic Submission of Medical Documentation (esMD) initiative is developing solutions to support an entirely electronic documentation request.

Provider

electronic

slide4
esMD
  • Goals
  • 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

4

s i framework esmd overview
S&I Framework esMD Overview

Registration Authority

Certificate Authority

Provider Directories

Provider Entity

Payer Entity

Contractors / Intermediaries

esMD UC 1: Provider Registration

Includes Digital Signature

Agent

esMD UC 2: Secure eMDR Transmission

Includes Digital Signature

Provider

(Individual or Organization)

Payer

esMD AoR Level 1

Digital Signature on Bundle

Payer Internal System

esMD AoR Level 2

Digital Signature on Document(s)

wet signatures
Wet Signatures
  • Standards and legal standing
    • Standards are based on legal precedence
    • Non-repudiation inherent in wet signature
  • Audit requirement
    • None
    • Often requires an attestation to determine validity
  • Timing of Signature
    • Applied at any time (timing policy cannot be enforced)
  • Fraud protection
    • none
    • Short of forensic evaluation of original signed document unable to determine when signing occurred
electronic signatures
Electronic Signatures
  • Standards and legal standing
    • Standards are based on technology and legal precedence
    • Currently there are no technically mature techniques that provide the security service of nonrepudiation in an open network environment, in the absence of trusted third parties, other than digital signature-based techniques.(HHS)
  • Audit requirement
    • Require audit of signing system (e.g. EMR) installation, policies, and audit logs
    • May require an attestation to determine validity
  • Timing of Signature
    • Record of time of signing
    • Can be applied at any time – timing determined by EHR
  • Fraud protection
    • None/Limited – all required a physical audit and attestations
digital signatures
Digital Signatures
  • Standards and legal standing
    • International and US Federal standards
    • Standards based on cryptography
  • Audit requirement
    • Audit required as part of identity proofing and certificate issuance
  • Timing of Signature
    • Time stamp on document is evidence of when signing occurred
    • OCSP response is external evidence of timing and certificate validity
    • Signature when document is complete
  • Fraud protection
    • Absolute – assuming that PKI policies are followed
author of record level 2 requirements
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)

9

provider with signed documents
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

10

signature on cda
Signature on CDA

Solution: Add “signatureText” attribute to Participation occurrences for legalAuthenticator and authenticator in the CDA Header to hold Digital Signature and Delegations of Rights Assertion artifacts -- exclude these Participation occurrences from the calculated digest

CDA Document

Section

Text

Entry

Entry

Entry

Entry

Authenticators and Digital Signatures

Header

Structured Body

Structured Body

Section

Text

Entry

Entry

Entry

Entry

CDA Document

Unstructured Body

Authenticators and Digital Signatures

Header

Unstructured Body

e.g. PDF

11

implication of digital signatures
Implication of Digital Signatures
  • Once signed, the content may not be altered without voiding the Digital Signatures
  • Digital Signatures will not work on anything where the structure will be altered
  • Must address individual contributions – do this through author participation, role and signature purpose
today typical response to cms request for documentation
Today – Typical Response to CMS request for Documentation

Documentation collected via EHR forms and templates and stored in the EHR Database

Lab Orders/Results

History of Present Illness

Vital Signs

EHR Forms/Templates

Allergies

Medications

History and Physical

Vital signs

Visit Summary

Orders / Treatment

Textual reports

CDA Document

Authenticators and Digital Signatures

Header

esMD Phase 1

Unstructured Body

PDF

EHR Database

PDF

Demographics

EHR generates PDF of all encounter information (typically)

13

current templates
Current Templates

Use of Current Templates

Create Structured CDA

1) Works for all sections and entry templates defined as SHALL or, depending on the certification requirements, SHOULD

2) Sections and entry templates defined as MAY are supported to various degrees, or not at all, by each EHR vendor

3) How does the provider meet documentation requirements?

4) Recipient of the document does not know if data does not exist, data is being withheld, or the implementation does not support the section/entry

CDA Document

Authenticators and Digital Signatures

Header

Structured Body

Lab Orders/Results

History of Present Illness

Section

Section

Section

Section

Text

Text

Text

Text

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Vital Signs

EHR Forms/Templates

Allergies

Medications

History and Physical

Vital signs

Visit Summary

Orders / Treatment

Textual reports

EHR Database

Demographics

14

sign cda
Sign CDA

Notes:

Signer may authenticate and then review/sign multiple documents at one session

Authentication via acceptable two factors -- something you know, something you hold, something you are (e.g. biometric), etc.

CDA typically contains a subset of the encounter information

Universal Time

Long term validation

CDA Document

Header

Authenticate

Signing “Module”

Structured Body

Lab Orders/Results

History of Present Illness

Section

Section

Section

Section

Text

Text

Text

Text

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Write Signature

Digest

Vital Signs

EHR Forms/Templates

Allergies

Medications

Authenticators and Digital Signatures

History and Physical

Vital signs

Visit Summary

Orders / Treatment

Textual reports

EHR Database

Demographics

Not in CDA

15

create complete cda
Create Complete CDA

Prior to or at time of signing – create CDA from Complete Document Template

CDA Document

Create Structured CDA from Complete Document Template

All Document sections and constrained entries are populated or use appropriate nullFlavor

Ensures that all captured documentation is in the CDA prior to signing

Authenticators and Digital Signatures

Header

Structured Body

Lab Orders/Results

History of Present Illness

Section

Section

Section

Section

Text

Text

Text

Text

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Vital Signs

EHR Forms/Templates

Allergies

Medications

History and Physical

Vital signs

Visit Summary

Orders / Treatment

Textual reports

EHR Database

Demographics

16

sign cda1
Sign CDA

Notes:

Signer may authenticate and then review/sign multiple documents at one session

Authentication via acceptable two factors -- something you know, something you hold, something you are (e.g. biometric), etc.

Universal Time

Long term validation

CDA Document

Header

Authenticate

Signing “Module”

Structured Body

Lab Orders/Results

History of Present Illness

Section

Section

Section

Section

Text

Text

Text

Text

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Write Signature

Digest

Vital Signs

EHR Forms/Templates

Allergies

Medications

Authenticators and Digital Signatures

History and Physical

Vital signs

Visit Summary

Orders / Treatment

Textual reports

EHR Database

Demographics

17

provider setup for digital signatures
Provider Setup for Digital Signatures
  • Individual provider supplies IDs and other information as part of credentialing or to a standalone Registration Authority (RA)
  • RA verifies credentials
  • Certificate Authority (CA) receives providers information from the RA
  • CA issues access information (e.g. hard token) to the individual provider
  • CA issues encrypted key to the signing application key store

1)

Registration Authority

2)

3)

4)

Certificate Authority

5)

Provider

Signing Application

signing process
Signing Process

CDA Document

  • C-CDA created for activity to be signed (system or on demand)
  • Signer views list of documents (C-CDAs) to be signed
  • Signer reviews documents and indicates ready for signature and where appropriate role and signature purpose (will most likely be defaulted based on signer)
  • Signer authenticates to Signing Application
  • Signer signs list of all reviewed and accepted documents

Digital Signatures

Header

Structured Body

Lab Orders/Results

History of Present Illness

Section

Section

Section

Section

Text

Text

Text

Text

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

Entry

1)

Vital Signs

EHR Forms/Templates

Allergies

Patient Visit Date Document Role Purpose Rev Ready

James, Sandy 8/15/2013 Complete CDA MD Legal Authenticator

Stanford, John 8/14/2013 Procedure CDA MD Legal Authenticator

Stanford, John 8/15/2013 Complete CDA MD Co-Signer

Medications

X

X

History and Physical

Vital signs

Visit Summary

Orders / Treatment

Textual reports

...

X

X

X

Sign selected documents

5)

2)

3)

Provider

Signing Application

5)

EHR Database

Demographics

4)

new templates
New Templates
  • Documents
  • Complete Encounter Document (office visit, consult, home health)
  • Complete Hospitalization Document (hospital admit and discharge)
  • Complete Operative Note Document (operative note)
  • Complete Procedure Document (procedure note)
  • Time Boxed Document (shift, day, period) (for acute / long term care)
  • Sections
  • Additional Documentation Section (documents that do not have a place in the existing sections)
  • Externally Defined CDE Section (data collection using externally defined templates that produce name value pairs defined by external standards (NLM ...))
  • Orders Placed Section (orders that are instantiated (moodCode RQO))
  • Transportation Section (provider copy of transportation documentation)
notes medicare ncd lcd
Notes – Medicare NCD/LCD
  • Provider is not required to use a specific document template or even use a CDA at this time
  • Attachments rule may change this to require a CDA document
  • Provider is responsible for submitting all documentation required to justify that the services is medically necessary and appropriate
  • Signatures must be applied prior to billing -- based on policy
  • We are:
  • Not changing the content or use of the existing templates in CCDA R1.1 or R2
  • Not requiring new data collection by provider – they should be documenting based on medical best practice (embodied in NCD/LCDs)
  • Creating templates that ensure that the CDA signed by a provider contains everything documented in the encounter. Provider can withhold information if provider deems appropriate and technology supports.
  • Creating Additional Attachment Templates that meet Medicare requirements and can be used by other payers or providers as they deem appropriate.