Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 91, Issue 56

[Sebastian Hilbert]

Am Dienstag 29 Juni 2010, 02:33:03 schrieb richard kim:

Hi Richard,

Comments below.

> >What happened. Can you report on any specific issues with web interfaces ?
> >What the interface an issue in your attempt to create your own emr ?
> 
> I'll answer this question first.  The EMR we attempted to design was
> completely different from anything out there because we worked on several
> unprovable assumptions.

You probably mean unproven assumptions as physicians out there will approve or 
dissapprove your assumptions quickly.

> The reason we fell apart was just lack of
> continued interest by the developers.

I guess this is because some of you did try to scratch someone else's itch 
instead of your own ?

> Unfortunately, I am not sure how
> what I learned can be applied elsewhere, but I am still giving it
> continual thought.
> 
I am sure some of it can be applied. Even avoid certain things can be helpful

> It was a web application/server based system, with use of movable portlets
> ( http://en.wikipedia.org/wiki/Portlet).  An example of movable portlets
> is igoogle.com.  The portlets would be set up so that each one would
> contain a specific function.  For example, 1 portlet would represent the
> immunizations.  1 would represent the Past Medical History, and so on.
>  Since written in javascript, the applications could be as simple as a text
> viewer, or as complex as a full scheduling system.  No real limits, other
> than automatic access to local desktop files (javascript limitation).
> 
Roughly a portlet could be compared to a plugin. Each tab in GNUmed is a 
plugin and can be removed or added as the user wishes.

> Since the portlets were movable, you could do many things such as
> completely customize the appearance of a page. 

This soundy good but has drawbacks as well. Users tend to customize until it 
is totally hosed. Then they will call tech support and tech support will be 
happy to charge them. I remember the days when theming Win95 was all the hype.

> You could also duplicate
> portlets as needed.  Did you ever type a message, then ask "what was that
> lab value again?" go back to the lab page, go back to the message page,
> and finish typing?  I have, many times. 

That makes sense. wxpython has the wxAUI interface where you can do parts of 
this.

> With movable portlets, you can
> keep the labs and messages on the same page . . . if you want.  If not,
> then you have that choice to change it.

Same for wxAUI but you are right it is uncommon on the web.

> Me personally, I would like a
> list of allergies and medications next to the messaging system, so I can
> make recommendations without changing pages.  This system of movable
> portlets allowed for that.

What do you mean by messanging system ? Maybe we can get some clever ideas for 
GNUmed. Recently we asked how users want their patient overview plugin. We 
still need feedback on this. The patient overview plugin will reuse existing 
components (not quite portles)

> 
> Many times, primary care physicians and specialists of all sorts need to
> share the record.  

Do you mean in looking at the record at the same time ?
In GNUmed you can do this. As an example open patient Kirk in the public 
database from two computers and open one of the two progress notes plugins on 
each. That pretty much simulates it, doesn't it ?

> That means no one is really happy with the options, and
> there are too many options to sort through.  Portlets can be customized per
> patient,

There is a German EMR that can do this (they kind of implemented a desktop 
within the application where you can drop widgets) but users mess up 
creatively all the time.

> and per provider, so that an ophthalmologist does not need to see
> the same screen as an obstetrician, even though they are using the same
> system. 

See above. In GNUmed both physicians could even look at the same record in 
different languages.

> This would cut down on the large number of menu options, which can
> be very complete, but very hard to navigate.
> 
Sure. GNUmed will add menu options dynamically depending on if a plugin is
there or not. The same could be done in a web interface.

> Finally, since the functions were embedded within a given portlet,
> development could be done in parallel.  Closest analogy I can make is with
> the iphone, where within 2 years, they had over 100,000 apps.  If someone
> did not like the existing medication portlets, they could hire someone to
> make their own, without touching the core system. 

Same in GNUmed. Plugins are independent. Load them or don't

> Therefore, you could
> conceivably have different people using the same data, but accessed with
> different applets. 

Same here.

> Basically, I think the iphone has 20 different apps for
> farts -- I guess because you can't get enough of them -- but basically it
> encourages some redundancy in the system as needed.  This would eliminate
> the problem where many physicians say "I like this part of the EMR, but not
> that part." You would not need to take all or none, but could rather
> create parts how you like them.  But at the same time, it would not lead
> to bloat, since each physician would only seen the portlet they choose to
> use, and not the 19 others that exist out there.  Finally, if you wanted
> some portlet, chances are, someone else wants the exact same thing.  Given
> the Free software system, you could use something that someone else
> created -- like an app store with Free software.
> 
Same here. Once a number of plugins exist there could be a feature to have 
those installed seperately.

> So, that was the system in a nutshell.  Again, I am not sure what we can
> learn from it, as it is quite foreign from anything else I have seen in an
> EMR, and therefore admittedly, unproven.

Nah the concept is not that far off. While I tend to doubt that too much 
flexibility will have a use case in reality other then playing customize-your-
emr during night-shifts instead of solitaire the concepts are well received 
and should be applied to a webinterface for GNUmed.

> But if anything, I think
> designing the system enlightened me as to understanding trade offs people
> have to make in dealing with electronics, and approaches to some of the
> social barriers to usage.  Thanks again.
> 
Your comments and lessons learned are most valuable. What you have in mind is 
fairly complex. A intermediate step would be to implement a single-page-
application which shares some concepts with the GNUmed plugings. For that the 
GUI-broker needs to be ported to the web. That would allow people to write 
plugings the same way you could write plugings for the wxypython application.

Then when this has been achieved those plugins could be merged into portlets 
where a portlet broker would replace the gui-broker.

Too bad I lack sufficient web development skills. I would love to prove that 
the current GNUmed middleware and backend is fit to host a web gui. I guess 
many people underestimate what the current web prototype tells you.

The current web prototype is based on cherrypy (just happend). It lets you 
reuse all the GNUmed code for user authorization and query the GNUmed database 
without changing a single line in the middleware and backend. All I had to do 
was to produce a webpage that would get the credentials in a webpage instead 
of the wxpython login dialog and feed that to the middleware. It then works 
with this information on the server to query the backend. So to say it again 
all that was neccessary was one simple webpage with a login form. Logging was 
reused without a change so GNUmed logs will be written as well. The point is 
you don't need a framework anymore with ORM and stuff. The framework is there 
already. All you need to do (I guess) is write an interface. If you one writes 
a multipage interface then all pages could be processed on the server. If one 
writes an SPA then I would guess that you need something like JSON-RPC ( I 
still don't fully understand this).

More important then the customizations is to have portlets/plugins in the 
first place. We very much welcome input on how to group information on the 
screen. Paper and pen (and a scanner) will do for that part.

Sebastian