anonymous wrote on Monday, April 28, 2014:
We have a duplicate insurance company under Administration > Facility > Insurance Companies. Fortunately, there were no claims filed under that company so I was hoping to just delete the entry. Doesn’t seem to be an option. Maybe this was by design? Will I screw anything up if I just drop the entry from database?
fsgl wrote on Monday, April 28, 2014:
There is no “Unused” column in the table, so there is no safe option from the database side.
An awkward work-around is to blank out the name of the duplicate, causing it to go to the top of the list above Unassigned. It can be used for another carrier in the future. Clicking the blank space at the top will bring up this “insurer-in-waiting” for later editing.
anonymous wrote on Monday, April 28, 2014:
Good idea for a workaround. Still curious if deleting the entry from the “insurance_companies” table would cause any unforeseen consequences. I get a little obsessive over minor things like this, so would be good to know if it happens again in the future.
blankev wrote on Monday, April 28, 2014:
As long as it is a new install, don’t hesitate to experiment. As soon as you are in production phase, it is better to hide. It does not take much extra space, but could keep you form harming the interactions between tables and avoid many headaches to restore to the working environment.
fsgl wrote on Monday, April 28, 2014:
Developers’ refrain: Never delete, make unused.
Do you know how to add an UOR column as in layout_options? It would be a useful customization.
Experiment in the Demo and let us know the best and safest solution.
anonymous wrote on Monday, April 28, 2014:
The voices of reason prevail. I will use the entry for another insurance company.
I’m not sure I understand the purpose of adding a uor column. Would that be for creating an unused toggle? I’m assuming once claims have been generated and payments posted to a specific insurance entry, deactivating or deleting is out of the picture.
blankev wrote on Monday, April 28, 2014:
So now you are convinced, I would suggest for Insurance Comp. just hit the DELTE button as long you did not have any insured for this Comp.
For this special part I would dare to delete. Don’t forget to tell me I was wrong in case of failures…
anonymous wrote on Monday, April 28, 2014:
Wait. So you’ve convinced me to do the right thing, and now you want me to take the risk?!?
This is a production environment, so I don’t want to take any chances. I was hoping one of the devs could share some insight on any relation to other tables that could be discombobulated with such a deletion. I’ll go the safe route this time.
Wish I had more time to play around in a test environment…
anonymous wrote on Monday, April 28, 2014:
Now that I think about it, a double entry could cause issues while posting payments. If a claim is generated for one of the entries, but payment is posted to the other, wouldn’t that cause inconsistency in AR reporting? One insurer will have a negative balance and the other will remain outstanding.
fsgl wrote on Monday, April 28, 2014:
Not if the duplicate has been blanked out.
Hopefully staff has not been posting to both. Otherwise they will have to go into the EOB Posting Invoice and correct the entry.
Once the duplicate has been blanked, the Billing view and the Invoice will show a payment with no name for the insurer. Staff will have to adjust out that payment, re-enter it and re-assign the payment to the remaining insurer.
Since we are talking about a production copy, best not to fool around and tempt Fate.
blankev wrote on Monday, April 28, 2014:
Just rename the double Insurance name into something obvious. “To be filled as next Insurance…”
All Insurance comp have a unique identifier. So for future reference this hidden Insurance Comp will show somewhere in the middle of the table of Insurance Comp’s, after you have given it a new name. (Might show in alfabetical order in the Facility Insurance group)
yehster wrote on Monday, April 28, 2014:
If you are absolutely certain that no existing records reference the erroneously entered insurance company, you are probably safe to delete the row.
Validation code to verify that an existing record is not in use would be a prerequisite to implementing a “safe” delete button, which is probably one of many reasons why that functionality isn’t implemented in the app itself.
The reason why deleting columns in the layout editor is so dangerous is that that operation modifies the actual database tables, and not just rows in an existing table.
This is somewhat of a different beast in that you are just deleting one row. (As long as you do it correctly…)
If this were a system someone was paying me to manage, I’d personally would have no qualms about deleting the entry after verifying that this particular entry was in fact not referenced anywhere else. Recovery to recreate the entry with appropriate SQL statements in the event that this assumption is incorrect shouldn’t be too difficult.
Whether to delete the row vs. blank it out kind of depends on your level of comfort with database management.
anonymous wrote on Monday, April 28, 2014:
Thanks, Kevin. My familiarity with the database is steadily increasing. I suppose I should use this problem as a learning experience and do a little more tinkering.
I originally did a search by Insurance Company in the billing manager and didn’t see any entries. There was one patient that was assigned that insurer, but the patient never showed for the appointment, thus no claim generated. I switched their insurance to the original entry and confirmed no other entries via database query. See attached screenshots.
I feel a little more comfortable deleting the entry, so I’ll do my nightly backup and delete the row. Fingers crossed…
juggernautsei wrote on Monday, October 24, 2016:
Pull request to address this issue