Guarantors

sunsetsystems wrote on Tuesday, July 09, 2013:

Anyone want to comment on the best way to add support for guarantors in OpenEMR? I’m converting a client from another system that has them, and it will be awkward not to bring them over. This is mostly about who to send the statements to, and I presume typical examples would be a child’s parent or an elderly person’s guardian.

Current ideas are:

  1. Create a new table plus all the new GUI stuff to maintain it and to make selections from it.

  2. Add yet another set of name/address/phone fields to the patient_data table (note it’s pretty crowded already).

  3. Add guarantors as if they are patients, and if they are not also patients (though they easily could be in a family practice setting) then they wouldn’t have any encounters or other medical info.

I’m kinda leaning towards #3. What do other practice management systems do? Thoughts?

Rod
http://www.sunsetsystems.com/

tmccormi wrote on Tuesday, July 09, 2013:

3 is how I’ve done it in the past with just using a guarantor record type list. Default to “patient”, everything else is consider a guarantor, “Parent”, “Guardian”, etc … list can be modified/expanded that way.

Then for type = patient, an optional field to select the “guarantor” record and a option to copy the basic geo-demographics, phones etc from the guarantor record into the patient record to save on typing… (similar to using ‘self’ in the insurance record… That said adding “guarantor” as an option in that section would be good too (or perhaps assuming guarantor on insurance if one exists)

Note: being a guarantor does not preclude also being a patient :slight_smile:

–Tony

zhhealthcare wrote on Wednesday, July 10, 2013:

The third option is better. Medisoft and TotalMd goes this way. The Insurance subscriber information can also be treated in this manner.

Eldho
ZHHealthcare

mdsupport wrote on Wednesday, July 10, 2013:

Rather than creating multiple dummy ‘Guarantor’ patient records, taking Tony’s approach further why not create ‘Guarantor’ as one insurance company and then use subscriber set of fields to fill in real guarantor info like name, address etc.? That will inherit the mechanism to have time delimited guarantors.

fsgl wrote on Wednesday, July 10, 2013:

If the purpose is knowing where to send the patient balance, the Contact Address can be that of the guarantor and her phone number in Emergency Contact, while the address of the patient can be in Insurance.

tmccormi wrote on Wednesday, July 10, 2013:

Because guarantors are not limited to insurance related uses.
On Jul 9, 2013 11:02 PM, “MD Support” mdsupport@users.sf.net wrote:

Rather than creating multiple dummy ‘Guarantor’ patient records, taking
Tony’s approach further why not create ‘Guarantor’ as one insurance company
and then use subscriber set of fields to fill in real guarantor info like
name, address etc.? That will inherit the mechanism to have time delimited
guarantors.

Guarantorshttps://sourceforge.net/p/openemr/discussion/202506/thread/718ff883/?limit=25#40c1

Sent from sourceforge.net because you indicated interest in
OpenEMR / Discussion / Developers

To unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.net

tmccormi wrote on Wednesday, July 10, 2013:

It’s more than insurance and a/r. In pediatrics it’s about legal and personal responsibility, true of some mental health too. And in family practice the guarantor is frequently also a patient. The suggested num 3 option is the most normal way to do this in other EMRs
Tony

yehster wrote on Wednesday, July 10, 2013:

Generically, something that may be useful is a table that maintains “patient-to-patient” relationships. (would have patient1-id, patient-2-id and relationship-type). The relationship type could be guarantor, spouse, sibling,parent, etc…

deschel wrote on Wednesday, July 10, 2013:

In my demographic/contact database project (yes I am still working on this), I am currently working on creating a table structure that supports something like this and so much more. For a summary, see https://sourceforge.net/p/openemr/discussion/202506/thread/02d39134/.

Hopefully, it will be completed in the next 3-6 month time range.

It follows the idea of your #3 but does much more, including normalizing much of the data.

Patient contact information is taken out of patient_data and put into a new table person. Person can be a guarantor, secondary contact, etc. Then a separate contact database is created for address and phone information. Both people and businesses point to this. Contact information is thus abstracted and can be used for anything. The contact database would track everything that requires contact information, referring doctors, dme companies, pharmacies, etc.

My new system will also support multiple addresses for patients, guarantors, etc, because addresses will be normalized.

I don’t know what your time range for needing your guarantor support. If you can wait, or if you need something “jerry-rigged” now. And, if you do create something quick and dirty to satisfy your client, please avoid contributing it to dev version for now, because it will create more work for me to translate the data to the new structure.

Currently, the sql files to create the data tables is finished, some work has been done on sql files to port data to new structure is finished, and I am currently working on the interface.

I’ve communicated with Brady about this project, who insists on almost 100% compatibility with the custom layout engine, which is adding a lot of work to the project, and is very difficult since the layout engine is designed for flat tables rather than normalized tables. But, I do have a plan for this, it just adds a lot to amount of work needed and complexity of project.

After getting burned with hiring people, I am doing most of the work myself. Therefore, for this major upgrade, I am looking more for “collaborators” than “contractors”.

Would you want to collaborate with me?

I believe that my project is a major contribution, that addresses many deficiencies in the contact database structure, and addresses issues that apparently people are jerry-rigging solutions for, such as guarantor. But it addresses so much more, that would help make OpenEMR more marketable. Therefore, it would be in everyone’s interest to help me.

Let me know if any one is interested in volunteering some time/expertise to help.

David Eschelbacher

deschel wrote on Wednesday, July 10, 2013:

By the way, the link is to a general outline to give an idea of the tables I am proposing. There are some minor errors/deficiencies in the table structure that I have addressed already. Therefore the tables and relationships are 90% correct.

David Eschelbacher MD

fsgl wrote on Wednesday, July 10, 2013:

In the case of a Pediatric patient whose insurance coverage is via the non-custodial parent, that parent would be the Subscriber and the Relationship would be Child. In the very unusual situation wherein there is a controversy over which parent is the guarantor, the court order can be entered into the medical record.

The case of a patient who is not compos mentis can be handled like 92 year old John Doe.

Our old practice management software had the capability of grouping family members together into one account. It proved to be very unwieldy and separate accounts had to be created.

If the guarantor is also a patient, then it follows that another account needs to be created.

Which is easier to accomplish and less likely to introduce errors, re-directing guarantor information into the existing system or creating modifications for this task?

zhhealthcare wrote on Wednesday, July 10, 2013:

Rod,
Here’s what I think:
When we talk about guarantors it is the person that the bill is sent to and is responsible for the money. Usually the patient is responsible for the payments after the insurance cycle is completed. Therefore the logic for the billing will usually follow that of a patient’s.

However if the guarantor does not pay then the patient is liable, is he not? Or there could be cases where the guarantor agrees to pay only a part of the payment and the rest falls on the patient. Most practices have an agreement with the patient conferring the ultimate responsibility on the patient even if he is covered.

The ideal solution would be to have a field in the patient table for guarantor. This can be populated in three ways:
• Self. i.e. The patient
• Another patient: could be the father, mother, or any other individual
• An entity: A Company that provides healthcare to the patients, or a charitable organization that does so. I propose this needs to be another table or we can use the addressbook for this one.

So when the field is being populated, if the party is not “self”, then their needs an option to populate from either another patient or from another entity.
Subsequently the financial reports need to be tweaked (or add report) to show who actually owes the money so that AR people can work on it accurately.

Shameem

ZH Healthcare

yehster wrote on Wednesday, July 10, 2013:

According to “Citizens United” companies are people, so putting a company’s info in the patient_data table so it can be treated consistently is acceptable according to the supreme court.

blankev wrote on Wednesday, July 10, 2013:

IMHO as a non-user non-developer, but interested, there is something in place but without the look-up function. Under Insurance you can make under relationship a choice of who is the responsible person, or to say who is insured/responsible for payment. Only there is no look-up function to include all the fields taken of the Payment Responsible Person. This can also be done for second Insurance and third.

In my EMR of 2007 non-OpenEMR, you register the Responsible Insured person with all information first. Than if you choose Child or Spouse or Dependent you use the ID of the Insured person and once the insured person is found all particulars are registered for dependent. If the Main Insured person changes insurance it is asked if you want to make the dependents follow the same changes or make them member of a different Insurance.

To write this down seems a huge task, as may be the Look-up function might be for Developers. But if seen during practice hours and during a busy workflow it work easy and makes everything related very consistent.

zhhealthcare wrote on Wednesday, July 10, 2013:

Wouldn’t Putting a Company in the patient table mess up the MU calculations?

yehster wrote on Wednesday, July 10, 2013:

Most of the MU calculations are based on “patients seen” so as long as these “pseudo patients” didn’t have encounters, they won’t impact those MU calculations. The same issues would exist for guarantors who aren’t also patients.

The basic issue is what’s ideal (Dr. Eschelbacher’s fully normalized entities/contact info vision) vs. what’s expedient (use existing tables as much as possible/layout) or something in between.

zhhealthcare wrote on Wednesday, July 10, 2013:

Yes, most of the calculations are based on “Patient’s Seen” but not all. And I believe, not sure, tweaking those reports are going to be linked to MU cert.

Anywho, about the basic issue, do not do expedient! Do it right.

zhhealthcare wrote on Wednesday, July 10, 2013:

Another question: Is not Guarantor the same concept as Insurance, where the insurance is guaranteeing the payment of the patient? So is it not similar to having multiple primary insurances wherein the patient has two primary responsible parties who guarantees payment? If so, wouldn’t implementing the multiple insurances be adequate? In this scenario nothing else needs to be changed in terms of billing logic or any. We can queue up billing to the desired parties(insurances/guarantor) after each cycle and then finally to the patient.

Shameem
ZH Healthcare

zhhealthcare wrote on Wednesday, July 10, 2013:

This will actually kill two birds with one stone:
Multiple primary insurances which have been asked for by various people at various times, and the guarantor issue.

The drawback is it doesnt cover how to include another patient as the guarantor :frowning: oops

sunsetsystems wrote on Wednesday, July 10, 2013:

Great comments, I’m glad I asked!

David, your normalization project still sounds very cool and I hope it works out well. I’ll try not to mess you up too badly. Sounds like the only database change needed is a new “guarantor” column in the patient_data table which is just a reference to another patient, or more commonly 0 to indicate “self”.

I’m pretty sure we don’t want to mix this with insurance as that may be confusing and/or conflict with insurance data. This is not about insurance.

Supporting guarantors outside of the patient_data table may be desirable, but could be added later so I’ll not worry about that yet. Dunno about the patient being responsible if the guarantor does not pay, I’ve not heard of that, but it sounds like a legal issue beyond the scope of the EMR.

Thanks again for all the input.

Rod
http://www.sunsetsystems.com/