[Top][All Lists]

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

Re: [Gnumed-devel] When & where to present GNUmed e.g. IEEE Symposium? R

From: Ian Haywood
Subject: Re: [Gnumed-devel] When & where to present GNUmed e.g. IEEE Symposium? Role of "Papers"?
Date: Sun, 27 Nov 2005 21:41:43 +1100
User-agent: Debian Thunderbird 1.0.7 (X11/20051017)

Richard Hosking wrote:
> One of the main benefits from Gnumed would be to escape the M$ licensing
> morass. Is there a credible scheduling/accounting package that could run
> under linux or form the basis for one?
medical appointment scheduling is pretty specialised - I don't know of any, but 
it's shouldn't be that hard.
Especially when looking at "Patient$" (yes, that's actually it's real name), 
the clunky
proprietary scheduler my clinic uses.
Maybe a job for Sebastian's secret army of cloned robot-programmers? ;-)
I'm happy to write a spec when the wiki comes back

Billing is another matter. On the face of it, not that hard either here in AU, 
(for GPs):
        - you have a list of item numbers, which HIC publish in a nice plain 
ASCII file
        - a list of billing types (private, bulk, pensioner, DVA, WorkCover)
        - a table for the (type, item, price) tuples and widget to edit them.
        - keep a list if item(s) charged for the consult and the billing type
        - print an invoice at the end of the consult
        - use SQL GROUP BY queries to make monthly reports; earning by doctors,
by item, by doctor and item, etc.

Liz, Richard, et al: what am I missing? (probably a lot)

> The other major issue is maintenance of data relating to medications and
> items etc. At present medication data could be obtained from MIMS,
> presumably under licence. How would the issue of medication and item
> data maintenance be handled?
There's plently on this in the list archives.
(but not for quite a while, and we've never came up with a good solution)
So, let me bore you all to tears once again ;-)

The problem is it's surprisingly hard to name a drug. Brand names tend to
change as brands go on and off the market, or as drug companies feel like
it (MIMS versions alternate freely between "Losec" and "Losec Tablets" for 
Generic names get complicated with stuff like 
Framycetin/Gramicidin/Dexamethasone [Sofradex],
and aren't specific enough. (Chloramphenicol eye drops and IV infusion, for 
And we haven't even started with the "ex tempore" stuff.

PBS item numbers are pretty good: very specific but constant and the same 
bio-equivalent brands. But no code for OTC stuff and non-PBS items like Ritalin.

ATC (the "Nordic codes") are portable but tend to be a little coarse to rely on 
but they are good for avoiding "lock-in" (the clinical database can only ever 
be used with one pharmaceutical

The best I can come up with this based around Richard Terry's work and previous 

-- this is the clinical database's "private" list of meds, which is populated 
as the user refers
-- to an external source of drug data. Entries aren't ever changed, a new one 
is created if
-- you need to change dose etc. Postgres access rights should be used to 
enforce this.
select table clin.prescribable
        pk serial,
        brand text,
-- as RT pointed out, it's useful to have separate entries for different 
brands, so you can 'cheat' and use
-- different brands for different doses/instructions that you use.
        generic text,
        atc_code varchar (7),
        database integer references databases (pk),
        db_code text, -- code specific to that database, where we got this data 
from. Can be NULL (for ex tempore)
        form text,
        instructions text,
        per_day float, -- number of "units" per day with these instructions (so 
we can calculate when the script runs out)
        amount integer, -- number of units dispensed
        repeats integer -- repeat scripts given

-- meds currently being taken (even if we didn't prescribe them ourselves)
select table curr_meds
        fk_prescribable integer references prescribable (pk) not null,
        started date not null,
        last_prescribed date
) inherits (clin_root_item);

-- exactly one row here for each script that comes out of our printer
select table scripts
        fk_prescribable [] integer references prescribable (pk), -- the item(s) 
on the script (max 3 on AU)
        form integer references clin.form_instances (id), -- the form used.
        authority text, -- the PBS (or equivalent) authority number
        mode integer, -- totally locale-dependent. In AU we woud have 0=PBS, 
1=RPBS, 2=private
) inherits (clin_root_item);

Ian H

reply via email to

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