gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] gnumed remote control


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] gnumed remote control
Date: Sat, 3 Dec 2005 13:25:47 +0100
User-agent: Mutt/1.5.9i

On Tue, Nov 29, 2005 at 10:01:51PM -0800, Jim Busser wrote:

> I found a small local company (sans EMR) that would be happy to have 
> their biller/scheduler used
That's good.

> but felt unsure if they had the skills 
> (or wanted) to incorporate special code into their product.
It may not be necessary to add much of any code to their product.

> Find a program that can "call" an external piece of code and come up 
> with even just one keybinding and menu item to invoke it. (If the 
> program cannot / will not do *that*, the user could look instead to 
> an automation utility to deliver this function.)
> 
> The external code would serve as a "connection piece" (maybe in 
> engineering this would be a "regulator"?) and would, based on 
> whichever patient is active in the biller/scheduler, permit the user 
> to
> 
> 1. Jump to the current patient in the EMR (GNUmed)
> 2. Jump *and* update demographics, or
> 3. Create this (new) patient in the EMR
It much depends on how one wants the system to work. Does on
usually enter patients in the billing part and *then* turn
to GNUmed for clinical work - or is it the other way round ?
The first way would be the least hassle/additional code for
3rd party software (eg the billing software).

> Beyond that, the external code would require only as much help as it 
> takes from the biller/scheduler people to define / open the data to 
> pass through to the enslaved GNUmed.
Exactly. All they need to do is to deliver patient data and
tell GNUmed to open/create that patient. In the most simple
case it could work like this: "They" write the current
patient's data into a flat file. The user then switches to
GNUmed and invokes "search patient from file". Which would
then read the 3rd party patient data file and open/create
that patient. We would have to add that functionality but
that can be done in a snap.

> Nicer would be for the "calling" billing/scheduler to contain 
> individual keybindings and menu items and able to pass --- to the 
> connecting piece --- a parameter to signal the user's intent.
Sure, whichever level the "other" software wants to use for
cooperation.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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