[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Appointment handling
From: |
Slappinjohn |
Subject: |
Re: [Gnumed-devel] Appointment handling |
Date: |
Mon, 01 Apr 2013 20:10:59 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 |
Hi,
I have a private Practice too and I'm using Korganizer / Kolab Groupware
to handle my appointments. Because of the Kolab Groupware Server one can
handle appointments in the office and I can see it a few seconds later
on my practice PC, smartphone, etc.
BTW: I tried CalDAV first, it was not working as expected.
Marc
Am 01.04.2013 05:20, schrieb Jerzy Luszawski:
> On Sat, 30 Mar 2013 21:34:58 +0000
> "Busser, Jim" <address@hidden> wrote:
>
>
>>> Found some old code in git.
>>>
>>> http://gitorious.org/gnumed/gnumed/blobs/rel-0-1/gnumed/gnumed/client/wxpython/gmAppoint.py
>
> I missed this one - I simply didn't pull so old commits :)
>
>> There has also, all along, been discussion of GNUmed taking advantage of
>> calendaring already being performed in other applications. For example, I
>> believe that if people were running
>>
>> KDE / konsolekalendar
>>
>> then one of GNUmed' plugins could load entries from that file and
>> potentially bring patients into focus through name matching.
>
> While external scheduling application may be easier to implement, it
> looses one important feature of Gnumed - single, consistent database
> with proper access rights, auditing and maintenance (backups etc.).
> Furthermore, it is (IMHO) impossible to enforce consistency between
> Gnumed encounters and external appointments.
> Generally, I don't see any advantages of a plugin which only displays
> appointments managed by external application - that external
> application must be opened anyway. OTOH bi-directional
> communication to open/focus related entries seems so complicated that
> it overweights the benefits of not writing a genuine widget.
>
>
>> Another idea was to be able to load and parse Google or ical format files.
> ... maybe use CalDAV?
>
> I do see the need for occasional import/export of appointments data,
> but I think that for regular work appointments should be managed
> internally. To be more precise: even fetching appointments in
> the morning *every day* is still only occasional import.
>
>>
>> Nowadays, patients are increasingly wanting to make their appointments based
>> on a knowledge of what openings are available.
>>
>> This almost makes it desirable for the calendar to be outside GNUmed, with
>> GNUmed able to
>>
>> 1) "read" the calendar and
>> 2) perhaps "feed" the calendar with the doctor's availability
>>
>> I almost suspect some business model exists in an external scheduling app,
>> almost like a match-maker
> (...)
> Indeed, there are such services in Poland (at least I have seen
> their advertisements). For this - import module putting appointments
> into waiting list would be enough.
> But still - everything is managed outside Gnumed. Especially
> cancelling appointments would require special care to reflect it
> in Gnumed. And no data mining combining medical history and future
> appointments would be possible, for example finding all patients after
> some kind of surgery, who are scheduled for follow-up next month, or
> who have not shown up for more than 3 months and are not scheduled for
> next visit, and so on. These are simple queries, which will not be
> possible without schedule data in the database.
>
> Recently I started to use Taskcoach
> (http://taskcoach.org/devinfo.html) and I keep thinking of a way to
> incorporate it into Gnumed. It has good task management with subtasks,
> categories, priorities and time tracking, but lacks time-finding
> features (time slots etc.), proper month/week view, and advanced
> filtering. It is written in Python :) I think that switching from its
> XML-based storage to database and merging with
> wx appointment scheduling widget might improve it a lot. I'll see what
> I can do with it.
>
>