Re: [Gnumed-devel] describing use cases

[Karsten Hilbert]

> >         * e.g. define minimum criteria to differentiate persons 
> >(uniqueness)
> Can you clarify?
In the widest sense this is asking for the definition of the
PUPIC ... :-)

> >         * e.g. warn of potential duplicates
> Good idea, again this requires the "fuzzy matching algorithm to be 
> described.
But elsewhere, perhaps, on a technical/implementation page.

> >         * e.g. can initiate from within an unsuccessful patient search
> Not really useful IMHO.
Well :-)   I have longed for that features a cast of thousand
times with the commercial EMRs I am using.

> Patient searches are based only a few characters of the name ("j bu" for 
> instance.).
Tell that to any frontdesk staff that doesn't have (nor get) a
clue about how computers work. I have watched them
painstakingly typing the whole name a gazillion times
only to discover it didn't exist. And having to type it in
again in the enter new patient form. I'd vote for saving those
poor souls a couple of keystrokes any day.

> But easy to do.
Except that it needs doing.

> >         * e.g. can create new person from unmatched lab result header 
> >after rejecting offer of soft matches
> With an appropriate warning.
Why, surely only after the user manually confirmed that that
is indeed a new patient.

> Certainly in the Australian context this
> would almost certainly be creating a duplicate.
Which would then, given the above, be "intended" duplicates...

> >         * e.g. be able to be "called" (patient selection) from a 
> >separate EMR-lite
> I am doing this now as part of the "Richard space" framework.
Which would mean you are reinventing the wheel. What else
would the built-in XML-RPC server started by the --slave
option be for ? That can be used to drive the GnuMed GUI to do
anything you desire. It may offer gaps for improvement, though.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346