[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] re: mapping

From: sjtan
Subject: [Gnumed-devel] re: mapping
Date: Thu, 26 Feb 2004 22:50:11 +1100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]