• dnm (unregistered)

    Canadian law stipulates that nobody can make you hand over your SIN if you don't want to, except the government, and an employer.

  • Will (unregistered) in reply to Josh
    Josh:
    I had a similar problem with my daughter - she was born on Jan. 1. We've come across THREE separate software systems that reject Jan. 1 as a valid birth date. I can't POSSIBLY imagine how that got in there.

    My girlfriend's sisters are twins, born on January 1st. Doubly screwed, I suppose.

    captcha: doom. Doom on them ever moving to Canada, evidently.

  • wiregoat (unregistered) in reply to WIldpeaks
    WIldpeaks:
    Jim:
    No testing for twins, triplets etc eh?
    The application must have been made by programmers without a life

    Without one specific aspect of a life, anyway.

  • (cs)

    Crap, I have triplets born on Jan 1.

    Their name are True, False, and File Not Found.

    I can't get them insured anywhere!

  • Look at me! I'm on the internets! (unregistered)

    Still on hold. I think they have one agent answering the phone for the entire province.

  • nobody (unregistered) in reply to DamnedYankee
    DamnedYankee:
    Don't worry, the real WTF will come when he actually tries to make a claim !

    Ah, no. He just have 9 wives.

    Captcha: pirates - yes, only pirates have that many wives.

  • (cs) in reply to skippy
    skippy:
    chris:
    Jerim:
    Maybe I am crazy, but wouldn't using the SSN be the most glaringly obvious choice? It is unique for every American citizen.
    Except this is a problem in Canada. Do Canadians have something equivalent to a SSN?

    Oh course we do! It's a Social Insurance Number (SIN). Why they don't use it is anybody's guess, but sometimes people are always walking on eggshells being worried about the privacy implications of storing that number. In this case, it's completely stupid cause they require it anyway. sigh

    Your SIN should only be given to:

    1. Your employer.
    2. The government.

    And NOBODY ELSE. Other people will ask for it, but only those two people are entitled to ask for it. (If I remember correctly.) You college shouldn't get it. Your credit card companies shouldn't get it.

    But this isn't the point. What the system should do is have a 32-bit number as the primary key for their client database. When you start up a new client file, they get an automatically generated number. That number is by definition unique. The rest of the data - birthdate, name, gender, conditions, are supplementary data. If you want to get a report of some kind that looks at other fields, then you could query the database. (I know this, and all I know about DB work I learned from TDWTF)

    By the time they end up with more than 4 billion people using their system, the system will be completely archaic.

  • G Money (unregistered)

    I'm suspicious. It seems that husband and wife who share the same last name who happened to be born in the same month would be just as (if not more) common than twins.

  • Jimbo (unregistered)

    Someone needs to teach these coders about the birds and the bees.

  • Look at me! I'm on the internets! (unregistered)

    Woo! The phone rang. Then the voice came on and said "Wait times can exceed 10 minutes"

    Did I just jump from the moron queue to the idiot queue?

  • Look at me! I'm on the internets! (unregistered) in reply to Look at me! I'm on the internets!
    Look at me! I'm on the internets!:
    Woo! The phone rang. Then the voice came on and said "Wait times can exceed 10 minutes"

    Did I just jump from the moron queue to the idiot queue?

    And the hold music has changed from "Nutcracker Suite" to light jazz.

  • (cs) in reply to oh geez
    oh geez:
    This story is completly BS. I used to be a developer at Sun Life Canada, and this was never an issue (unless if it happened within the last year, or a very long time ago). They have an excellent source control prosses, as well as many development and test servers. Any single change had to go threw a large change request approval system Unless this story is referring to another Financial company (which I can't see why it would because why would you harm one companies reputation for the sake of anothers) I call it BS. Sunlife has Millions of customers across the World, with Im sure many "Twins" on the same plan. How exactly would the old data (that would of had Twins in it) exactly make it into the new System?

    So unless this story happened many years ago, I call BS on this wtf, either that or the CSR was new and absolutly had no idea how to use the system (very possible)

    Now while this story is indeed interesting, after reading it it makes me question the integrity of every other WTF posted.

    "It turns out that a new version of their software was installed that tracked each person's budget based on their last name, plan number, and month/year of birth. Hence, having two people born in the same month and year on one plan would cause all claims to be booked against one of the two's budget, risking a premature budget exhaustion. "

  • craaazy (unregistered)

    This is why I'm planning to name my kids {9FCAF0A2-ACA0-11DB-8059-D4BD55D89593} and {443aa11b-7973-45f0-ac4a-8e0f1e0169ec}

    captcha: craaazy

  • (cs) in reply to deadlock
    deadlock:
    oh geez:
    This story is completly BS. I used to be a developer at Sun Life Canada, and this was never an issue (unless if it happened within the last year, or a very long time ago). They have an excellent source control prosses, as well as many development and test servers. Any single change had to go threw a large change request approval system Unless this story is referring to another Financial company (which I can't see why it would because why would you harm one companies reputation for the sake of anothers) I call it BS. Sunlife has Millions of customers across the World, with Im sure many "Twins" on the same plan. How exactly would the old data (that would of had Twins in it) exactly make it into the new System?

    So unless this story happened many years ago, I call BS on this wtf, either that or the CSR was new and absolutly had no idea how to use the system (very possible)

    Now while this story is indeed interesting, after reading it it makes me question the integrity of every other WTF posted.

    "It turns out that a new version of their software was installed that tracked each person's budget based on their last name, plan number, and month/year of birth. Hence, having two people born in the same month and year on one plan would cause all claims to be booked against one of the two's budget, risking a premature budget exhaustion. "

    So yes a recent update. No, the operator wasn't an idiot, she understood the problem. No, historical data did not get hosed during import.

    The problem is not that the system wouldn't inherently allow these kinds of duplicates, but rather that the system would apply all claims for each to only one, cause a "premature budget exhaustion." The operator really was trying to be helpful. All the old data that went in with these kinds of duplicates are just waiting for the budget to run out.

  • Rich (unregistered) in reply to Jerim
    Jerim:
    Maybe I am crazy, but wouldn't using the SSN be the most glaringly obvious choice? It is unique for every American citizen. That way, you could have as many John Smiths born on 4/15/1970 as you wanted, their SSN would tell them apart. I just don't understand why that wasn't the obvious choice when developing the software.

    (I understand with babies it may take a while to get the SSN, but certainly the insurance company can wait a little while.)

    Firstly, it it is actually not unique (and that has caused problems) and secondly there are laws against requiring it for identification (often ignored) for most things.

    Rich

  • Look at me! I'm on the internets! (unregistered) in reply to Look at me! I'm on the internets!
    Look at me! I'm on the internets!:
    Look at me! I'm on the internets!:
    Woo! The phone rang. Then the voice came on and said "Wait times can exceed 10 minutes"

    Did I just jump from the moron queue to the idiot queue?

    And the hold music has changed from "Nutcracker Suite" to light jazz.

    Woo Hoo! Humanity.
    Cert was issued in December. Returned by courier. Will re-issue.

  • charles bretana (unregistered) in reply to KattMan

    I might be wrong, but I'd wager this issue was caused by some purist dba who believes every database table key must be 'meaningful', (consisting of multiple real-world data attributes), rather than 'non-meaningful', (like a single self-generating integral attribute).

  • facetious (unregistered) in reply to oh geez
    oh geez:
    I used to be a developer at Sun Life Canada. ... They have an excellent source control prosses, ... Any single change had to go threw a large ... How exactly would the old data (that would of had Twins in it) exactly make ... either that or the CSR was new and absolutly had no idea how to ...

    If your development had as many errors as your writing, I wouldn't be surprised. I chose to only highlight the most obvious mistakes and leave the numerous other grammatical ones alone.

  • Rich (unregistered) in reply to AirMan
    AirMan:
    Okay, so which one of us is older? We were both born on the same day and year!

    What time of day? Or doesn't that count?

  • (cs) in reply to KattMan

    The problem with this system is much more complicated than we realize.

    Reading it carefully, you could put twins in the system, and they will show up as different people and records, so there is a more stringent key used internally to separate these.

    The problem comes from the fact that this key is normally not used by the users. You enter the persons last name, month and year of birth and expect to get a single record. This search perhaps returns only one, it should return a list showing first names and other info to narrow this list.

    Secondly, when a claim gets sent you maybe get only the plan number which is the same for all members on that plan and the last name, month and year of birth. Since claim processing is first done by an automated process it links on the first match.

    How to solve all these layers of issues is a huge challenge in an old process.

    Just goes to show, you can read this and find so many more WTF's you never thought of and explains some of the experiences of people here when dealing with any insurance company.

  • charles bretana (unregistered) in reply to Jerim

    Actually not, SSNs are reused...

  • (cs)

    To quote South Park, "blame Canada."

  • (cs)

    Um. Why a MONTH apart instead of a day?

    I can't wait til they claim fraud or deny benefits in a few years when a claim is made and the birthdates don't match.

  • (cs) in reply to Rich
    Rich:
    AirMan:
    Okay, so which one of us is older? We were both born on the same day and year!

    What time of day? Or doesn't that count?

    And don't forget to standardize your birth time and your current time to UTC.

  • MadCow42 (unregistered) in reply to Sean
    Sean:
    tharfagreinir:
    Where I live (Iceland) everyone gets a unique id assigned to them at birth that lives forever in a national registry. This is used practially in every computer system where you need to ensure that you can identify people uniquely.

    Gotta love Big Brother.

    Actually you have to admit that would make our jobs as programmers much less complicated in many cases. If the United States just automatically assigned a social security number at birth it would be practically the same thing.

    That's always nice, until a foreigner moves to town after their birth. :) How about temporary workers with (or heck, without) permits?

    Kevin.

  • (cs) in reply to unklegwar
    unklegwar:
    Um. Why a MONTH apart instead of a day?

    I can't wait til they claim fraud or deny benefits in a few years when a claim is made and the birthdates don't match.

    If you read carefully the only values used are last name, month and year. They only way to make these records look different is to put them a month apart.

    Still even if day was added to the mix, it doesn't solve the problem, it only makes it more granular.

  • The OLD Geek (unregistered) in reply to grg
    grg:
    That is a problem. My insurance agent by pure chance had two clients with the same (and unusual) first and last names, and identical birthdates. Their computer kept denying one of them coverage because the other one had already had that operation.

    heee. All through grade school, I had these 2 cousins in my class. Seems neither father had talked with the other RE Names. Their wife's gave birth the same day, and they named their daughters after the same person. Yep, same first MIDDLE and last names, and birthdate. Always caused "fun" the first day of school "FN?" "Which one?" "FN, LN?" "Which one?" (slight exasperated tone of voice "FN,MN,LN?" "which one?" (VERY exasperated tone of voice) "The one born on MM/DD!" "Which one?" (sound of teacher banging head on desk)

  • (cs) in reply to MadCow42
    MadCow42:
    Sean:
    tharfagreinir:
    Where I live (Iceland) everyone gets a unique id assigned to them at birth that lives forever in a national registry. This is used practially in every computer system where you need to ensure that you can identify people uniquely.

    Gotta love Big Brother.

    Actually you have to admit that would make our jobs as programmers much less complicated in many cases. If the United States just automatically assigned a social security number at birth it would be practically the same thing.

    That's always nice, until a foreigner moves to town after their birth. :) How about temporary workers with (or heck, without) permits?

    Kevin.

    Another example of why SSN's in the USA are not unique:

    We have all heard about the nice things our health care system does for other nations, we bring in the worse cases, do expensive procedures at no cost to them and let them go back home. Our military medical professionals also do this with foreign nationals that need our treatment.

    So the systems use SSN's to track people, but these people have no SSN. What do they use? Since they have no reason to apply for a real one, these system often use the 888 range of SSN's. These numbers are usually considered invalid and that is why they are used. These numbers are unique only within the system they were created in, so when someone gets transferred from a military hospital to a USA based hospital that number travels with them and can collide with another record currently in the system.

    This has happened many times before.

  • (cs) in reply to J Random Hacker
    J Random Hacker:
    tharfagreinir:
    Where I live (Iceland) everyone gets a unique id assigned to them at birth that lives forever in a national registry.
    And, of course, they may well have different last names, anyway.
    forever? Is that like 9-9-99 is an ok test date because it's so far off?
  • The OLD Geek (unregistered) in reply to pc
    pc:
    It's also not required to have an SSN in the U.S.

    Yeah, it is, and has been for at least a decade. They changed the rules - you MUST apply for an SSN at birth - in fact, at least in NY, the hospital is required to do it for you!

  • (cs) in reply to JohnMo
    JohnMo:
    My brother and I both had new baby girls join our families in 2005. Despite living hours apart and rarely speaking, we discovered during the pregnancies that we had chosen exactly the same first and middle names. We didn't really want them to have the same name and they were born two months apart, but we also thought that as rare as our last name is that they would be suspected of being duplicates in every computer system on the planet if one of us didn't choose a different name.

    Having wrangled with insurance companies many times, this kind of thing doesn't surprise me at all.

    Just curious, which one of you wound up changing the chosen name? The same thing happened to my mother and her cousin. My name is the one that wound up getting changed.

  • jweller (unregistered) in reply to Abscissa
    Abscissa:
    Driver's liscence numbers are unique (at least if you take into account the state - I'm not sure if there might be duplicates across state lines), but the obvious problem with those is that not everyone has a driver's liscence.

    well I think every state issues ID cards for those who do not drive, but that creates a whole other set of problems. At least in MD, I don't know about other states, your drivers license "number" always starts with the first letter of your last name. So when I got married a few years back, my wife got a new license, with a new number. Imagine the problems with telling an instiution that you now have a new ID number. I can only imagine that conversation

    captcha = craaazy - yes is is.

  • VC1 (unregistered) in reply to WIldpeaks
    WIldpeaks:
    Jim:
    No testing for twins, triplets etc eh?
    The application must have been made by programmers without a life

    By denying entry into the system, they don't have to pay the bills for expensive multi-births and the subsequent neonatal ICU costs.

  • (cs)

    Hm... here in Mexico, we have TWO unique keys issued.

    The first one, RFC, is only used for fiscal purposes. The second one, CURP, is a unique ID issued since birth (supposedly), and used by not only government dependencies but schools and such. It is intended to use it for fiscal purposes too, substituting RFC, but we still get slated with both of them.

    Oh, and not everyone has it, because CURP was implemented only 9 years ago.

    So many DB's used RFC, but a bunch of other newer apps use CURP as a primary key.

    Difference with SSN? Well, this one is actually made for ID purposes, so you're guaranteed have a unique one. Specially because of the format:

    Say, Jose Sanchez Segura (we use father, mother surnames here) was born in DF (Federal District) on Oct 31, 1980? SASJ801031HDFNGS01

    So that thing bundles up both surnames, firstname, DOB, sex, state where you were born, even more stuff from surname/firstname, and a number stuck to the end (to avoid collisions). Still, sometimes these are changed because of some rather humorous combinations:

    LOCA790103... (LOCA means "crazy woman") PUTO660303... (PUTO is "male prostitute" or "faggot" depending on context, both uses rude)

    Now that's some primary key!!!

  • freakshow (unregistered) in reply to facetious
    facetious:
    If your development had as many errors as your writing, I wouldn't be surprised. I chose to only highlight the most obvious mistakes and leave the numerous other grammatical ones alone.

    Thank you, facetious. As a certified grammar Nazi myself, I had a very difficult time reading that post.

  • (cs) in reply to Otto
    Otto:
    Jerim:
    Maybe I am crazy, but wouldn't using the SSN be the most glaringly obvious choice? It is unique for every American citizen.
    Problems with this: - SSNs are not unique. Really. - SSNs are not required. Many people don't have one. - Some state and federal laws make it specifically illegal to use SSNs in the manner you're describing. Identity theft issues.

    The correct way would be for the insurance company to create a unique in-house ID number for every person that they are insuring, and to use that instead. The ID number would be global across their entire system.

    A lot of database people think that a primary key should always be composed of "natural data" and not to have unique ID number columns. This is an example of why they are wrong, because there is no set of natural data that will always uniquely identify individual people.

    In the US you have to have a SSN to do almost anything. Get a job, got to school, etc. It is how the government knows if you are the John Smith it is looking for, other than fingerprints. Especially for Insurance purposes, how could they ever prove that you are the John Smith that has a policy with them. Every John Smith in the country could file a claim with them and they have no way to telling.

    I think SSN is a key component in identify theft. You use it to prove who you are and it eliminates a lot of identity theft. You don't withold it so no one copies it. That is like burning your fingerprints off because someone might lift them off a glass bottle and use them. However, now you have no way of proving you are who you really are. You aren't giving your SSN out to a total stranger, you are giving it to a company where its usage can be traced. A criminal can get your unique ID giving to you by a company, just as easily as your SSN.

  • AnonymousCoward (unregistered) in reply to themagni
    themagni:
    skippy:
    chris:
    Jerim:
    Maybe I am crazy, but wouldn't using the SSN be the most glaringly obvious choice? It is unique for every American citizen.
    Except this is a problem in Canada. Do Canadians have something equivalent to a SSN?

    Oh course we do! It's a Social Insurance Number (SIN). Why they don't use it is anybody's guess, but sometimes people are always walking on eggshells being worried about the privacy implications of storing that number. In this case, it's completely stupid cause they require it anyway. sigh

    Your SIN should only be given to:

    1. Your employer.
    2. The government.

    And NOBODY ELSE. Other people will ask for it, but only those two people are entitled to ask for it.

    ...snip...

    Not quite true. Certain organizations (largely financial institutions) need to report to the CRA (Canada Revenue Agency (previously known as the Canadian Customs and Revenue Agency (previously known as Revenue Canada))) - they need to report certain kinds of investment income, confirm RRSP contributions, etc.

    Your employer is just one of those organizations, for it needs to report that income, and also submit taxes to the government on your behalf.

    Your college may need to, so that it can correctly give you a tuition credit slip for your tax return. Not sure about that though.

  • (cs) in reply to Sprout
    Sprout:
    Sunlife does not require childrens names or birthdates. Liarface.

    ...with a similar contribution immediately above it.

    Welcome to the developers from Sun Life... sigh

  • (cs) in reply to AnonymousCoward
    AnonymousCoward:
    themagni:

    ..snip..

    Your SIN should only be given to:

    1. Your employer.
    2. The government.

    And NOBODY ELSE. Other people will ask for it, but only those two people are entitled to ask for it.

    ...snip...

    Not quite true. Certain organizations (largely financial institutions) need to report to the CRA (Canada Revenue Agency (previously known as the Canadian Customs and Revenue Agency (previously known as Revenue Canada))) - they need to report certain kinds of investment income, confirm RRSP contributions, etc.

    Your employer is just one of those organizations, for it needs to report that income, and also submit taxes to the government on your behalf.

    Your college may need to, so that it can correctly give you a tuition credit slip for your tax return. Not sure about that though.

    Yes, you're right and I'm wrong. You have to give them your SIN to get a T22A.

    I was thinking of what my college used to do - they just used your SIN as your student number.

    And then posted it when they posted your grades.

  • Big Vuda (unregistered) in reply to Kiss me, I'm Polish
    Kiss me:
    Hey! I'm your evil twin.

    Kiss my sweet dupa.

  • (cs) in reply to VC1
    VC1:
    WIldpeaks:
    Jim:
    No testing for twins, triplets etc eh?
    The application must have been made by programmers without a life

    By denying entry into the system, they don't have to pay the bills for expensive multi-births and the subsequent neonatal ICU costs.

    Read more carefully, they were not denying multi-births into the system, they let them in, it's just that all claims would be counted to a single "person" causes a "premature budget deficit." Still saves the agency money if they can deny claims with proof to back up the budget deficit.

    The person on the phone was actually trying to be helpful by not letting the so called duplicate happen. She probably got reprimanded by her boss and demoted to duplicate claims processor.

  • Macgyver (unregistered)

    What about when some insurance security bottom-fee... consultant comes in an runs a set of queries designed to detect false entries?

    Two children, born one month apart to the same father and mother will likely get a hit.

    Captcha:quake... REPEAT!

  • the bob (unregistered) in reply to Josh

    It's easy to understand why an application would challenge (but not reject) a Jan 1 birthday -- that's the easiest and most common day to enter when you don't have a clue what the true birthday really is, so it's frequently bogus. You see it a lot in data sets.

  • waefafw (unregistered) in reply to dnm
    dnm:
    Canadian law stipulates that nobody can make you hand over your SIN if you don't want to, except the government, and an employer.

    Yes. And it still astounds me how many places ask for it anyways. I politely tell them they don't get the privilege of knowing my SIN #. I haven't had any grief yet from doing this.

  • (cs) in reply to waefafw
    waefafw:
    dnm:
    Canadian law stipulates that nobody can make you hand over your SIN if you don't want to, except the government, and an employer.

    Yes. And it still astounds me how many places ask for it anyways. I politely tell them they don't get the privilege of knowing my SIN #. I haven't had any grief yet from doing this.

    <sarcasm> Jeesh, those Canadians. Always SINning vigorously. </sarcasm>
  • JohnB (unregistered) in reply to skippy

    SIN is required for only a limited number of transactions -- generally ... but not exclusively ... anything of interest to the Canada Revenue Agency, passport issues and a few others.

    Just because you are often asked to supply it, doesn't mean you must always supply it.

  • (cs) in reply to craaazy
    craaazy:
    This is why I'm planning to name my kids {9FCAF0A2-ACA0-11DB-8059-D4BD55D89593} and {443aa11b-7973-45f0-ac4a-8e0f1e0169ec}
    Cool, my oldest daughter's name is {9FCAF0A2-ACA0-11DB-8059-D4BD55D89593}! And we were going to name the next baby {443aa11b-7973-45f0-ac4a-8e0f1e0169ec}, but it was a girl and we didn't want her to get teased for having a boy's name.
  • bah (unregistered)

    It's not even twins or triplets that would cause this problem; my brother and his wife have the same birthday!

  • Remco G (unregistered) in reply to Josh
    Josh:
    I had a similar problem with my daughter - she was born on Jan. 1. We've come across THREE separate software systems that reject Jan. 1 as a valid birth date. I can't POSSIBLY imagine how that got in there.
    My girlfriend was born on 1/1/1970. Surprisingly, she says she can't remember being refused by a computer system.

    She did like it when I told her much of the Internet tracks the time by the number of seconds since her birth day :-)

  • (cs) in reply to oh geez
    oh geez:
    This story is completly BS. I used to be a developer at Sun Life Canada, and this was never an issue (unless if it happened within the last year, or a very long time ago). They have an excellent source control prosses, as well as many development and test servers. Any single change had to go threw a large change request approval system Unless this story is referring to another Financial company (which I can't see why it would because why would you harm one companies reputation for the sake of anothers) I call it BS. Sunlife has Millions of customers across the World, with Im sure many "Twins" on the same plan. How exactly would the old data (that would of had Twins in it) exactly make it into the new System?

    So unless this story happened many years ago, I call BS on this wtf, either that or the CSR was new and absolutly had no idea how to use the system (very possible)

    Now while this story is indeed interesting, after reading it it makes me question the integrity of every other WTF posted.

    Alex anonymises these. It most likely didn't happen at Sun Life Canada. Alex may even have made up the company name not realise it collided with a real one.

Leave a comment on “Disjoint Twins”

Log In or post as a guest

Replying to comment #:

« Return to Article