So I am in the process of transferring Lytec medical data into openemr. One complaint I am having trouble with from the end-users is that in Lytec you can press various function keys as hotlinks to things like billing. Although I have suggested tabbed browsing and tabbing to text fields, they still feel as if they are using the mouse too much. Are there any ideas how to make things more efficient? Would this require writing a new browser app (major PITA), or am I overlooking some browser features already available?
Perhaps your keyboard shortcuts could be implemented in JavaScript. It may be a little tricky, depending on which browsers you want to support. Looking in the JavaScript Bible, the most relevant items seem to be window.captureEvents(), window.onKeyPress, and <object>.onKeyUp().
I think this is more a problem of details than of generalizations. Could you give one or two examples of "using the mouse too much" so we can get more focused?
Really I think optimally you should be able to navigate the entire system without taking your fingers off the keyboard. I mean mousing around is fine for browsing, but for serious data entry it would be very nice to keep those hands on the keyboard and never have to move to the mouse.
I guess my last post did not suffice for your request of an example. However, i think the original example of billing I started with works best. Say you are on the homepage, find a patient, enter in an encounter and process all the assosciated billing without using your mouse. Not possible is it?
Our current billing system runs in MS DOS. In unix-speak it looks and feels like an ncurses application. There are lots of "hot keys." ctl-A takes me to the appointment scheduler. ctl-L list all charges and payments. +T add a charge, *T to change a charge, -T to delete a charge, +Y add a payment, *Y to change a payment, -Y to delete a payment, ctl-V view todays charges, and so on and so on …
True clerks are keyboardists. They usually type well and are wizards with a 10-key pad. Not having to take their hands off the keyboard makes them much faster.
MS Windows appilcations and X-applications are geared toward point and and click with the mouse. This is useful behavior for a non-typist and is what has made the PC explode in popularity.
OpenEMR, as a Web-based application, is much more like “cruising the Internet” with a mouse. It is a 3 tier application where the first tier is the user’s browser. The second tier is the business logic of OpenEMR, the third tier is the SQL backend where there may be stored procedures.
True keyboardists never want to touch the mouse because it slows them down.
To do this, the Web pages will need to respond to combinations of keys to navigate to a different Web page while maintaining the session ID.
A typically better solution would be a runtime client that is installed on the local PC. This of course is the way GnuMed operates using Python and wxPython. It is easier to get a runtime client to be aware of keyboard input. The C language (not C++) excels at this and is the major reason the Gnome desktop uses C as its language.
The top bar across the top serves the purpose of the “hotkey pad” fairly sufficiently. Maybe if we could incorporate the java script stuff colpa was talking about it would work. Although I think Dr. Bowen is spot on if he’s talking about a proprietary client that was just a hotrod browser built for openemr. But, and maybe I’m wrong, that sounds like a major task.
I did a lot of research prior to making the decision to go with OpenEMR.
The problem is, browsers do not track mouse movements and keyboard entry the way other programs do. Because of the remote distance between the typical server and the typical browser-client the interaction is intentionally stateless. It doesn’t matter to the server whether the client responds in 15 milliseconds or in 15 years.
The only reason that OpenEMR cuts you off at all is that there is a piece of code that counts time from the last entry and cuts you off if you took too long to respond. This is not an inherent feature of the server-client interaction but was added because it is required by HIPPA.
The server-client interaction (for the most part) is completely independent of the OS running on the server and the OS running on the client. It allows a practice to use already existing hardware.
What I am talking about is a run-time client. These are like the normal programs that you use on your desktop every day. They are not browsers.
Writing a run-time client is like starting a completely new project from scratch. It has to be installed onto your local PC like any other piece of software. This includes navigating the minefield of getting your software run-time client to install on multiple dramatically different OSs.
We might be able to emulate some of what the keyboardists want with javascript, perhaps with the "hotkey pad" suggested by Emily, but we will not be able to completely able to do this with the "stateless connection" of the usual web browser.
I am in complete agreement that building a front end that runs on the client would be a huge undertaking. Especially if the entire thing was rewritten from the ground up. Can an existing codebase be adopted?
I mean maybe just a few tweaks to mozilla/firefox? Or are you talking about moving the php processing as well to client? So that just database calls are going to server?
There are really quite a few ways to go about this. And I’m not even sure why stateless interaction is a bad thing. And what advantages would be able to utilize with it?
Anyhow, I really do like OpenEMR above the other offerings as well. I just want my end-users to feel the same way.
I’ve got to agree with Dr. Bowen. Multiuser database use in business appears to be heading in this web-based direction, rather than client-server (i.e., it’s not good because I agree, but because a lot of people do).
Tweaking mozilla/firefox would be a huge undertaking, because they are huge cross-platform projects. But all modern browsers are already designed to be tweaked, with JavaScript! Yes, there are minor, surmountable cross-browser issues but these are well understood. JavaScript is mature and, I believe, underutilized in general.
As to the HIPPA-required timeout issue, a JavaScript running on the browser could do its own timing, put up a 5 minute warning, then replace it with a “you’ve been logged out” message at the right time (the length of which can be set by the server). My bank’s web banking service does this.
Also, JavaScript really shines in data-entry validation without requiring server interaction.
I don’t know if I’ll be able to contribute code to this effect any time soon, but I’m happy to answer JavaScript questions.
Lot’s of very fruitful ideas coming from everyone! Thank you guys so much. I think I am going to poke around under the hood, and see if I can’t find where that top menu is generated. If I do I’ll see if I can’t implement any of colpa’s suggestions. Anyone with pointers is welcome to shout them out.
Although current sentiments seem to point towards openEMR as outdated code, I am finding it very nicely organized and very easy to read. Counter this to postnuke which I have also been working with recently which seems to be a convoluted mess because of too many chefs in the kitchen. Anyhow I’m starting with interface/main/main_navigation.php, and I was surprised to see that javascript was already being utilized. And I thought there would be complications introducing java to the code! Oh well, this shouldn’t be so hard at all. I just need to familiarize myself with this " window.captureEvents(), window.onKeyPress, and <object>.onKeyUp()" stuff. I read in another thread someone requesting that the themes be easier to change (this is a point at which postnuke does really well). Anyhow I was thinking it would be really nice if the keyboard shortcuts were themable as well. For example a lytec theme that made it easier for the lytec people as all the keystrokes would be similar. Other themes that resembled other software could be made as well.
you shouldn’t worry about the code being clear or not,
if we are implementing changes, those will be only to improve the code readability and make development and further changes easier not only for developers but also to experienced users.
Isn’t it possible to write a program that will interact with the user via the shell at the command line with PHP? Possibly, the existing PHP code could be used with a command line interface without rebuilding from the ground up.
I really think colpa’s suggestion will work. I am pretty new to javascript, but it seems to be exactly what I was asking for. Although compatibility with all browsers looks to be the most challenging. But, as colpa stated, javascript can add some heavy duty functionality to a website. Take a look at this faq I found this morning:
Now just to figure out how to implement a case selection structure that recognizes some key strokes. One question, does anyone know how this will interact with existing key combinations? For example, say I had alt-p go to a certain link, would the browser go to the link AND print the last page?
This kind of event handling is highly browser-dependent. There are multiple DOM standards that are implemented differently in different browsers, even in different versions of the same browser. Bugs are rampant.
When it comes to client-side JavaScript and the DOM, you don’t want to start getting clever unless you have a great deal of spare time and resources for testing on multiple platforms. Trust me on this.
The more I research the more I agree with you. However, I do not think I will be able to influence my end-users to move from lytec without mouseless navigation. Do you have a better idea? I am still going to try this option. Albeit for a specific browser (mozilla I think). If a theme sort of option was introduced maybe different setups for different browsers could be selectable as well.