Re: [Gnumed-devel] re: rschedule

[James Busser]

On Jul 1, 2006, at 12:20 AM, Karsten Hilbert wrote:

> > Someone needs to decide if it is desirable to try to link the  
> > appointments in
> > oscar to gnumed,
> I would think so.
>
> > and
> >
> > then what is the desired mechanism to notify the gnumed applicaiton,
> I'd suggest using the XML-RPC interface but it's up to you guys.

Part of this discussion depends on identifying whether we are talking  
about patients being created plus having their appointments made in  
Oscar, passing to GNUmed any patient activations --- which is what I  
think we are talking about.

So in this approach, the office (surgery) reception and managers  
would almost always be working inside Oscar for reception and patient  
identification. Maybe some would input clinical information and  
results into GNUmed.

Doctors in the practice would use a hybrid of Oscar with GNUmed might  
normally navigate inside Oscar while working through the appointment  
list but could have dual options of searching for patients through  
Oscar (which would move a GNUmed instance to the linked patient) or  
could flip into the GNUmed instance to work on a different patient,  
who could remain the open patient in GNUmed until the user moves  
within Oscar.

I am not savvy enough to get inside Oscar's appointment objects  
(whether each appointment is an object, or collection thereof) which  
are presented in the Oscar browser. Even so, each appointment offers,  
beyond its toggled "status", the following that can be clicked

- edit appointment information
- an E for Encounter
- an M for master demographic record
- a B for Billing and an
- Rx for prescribing

each of which should be able to reference the patient's master  
demographic id number (Oscar's internal unique identifier).  
Therefore, apart from editing the appointment information then,  
whichever of E M B and Rx that is chosen, it should be possible to

- extract the master Oscar id
- pass it, via XML-RPC, to notify GNUmed that a patient has been  
selected, and cause GNUmed to test whether the patient exists and  
accordingly move to them, or to create them from the Oscar  
demographic info

The above could, with the agreement of the Oscar people, be  
incorporated into the Search-Edit/Create demographic code plus the  
Appointment code without having to make any changes to the Oscar data  
structures. The main oscar preference file, which resides on the  
server (it is the oscar.preferences file) could be altered to contain  
one extra parameter xmlrpc= yes to control whether or not this extra  
code gets actioned.

Whether or not the E(ncounter), M(aster demog), B(illing) and Rx  
buttons keeps users in Oscar, or jumps them into GNUmed (or anything  
else), could also be specified with the oscar.properties info,  
something like xmlrpc = (any of) "EMBRx" with a default of ""

I think the above would be much tidier than to aim to store in  
Oscar's appointment table (or any other Oscar table) any external  
references. I believe GNUmed already has a place in its backend that  
could be borrowed to store the Oscar patient id.