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

[Richard Terry]

> Aha. You are clamouring for putting everything into it's own
> table. How are you going to search across the entire narrative
> then ?

Why is having clinical data in multiple separate tables a problem. Surely that 
is what SQL is for. I have well over a hundred tables in my db and can 
instantly pull out very complex medical records?

I guess in the end however I obviously defer to those working on the backend 
who understand the rationale of what they are doing.

Regards

Richard

On Thu, 25 Nov 2004 07:39 pm, Karsten Hilbert wrote:
> > 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