Avoiding a Blind Data

Courtesy of the PCX Newsletter (For a Free Trial, please visit www.cis-pcx.com/register)

Mike Kurland, GP and Compliance Specialist
mikekurland@cis-partners.com

“Trust me, this data was meant for you. You are going to love this data. It has a great personality.” We’ve all been there. You think it’s going to be different this time so you take a chance. Unfortunately, we all know how it ends. But unlike a blind date, where the worst that might happen is the need for a restraining order or a free trial in the witness protection program of the month club, bad data can lead to something much worse; inaccurate government pricing.

How well do you know your data? Are you just caught up in how your data looks in the latest fall fashions – you know, the trophy data? Do you admire your data from afar? By now you are probably thinking to yourself, “The game’s on tonight. Isn’t data IS’s problem. I’m more about the glamour and spice, aka, the regulations and laws.” Living the GP lifestyle is exciting, but if you can’t find the right data or it doesn’t have the right personality, all that your GP knowledge will do is help you determine how inaccurate your final calculations are. OK, so now you are probably wondering how you a nd your data can take the next step together in building a trusting, caring relationship.

Simple. Take the time to get to know your data. First, understand your data sources and the people responsible for them. Odds are, there is more than one source feeding your GP calculations (SAP, contracts management tool, etc.). Thanks Mr. Obvious. True, you probably already knew that, but do you know each system well enough to identify and explain anomalies or variances? If you are not constantly kept in the loop, this burden may fall on you. Knowing who to contact is key, especially with monthly reporting deadlines. And don’t forget that the pe rson pulling the data probably isn’t the same person that can explain it. Is the data really what you think? We all know that shortcuts are taken and that sometimes departments find creative ways to build efficiencies into their daily work load by utilizing systems in ways that they were not designed for. If the data isn’t who you thought it was (and we have all been in those relationships), you are probably going to mistreat it while performing your calculations. It is important to let managers and team leads know to verify this activity with you first.

Do you know how each system interfaces with one another? What is the main source of your attribute data (product, WAC, customer lists, etc.) and how are updates/additions to this data passed to the other systems? Are they instant or via an overnight batch? This could lead to timing issues, especially if changes are made on the last day of the month. What if there is an interface issue and the batch process cannot run for several days? Are you in notified? Were the appropriate adjustments made? What validations are performed on each interface to ensure its accuracy and completeness? You do not have to become an IS guru, but you should have a high level understanding so that you have confidence in the final data. Don’t forget that your data may be playing the field and traveling between multiple systems before you receive it. If you only reconcile back to the source that you received the data from, then you may be missing errors upstream.

It is important to know how corrections in one system are sent to another. Is this process automated? Is there a process? For example, let’s say that contract pricing for direct sales is maintained in your contracts management system but invoiced and paid via SAP. If a pricing error in the contracts system is retroactively corrected does this trigger corrections in your SAP system? If not, you could be over/understating Best Price. Remember, all it takes is one transaction. What if it is a prior period adjustment? If this notification is not autom ated, do the right people know to inform you and your reporting timeframe?

Is the data detailed enough to meet your GP methodology? For instance, are PBM rebates stored at a level that would allow you to determine mail order vs. non-mail order? If so, does this system perform the rebate pricing or is that done by a system which receives summary level data? What if changes are made at the summary level? How do you adjust for them? Not to mention, that this would mean that you may have to link data from several systems increasing the difficulty of retrieving the data you require.

Is your data currently or going to be achieved? If so, do you know how to retrieve it for recalculations or audits? How much notice will IS need to retrieve the data and who do you contact? Legacy systems are a whole other matter. It is common to only convert recent or active data to the new system. Remember when you broke up with your legacy system and said you would stay in touch? Odds are, you didn’t. If your legacy system is already several years old, is there anyone who understands the data structure well enough to correctly pull the data that you require?

Finally, what about the data that doesn’t even exist yet? We all know how creative and complicated managed care contracts can be. Are you in the loop? This will determine if you are proactive or reactive? Do you know how each contract will be entered into the system and if it will contain the data you need? If the deal has several components, can you link them to arrive at an accurate Best Price? Will your current bundling logic suffice? Questions you don’t want answered in the middle of a pricing cycle.

Remember, relationships are hard work but they can be rewarding. Don’t settle for a blind data. You deserve better.