+
Skip to content

Conversation

trafficpest
Copy link
Contributor

@trafficpest trafficpest commented Oct 3, 2025

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%

Jason March and others added 4 commits October 2, 2025 17:54
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
@trafficpest trafficpest changed the title Prior auth Prior auth bug fixes and features Oct 3, 2025
Copy link
Contributor

@kojiromike kojiromike left a 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.

@kojiromike
Copy link
Contributor

Is there an issue for this PR? We will need one, IIUC.

@trafficpest
Copy link
Contributor Author

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

@adunsulag
Copy link
Member

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

@trafficpest
Copy link
Contributor Author

Is there an issue for this PR? We will need one, IIUC.

#9030

@trafficpest
Copy link
Contributor Author

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

@sjpadgett
Copy link
Member

I think this is going in a good direction.
The last PR was basically bug fixes and user interface consistencies. I do wanna pull it down and test later tonight.

@juggernautsei
Copy link
Member

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

@trafficpest
Copy link
Contributor Author

@juggernautsei
Note: the SQL count incorporates auth code + billed units of service code + service date to get an accurate count. My sister-in-law gets auth codes that include a date range and more than one service code each with different billed units. So now you enter amount for each code with auth. Thank you for the module, it was really helpful!

@trafficpest
Copy link
Contributor Author

This should be good to go now. I haven't tested since all these minor commits but I think it should be good.

@juggernautsei
Copy link
Member

juggernautsei commented Oct 4, 2025

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.
@sjpadgett I noticed that there is a cdn reference. Is this permissible?

image

@juggernautsei
Copy link
Member

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.

@trafficpest
Copy link
Contributor Author

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. @sjpadgett I noticed that there is a cdn reference. Is this permissible?

@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?

@juggernautsei
Copy link
Member

@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.
@adunsulag said something to me a long time ago that stuck with me about polluting the OpenEMR namespace with my modules. So, from that point forward, I started putting my modules in their own namespace to keep it separated out from the OpenEMR namespace. Then he went and built the function/feature to load the module namespace into the main autoloader. Which frankly baffled me. But I still build my own namespaces most of the time.

@sjpadgett
Copy link
Member

So what's the question?

  • Should we be using autoloader? Depends! Does the module require dependencies that core doesn't provide? For instance, install a new widget library that may only be used by module and wouldn't serve core in any significant way however makes the module great. Then this would require an install mechanism where a package or composer run is needed.
  • So what's in a namespace? If a core module I use openemr's module namespace and register from bootstrap(my preferred method). You can still have a composer json that describes the module and its PSR-4 pathing. I haven't yet needed to specifically run an autoloader specific to my modules.

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.
This method may have some limitations solved by composer PSR-4 handling. I do both. However IMO if you need to run an autoloader that resides in the module then we missed it in integrating module into core where it was a third party install previous.

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.
First autoload call shouldn't be needed and figure out and register your namespace. Second: whenever modifying the menus in openemr, existing menus shouldn't be removed or renamed unless a specific reason is given and admin is aware on module install. This is especially true for the Patient Menu and should stay intact due to items required for ONC. Add to but not take from!

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.
@juggernautsei Are you going to pull down and help @trafficpest test and resolve the autoload issue? It'd be worthwhile instead of you doing mod's later after this is merged to help author resolve. I'll help if needed

@juggernautsei
Copy link
Member

@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
Copy link
Member

@sjpadgett That's fine @juggernautsei it's your module and I'm really happy you contributed it. Can't wait to see outcome

@juggernautsei
Copy link
Member

@trafficpest, I have a question about the graphic at the top of the List report.
The graphic is adding all of the units from every patient in the system together. Is that the way it's supposed to work? It doesn't seem helpful to me, but I am not the provider.

image

@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

@sjpadgett
Copy link
Member

@trafficpest @juggernautsei
Sherwin, I believe you should be able to push your changes to a branch in the authors repo where he reviews and merges into his PR repo.
Once that is done we can merge to core.

@juggernautsei
Copy link
Member

juggernautsei commented Oct 8, 2025

@sjpadgett I will work that out.
I don't have access to push changes to @trafficpest repo. I am stuck at this point

image

Here is what is looks like now.
https://komododecks.com/recordings/LgwT4CEEUwissyjkILWt

@trafficpest
Copy link
Contributor Author

@trafficpest, I have a question about the graphic at the top of the List report. The graphic is adding all of the units from every patient in the system together. Is that the way it's supposed to work? It doesn't seem helpful to me, but I am not the provider.

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.

@trafficpest
Copy link
Contributor Author

@sjpadgett I will work that out. I don't have access to push changes to @trafficpest repo. I am stuck at this point

@juggernautsei, sorry for the delay. I have sent an invite to you to be a collaborator and push code to my repo.
In the end what did you do with the module autoload? rewrite the bootstrap or just return the require in file?

Side note:
I have bad news for you guys: I got my wife's therapy practice to switch to OpenEMR after seeing it at my sister-in-law's ABA practice. Now you'll probably be dealing with me every once in a while, haha.

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.

@trafficpest
Copy link
Contributor Author

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

Screenshot From 2025-10-07 23-16-59

@juggernautsei
Copy link
Member

juggernautsei commented Oct 8, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Prior Authorization Management Enhancements
7 participants
点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载