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

[J Busser]

At 9:39 AM +0100 11/25/04, Karsten Hilbert wrote:
>  > Whearas you can allow the user to type in this info into the general SOAP
> >  stuff
> Of course not. No one suggested that.

The confusion about the tags was my own fault... I had of late been 
referencing the web-based display of the schema which we know poorly 
shows some table relationships...

Perhaps Richard is suggesting that if no special GUI area is provided 
for (e.g.) Family History, then users will be stymied on what to do. 
They may be puzzled, looking around in vain for a menu item or icon 
by which to reach a special input area that is out of view (or which 
may not even exist!).

Can I have it clarified/updated how the in-line popups are intended 
to work? While inputting into SOAP, do some in-line pop-ups permit 
coded or tagged info to be input entirely within the pop-up, whereas 
when several field-items (or multiple child records) are needed, the 
user might be brought to a different widget? And after such detailed 
input, the user is returned to the SOAP, able to see a formatted 
representation "link" within the SOAP? Is it established yet whether 
such formatted representations *behave* as links and so, if clicked, 
would transfer the user to the linked widget / editing area, where 
the additional detail could be inspected, and audited if required?

On how Family History items would "relate" to the narrative rows... 
At any one "encounterlet" (Karsten: "encountlet") does a single 
narrative Soap row serve to hold *all* the Soap narrative (history) 
for that visit, which could contain both symptoms *and* the patient 
report of family history? There is no advantage or need to have a 
separate Soap row by which to capture and tag family history?

Assuming we wish family history to be more than free text inside a 
Soap note, then clearly multiple family history items per-patient 
cannot be just stored inside the Soap text. Each of multiple Family 
History items would be contained in a separate row within an 
ancillary table (as is the case with clin_diag) but I am wondering 
whether in the current patient encounter, there may be multiple 
encountlets and whether each family history item needs to be linked 
to any of multiple possible encountlet/episodes which feels like a 
lot of work. I have an idea on this at bottom in the Addendum.

What if a family history item must later be amended ("oh it wasn't 
bowel cancer, it really was hepatocellular cancer") - does the audit 
process maintain linkage only to the original Soap row (and therefore 
encounter) or is it only the original version that maintains that 
original relationship, whereas the updated row carries a link to the 
newer encounter within which the audit was performed?

How are the relatives to be handled? Presumably entered as free text 
individuals and not persons in their own right (though it is possible 
that the person may already be, or may in future be, a patient in the 
practice - almost certainly the case with siblings of young 
patients). Can this be ignored for now in the schema, and considered 
later in a version 2 or 3 whether and how to share or flow-through 
family history from a patient to a different gnumed person/patient?

So back to *part* of what Richard might be asking (sorry if I am 
wrong). Is it for users to be able to "see" and "directly access" a 
separate on-screen editing area, into which they would add lines, one 
per relative / condition combination?

Maybe in order to be permitted to do so, the system would "require" 
an "encounter-mode" to have been "entered". So for example, if the 
user should acknowledge entry into a "chart review" mode, they could 
enter or amend Family History items, while behind the scenes an 
encounter would be created, attached to a "default" episode 
('chart-maintenance'? 'FHx'? [*see addendum below]), unattached to 
any  issue, with single Soap row. And if it that Soap row were later 
to be viewed, it would contain and display the same representational 
links as would have been generated had the user instead originated 
the entries and amendments from within a Soap widget? Entry via the 
Soap widget might have offered a purposeful way to attach a family 
history encountlet to a particular episode (perhaps already linked to 
an established issue) but the optimization of such links could always 
be done at a later session?

* Addendum - perhaps, if there is a rationale to invite direct-entry 
of data into dedicated widgets (perhaps like Family History) the 
widget could default to attach to an episode dedicated to that widget 
type. We might then end up with a set of episodes unattached to any 
health issues, episodes like:
Family Hx
Personal Hx

Any episodelets contained therein could have been entered directly, 
via the item-type related widget, or via Soap but by user who 
deliberately assigned that link, because a given Family History item 
was irrelevant to any of the patient's known issues, therefore why 
not assign it to the episode "Family Hx"?
The only thing is that a given clin_narrative