[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] <feature> radiology report - text only
|
From: |
Karsten Hilbert |
|
Subject: |
Re: [Gnumed-devel] <feature> radiology report - text only |
|
Date: |
Tue, 5 Aug 2008 16:27:39 +0200 |
|
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hello Jerzy,
there are several ways this can be accomplished:
1) as an "encounter"
- define an encounter type "radiology report"
(this seems important so later such things can
get mapped into better structures)
- create an episode "studies" for a patient
- open a new encounter for a patient
- set the type to "radiology report"
- enter the request into the reason-for-encounter,
e.g. "MRI left shoulder"
- enter contrast medium allergies or info on osteosythetic
material/pacemaker/... into the allergies table
- record history details for a study into the history field of
a new progress note for that patient
- the progress note (encounter) date is the study date
- enter body region into history or findings field
- enter report text into findings and/or assessment field
as appropriate
- enter any recommendations (say, CT scan recommended to better
evaluate osseous structures) into Plan field
- enter facility into, say, assessment field
- text expansion macros which are new in 0.3 can help
a great deal in standardizing text layout in the fields
This would allow to have some sort of sensible structure
with the tools currently at hand. That structure could
fairly easily be parsed for later reformatting into better
suiting fields or for better formatted display.
2) as a text document
- documents do not have to be scanned pages, they can be
of any type and even mixed text and images
- create a document type "radiology report", maybe
even "report MRT knee", "report cCT", if that makes sense
- write a text file with whatever editor you want or
even with a dedicated editor, be it XML, plain text,
RTF, LaTeX, HTML, you name it
- import that text file
- set document type appropriately
- set document date as study date
- set episode as "studies" or "MRI studies" or
whatever seems appropriate
- set external ID as PACS study ID
- set comment to, say, facility and/or body region
- maybe attach one or two images where appropriate
If you want to go that route I would support you by enabling
the "long description" field in the GUI -- each document can
have any number of "long descriptions" attached to it - for
example an OCR version of a scan - or a radiology report
text. If you enable "empty" documents you can pull this off
without even importing external documents: just create a
document of the appropriate type without pages and enter the
actual report into the long description field at the bottom
of the "import documents" tab. Again, text macros will help
here. You can still attach the occasional image to any of those
"empty" documents (they are not empty anymore, then).
Note that currently the long description is not enabled in
the GUI just yet.
Also note that GNUmed is able to link into your PACS to jump
to the corresponding images provided the external ID was
entered and a link script set up properly.
3) a dedicated "user-defined form"
Those are not at all implemented in GNUmed yet.
4) similar to measurements as as structured sOap subtable
This is quite doable but would require at least on full
release iteration, IOW, do not expect it before 0.4.
In that case a structured table (like for test results)
would be added and bound into the GUI.
> I don't see any easy way to accomplish this in current GUI and database
> schema - if I missed something - please let me know.
see above
> That's what I need:
>
> The data stored should be:
> [patient demographics],
> <date of the examination>,
> <examination type> (eg. "CT", "MRI", "DSA" etc.),
> <body region> (eg. "head", "lumbo-sacral spine" etc.),
> <report text>,
> maybe also some reference to the facility performing the examination,
> but this is not important for me at the moment.
no problem, see above
> The data can be displayed in EMR journal similar to the lab results, as
> "objective" record with <examination type> + <body region> as header and
> <report text> below.
This can be accomplished. 1) and 2) already do it, 4) would
offer it, too.
> 2. Is there anyone who works on it?
No.
> If I was to take care of it I would create separate table for it -
That would correspond to example 4).
> 3. Are there any database consistency issues you all know about but I
> might miss? (other than the basics about 'clin_root_item' inheritance
> descibed in http://wiki.gnumed.de/bin/view/Gnumed/DbStructure)
Not that I can think of at the moment. A good example might
be the measurments table(s).
> 4. Some info about auditing would help - is there any available?
There is both technical auditing of changes in the database
as well as clinical auditing ("formal" evaluation) of items
- currently for documents and measurements.
Feel free to ask for help or clarification !
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346