I have finally gotten my project for keeping track of Batch file submissions and EDI response files to a point where the basics are in place and it seems to work reliably. This is something that would go into the Contrib section since it is only useful to people who use x12 837 Batch claims submissions and receive x12 response files like x12 999, 277, and 835 files, as well as Availity clearinghouse response files.
I have not tried to actually integrate it into OpenEMR, and that is the next step. Right now it works as a stand-alone web application. What is needed is code for user permissions/access control, a place in the menu, and getting the directory paths right, and some more things, no doubt. Hopefully, the integration part is relatively simple, but I feel some collaboration here would be very helpful.
This project is for people like me who do billing and want it to be easier to decipher responses, troubleshoot errors, and just know what the heck is going on.
If you are interested, the Readme.html goes over the installation and usage for testing purposes and from there, I would like to figure out how to make it available as a Contrib addon.
This is a lot of code
Suggest integrating it now, which will make it easier for testing by others etc.
To integrate, suggest in OpenEMR:
1. Make a library/edihistory directory and place all the php library files (stuff in edihist and would also peel off all the functions in edi_history_main.php into another file and place into this library directory).
2. Place the edih_view.php and the edi_history_main.php (after all functions removed) into the interface/billing directory.
3. Place a link in left_nav (agree with bottom of Fees section) going to the interface/billing/edih_view.php script
4. Place javascript stuff in library/js (if not there already)
5. Place css stuff in library/css (and images folder is here also)
6. In the edih_view.php and edi_history_main.php scripts, add to top(php code):
(just a starting point, but then can get things right (agree with using openemr/sites/*/edi/history) by utlizing the OpenEMR paths and OpeneMR functions and OpenEMR access controls.
Kevin - if you don’t have the time (or energy) to do this integration MI2 will volunteer a programmer for it. Modifications to support formats other than Availity can be an exercise for later …
I am presently reading over the Git for Dummies and working on bringing my OpenEMR branch up to date. I will follow Brady’s suggestions, which make sense. There is a lot of code, but I tried to follow patterns so that the era file scripts are similar to the 277 script, etc. Also, there are a multitude of x12 item code definitions and that takes a lot of space. Besides, I had to learn about x12, php, and javascript, so there is probably a bit of inefficient or pointless code remaining at places.
MI2 will volunteer a programmer
Thanks for that, Tony. If you think this is a “value add” that customers will like, then by all means. It would be good to have spent some time so that your folks understand the code and maybe spot some easy improvements, so it could be a worthwhile investment of time. However, I know that time is valuable and coding projects always take more time than they are supposed to.
One thing that is unfinished is reading 271 eligibility responses. I had nothing to work with but some “implementation guides.” Customers would probably like to be able to submit 270 eligibility inquiries and decipher the responses. I know you can do individual requests with Availity and various others, but the time and password/link hassles are a pain. As implied, there is likely no end to the possibilities.
Created branch edihistory at https://github.com/kevmccoroff the openemr I had pulled from a few days ago. The main issues I am addressing are (1) making sure directory paths are correct and (2) putting a link in the left_nav frame.
Kevin I’ve not looked at this much, but are you familiar with the code already in OpenEMR that parses 835 files? If not, see library/parse_era.inc.php. Also if it matters, note that the “claims” table is a log of claim submission activity.
Yes, I have looked at the 835 parsing and what my code does is actually create useful RA’s on demand, i.e. select file, get RA. I tried to be as complete as I could since the existing code really focuses on just enough (not quite) for reconciling payments. There are several parts of the database that could be usefully queried, especially the claims and the payments, but I just don’t have the time or knowledge to do that as of now. The project is completely designed around batch and response files, with no outside information used. Yes, it would be better to use some data from the existing tables.
It looks like I am using OpenEMR 4.1.2-dev, which I mistakenly patched with 4-1-1-patch. I get this error in the left_nav frame when I try and load it:
ERROR: query failed: SELECT * FROM code_types WHERE ct_active=1 ORDER BY ct_seq, ct_key
Error: Unknown column ‘ct_active’ in ‘where clause’
This occurred before and after the mistaken patch and I can’t find the query.
Also, this error appears in the httpd error log:
PHP Fatal error: require_once() : Failed opening required ‘formdata.inc.php’ …
Apparently included by /interface/main/main_screen.php
Need to upgrade your testing database to 4.1.2 via the sql_upgrade.php script. Note I generally just completely reinstall openemr anew (ie. drop the database completely and run the setup.php script) when developing/testing code.
Also, you will need to change the left_nav link path to:
billing/edih_view.php
It seems to be working now in my test installation. It took a while to figure out how to handle the directory paths and I am wondering how they will work in different installations. I have not tested extensively yet. Testing is mainly uploading response files and seeing if the bell and whistles work. I used the existing jquery-1.7.2.min.js, jquery-ui-1.8.21.custom.min.js, and jquery.dataTables.min.js.
Also, I used the jquery-ui-1.8.21.custom.css and jquery.dataTables.css. I would like to reduce the font size because it is hard to fit things into the top frame and now the fonts cause everything to be too large. The css file I wrote, edi_history.css, can undoubtedly stand some improvements as well.
Since I envision this as a “Contrib” or optional feature, how does one go about setting that up? I see some statements about the global configuration, so I guess that is where I should look.
Some quick things to do before doing a full-fledged review (I’ll show you how to rebase your code into one commit at that time):
1. Use a consistent menu link title. Seeing ‘Claims EDI’, ‘EDI History’ and ‘Claim History’ (this one in comments at top of edih_view.php file) in different places. Suggest picking one that laypeople would understand.
2. Suggest adding the global at Adminsitration->Globals->Appearance->(below ‘Enable Fees In Left Menu’). This is actually simple to add in the library/globals.inc.php file (search for ‘enable_fees_in_left_menu’ and simply copy/paste it below this and then fill in your info. Suggest turning it on by default for now (can consider turning it off when release 4.1.2, but much easier for testing etc. to turn it on by default for now).
3. Note that openemr/sites/* will not be writable in most installs. Suggest instead checking to ensure openemr/sites/*/edi is writable and place all files/logs within this (such as the history directory etc.).
4. Migrate the README file to openemr/Documentation directory
After above is done, then I’ll show you how to compact the code into one commit for a full-fledged review (can then go through translation, escaping, access controls, not geeky button label text, etc/; note this shouldn’t be to extensive since your actual display code is not to big).
Note that openemr/sites/* will not be writable in most installs.
I did not think I tried to write or check there. I thought the ‘writeable’ tests were all at least openemr/sites/default or whatever one gets from $GLOBALS.
place all files/logs within this
Yes, all files are placed in /openemr/sites/<sitename>/edi/history/<dirname>.
Except, I expect the batch files to be in $GLOBALS/edi. If someone uploads a batch file, it will match an existing file and be ignored.
Except, with the log, I have the problem of logging a failure of the setup() in a directory that was not created. I put a test in the csv__edihist_log() function, but I don’t really like a test for a one-time situation.
Suggest adding the global at Adminsitration->Globals->Appearance->(below ‘Enable Fees In Left Menu’).
I gave it a try. Also, I moved and renamed the Readme file.
Latest revisions just pushed to edihistory branch.
Hi Kevin,
Let me know when your done with modifications, then will do a full review (I’ll rebase your 23+ commits into one and then just review it on my github account).
-brady OpenEMR
Tomorrow always brings a new perspective on things that need to be changed. I have made a good number of code cleanup changes - removing useless comments/notes, unnecessary code, etc. I even found and fixed a couple of little bugs. I may not be “done” with modifications, but right now I can’t think of any more. Amazingly, it still works.
To see my comments (44 of them), search for bradymiller on the page. (note all simple stuff to do, then it should be ready for committing to sourceforge).
I suggest you now work from this branch, which can be done by doing in your openemr repo:
git remote add brady git://github.com/bradymiller/openemr.git
git fetch brady
git checkout brady/kevmccor-edihistory_2
(ignore the error)
git checkout -b edihistory_2
(you now have your own local branch with this code at edihistory_2)
(do some work in it and then can start pushing this new branch to your github repo)
I did the edits you suggested for /interface/billing/edih_view.php, and /interface/main/left_nav.php, and the copyright info in edi_history.css.
You commented that I should not put the log file in /sites// and I agree, but it is only there during the setup() function, prior to creating the file storage directories. I did that because I do not know where else to put it and I thought it would be better to have something more permanent than echo ‘error message’. I don’t think it is all that important, so I’ll change it.
I pushed to the ‘edihistory_2’ branch.
You commented on the “define(‘SITE_IN’, 1);” concept of restricting access. I think the /library/edihistory script functions should have restricted access, because they could be used to see protected information - that is what they are used for - so only authorized users should be able to use these functions. The “define(‘SITE_IN’, 1);” is a pretty simple technique, requiring that the main script has to be loaded first. Some other OpenEMR files use the same idea. I tend to think some sort of session check would be better, but I don’t know and would need some guidance on the session topic.
It is a lot of code, but there are lots of x12 ‘code’ references, and each x12 file type has its segment id’s and codes, so there is a lot of tedious "if (this) elseif (that) "
One question I have been wondering about is the jquery javascript in edih_view.php. What should be in the $(document).ready(function() … and what can be outside (and what difference does it make)? I have an idea, but since it worked, I left it as is.
Putting the code in $(document).ready makes it so that code waits until the document is fully loaded before running.
It looks like what you are doing primarily is binding events, and since you have already declared the elements you are trying to bind to at the point where you introduce your javascript code, you actually don’t need to wait until for the “ready” event to fire.
If you moved all that event binding (and jQuery hooks) code to the top of the file (before your HTML) by using .ready() things will still work, but if it weren’t wrapped it won’t work because for example $("#tabs") won’t resolve because it wouldn’t have been declared yet.
Clear as mud. I want things to be fast, but from what you say it won’t make any difference in speed. Also, now that I think about it, there is a “flash of unformatted content” when the jquery-ui dialog opens. You see the old content momentarily or whatever. It is fast, but not as smooth as I would like. There is the main html output, with links to things like response messages or claim segments. These links are “bound” to the jquery-ui dialog, and even links in the dialog content are similarly bound. In my mind, the parts I would like to improve are in the css and jquery-ui area. I decided that I could spend infinite time on perfection or I could get something out that people could use, and myself and others could improve.
