gnumed-devel
[Top][All Lists]
Advanced

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



reply via email to

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