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.
Thanks
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Last edit: fsgl 2015-10-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
Thanks
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Terry
Last edit: Terry Hill 2015-10-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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”
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
--Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why not use the existing insurance framework? Isn't an insurance just a subset of 'Guarantors'?
It may make sense to change demographic tab from 'Insurance' to 'Billing' or 'Financial Responsibility'. That will provide a single view of all financial parties involved in paying for patient care.
Last edit: MD Support 2015-10-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, the guarantor is who pays if the insurance company rejects the claim.
Again, all of these parties generically are "contacts" and it would be nice to have a more basic entity that could be generically used, but there is a lot of legacy code that would need to be refactored to accomplish that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Having had to modify the insurance framework to support more than the current defaults and break the Primary->Secondardary->Tertiary flow that is baked into the process, I can tell you that it's very hard, but, we are finding all the possible issues that we have "caused" :-)
However, I agree that that is one possible solution from a stricly idealistic point of view.
I have attached a couple of screen shots of what this looks like
I completely agree with your assessment of 'Primary->Secondardary->Tertiary' logic. My only worry would be adding another element for biller to consider => developer to put on reports and screens.
At the end of the day, this is billing related feature. Many of commercial billing systems use an abstraction layer to implment flexible billing plans - e.g. Kareo uses 'cases'. Within a case you can define payor hierarchy to be followed by billers. Since you can specify the billing plan for each encounter, situation like worker's comp visits, litigation related payments, family payments etc. can be set up in addition to 'default' insurance hierarchy + patient responsibility.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm...we seem to be missing a lot of posts...like the one where I stated that vertical tables are a pain, and we have to go there anyway....and like where I thanked Terry for taking on doing anything...by any method...to tackle the guarantor issue that has been grinding around.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Thanks
Terry
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.
Last edit: fsgl 2015-10-21
Suggest not adding to the patient_data table and instead creating a separate guarantor table.
https://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html
One of the limitations is 8000 bytes for a row.
Having a separate guarantor table has a lot of advantages in the long run. Extending the patient_data table is easier in the short run.
Thanks Kevin.
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?
Thanks
Terry
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.
Rod
http://www.sunsetsystems.com/
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.
Rod
http://www.sunsetsystems.com/
This is the sql file for the fields and tabs. This is posted only to show the fields that are currently used in my installed locations.
Vertical tables were incorporated in the “Patient Flow Board” addition.
Terry
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.
Rod
http://www.sunsetsystems.com/
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.
Terry
Last edit: Terry Hill 2015-10-21
The extra set of fields would be for non-custodial parents, who are the insured or adult children, who live elsewhere.
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”
Terry
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.
Rod
http://www.sunsetsystems.com/
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.
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.
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.
--Tony
Regarding simplifying queries, that's yet another good reason to build a PHP object model for patient data. Other data too.
Rod
http://www.sunsetsystems.com/
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...
Why not use the existing insurance framework? Isn't an insurance just a subset of 'Guarantors'?
It may make sense to change demographic tab from 'Insurance' to 'Billing' or 'Financial Responsibility'. That will provide a single view of all financial parties involved in paying for patient care.
Last edit: MD Support 2015-10-21
No, the guarantor is who pays if the insurance company rejects the claim.
Again, all of these parties generically are "contacts" and it would be nice to have a more basic entity that could be generically used, but there is a lot of legacy code that would need to be refactored to accomplish that.
Having had to modify the insurance framework to support more than the current defaults and break the Primary->Secondardary->Tertiary flow that is baked into the process, I can tell you that it's very hard, but, we are finding all the possible issues that we have "caused" :-)
However, I agree that that is one possible solution from a stricly idealistic point of view.
I have attached a couple of screen shots of what this looks like
Last edit: Tony McCormick 2015-10-21
I completely agree with your assessment of 'Primary->Secondardary->Tertiary' logic. My only worry would be adding another element for biller to consider => developer to put on reports and screens.
At the end of the day, this is billing related feature. Many of commercial billing systems use an abstraction layer to implment flexible billing plans - e.g. Kareo uses 'cases'. Within a case you can define payor hierarchy to be followed by billers. Since you can specify the billing plan for each encounter, situation like worker's comp visits, litigation related payments, family payments etc. can be set up in addition to 'default' insurance hierarchy + patient responsibility.
Hmm...we seem to be missing a lot of posts...like the one where I stated that vertical tables are a pain, and we have to go there anyway....and like where I thanked Terry for taking on doing anything...by any method...to tackle the guarantor issue that has been grinding around.