[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] RE: Gnumed-devel Digest, Vol 7, Issue 18

From: s j tan
Subject: [Gnumed-devel] RE: Gnumed-devel Digest, Vol 7, Issue 18
Date: Fri, 20 Jun 2003 09:41:23 +1000


Date: Thu, 19 Jun 2003 02:46:50 -0400 (EDT)
From: Michael Bonert <address@hidden>
To: gnumed-devel <address@hidden>
Subject: [Gnumed-devel] OSCAR McMaster Workshop
Message-ID: <address@hidden>
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
Precedence: list
Message: 5

I went to the OSCAR McMaster Workshop on Wednesday.  It was fairly well
attended 20-25 people--many family physicians, a few residents.  One
physician was representing a group practise of ~65 physicians... and
seemed impressed--looks like OSCAR will get a big test soon.  :)  

I understand OSCAR design a lot better.  Impressive is that a good deal
the government forms are integrated and some of the patient care is
standardized into checklists (they already have rudamentary clinical
decision support).

I think I now also understand why they went with the large text field
describe encounters) instead of breaking the encounter into several

Reasons for the simple, large text field:
1. it is simple to implement in the web browser/set-up

2. it is (simple and) how (I imagine) most physicians take notes on

        ASIDE - complexity is one concern I have about GnuMed.  It is my
impression that the people here have such a great deal of technical
relative to the average physician... that the software we will produce
will be such a leap forward that the learning curve will be too steep.
BMJ article discuss this problem --
quote: "Paradoxically, the problem may be exacerbated by people with
clinical and computer experience. Although such people are valuable as
"product champions" to support implementation, unless they are kept in
balance they can inappropriately push commissioners beyond what is
sustainable on a routine basis by staff with no special interest in
information technology."

The draw backs of the large text field (OSCAR approach) became obvious
one of the discussions in the afternoon session where one participant
asked if some of an example entry (which consisted of two parts: (1) a
diagnosis and (2) a note of what was prescribed) would have to be
duplicated in order to generate a prescription.  The answer was: 'yes,
some of the data (which drug was choosen) has to be entered twice (once
for the narrative in the encounter window, once for the generation of

I think the waiting room/receptionist functions on OSCAR are very nice
something we should take a close look when designing ours.  The schedule
and patient status (not here yet/in waiting room/in examination
examined/cancelled appointment) are visually integrated in one
view; patient status changes are done with one mouse click; it is
intuitive and well thought-out.

They have a risk of cardiovascular disease calculator... an idea for

General Note: the demo is newer
code than version 1.0 (the only version available on sourceforge)

What surprised me most is that they aren't currently using a
CVS.  Actually, that totally blew me away; I always thought a CVS was
essential for good quality control and proper developer coordination.  I
don't know how they manage without a CVS.  I guess in reality they don't
(manage too well)... I have the impression the lack of CVS has
to problems they are having currently; David mentioned that they have
(back-end) compatibility problems between the old version and new
(unreleased) version.  (I talked to David about how I see this... a
is coming.)

A lot of the Workshop focused on transistion and I have the impression a
strong migration plan is a must.  If things appear too complex people
be less inclined to migrate.  Transistion to GnuMed is probably a good
niche market... if on the long run someone wants to do consulting there
probably will be lots of opportunity.

I learned more about the politics of health care around here.  Seems a
good number of the policy makers here unfortunately belong with the
knuckle dragging neanderthals (they seem to be most interested in a
centralized approach... where they can make money--something a kin to
micro$oft's .net).  

Promising is that (independent of the workshop) I've made some contact
with another professor (here in Toronto) that is interested in health
information management (in family medicine); he invited me to his
clinic... perhaps something will come of it.

All-in-all it was very productive day and it was really interesting.
It was a joy to met David and his team.  

Great to see you're on top of the security issues. :) I knew the
permissions I had set weren't good practise.  I was just a bit too lazy
read-up on the details of pg_hba.conf settings... when I first got the
back-end working I was happy that it connected... and since didn't
re-examine those settings in any detail.  (The main point of my last
was showing the differences in the postgresql versions.)

I hope this message wasn't too much rambling.


Date: Thu, 19 Jun 2003 17:20:20 +1000
From: richard terry <address@hidden>
To: Michael Bonert <address@hidden>,
 gnumed-devel <address@hidden>
Subject: Re: [Gnumed-devel] OSCAR McMaster Workshop
Message-ID: <address@hidden>
In-Reply-To: <address@hidden>
References: <address@hidden>
Content-Type: text/plain;
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Reply-To: address@hidden
Message: 6

>       ASIDE - complexity is one concern I have about GnuMed.  It is my
> impression that the people here have such a great deal of technical
> relative to the average physician... that the software we will produce
> will be such a leap forward that the learning curve will be too steep.

One would hope not. In fact complexity should be hidden from the user.
advantage of the editing area concept is that it removes much of the 
complexity by automatising (if there is such a word) much of the effort
takes to enter data. I still think the web paradigms are of little
use in a GPs office!

> _______________________________________________
> Gnumed-devel mailing list
> address@hidden

Recently, I'm seeing if a OO model can  be used w.r.t. to time of
debugging, performance etc.. in java. I've looked at the OpenEHR model
and at the stuff
Presented in Analysis Patterns book by Fowler, and really the OpenEHR
is harder to understand and looks like it is not properly separating
analysis from implementation / design. On the other hand, the analysis
patterns stuff is easy enough to understand ( when the accompanying text
is read), but how good it looks when implemented, I don't know. I think
it's possible to map those patterns to a implementation much more easily
now (then since when the book was written , 1996) , as a lot of free
tools exist now: I'm using community edition stuff for UML java mapping,
IDE assisted coding, and open source object-relational mapping framework
, a build and a testing framework,  to see if a usable application can
be made. (Not sure if I should be naming the tools used, because I'm
strictly doing this as a hobby, but if you use google to search such
java tools, it'll be easy to figure out). 

Michael Bonert's review is interesting : I read that paragraph about
Propeller Heads not being Political Animals as well , which I'd agree
with. And the bit about Neatherdals is funny to a point, (until you
happen to be a hapless developer-type cudgelled by one). The bit about
the large text field is true enough ; it's sometimes too hard to try to
work and also remember how a particular user interface has a structured
entry panel and where to find it; w.r.t. structured data, recently I had
a dispute ( seems like every time I try to make a contribution) with
Karsten about how exactly to link up encounters with episodes with
entries etc... and that issue is also addressed in the planning chapter
of the analysis patterns book ( which basically says you can do it
either lazy or eager) : e.g. so a lazy way with Oscar would be to have
some sort of reviewer to classify the free text entry , automated or
human (does Michael know of such a design in Oscar?)  , and an eager way
would be a context-sensitive parser , like a programmer's IDE, to
classify text and terms ( an additional function to shortcut expanding):
A web based client would not allow the eager way, which might support
Richard's objection.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]