Re: [Gnumed-devel] GNUmed plugin development - part 3

[Karsten Hilbert]

On Wed, Apr 08, 2009 at 01:55:47PM +0200, Hilbert, Sebastian wrote:

> How do we want to go about the backend ?

Well, one conceptual approach could be to regard individual
device settings as measurements and treat them as such --
they would auto-appear in the measurements grid for one
thing (but can, of course, be re-used in your widget as you
see fit). The existing grid would allow you to simple-view
your data w/o any coding at all on your part. Thus they
would also auto-appear in the EMR tree and EMR journal -
quite desirable ;-)  I bet LOINC got a bunch of useful code
points.

Another approach is to code up a specific table. This is
undesirable since it'd be a) a specific table for a
non-generic thing (think of what to do with pacemaker data,
ecg data, EEG data, ENG data, ... - a table for each !?!)
and b) would likely require one table (structure) *per defi*
(because they will all have different measurements).

Yet another approach would be to regard one device "state"
(made up of several measurements) to be a (structured)
document. It could be stored in either a device_state table
or even the documents table itself. Upon loading some code
would interpret the structure and turn it into individual
values -- but, then, we *already* have that in the form of
measurements ;-)   The "structured doc" approach also let's
results appear (aggregated) in the doc tree, the EMR journal
and emr tree. It would also serve to provide an aggregation
structure (the document) and allow to attach other things
(scans of ecgs, say) to the same aggregation (document).

"Measurements" is the clean approach as far as the values
are concerned. It, however, requires a bit more code than:

"Structured document" is an acceptable first-iteration
approach and may allow us to cut a few corners for now: it
provides aggregation, makes device states auto-appear,
allows for commenting on them, and allows to attach metadata.

Way to go, I'd say (from what little I understand of the
actual requirements).

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