gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] OSCAR McMaster Workshop


From: Michael Bonert
Subject: [Gnumed-devel] OSCAR McMaster Workshop
Date: Thu, 19 Jun 2003 02:46:50 -0400 (EDT)

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





reply via email to

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