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

[richard kim]

Thanks, Sebastian.  I think I understand where you are coming from more now, and I think I misunderstood a lot from before.  I'll make mention of your comments a little at a time.

>> I, with a group of friends,
>> tried to start an EMR project of our own, but it fell apart completely.  I
>> hope to share my opinion from my experiences.
>>

>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.  The reason we fell apart was just lack of continued interest by the developers.  Unfortunately, I am not sure how what I learned can be applied elsewhere, but I am still giving it continual thought.

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

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

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.

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

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

Richard