OpenEMR is still weak on basic accounting functions. Some improvements around claims billing and payment posting were contributed by Sunset, MI2 and ZHH a few years ago, but much still needs to be done.
MI-Squared has recently been contacted by several groups that would like to contribute to these improvements but the project is too big for them alone. Minimum cost for the core modifications to support true transactions (per GAAP) and good, basic reporting are estimated at $30K, the whole project with all the bells and whistles is more like $100K (some will tell you it's much more than that and are probably correct).
Are there any practices or other vendors out there that would like to do a collaborative project around this to be contributed back to the community?
20 clinics contributing $1500 each would get it a long way. Could do that via the OEMR.org if desired and we could bid the work out to the qualified developers.
Tony
oemr.org president
Last edit: Tony McCormick 2014-04-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am in it! I would be happy to contribute - more cash and ideas than code. Willing to try small coding tasks.
I currently use zirmed as a clearing house and had hoped to integrate its API into openemr. But we dont have to - I would rather contribute the monthly I pay to zirmed on to the openemr developer teams if we can get same or better value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have used Zirmed for about 3 months now, and except for their costs, they have some very nice features, all available via API. My wish list for openemr will include the following:
1. Batch eligibity - will be great to send and receive responses within OpemEMR
2. Batch claims - send claims and receive ERAs
both these should be straight forward. OpeneEMR does generate compliant files (EDI 270 and 805 5010 files) and could be configured to push sFTP to Zirmed (which it does allow)
3. Patient estimation tool - this is a great tool, especially in today's climate with higher deductibles and copays and co-insurance. Zirmed does a realtime calculation and then allows you to request payments at time of service (for example using zpay). We all know that these are best collected there and then.
Zpay - an integrated interface for collecting the correct payments via check, card, etc.
Claims status indicator and denials manager
I dont think we need to re-create the wheel - it is a whole enterprise on its own - simply having the zirmed and Openemr APIs talk to each other will be great help
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to be involved at least in helping to translate what's needed into how it will be done and how that breaks down in terms of tasks. After that, this doesn't need to be a monolithic project but can become a collection of projects that can be funded and completed separately.
We don't use billing because of several limitations. However we could help with cash and/or code for robust elig check. May be oemr.org can run elig check as a routing service to generate some maintenance cash flow.
On a related note, we should not forget non-US partners - specially those handling cash prepayments seem to come up with peculiar requirements from time to time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Human beings tend to be dissatisfied until they are asked to supply money or work for the remedy (present company excepted). Hence the challenge: "Put up or...".
It seems to be the second option.
Back to MU2 x 3.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Human beings tend to be dissatisfied until they are asked to supply money or work for the remedy (present company excepted). Hence the challenge: "Put up or...".
I have full commitment to rip out the current crap we have for billing management and rewrite it. Plan is to follow the Gap Analysis we already developed and to enhance and supplement it with best in class from the proprietary systems most cherished by billing staff.
This will start with changes to the billing table structure to make ALL monetary transactions follow Generally Accepted Accounting Practices (GAAP. Baseline is no dollar amounts are ever, ever modified. Only adjusted by addtional transactions as debit/credit entries.
--Tony
www.mi-squared.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are there plans to revise the UI as well, or is this more of a behind the scenes cleanup? I find the multiple avenues of posting payments to be confusing and unnecessary. We have Fees > Payment, Fees > Checkout, Fees > Batch Payment, Fees > Billing > EOBs > EOB Invoice, etc.
Is it feasible to pull all of these functions into something more consolidated? Also, feel free to share a donation link or PayPal address for those of us that would like to donate towards the effort.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BUT, please do this design and coding work in full public view. We have a whole bunch of stakeholders here and a lot of existing code investment. Also it will work a whole lot better if it's done piecemeal. Yes that will take extra planning but it gives you a fighting chance of being successful. If your sponsor doesn't like that, let me and/or Brady talk to them.
By the way some folks may object if they can't make a data entry typo and fix it right away without dragging the remnants of it into perpetuity. But that can be discussed later.
We will start with minor updates to the the hurt points and move to major
rewrite, likely as a zend module that can installed in place of the
existing stuff.
One big questions is: how can we (or even should we) try and port the old,
non transactional data forward?
Tony McCormick, CTO
www.mi-squared.com
Support: 866-735-0897, Direct: 713-574-6709
My Calendar: http://bit.ly/XznvDo
... we have to slow down a bit to be able to speed up a lot... (me)
--
Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Tony, I'm pleased that you are organizing this effort and looking for feedback.
I would not characterize the current accounting data as "non-transactional". And yes, if the SQL schema changes, porting old data is a must. This is ALWAYS a requirement.
To the degree that code is rewritten, I recommend focusing on using a PHP object model for the data and data-centric algorithms. What makes things messy is not failure to use a framework, but rather scattering SQL and repetitive code all over the place. Better to think about frameworks after this kind of modularizing is done.
I think it's also important to leverage existing code and concepts as much as practicable. Don't underestimate the amount of work it would take to replace it... this stuff has been evolving over more than 10 years. Most software projects fail; baby steps are insurance against that.
Here is the request list we are working in now, feedback on these and other high value updates would be good. Not making major changes to the core at this point, just upgrading the tools and reports as a starting point. This plus Terry's recent work will go a long way I think,
1 Aging Days Summary Report, ALL/Payor/Facility
2 Patient Ledger (with 3 columns Chg/Pay/Adj) (This is almost done)
3 Accounting Reports (payments/aging etc that are accurate).. (new reports in progress)
4 Claims process simplified, auto upload and download of batches/ERA/reports. (this one is kind of dependent on the clearing house in use)
5 Auto posting of same above to EDI management tools (same, clearing house dependent)
** 4 & 5 should also be able to automatically load the EDI History tools rather than the manual process it has now.
6 Simplified access to billing report tool, like "bill the patient now" from the fee sheet? or similar.
7 re-order the CPT codes which will be submitted (have a version that sort automatically but highest charge first already)
8 a "check all that are ready to bill" button in the billing view
Yes, which is why it says a better method. That process creates a payment that is only visible using the "Batch Payments/Search" and it doesn't have any information about the payment type/reason, it does not show up in any of the financial reports as a credit against anything, it doesn't show in the billing widget on the customer screen, etc. It does show in the new patient ledger we've written (item 2)
Would it be possible to also include an option to generate a "clean ledger" which would omit payments and adjustments and only list total charges for the selected encounters? This is something that is often needed when dealing with automotive personal injury claims.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, that presumes some sort of filtering options either before or after requesting the ledger, right now it's a full and complete list of all activity for the patient which is what a ledger is supposed to be.
What you are asking for is really a kind of specialized 'statement', trying to make this less complicated rather that more.
Who is the target audience for this kind of statement? The payor, ie: auto insurance company? In which case it's really a claim form, not a ledger.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The clean ledger is requested by attorneys who represent the injured party for potential settlement of bodily injury claims after PIP benefits have exhausted. I can't say I'm 100% sure how they use it, but I assume it is used to predict the cost of future medical care.
My current solution is to manually delete all the payment and adjustment transactions and recalculate the total. It can be pretty time consuming. An option to print a clean ledger would save me a significant amount of time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OpenEMR is still weak on basic accounting functions. Some improvements around claims billing and payment posting were contributed by Sunset, MI2 and ZHH a few years ago, but much still needs to be done.
See: http://www.open-emr.org/wiki/index.php/File:OpenEMR-PracticeMgmt-Developement.pdf
MI-Squared has recently been contacted by several groups that would like to contribute to these improvements but the project is too big for them alone. Minimum cost for the core modifications to support true transactions (per GAAP) and good, basic reporting are estimated at $30K, the whole project with all the bells and whistles is more like $100K (some will tell you it's much more than that and are probably correct).
Are there any practices or other vendors out there that would like to do a collaborative project around this to be contributed back to the community?
20 clinics contributing $1500 each would get it a long way. Could do that via the OEMR.org if desired and we could bid the work out to the qualified developers.
Tony
oemr.org president
Last edit: Tony McCormick 2014-04-14
I am in it! I would be happy to contribute - more cash and ideas than code. Willing to try small coding tasks.
I currently use zirmed as a clearing house and had hoped to integrate its API into openemr. But we dont have to - I would rather contribute the monthly I pay to zirmed on to the openemr developer teams if we can get same or better value.
Lams,
What features would the ZirMed API provide you (besides basic clearinghouse functions) that you would like to see in OpenEMR?
--Tony
Hello Tony,
I have used Zirmed for about 3 months now, and except for their costs, they have some very nice features, all available via API. My wish list for openemr will include the following:
1. Batch eligibity - will be great to send and receive responses within OpemEMR
2. Batch claims - send claims and receive ERAs
both these should be straight forward. OpeneEMR does generate compliant files (EDI 270 and 805 5010 files) and could be configured to push sFTP to Zirmed (which it does allow)
3. Patient estimation tool - this is a great tool, especially in today's climate with higher deductibles and copays and co-insurance. Zirmed does a realtime calculation and then allows you to request payments at time of service (for example using zpay). We all know that these are best collected there and then.
I dont think we need to re-create the wheel - it is a whole enterprise on its own - simply having the zirmed and Openemr APIs talk to each other will be great help
sure, i'd like to contribute code and cash, probably my cash would be more preferred ;)
also interested in how realtime 5010 270 271 can be introduced to help with the collect correct information
Last edit: Stephen Waite 2014-04-15
I would like to be involved at least in helping to translate what's needed into how it will be done and how that breaks down in terms of tasks. After that, this doesn't need to be a monolithic project but can become a collection of projects that can be funded and completed separately.
Rod
http://www.sunsetsystems.com/
We don't use billing because of several limitations. However we could help with cash and/or code for robust elig check. May be oemr.org can run elig check as a routing service to generate some maintenance cash flow.
On a related note, we should not forget non-US partners - specially those handling cash prepayments seem to come up with peculiar requirements from time to time.
Curious to hear more about the sort of limitations you have encountered with billing.
Wishlist
Last edit: fsgl 2014-04-15
Hmm,
Seems like a pretty weak response for something that people complain about all the time.
Perhaps removing practice management and making OpenEMR a pure EMR would be a better approach? Then the whining would stop... :-) just kidding.
But ... it seems like something that would get more response/support than this.
--Tony
Human beings tend to be dissatisfied until they are asked to supply money or work for the remedy (present company excepted). Hence the challenge: "Put up or...".
It seems to be the second option.
Back to MU2 x 3.
To: 202504@discussion.openemr.p.re.sf.net
From: fsgl@users.sf.net
Subject: [openemr:discussion] OpenEMR Accounting Upgrade Project
Date: Sat, 19 Apr 2014 11:06:31 +0000
Human beings tend to be dissatisfied until they are asked to supply money or work for the remedy (present company excepted). Hence the challenge: "Put up or...".
It seems to be the second option.
Back to MU2 x 3.
OpenEMR Accounting Upgrade Project
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/openemr/discussion/202504/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Well,
I have full commitment to rip out the current crap we have for billing management and rewrite it. Plan is to follow the Gap Analysis we already developed and to enhance and supplement it with best in class from the proprietary systems most cherished by billing staff.
This will start with changes to the billing table structure to make ALL monetary transactions follow Generally Accepted Accounting Practices (GAAP. Baseline is no dollar amounts are ever, ever modified. Only adjusted by addtional transactions as debit/credit entries.
--Tony
www.mi-squared.com
Hi Tony,
Are there plans to revise the UI as well, or is this more of a behind the scenes cleanup? I find the multiple avenues of posting payments to be confusing and unnecessary. We have Fees > Payment, Fees > Checkout, Fees > Batch Payment, Fees > Billing > EOBs > EOB Invoice, etc.
Is it feasible to pull all of these functions into something more consolidated? Also, feel free to share a donation link or PayPal address for those of us that would like to donate towards the effort.
Sounds promising...
BUT, please do this design and coding work in full public view. We have a whole bunch of stakeholders here and a lot of existing code investment. Also it will work a whole lot better if it's done piecemeal. Yes that will take extra planning but it gives you a fighting chance of being successful. If your sponsor doesn't like that, let me and/or Brady talk to them.
By the way some folks may object if they can't make a data entry typo and fix it right away without dragging the remnants of it into perpetuity. But that can be discussed later.
Rod
http://www.sunsetsystems.com/
This particular consortium of customers insists that the work be done for
the community, so yes it would be in public. The overall plans and issues
are already part on the wiki and have been for years now ....
http://open-emr.org/wiki/index.php/File:OpenEMR-PracticeMgmt-Developement.pdf
We will start with minor updates to the the hurt points and move to major
rewrite, likely as a zend module that can installed in place of the
existing stuff.
One big questions is: how can we (or even should we) try and port the old,
non transactional data forward?
Tony McCormick, CTO
www.mi-squared.com
Support: 866-735-0897, Direct: 713-574-6709
My Calendar: http://bit.ly/XznvDo
... we have to slow down a bit to be able to speed up a lot... (me)
--
Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.
Thanks Tony, I'm pleased that you are organizing this effort and looking for feedback.
I would not characterize the current accounting data as "non-transactional". And yes, if the SQL schema changes, porting old data is a must. This is ALWAYS a requirement.
To the degree that code is rewritten, I recommend focusing on using a PHP object model for the data and data-centric algorithms. What makes things messy is not failure to use a framework, but rather scattering SQL and repetitive code all over the place. Better to think about frameworks after this kind of modularizing is done.
I think it's also important to leverage existing code and concepts as much as practicable. Don't underestimate the amount of work it would take to replace it... this stuff has been evolving over more than 10 years. Most software projects fail; baby steps are insurance against that.
Rod
http://www.sunsetsystems.com/
Here is the request list we are working in now, feedback on these and other high value updates would be good. Not making major changes to the core at this point, just upgrading the tools and reports as a starting point. This plus Terry's recent work will go a long way I think,
1 Aging Days Summary Report, ALL/Payor/Facility
2 Patient Ledger (with 3 columns Chg/Pay/Adj) (This is almost done)
3 Accounting Reports (payments/aging etc that are accurate).. (new reports in progress)
4 Claims process simplified, auto upload and download of batches/ERA/reports. (this one is kind of dependent on the clearing house in use)
5 Auto posting of same above to EDI management tools (same, clearing house dependent)
** 4 & 5 should also be able to automatically load the EDI History tools rather than the manual process it has now.
6 Simplified access to billing report tool, like "bill the patient now" from the fee sheet? or similar.
7 re-order the CPT codes which will be submitted (have a version that sort automatically but highest charge first already)
8 a "check all that are ready to bill" button in the billing view
9 Pre-Billing issues/readiness report/process (Harley's scripts)
10 Centralized access to key billing workflow tools if user is billing type (ACL), some kind of dashboard or workflow manager
11 Better ways to handle pre-pay/unallocated dollars at the patient level
--Tony
Hi,
Is there already a pre-pay mechanism? Remember seeing that option in Fees->Payment->Payment Against->Pre-Pay
-brady
OpenEMR
Yes, which is why it says a better method. That process creates a payment that is only visible using the "Batch Payments/Search" and it doesn't have any information about the payment type/reason, it does not show up in any of the financial reports as a credit against anything, it doesn't show in the billing widget on the customer screen, etc. It does show in the new patient ledger we've written (item 2)
See attached
Ledger example patient with nothing but a pre-pay posting
Tony,
Would it be possible to also include an option to generate a "clean ledger" which would omit payments and adjustments and only list total charges for the selected encounters? This is something that is often needed when dealing with automotive personal injury claims.
will add it to the list of feature requests.
However, that presumes some sort of filtering options either before or after requesting the ledger, right now it's a full and complete list of all activity for the patient which is what a ledger is supposed to be.
What you are asking for is really a kind of specialized 'statement', trying to make this less complicated rather that more.
Who is the target audience for this kind of statement? The payor, ie: auto insurance company? In which case it's really a claim form, not a ledger.
The clean ledger is requested by attorneys who represent the injured party for potential settlement of bodily injury claims after PIP benefits have exhausted. I can't say I'm 100% sure how they use it, but I assume it is used to predict the cost of future medical care.
My current solution is to manually delete all the payment and adjustment transactions and recalculate the total. It can be pretty time consuming. An option to print a clean ledger would save me a significant amount of time.
Wouldn't it be simpler to tally the charges & insert it into Billing View?
In addition to negating the adjustments & payments, these amounts will have to be re-entered later to accurately reflect ledger activities.