Update Diagnostic Statement(s) in DICOM ECG

[VJP]

I am trying to update (change/replace) just the existing Diagnostic Statement(s) in a DICOM ECG.
Basically I want to change the statement and then save to DICOM again.

I tried setDiagnosticStatements() in DICOMFormat, but it looks like it just adds another annotation to the existing sequence. This Does not seem correct.

From DICOMFormat.cs:#

foreach (string line in stat.statement)
{
    Dataset ds = element.AddNewItem();

    ds.PutUS(Tags.RefWaveformChannels, s_MeasurementRWC);
    ds.PutUS(Tags.AnnotationGroupNumber, annotationGroupNumber);
    ds.PutST(Tags.UnformattedTextValue, line);
}

I need something Like replaceDiagnosticStatements that updates or replaces (Delete/Add) insted of just adding to the list of elements.

Also even if I add to, the code to read (getDiagnosticStatements) only gets the first annotationGroup number of statements anyway. And the saved file show error when dumping with OFFIS tools.

I could try to add replaceDiagnosticStatements to the code and see if I can make it work?
Or if setDiagnosticStatements does not work correctly and you can update? Let me know the best way to do this and how I can help.

Thanks,
VJ

[VJP]

I am making some progress with updating Diagnostic statements. However, I am not sure why the extra annotation text of (UN)CONFIRMED REPORT is added each time (or at all)?

If I open and save a DICOM ecg more that once, I get multiple of these is output file. This does not seem correct?

(fffe,e000) na (Item with undefined length #=3) # u/l, 1 Item
(0040,a0b0) US 1\0 # 4, 2 ReferencedWaveformChannels
(0040,a180) US 0 # 2, 1 AnnotationGroupNumber
(0070,0006) ST [UNCONFIRMED REPORT] # 18, 1 UnformattedTextValue
(fffe,e00d) na (ItemDelimitationItem) # 0, 0 ItemDelimitationItem
(fffe,e000) na (Item with undefined length #=3) # u/l, 1 Item
(0040,a0b0) US 1\0 # 4, 2 ReferencedWaveformChannels
(0040,a180) US 0 # 2, 1 AnnotationGroupNumber
(0070,0006) ST [UNCONFIRMED REPORT] # 18, 1 UnformattedTextValue
(fffe,e00d) na (ItemDelimitationItem) # 0, 0 ItemDelimitationItem

[MJB van Ettinger]

Hi,

Yeah that "UNCONFIRMED REPORT" was build in to imitate the Mortara DICOM files. I could provide a configuration item that allows you to turn off this behavior/feature.

I actually did some work on this before this year, perhaps the information will help you with your issue. Look at this discussion with Larry (https://sourceforge.net/p/ecgtoolkit-cs/discussion/863551/thread/08c738e2/?limit=25&page=0). That described the way it currently should work. With each update a new annotation group should be created. This allows to keep track of an history of the diagnostic statement.

If this does not work for you (or you would want to turn it off), I can provide a configuration item that will allow you to just replace the current diagnostic statement.

With Best Regards,

Maarten

[VJP]

Maarten,
Thanks for the response. I did not see where this thread discussed a history of diagnostic statements, but it makes sense. As long as it does not violate DICOM spec for ECG. I would be curious to see how other DICOM viewers handled it. I will review how it works now a little more to understand it better.

I would prefer to have config option to NOT at the Mortara Text to statement, just in case.

Thanks, VJ

[VJP]

Maarten,
Also getting back to beginning of this post, is setDiagnosticStatements() that best method to use to update the statement(s) text? Basically I have a DICOM ECG (Read from file) and want to save it to another DICOM ECG file, but I want to changed the Statement(s) text in CurrentECG.
-VJP

[MJB van Ettinger]

I can provide a configration item as you please. Leaves me with a question: how do you store wheter a diagnostic statement is confirmed?

In my opinion the setDiagnosticStatement is the right way to store the these statements. Maybe you prefer the system not to keep track of all the changes. I could also provide a configuration item to prevent this from happening (just remove the previous statement).

If I got a code fix is it enough for me to just commit to the CVS or do you want a bug-fix as well.

[VJP]

Maarten,
Sorry for the delay, I was out of office for a couple weeks. While I do lie the idea of tracking annotation (interpretation text) changes, our DICOM expert does not think adding a new annotation group with different number is they way we should do it. He is concerned that other DICOM readers may not know which annotation is old or new since the spec (2011) does not specify a precedence in DICOM.

C.10.10.1.4 Annotation Group Number
The Annotation Group Number (0040,A180) allows the logical association of multiple annotations
within the current SOP Instance. Such linked annotations share an Annotation Group Number,
but each annotation is semantically separable. The nature of the association is not defined. The
number is not semantically significant.
Note: For instance, the R-wave in several waveform channels may be annotated, and all occurrences
of the same R-wave could be linked in an annotation group. 

We have our own way to handle DICOM updates with auditing and DICOM precidence information stored.

So if you could add a way to configure setDiagnosticStatement to just overwrite, that would be great. That is basically what I do in the updateDiagnosticStatement method I added, but I would prefer to use your lib without having to modify it.

Let me know how I can help. Thanks, VJ

[MJB van Ettinger]

I almost forget about this issue.

Will try to look at this issue tomorrow if I can find the time. Otherwise I will look at it again next week.

[VJP]

Thanks

[MJB van Ettinger]

I just published a patch that might help you.

There is now a Configuration item (to the DICOM plugin) added that allows you to fine tune what you need. The configuration item is called: "Mortara Diagnostics" and values that can be used are: True (default), False, StateOnly or HistoryOnly. My guess is False will work for you.

Can you let me know if this works for you.

[VJP]

I will try it next week. If I have ver 2.3 with no patches, do I need to apply all previous patches in order? BTW, another person now wants the statement history and thinks the way you do it might be perfect. So I will be testing both configurations, thanks again.

Mostly talking about source code changes since I am building toolkit myself.

[MJB van Ettinger]

Latest patch will be enough. All previously changed dlls are included.

I put quite some effort in the support for an history of measurements and diagnostics. So that is why I was not going to remove it. And in the end making it configurable will suite you perfectly, especially if there are no (new) bugs after my latest changes.

I'm very intrested if this works for you so let me know how it turns out.