ECG to PDF issue

Larry
2013-02-21
2013-05-09
1 2 > >> (Page 1 of 2)
  • Larry
    Larry
    2013-02-21

    I'm trying to convert a Cerner ECG (Dcm) file to a PDF file via the objects, and am getting an error on the check of the IECGFormat.Works() method.  I've tested using the Example DCM file, which worked fine, as well as a sample file directly from Cerner, which worked fine. Now I'm testing using a real ECG dcm file that I am retrieving from the system using Cerner's web services, and when I get to the code of checking the format object following the ECGConverter.Instance.Convert method, I'm getting a FALSE back from the Format object Works() method.  I'm wondering what could be causing this.  What is the purpose of the Works() method anyway?

    Code clip:  (written in VB.NET v3.5)

    ECGConverter.Instance.Convert(objSrcfile, "PDF", objConfig1, objDst)

    If IsNothing(objDst) OrElse Not objDst,Works() Then
       Throw error
    End If
    ================================================

    The objDst object is not Nothing (null), but the Works() function is returning FALSE.  This didn't happen with my previous sample files, just the "real" file…figures…

    Thanks in advance for any help you may be able to provide!

    Larry

     
  • There are multiple reasons why works function returns false. But in most cases it is due to bad configuration of the PDF plug-in (for the provided input file). Are you using the right values in the configuration you use. This can be checked with ConfigurationWorks() (or is works on the config object).

    Also there can be issues with specific input file you are using for this.  (Aka a bug)

    Did you try to convert this file using the ECG Viewer? This will give you an indication of the available configuration fields for the PDF plug-in. Because the availble lead formats are indicated by the ECG Viewer.

     
  • Larry
    Larry
    2013-02-22

    Hi mvanettinger,

    I didn't even think about using the tools provided with the DLLs…duh!  However, when I try opening the Cerner DCM file with ECGViewer, it just has a blank screen.  I tried opening the sample file I received directly from Cerner, and it opened to the ECG image, so I'm not sure what's wrong with the actual production file.  I also tried to use ECGTool.exe to convert it, but got a "Conversion Error" message similar to what my own code produced.

    As I mentioned above, I am using a Cerner web service to retrieve the binary stream of the DICOM file, that I am then in turn saving to the DCM file that I run through the converter.  This is the first time I'm testing the usage of the web service, although I've followed what Cerner has told me on how to utilize it, so maybe there is something going on in the web service process when it's pulling the file.  I'll check with Cerner on that.

    I'm not quite sure what you mean by, "Are you using the right values in the configuration you use".  I'm not overriding any config values, if that's what you're asking. I'm just calling the ECGConverter.Instance.getConfig("PDF") to return a config option that is passed directly into the Convert code you see above.  How can I use the ConfigurationWorks() method to check out what might be wrong with this file?

     
  • Hi Larry,

    Well if the screen stays empty (white). Then the DICOM file isn't read right. This can be because of two reasons (I can think of):
    1. There is a bug in my dicom-plugin that prevents the reading of this DICOM file
    2. The DICOM file contains an embeded PDF instead of real waveforms.

    If you know that the 2nd is the case then there is no solution (not completly true I know there are people that retrieve signals from PDF files). If you don't know or are sure that the second isn't the case I can take a look at the sample of the file that isn't working for you.

    With Best Regards,

    Maarten

     
  • Larry
    Larry
    2013-02-25

    Maarten, the file is definately not an embedded PDF, it is a DICOM image file generated by a Mortara ECG Kart.  I spoke with Cerner, and sent them a file that wasn't working.  They ran it through various converters on the web, and while most failed, some didn't.  One that failed returned the message, "Error code: For input string: '1.' "  What they were able to determine from that was that the file contains a value of "1." in some VR DS field that they were not able to identify. Apparently the ECG Tooklit converter is having a problem with the fact that the value isn't in proper decimal format with a trailing "0".  I'm not really familiar with the DICOM structure, but Cerner indicated that the DICOM standard is ambiguous as to whether missing the trailing "0" is valid or not. The converter built into the Cerner product uses Java and handles this by converting the retrieved value to a double data type, which changes the value from "1." to "1.0". Cerner was actually the ones that directed me to ECG Toolkit, but they didn't really have an answer as to what to do about this issue.

     
  • Hi Larry,

    Shame on me for using the standard parse functions in dotNET:-)

    Will take a look at these fields and check if I can solve this issue easilly. If I got a patch should i send you a copy or is posting the patch on this site enough?

    The ConfigurationWorks function only replies true or false, but it will indicate that the issue might be configuration related. Specifically the PDF plugin has got some very usefull items like setting the "Lead Format". Example of correct value is "ThreeXFourPlusOne", but it might not work if the ECG isn't standard 12 leads.

    With Best Regards,

    Maarten

     
  • Larry
    Larry
    2013-02-25

    Hi Maarten,

    I really appreciate your help on this!  Posting a patch on the site is probably best.  That way, if we aren't the only ones to run into this issue, it may benefit others.  I'll also send you a sample DCM file to the email address you sent me.  That may help you better identify where the converter is catching the data issue.  As far as I know, this is supposed to be a "standard" 12-lead ECG.

    Thanks again!

    Larry

     
  • Just discovered the issue originates in the dicom# library. This code isn't ported to MonoDevelop yet. Luckilly I'm a developer on this project, but this requires quite some additional effort.

     
  • Larry
    Larry
    2013-02-27

    Thanks for looking into this for me!  Is it a major modification?  How long before you see any change to the dicom# library happening?  Just trying to get an idea of whether or not I have to look for a different solution or not, as the project I'm involved with is a bit time sensative.

    Thanks again!

     
  • It will require some digging around.

    Also compilng the dicom# library isn't compatibile with higher .NET version (3.0, 3.5 and 4.0) right now. So propably have to fix that as well.

    I will take a better look at it on Monday. I guess it should be possible to solve the bug in a week or maybe two. I will make a special build if it turns out to be to much work.

    Keep you posted about my progress.

     
  • Larry
    Larry
    2013-02-27

    Thanks for the quick turn-around on the update, Maarten. Is it necessary to compile the dicom# library with a later version of .NET, or can it be fixed and compiled using whatever version it is currently compiled with?  Since I know that you can still reference a library written in a lesser .NET version, I am just trying to understand what the concern was with compiling the library.

    Let me ask you, now that you've seen an issue, is this something that you would want to "fix" regardless of my project?  Since it's going to take at least a couple of weeks, and we are trying to find a solution in less time than that, I don't want to ask you to go out of your way to make these changes if it isn't something that you would do anyway.  I'm not quite sure what to do right now.  We have another open source, albeit Java-based, "potential" option, but it hasn't been tested yet, and we have to use another 3rd-party person to help us develop a web service around it in order for us to utilize it from VB.NET.  I don't have sufficient enough experience with Java to be able to set that up, at least not in a quick fashion. So…I think I will approach this 3rd-party and see if they can at least test the Java converter against the file that your converter doesn't like to see if it has the same issue or not.  If it doesn't, then I'll have to see if they can create what we need sooner than a couple of weeks.  I don't want to tell you NOT to continue with updating the dicom# library, but I understand your time is valuable, and I don't want to put you out either.

     
  • I tried looking at the file you provided using: dcmdump.exe by DICOM@OFFIS and I get this very strange result:

    D: $dcmtk: dcmdump v3.6.0 2011-01-06 $
    D: 
    D: DcmItem::checkTransferSyntax() TransferSyntax="Little Endian Explicit"
    W: DcmItem: Non-standard VR  ' (00\00) encountered while parsing element (fffe,e00a), assuming 2 byte length field
    W: DcmItem: Parse error in sequence item, found (fffe,e0dd) instead of an item delimiter
    W: DcmItem: Non-standard VR  ' (00\00) encountered while parsing element (fffe,e00a), assuming 2 byte length field
    W: DcmItem: Parse error in sequence item, found (fffe,e0dd) instead of an item delimiter
    W: DcmItem: Non-standard VR  ' (00\00) encountered while parsing element (fffe,e00a), assuming 2 byte length field
    W: DcmItem: Parse error in sequence item, found (fffe,e0dd) instead of an item delimiter
    W: DcmItem: Non-standard VR  ' (00\00) encountered while parsing element (fffe,e00a), assuming 2 byte length field
    W: DcmItem: Parse error while parsing element (fffe,e000)
    E: dcmdump: Invalid tag: reading file: TestECG.dcm
    

    I definitly know little about the DICOM standard, but looked in the DICOM standard and the tag isn't part of the standard. It is possible the error happens just before the reading of this tag value.

    Probably best choice to try another way to solve this issue..

     
  • Larry
    Larry
    2013-02-27

    I downloaded the "DicomUtilities", which allowed me to run the dcmdump against the original file, and it doesn't have these errors.  Looks like these errors were caused by the patient information obscuring process.  Not sure how to remove that information now in order to send you another file.

     
  • Larry
    Larry
    2013-03-01

    Maarten, I've sent you the file that cerner returned from me after running a toolkit that they have to obscure patient information.  Hopefully you'll be able to garner more information from this file.

     
  • Thanks for the new file.

    You actually described the issue spot on with your post  #5. My first changes actually resolved the issue.

    Will make a patch based on these changes today.

     
  • Larry
    Larry
    2013-03-02

    That's terrific, Maarten! I wasn't expecting a patch that soon. I'll give it a try on Monday. Thank you SO much for your help with this!

     
  • Larry
    Larry
    2013-03-04

    Maarten, I tested the patch and it does now get past the problem data.  Thank you! 

    However, there are a number of differences in the PDF image when compared to our production version.  One of the differences is that, as may be expected, the converter is creating a PDF with all 12 lead graphs shown.  For whatever reason, we only show 4 leads on our images.  Is there a way to control which leads appear in the converted PDF? 

    Also, there are several numeric values missing from the converted PDF, such as the "PR int", "QRS dur", and the "QT" part of the "QT/QTc" fields.  They all come out as "0" from the converter, whereas the production chart has actual values for those fields.  I did find these values in the DICOM file using dcmdump, but they all were ones that had a decimal point without the trailing zero, although so was the "QTc" part of the "QT/QTc" field, and it does appear on the converted image.

    The "Reviewed by" field comes out as "^^^^", where there is a physician specified on the production, and I do see the physician value in the DICOM file. 

    The patient First name isn't being written to the PDF, only the last name.

    The DOB is in the format, "DDMMYYYY", whereas ours is in long format "DD, Mon YYYY".

    The Age is also coming out as a "0", although I do find it in the file.

    Our production version also shows a Location value, which is in the DICOM file, but it doesn't appear on the converted PDF.

    Can some, or all, of these be controlled via configuration values, and if so, how would I specify them?

    I'm not sure if you can help with all of these issues or not.

    Thanks!

    Larry

     
  • The PDF plugins allows you to configure the format its output. I am not sure which format you are talking about but it sounds like 3x4. If you want this as your output you have to set the "Lead Format" configuration item to "ThreeXFour". From command line this would be:

    ECGTool.exe -C "Lead Format=ThreeXFour" file.dcm PDF file.pdf
    

    All allowed values are:
    Regular (default)
    ThreeXFour (for 3x4)
    ThreeXFourPlusOne (for 3x4+1)
    ThreeXFourPlusThree (for 3x4+3)
    SixXTwo (for 6x2)
    Median (for the Average Complex if provided)

    Probably added a bug with my new parse functions. So I will take a look at this right now. Will also look at the Physician field to see what might be causing that issue.

    I never got around making all the output of the PDF plug-in configurable. But because the code is Apache Version 2.0 you can also take the PDF sources and make a special PDF-plugin that suits your needs (without being required to publish your code changes).

    With Best Regards,

    Maarten

     
  • Larry
    Larry
    2013-03-04

    That worked!  Although, it was actually the "ThreeXFourPlusOne" option that needed to be used.  Is there a help file or something that will tell me all of the configuration options allowed for DICOM to PDF?

    Thanks,

    Larry

     
  • I can't really find what the issue is with the measurements values yet. Maybe I will have more luck tomorrow.

    But for now this explains the PDF-plugin configuration items:

    Lead Format (I already explained)
    Paper Type: A4, LETTER, A4_Portrait, LETTER_Portrait
    Gain: default: 10 (mm/mV)
    Speed: default: 25 (mm/s) when changing this value Lead Format will be ignored.
    Grid: true or false
    Extra Leads: default value is empty, Specify the extra leads (labels, comma separated) for ThreeXFourPlusOne (value "V6" will display V6 as fourth lead) or ThreeXFourPlusThree (value "V4,V5,V6" will display V4,V5 and V6 as fourth, fifth and sixth lead)
    Document Title: empty (PDF Title field)
    Document Creator: empty but obvious purpose (PDF Creator field)
    Document Author: empty but obvious purpose (PDF Author field)
    Header Image: default empty, provide path to an image that will be displayed at the right top of the PDF.
    Free Text: default empty. A field that allows free text to be added to the PDF. syntax is a bit odd:

    X1,Y1:Text1|x2,y2:Text2
    Where:
    X1,y1 is the location from top left in mm (inches when using LETTER) for "Text1"
    x2,y2 is the location from top left in mm (inches when using LETTER) for "Text2"
    
     
  • Oeps forget about the font size. The syntax allows a bit more tweaking You can add an fontSize value in front of the each line. So this will also work:

    x1,y1:Text1|x2,y2:Text2|fs3,x3,y3:Test3
    Where:
    x1,y1 is the location (two nummeric values) from top left in mm (inches when using LETTER) for "Text1"
    x2,y2 is the location (two nummeric value)s from top left in mm (inches when using LETTER) for "Text2"
    x3,y3 is the location (two nummeric values) from top left in mm (inches when using LETTER) for "Text3"
    fontSize3 is the font size (one nummeric value) of "Text3" displayed at location: x3,y3
    
     
  • Larry
    Larry
    2013-03-04

    Ah…good to know. Thanks!

    I don't suppose you have any VB.NET experience, do you? The reason I ask, is that while I was able to get the proper Lead Formats using the ECGTool program, now I'm trying to implement that particular config into my VB program.  The problem is that I can't seem to figure out the VB syntax to add this config.

    From the ECGTool source, I know the C# syntax is:  config1 = (string) _Config.GetByIndex(i)

    When I tried using that syntax in VB as,   config1("Lead Format") = "ThreeXFourPlusOne"  ,  I get a value of "Nothing".

    I've also tried,  config1.Item("Lead Format") = "ThreeXFourPlusOne",  but get the same Nothing value, so I don't know what syntax I can use to get the value into the config1 ECGConfig object.

     
  • Larry
    Larry
    2013-03-04

    Okay, I wasn't wrong on my syntax, just the timing of it.  I figured it out.

     
  • Hi Larry,

    So I solved part of the issue with tbe values. First of there was a bug in my new parse functions. Just should have tested it better.

    Besides this currently the DICOM-plugin doesn't read the fields "PR Int", "QRS Dur" and "QT dur". I origanally assumed that "Ponset", "Poffset", "QRSonset", "QRSoffset" and "Toffset" are always available. This is assumption that originates from the UNIPRO and SCP-ECG standards. I already added support for reading of the PR int, QRS dur and QT dur for formats like MUSE-XML, but I never implemented it for the DICOM plug-in.

    So that is what I will be doing next. I think I will be able to produce a patch on Thursday.

    With Best Regards,

    Maarten

     
1 2 > >> (Page 1 of 2)