STUDYID has illegal characters

[Algie Rosario]

Hi All, 

I have an issue regarding "illegal characters" in a patient STUDYID.

The studyID looks like this

1.2.40.9.13.1.201502121421.1685669757.A%209484620

and even WEASIS cant open it.

Why and How does this happen? It happens in CR Modality.

Im using dcm4chee 2.17.1

Thanks in Advance.

[jne...@gmail.com]

You can try to coerce the invalid UID using the cstorerq.xsl template, prior to inserting the data in dcm4chee. I have had success doing that to remove leading '.' characters, which is also invalid.

Something similar to this might work:

<xsl:if test="contains(attr[@tag='0020000D'],'A%')">
         <attr tag="0020000D" vr="UI">
            <xsl:value-of select="normalize-space(translate(attr[@tag='0020000D'],'A%',''))"/>
         </attr>
</xsl:if>

Also look at the 'CoerceBeforeWrite' option in service=StoreScp . Setting that to True will make the coercions before inserting the data into the dcm4chee database.

cheers,
Jordan

[NicolasPasini]

Hi Algie,

I have seen many dicom files and I never seen an ID like this before.

1 - If your are using Modality WorkList, you should first check that system, since the MWL provide that value.

2 - If you are not using Modality WorkList, then you should ask to the CR specialists. One thing you can do by your own, is to export the dicom file from de CR to a CD or USB. 

Then copy the file to you Laptop and use some tools to "DUMP" (to see) the content file, to check the ID.

Yo have to trace that ID, which is in fact the StudyInstanceUID

(0020,000d) UI [1.2.840.113845.11.1000000001951524609.20150207124235.2522695] #  60, 1 StudyInstanceUID

Make sure the dicom file is correct before is processed by DCM4CHEE PACS.

Who is the manufacturer of that CR btw?

If this ID value, it is really an error, then try to find the solution in the MWL or CR. 

I dont know that much the way DCM4CHEE parses the files. That's why I would check first the original dicom file from the CR.

If you see that it has illegal characters, then there is something wrong in CR or MWL and not in dcm4chee pacs.

Well, That's what I would do first at least....before trying to coerce the invalid UID.

If there no way to solve this, then I would do what Jordan has mentioned.

Regards,

Nicolas P

[Algie Rosario]

Hi Jordan and Nicolas!

Thank you so much for your effort and help. And i will try both your suggestions.

Youre both a great help =) Cheers.

I will message again if i found any of the problem. Thanks

[Algie Rosario]

Nicolas the manufacturer of CR was Fuji. It is Fcr console.

[Algie Rosario]

Hi Nicolas and Jordan, as per checking we are using the dcm4che editmwl.jar to process the hl7 file given by the clients HIS.

And also this process gives the StudyInstanceUID. The workflow is like this:

HIS ----dump HL7 file to a folder---------> PACS MPPS (editmwl.jar will process/parse the HL7 and insert to MPPS table for WORKLIST) ------- modality will query-----> MODALITY

I believe that dcm4che MPPS service will create/give the STUDY_IUID of a patient.

Please correct me if im wrong.

Thanks

[NicolasPasini]

Hi Algie,

Sorry, I don't know how the dcm4chee's worklist works, but yes, what you said is correct. HIS is sending the hl7 message. Dcm4chee will populate the worklist queue, so that way the CR modality will be able to ask and get the StudyInstanceUID.

 You could try to find in DataBase the row related to that study to check the StudyInstanceUID, if it is wrong , then something went wrong with the woklist.

 Is this happening with all CR studies ?

 Is this happening only with CR modality ?

 I am just asking questions to provide further information to the comunity. I haven't worked yet with dcm4chee's worklist.

Btw, there is a table in DataBase called "mwl_item".  That table has a column called "study_iuid". Try to find the row related to that

patient/study. Using the column "accession no" (Accession number) as the the key for the WHERE clause.

Just to let you know, the StudyInstanceUID belongs to a study, not patient.

Hope someone else can give you more information to solve the issue.

Regards,

Nicolás

[Algie Rosario]

Hi Nicolas,

Yes I founf the database and table for worklist:

mppsio > mwl_item > column study_iuid with value "1.2.40.9.13.1.201502121421.1685669757.A 00038458" 

This only happen last week with 1 patient, then this week for 2 patient of CR modality only. Not all all studies.

I dont know where to check with the dcm4chee JAR file.

Or maybe Jordan's suggestion is a possible solution?

Thanks

On Friday, February 13, 2015 at 11:41:08 AM UTC+8, NicolasPasini wrote:

Hi Algie,

[Algie Rosario]

Hi Nicolas,

Already found the problem. It because of the clients patients registration on their HIS server.

Its like this:

MSH|^~\&|PATIDOK|V9.8.0.000|MCC||201502121421||ORM^O01|MCC|P|2.3|

PID|||00038458|2015809551^1000458408^|SITI RAEDAH BINTI MAHYUDDIN^^^^||19780410|F|||NO.34 1ST FLOOR NEW BUSINESS CENTRE, LEBUH PULAU PINANG OFF JALAN MERU^^Klang^^41050^|0|||MAL|3|5||A 9484620|||5||||||

PV1|||1110^^^2008^^^^^DIAGNOSTIC IMAGING||^||2026^GENERAL PRACTITIONER ^^||||||||||||2015809551||||||||||||||||||||2008|||||201502121420|||||||||

ORC|NW|2015809551-2|||||^^^^^3|0|201502121421|mrazziuddin||0^Internal Physician^^^^|1110|||^^|2008|1110^01||

OBR||2015809551-2^1||62011197^CHEST - GP^^^^||201502121421||||||||||||||||||||||||||||||||||||||null

The red mark contains "space". 

Thank you :)

On Friday, February 13, 2015 at 11:41:08 AM UTC+8, NicolasPasini wrote:

Hi Algie,

[NicolasPasini]

Hi Algie,

Well Done !

I opened the hl7 with HL7 browser software. You are using the SSN Number - Patient to generate part of the STudyInstaceUID.

Did you configure that ? is it optional ?

Can someone clarify this ?

Regards,

Nicolás

[Algie Rosario]

Hi Nicolas,

Yes its already configured in the codes of parsing the HL7. 

My client said it was the Patient's Passport Number which is essential to them.

Anyways, thanks Nicolas :)

[Algie Rosario]

Nicolas maybe you know how to Mapped Values from Modality.

Like this images:

But please disregard the red mark..

Thank you soo much :)

On Friday, February 13, 2015 at 8:30:55 PM UTC+8, NicolasPasini wrote: