[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/


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

> 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",

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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