Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

SS Numbers

CVerk
2012-09-07
2013-04-06
  • CVerk
    CVerk
    2012-09-07

    We checked around at all the people we interacted with, labs, insurance etc. and found that none of them are using social security numbers to identify patients any longer, except for patients medicare ID is still their social security number.  So we deleted them from our database as a security issue.  The problem is that you can't make that field unused in demographics or demographics doesn't work.  If you leave the field blank and in insurance, if they have a different family member as the primary insured, it won't let you save information because the primary insured and the patients social security number are now the same (blank). Does anybody see why social security numbers couldn't be more elective.  They just seemed to me to have become a dangerous piece of information to leave in your database if they are no longer needed for billing etc.

     
  • Tony McCormick
    Tony McCormick
    2012-09-07

    This is very true and is really a bug that needs to be fixed.  Cverk, can you open a tracker bug on this please.
    -Tony

     
  • David
    David
    2012-09-07

    As a workaround you could simply put a space in the demographic ssn entries.  That's what we do.

     
  • CVerk
    CVerk
    2012-11-07

    Putting a space in only works temporarily for the current session.  If you come back later it won't let you save it again.

     
  • Tony McCormick
    Tony McCormick
    2012-11-07

    This issue really needs to be fixed.   SS# should be not just optional but easy to hide, including the new Patient->Patients search column.

    MI2 will pay a $250.00 bounty to the fix developer that gets an acceptable solution committed to the base project.

    Tony
    www.mi-squared.com / @tonymi2
    oemr.org / @OEMR_org

     
  • Tony McCormick
    Tony McCormick
    2012-11-07

    I really wish this forum had edit….
      I meant 'First Developer' but fix developer might be a good title…
    -Tony

     
  • Kevin Yeh
    Kevin Yeh
    2012-12-19

    https://github.com/yehster/openemr/commit/6684dcb7e6bbf0c67571bfc7e0f6714043194c7b
    I've fixed the problem with "blank" social security numbers when subscriber is other than "Self". I added javascript that confirms that the SSNs are actually valid before worrying about if the are the same or not.

    In addition, by explicitly testing for the existence of form_ss before trying to use it, the demographics form still works even if you remove SS from layout_options.

    Tony, please take a look and let me know if you find this solution "acceptable."  If so I can commit to the base project and we can arrange collection of the bug bounty.

     
  • Rod Roark
    Rod Roark
    2012-12-19

    Field-specific GUI coding for layout items should be avoided. Instead, define a new "Options" symbol (to go into layout_options.edit_options) which, when present, will cause validation and/or input enforcement of US-style social security numbers. That is the kind of thing the edit options are for.

    By the way ss and other fields that are originally provided should never be removed from the layout. Things may break. Instead, mark them as Unused. I consider the ability to remove them a bug.

    Rod
    www.sunsetsystems.com

     
  • Rod Roark
    Rod Roark
    2012-12-19

    I typed too soon, just realized this thread is not about input validation of SSNs.  However my second comment is definitely relevant to this thread.

    Rod
    www.sunsetsystems.com

     
  • Kevin Yeh
    Kevin Yeh
    2012-12-19

    https://github.com/openemr/openemr/blame/master/interface/patient_file/summary/demographics_full.php#L123
    Rod, All this "field specific" GUI coding was originally your contribution. 
    The fundamental problem isn't validation of a single field value that can be done with edit options.  I am changing the behavior of existing javascript that you hard coded into the form.

    I'm not enforcing that only a valid SSN is permissible.  What I am doing is that before preventing the user from saving because  "Subscriber relationship is self but SS number is different" the values being compared are in fact (or at least look like) SS#.

     
  • Kevin Yeh
    Kevin Yeh
    2012-12-19

    I did find a mistake in my commit. so that the original validation is actually never happening right now, but I still think this is the correct way to do things.

     
  • Kevin Yeh
    Kevin Yeh
    2012-12-19

    Ok… having a hard time getting the right stuff into github… Last commit included some other changes in:
    interface/new/new_comprehensive.php
    That aren't part of this fix…

     
  • Tony McCormick
    Tony McCormick
    2012-12-19

    I'll check it out this evening when it's gets quiet around here..
    -Tony

     
  • Kevin Yeh
    Kevin Yeh
    2012-12-19

    https://github.com/yehster/openemr/commit/912765f00efa282199999e7c4f000bc8f15ad865
    Here is the final (hopefully) version of this fix.
    In addition being more conservative about when to throw the 'Subscriber relationship is not self but SS number is the same!' error message, I also made it so that you can now override the warning if it's "really OK?"

    I believe that it is better to warn and allow such a conflict in case as Brady mentioned someone international is using this field for something other than SS#. Since he can still change his mind about it later.  Where as the original approach of just alerting and preventing is less flexible.

    All that said.  Leaving the SS# fields blank, or hiding them in layout options should work fine now.

     
  • mborchorst
    mborchorst
    2012-12-19

    Just as an aside.. We use the SS# for the danish "CPR" or "sygesikringsnummer" which nicely fits the SS name but most likely with a different validation scheme.

    /Morten

     
  • Kevin Yeh
    Kevin Yeh
    2012-12-19

    Here is the complete branch with a couple updates for translation/escaping issues.

    https://github.com/yehster/openemr/tree/ss_insurance_validation_fix

    We are adding a new function xls() to htmlspecialchars which is appropriate for translating strings that are to be used within javascript code.  Once this gets to the master branch, I'll update the code base security page wiki. This should be the preferred method of escaping javascript literals in the future to improve code readability.

    When using the fields for "sygesikringsnummer" if it doesn't match SS# format exactly 9 digits (123-45-7689) either with or without dashes (123456789) what will happen is that the warnings:

    'Subscriber relationship is self but SS number is different!'

    'Subscriber relationship is not self but SS number is the same!

    will never appear. 

     
  • Tony McCormick
    Tony McCormick
    2012-12-21

    This looks good to me and tested fine in my tests.  Commit it and the bounty is yours :-)
    -Tony