Adding clinical info, findings and diagnosis to a Waveform file [LONG]
Ronaldo Souza
First a little background: we're involved in a project which includes
the aquisition of 12 lead EKGs in very small, poor and often isolated
towns in Brazil. The EKGs are sent in DICOM/Waveform format to a
central server via e-mail or FTP where they'll be interpreted by
cardioogists and a diagnosis will be made.
We have the waveforms working but, at this point, we haven't figured
out a way to send and receive important information, necessary for
proper analysis/diagnosis of the EKGs, such as clinical background,
medications, symptoms which led the patient to the ER, etc. Another
thing that's missing is a structured way to add the cardiologist's
findings/diagnosis/recomendations into the received file, which will
then returned back to the original sender.
Since all the information mentioned above is in free text format, one
possibility we were contemplating was to (mis)use the Sup30.C.10.10
"Waveform Annotation Module", specifying the "Unformated Text"
tag(0070,0006), which would contain all the necessary information in
free text, but this seems quite ugly and the "annotations" either would
be related to the patient and not the waveforms or related to the
waveforms as a whole, and not to specific points.
So the question is: what's the recomended structure for adding to a
Waveform file one or several unformated text items with the patient's
clinical history, risk factors, medication, reason for the ER consult,
symptoms and, at the other end, in the diagnosis center, how to
append/add the findings/diagnosys/recommendations.
Our work conditions are absurd and there's such thing as "give me six
months to study these DICOM specs and I'll get back to you" so, if
anyone feels like helping us, please make it as simple as possible and
don't presume full understanding even of the Waveform supplement on ur
part.
Sorry for the long post and thanks in advance for any help, pointers
and comments.
Best regards,
Ronaldo Souza
Chris
If it is a problem finding suitable predefined tags to put these types
of information, why dont you just create your own private tags and put
this information there? You could create specific, defined private
tags within your 'DICOM ecosystem' which hold each of the types of
information you desire:
Clinical background
Medications
Symptoms
Diagnosis
Recommendations
Etc.
Doing this from non-customized software might of course not be
straight forward, but it shouldnt be impossible if you are able to
work on some custom software solutions based on one of the many good &
free DICOM tools that are available.
Best regards,
Chris
Peter B Schmidt
Chris wrote:
> On 12 Des, 09:43, "Ronaldo Souza" <nos...@nospam.org> wrote:
>> Hi,
>>
>> First a little background: we're involved in a project which includes
>> the aquisition of 12 lead EKGs in very small, poor and often isolated
>> towns in Brazil. The EKGs are sent in DICOM/Waveform format to a
>> central server via e-mail or FTP where they'll be interpreted by
>> cardioogists and a diagnosis will be made.
>>
>> Since all the information mentioned above is in free text format, one
>> possibility we were contemplating was to (mis)use the Sup30.C.10.10
>> "Waveform Annotation Module", specifying the "Unformated Text"
>> tag(0070,0006), which would contain all the necessary information in
>> free text, but this seems quite ugly and the "annotations" either
>> would
>> be related to the patient and not the waveforms or related to the
>> waveforms as a whole, and not to specific points.
Okay, you checked the Waveform Annotation Module more closely (which is
now in the Standard as PS3.3-2008 Chapter C.10.10) if this matches your
needs? Maybe some of the "unformatted text" may be coded as not so
unstructured anymore, as Measurements may be stored as measurements etc.
Another hint: Did you evaluate the Structured Report IODs yet? There are
1.2.840.10008.5.1.4.1.1.88.11 Basic Text SR Storage SOP Class
1.2.840.10008.5.1.4.1.1.88.22 Enhanced SR Storage SOP Class
1.2.840.10008.5.1.4.1.1.88.33 Comprehensive SR Storage SOP
with their Definitions in PS3.3-2008 chp. A.35. This is the "modern" way
to store Observations and acquisition related information in DICOM.
Using Annotation Module or Structured Reports will involve a controlled
terminology for your texts and findings, but maybe you may start simple
and refine the implementation to match your requirements.
>>
>> So the question is: what's the recomended structure for adding to a
>> Waveform file one or several unformated text items with the patient's
>> clinical history, risk factors, medication, reason for the ER
>> consult,
>> symptoms and, at the other end, in the diagnosis center, how to
>> append/add the findings/diagnosys/recommendations.
>>
That is precisely what Structured Reports are about :o)
>> Our work conditions are absurd and there's such thing as "give me six
>> months to study these DICOM specs and I'll get back to you" so, if
>> anyone feels like helping us, please make it as simple as possible and
>> don't presume full understanding even of the Waveform supplement on ur
>> part.
>>
[...]
>
> If it is a problem finding suitable predefined tags to put these types
> of information, why dont you just create your own private tags and put
> this information there?
Sorry, "just create a private monster^H^H^H^H^H^H^H IOD and let it spawn
into the public" is the most dangerous and most incompatible method,
causing highest maintenance costs. You will be responsible for the
privatizations for the whole data lifecycle, and as the OP stated that
it is to be used in large rural areas, I also expect a long software
lifecycle. If there is a Standard Object might match your requirements,
give it a second evaluation and consider extending it with Standard Tags
(which is also allowed, but not really elegant).
If there is an IOD that matches, use it.
No clinical information in privatized objects will persist without heavy
efforts and maintenance - which will have to be done by *you*. Don't
tell me I did not warn you :o)
Some more points I have discussed recently with another group member,
please use groups.google.com and search for "Private data in SC or in
other modality ?" group:comp.protocols.dicom - this was just a few days
ago, so it might even still be available on your news server.
Also, I second Chris tip to have a look at toolkits and sample
implementations to help you create your software - there are plenty
around :o)
My EUR 0.02,
Peter
goodalle
acquisition for many years. These systems are fielded in remote
locations often with only the modality itself or a modality alongside
a dicom workstation with the ability to edit/modify DICOM headers of
the IODs received from the modality. Typically these systems don't
have a local HIS/RIS/PACS to be integrated nor do they have sufficient
or continuous network connectivity to allow them remote access to the
integration services they provide. For example the US Navy deploys
Xray with either file scanners or CR systems in the medical bays of
aircraft carriers and similar ships.
The approach we used was to provide forms based entry system where the
medical officer onboard the ship could enter clinical information
about the exam - reason it was acquired as well as extended dialog/
circustances about the entry. We put this information into the tag
Additional Patient History (0010,21B0) which is a long text field able
to accomodate lengthy discriptive information. (0010,21B0) was later
designated by the IHE as carrier for free text information from HL7
orders on the modality worklist.
However 0010,21B0 is in the Patient Medical Module --ie it is not
officially part of the Image composite IOD definitions. It was part of
the old patient and study management sop classes and therefore was
present in the dicom tag data dictionary To be "legally" included
image headers, it is supposed to be buried down in the request
attributes sequence. This has the issue that most dicom software at
the time (and continuing in many today), really doesn't make
information in sequences very accessible for easy viewing in the user
interface of the receiving systems. Typical viewers can only be
configured to display dicom attribute values from the "main image
sequence" and few of the older sequences.
On the other hand, most DICOM parsers will allow standard DICOM tags
to be included in the main image sequence even if they don't
technically belong there, and make the object technically non-
compliant to the IOD
So, for cases analogous to your own, we found we not only could modify
images from the modality to include information in the addition
patient history module, but in doing so we retained a lot of
interoperability because so many other people had done the same thing:
quite a number of viewing applications supported display of this
information with the images
Images were acquired on the modality onboard a ship, transferred to a
local workstation, and clinical information added to the field. Images
were then transferred using DICOM protocol over a satellite uplink,
modem, or network link to a receiving PACS/workstation in the US. In
the simplest case, the images are simply displayed with the Additional
Patient History attribute displayed in large text window. Our project
actually automated it, with another application running with the dicom
workstation to extract the information from the header, put it into a
form , and allowed the stateside radiologist to enter and sign a
report. The report was then emailed back to the originating medical
officer (whose email was embeddd in the free text field).
The 12 lead waveform IOD also doesn't include the additional patient
history (0010,21B0). Assuming an appropriate workstation at the
acquisition site, you could try adding it to the waveform main
sequence, but I think you might find the receiving systems may not be
quite so accomodating as imaging systems are. The waveform IODs were
developed more recently without the heritage of the fairly dirty
information models from ACR-NEMA. You might find the receiving systems
less tolerant of a tag where it is not supposed to be. I wouldn't rule
it out entirely, but I think you'd want to do some compatibility
testing before deciding to "go off the range" this way. On the
otherhand, they might well use the same base dicom libraries that
tolerate this kind of thing in the imaging world.
Give it a try and see where it takes you.
BTW - your idea to use the waveform annotation sequence is an
acceptable/valid use. If you look at the definition of the waveform
annotation module in dicom part 3, it contains the following:
Annotations may represent a measurement or categorization based on the
waveform data, identification of regions of interest or particular
features of the waveform, or events during the data collection which
may affect diagnostic interpretation (e.g., the time at which the
subject coughed).
You're not restricted to only certain types of content in annotations.
However their presentation, where they are supported for display at
all, tends to be intended for pretty short bits of text, so it may not
work for you. The issue you're going to have is the same as above
regarding 0010 21B0 - the question is "will the viewer used to display
the waveform support display of waveform annotations". Support for
standard annotation formats even within the imaging domain of dicom is
spotty at best.
Chris
> > Chris wrote:
>
> > If it is a problem finding suitable predefined tags to put these types
> > of information, why dont you just create your own private tags and put
> > this information there? You could create specific, defined private
> > tags within your 'DICOM ecosystem' which hold each of the types of
> > information you desire:
> > Clinical background
> > Medications
> > Symptoms
> > Diagnosis
> > Recommendations
> > Etc.
>
> was checking with the guys from the server side and they told me that
> they wouldn't be able to read any private tags and wuldn't budge in
> that direction because this practice (creating privat stuff) is
> discouraged by the standards. Despite all these warnings, I'm still
> interested in this option which, AFAIK, may turn out to be my
> best(only?) shot.
>
> As I mentioned before, I was handed down this task without the means to
> handle it, therefore my general DICOM knowledge is weak, to say the
> least, so I must ask: is what you're suggesting what's described in PS
> 3.3 - 2006, pg. 71, "8.7 - CONTEXT GROUP EXTENSIONS"?
>
> Can you or anyone else provide links to DICOM files (preferably
> Waveform) with private tags?
>
> Finally, you mentioned good & free DICOM tools avaiable. Since my focus
> is *exclusive* *to* *waveform* modality, could you provide some links?
>
> Again, sorry for my stupid questions and *many* thanks in advance for
> any comments, ideas, pointers, etc.
>
> Best Regards,
> Ronaldo
Hello Ronaldo,
I see you've got a lot of good tips here from Peter and Goodalle, who
seems to have a very good knowledge of the what tags exist and can be
used according to the DICOM standard.
It still seems like you might have some problems of how to get this
information into your DICOM files, and how to display it afterwards?
Perhaps some programs exist 'off the shelf' that are able to do this,
I dont really know, but if not, it seems you will have to develop a
solution to your problem. If so, there are a lot of free toolkits
available that may help you with your problem.
I will mention the one Im familiar with, Ruby DICOM (http://
dicom.rubyforge.org/), since Im the author of this DICOM toolkit. This
library will allow you to read, edit, and write all kinds of DICOM
files. It is fairly easy to install and use, since its written in the
wonderfully elegent Ruby language, and it's free, which is nice too.
I'll just throw out an idea here of what you can potentially do:
In the Ruby language we have something called Rails, which is an
amazing framework for building web applications with a database
backend, and it is very flexible and easy to use. By combining these
two programs, you can make your own DICOM web application, where you
have forms for filling in the different types of information you want
at the provincial clinic, and your web application can be programmed
to enter the information of these text fields in whatever DICOM tag
you tell it to. At your central 'analysis center', these files can be
read by the program, the content of the tags of your choice can be
displayed, and you can have forms where the specialist enters his
recommendations, which is then saved back to the DICOM file.
This will obviously require some development work, and its not clear
to me how much resources you have available to solve this problem.
There might be other solutions available to you which are better, I
really dont know. However if you should find this interesting, I would
be willing to stay in touch with you to assist.
Best regards,
Chris
Peter B Schmidt
after a first reading of your use case information, it seems to me (I am
not a physician) like some sort an order Information you want to convey
- I will have a closer look also at the IHE Documents [1] if there is a
best practice for these use cases - maybe the cardiology framework has
something for us...
Ronaldo Souza wrote:
> Oops. The only PS3.3 I have is 2006. Where can I find the 2008?
You can get the recent .pdf's at
ftp://medical.nema.org/medical/dicom/2008/
Old versions, Supplements, and Correction Proposals are listed at
David's site [2]
> One thing that confuses me though, is that C.10.10 clearly says:
>
> "Each Annotation Item shall have the following components:
> 1. An annotation Text, Coded Name (only), Coded Name/Coded Value
> pair, or Coded Name/Numeric Measurement pair (mutually exclusive)
> 2. Temporal coordinates in the Waveform to which the annotation
> applies"
I do not know if this is desirable, but how about setting the time span
to t=0 to t=(maximum time)?
> Most of the information is not related to the waveform at all, but to
> the patient and, even the findinds aren't related to any specific point
> of the waveform, but to the waveform+clinical history as a whole. For
> instance, the use of certain medications can alter the diagnosis
> completely. Wouldn't the use of annotations in this case be a bit of a
> stretch which, as you pointed out regarding private IODs, have the
> tendency to come back and byte one's ass?
:o) Well, yes. As I stated, I am not a cardiologist, but I can imagine
this. Nevertheless, to my layperson understanding, medication that may
change the interpretation of the ECG should be documented in the Object.
I wonder if the waveform annotation module really will be the best
choice - encapsulated CDA comes to my mind, but that's a completely
different point of view... I will look some more things up and come back
to you later, okay?
> It seems SRs are the way to go for me. Could you clarify a bit what you
> mean by "controlled terminology for your texts and findings"? Are
> "Concept Names" predefined in some dictionary?
It's about "Coding Scheme Designator" and Version (Attributes
(0008,0102) and (0008,0103) ). There are coded values defined in DICOM,
LOINC, SNOMED and others. PS3.17-2008 has plenty of examples and
reference on that, and Dave Clunie's book [3] which is available freely
has an excellent introduction to Structured Reports.
I will come back after I had a closer look. Stay tuned ;o)
Kind regards,
Peter
References:
[1] http://www.ihe.net/Technical_Framework/index.cfm
[2] http://www.dclunie.com/dicom-status/status.html
[3] http://www.pixelmed.com/srbook.html