prepare data universe for appropriate submission to cms2).pdf · prepare data universe for...
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 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 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
• “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
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 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
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
Office: 215.937.4108
Mobile: 215.432.3002
47