gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Appointment handling


From: Busser, Jim
Subject: Re: [Gnumed-devel] Appointment handling
Date: Sat, 30 Mar 2013 21:34:58 +0000

On 2013-03-30, at 12:24 PM, Sebastian Hilbert <address@hidden> wrote:

> On Saturday, March 30, 2013 06:44:46 PM Sebastian Hilbert wrote:
> > Hi,
> > 
> Found some old code in git.
>  
> http://gitorious.org/gnumed/gnumed/blobs/rel-0-1/gnumed/gnumed/client/wxpython/gmAppoint.py


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.

Another idea was to be able to load and parse Google or ical format files.

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

- doctors subscribe either free, or for a small charge, depending on # / volume 
of subscribed patients
- doctors feed availability into the system
- patients who wish such a service pay a subscription fee
- patients can "see" if a particular slot of time, filterable by doctor (one 
doctor, or all in praxis) is
        confirmed for them
        pending confirmation for them
        pending confirmation for someone else
        available
        unavailable
- patient can request one or more (configurable maximum) from among
        available slots
        slots pending confirmation for someone else
- patient can also request cancellations or changes

The doctors and patients would each need to be able to subscribe to this 
calendar.

The patient account might need to be able to store a parameter to assist 
linkage (the gnumed pk for their record, or a hash thereof)

A doctor should avoid to have to manage too many different calendars. 
Therefore, if they would use such an external calendar, they might need also 
need to input, into it, the appointments of the patients who have no desire to 
manager their appointments.

The above maybe needs a revenue sharing model, where the praxis pays a base 
price for the service, and patients who then subscribe to the service provide 
revenue that is split between the praxis and the service provider.


-- Jim




reply via email to

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