Interface design

OpenEMR Development
1

lannygoodman wrote on Saturday, July 21, 2012:

first, let me say i have the highest regard for open source efforts.  i use them whenever i can and greatly appreciate the efforts that talented developers invest in a platform.

that having been said, i just reviewed the demo as we are actively looking for an EMR platform.  assuming your demo is your best foot forward, from a design standpoint, the user interface can only be described as ghastly.  it is clear that programmers should never be allowed to do either graphic or functional interface design.  it is precisely their in-depth knowledge of how the system works that makes them unqualified to do the functional UI design (because your users initially know nothing about how it works) and developers rarely have any graphic training or sensibilities.

apple has overtaken the microsoft juggernaut precisely because MS is run by engineers and apple is run by designers.  anyone who has ever used both will appreciate how much easier apple products are to use and on the eye.  open source is no more an excuse for bad UI design any more than “hey it’s free” is an excuse for bad functionality.

i applaud the work you’ve done and i have no doubt that there are docs (many of whom are geeks anyway) who will love the system.  however, if you want openemr to fulfill its potential, you really need to get a designer and UI expert on the team. 

in the meantime, sadly, i’m going to have to look elsewhere for an emr system,

2

sunsetsystems wrote on Saturday, July 21, 2012:

If you’re done calling our baby ugly, do you have any specific suggestions for design changes?  :slight_smile:

Generally the UI is a product of what users ask for and are willing to do or sponsor.

Rod
www.sunsetsystems.com

3

bradymiller wrote on Saturday, July 21, 2012:

What do you mean, Rod? He did give a specific issue; it is ghastly. All we need to do is implement a un-ghastly button/feature and all will be well. I’m thinking of making a button that when clicked, shows the Apple logo at the top left… We could even control it with a global… We should also head on over to the open source contributors vending machine and order the team a designer and UI expert. :slight_smile:

4

cverk wrote on Saturday, July 21, 2012:

This looks like the state of politics and the practice of medicine. One side presents a detailed plan with an invitation to contribute improvements, and the other side just issues criticism without any new ideas.  Maybe its just that I view Macs as good for kids entertainment and Windows and Linux as good for actually getting some work done. So basically I am putting my two cents in that I use this interface every day now to run an actual primary care office, and maybe I am indeed a geek, but I like it as simple as possible . I would rather pay more attention to the patient instead of the computer.

5

mcaloon wrote on Saturday, July 21, 2012:

Hey Lanny,
    Back in March I took a look at openEMR on the hub for code that supported ICD 10 and didn’t find it. I was, like you, disappointed. Unlike you I actually engaged the community instead if your lame applause. If you’re serious about getting involved take a look at the recent threads about jquery and the workflow redesign. How dare call out baby ugly!!! Thanks. to me, Brady,  Arnab and a host of other community members who tested. Although still an infant, our baby speaks ICD10.

Contrary to your uniformed comments, there are a number of pros on the team.  If you choose to join our ranks,  welcome.

Mac

6

zhhealthcare wrote on Sunday, July 22, 2012:

I will take that criticism positively.  The last time someone called openemr primitive ( see posts from two years ag)  we changed the interface with whatever resources we had at the time.  We will rise up to meet this challenge, albeit slowly!!  We have the best group of developers here!  Lanny and the rest watch out.

Shameem

7

juggernautsei wrote on Sunday, July 22, 2012:

I have seen some really great interfaces built for the product but people won’t donate them to the community.

But also people come here and talk but are not willing to put up any money to sponsor the work that needs to be done.

But it is simple human nature to be critical without offering any help.

Sherwin
http://ww2.openmedpractice.com

8

avantsys wrote on Tuesday, July 24, 2012:

We’ll have to be brutally honest here.

There are some basic design flaws in the _ergonomics _of the GUI.

For instance, all users have become accustomed to having the “Save” & “Cancel” buttons (and their equivalents) at the bottom of the pop-up window or the menu in question. Putting them on the top (as OpenEMR does with the prescription module) simply does not sit well with them.

And that’s just one of the many small, but annoying things that need to be corrected. There is a lot of work that needs to be done to the layout of the application (mostly CSS stuff).

Another flaw is that, in its default form, OpenEMR throws far too many options and far too much information at the user. This makes it look cluttered and confusing. A doctor that first encounters OpenEMR simply does not know what to do first, where to start, what s/he needs to do first, next etc. For our own implementation, we’ve had to throw out lots of stuff that our clients have told us they either don’t want or can’t figure out how to incorporate in their own workflow. Later on in this post, I’ll talk about how easy or hard this is to be done.

Now let’s come to the issue of eye candy. The time when I fiddled around with the bells and whistles of Windows 95, choosing cheesy sounds for my system and even cheesier cursors etc is now well behind me - in fact, almost half my life has passed since that time.

Now, I’ve reached the time-honored conclusion that a good GUI is one that you don’t even realize it’s there; one that you don’t even think about; one that is simple, functional, doesn’t look dated, cheesy or ugly and presents _only _the information that’s needed, _when _it’s needed and in a clear, concise and easily comprehensible manner. OpenEMR’s GUI _has _the potential to become like that, but it needs a lot of work on behalf of the developer that takes the code and starts trying to make sense of it, simply because the code is not straightforward and needs a thorough cleanup (and trust me, individual developers working by themselves and smaller outfits will have a very hard time performing this task for the community - this job needs serious teamwork in which everyone will be involved, with the “big boys” leading the way). When you have all sorts of different types of code in the same file (the left_nav.php that I’d talked about some time ago is a prime example), you’re not helping other developers improve the system, because they’ll have a hard time understanding which option is where, what it depends on, what else depends on it and how it affects other things.

Konstantinos

AvantSys Informatics

9

avantsys wrote on Tuesday, July 24, 2012:

mcaloon:

You mentioned that you implemented ICD10 for OpenEMR. So have we, albeit for the Greek translation of it. Have you added any usability enhancements to it (autocomplete, retrieving diagnosis title directly from the ICD10 entry)? Because we’re almost done adding these enhancements and we’re planning to contribute them if anyone wants them.

Konstantinos

AvantSys Informatics

10

tmccormi wrote on Tuesday, July 24, 2012:

Konstantinos:  I agree with you on this in a big way.   The CSS is getting better all the time, slowly pulling things into it so that the eye-candy can be what the end target wants, but it’s still a login way from being “easy” to change the look, much less the workflow.

Regarding the left_nav and menus in general.  It’s time to toss that monstrosity and replace it with a menu system that is driven by database tables.    I’m going to post a new topic thread on that right now…

Tony
www.mi-squared.com / @tonymi2
oemr.org / @OEMR_org

11

mcaloon wrote on Tuesday, July 24, 2012:

Konstantinos,
   I worked with Brady, who did all of the related code changes. I really. focused on the data load rewrite.  I am sure we’ll. be interested in integrating your contribution. Did you post it to github yet?

Mac

12

bradymiller wrote on Tuesday, July 24, 2012:

Hi Konstantinos,

In addition to supporting ICD10, we also modularized/refactored the code to allow any type of “Code Type” in any database schema (ranging from using the codes table to other custom sql tables).

The functions that will look up code types are the code_set_search() and lookup_code_descriptions() in the custom/code_types.inc.php script. There’s even a sort of API for them here:
http://www.open-emr.org/apidocs/OpenEMR/_custom–code_types.inc.php.html

So, suggest implementing these function in your enhancements. I am guessing you have dumped the ICD10 codes in the ‘codes’ table so setting ICD10 external to No at Administration->Lists should then support what you have. In the future, it makes sense to import your Greek ICD10 codes into OpeneMR via Administration->Other->External Data Loads into a set of tables other than the codes tables and creating a new External settings(or using the current ICD10 tables and external settings if possible). Out of curiosity are you using the a public !CD10 code set (such as WHO)?

-brady
OpenEMR

13

avantsys wrote on Monday, July 30, 2012:

Brady,

When we’ve finished the final refinements to the autocomplete for the ICD10, I’m going to send you the code so that you’ll submit it to github.

Konstantinos
AvantSys Informatics

14

bradymiller wrote on Tuesday, July 31, 2012:

Hi Konstantinos,

Sounds good. Even more ideal if your group submits the code directly via gith/github. Here’s a tutorial for setting up and using a OpenEMR github repo: http://www.open-emr.org/wiki/index.php/Git_for_dummies

-brady
OpenEMR