NCPDP Encounters at US Script

US Script had grown into a finely tuned, mature, and successful commercial PBM before it was acquired by Centene.

Suddenly, US Script quadrupled its business volume and inherited several government Medicaid health plans.  With these plans came reporting requirements otherwise known as “encounters”.  These “encounters” would send the smart software developers running scared within three months.  I stayed, but I’m, well, nuts.  I enjoy challenges, especially when they give me an opportunity to make a huge difference to the company.

Ken, Centene’s liason between the health plans and US Script, had a great sense of humor and urgency as he once commented to me, “…the eyes of all the gods of the pantheon were on you”.  Encounters are used for insurance rate setting and recovery of millions of dollars of “reinsurance” money for health plan members with extraordinary requirements.  Furthermore, errors and untimely submissions and corrections can result in costly sanctions from the states.  So, these encounters have a very real impact on the profitability of the company.

Unfortunately, when Centene acquired US Script, encounters systems were not built.   Nor was it easy to find someone who knew anything about encounters.  Specifications were scant, and just before I started working for US Script, in desparation a couple programmers tossed some partially developed prototypes into production before leaving the company.

Truth is, nobody is to blame for this helter-skelter.  Management had a choice to make — take on a great opportunity with great challenges believing we can win, or turn it down.  I know management made the right decision and I expect our company to be an industry leader in encounter expertise within six months to a year if we are not already there.  As for the programmers who left, they were brilliant programmers and did a great job of getting things started at a very difficult and pressured time.

What I walked into

When I stepped into this position, pressure on US Script was high.  We were sending encounters to the states, but our programs were faulty and incomplete.   Some errors had gone months unnoticed and hundreds of thousands of claims needed to be cleared out and resent.  This was complicated further by the fact that Centene owned several companies with health plans serving different states, each state with completely different requirements, file formats, business rules, and frequently changing specifications.

Of the tens of thousands of pharmacies sending claims to US Script, some identified physicians by DEA number.  Others used state license numbers.  Some identified physicians by Federal Tax ID, and others used Medicaid IDs.  And, there was no guarantee we would receive the same ID we were required to give to the state.  This was further complicated by transitions that the states were making from legacy IDs to the NPI.

The first prototypes in production

One of our encounters programs was written in Oracle Reports 6i while the rest were all written in Oracle PL/SQL and were called by Unix shell scripts, except one which had to be run by hand within SQL*Plus.   These PL/SQL programs consisted of a single loop based on a complicated SQL join with output being sent to the utl_file directory.  Output files usually had to have their carriage returns stripped off with a short Perl program.

There was little if any error handling or error logging.   There was no formal tracking of which claims had been sent or held.  No mechanisms for voiding, adjusting, or correcting claims were present.  Replacement claims would be submitted as new-day claims causing them to fail with “duplicate claim” errors.

Flood of Emergencies

Several plans required massive replacements.  Often documentation on the requirements of encounters lacked clarity, correctness, or completeness, and often systemic problems in the programs went months undetected and unreported to the health plans and to US Script.

For one plan, reinsurance dollars were threatened by a scaling problem in the metric quantity.  Others had thousands of held claims for lack of a proper physician or pharmacy ID.  One required our paid amounts to be replicated into the Coordination of Benefits segment and this was complicated further by buggy error reporting leading one to conclude that their production and test systems were requiring opposing things.

While these challenges were taking place, various health plans transitioned from using Medicaid IDs and DEA numbers to using NPIs, and plan administrators began asking for special reports on the number of encounters held, why they were being held, and expected dates of resolution, and my time was often burned up with conference calls and special reports making it difficult to move forward strategically.

Two additional plans were brought into production and another plan wanted their encounters done on a weekly basis, though their period-end processing was done twice per month.

Innovations Resulted…

Since most of the programs were built around a single cursor with a massive join, it was impossible for us to detect which claims were being left unsent.

I created a scanner program in object oriented Perl that could read any encounter file in any format into a master table to track information on the filename, location, batch id, batch type, creation date, etc., and to track the information on each claim in the file into a detail table.  The program had a configuration file of regular expressions to enable it to be quite flexible, and I tested it and optimized it for speed, and eventually, every encounter file sent to every health plan was scanned back into the database enabling us to track what we sent.  I later created some PHP programs on an internal web site to review the status of the encounters for any health plan quickly.

This helped me to determine which encounters were sent to the state and which ones were held.  It also enabled me to write code into the encounters programs that would protect against sending duplicate claims.

The health plans were happy, but they also wanted to know why the claims were being held.  Fortunately, one programmer before me helped open the door to this.

Shortly after I started at US Script, one developer became frustrated with how long it was taking to run encounters for one health plan, and he began breaking the main cursor into separate cursors — one to pull the claim information, another for the physician, another for the member, and so on.

I capitalized on this and began doing this to the other encounter programs as well.   In addition to speeding things up, this change made it possible to track and log errors for every unsubmitted claim.  Furthermore, it became trivial to create a list of claims to correct or submit or resubmit.

Physicians Anonymous

We had tremendous difficulty resolving the issue of what to do with claims that were adjudicated with our system with one ID for a physician while we were required to deliver another ID.  What often happened was that a health plan would require a DEA, Tax ID, State License, or Medicaid ID for a physician at adjudication time but would later require an NPI in the encounter file.

I created a couple programs in Perl to log into the database and obtain a list of physicians that had outstanding claims for a given health plan but did not have an NPI.  The program would sort those physicians by decreasing claim count or billing amount and show the pharmacy information and the prescription number of the latest claim for that physician.

This was a great help to our call center enabling them to call the pharmacies and get the information on these physicians.  The only problem was that there were thousands of them for some of the plans.  And this seemed so unnecessary as there is a publicly available CMS database that has the NPI for every physician in the country.  But, that wasn’t the problem.  The problem was that we did not have a way of matching the physician records with the NPI to the physician records with another legacy ID.

Some physician records had two or three different kinds of IDs, and we were able to find matches for a few of those physicians, but a few thousand still remained.  Then my director noticed that one prescription number at a pharmacy may have multiple fillings, some of which may have one ID while another filling of that same prescription would come through with an NPI.  Also, in some situations, different claims for different prescriptions for the same member can be matched on the first six digits of the GPI code, especially where there are an overwhelming number of matches by multiple members and few or no matches to any other physician NPI or where the last name also matches.

With this kind of matching, we were able to identify all but about 150 physicians out of a few thousand unidentified physicians leaving a very small number of calls for our call center folks to make and greatly reducing the number of outstanding and uncorrected claims for that health plan.

I am now the senior developer of a team of three with a manager who shelters us taking on the communications and resolution of conflicting priorities with the health plans, and we are working on the architecture of the next version of pharmacy encounters.  I am confident that the other two developers are very highly skilled and would be able to take over and bring these encounters to the next level if I were to move on into another position.  And that’s a good feeling.