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

[Karsten Hilbert]

> 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. 
I assume you are correct.

> Can I have it clarified/updated how the in-line popups are intended 
> to work?
I personally think they should be auto-invoked when keywords
are typed. Eg. if I type "famhx" the family history edit area
will pop up. Of course, everyone and her cat will want
different keywords (let alone other languages) so, yes, we
will have some built-in default but we will allow to configure
those keywords. I do think, however, that we need to have some
way of invoking those popups via some function key, too. Eg.
Hit <ALT-something> to pop up a list of edit areas one can
chose from to input data into.

> While inputting into SOAP, do some in-line pop-ups permit 
> coded or tagged info to be input entirely within the pop-up
Yes. The popups can be (nearly) arbitrarily complex. The first
complex popups will be the edit areas Richard previously had
where we now have the SOAP widget.

> whereas 
> when several field-items (or multiple child records) are needed, the 
> user might be brought to a different widget?
I would not like that approach. If I want to input two
vaccinations I should have to type the invoking keyword twice.
Alternatively one could have a button "next" on the popup that
dumps the content into the soap widget and clears the popup
for input of a new item. Richard, do you think that is useful
design ?

> the user is returned to the SOAP, able to see a formatted 
> representation "link" within the SOAP?
Yes. My initial proposal is to format the links like this, eg:
"[:vacc:Tetasorbat SSW:]" where the part between the :'s is
used as the key into the additional data dict during parsing
later on.

> 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?
This is certainly doable but I would probably refrain from
doing so for the time being (due to ease of coding). That
functionality can be added fairly easily and cleanly later on.

> 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?
No. If the soap input widget is configured to have two Soap
input fields (eg. labelled "Patient Request" and "History
Taken") it would also create two narrative rows in the
backend, presumable with different additinal types being
applied.

> There is no advantage or need to have a 
> separate Soap row by which to capture and tag family history?
If we didn't maintain that separation on the backend there
would be no point in allowing for it in the GUI.

> Assuming we wish family history to be more than free text inside a 
> Soap note,
we do

> then clearly multiple family history items per-patient 
> cannot be just stored inside the Soap text.
Correct. Rather the narrative part of the family history (eg.
the "bowel cancer" will become an appropriately typed
clin_narrative row all by itself and thereby is initially
linked to the encounter and episode it was entered in - unless
we want to decide to always link family history to a default
"family history" health issue. The additional data above and
beyond the narrative will be stored specifically in a table
much like Richard suggested (as we do for additional data
regarding diagnoses). I am still deciding (input solicited) on
whether to make that an extra, linking table or a dedicated
clin_root_item descendant.

> 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.
It happens fairly automatically by way of the
encountlet/episode under which the invoking SOAP input widget
operates.

> What if a family history item must later be amended ("oh it wasn't 
> bowel cancer, it really was hepatocellular cancer")
If later means *really* later as in after saving the soap
input widget initially used to invoke the family history popup
then we'll need a dedicated input widget for that. However,
we already have it :-)  It's precisely the same edit area code
that's being using inside the popup except it's invoked
somewhere else codewise...

> - 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?
That entirely depends on how we want to implement it. The
audited copy of the original row will maintain linkage to the
original encounter anyways, of course.

> 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?
Surely, I would have two fields:

create table fam_hx (
    pk serial primary key,
    ...,
    fk_relative integer
        default null
        references identity(id),
    relative text
        default null,
    fk_relationship integer
        default null
        references enum_relationship_types(pk)
) inherits (clin_root_item);

and add a constraint that allows for *either* fk_relative *or*
relative and fk_relationship to be NULL. I would not enforce
having the relative in the database even later on.

> 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?
A classic example for the proposed "next" button on the popup ?
Eg. user types "famhx", up pops the widget, user enters fam
hx, presses next, enters fam hx, presses next, etc, etc. If
the patient later in the process remembers still other fam hx
data one can just invoke the fam hx popup again via the
keyword.

> 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?
I am a bit bedazzled by this. It sounds more complicated than
what I would personally need.

> * 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
This is certainly a sensible approach and could be made a
configurable default.

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