I’m pretty much a notice at using AI and most of you have probably figured the following out. However, I learned that I can use it to perform a variety of tasks in OpenEMR coding and analyzing. This may have been brought up before, but here is a summary of my findings:
ChatGPT (or your preferred agent) can analyze DB queries embedded within php files. All I did was upload several important php files, such as demographics.php, demographics_full.php, stats.php, stats_full.php, and files dealing with calendar. For a few tables, it asked to see the current indices, but within a couple of minutes it gave me sql commands to create a whole slew of indices (composite indices) that were missing that sped up the system tremendously. I mean, OpenEMR is now flying for me. It showed me ways to log slow queries and copy and paste to it, so it analyzed further and gave additional suggestions. In addition, it offered to change some queries in the php code to quicker, more stable ones, but I passed on it for now, as just adding those indices helped so much! One thing it noticed, for example, was that the calendar events (I think it’s openemr_calendar_events or something similar) that basically pulls everything for the calendar has field pid stored as text, whereas all other tables have it as bigint. That made a huge difference, as even indices will not help if mySQL has to convert every text to number and compare.
I now have my first fully AI-created report. Unlike my previous endeavors with OpenEMR, I did not write a single line of code. I uploaded a representative report php file and provided some information on what I would like to see and basic functionality. It pulls up photographs available for a patient and can create a printable report with side-by-side photographs (great for cosmetic cases, surgeries, etc). It can rotate photos, zoom in and out and create custom labels for photos on the report. In the code that it came up with, it even has extensive comments. I can provide this report to whoever wants it, but it looks great! And it only took a few minutes to create (I had to make a few changes after the original, but only to improve the functionality).
I think this could serve as a kind of call to action to better the functionality of OpenEMR in terms of improvement of what is already in it. Tables and indices have to be optimized, some queries have to be improved, maybe even some logic in various places. As we continue to enlarge the scope of OpenEMR and create new functionality, I think it would be important to optimize what is already in it and build upon that. And I believe that AI can REALLY help with this step by removing the need for hours and hours of this manual labor.
Let me know what you think or if you want the new, AI-generated photograph report.
If you found changes that would improve DB performance, we’d certainly welcome a pull request We are doing a lot of work right now to improve DB-related tooling and systems, so that would slot in nicely.
We’re using AI pretty heavily, especially when performing refactors. Like any other tool it’s not perfect, but it’s able to tackle a lot with low or sometimes zero intervention. One of our goals is to improve the process for AI-supported contributions - claude.md improvements, better documentation that it can leverage, etc. @kojiromike may have more to add here.
Thank you for sharing this. The work around query optimization and AI-assisted refactoring is especially useful to see in practice. I’m currently working on a Week 1 sprint focused on introducing a modular AI agent into OpenEMR with three requirements: a deployed agent, an evaluation framework, and observability wired in.
My approach is to keep all new work isolated, avoid any disruption to the existing codebase, and align strictly with repository conventions and contribution guidelines.
Given the direction you mentioned around improving AI-supported contributions and DB tooling, I’d appreciate your guidance on one point: From your perspective, where would an AI-assisted system provide the most immediate value to OpenEMR today without introducing risk?
For example:
Query optimization and DB performance analysis (like Alex’s work)
I’m aiming to ensure my implementation aligns with real priorities from contributors actively maintaining the system, rather than building something theoretically useful but practically disconnected.
If there are any current efforts, constraints, or “avoid this” areas I should be aware of - especially around DB changes, schema assumptions, or AI-generated contributions, I’d value that context.
I think the most effective / least hazardous first step is to improve the current queries in OpenEMR, whether through additional indexing (that’s the simplest way to improve performance without breaking anything) or through finding logical holes or edge cases and eliminating various inefficient queries (such as N+1 queries). This alone will speed up the entire system and should be done as first priority, since they have very little chance of breaking anything and can significantly improve what’s already working. And all that needs to be done is to upload at least the major components of the system (calendar files, demographics.php, demographics_full.php, stats.php, etc) into AI and asking to see what kind of issues it can find. It is actually a pretty good QA tester as well!
The second step is to identify those areas of OpenEMR that need most urgent attention that could be useful to the users (not the developers, but actual users), such as improvements in UI, clinical flows, and general efficiencies. For example, I have now implemented ways to upload fee schedules for various insurances into my OpenEMR and to calculate patient due amounts based on insurance accumulations, as well as to flag insurance underpayments. And this is all AI-coded. Significant improvements to workflows are, in my opinion, a major priority for OpenEMR development.
The problem is, the current system of trying to get code into the main system is, in my opinion, very archaic and does not allow for fast development of major improvements. My proposal would be to ask actual clinical users for their input on features to implement, then quick implementation using AI, followed by independent AI-assisted review of code and potential implications (logic problems, edge cases, breaking previous code), and quick addition to the main code. This is especially true for changes that will not break anything. Additions to the code should take around a month to keep pace with what individual users, such as myself, can implement themselves using AI. This is the beauty of the combination of open-source software and human-guided, AI-coded development. This would ensure that OpenEMR remains an excellent out-of-the-box tool rather than a nice system that one needs to tweak extensively to get to where it’s useful in clinical practice.
We are doing a lot of work right now to improve DB-related tooling and systems, so that would slot in nicely.