Re: [Gnumed-devel] My Simple Brain - Data Storage - FH+Habits

[Karsten Hilbert]

> I've watched and watched the following sort of debate on this list for a long 
> time:
Yes, and what precisely is the problem ?

> ==========================================
> > 4 is only if we have some alternate mechanism to tag and later 
> > subselect certain types of history as Syan was asking, for example I 
> > am not sure how we expect to draw out stored info on risk behaviours 
> > (EtOH, tobacco, sex & other so-called Social History), likewise 
> > Family History if these are all supposed to be entered into 
> > clin_narrative
> Again, you can attach any number of arbitrarily created tags
> to any clin_narrative item. It may indeed be useful to
> pre-create a number of "well-established" tags.
> =============================================
> 
> And I ask myself the same question, again, again and again. Why does it have 
> to be so hard?
Hm, I wonder what you think has to be so hard ?

> Why not do the obvious [...]
You fail to mention what "the obvious" is, IOW what did I
suggest will lead to something non-obvious ?

> You are not going to be able to 'draw out' certain types of history such as 
> drugs, family history etc, unless they are appropriatley entered in a popup 
> or stand alone editing area, as they will all have unique types of 
> information and some sort of structure will need to be enforced.
Aha. You are clamouring for putting everything into it's own
table. How are you going to search across the entire narrative
then ?

Within the current GnuMed schema there are two solutions to this:

1) Put all the data you think needs to be in extra tables into
   clin_narrative rows and type those rows appropriately for
   filtering. Now, this of course won't be done manually by
   the user but rather by the save logic of a FH/PH/... popup
   edit area. This has the disadvantage of possibly storing
   non-text (eg. integers/bools) into a text column. Which can
   be overcome by factoring out those fields to an ancillary
   table much like your data_FH table or our clin_diag table.
   That table would *link* to a clin_narrative row for any
   comment/narrative/description field which in itself are
   appropriately typed.

2) In other cases it may be easier/better to just define a
   child table of clin_root_item. This inherits one narrative
   field. It can of course link to more narrative fields
   (which isn't as clean conceptually, however, and a sign of
   having to think about using approach 1). This also
   immediately inherits the possibility to be typed to ones
   hearts content - again, of course, done by widget logic,
   not manually.

Deciding which approach to user is entirely a
backend/middleware issue. I don't see where your problem lies.

> Whearas you can allow the user to type in this info into the general SOAP 
> stuff
Of course not. No one suggested that.

> What seems to be constantly forgotten, (and at the risk 
> of being boring and annoyingly repetative) is that your user is not going to 
> do what you think they are going to do.
No kidding.

> The family history question is a good point: Here are my tables, certainly 
> different from gnuMed's. Note here to normalise the data a simple single 
> table structure will not suffice:
A *simple* structure will not suffice, that's right.

I will look at the structure you attached to find what we can
usefully transfer.

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