Re: [Gnumed-devel] First sample of gui function docs

[Karsten Hilbert]

> Sure, in that case Richard's specs just need to state that the above
> function will be used for the age display. A very minor point, but
> display of months for ages > than say, 3 or 4 or 5 years is probably
> unnecessary (but who cares?). 
Sure, medically it may (at least above the age of say, 12,
since some acceptable age ranges for vaccinations/screening in
children are given in year/month notation. Later on it is a
nice boon to be able to say: "ah, only 1 month to go until
retirement" - makes patients happy. Sure, I could look at the
DOB but that's often more work (for the eye/mind).

> > Address tables are fully audited.
> Audit tables are one way of maintaining an address history, but how can
> they distinguish a minor correction to an incorrectly recorded address
> from a completely new address?
They can't, in the current model.

> Explicit modelling of important data
> elements which are likely to change in the course of the relationship
> with the patient is probably warranted. However, not important enough
> for Version 1.0 - but worth considering for a future version.
OK, got your point. We already do so for names at least. Put a
note in the relevant schema file.

> Briefly, how does the GNUmed table auditing mechanism work?
Every table that is to be audited needs to inherit from a)
audit_fields and b) audit_mark. For every such table another
table with the prefix "log_" must exist that has the same
attributes (except those inherited from audit_fields/mark) with
the same datatypes but no constraints (NOT NULL will likely
work, though). It *may* have less attributes than the audited
table in which case those attributes are not audited (duh!).
Any such audit trail table must inherit from audit_trail. Given
those prerequisites a script run during bootstrapping of GnuMed
databases will create all the needed update/insert/delete
triggers/functions and attach them to the tables. I am
currently working on auto-creating the audit trail tables,
too. A longer description is in the manual.

> > > If so, then at least the previous address (if recorded) should be shown,
> > > and the (approximate) date of last move.
> On the demographic summary screen which I was commenting on.
That certainly depends on the locale. Our people don't move
much. For here it'd be sufficient to have that indicator in
the demographic details screen.

> > > c) Occupational history? Patient might be a bus driver now but was a
> > Will add tables.
> Hmmm, I can't stop you, but could I suggest a more considered approach
> to design and implementation? Haste makes waste...
:-)))    That doesn't mean a half-baked table is going to
appear in there yesterday...

> Although my
> suggestion of capturing an occupational history is doubtedly sound,
Hence my "will add tables".

> there are a number of things to consider before implementing a table to
> hold it. Such as: Is it important enough to be implemented in Version
> 1.0?
Providing table(s) is a matter of a couple hours of thought
(while at work, that is :-) and, say, one hour of actually
writing the tables... ;-)

> What level of detail of occupation is desirable - a general
> practice seeing many occupational injuries might need more than other
> setting?
IMHO for the general case just

table occupation
    id
    name

(this for normalization, input reuse)

table lnk_job2person
    id
    id_person
    id_occupation
    comment

(more than one job per person, start/end + notes in comment)

> Is a coding system or controlled terminology desirable? If so,
table occupation + phrase wheel should provide all the needed
control over the terminology in the general case, a "good" set
of initial occupation.name values reduces the desire to add
more

> which one(s)? If just free text, how much - a how mini-essay on each
> job, or just a single line?
technically, there's no difference in PostgreSQL:
varchar(nn) is just "text" with a length check added so using
varchar() is really only useful when one wants to absolutely
enforce an upper bound on the length

this applies to occupation.name and lnk_job2person.comment

what the frontend does with the text is another matter,
content should be split into "name" and "comment" such as
"secretary", "also does heavy lifting at this SOHO company"
since the plain job name may not hint at the increased
risk of interdiscal prolaps as opposed to benign ischialgic
back pain. Same for "steel worker" + "senior employee, hasn't
entered production area for last 10 years" etc.

> Finally, could other input be sought before
> implementation?
Sure, yours :-)   Now, if specific settings require
finer-grained control over this matter they link in more
specific tables (like gmMeasurements.sql -> test_result ->
lab_result)

> > > d) Highest educational level. Increasing evidence that on a population
> Likewise.
Likewise.

> > > e) Ethnicity! Country of birth, first language, language spoken at home,
> here in Australia the Australian Bureau of
> Statistics codesets are the ones to use. No idea about Germany or
well, piece-o-cake: ISO country codes and locale language
codes. If AU needs more specific items (since, for example ISO
country codes do not map onto Australian Bureau of Statistics
country codes etc) then AU needs additional tables not
pertinent to the general case. We already use "official" (ISO)
sets for country codes.

> > The last three might as well be put into clinical history,
> > backend-wise.
> Personally I am not sure language details belong in clinical
> history...they seem like socio-demographic characteristics to me.
I agree that language does not warrant it's own type of
clinical history item but should be split into:

in demographics:
- locally dominant language proficiency
  (scale of levels)
- needs translator for ...
  (which language person speaks best, includes sign language)

in clinical history:
("educational/occupational")
- languages spoken by person/at home



> although it would bother me if I saw language in a clinical
> history table.
Why ? It is *history*, is it not ? It surely can elicit
clinical findings (such as perceived poor compliance due to
poor understanding of instructions).

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