We need to handle non-‘ICD9’ diagnosis for our clients. This may be in addition to ‘ICD9’ diagnosis.
This series of patches is one way to achieve this, but I would like some feedback on the approach.
Patch 1: The new library functions should not require much maintenance, unless we start using them so much we have to optimize them for speed. They are only really useful to pass data through an HTTP request, so I don’t think that will be an issue. Just provides developers more tools.
Patch 2: The new interpretation of the codetype URL parameter is mostly backwards-compatible. The encoding used for arrays in patch 1 turns array(“foo”) -> “foo” and vice-versa so single-code arguments are mostly handled. Coding systems whose name contains a comma, double-quote, carriage-return, or new-line will break, but those should really not be in use anyway. For the most part this just adds functionality, with a minimum of overhead.
Patch 3: I would love some feedback on my approach; there are a lot of ways to implement this functionality. It may be better to introduce a ‘diag’ element in custom/code_types.inc.php and fix up existing data. Also, it would be good to get some feedback from anyone using the ‘athletic_team’ or ‘ippf_specific’ features to make sure this is what they want or at least to make sure it doesn’t cause them any issue.
Haven’t looked at your patch code yet, just the narrative. The approach sounds nice! But for #3 I agree that a separate “diag” attribute is better. I don’t see any problems offhand with the athletic_team or ippf_specific cases.
And for what it’s worth, I think migrating this array to a database table and an appropriate management GUI is a likely future enhancement.
Mapping the code_types directly to a DB table seems easy enough, but I’d need to fix-up all the places it is referenced. I also am not as familiar with some of the array elements as I should be (e.g. ‘mod’ and ‘rel’). There are probably some other issues that must be discussed when we want to move it into the database. I will create a separate tracker issue and forum thread for the migration once I get back from lunch.
It would be nice to get these patches in before that migration, since they don’t increase the use of the array too much.
I will also try and re-write the patches (actually, only #3 should be affected) to use a new ‘diag’ attribute this afternoon and update the tracker with a new tarball. Please don’t let this stop anyone from providing further feedback on the patches as they exist now, I can always filter and integrate the feedback into update patches.
The array in its current form could be loaded from the database table by adding logic for that to code_types.inc.php. That way you don’t have to bother with all the places that reference the array.
Patch 1 and 2 remain the same.
Patch 3 is now the modifications to the code_types array in custom/code_types.inc.php.
Patch 4 is the old patch 3, removing the ‘athletic_team’ hard-coded value and using the “diag” attribute added to elements of the code_types array.
Stephen, this looks good, thanks for the patches! I’ll wait a few days before committing in case there are any further changes, and to give others a chance to comment.
Even if developers don’t use git, I suggest you all get a github account and “watch” the openemr repository. For example, Rod, we can comment on your commit and even comment on selected lines of your code if any problems/questions that would then get sent to you (if you are “watching” it). I bring this up, because it’s been working really between Stephen and myself. For the newer developers, it’s a very efficient way to follow along and learn from others and for us to also review your code (if you have your own forks and branches and want us to review or pull your code in).
-brady
We should be aware that GitHub comments are not easy to search for or to link to, so they should probably be limited to rather short exchanges. If it is something the whole project needs to know, or if your question/answer to very long, it would be best to move the conversation back here.
It is easy to link to and reference specific commits, as long as your communication medium has the 16 hexadecimal characters and some sort of delimiter. Of course, if a commit disappears (because it was rebased, for example), you are out of luck, but it is best to notify people and use a branch name if you plan to rebase or otherwise “rewrite history”.
I do appreciate your comments on my branches in GitHub, Brady, but I plan to announce anything I want to commit to CVS here so that everyone (including those that don’t want to be bound by the GitHub terms of service) has a chance to review/comment.
hey,
Agreed not a replacement for official discourse here in the forums, but has still been proven to be a useful tool for questions on code and to point out issues with code. Especially code questions/issues in the main openemr git repository.
-brady
I just tested the code to lists. Real nice but I have a Question.
In 2012 both ICD9 and ICD10 codes will be allowed during transition. Well with that in mind I setup ICD10 in the list (I did not populate it) and sure enough it showed up in the fee sheet.
Now for my question: How do I disable (Dont wanna delete) ICD9?
