Re: [Gnumed-devel] Patient demographic input screen

[richard terry]

> I can just reiterate my plea here to ask front-desk staff as
> to what they do how.
> The main point is to make patient demographic input as smart
> and as fast as possible with the ability to delve deeper if
> wanted (needed). In fact, one needs to think about whether an
> entirely separate front-desk client would be in order. 

Ideally we need a separate front-desk client which is integrated with the 
practice billing. However this is a long way off. I've found in my work on my 
clinical desktop, that I need access occasionally to some of the basic 
patient data, including stuff which will be country specific (eg. in Oz we 
have a medicare number which is a defacto national identity number).

My intention with the patient demographic screen was to add this sort of 
access-functionality to gnuMed  without it intending to replace an up front 
module. The reality in Australian general practices and I suspect in all 
others is that they currently have a commercial billing program of some sort 
from which we will need to get the demographic data. The existing billing 
programs will continue to function for some years until/or if a gnumed 
billing client turns up. (I've done quite an extensive billing module design 
mock up in qt designer and I attatch the .ui - file for those interested - 
you will need linux and qtdesigner to run this. I spent a few hours on this 
one night when I was frustrated with wxPython, and modelled it after 
australian needs with some copying of Geof Stokelds tables/screens (AccessGP).



>Another
> train of thought is which way to separate/integrate front desk
> work. Is inputting demographic information the only task ? Or
> do they create (billing) "cases", fill the waiting list......


I would envisage that the panels which hold the say demographic screen, or 
the appointment screen will be plugins that will be used in an upfront 
billing/appointments whatever client, which we just happen to plug into the 
gnumed client on the doctors desktop.


----- Forwarded message from Alec Dempster <address@hidden> -----

> As Karsten suggests there are many different needs between very many
> different types of practices.
> Could you provide a wizard that enables the average user to design/redesign
> their own demographic interface layout -- so they can drag and size field
> controls from a field list, including optional tab controls, text "widgets"
> (correct jargon?), or pop-up windows (do not encourage too many of these)
> etc???

I'd like to say 'in your dreams'. Of course the answer is yes but probably a 
long way down the track. The problem with much of this stuff is that some of 
it really is country specific. Screens are probably going to end up a dogs 
breakfast even with an extremely clever wizard. I suspect that in the end 
developers from each country will need to take the code and add/delete stuff 
as needed.

The gui screen I've developed will be like the attatched png file 
(qtpatientsgui.png) which covers all the basics, like allowing firstname, 
surname, title, preferred salutation, multiple alias's, multiple 
addresses(residential/postal etc), basic personal details:birthdate, 
occupation, country of birth, next of kin + address, contact details(home, 
work,fax, email, web, mobile + patient photo, and ability to aquire this, 
import, export. Plus I'll add a memo field.

It would be possible, screen realestate allowing, to allow several user 
configurable fields to display.

I'd be interested to hear from the list as to how far this basic design goes 
to satisfying requirements.

> Personally i've never found any 'off the shelf' medical software package
> with enough power and flexibility to allow efficient adaptation for my
> particular needs. 
>I hope gnumed frontends can have inherent flexibility
>use I don't want to have to learn python (too much else to do in my
> life). Would a web based frontend will be high or low on the list???
> cheers to all Alec
> 

And no, you never will, cause we are all individual's. Learn a little python! 
A web based front end is not currently high on the list.

I think we need to get realistic here and get a functional gnuMed running 
within the next six months, allowing linking to existing demographic data and 
functioning in all the basic area's needed on a desktop from allergies to 
prescriptions to requests etc. If we wait until we have everything optimised 
and develop a fully blown supersmart system we will never get anything 
release.  We have to crawl before we walk. As long as the backend guys get 
the database and the nuts and bolts right, the gui can change along the way 
to accomodate.



Regards


Richard Terry

qtpatientsgui.png
Description: PNG image

patient_input7.zip
Description: Zip archive