I have an SQL file that will create the guarantor tab in the demographics layout and fields in patient data file. I have some changes to demographics.php and Globals as well as some other programs. This post is for discussion. I know the first push back is going to be adding this to the patient_data table. Why? Is there a limit in MYSQL as to the number of columns or what is the reason for not doing it this way. I need to understand what the community wants/needs. I was told that in previous versions the adding of fields thru the layout function to the patient data table caused some problems, this was because the fields were defined as varchr(255), that has been changed to text and there are no reports of the problem occurring since that change. The lacking of a guarantor to patient relationship is one of the first hurdles that needs to be over come in order to move OpenEMR toward a full practice management system.
I have asked for guidance from the community on a number of projects and have received feedback and I appreciate those who have helped… I know there are more developers out there that can and should have input as to the direction of this opensource project. Voice your suggestions and requests during the development of the projects or be content with the outcome.
A guarantor tab is useful for Pediatric patients who parents are divorced or for aging patients whose children have power of attorney. It’s a good idea to have it as a Demographic tab because most patients are their own guarantors, thus this tab will not be needed for the majority of patients.
The technical aspect of setting up the tab may be less difficult than getting divorced parents to agree regarding guarantorship. In the case of Geriatric patients, there is rarely a dispute as to the responsible party.
Adding to patient_data should not be a big deal. It’s mainly name, address, phone number & Social Security number (for collection, if need be).
In the case of Pediatric patients, most of the data would be in Insurance. In both cases the Patient Statement needs to be mailed to the guarantor.
Was the original intent of making the demographics layout based to make it easier for the user to add / remove fields? Does the entire layout usage for all the demographics data need to be re-evaluated? Would it be more advantageous to move the other tabs to their own tables or just some of the data?
Gathering the amount of demographic information has changed very little over the past 3 decades.
It’s AR & meeting governmental mandates that are filling up hard disk space.
Not likely that the feds would be interested in who is paying the bills, if not the patient; therefore a separate table would probably not enter into the equation for MU calculations.
The insurers know who is the subscriber & if the insured is not a policy holder, they would have no interest in the guarantor.
I would not add a separate table for guarantors, or for any particular tab. What would make sense is a separate “vertical” table similar to lbf_data (used for layout-based encounter forms).
This could be done as a complete replacement for patient_data (a lot of work), but to be more realistic as a complementary table just for user-added or future fields (not so much work). In that case patient_data can be pared to those “core” fields used by existing functionality that is hard-coded to reference them.
Vertical tables are very flexible and help to separate layout from database structure. They can also be space-efficient since empty values can be omitted.
Part of this work might be creating a PHP object model for patient data.
A vertical table for additional patient data is also a very reasonable approach. More complex than the separate gurantor table, but ultimately very powerful.
Also note that for a general practice, guarantors will often also be patients, and could be implemented as rows in the patient_data table. Two additional columns would be needed in patient_data: an indicator of whether the row is for a patient, and a guarantor value that is an optional pid value of the patient’s guarantor.
A similar approach could support other patient relationships: spouse, mother, guardian etc.
Terry can you explain a bit more? Looks like you have a field to indicate if guarantor or patient, but you also have separate guarantor fields for name, DOB, address etc.
I used the Patient/Guarantor field to search for a Guarantor , the search program is a modified version of the find patient. If it has Guarantor or Both I bring those records up when looking for a Guarantor record and use the record to populate the Guarantor information. I use the Name, DOB , SS , relationship to patient, PID and address for the Guarantor .
The way I am doing it is by no means correct or the most efficient, it is a way.
Think about this scenario , you have a student away at college “Patient”, Parents are divorced , Mother is the “Guarantor” financially responsible and the Father carries the insurance “Subscriber”
Yeah, offhand I think the best approach that’s not a ton of work is to implement guarantors as patients per my 2nd post in this thread. Thinking about it some more, instead of a guarantor column you could create a table of patient relationships: pid1, pid2, type_of_relationship.
If one parent has the financial wherewithal to be the guarantor, chances are good that (s)he is also the insured. (S)he usually makes more money & does not need the aggravation of dealing with the ex.
Never seen above scenario for medical bills in the court documents of our patients.
Allowing generic many-to-many relationships between records in the patient_data table through a relationships table can be very powerful…
It would make things like two fathers or two mothers simpler.
There is the potential for “strangeness” like occurs with referring physicians currently if one of the related entities isn’t strictly a patient, but it probably wouldn’t be so bad.
We use the “link to another patient_data record” currently for some of our clients. It works well, just 1-1 though, I like the vertical table model in the long run with support for many-to-many relationships.
The gotcha, is that it’s make reporting/query’s tricky for those whose SQL-foo is not well oiled.
Note: this feature is needed by clients that do work for the elderly. Even if, legally, they are responsible, frequenltly they are not able to handle their own bills and designate a family member for that.
Yes, a vertical table, and yes, a globals config.
Give thought to being able to use a “people” table, with those persons listed having link-ups. We use a sort of ‘agents’ table to do things with a knockoutjs schema. This very much gets into the whole Address Book, User’s Table, and al that confusion. With a people table (much like an addresses table, a phone numbers table, and all that other sort of thing) you get a lot more utility out of your effort, and provide a basis for migration to better data linking. This basically means you have to integrate things with a patient dashboard so that you can pick/add people/agents to the list, then link them to a patient, then describe the relationship to the patient. These relationships would be things like Guarantor, Teacher, Emergency Contact, Case Worker, etc…