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.
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.
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.
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#.
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.
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…
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.
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.
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!
