[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Gnumed-devel] gnumed remote control,
Karsten Hilbert <=