Charge Entry Changes / mysqli / and Smarty

mbrody wrote on Monday, April 07, 2008:

Hello All,

I am new to this community so I will take a moment to introduce myself,  My name is Michael and I have been in practice as a doctor for about 20 years.

I work part time at a local VA hospital and am very familiar with the VistA EHR software which is very feature packed, and for a while I played with installing it for my practice, but it is written in mumps is difficult to install, and is well a pain in the arse.

I then went searching for an alternate choice and found OpenEMR.  It appealed to me because it is written in php with a MySql backend and I have written numerous application for that platform.  I spend about half of my time playing doctor and the other half writing code.

I belive that I can bring some ‘real world’ insight to the community and have already had contact with Rod about changes to the billing interface to make it more similar to the way data is inserted into a HCFA form.  I will be doing some work on that in the next few weeks.

In looking at the code I have made a couple of observations. 

First the mysql calls are not mysqli. mysqli is a better method of db  calls.  Is there any interest in converting the calls?

Second the javascript code and html is part of the php code.  This makes the php codebase more difficult to manage IMHO.  Is there any interest in moving to Smarty, moving the html and javascript to the Smarty templates and just having the php functionality in the php code?

Michael

cfapress wrote on Monday, April 07, 2008:

Hi Michael,

Welcome! I’ve been doing major work on getting the calendars into an Outlook-style look and feel. I’m mainly a PHP/HTML/Javascript guy. I’d never touched PHP Smarty. Ever. So I found myself looking at the old calendar code and tried to sway it away from Smart and more toward a more conventional mix of Javascript/HTML/PHP.

The biggest problem I have with PHP Smarty is that it adds another layer of complexity to a situation that doesn’t need it. The idea of Smarty is to separate the business logic from the interface design. This is the ‘golden rule’ but never achieved. I’ve never seen it work smoothly and cleanly in my 12 years of web programming. Instead you end up with back-end business logic creating lots of variables. They are passed to the front end (template) parser. The parser takes the variables and spits them out. Then the application grows and the variables and loops included in the front-end (template) increase. So in the end you’re facing a messy situation of business logic having crept back into the interface because of the ever changing world of user interfaces.

Better to have just stuck with the original parsed language to begin with. I firmly believe that PHP is already a language that should be used as Smarty is intended. It’s tag-based “<?php  … ?>” like Smarty “{…}”. It easily loops. You can include files on the fly. I just don’t see how Smarty is an improvement over a properly designed and developed PHP application.

Honestly, I’d like to see the PHP Smarty stuff stripped from OpenEMR. While we’re at it we should really change out the PostCalendar for another which handles repeating events in a better fashion.

But alas… here we are. Working with a Frankenstein that *** kicks the pants off *** of the commercial products out there.  :slight_smile:

I’ve never heard of MySQLi. I’ll have to take a look at what that’s all about. But going in and hitting replacing all the MySQL calls will take about 40 hours of time for the coding and testing. What kind of improvements would MySQLi add to the application?

Jason

chemed wrote on Monday, April 07, 2008:

Jason,

While you are technically correct, that Smarty is just another layer doing the exact same thing as plain PHP could do, there are a couple of benefits to using a separate template engine.
1) If you ever want to reuse parts of your HTML code you will need some kind of template support, even if it is your own lite one.
2) Your HTML/JS will look much better and will be much easier to edit in the IDE if you do not split it into multiple concatenated strings and echo statements.
3) Some argue, that UI designers have easier time with Smarty as opposed to PHP. I think they get scared after seeing <?php echo "$…"; ?> instead of shorter {$…}.

On the other hand, with the advent of modern AJAX interfaces (like ExtJS) generating HTML from PHP will soon be the thing of the past.

drbowen wrote on Monday, April 07, 2008:

Welcome Micheal,

If you have not already done so you should look at the OpenEMR System Architecture:

http://www.oemr.org/modules/wiwimod/index.php?page=InformationForNewDevelopers&back=WiwiHome

Mysqli was introduced with PHP5 and provides faster database connections.  Conversion of all mysql connects to mysqli should improve database connection speed and improve overall efficiency of OpenEMR.

Smarty works well if implemented early and done well.  This is not the case with OpenEMR.  The developers group as a whole voted in 2005 to move away from Smarty.  (The vote was 100% against Smarty).  Smarty adds another layer of complexity that can otherwise be written directly with PHP code.  It is also harder for non-professional developers to make contributions due to steepness of the Smarty learning curve.

We have been moving towards Ajax.

Sincerely,

Sam Bowen, MD

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

sunsetsystems wrote on Tuesday, April 08, 2008:

Well, we discussed Smarty extensively quite a while back, and the decision was made to avoid it for new development.

To be honest I don’t really understand your proposed billing changes.  But I’d like to see an incremental approach where we understand and discuss the way things work now, and get everyone’s input on ways to improve them.  I think the next important step for improving the billing side is to replace the functionality that we currently use in SQL-Ledger.  Getting rid of SL will make things a whole lot easier all around.

Of course you can throw out baby and bathwater, and making a new baby is plenty of fun, but raising a kid from scratch is very hard work.  Adopting one already out of diapers is usually easier.  :slight_smile:

Rod
www.sunsetsystems.com

mbrody wrote on Tuesday, April 08, 2008:

Rod,

I will try to explain my ‘logic’ here:

1 - When a patient has a primary and secondary insurance and there is NOT automtic crossover, there needs to be a way for the program to track when to print out the HCFA to bill the secondary insurance carrier.  So the program needs to track when the primary insurance payment is complete.

2 - When multiple procedure codes are billed on the same day, an insurance company may pay some codes and not pay others.  This usually involves some additional information the insurance company is asking for to justify the other codes, or a processing error on the part of the insurance company.  There needs to be a method of tracking payments by proceedure ccde to allow doctors to track and persue outstanding monies.

3 - Some insurance companies have copays for certian procedure codes, and no copay for other procedure codes.  So in some cases a patient may have 0 Copays due at the time of the visit,  and in other cases the same patient may have multiple copays due at the time of visit.  Therefore there is a need to be able to attach Copays to specific procedure codes. 

4 - If a specific claim in in dispute, or review that is part of a patients history, and they change insurance carriers midway through their treatment plan,  there needs to be a method of linking charges to historical insurance policies (the company, and insured ID information) for primary, secondary, and tertiary plans.  So that these claims can be properly rebilled to the proper former insurance carrier.

5 - There are times when a patient comes in for a visit, and depending upon the services rendered, different insurance companies may be responsible for different aspects of the care rendered.  For example a patient who is on Medicare who comes to the office and receives both medical care and durable medical equipment.  We need to bill one medicare carrier for their medical care, another for their DME.

6 - Now this one is a bit esoteric but there are doctors who accept non traditional methods of payment, such as barter.  Or doctors may wish to seperately track Amex, Master Card, and Discover payments seperately since they have different discount rates and annual fees, and use those reports to see if it is worth keeping those services.  Or A doctor may have a website where they accept payment via paypal, and they want to track paypal payments seperately.  By giving end usres the ability to add payment types themselves in a n+1 manner,  the program can provide the flexibility for the ones I have listed and anything else that may be unique to a specific practice.

When transactions are written to the database, they should be done in such a way that it improves the doctors ability to manage their A/R.

I have had the opportunity to use three different medical billing packages (was a beta tester for two of them) and have had the opportunity to see many A/R issues and how certian software packages were defieient in assisting the docs with managing their A/R.

My proposed plan will provide a set of tables that will allow queries and functions currently unavailable that will improve the docs ability to manage their A/R.

Michael

sunsetsystems wrote on Tuesday, April 08, 2008:

OK, thanks – I’ll respond point-by-point:

1: This is already handled via the "EOB Invoice" page.  You can use it to enter insurance payments, to mark primary (or secondary/tertiary) payment as complete, and to reopen the claim for secondary/tertiary processing.

2: This is already handled.  Payments are normally associated with their procedure codes.

3: Since patient payments can also be associated with procedure codes, logic could be developed to accomodate that for copays as well.  No database structural change would be necessary.

4: Historical insurance coverage is already handled via the "effective date" field.  Thus old claims will be regenerated with the correct insurance.

5: This one I’ve not heard any complaints about, but I’m sure a solution can be worked into the existing structure for practices where it comes up frequently.

6: Support for the payment method already exists, and can be expanded if desired.

Perhaps you have not seen all of the available documentation?  My screenshots at http://www.sunsetsystems.com/node/8 are a bit out of date, but they go a long way towards illustrating how many of these things work.

For features that you think should be present but do not seem to be, please ask!  Documentation in many areas is lacking, and that’s where help is also needed.

Rod
www.sunsetsystems.com

drbowen wrote on Thursday, April 10, 2008:

Dear Michael,

This is a lot to digest at one time but I did want to make a couple of more comments and clear up a couiple of things.

Quoting from your post:

*** 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. ***

I think you are referring to PHP5?

We have been trying to move all of the code over to PHP 5 for a while (at least the last two years).  All of the code will run on a PHP 5 engine.  We do however want to rewrite all the older PHP 3 vestiges, and PHP 4 code.  The last time we counted the OpenEMR code base its about 475,000 lines (not couting the calender).  It will take a while to get all of the PHP 3/4 code converted to PHP 5. 

With the move to PHP 5 we are also trying to modularize the code and move to an object oriented style.

The need to manage all of the AR from within OpenEMR without SQL-Ledger has been recognized for a number of years and has been a project goal since 2005.  In 2005, FreeB was necessary to do the electronic billing and SQL-Ledger was adopted as the expedient way to manage the AR.  This came with the penalty of increased complexity of install.

Yet the need to create a OpenEMR / PHP / MySQL practice management module has been clear for several years.  What you are proposing is to beef up the practice management aspects of OpenEMR which we are definitely in favor of.

We feel AJAX will help us make the templates more readily modifiable by the non-programming end users.

It sounds like you need to look more closely at the AR code that Rod has already created and post the CPT / IC9 / charge data to an OpenEMR table instead of the SQL-Ledger.  We want to do this without breaking backwards combatibility for those using SQL-Ledger.

As Rod has stated, trying not to have to start from scratch will be an advantage.

I will post some info as a get a little more time.

Sincerely,

Sam Bowen, MD