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

[s j tan]

------------------------------

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
of
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
(to
describe encounters) instead of breaking the encounter into several
forms:

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
paper

        ASIDE - complexity is one concern I have about GnuMed.  It is my
impression that the people here have such a great deal of technical
skill
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.
A
BMJ article discuss this problem
http://bmj.com/cgi/content/full/326/7394/860?etoc --
quote: "Paradoxically, the problem may be exacerbated by people with
both
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
in
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
the
prescription).'

---
I think the waiting room/receptionist functions on OSCAR are very nice
and
something we should take a close look when designing ours.  The schedule
and patient status (not here yet/in waiting room/in examination
room/being
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
GnuMed.

General Note: the demo http://67.69.12.117/index.php?pageId=3 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
contributed
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
change
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
will
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.  

---
Andreas:
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
to
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
post
was showing the differences in the postgresql versions.)


I hope this message wasn't too much rambling.
Michael



------------------------------

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;
  charset="iso-8859-1"
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
skill
> 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.
One 
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
it 
takes to enter data. I still think the web paradigms are of little
practical 
use in a GPs office!


>
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel



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