The Eye Exam form is ready for a review. Although I am sure there are some translations and other such issues that will come up in the review, I think the form is ready for testing by the community.
The latest commit working off of Brady latest codebase is here:
This is a big form with several “sections”. Even if you are not an Eye Doc, please feel free to comment on any section(s) that may make sense. Like any clinical document, the most important sections are:
HPI
PMH->PMSFH->ROS
Clinical data specific to eye docs
IMP/PLAN
Report/PDF
I do not really know how else to get it reviewed/tested other than ask anyone who can, to look at least one section. I am working on adding tool-tips and the wiki and minor flow issues across the form. At first it may seem complicated but my hope is you will find it to be intuitive and easy to navigate. Please let me know where it breaks or the work flow doesn’t “flow” as you would naturally expect.
I am trying to get other developers more involved in the review process, since code reviews have been a bottleneck to the OpenEMR project for some time. So please feel free to review, review, review
I am still new to git and the development process.
When a bug is found, do we announce here the code review should occur from a new starting point?
If a reviewer is using the demo server, the new code is auto-updated every day (12:32EST).
Do some/many/any people download the whole branch and test it locally?
If so with each change do they redownload the changes/updates?
Do reviewers go through the code line-by-line or play with the interface or both?
Are there different names for reviewing the code itself and testing the look/feel/functionality of the product?
Either way, I found a bug in assigning a PMSFH item to the issue list and here is the commit:
Regarding phpmyadmin, we had to upgrade to a new version to support PHP7(and the new version of phpmyadmin requires PHP5.5+). Are you using the XAMPP package? If so, the XAMPP package also comes with a version of phpmyadmin that you can use.
Regarding bug fixes and ongoing work, recommend that you just keep working in your current-work branch and adding commits there. A code reviewer can first review your main commits I listed above and then take a look at the proceeding commits. And at some point after this review cycle, we will then rebase all your work into another commit for another cycle of reviewing. It will be helpful to focus your current-work branch on your eye form and avoid placing unrelated code in there(for example, during the next rebase, I will likely separate out your theme file and encounter/provider work into separate branches).
Also to answer some of your questions, this is dependent on the reviewer and on the code being reviewed, but here is what plan to do in this case:
checkout the remote branch on git and do a sanity test on it locally (I have a script that fetches/updates everybody’s repo, so whenever I do this I am testing the most recent code).
I am interested in familiarizing self and staff. Had a local IT man load 4.2 open EMR and the eye exam to a laptop. Although I, was able to explore the earlier version in local host mode, ths may to much program for a lap top to handle can’t seem to load before timing out.
He is seeking to load it to a server we bought for exploring the possibilities.Any advice is welcome. Should we employ the older version of oerm for this experiment? Other tips are welcome.Thanks.
Scott
This feature is getting close to getting into the codebase (currently migrating over to the packages in public/assets and then I think the only thing that needs to be then looked at is use of documents).
Ray’s eye form was just committed to the codebase(and will be in OpenEMR 5.0.0). Can use it at Encounter->Clinical->Eye Exam. Thank you Ray for contributing this amazing form!
