[Top][All Lists]
[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