gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Structured input form


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Structured input form
Date: Fri, 13 Apr 2012 07:43:03 +0200
User-agent: KMail/4.8.2 (Linux/3.0.0-17-generic-pae; KDE/4.8.2; i686; ; )

On Thursday, April 12, 2012 10:30:13 PM Karsten Hilbert wrote:
> On Thu, Apr 12, 2012 at 06:47:14PM +0000, Jim Busser wrote:
> > It seems that the desire is to easily and efficiently
> > input for each patient, in a consistent way, one or more
> > pieces of information *other* than narrative.
> 
> Karsten

The desire to capture structured information is well taken. The design 
originally proposed might have its root in the era of Filemaker and friends 
where you would pretty much create a database and have a nice and easy 
interface to it.

I am not sure bending the SOAP widget is the best idea. It sure could work but 
it was never designed for that purpose.

If you want to capture structured information which is a mix of GNUmed data 
(lab values, patient history, medication) all in one place instead of spread 
all over GNUmed you might want to consider two approaches until GNUmed (if 
ever) has the flexibility to quickly whip up "forms".

1) If you have a stable set of Forms you might want to create a dedicated 
widget for it. Some fields could be populated from other areas of GNUmed.

2) If you have an ever chaniging set of forms you might consider setting up a 
dedicated solution for this such as OpenClinica (heavy duty) or any other 
"forms" software which could be fed from GNUmed

I am talking about research here. In this setting you usually do not elicit 
all data for a "case report form" in one single encounter. But the final case 
report form hides this information and creates a pseudo encounter (the one 
with the paper form, when signed) You pull in information from all kinds of 
sources. 

Similar in GNUmed. You have many encounters and types of information which 
would make up one case report form. The problem is that GNUmed would need a 
feature to tag encounter which need to go into the form and which not. Say you 
perform two ultrasound procedures in one hospital stay: But only one would 
need to get pushed to the CRF. How is GNUmed to decide ? Same with multiple 
measurements of liver enzymes. We solve this by manually deciding and filling 
out CRFs (pseudo encounters). This defeats many concepts of GNUmed.

In my opinion the only clean solution would be to set up OpenClinica or REDCap 
(both free as in beer), define a "study" and interface to it from GNUmed. 
Ideally one would set up i2b2 and push data to the data warehouse.

The hard part is where to draw the line. For a single practice or a few forms 
it seems overkill to implement a OC/i2b2 solution. In this setting a "get off 
my back and let me have filemaker in GNUmed" appraoch seems desirable.

Now back to the later approach. One could look at OpenOffice Base (I think). 
Maybe Karsten could comment on the possibility of OpenOffice pulling data from 
the GNUmed database. I am sure a reasonably skilled programmer could write a 
simple forms solution inside GNUmed (a new widget effectively). The problem I 
see is that collecting data in this widget would not make it available in the 
appropriate places in GNUmed (for later access).

But.... If you go - hey just let me have a way to store this information - I 
don't care about encounters, health issues and the likes ... then one could 
whip up a widget and store it either as 'pseudo-SOAP' issue (hard to parse 
later on) or 'pseudo-measurements'

It all comes down to what you want. 

Sebastian



reply via email to

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