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

[Karsten Hilbert]

On Mon, Jun 28, 2010 at 05:33:03PM -0700, richard kim wrote:

> >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 ?

...

> Since the portlets were movable, you could do many things such as completely
> customize the appearance of a page.  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.

One of the ways of solving this is Richard's design which we
are starting to narrow in on.

> With movable portlets, you can keep the labs
> and messages on the same page . . . if you want.

And if you know beforehand that you'll need a lab portlet.

Which is the same as if you opened a second GNUmed instance
showing the lab page while typing the message in the first
and tiling the windows in your window manager.

> If not, then you have that
> choice to change it.  Me personally, I would like a list of allergies and
> medications next to the messaging system, so I can make recommendations
> without changing pages.

That is the sort of clinical recommendations I regularly ask
our users on list to contribute.

Regarding your concrete desire - what is it that you are
referring to by "messaging system" ?

> Many times, primary care physicians and specialists of all sorts need to
> share the record.  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, 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.  This would cut down on the large number of menu options, which can
> be very complete, but very hard to navigate.

I agree making this sort of customization easier is very
desirable.

> Finally, since the functions were embedded within a given portlet,
> development could be done in parallel.

The (clinical, etc) functionality was embedded inside the
*widgets* ?

>  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.  Therefore, you could
> conceivably have different people using the same data, but accessed with
> different applets.

Ah, OK, I see. GNUmed also does this.

> 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.

Oh, same here - don't like the medication interface ?  Have
a new one created just for you. Your developer can talk to a
proven stable middleware and not be concerned about how to
transfer stuff from/to the database. Whenever a medication
is added/changed/deleted in the database your interface can
receive a signal from the middleware -- if it so desires.
This works across interfaces (you could run both the old
ugly and your new shiny meds interface), across GNUmed
instances (edit meds in one, see it appear in another), and
across machines (have frontdesk staff update current meds
list and see it instantly appear in your exam room).

> 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,

Well, I think, the insights you gained can only further
other, future EMRs if they are applied/tested against what
else is there. So, if you went through GNUmed and applied
your findings to how GNUmed does things you might be able to
point out (or even code) possible improvements.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346