Another Hell Of A Week Today...

Yet another Monday this week, and one hell of a week, today.

There are many days where things cross my desk and I think "wouldn't that make a great post..."  Nope.  There is no one standing over my shoulder monitoring what I think, do, or write here, so it's all my responsibility.  And frankly, I don't think I'd want anyone to read a third-party version of any of my rather stupid human tricks which end me up in the hospital.

Today was a very busy not very good day.  There are some things I can share that don't infringe on anyone's privacy except for a software implementation person who has experienced an air-gap between brain and...  well, output.

Very briefly - the job I do is to ask insurance companies that you pay if they will consider paying my employer for the services we provide you - that you being someone who has recently had a less-than-optimal outcome encounter with some form of germ that has caused them to get pretty terribly sick.  Sick enough, as I was several times over the years, to require time in the hospital, expensive tests, and the discovery that while, yes, there may be brains between my ears, they don't always provide me the best advice. 

Mind you, most of the folks I see are much smarter than I was, so there is that.  I mean, I see people with symptom onsets which are typically under a week before they seek professional help.  First time I landed my butt in the hospital, things started feeling unwell about two months before I finally said something.  Second time I only waited a month.

But back to the point - my job consists of taking those prescriptions a doctor writes and translating them into, well, codes.  That is, the patient is typically getting some sort of medication to combat something that went wrong - or sometimes it's to deal with symptoms that another therapy is causing.  Things like dehydration and malnourishment while getting chemotherapy...  Ya know.  Stuff like that.  

But the job consists of finding the medication on a list, which tells me three things.  First is the code for the drug.  Second is the type of therapy it is.  The third is the "unit size" for that medication.  

Let's take a popular one that I did not see today.  A medication called Meropenem.  That's an antibiotic.  It gets used for treating infections.  It has a code, J2185.  Every dose that is delivered is calculated in units of 100 milligrams.  That is, if the dose is 500 milligrams three times a day, that means that the patient is receiving 5 units per dose, 3 times a day means 15 units a day.  Let's say the doctor says that should last for 30 days - that means I have to ask your insurance company if they'll consider paying us for 450 units of J2185, another 30 units of S9502, and ... well, I know, I skipped something.

S9502 is the code for what is often called "DME".  The D can vary depending on the insurer and the position of Jupiter.  One definition for D is "Durable" - that's stuff you use for a while.  Another definition is "Disposable".  Stuff you use once.  Welcome to the Medical Authorization Field.  But the critical thing here is that the S95 part usually will tell you it's an antibiotic, being delivered in a certain way (not by mouth), and the 02 is the tricksy bit.  If it was S9500, most insurers would know that's once a day.  S9501 is Twice a day - every 12 hours.  S9502 is every 8 hours, which should work out to 3 times a day.  S9503 would be every 6 hours, S9504 is - you got it, every 4.  S9505 is usually - nope - every 3.  Yep.  And that's only for some companies.  Others have their own definitions.  Some use another code because it makes no difference to them how often the patient is getting the drug, they only pay X every day, if it's one dose or twelve.  

BUT then there's more fun.  Every insurance company out there has their own rules.  That DME code will include some things for some, other things for others.  Most commonly, there are additional things that come along when we do our thing.  Some companies include these things in that DME code.  Some include some.  Some include none of it.  So where one insurance company may only require two codes for that service, others may need me to request six.  

So there's the complex part of the job.  We have a pretty fancy, spiffy system that permits us to track what's going on, what's approved, what needs to be approved, and most importantly, what we may need to get more of because the stuff isn't working as fast as the doctor has ordered.  Because while I may be somewhat in awe of doctors and nurses, I am also well acquainted with the old adage that no plan survives contact with the enemy.  Works on a battlefield and in the human body when germs are involved.  The reason I am not a medical professional is because I do not understand the value of a proportionate response.  If there's a snake right in front of me, I am fully in favor of nuking the snake.  Yes, I am aware that I shall also fail to survive the nuke, but the snake will be done.

So anyway, back to the point - I ask insurance companies to approve the consideration that certain things may actually - at the time I'm asking - make a fair amount of medical sense, so they'll consider paying for it when the bill comes.  An awful lot of wiggle room, that's the world I now live in.  

But there are some codes that are pretty microscopic.  There are some medications that have unit sizes of one milligram, some of one microgram - and that's only in the basic stuff I do, which is basically a lot of things you NEVER see advertised on TV.  If you see an ad for it, the odds are very highly stacked against me ever seeing anything to do with it.  Smarter people do that stuff.  

But there are also codes that are defined by time, as I noted above.  There are codes that determine how many times a day you get a medication.  There are also codes that define the rental of an expensive device for a period of time.  Some of these devices are rented for a week or month at a time.  Which is where we come to today's flashback problem.  

A patient needed a piece of equipment for a while.  Not in this case, but I'll call it six months.  And our system knows that the particular code, which I'll call X1, is good for 30 days.  It tells me that.  But the accounting back end of our system somehow became disconnected from the part that tells me 30 days, because for my example patient it was charging the wrong amount.  Instead of charging 1 unit X1 every 30 days, or even 0.033333 units ever day (0.03333, continuing for a lot longer, is what one is when divided by 30 days), our system went gonzo and decided to charge one unit per day.

So when I got approval for six months, and entered it into our system back last January, we had approval which should have run from January 1 through June 28, that being 180 days after January 1 this year.  Normally, it's June 29 when it's not a leap year, but, well, leap year.  So anyway, what seems to have happened in our system is that the first month charged properly - after the first 30 days, it charged one unit every day.  

So I had to explain this to my boss, with charts and screen shots, and then sit down at the end of the group W bench...  No, there's no Group W bench, I just got back to work.  But then the issue became with the reporting system - I could only report the sort of problem that someone expected we would have - not the sort of problem we were having that was NOT what was expected to have.  

So there's the fun nugget from today.  I have a problem with a software variable that got changed, it was not expected to change, there's no one I can report the issue to because, well, the problem is not expected.  

Wait a minute, isn't that the very definition of a bug?  I dunno.   My 20 years in IT covering help desks, various hardware and software systems, well, I can tell you that when I picked up the phone and someone said "I have a problem" I learned pretty damned quick that while the hundreds of problems I solved may give me a leg up on solving the next one, there was absolutely no guarantee that EVERY problem had a straightforward solution.  

No, I shan't whip out a hundred stories of problems solved.  I will, however, point out that my trusty four troubleshooting rules remain extremely useful.  Once again - 

1) is it plugged in?

2) Is it turned on?

3) is it spelled right?

4) ARE YOU SURE?

Number four being the one that has solved many a problem.  In this case, while spelling is not likely the issue, I expect the core is probably a mistake made by someone who was absolutely certain of their configuration experience, and was positive that X1 was a one-unit-per-day code like all those others.  

It's a resolvable issue.  We know about it, we can tell our people that it can be over-ridden.  We do not have that authority, because we do not need it.  Others do, we just need to explain why they need to use it.  And my supervisors do value my insight and input, and I'm one of the few who are asked to take on the Yeti of gatekeeping to sneak past and make sense to someone who can make things happen.  It also helps they lend their considerable experience, knowledge, and their faith in me which is far outweighed by the other stuff to push my discovery off in the right direction.

Who ever would have believed 20 years in IT would be useful elsewhere?  Well, a lot of folks who passed on my resume all those years ago, but I am thankful they did so I have the opportunities I have today.  See?  It's not all bad.  It's just a simple equation - you can grease the squeaky things, sand the rough things, and apply duct tape to things that move but should not.  Hopefully I'm not duct-taped to the keyboard in the near future...