CMS Program Audit Universe Preparation M. Juhanson

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

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
Director, 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
“…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
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
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!
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

• 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

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 data
MJ 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
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

Self-inflicted injuries
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

Self-inflicted injuries
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?

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
(SCD) Record Layout (cont'd)
NOTE – if you delegate CDs, is this data available to your PBM, or is this in
another source?

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

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

Date the request was
received
CHAR Always
Required
10 Date the request was received from
the beneficiary, their authorized
representative, or their prescriber.
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
Note – characters are always required. As a QA look for any blank fields.

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

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

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
Supporting statement in case of exceptions only for timeliness test

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).
2015/01/01). Enter NA if not
applicable.
32

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

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

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
NOTE THE INSTRUCTION – Not the date letter printed. It’s the date the letter is
mailed or faxed.

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

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

What 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

• 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
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 Practices
• 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 101
If P then Q
If not P then not Q
PIVOT TABLES

Best Practices
• 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 Practices
• 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

• 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
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 45

Resources
CMS Program Audits Web Page
http://www.cms.gov/Medicare/Compliance-and-Audits/Part-C-and-Part-D-
Compliance-and-Audits/ProgramAudits.html
46

Questions ?
mjuhanson@performrx.com
Office: 215.937.4108
Mobile: 215.432.3002
LinkedIn
47

CMS Program Audit Universe Preparation M. Juhanson

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (7)

Similar to CMS Program Audit Universe Preparation M. Juhanson

Similar to CMS Program Audit Universe Preparation M. Juhanson (20)

Recently uploaded

Recently uploaded (20)

CMS Program Audit Universe Preparation M. Juhanson

Editor's Notes