340B: Solving a Difficult Problem, Simply
340B seems to be a hot topic for many lately. Whether they are trying to report dispenses as part of the Health System, they are a contracted pharmacy or they are trying to break into the world of 340B. Time and time again I hear how hard it can be. I must be a sucker for punishment because I jump at these opportunities.
These agreements can seemingly be complicated and the impact of an audit where you are found to be in non-compliance can have hefty penalties. That is why third party administrators such as MacroHelix, Sentry, PSG and others have come into prominence. They take your pharmacy data, match it to the hospital data and determine the dispenses eligibility based on many factors. Once you this is done, your contract takes effect and you might get a dispense fee, drugs replenished and an invoice to repay the 340B covered entity, or it may not be like that at all.
MedEdge has many years of experience serving pharmacies in this scenario and it seems every one has slight variations in their setup and rules to what is sent. Most TPAs will tell you to just sign a piece of paper to get your data from the switch and that is it. That sounds nice but……not exactly the case.
When looking at a 340B contract and trying to define how to get the data to them there are a few things that need to be considered:
Data from the "Switch" - I have heard this claim over and over again. This means that you give the TPA permission to pull your data from the NCPDP switch that adjudicates the claims. This is a great solution if you are a Retail Pharmacy with no desire to have more than one 340B contract. However, in my experience nobody wants just one and if you are Infusion or Specialty your claims are not 100% electronic pharmacy, so now what? Now you need to think of your strategy for 340B. The TPA is driven by the covered entity so if you go after multiple Covered Entities then chances are you will be sending data to multiple TPAs. If you are not 100% electronic pharmacy you need to determine how to convert your major medical data to the data format. This will require work from your IT department or IT partner for your dispensing system. I have not ran into a system that did not have the data needed, they just had to do some conversion of the data to the required format.
Contract requirements - Regardless of the TPA, their data for all of their contracts are going to be the same data format. This does not mean that your contract requires the data. For instance, I have had many customers who are a hospital owned system trying to get the billed, total payments and copay for the data feed. This typically is not necessary as these entities are just looking to get drug replenished and not seeking to get a dispensing fee from the hospital. This means that the lag in time from dispense to recoupment can be less as you are not waiting on the billing process to complete or even start. Be sure to understand your contract's uniqueness and trust but verify the TPA's data file requirements.
Payer Filtering - This mostly deals with eliminating government payers such as Medicare/Medicaid and Managed Medicare. Here you will want to determine if you need to eliminate any dispenses tied to the dispense as they can cause issue in accruing drug amounts. However, be smart and calculated in how you approach this. Too often I see systems that have been setup to hardcode specific payers. This is fine if you want but what happens when the payer name changes or you add more payers? This process can be daunting at best and inaccurate in most cases. Instead think of other higher level logic such as using a Payer Type/Group to filter out all "Medicaid" payer types or perhaps there is a way to create a custom field that says "Exclude from 340b". Either way these types of processes and system setup will save you a lot of headache.
Data Validation and Automation - This is a big one. Many times I have seen clients try to manage the data through a spreadsheet…YUCK! Can you imagine how dated the information in the spreadsheet is or how prone to errors this could be? Don't you want a process where you can, as Ron Popeli famously said, "Set It and Forget It!"? To do this you should think about how to setup an automated validation tool that will check each record of data for accuracy, alert you to any errors and then send the clean data automatically to your TPA. Trust me when I say you do not want to think about the potential costs of having to send files, fix files, resend files and repeat. Having it done right the first time is worth its weight in gold.
No matter what your situation, 340B doesn't have to be a struggle to implement if you have a strong strategy and powerful data partner. Keep these points in mind
Data file format may be standard but your situation is not. Be prepared to explain your system, your business and work with the TPA on how they want to see the data.
Your contract with the covered entity is specific to you and may not require the same requirements as the TPA "standard".
Have a solution in place that includes a process to manage your ever changing business to accommodate new payer and drug/therapy mix so you are not painted in a corner with 340B.
Have a solution that allows you to manage data issues and keep the data flow automated. Having a manual process for these processes are expensive and cumbersome. Automate everything and continue to build your 340B business with confidence.
