-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Prior auth bug fixes and features #9027
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
fixed date type hint bug on a funtion when adding new auth changed CPTs to CPT since you can only add one singular at a time Removed duplicates rows in global report added pie graph of % of all auths used on global report Added bar graph and percent in tables of patient auths and global auth reports to easily see how many auths you have remaining. To know when to reauth quickly It is color coded green 67-100%, yellow 34-66%, red 0-33%
fixed date type hint bug on a funtion when adding new auth changed CPTs to CPT since you can only add one singular at a time Removed duplicates rows in global report added pie graph of % of all auths used on global report Added bar graph and percent in tables of patient auths and global auth reports to easily see how many auths you have remaining. To know when to reauth quickly It is color coded green 67-100%, yellow 34-66%, red 0-33%
Fix for phpstan failure
Remove unneeded types when passing variables to js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I left some suggestions for simplifying some code and avoiding duplication.
interface/modules/custom_modules/oe-module-prior-authorizations/public/index.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/index.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/reports/list_report.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/reports/list_report.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/reports/list_report.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/reports/list_report.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/reports/list_report.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/index.php
Outdated
Show resolved
Hide resolved
Is there an issue for this PR? We will need one, IIUC. |
No, sorry. My sister-in-law had a few bugs and wanted some more features, then I thought I would share. I will make one in a bit. You guys are so fancy for me, lol. I'm learning how you like things as I go. Thank you again |
interface/modules/custom_modules/oe-module-prior-authorizations/public/index.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/reports/list_report.php
Outdated
Show resolved
Hide resolved
interface/modules/custom_modules/oe-module-prior-authorizations/public/reports/list_report.php
Outdated
Show resolved
Hide resolved
@juggernautsei can you take a look over this, looks like a good addition, but want to make sure functionality wise it will still work the way your other clients are using it. |
|
@adunsulag I did deactivate his code in my last commited PR for this module that required his custom table. Also, a main dev had me remove his custom patient menu overwrite for a simple patient menu append. I left his code for his custom table there just commented out that way vanilla OpenEMR users can use this plugin and he can always just uncomment. |
I think this is going in a good direction. |
@adunsulag I will look this over this weekend. @kojiromike when the custom menu was conceived. At the time we had no way to inject into the dashboard menu bar. So, the custom bar was used. We should look into using some java script to inject the navigation into the native dashboard menu to get rid of the custom menu. I like what I read. I will try it out on one of our systems to see what it looks like. I like the idea of the graphs. Visuals are always good. |
@juggernautsei |
This should be good to go now. I haven't tested since all these minor commits but I think it should be good. |
I loaded the module and found in the index.php and the list_report.php needed to add the require autoloader in both files then it works. |
There is so much I would restructure about this module now. Hopefully, when we find an API partner. I will do the restructuring of this module to bring it up to date. |
interface/modules/custom_modules/oe-module-prior-authorizations/public/reports/list_report.php
Outdated
Show resolved
Hide resolved
@kojiromike Why does the module need the vendor autoload still? I thought core app will include registered modules autoloads? Should the include be there or not? |
@sjpadgett The module needs to be updated. This module was created prior to the work that @adunsulag did in the openemrbootstrap to autoload classes into the OpenEMR namespace. That will be part of my refactoring of this module to restructure it. |
So what's the question?
Our first module was my fax/sms that Stephen engineered the integration and added the namespace register and i've used and expanded on this method since. Check out my ModuleManagerListener where it allows the module to register and live in a namespace on install from module manager. Having @adunsulag module skeleton is terrific but remember, it is designed to show all the capabilities of modules and the preferred work flow for the various actions not necessarily all of which is required to be present. So two thing caught my attention with this module: autoload and Patient Menu. I really like this module and I think it is necessary in a majority of installs. In fact it wouldn't hurt to enable by default! lol no please don't do that. |
@sjpadgett, I have already pulled down the module. Again, that is why I want to refactor this module to take advantage of the advances in the module ecosystem. When I first designed the module. I talked with Stephen briefly about it and the Patient Menu. Again, since there was no way at the time of injecting in the that menu. We opted to do the replacement which added the Prior Auth to the patient menu. Now, I should be able to expand the injection process to the patient menu. The other reason, I personally us an autoloader is sometimes I use PHP SlimFramwork in my modules. I like my modules having its own router. It gives me clean URL and decouples stuff like you using Phreezy. A lot of this stuff is just a matterr of preferences in my opinion. Of course we have to bow to the leaders of the gang of coders. There are still things I can't see yet but I will get there in time. So, I will refactor the openemrbootstrap.php file to include the class loader. Create a Bootstrap.php class in the /src and put in a really basic router. I am going to add and interface for the different prior auth providers or it may be better to use and abstract class. I will figure it out when I get closer to having a provider to work with. |
@sjpadgett That's fine @juggernautsei it's your module and I'm really happy you contributed it. Can't wait to see outcome |
@trafficpest, I have a question about the graphic at the top of the List report. @sjpadgett I have completed the refactoring of this module. I will post a repo and link to it. I will haven't found any insurance prior authorization providers yet. I am running into the same thing as with the most anything else. They want to know how many providers are there, what is the volume of blah blah blah |
@trafficpest @juggernautsei |
@sjpadgett I will work that out. Here is what is looks like now. |
Yes. The idea is to be able to have a quick, single view of authorizations as a whole. Sum all your active authorizations so you can tell normal ranges, etc. It wouldn't be a bad idea to capture some data points to show trends, but I think its not worth the effort. Main reason is to quickly see if people doing auths are doing their jobs. |
@juggernautsei, sorry for the delay. I have sent an invite to you to be a collaborator and push code to my repo. Side note: She already has me busy training employees at different locations, dealing with data migration, and, on top of that, I'm tasked with writing a Braintree payment integration module (her processor) that takes copays automatically on check-in. I'm tying it to arrival on the calendar, as I couldn't find an event for encounter. |
@juggernautsei, I see you're adding more than one CPT code in the string, and the way I changed the SQL to match the CPT and billed units, that would fail. I changed the label text from the plural CPTs to the singular CPT. Most authorizations have different units permitted for each service code, so the provider needs to add each one independently. The form could be changed, or the match condition could be changed from '=' to 'IN' in the SQL. |
@trafficpest , We need to add an explainer on how to use the feature. So, people don't have to guess how the system is set up. I looked for the invite. Can I use your screenshot in the help file? I have pushed my changes. |
fixes #9030
Prior Auth bug fixes and Features
fixed date type hint bug on a funtion when adding new auth
changed CPTs to CPT since you can only add one singular at a time
Removed duplicates rows in global report
added pie graph of % of all auths used on global report
Added bar graph and percent in tables of patient auths and global
auth reports to easily see how many auths you have remaining.
To know when to reauth quickly
It is color coded green 67-100%, yellow 34-66%, red 0-33%