[Top][All Lists]

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

Re: [Gnumed-devel] widget connecting

From: Karsten . Hilbert
Subject: Re: [Gnumed-devel] widget connecting
Date: Thu, 5 Jun 2003 18:23:39 +0200 (MEST)

>> 2) keeping progress notes in simple SOAP structured text input
>>    fields (clin_note/clin_history/clin_physical rows)
>> 3) per patient ASCII export of progress notes to text files for
>>    re-use constrained by date, encounter, episode, health issue
> I would have to see this in practice, Karsten.
Hopefully you will before too long.
> Item 3 is a nice extension to item 2.
Huh ?

The constraint would be optional, of course. Like selecting what to dump
based on the mentioned criteria. Or selecting "dump all" :-)

> However, my patients typically 
> present with, on average, three problems. Often the symptoms and signs 
> will overlap from one problem to the next and I find it hard, 
> particularly in advance, to determine what data item belongs where.
Sure. One does not *have* to assign either episodes or health issues
beforehand. Any data entered by default belongs to the default episode/health 
unless one has been selected explicitely. However, that selection carries
over to the next session for this patient. Each item is tagged individually. So
it can always be reassociated later. There may be a need to splitting items
for reassociation but we can worry about that when the need arises.

> Currently I have one large SOAP box where I use bars to delimit each 
> clinical entitity. This makes moving data around within the box 
> relatively easy.
Sure, the solution is to have a main notebook tab labelled "David's
single-box SOAP". There's nothing holding us back from *also* having "Karsten's
few-boxes SOAP" AND "Richard's smart SOAP". If you don't want to see our input
widgets as tabs you can always not load them (thanks to Hilmar's ConfigRegistry
this is now nicely transparent).

> I am concerned that multiple input fields for multiple 
> problems will make the display and hence the manipulation and more 
> significantly the interpretation of that data worse.
Also note that those multiple input fields aren't intended for
*representation* of the SOAP content ;-) For that I'd personally prefer a tree 
just like
the document tree or the config tree -- but that's me :)  Nothing stopping us
from having a HTML representation and, of course, Richard's excellent
presentation mode ... (Richard, I'm not trying to mock you, just  making a 

from an e-Cafe in Manchester (no Hilmar, I haven't  met anyone here yet...)

+++ GMX - Mail, Messaging & more +++
Bitte l├Ącheln! Fotogalerie online mit GMX ohne eigene Homepage!

reply via email to

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