[Gnumed-devel] re: mapping

[sjtan]

> Roughly there currently are
> two schemes in use: a manual "mapping" done by me (seen the
> vaccinations edit area) and a "defined" mapping done by you
> (see PastHx I believe). Mine is cleaner code, acceptable and
> works. Yours works, is way more elegant but isn't "clean" code.
can't remember it ; probably pretentious stuff , that I thought was
cool and "design"-ful at the time. What do you mean by "clean"?

If you wrote a mapping specification, may be me or some other
developer will be able to follow whatever EMR requirements you
and a few others seem to know implicitly. I'm a little short sighted,
as I haven't made enough effort to try and read ALL the code,
which unfortunately, looks required. Personally, I don't expect
an EMR to be that reliable, with what we're used to in Australia :
rapid entry tools for semi-structured free text, with some 
pseudo-knowledge base
text matching thrown in. Most of them don't have repeatable dialog entry
(in case the dialog was dismissed before the printer failed mid-form),
and maybe a couple make non-transparent sporadic gestures at trying to
match hidden diagnosis codes with drug prescription warnings (this 
passes for
AI). To escape lost work during client crashes, which averages 2 times per
session, all entry is passed straight to the DB without any caching in 
objects,
(just like data-aware widgets).
To be fair, non-validated free text might be a convenient
way of recognizing one's own style of notes , many years later.

Maybe choose the most essential data functions first - non-repudiation 
and authentication
(which apparently requires a trusted-third party to validate the time ?).

What seems to be an important requirement is also the ability for the 
EMR to interface
to messages issued by other systems such as diagnostic services, and 
electronic discharge
summaries; scanned or sent consultant reports, and associate them with 
the correctly
identified patient record, which can be done within the workflow 
requirement that a
clinician views all reports. What seems to happen presently is that the 
GP EMRs here
can at least extract patient identification information from incoming 
electronic reports,
and attempt to match to existing patients; scanned in documents are 
classified by
the medical secretaries. The EMRs here present any unviewed documents 
per clinician,
then allocate per patient; with SQL , it should be easy to view 
documents either
chronologically per clinician, or per  patient, or all documents within 
a time period,
at anytime. The actual target artifacts are discharge summaries, and 
comprehensive
referral letters, so that  medical care can be transferred  between 
specialist , hospital and GP
with maximal relevant information. It would be nice to increase the 
relevance by
sophisticated validation, but maybe this should be a secondary 
requirement, and leave
the garbage filtering to people for now.