CMS Program Audit Universe Preparation M. Juhanson

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.

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!!!

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

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 =

Why a universe is important

“…from which samples can be drawn”

• 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

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

CMS’ universe expectations- What they said in June 2015

SUBMIT UNIVERSE 1• 15 days to submit• If data issue

identified…Strike 1

SUBMIT UNIVERSE 2• If perfect, CMS

will use this universe.

• If there are still errors…Strike 2

SUBMIT UNIVERSE 3• CMS will use this

universe regardless. • No chance to revise

universe• If you can’t get

accurate data… Strike 3!

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)

HPMS Memo- October 20, 2015

CONSEQUENCES FOR UNIVERSE FAILURESThe 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

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

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)

COMMON UNIVERSE PROBLEMS

Common universe problems

CMS Pain Points

Description of the Problem ExamplesData 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

Self-inflicted injuries

Common universe problems

The FA universe did not contain rejection error codes in five separate casesThe FA Universe showed beneficiary as new when they were notFA 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

Self-inflicted injuries

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)

CDAG AND FA UNIVERSE REQUIREMENTSWhat’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. EIAM6. SCDER 7. ECDER 8. ERD 9. SIAM 10. SGD

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

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)

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.

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.

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.

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 AlwaysRequired

2 Residence code for the beneficiary. Valid values are:00 – Not specified, other patient residence not identified below01 – Home 03 – Nursing Facility04 – Assisted Living Facility06 – Group Home09 – Intermediate Care Facility/Mentally Retarded11 – HospiceNote: 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. 

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).

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.  

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)

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.

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)

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.

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.

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.

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.

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.

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

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

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. supporting field errors

Business Owner (BO) Review

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

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

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

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

Recap

New universe requirements and consequences• 15 days – Complete & Accurate Universe• 3 strikes & you’re out-ish• CDAG – 15 templates• FA – 4 templatesPerfect Universes don’t Make Themselves• Learn from common mistakes• Have a plan• PBM/FDR engagement is key• Perfect practice makes perfect execution

Resources

CMS Program Audits Web Pagehttp://

www.cms.gov/Medicare/Compliance-and-Audits/Part-C-and-Part-D-Compliance-and-Audits/ProgramAudits.html

Questions ?

Michelle Juhanson, CHC, [email protected]: 215.937.4108 Mobile: 215.432.3002LinkedIn

Copyright © PerformRx, LLC 2015 All Rights Reserved