Re: [Gnumed-devel] When & where to present GNUmed e.g. IEEE Symposium? Role of "Papers"?

[Sebastian Hilbert]

On Sunday 27 November 2005 11:41, Ian Haywood wrote:
> 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
Wiki is a problem. We have the files back but  I will not install a Wiki on 
*my* servers unless Debian provides uptodate packages. Which  has not 
happened as of yesterday. So we are stuck unless some sets up a wiki from 
source and maintains it. I have absolutely no ressources myself to install 
and maintain a wiki from source.

Writing the specs in a word processor locally might do for a start. I am sure 
we can transfer it to the Wiki once it is back up. To leave yet another piece 
of information. Those clone robot programmers come in pairs. They have to 
finish it within one semester and are required to finish it. The have no 
medical knowledge. Communication will be by means of mailing lists and CVS.
We pretty much have the infrastructure to handle it but as stated before each 
pair will be communicating with a "medical project manager". In other word 
you :-) Unless we find a need and make use of these ressources via spelling 
out specs upfront / as we proceed I see little value in allocating more 
ressources into setting up the connections.

Anyone care to monitor and notify me of (not necessarly maintain) Wiki 
status ? If new debian packages are out let me know and / or when problems 
are announced on the web.


>
> 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
> example) Generic names get complicated with stuff like
> Framycetin/Gramicidin/Dexamethasone [Sofradex], and aren't specific enough.
> (Chloramphenicol eye drops and IV infusion, for example) And we haven't
> even started with the "ex tempore" stuff.
>
> PBS item numbers are pretty good: very specific but constant and the same
> between 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 alone, but they are good for avoiding "lock-in" (the clinical
> database can only ever be used with one pharmaceutical database)
>
> The best I can come up with this based around Richard Terry's work and
> previous discussions:
>
> -- 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
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice