[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] describing use cases
From: |
J Busser |
Subject: |
Re: [Gnumed-devel] describing use cases |
Date: |
Sat, 12 Feb 2005 00:55:48 -0800 |
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?
- [Gnumed-devel] describing use cases, J Busser, 2005/02/12
- Re: [Gnumed-devel] describing use cases, Ian Haywood, 2005/02/12
- Re: [Gnumed-devel] describing use cases,
J Busser <=
- Re: [Gnumed-devel] describing use cases, Karsten Hilbert, 2005/02/12
- Re: [Gnumed-devel] describing use cases, Ian Haywood, 2005/02/12
- Re: [Gnumed-devel] describing use cases, E Dodd, 2005/02/12
- [Gnumed-devel] demographics & identity (was: describing use cases), J Busser, 2005/02/12
- Re: [Gnumed-devel] demographics & identity (was: describing use cases), Karsten Hilbert, 2005/02/13
- [Gnumed-devel] DevelopmentProcess (was: demographics & identity (was: describing use cases)), J Busser, 2005/02/13
- Re: [Gnumed-devel] describing use cases, Karsten Hilbert, 2005/02/12
- Re: [Gnumed-devel] describing use cases, Karsten Hilbert, 2005/02/13
- Re: [Gnumed-devel] describing use cases, Karsten Hilbert, 2005/02/12
- Re: [Gnumed-devel] describing use cases, Karsten Hilbert, 2005/02/12