prepare data universe for appropriate submission to cms2).pdf · prepare data universe for...

48
Prepare Data Universe for Appropriate Submission to CMS Michelle Juhanson, CHC, CHPC Director, Compliance & Quality Pharmacy Benefit Oversight and Compliance Conference – November 12-13, 2015

Upload: buikien

Post on 27-Mar-2018

223 views

Category:

Documents


2 download

TRANSCRIPT

Prepare Data Universe for Appropriate Submission to CMS

Michelle Juhanson, CHC, CHPCDirector, Compliance & Quality

Pharmacy Benefit Oversight and Compliance Conference – November 12-13, 2015

Speaker’s Disclaimer

• Michelle Juhanson, CHC, CHPC does not have any financial conflicts to disclose.

• This presentation was prepared or accomplished by Michelle Juhanson, CHC, CHPC in her personal capacity. The opinions expressed in this presentation are the speaker’s own and do not reflect the view of PerformRx.

• The speaker is not promoting any service or product.

2

Speaker Introduction

Michelle Juhanson, CHC, CHPCDirector, Compliance and Quality

• 10 years of Part D compliance experience in multiple settings: Part D IRE, plan sponsor, and PBM

• Accountable for PBM responses to numerous CMS audits for clients in 12 states and the District of Columbia since 2007– Program audits

– 1/3 financial audits

– PDE data validation

– Transition monitoring

– Formulary administration

• Oversaw PBM responses to more than 250 external audits since 2007

• Compliance Officer at PerformRx

• Directs integrity audit and rejected claims processes at PerformRx

• Chair of the PerformRx Compliance, Quality, and Star Alliance Committees

• Member of the Health Care Compliance Association and certified in Health Care Compliance (CHC) as well as Health Care Privacy Compliance (CHPC)

• Speaks on issues of compliance and quality at industry conferences nationwide

UPDATE- CMS Program Audit 2015- All CDAG and FA Universes passed CMS review. 0 CAR, 0 ICAR, 0 observation, no resubmission requests!!!

3

Presentation Goals

• Understand purpose of a universe for any audit

• Review CMS’ general universe collection/submission expectations

• Identify typical universe problems

• Understand consequences for universe failures

• Learn CDAG and FA universe requirements

• Review best practices and lessons learned

• Q & A

4

WHY IS A UNIVERSE IMPORTANT FOR ANY AUDIT?

What is a universe?

Why a universe is important

• What the average person thinks

Universe - (statistics) the entire aggregation of items from which samples can be drawn; it is an estimate of the mean of the population

Synonyms: population

• What an auditor means =

6

Why a universe is important

• Samples give auditors a good idea of what is happening in the whole population

• An accurate universe is necessary for audit integrity• Sample Selection • False Positives • False Negatives

7

CMS’ UNIVERSE COLLECTION & SUBMISSION EXPECTATIONS

3 strikes you’re out turns into foul ball

CMS’ universe expectations

General Requirements• Provide accurate and timely universe within 15 business days of the

engagement letter date.

• Major changes to universe record layouts & submission timelines

• CMS will hold a call with you to review the universe request and answer any questions-

• Do - INVITE THE BUSINESS OWNERS WHO HAVE TO PULL THE UNIVERSE

• Do - INVITE THE PBM

• Don’t - Practice compliance hoarding

9

CMS’ universe expectations-What they said in June 2015

• 15 days to submit

• If data issue identified…Strike 1

SUBMIT

UNIVERSE 1

• If perfect, CMS will use this universe.

• If there are still errors…Strike 2

SUBMIT

UNIVERSE 2

• CMS will use this universe regardless.

• No chance to revise universe

• If you can’t get accurate data… Strike 3!

SUBMIT

UNIVERSE 3

10

2015 -2016 Audit Protocols

Calculation of Score Change

• Invalid Data Submission (IDS)

• IDS conditions will be cited when a sponsor is not able to produce an accurate universe within a maximum of 3 attempts.

• IDS conditions will be worth one (1) point.

CMS’ universe expectations-What they are saying now)

11

CONSEQUENCES FOR UNIVERSE FAILURES

The thrill of victory and the agony of defeat

Consequences for universe failures

• “Not having accurate

universes can drastically

affect your audit score”

• “Poor audit results may

lead to a referral for

possible enforcement

actions”

• “…can adversely affect

STAR ratings and past

performance “

- Jennifer Smith CMS , Division of Analysis, Policy, & Strategy (DAPS)

CMS Oversight & Enforcement Conference – June 16, 2015

13

Consequences for universe failures

• After 2nd failed attempt

– CMS will document “observation” in final audit report

• After 3rd failed attempt

– - Invalid Data Submission (IDS) “condition” in audit report for each element that cannot be tested grouped by the type of case.

– UPDATE Automatic ICAR for every applicable condition/element and possible enforcement action

• Example: if 11 audit conditions in Transition, CMS will issue 11 ICARs for Transition

– If limited to one or two elements, ICAR cited per condition

– Proof of ICAR correction not required on re-audit

• Accurate universe(s) will be required on re-audit

14

Consequences for universe failures

Why is this happening!?

CMS Says: • Equity & consistency across audited sponsors• Efficiency and need to complete the audit• Plan sponsor accountability - collect and submit

accurate dataMJ Says: • Bad universes waste everyone’s time and resources • It’s your data. It’s 2015. Poor universes speak poorly of

the organization. • An audit is only as good as the universe & they are

time sensitive

“An inability to pull a universe will adversely affect our ability to conduct the audit and your ability to complete the audit”

- Jennifer Smith CMS , Division of Analysis, Policy, & Strategy (DAPS)

15

COMMON UNIVERSE PROBLEMS

Common universe problems

CMS

Pain Points

Description of the Problem Examples

Data in the wrong fields Date where time belongs

Missing data Blank fields not cases of data N/A

Inappropriate data Continuing members in the universe for new members

Previously pointed out universe errors repeated despite CMS instruction

Using the date a letter was written vs. the date the letter was sent in the mail

17

Common universe problems

The FA universe did not contain rejection error codes in five separate cases

The FA Universe showed beneficiary as new when they were not

FA and Transition - In many instances, the primary return messaging was not provided, making it difficult to fully evaluate the claim.

Producing universe for re-audit in incorrect template for the initial audit year (i.e., 2013 re-audit on 2014 universe format)

Universe produced for the audit did not include the complete pharmacy messaging as required in the CMS audit templates. CMS template states “***Sponsor must provide ALL pharmacy messaging, not limited to the number of fields in this template. Please insert columns as necessary.”

Universe error resulted in patient residence/pharmacy location errors

18

Common universe problems

ADMINISTRATIVE ERRORS

File format (MS Excel to .txt conversion problems (with headers, without headers)

File transfer problems between companies(claims processor - to PBM - to plan)

File naming convention errors

Failure to produce FA universe timely (48hrs)

19

CDAG AND FA UNIVERSE REQUIREMENTS

What’s New & What You Need to Know

CDAG universe key points

15 Individual Universe Templates

– Delivered in tab delimited text (.txt) file format WITH A HEADER ROW

– Include all contracts and PBPs identified in engagement letter in each universe

– 15 record layouts for new requirements

– Universe validation calls with CMS – to quickly check that the dates/times in universes are the same as what's in the system.

– Include favorable, partially favorable, and unfavorable decisions in each universe

– Correction: “was interest paid on the claim?” is an error and CMS will remove it from DMRCD and DMRRD universes

1. SCD 2. ECD 3. DMRRD 4. EIRE 5. EIAM

6. SCDER 7. ECDER 8. ERD 9. SIAM 10. SGD

11. DMRCD 12. SDR 13. SIRE 14. DMRRE 15. EGD

21

Formulary Administration (FA) key points

4 Individual Universe Templates

– Delivered in tab delimited text (.txt) file format WITH A HEADER ROW

– Include all contracts and PBPs identified in engagement letter in each universe

– Excel may be accepted based on CMS Oversight and Enforcement conference and October 20 memo.

• Please confirm with your CMS audit lead in all cases

• Auditors still prefer .txt format

1. Rejected Claims Formulary Administration (RCFA)

2. Rejected Claims Transition (RCT)

3. Prescription Drug Event (PDE) 4. New Member (NM)

22

Standard Coverage Determination (SCD) Record Layout 29 Elements

Field Name Field Type Field

Length

Description

Beneficiary HICN CHAR

Always

Required

11 Health Insurance Claim Number

assigned by the Social Security

Administration to an individual for

the purpose of identifying him/her

as a Medicare beneficiary. The

number is between seven and 11

digits long (e.g., 123456789A). Do

not include any spaces, hyphens or

other special characters.

Beneficiary First

Name

CHAR

Always

Required

30 First name of the beneficiary.

23

If delegated, does the FDR have the HICN and is it easily retrievable?

Field Name Field Type Field

Length

Description

Beneficiary Last

Name

CHAR

Always

Required

30 Last name of the beneficiary.

Enrollment Effective

Date

CHAR

Always

Required

10 Effective date of enrollment for the

beneficiary into their current PBP.

Submit in CCYY/MM/DD format (e.g.,

2015/01/01).

Cardholder ID CHAR

Always

Required

20 Cardholder identifier used to identify

the beneficiary. This is assigned by

the sponsor.

24

Standard Coverage Determination (SCD) Record Layout (cont'd)

NOTE – if you delegate CDs, is this data available to your PBM, or is this in another source?

Field Name Field Type Field

Length

Description

Contract ID CHAR

Always

Required

5 The contract number (e.g., H1234,

S1234) of the organization.

Plan ID CHAR

Always

Required

3 The plan number (e.g., 001, 002) of

the organization.

25

Standard Coverage Determination (SCD) Record Layout (cont'd)

Note field length requirements. A length of 5 means there can only be 5 spaces worth of data in that field. This is just one of many items to QA.

Field Name Field Type Field

Length

Description

Patient Residence CHAR Always

Required

2 Residence code for the beneficiary.

Valid values are:00 – Not specified, other patient residence not identified

below

01 – Home

03 – Nursing Facility

04 – Assisted Living Facility

06 – Group Home

09 – Intermediate Care Facility/Mentally Retarded

11 – Hospice

Note: When the patient residence code is not directly

populated on the incoming coverage determination (CD)

the sponsor can obtain the information from the rejected

claim prompting the CD, other paid claims occurring

within 3 days of the CD, or any medical information the

plan may have at the initiation of a coverage request. If

the sponsor still cannot determine the patient residence

code, then enter 00- not specified in the universe field.

26

Standard Coverage Determination (SCD) Record Layout (cont'd)

Note: A “00” response is acceptable if residence code cannot be determined. Pulling residence from claim data may be complicated if not stored in PA system.

Note: CMS copy/paste error – Use NCPDP values for patient residence, not pharmacy values on pg. 21 v021015

Field Name Field Type Field

Length

Description

Date the request

was received

CHAR

Always

Required

10 Date the request was received from

the beneficiary, their authorized

representative, or their prescriber.

Submit in CCYY/MM/DD format (e.g.,

2015/01/01).

Time the request

was received

CHAR

Always

Required

8 Time of day the request was received

from the beneficiary, their

authorized representative, or their

prescriber. Time is in HH:MM:SS

military time format (e.g., 23:59:59).

27

Standard Coverage Determination (SCD) Record Layout (cont'd)

Note – characters are always required. As a QA look for any blank fields.

Field Name Field Type Field

Length

Description

Was the case

approved or

denied?

CHAR

Always

Required

16 Enter the final disposition of the

case. Valid values are: approved,

denied, IRE auto-forward, dismissed,

withdrawn, re-opened. Enter NA if

the request was never resolved/

processed.

Description of the

issue

CHAR

Always

Required

2000 Description of the issue. For denials,

also include an explanation of why

the case was denied.

28

Standard Coverage Determination (SCD) Record Layout (cont'd)

Partial approvals are technically denials.

Consider using rationale from decision letter.

Field Name Field Type Field

Length

Description

NDC_11 CHAR Always

Required

11 11-Digit National Drug Code. When

no NDC is available, enter the

applicable Uniform Product Code

(UPC) or Health Related Item Code

(HRI). Do not include any spaces,

hyphens or other special characters.

Enter NA if not applicable.

Drug Name, Strength &

Dosage Form

CHAR Always

Required

150 Drug name, strength & dosage form.

Was request made under

the expedited timeframe

but processed by the

sponsor under the

standard timeframe?

CHAR Always

Required

1 Yes/No indicator of whether request

made under expedited timeframe

was processed under the standard

timeframe based on the sponsor

deciding that expedited case was

unnecessary. (Y/N)29

Standard Coverage Determination (SCD) Record Layout (cont'd)

Field Name Field Type Field

Length

Description

Clearly indicate

exception type.

CHAR Always

Required

19 Type of exception request. Valid values

are: tier, non-formulary, prior

authorization, quantity limit, step

therapy, or hospice.

Please list expiration

date of the approval.

CHAR Always

Required

10 Expiration date of the exception

approval. Submit in CCYY/MM/DD

format (e.g., 2015/01/01). Enter NA if

not applicable.

Is this a protected

class drug?

CHAR Always

Required

1 Protected class drug indicator. (Y/N)

Date prescriber

supporting

statement received

CHAR Always

Required

10 Date the prescriber's supporting

statement was received. Submit in

CCYY/MM/DD format (e.g.,

2015/01/01). Enter NA if not

applicable.

30

Standard Coverage Determination (SCD) Record Layout (cont'd)

Field Name Field Type Field

Length

Description

Time prescriber

supporting

statement received

CHAR

Always

Required

8 Time the prescriber's supporting

statement was received. Submit in

HH:MM:SS military time format (e.g.,

23:59:59). Enter NA if not

applicable.

Disposition of the

request

CHAR

Always

Required

16 Status of the request. Valid values

are: approved, denied, IRE auto-

forward, dismissed, withdrawn, re-

opened. Enter NA if the request was

never resolved/ processed.

Was request denied

for lack of medical

necessity?

CHAR

Always

Required

2 Yes/No indicator of whether request

denied for lack of medical necessity.

(Y/N/NA)

31

Standard Coverage Determination (SCD) Record Layout (cont'd)

Supporting statement in case of exceptions only for timeliness test

Field Name Field Type Field

Length

Description

If denied for lack of

medical necessity,

was the review

completed by a

physician or other

appropriate health

care professional?

CHAR

Always

Required

2 Yes/No indicator of review by

physician or other appropriate health

care professional if case was denied

for lack of medical necessity.

(Y/N/NA)

Date of plan

decision

CHAR

Always

Required

10 Date of the plan decision (e.g.,

approved, denied, IRE auto-forward,

dismissed, withdrawn, re-opened).

Submit in CCYY/MM/DD format (e.g.,

2015/01/01). Enter NA if not

applicable.

32

Standard Coverage Determination (SCD) Record Layout (cont'd)

Field Name Field Type Field Length Description

Time of plan decision CHAR Always

Required

8 Time of the plan decision (e.g.,

approved, denied, IRE auto-forward,

dismissed, withdrawn, re-opened).

Submit in HH:MM:SS military time

format (e.g., 23:59:59). Enter NA if not

applicable.

Date effectuated in

the plan's system

CHAR Always

Required

10 Date effectuated in the plan's system.

Submit in CCYY/MM/DD format (e.g.,

2015/01/01). For denials and IRE auto-

forwards indicate NA.

Time effectuated in

the plans' system

CHAR Always

Required

8 Time effectuated in the plan's system.

Submit in HH:MM:SS military time

format (e.g., 23:59:59). For denials and

IRE auto-forwards indicate NA.

33

Standard Coverage Determination (SCD) Record Layout (cont'd)

Field Name Field Type Field

Length

Description

Date oral

notification

provided to

enrollee

CHAR

Always

Required

10 Date oral notification (or

documented good faith attempt)

provided to enrollee (or their

authorized representative). Submit

in CCYY/MM/DD format (e.g.,

2015/01/01). If no oral notification,

indicate NA.

Time oral

notification

provided to

enrollee

CHAR

Always

Required

8 Time oral notification provided to

enrollee. Submit in HH:MM:SS

military time format (e.g., 23:59:59).

If no oral notification, indicate NA.

34

Standard Coverage Determination (SCD) Record Layout (cont'd)

Note – if you did not connect with the enrollee you must enter “NA”- Also-CMS uses “N/A” and “NA” & confirmed that plans will not be “dinged” for either

Field Name Field Type Field Length Description

Date written

notification provided

to enrollee

CHAR Always

Required

10 Date written notification provided to

enrollee. The term “provided” means

when the letter left the sponsor’s

establishment by either US Mail, fax, or

electronic communication. This field is

not for when a letter is generated or

printed within the sponsor’s

organization. Submit in CCYY/MM/DD

format (e.g., 2015/01/01). Enter NA if

not applicable.

Time written

notification provided

to enrollee

CHAR Always

Required

8 Time written notification provided to

enrollee. Submit in HH:MM:SS military

time format (e.g., 23:59:59). Enter NA

if not applicable.

35

Standard Coverage Determination (SCD) Record Layout (cont'd)

NOTE THE INSTRUCTION – Not the date letter printed. It’s the date the letter is mailed or faxed.

Field Name Field Type Field Length Description

If untimely, date

forwarded to IRE

CHAR Always

Required

10 For untimely decisions, date the

request was forwarded to the IRE.

Submit in CCYY/MM/DD format (e.g.,

2015/01/01). For timely decisions

indicate NA.

If untimely, time

forwarded to IRE

CHAR Always

Required

8 For untimely decisions, time the

request was forwarded to the IRE.

Submit in HH:MM:SS military time

format (e.g., 23:59:59). For timely

decisions indicate NA.

If untimely, date

enrollee notified

request has been

forwarded to IRE

CHAR Always

Required

10 For untimely decisions, date the

enrollee was notified of request

forwarded to the IRE. Submit in

CCYY/MM/DD format (e.g.,

2015/01/01). For timely decisions

indicate NA.

36

Standard Coverage Determination (SCD) Record Layout (cont'd)

BEST PRACTICES & LESSONS LEARNED

If at first you don’t succeed, try, try again

Best Practices & Lessons Learned

Document process for requesting, pulling, validating, submitting

• Consider PBM / FDR timeframes and information flow• Confirm naming conventions• Determine what systems are compatible and “talk” to one

another• Be prepared to combine data across platforms

– Combine data from FDRs with the plan data or other FDRs

• Have a plan for transferring and receiving the information– FTP/NDM/email/ portal? So many ways, so many pitfalls.

• If PBM or claims processor is the source of the data, have clear documented agreement – Contracts, performance guarantees, or executive level agreement

KNOW YOUR DATA SOURCES FOR EACH UNIVERSE/ELEMENT

38

Best Practices & Lessons LearnedWhat we did that worked

• QA universes until 100% complete - even after submission to CMS or plan

• Always disclose errors to client. Provide:– Description of issue– New universe– Before/after pictures of

correction– Methodology to find

errors– How you know its fixed– Revised attestation of

correctness

• Be prepared to discuss with client/CMS Potential false positives– Example– Date decision letter mailed before

date/time decision made– Your system, workflow may not

match CMS expectations– Explain your process confidently

Identified universe errors and CMS has the file– Explain # of lines any error exists

General Recommendations

39

Best Practices & Lessons LearnedWhat we did that worked

• Analysts, managers, and executives accountable– Dedicated time & team

– Dedicated (quiet) rooms

– This is the priority

• BO owns data and results regardless of informatics

• Line item review

• Review a sample of claims and CD/RD cases against the universe

• MS Excel- pivot tables to find things that don’t make sense– Duplicates that may point

to copy paste errors

– Date mismatches- if you have “NA” in one field, but a date in another and vice versa

– Blank fields where CMS says “CHAR Required”

– Foundation vs. supportingfield errors

Business Owner (BO) Review

40

Field

Label

Field Name

A If untimely, date

forwarded to IRE

B If untimely, time

forwarded to IREC

C If untimely, date

enrollee notified

request has been

forwarded to IRE

41

Best PracticesWhat we did that worked

• In this example-• If you have data in “A” then you must have

data in “B” and “C”• Know your foundation fields versus your

supporting fields• Complete pivot table searches for blanks or

‘N//A” in any supporting field (B, C) where there is data in the foundational field (A)

Foundation Field

Supporting Field

LOGIC 101If P then Q

If not P then not Q

PIVOT TABLES

Best PracticesWhat we did that worked

• Open all files look for

– Blank fields

– Improperly labeled field names

– Failure to apply any CMS-clarified elements

• Require signed attestations from BO executives & vendors

– Describes QA process

– Affirms accuracy of universe

– Confirms executive-level ownership of accuracy and any negative outcomes

• Compliance should NEVER blindly forward audit documents to client/ CMS

• Everyone is accountable for expertise in this process

Compliance Review

42

Best PracticesWhat we did that worked

• Very short turn-around time• Immediate notice to business as

issues identified• Final report/memo issued of all

identified errors• Written response from BO

required for documentation purposes

• Universe audit – Blank fields– Improperly labeled field

names– Failure to apply any CMS-

clarified elements– Improper formats

(dates/times)

• 100% of CDAG samples…if possible for match of universe data– Blank fields– Discrepancies btw universe

and case file

Internal Audit Review

43

Best Practices & Lessons Learned

• Get top-down support from executive leadership– Show them CMS enforcement letters. $$$ talks!

• Make sure you have a “real” QA plan. – Compliance “looking at it“ wont cut it

– Business owners must own the universe, results, and QA

• Train your business owners on CMS universe requirements. Line-by-line, universe-by-universe

• Encourage automation wherever possible

• Conduct mock audits – announced/unannounced universe monitoring events…until you get it right– Make sure people take the mock audits as seriously as a CMS audit

– Consider hiring a third party

44

Recap

Perfect Universes don’t Make Themselves

Learn from common mistakes

Have a planPBM/FDR

engagement is key

Perfect practice makes perfect

execution

New universe requirements and consequences

15 days –Complete &

Accurate Universe

3 strikes & you’re out-ish

CDAG – 15 templates

FA – 4 templates

45

Resources

CMS Program Audits Web Pagehttp://www.cms.gov/Medicare/Compliance-and-Audits/Part-C-and-Part-D-Compliance-and-Audits/ProgramAudits.html

46

Questions ?

Michelle Juhanson, CHC, CHPC

[email protected]

Office: 215.937.4108

Mobile: 215.432.3002

LinkedIn

47

Copyright © PerformRx, LLC 2015 All Rights Reserved