Re: [Gnumed-devel] describing use cases

[Karsten Hilbert]

> UNIQUE = {lastname, firstname, dob, cob, PUPIC}
Since all those can be the same yet the people are different
(while unlikely) we can only solve this via a dedicated
distinguisher field. Which is provided for right inside the
PUPIC. IOW the PUPIC is intentionally to be made unique if it
ain't so all by itself.

> - does a dob timestamp require a time, or will it accept "just" a date 
> portion
Yes, but I think it will set the time to something (which is
then untrue). In the name of medical verity do we need to
separate date and time ? It almost sounds like it. Clinicians,
input, please !

> - if an accurate dob is unavailable, even temporarily at a time that 
> a new patient *needs* to be created
Liz pointed out that need before. Do people think we should
allow NULL (for unknown) as the DOB ?

I would then add a non-null but impossible default to that
table and add a constraint which complains about that default
such that programmers need to *actively* insert null values
for unknown dates and cannot just fall back onto the default.
This is inconvenient for the coder, yes, but intentionally so
as the dob is a really important trait.

Else we could have a companion field "textual_dob text" with a
constraint where *either* dob *or* textual_dob can be null but
not both. In that one would then have to enter *something* if
the dob is not known (eg elderly or juvenile or approx 70 yrs
or something).

What about that idea ?

> - 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
Not a good idea.

> -OR- users would have to input a sham date like Jan 1, 1800?
Also possible but no good IMO.

> - 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"?
It already is as is.

However, the cleaner solution is likely to allow NULL and
remove "unknown" from marital_status. Done.

> - 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_ 
Yes.

> 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)
True.

>  will renaming this break anything badly?
Very fundamental tables. Unsure of repercussions so having
been hesitant to go ahead. Should be done, though.

> - not sure how the tables identity and names work together...
An Identity is the biological entity of a being (sic). A name
is a label for that entity. Entities (eg identities) can have
several labels (eg names) only one of them being "active" at a
given time.

> is a 
> new identity row to be created only through the creation of a new row 
> in names
No. You could, conceivably, have an identity without a name.
Think Chinese before their 9th (?) birthday in pre-cultural
revolution times. Or as-yet unnamed newborns.

>, and is the enforcement here at the middleware or gui level 
> as the schema cannot achieve it?
It could, by way of triggers.

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