mbrody wrote on Tuesday, April 08, 2008:
Well I am a proponent of Smarty, and these days when I write an app I start with Smarty. I understand the comments about if the project is started with Smarty, and if the developers made a decision in 2005 then if I am going to join the developer community of this project then I need to ‘go with the flow’.
Jason, as far as your comments regarding Smarty gettin too comples as the application grows, I would have to respectfully disagree with you. To use a single template and put numerous conditional loops in it as the application grows is a wise as writing a php program as a single file rather than using classes.
The power of smarty is in creating a series of templates each tailored to the module that is sending the output code. Tying the templates together with includes for the headers and footers, and utilizing common css files can allow you to utilize smarty and split the business logic out of the display control.
But then again PHP / Smarty is something I have done a fair amount of work with and am very comfortable with so I can say that I am not 100% objective. As far as the mods to the PostCalendar, the first suggestion I would make is move to PC 5.0 I use it extensively in some PostNuke installations and it has significant advantages over 4.0. Managing the look and feel of the PC is not that difficult in that the templates are all easily accessable and I have written my share of modifications for that module in the past. That particular project is not something I have a great deal of interest in taking up since I am currently focusing on the Fee Entry Module to make is more compatible with the way HCFA’s are filled out and the way insurance companies in the US Pay Claims (on a line item basis).
I do find the AJAX path quite intriguing. I have done some light reading on it, but have not yet played with that platform. I have spent much more time working on using css to it’s fullest capabilities, as a result I am not entirely confortable with Javascript and have not delved into AJAX.
Programming style discussion aside. Here is what I plan to work on and why. If this does not fit in with the anticipated path of OpenEMR please let me know now.
I will be creating a new billing tables named t_billing
I will have t_billing written in parallel with billing so that there will be no impact on ‘legacy’ if this upgrade is accepted to the core and people wish to continue with the current system
Table t_billing_codes
this table will ONLY have billing codes. regardless of the type cpt / hcpcs etc.
ID (auto increment)
Code (cpt Code)
Date of Service
Diagnosis (utilizing current style)
Modifiers (utilizing style similar to Diagnosis)
Units
Total Fee
patient ID
Provider ID
Primary Insurance Co ID
Primary Isured ID
Primary Inisured GP ID
Primary accept assignment
Primary Insurance Status
Status options - no payment recieved from primary ins
partial payment recieved from primary ins
full payment recieved from primary ins
Secondary Ins Co ID
Secondary Insured ID
Secondary Insured GP ID
Secondary Insured Status
Status options - no payment recieved from secondary ins
partial payment recieved from secondary ins
full payment recieved from secondary ins
Tertiary Ins Co ID
Tertiary Insured ID
Tertiary Insured GP ID
Tertiary Insured Status
Status options - no payment recieved from tertiary ins
partial payment recieved from tertiary ins
full payment recieved from tertiary ins
Paid in Full (t/f)
Comment
table t_billing dates
this keeps track of when bills are sent out every time bills are sent out this table is written to.
ID (auto increment)
Procedure Code ID (ID # from t_billing_codes)
Time / Date Stamp
Method (electronic / HCFA / Patient Statement)
table t_payment_types
ID (auto increment)
Type (patient payment, patient adjustment, insurance payment, insurance adjustment etc)
table t_payment_methods
ID (auto increment)
Type (check, credit card, professional courtesy, cash etc)
table t_credits
ID (auto increment)
amount
type (reference ID from t_payment_types)
method (reference ID from t_payment_methods)
bill_code (reference ID from t_billing_codes)
source (primary insurance, secondary insurance, tertiary insurance, patient, other)
With this set of tables the following queries are possible
Show me all claims that have payments pending from primary insurance
and rebill all claims that have payments pending from primary insurance
Show me all claims where primary is paid and secondary is not paid in full
Bill secondary insurances for copayments
same for third
Bill patients for all balances not paid for by primary, secondary, or tiertary ins.
potential query = if primary exists and primary ! paid in full or
if secondary exists and secondary ! paid in full or
if tertiary exists and tiertary ! paid in full
it means that insurance payments are still pending do not bill the patient for this line item
else bill patient for this line item.
many queries and functions are possible with this data table structure.
each procedure code has its own line items and all payments are applied on a line item basis. This way if three codes are billed, and two are paid for, the two that are paid for can be marked appropriately and the third code is still pending so that the doctor’s office can follow up on why that code was not paid.
Insurance companies pay by line item. Payments should be recorded in the same manner.
Basically this means a major overhaul of the Fee Sheet Routine.
Writing a routine inside OpenEMR to accept payments at the time of the visit for the current and previous visits.
making that routine does ‘real time’ credit card processing connecting with authorize net.
Writing a routine to post insurance payments and post them to line items, and mark insurance payments as ‘complete’
Writing a routine to manage t_payment_methods
Writing a routine to manage t_payment_types
If I am going to 'play with the billing portion of the program, i figure may as well do it in a way that significantly increases the potential functionality of the program.
In order to not cause any issues with any other development, I would start by creating "alternate fee sheet" as a choice in encounters. and building from there. all other routines would be completely new and therefore nothing I do will interfere with other development.
Michael