#7. Building Blocks of Successful Plan Building
I have often said that the Plan Builder is one of the top three most important team members within a TPA. They are typically responsible for set-up of a TPA’s clients and the client’s Plans in the TPA administration system. It is a critical role which requires very detailed knowledge of system functionality as well as the ability to dissect Plans to understand coverage as stated and as intended.
Plan Building impacts so many areas of client relations and operations there it is essential that TPAs get it right the first time. Over the years, I have seen several “best practices” related to Plan Building that will benefit every TPA as it manages this important function.
Plan Building Reporting Relationship
In some places, Plan Building is considered an IT function because IT manages the platform including the vendor relationship. In others, Plan Building is managed by the Claims Department as an Operations function. I am not sure the function belongs in either place, as a TPA should never want competing responsibilities or egos impacting quality and productivity in the Plan Building function.
Two of the “best practices” I have seen align the Plan Builder with Account Management/ Implementation in one case and Quality Assurance/Audit in another. When you step back and think about it, reporting through Account Management/Implementation makes sense. It puts the function closer to the client, who ultimately owns the Plans and must establish rules around and intent of coverage. Once the rules and intent are known, the Plan Builder defines how it will be built in the system. The other option, which I see as a second choice, is inclusion in the Quality Assurance/Audit function. That also makes sense because the accuracy of every call and claim is reliant on the work by the Plan Builder.
Job Description and Performance Evaluation
This seems very simple, but identifying and prioritizing the key responsibilities for a Plan Builder and how success or failure should be measured is a challenge. Some of the obvious responsibilities are accuracy of adjudication based on the benefits programmed in the system; the rate of auto-adjudication; effectiveness of processing controls relating to consistency; and the quality of EOB/EOP communications relating to adjudication decisions. In my mind, each of these represents a destination versus the journey. Excellence in Plan Building is perpetuated if the Plan Builder has invested time and experience in building the procedures which lead to accuracy and higher auto-adjudication rates. On this basis, within each of the major goals the TPA should measure progress on initiatives included in “the journey”. These include:
Knowledge and use of the upgrades and enhancements released by the system vendor impacting adjudication, workflow, and claims controls;
Development of working relationships with qualified Plan Builders at other TPAs using the system;
Integration and testing of new code releases into plan build and adjudication logic;
Integration and testing of compliance-related plan design and procedures into Plans where it is required;
Building of standard benefit logic and auto-adjudication parameters which can be used as time-saving “shortcuts”;
Maintenance of an all-inclusive test claim set which can be used to validate plan building prior to release on “live” claims; and
Development of “model” plan designs which can be used as guidance for the Sales and Account Management Teams in working with smaller groups.
Medical Service and Coverage Matrix
Interpretation of the “coverage intent” of a self-funded Plan Sponsor is one of the most important parts to the implementation process, whether it be for a new group or an existing client making changes. Quite honestly, it is also one of the most complex. That is because it is not as simple as asking whether a medical service, procedure or situation should be covered or not.
The answer could vary based on where a service is provided (e.g., “We don’t want to cover high-cost radiology done in a hospital when there is an independent radiology facility nearby”). It can also vary by the multiple layers of care offered under a category of treatment. For example, with a desire to exclude infertility care a Plan Sponsor could mean diagnosis, drug treatment, surgical treatment or invitro-fertilization. Coverage for some services might vary by a specific network or category of provider, or based on whether a prior authorization or precertification has occurred. There is also variation on whether coverage applies to the deductible and coinsurance or whether specific benefits like a copay or 100% coverage apply. There is also question on “service bundling”, or whether multiple services performed in a single encounter are handled separately from a benefit perspective or bundled under a single benefit. Office-based surgery or lab work are good examples. Are those services handled separately from the office visit and subject to additional patient responsibility beyond the copay? Finally, the Plan may have dollar or encounter limits applicable for a specifically defined time period or a lifetime.
Without a structure for managing the complexity of benefits described above, there is increased probability of misinterpretation of Plan Sponsor intent, inconsistent plan building, inconsistent and inaccurate benefit verification by Customer Service, a poorly written Plan Document and worst of all, the possibility that benefits are administered inequitably.
Roughly 15 years ago I began work on my “ark” in response to a TPA client with a litany of service issues. I call it the Benefit and Coverage Matrix. I recommend there is one in place for each Plan administered by a TPA, and the TPA design a document that works best for it. I believe that a minimum of two qualified individuals at the TPA should create separate versions based on existing documentation, then compare the two versions. Differences must be reconciled through discussion with each other and with the Plan Sponsor. Finally, the Plan Sponsor and their broker or consultant should sign off and be provided with a copy of the signed final version.
There are some “minimum requirements” which should be considered for the Benefit and Coverage Matrix. Some are obvious and others have been added over time:
The format of the document may need to change based on the structure of the Plan. It could be as simple as 2 columns for an EPO Plan, with the first column listing the medical service and the second column listing the specific benefit. A traditional PPO Plan might have 4 columns, representing the medical service and specific coverage for in-network, out-of-network and out-of-area. Any stratification in benefit applicable to the provider used should be reflected with a column specifying the coverage. (Example: A Plan using Reference-Based Reimbursement for all services might have a single benefit or if the program includes contracted “safe harbor” providers might reflect plan incentives to use those providers or at least a benefit difference of “subject to balance billing” or not).
List as many separate medical services as possible in the first column, and in alphabetical order. So, start with Abortion, Acupuncture and so on. The first time I used this tool we created a contest among TPA employees to name as many services as they could think of.
Below each of the services, there should be 5 separate lines for Specific Benefit Provisions, Pre- Auth/Precert Requirements, Network Variations, Accumulators/Limitations and Index to Plan Document:
Specific Benefit Provisions: The TPA should decide whether inclusions or exclusions should be listed here. Using Abortion as an example, the inclusion approach might note “only covers services related to a sexual assault reported to police.” The exclusion approach might note “Not covered except where related to a sexual assault reported to police.
Pre-Auth/Precert Requirements: This is very straight forward, and is where any requirement for medical necessity, setting of care and length of stay determination is listed, along with related penalties for failure to comply. Using high cost radiology as an example, there might be at least two entries… “MRI, CT Scan and PET Scan require Prior-Auth to determine medical necessity” and “Elective MRI, CT Scan and PET Scan require determination of no independent radiology facility in service area (25 miles) to be covered as outpatient hospital service”.
Network Variations: This is where any variation in benefit based on the provider used will be noted. For example, with Genetic Testing as a service, the TPA may offer a contract to a specialty lab where deep discounts are offered. Dep[ending on the Plan Sponsor’s intent, the entry might be “Only covered through ABS Genetic Lab” or “Benefit calculated based on allowed amount with ABC Genetic Lab and patient responsible for charges above the ABC Genetic Lab allowable amount”.
Accumulators/Limitations: For many services there will likely not be a specific limit and “Subject to lifetime maximum benefit” will be entered. Using the infertility services example I discussed previously, the entry here might be “Maximum for diagnosis and treatment for infertility is subject to a $2,500 lifetime maximum”.
Index to Plan Document: This line should provide direction to the specific page or pages in the Plan Document which relate to the benefit.
The Benefit and Coverage Matrix should be a living and breathing document reviewed any time there is a change in law impacting the ERISA or Non-ERISA Plan or at renewal. The review should include client feedback and decisions, as well as potential adjustments uncovered through calls, appeals and adjustments.
Testing and Quality Assurance
One of the biggest differences between the Plan Building approach at PBMs versus TPAs is the attention paid to testing programmed benefits. Most PBMs complete testing prior to taking a group live, because the claims are processed on a real-time basis and a financial transaction occurs immediately. That is not the case with TPAs, who generally release Plans into the workflow knowing that they are able to subject every claim to audit before it is released. Here is where a reality check is necessary. Most TPAs staff the audit function with just enough resources to avoid a total meltdown and report on Performance Guarantees. The standard RFP and SSAE 16 response of “we audit 100% of claims for all new plans for 30 days” just isn’t possible.
I am a firm believer in at least a 4-level Testing and QA process for Plan Building:
Plan Builder Peer Review of system programming against the Benefit and Coverage Matrix;
Use of a sample of at least 100 test claims to validate system output is as anticipated. The sample must include sufficient variation to test each category of benefit related to health acre services as well as limitations and controls. Any discrepancy in output must be reconciled, programming adjusted and correct output verified before the Plan is released.
Audit a more limited number of “live” claims prior to release, only dropping to normal random auditing levels once it is determined that all benefit variables have been validated in the “live” environment.
For the length of the contract, retrospectively analyze complaints and appeals to determine if the root cause is Plan interpretation (Benefit and Coverage Matrix-related), plan building related (built and tested inaccurately) or outside of the control of the Plan Builders (enrollment, provider demographics and pricing, authorization, etc.).
Next week’s Blog will focus on Effective Claims Work-flows and Resource Use.