For many months, the code submissions have been rolling in (which is a great thing). However, it’s been difficult keeping up and some really nice features(for example Ray’s eye form which is simply revolutionary) keep getting delayed. For example, here is my current code review queue:
REVIEW QUEUE:
EXPEDITE:
nothing
NORMAL:
Terry Exclude Insurance
Ray Eye Form
Sherwin prior auth form
Visolve multi-provider bug fix
Tony floating alerts
Sherwin labs form
MD Support PE form
Terry HFCA printout
Sherwin document drag and drop
Art x10 4010 smackdown
Terry Patient Portal Appt Scheduling (check with Terry if ready for a review)
Terry Insurance Inactivate code (waiting for toggle change)
MD Support Apps choices in login (Kevin and Rod review pending)
Figured it is a good time to begin brainstorming on ideas to encourage/motivate developers to participate in the code reviews? Please post your thoughts.
For starters, you may wish to delegate some of the responsibility by moving a few of the developers up the hierarchy.
Terry Hill & Ian Jardine (such an eco-friendly surname) are two names that come to mind. (Terry, your surname would be considered agrarian, if it had been terraced.)
I’m in no position to comment on their coding habits, but the 2 men’s common sense, even temperament & diligence would recommend them for consideration.
Thanks Mouse for the vote, but I am not versed enough as a programmer to adequately review the code for the code base. I am just a hack at best. Rod, Brady and Tony are the top canines for committing the code. I don’t believe Brady’s bottleneck is committing the code to the codebase but it is debugging it, testing it and bringing it to the standards of the codebase. Perhaps the vendors on the certified support page could help with a greater commitment in this area they are after all reaping a harvest from this project.
I can at best just chunk out small fixes till someone with greater abilities than mine comes forward to takeover this effort.
For item 13 (Apps mode) the approach is not sound for many reasons, and the commit does not warrant inclusion or further review.
It’s a neat idea, though. The same functionality could be cleanly implemented with @media specific CSS that hides the nav and title frames in appropriate situations.
Based on external and independently verifiable sources, such as basic demographic information that is stable over time
Clearly and easily distinguished from original information, such as automatic summaries that populate data fields that are clearly identified as nonoriginal and cannot be mistaken for original information
Not actually rendered as part of the record until after a re-authentication process and also auditable for identifying actual origination
The joint commission would also probably frown on this feature too.
My position is not to bring this feature into the code base based on the recommendations of AHIMA and the Joint Comission.
All,
I’m happy to help but I’m more of a big picture, “Does this feature make sense and is the logic good” kind of guy. The language translation, syntactial and injection stuff is (for some reason) invisible to me.
I think we should be using a automated review tool for much of this. There are tools for that, they are not perfect but they may help lighten the load.
PhpStorm does a great job of catching bad, deprecated and ill formed code if more developers used tools like that we would get a cleaner code base.
This code copies previous normal/abnormal settings and observation details from last form but does not save it. I am not sure if asking the physician to type in same comments for chronic conditions is going to improve quality of care - specially when they are to save, review and e-sign those . By same logic one could argue that every issue should be specific to a single encounter and physician should start every encounter with a clean slate!
What we really need is an API that lets external application to validate login, get ACL and session variables (if requested). Real target here is not to strip decorations from existing desktop oriented screens but enable mobile-specific apps with dedicated but limited functionality.
Hi,
From a clinician practical standpoint, the copy/paste mechanism is used in notes and for good reasons; of course, it can go astray if overly done, but we should leave that up to the user/physician’s discretion.(as an example, in my dictations, about half of the note is copy/pasted from the prior note; if somebody told me I couldn’t do that I would not be happy, because then a stable PMH history section would be lost which is very valuable clinically for covering doctors or when the patient gets seen in the ED or admitted to the hospital)
-brady
But what being copied and pasted here is a physical exam, for which new observations must be made every time.
Even for chronic conditions the findings are not necessarily stable. With asthma a wheeze might be present one visit and absent on another. The exam might vary because of time constraints on the physician himself.
Issues are a subset of PMH and are more reasonable to be copied forward as history is cumulative.
The Joint Commission and AHIMIA both acknowledge that copy and paste is appropriate for some documentation, hence the links I shared provide guidance rather than simply forbidding the practice.
I have also copy/pasted the physical exam on occasion (the problem with that on a dictation is that the vitals are in it; if didn’t have this issue, I would do it much more). It’s rather typical for a physical exam to not change from visit to visit for follow up visits(of course, this is dependent on the practice/speciality). From a philosophical perspective, I think it will be better to fall on the side of the physician/user rather than the folks in high towers(ie. leave these types of decisions to the ones in the trenches).
If this is changing the behavior of an old form, though, would recommend making this a global option that can be turned on/off.
Note the LBF/Layouts does have an option to default to previous value, so the demand is there.
Ideally we should write our clinical notes as we did as 4th year medical students with an abundance of detail. As we gain experience, the H & P becomes more compact & succinct, requiring fewer words to convey the essence of our findings.
When physicians are struggling to adapt to their new EHR’s, the luxury of a 15 page H & P is only available to those with few patient responsibilities.
As long as there is not wholesale cloning of the clinical note, verbatim; copy/paste or more preferably, autocomplete of recurrent phrases, is an inevitable result of having to see too many patients in too short a period of time while trying to be compliant with government mandates.
We, as physicians, certainly know how to care for our patients & how to document that care properly, because we spent 8+ years learning that art. Unforturnately those, without the training nor the experience, have it in their heads that they know better.
Re #3, I don’t see a ticket or a place to make general comments. I have this comment:
The “Misc Billing Options HCFA” has a “BOX 23. Prior Authorization No.” field and if I recall correctly, was designed to replace and enhance the Prior Auth form. It is referenced by the $billing_options variable in library/Claim.class.php. Seems like the thing to do is improve that form and not the Prior Auth form.
Here’s the most recent queue of pending code reviews:
ZH Healthcare MU2 Immunizations(plan to commit this to codebase very soon).
Terry duplicate appt bug fix(and other fix in tracking report)(minor and no need for others to review).
Matrix document image thumbnails.
Matrix data entry validation.
Ray eye form.
MD Support onsite patient portal signon update.
Matrix custom assets management; loading of custom js/css into every script.
Terry mod of floating alerts.
Terry exclude insurance.
Visolve multi-provider bug fix.
MD Support PE form.
Terry HFCA printout.
Sherwin document drag and drop.
Art x10 4010 smackdown.
Visolve layout buttons (waiting for theme fixes by Robert).
Terry patient portal app scheduling (check with Terry if ready for a review).
Sherwin prior auth form (issue has been brought up by Rod).
Sherwin labs form (issues have been brought up by Terry and Arnab).
Please, please, please, please feel free to review any of the code review requests listed above. Again, please…
If need a link to find the code, just ask.
With the 2 goals of 1) maintaining my sanity and 2) to not lose track of any code review requests, I maintain the above list on below website (the website is served via “github pages” which is super easy for me to modify the list as items change etc.). Just let me know if your code review request is not on that list: http://www.bradymd.com/todo/#openemr-code-reviews
