[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: J Busser
Subject: Re: [Gnumed-devel] My Simple Brain - Data Storage - FH+Habits
Date: Thu, 25 Nov 2004 10:44:03 -0800

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
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]