[Top][All Lists]

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

Re: [Gnumed-devel] re: rschedule

From: James Busser
Subject: Re: [Gnumed-devel] re: rschedule
Date: Sat, 1 Jul 2006 01:38:42 -0700

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.


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

reply via email to

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