[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] What is a calendar was Re: appointment schedular
From: |
Jim Busser |
Subject: |
[Gnumed-devel] What is a calendar was Re: appointment schedular |
Date: |
Sat, 07 May 2011 13:02:02 -0700 |
On 2011-05-07, at 1:04 AM, address@hidden wrote:
> Having an online schedular (calendar) has multiple advantages. -access
> -availability.
> Google calender is one such free online calender. Instead of kde based
> calendar, which may not be useful on other platform, should we include google
> calender as a schedular?
What is a schedule? What is a calendar?
What do they need to do?
I suggest that a schedule is an orderly listing, in relative date-time order, of
- multiple actions that are to happen
- involving one or more systems or person-entities
A calendar simply helps to
- "fix" the schedule to a specific calendar date-time when it starts
- help to display / visualize how the schedule would appear in the context of
any other already-calendarized (or reserved) schedule blockings
- optionally use program logic to find optimal timing or resolve or at least
warn about conflicts
A concern was raised that maybe Google calendar compromises data integrity
(security) or view access (privacy). That is true if:
- the data must be stored at Google
- the data consists of information that exists only at Google
- the data is data about which there is a concern if it would become known
What could be safely stored at Google?
- date-time durations when unnamed doctors, each labelled one among something
like "A" or "JB" is
available
already-booked, or
not available
- a patient identifier or key that does not give away patient information
either a bi-directionally useful key e.g. PUPIC
a unidirectional GNUmed to Google key (one-way hash of PUPIC)
Here are some thoughts about why calendaring is complicated…
- it is not so much the display of simple information… for any one doctor, the
appointment dates & times could even be put into the Waitlist and the data
series {date-time, patient name} could be plotted as rows
- it is not even a problem of being to display the information for multiple
doctors side by side, this is simply an extended case of display of simple data
… the complicated part is the LOGIC of streamlining and automating appointment
lengths based on the desired visit types, and finding "openings" based on a
schedule defined by each doctor in the praxis in advance, and deciding whether
to support "protected" times in such a system, and then supporting to search to
find "available" times that satisfy the required time for a doctor of interest
or any doctor in the praxis that would be available, depending if the doctors
each dedicated different portions of their time -- for example certain mornings
or afternoons -- for certain kinds of patient activities. And THEN supporting
how to fix broken appointments when a doctor's availability must change. And
also to manage patient preferences and waitlists and the state of knowledge and
the status of communications after every change.
I cannot understand that you would ever put a "copy" of clinical information
e.g. "HIV" *inside* a calendar, you might only display it (or provide a link to
reason for visit) in the visual representation of the calendar.
-- Jim