I upgraded to the current version today. No build versions seem to exist, so that is as good as I can say.
First go at it looked good, but the menu (formerly on the RH sidebar) for forms was posted vertically over the encounter summaries. This was identified after I had updated the production install, so I had to revert quickly. I then attempted the install on a test machine again, and noticed that this time it more clearly appeared to have a broken css (no BG colors, bad formatting etc). I got to the globals setting and changed the css to sky blue. Immediately, everything, including the new forms navbar (with me seing it for the first time), worked. I checked globals.php, and saw that after changing the style, the setting recorded there was still “$css_header = “$rootdir/themes/style_default.css”;”, still the same as matching the package that I downloaded. All the above cases were the same in IE as well as FF.
Make sure you clear your cache on all the machines that you are testing on. What you are describing was the case on all of our client machines connecting to our production server. The current release does exactly what you describe until after clearing the cache. After there are drop down boxes to show the forms. You have to click the “clinical” heading.
I have noted that the bar between the navigation on the left to the right pane is always resetting to about 2/3 of the width of the buttons on the left which is a minor irritation since it still works correctly but just detracts from the prettiness of the new buttons.
So far we are in full production on the 4.0 dev-tip. Our date of download was about 03-14-2011. We are running OEMR 4.0 pre-release and having very little problems.
“I have noted that the bar between the navigation on the left to the right pane is always resetting to about 2/3 of the width of the buttons on the left which is a minor irritation since it still works correctly but just detracts from the prettiness of the new buttons.”
I am not sure if I get you right but you can change the default navigation area width at Admin>Globals>Appearance. The default is 130. I have mine at 172 and is working great. OEMR defaults to this globals setting at logon.
Got the upgrade from the daily snapshot. Upgraded from the 9FEB version 4.0. No dev version/build ID’s on anything from what I have seen.
The reason I was having “problems” and doubting my upgrade methodology was due to the seeming errors that were really just .css differences. I set my browsers to not keep a cache between instances (dumps all on exit) but who knows if I actually had all instances closed down. It is possible also that the previous version of 4.0 I was running also had .css tweaks. At one point (when running 3.2 up until Jan 12) I had fully modified logos, css, and even some of the style hard code messed with.
Speaking of styles, now that the right navbar in the encounter view/controller is gone, how about spreading the notes out to the full %?
Next item: Patient record report interface has no direct link to the patient summary page (oh gosh, making us use the sidebar!). This is not a killer by any means, but one of our counselors had already (between 9am and 930) gotten used to having the equivalent of a “back” button in every page, so was stumped and yelling “it’s locked up!” when she could not find a back button. She did not even feel stupid when the tree menu was pointed out. “That’s a pain in the ass!” she said. “You TELL them that’s a pain in the ass!” she further ordered.
-Just following orders.
What i have done is to remove the categories. In Admin>Other>Forms, I give the category the same name as the form-or a shorter name if the form name is too long. This shorter name can also be entered in the “Nickname” column on the same “forms” page. In this way, I get “Vitals”, “Fee sheet”, “Procedure order” visible individually above the encounter summaries instead of having to figure out which category contains what form. This is not a good idea if you have very many forms active. Also the buttons do not act as a direct link but contain one item of the same name that can then be easily accessed.
aethelwulffe: God, your name is a tongue-twister, next forum you join, find a name like “john” or something:-).
Anyway, I agree that we should have a clear “Back” button on every page. Sometimes i resort to right-clicking and selecting "back "-from Firefox menu. Occasionally, this resets everything and I am presented with a screen similar to one met immediately after log-on.
Suggestion for Future: To save screen real estate, could we make the text area in forms “hug” its contents so that we do not have plenty of redundant space in forms. A good example is New Encounter Form. Here, there is a large text box in which all that is usually present when form is expanded is “(visit) reason” and “facility” followed by plenty of empty space. Many forms (except CAMOS) behave in this manner.
So far we are in full production on the 4.0 dev-tip. Our date of download was about 03-14-2011. We are running OEMR 4.0 pre-release and having very little problems.
Dr. Bowen,
How do your users react to the lack of a “back” or “close” button on the encounters screen? There is a lot of checking of past encounters before/during visits and my users would be annoyed immediately. I would never hear the end of it.
Mukoya…I’m not so sure about your handle either :) Anyways, it’s “Art” to you.
Currently, normal aspect screens seem to have a lot of wasted space on the right side, and scrolling is the most common mouse interface used. On widescreens, we are only utilizing half the screen in the EMR. I do not believe this is true for the documents interface however (just looking with my mind’s eye). Ultimately, being able to split the screen to vertical or horizontal views, or even using unpinned frames of some kind would be very useful. Instead of top/bottom view controls, having the two views watermarked with a 1 and a 2 in the corner, or even having a “red and blue” view that uses color coding to differentiate which view you wish to work on would be really nifty I should think. Really, I should check into using the EMR in a multi-display environment….but I guess multiple session ID’s and at least two instances running would be needed to allow really good displays for review or document comparison.
Ah yes, the patient name is far better. I’ll make sure to point that out.
I did not happen to look at the documents controller/section before I played around with globals, but I unchecked the flag for “hide documents encryption”, looked at it, saw what it looked like, and then when back and re-checked it in globals. Today, while looking at the documents, I see “validate Sha-1 Hash” and all that. I checked the globals, and “hide” was still checked. As this is a different machine, I doubt my net cache has anything to do with this, so I will attempt to play with this in the demo and see if I this is a verifiable issue.
OK so the Hash is the document validity check (whatever that does) and not the encryption manager. I am not seeing any reference to it in the 4.0 manual however. The screenshot in the manual does not show that feature either. I see this same item in the Demo http://opensourceemr.com:2097/openemr/
'splain?
hey,
The hash and encryption features were just added to get OpenEMR ONC certified as a modular EHR.
hash: simply stores a hash of your document in the database. thus if your document get corrupted/modified then the hash will change and not be the same as the original hash (it’s very simply now, but this will lead to a richer feature set in the future).
I was wondering if the hash check just creates a new value and compares it to an original. I was a little confused at first, but now I see that with the implementation of the feature, we did not include a script that creates and stores a hash value for all preexisting documents, so we are just sort of “picking up where we started”.
It’s great to lay infrastructure, but is it wise perhaps to be able to hide or perhaps rename this very hostile-named feature (like simply “document validation check”), or perhaps put the interface under the document frame? It’s a little hard to explain to a dispersed group of people that only possess slightly above average intelligence and no …apparent knowledge… of anything outside their particular specialty what the heck this is. I attempted to tell them “well it’s kinda like a checksum for documents you need to verify as being original or unchanged”….blank stares… really blank stares.
I was just looking at your wiki docs for this feature. Seems like it indicates that by default, the encryption feature box is unchecked by default. I have looked at globals.php in a 22mar snapshot, and this is not true. The feature is turned off by default.
aethelwulffe,
The SHA-1 hash stuff was a quick feature added to get ONC certified as a modular EHR and is a bit rough; agree there is room for improvement. To avoid confusion, decided to turn off the encryption feature by default.
-brady
“Admin>Globals>Appearance. The default is 130. I have mine at 172 and is working great. OEMR defaults to this globals setting at logon”
Thanks for this tip.
“but one of our counselors had already (between 9am and 930) gotten used to having the equivalent of a “back” button in every page, so was stumped and yelling “it’s locked up!” when she could not find a back button. She did not even feel stupid when the tree menu was pointed out.”
Actually, you can simply click on the patient name and get the same result. I have to admit having to go to the navigation menu, expand the clinical and then click summary bothers me too. The couple of extra steps cause enough time delay to slow things down.
“Speaking of styles, now that the right navbar in the encounter view/controller is gone, how about spreading the notes out to the full %? “
The plan is to move the encounters section to the summary page. The current blank space will become filled with the “Problem list” on the Summary page. The goal is for the patient summary page to become the “patient dashboard.”
Access to the summary encounter page in 4.0 is available from the “encounter” pull down in the title bar as are hot links to the active patient record and the active encounter as well as a quick list of past encounters and a “new” encounter selection. The whole point is to keep you from having to use the left nav menu during the work flow with a patient record.
As to the documents management screen, There is lot’s of room for improvement here. Regarding the SHA1 hash, this is just a way to confirm that a document has not changed since it was uploaded. A ONC-MU requirement. A script to create hash keys on previous documents would be a good tool to write… (Art, maybe?) Some suggestion on clarifying the wording would also be helpful, it’s kind of geeky, I admit
