Re: [Gnumed-devel] describing use cases

[J Busser]

At 6:31 PM +1100 2/12/05, Ian Haywood wrote:
> Can you clarify?
> >    * functional requirement e.g. input new person from keyboard
> >       * _use-case prerequisite(s):_
> >          * e.g. define minimum criteria to differentiate persons (uniqueness)

If Smith, Marie who lives in Town B exists already in the system, and 
I am faced with a new patient Smith, Marietta who lives in Town A (or 
worse, also in Town B) it is not much of a basis to distinguish them.

If each has a date of birth available, and it is different, it is 
somewhat reassuring to me.

Yet if the DOB is the same, while it is suspicious, it is possible 
these are distinct people so we cannot constrain UNIQUE = {lastname, 
firstname, dob}. So in case we had 2 patients who matched on these 
fields would we borrow use of the PUPIC field to distinguish them 
e.g. home phone number and have
UNIQUE = {lastname, firstname, dob, cob, PUPIC}

- does a dob timestamp require a time, or will it accept "just" a date portion
- if an accurate dob is unavailable, even temporarily at a time that 
a new patient *needs* to be created ("hello, Drs Office? My 
father-in-law is visiting from out of country and is sick, can he be 
seen in the office? Pardon me? You can't book an appointment until I 
find out his date of birth? But he and my husband won't be back until 
tonight. I have to phone tomorrow?
- maybe the above is dealt with by not creating a patient but rather 
creating a non-patient entry in the scheduler at the expense of less 
well being able to search it -OR- users would have to input a sham 
date like Jan 1, 1800?
- should fk_marital_status truly be NOT NULL and if this is kept, 
since the default is "1", does prudence dictate that the 
marital_status table's first row must be "UNKNOWN"?

PS:
- field naming Karsten agreed (I thought) that primary keys should be 
pk rather than id, owing to the ambiguity of id describing some 
non-computing administrative quantity also foreign keys should be fk_ 
not id_ as was done in the names table so the changes should be
          identity.id->identity. pk
          names.id->names. pk
          names.id_identity->names.fk_identity (referencing identity.pk)
 will renaming this break anything badly?
- not sure how the tables identity and names work together... is a 
new identity row to be created only through the creation of a new row 
in names, and is the enforcement here at the middleware or gui level 
as the schema cannot achieve it?



> >       * _essential features_
> >          * e.g. warn of potential duplicates
> Good idea, again this requires the "fuzzy matching algorithm to be described.
>
> >       * _highly desirable features_
> >          * e.g. can initiate from within an unsuccessful patient search
> Not really useful IMHO. Patient searches are based only a few 
> characters of the
> name ("j bu" for instance.) But easy to do.
> >          * e.g. can create new person from unmatched lab result 
> > header after rejecting offer of soft matches
> With an appropriate warning. Certainly in the Australian context this
> would almost certainly be creating a duplicate.

But if the soft matches are rejected, what then the alternative? 
Leaving the Lab Journal to then search around using other search 
options (other than fuzzy matching) to decide on who that result 
belonged to?

> Possibly the only exception is a specialist practice receiving
> HL7 referral messages. (as yet non-existent)

HL7 (or specialist practices using gnumed) as yet non-existent in Australia?