gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Prescription printing in arbitrary countries and serv


From: Horst Herb
Subject: Re: [Gnumed-devel] Prescription printing in arbitrary countries and services.
Date: Sun, 29 May 2005 01:58:50 +0000
User-agent: KMail/1.7.2

On Sat, 28 May 2005 18:05, Adrian Midgley wrote:
> > Doing a solution
> > for prescription is hard if you want to avoid that it only
> > works for one given country.
>
> There are various ways of decoupling prescribing from printing a
> prescription, is there a favoured one already?

In two weeks time I will demonstrate my own prescribing solution in 
gnumed-mini. I am pleased that Ian Haywood will be there too, will give us 
time to discuss how to best port it to gnumed proper. Source code will be 
published when I am back from that conference (and Ian can have a copy right 
away)

It works as follows:
1.) a medication is chosen via the drugref API from any database having a 
drugref API adapter (I use the Australian PBS data plus the proprietary 
Australian MIMS database plus the WHO essential medicines formulary)
2.) Because reference database can be volatile, the prescription module will 
*not* just store a reference to a drug in the drugef database, but for each 
prescription it will record in full text
- generic component(s)
- brand (if any)
- strength
- package size
- authorized repeats ("refills") if any
- instructions how to take medication 
- id of prescriber
and in a separate table it will record any country specific information like 
in Australia, compliance with certain subsidy restrictions and subsidy 
permission authorization

I used to print via generating a KWord (or formerly Abiword) file, but now I 
am really happy with the way printing works in wxPython 2.6.0, so this 
weekend I port my printing modules to use wxPython routines

The user interface problem for different national requirements is simple to 
solve:
1.) I "draw" the user interface using wxGlade, one for each special 
requirement, but sticking to user interface element naming conventions
2.) wxGlade produces a Python module for each such user interface design
3.) the  prescribing dialog module inherits one of those generated modules 
programmatically depending on locale
4.) since most functionality (including GUI) will be the same for all nations, 
these "universal" routines are isolated into a separate module

The bad points about my solution is lack of proper normalization and lack of 
coding making decision support more difficult, but all of this can be added 
on later when we port it to gnumed proper. Currently, my prescribing dialog 
is handcrafted specifically for Australian needs.

Horst




reply via email to

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