[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] gnumed handling of multiple practice MDs
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] gnumed handling of multiple practice MDs |
Date: |
Fri, 6 Feb 2004 14:33:10 +0100 |
User-agent: |
Mutt/1.3.22.1i |
James,
as usual I'll ask a few uncomfortable questions.
> Within a practice there maybe several physicians, any one of whom may be
> the "principal" MD
I am not sure I understand what use a "principal" MD is of. I
know this concept exists in many commercial systems. What do
you have in mind specifically as to what assigning a principal
MD is supposed to mean ?
> but during whose absence (or even on call) any of the others
> may see a patient.
This seems to hint at security implications.
> I imagine gnumed will in version 1 support the designation
> of one individual as a patient's principal doc
If someone clearly demonstrates the need and writes the code.
> while easily displaying who else has had any involvement,
Why, of course.
> presumably in reverse chronologic order.
Ordering is secondary for now, IMHO, particularly regarding
who was involved.
> Where a few physicians migrate out of a practice and may be replaced by new
> ones, or even if an ongoing member gets too busy, there may be a change in a
> patient's principal MD. In the event the desk staff err and change a value
> when
> they shouldn't ought gunmed be able to display the previous value
I tend to think that I do not understand the meaning of this
paragraph. What values are we talking about ? Clinical data ?
Assignment of principal MD ?
> or will it be
> enough for people to infer from viewing who's been involved.
I think so.
> When designating the practice doc pertinent to a field value,
Aha. We already support this courtesy of all clinical tables
inheriting from clin_root. Also, that's why client startup
fails if the provided DB account isn't mapped to a staff
member.
> should it be only docs presently "active" in the practice
> who are displayed
I think one should see the name of the staff member regardless
of current affiliation with this practice.
> and is there
> agreement that you'd optionally want to be able to bring up the names of docs
> who had been in the practice or reactivate locums who return from time to
> time?
Why, sure.
> Some practices make appointments for patients to come to the office to see
> someone other than one of the main docs. Commonest might be a nurse or
> perhaps
> dietician if one has been brought into the practice (even only as a
> free-agent
> available part-time to see patients) and there are also docs who have a
> medical
> student or resident come to work with them for a day, week, month at a time
> or
> once weekly for a series of months (Canada's OSCAR software supports these).
> - Is is hoped to accomodate such appointment-making and involvement-tracking
> in
> gnumed?
Surely so. They get a temporary DB account, are assigned to a
DB group (thereby acquiring DB rights) and are listed as staff
members. Once they disembark their DB account is disabled
while their staff account is retained.
> - Is there an attraction to be be able to book a "joint" or "stacked"
> appointment on a day & time when both the student/resident and the
> supervising
> MD, or both the MD and the nurse/dietician will be available?
If someone writes the code that's certainly possible. When
collecting the requirements for an appointment it's just that
it got 2 "human-presence" requirements apart from
"room-available", "office-open", "world-hasn't-been-nuked",
etc.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346