health insurance: what is happening?

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I work for a physician. Every month we receive a list of active patients from the insurance companies. Yesterday we received a list for August 1999 from a nationwide insurer. They listed a patient that died over three years ago. Resurected? Since February we have been receiving some of the payments from another nationwide insurance company addressed as: "Jane Doe, MD AVAILABLE FOR LATER USE City, State and Zip Code Fortunately we are located in a small town, the doctor is well known, and the Post Office put the letter in the doctor office box. This happens in one out of about twenty. We notified all of the insurance branches in February and again in May. Last month, July 1999, it happened again. Can't understand why this glitch keeps repeating. To address a woman as "available for later use" is a slap in the face! Will these insurance companies be there for us next year? luise

-- Aster (cimbri1@aol.com), August 12, 1999

Answers

Interesting.

"Available for later use" sounds like a field descriptor for a field in a file layout.

Do you file claims electronically?

I may be able to help here.....what state are you in?

As to the "resurrect", I'm pondering that one.

-- lisa (lisa@work.now), August 12, 1999.


Sounds like "AVAIL..." is dummy data "string" inserted into the street address field. Worst case would be ALL street address field data (for all addressees) to be replaced with that string. Backups anyone?

-- vbProg (vbProg@MicrosoftAndIntelSuck.com), August 12, 1999.

We do not file claims electronically yet. Wanted to wait due to Y2K. State is in the NW. Resurected patient: the street address was also changed to a prior address, not only for her but also for siblings. Ins. Co. excuse was that they posted the monthly updates from the employer. However employer would know that there was a demise over three years ago. Employer would also know that the street name was changed in remembrance, also street number was changed. Ins. already sent new insurance card to parents with the name of the little Angel. I think that there may be a glich in the software that reverts the data back to the old information that was deleted. I wonder how many many of these problems are occuring all over the country. We asked our front desk employees to verify all addresses as patients check in. aster

-- Aster (cimbri1@aol.com), August 12, 1999.

I wonder if someone "fixed" a bad case of The Nines by simply disabling all record expiration functions?

-- Ron Schwarz (rs@clubvb.com.delete.this), August 12, 1999.

Typical problem symptom .... it's happening.

I agree - this looks like it is "printing" a field description default, not the actual data. Was the "City, State, Zip" fields accurate for this pariticular woman? Was she an actual patient? Good SSN or medical ID number?

Curious timing: Feb, May, and now Aug. No rythme or reason to it, unless "second month of the quarter" causes a problem.

-- Robert A. Cook, PE (Kennesaw, GA) (cook.r@csaatl.com), August 12, 1999.



I do this stuff for a living... here's what a typical member file looks like.

Database: HEALTH.DATA.AIH TPI: Omnidex 3.04.11

MEMBER Detail Set# 153 Entry: Offset MEMBER# X12 1 (MEMBER-A) CONTRACT# X10 13 (!CONTRACT-A(MEMBER#)) ALT-KEY X12 23 (ALT-KEY-A) SSN X10 35 (SSN-A) AREA X2 45 CARD X2 47 FIRSTNAME X14 49 <> HCFA# X12 63 LASTNAME X14 75 <> LOCK X6 89 LR-RESPONSE X2 95 OP# X4 97 PERSON# X10 101 RECORD# X12 111 SEX X2 123 TITLE X4 125 TRANSCODE X2 129 YMDBIRTH X8 131 YMDCARD X8 139 YMDDEATH X8 147 YMDPREX X8 155 YMDPREXEND X8 163 YMDTRANS X8 171 YMDVERIFY X8 179 Capacity: 371000 (7) Entries: 294122 Highwater: 294122 Bytes: 186

Additional Third-Party Indexes: ALT-KEY-OCK X12 G

You'd think their eligibility file creation code would select where date-of-death EQ " "??

Still pondering.

-- lisa (lisa@work.now), August 12, 1999.


Once it was just a list of patients, subscriber of said Ins. Co.. Twice was a payment check. Dr. and insured data: date of service, ID #, names etc. were correct. It was only the P O Box that was omitted and in its place "AWAILALBLE FOR LATER USE" was printed. City, State and Zip Code were correct. This is a very small NW town were the doctors are well known. Thereby the reason that we received the mail. This ins. co. has branches everywhere in the country. We address our claims to the branches. The payments all come from one central office in PA. What I have been asking myself is, how come only one in about twenty each time was incorrect? Repeated failures? Will they be here for us and for our patients in 2000? Will these errors be permanently corrected, or are the computers going to default on and off? As for the "resurected" patient, I have no time to check the addressed of the other patients. Our receptionist will keep asking for confirmation of address every time that a patient checks in. Aster.

-- aster (cimbri1@aol.com), August 12, 1999.

Well, definitely the first thing to do is call the employer of the deceased and tell them they're sending bad data. If the employer is sending ineligibles (retired, terminated, deceased) to the ins. co, there likely is money still changing hands over these non-real members.

About the checks: call the PA office and ask to speak to the payables dept. and tell them the problem. Likely the computer staff is there at that office and can check out the program that writes the checks and/or labels.

I'm hoping the insurance companies will be there for you next year, but prepare for lots of delay and confusion, regardless. Good luck.

-- Lisa (lisa@work.now), August 12, 1999.


One more fun thing for programmers to look forward too. Handling all the "nixies" and resending people with addresses at CMRAs (Commercial Mail Receiving Agencies). Your friendly government postal monopoly (USPS) has "decreed" that all mail improperly addressed to CMRAs will be returned to sender. Only "properly" addressed items will be delivered. "properly" means having PMB (for "Private Mail Box") on a separate line above the street address.

An "improper" address would be:


   John Doe
   1234 Main St. #5  (or Suite 5 or Apt 5 or Box 5 or Drawer 5 ...)
   Klinton, AR  12345

A "proper" address would be (PMB ... has to be on a separate line)

   John Doe
   PMB 5
   1234 Main St.
   Klinton, AR  12345

This will create lots of fun for programmers -- having to add an extra address line for these, and integrate it with regular address formats, as well as whoever handles the returned mail.

YOUR government in action. EGTTTS (Everything government touches turns to shit).

-- A (A@AisA.com), August 13, 1999.


Moderation questions? read the FAQ