Interfacing with Dicom sistems

[IVAN TRACHTA]

Hi xProgrammer (do not know your name)

I'm just learning about this.

For now what I need (i think) is this part of your answer: "For this application it just needs to be written as a file and dumped into a designated folder for another application to pick up and process..."

Basically I must export information to be properly accepted by an equipment (RM-Tomography-Mammography Radiology-digital or whatever).
This information (patient data, study data, etc.) are provided by my system.
Finding out I have an example in a book of what I think is the format (txt?) But I must investigate further. Another question is which folder is where you should leave such information.

I'll be waiting for any further information you can provide.

Sorry for my english, and thank you.

Iván

[xProgrammer]

Hi Ivan

What is the format of file you need to generate - HL7 or DICOM?

An HL7 file will begin with "MSH" (for Message Header) and if it is using the standard separator will contain lots of "|" characters and should be all text.

A DICOM file will begin with "DICOM " (from memory) and will contain binary data.

I do have code to generate and parse DICOM files - at least the nuclear medicine ones I encounter. Some extensions might be required for other modalities etc.

Regards
xProgrammer (Doug)

[IVAN TRACHTA]

Hi Doug

At first I think I need to generate an HL7 file to send data automatically to medical devices. This information has to be incorporated to their task lists. Then, after the medical study be done, the DICOM file generated (by de medical machine) is sent to the DICOM file server (PACS).

The DICOM files then will be administrated by the appropriate software for storing and viewing this kind of images.

In short, I understand that should I generate HL7 files to facilitate the job where the studies is done.

Surely i must leave the HL7 file (txt) in a default folder for each medical device for that purpose. I must investigate this now.

Thanks again and keep in touch this way.

Iván

[xProgrammer]

Hi Ivan

The HL7 message that I have to generate is a REF message (a referral). You probably need a different message although some of the segments are probably common.

I don't have the HL7 specification (you have to purchase it and it isn't cheap) but I do have sufficient information to generate an HL7 REF message (I think) from the provider of the messaging software that needs to receive it. Whoever wrote the software that needs to receive the message is probably a member of HL7 and can legally provide you with the information you need.

Personally I am opposed to IT standards that you have to pay for - standards should be open and free - but in our environment HL7 is (unfortunately) pretty much mandated. It is a great pity that the US government hasn't stepped in and made the standard free.

Regards
xProgrammer
(Doug)

[Jeff Barnes]

Hi Doug,

Did you ever end up creating your code to read/write HL7 messages?
If so, would you be willing to share your code?

Also, same question for DICOM

[xProgrammer]

Hi Jeff

Re HL7

I am sending HL7 messages in production use. Currently only 2 message types - from memory (will check when back in at work) REF and LAB2. In practice I found that local (Australian) implementations whilst supposedly following the standards had their own variations. Happy to share code but cannot guarantee how applicable it will be for you.

Re DICOM:

I have code that will parse DICOM files (well nuclear medicine ones that we generate) with some Philips extensions. Again happy to share code but would certainly need adaption and / or extension to whatever you are trying to do. I had a brief go at doing DICOM queries. I could establish a session, get back a confirmation and end a session but in the small time I had to play with it I couldn't get a response to a DICOM query even though when I used Wireshark my query looked exactly (aside from IP address) to one from another piece of DICOM software whose query worked. I need to parse brain scan files in DICOM format to extract the data for subsequent processing and have been doing that in production for a few years now.

If you tell me a bit more about exactly what you need to do I can be a little more specific about the extent to which I may or may not be able to help. Sharing code isn't a problem - although its probably not of that much help without some explanation which takes time and so isn't worth doing if it won't help you. My code does what I need it to do and isn't a total solution but the basics are probably pretty good but incomplete.

I am running Harbour on Ubuntu Linux here but the OS should make no real difference, Code is all OO.

Regards
Doug

[Jeff Barnes]

Hi Doug,

For HL7, I looking to parse the incoming HL7 message so I can populate my database with the patient info etc..

For DICOM, what I would like to do is take whatever info comes out of a DICOM enabled medical device and again, populate my database.
The DICOM side of things is not too urgent as this is only a "thought" at this point. I know nothing about DICOM and would need to do some research.

[vilian]

Hi Guys,

About DICOM/HL7 images, Did you have already looked at this http://www.merge.com/Solutions/Toolkits.aspx ?

[xProgrammer]

Hi Jeff

In production I am creating HL7 messages not reading them and extracting data. However as part of developing my code I wanted to test it before inflicting my messages on anyone so I wrote some code to read test messages that my software wrote and extract the original data out of them. I'll try to find that code. It's actually a very simple process for any given message type. You call HB_ATokens() to split the message segments on Chr(13). Then you split each segment into fields using HB_ATokens on "|". For some fields which can contain multiple values, or multiple parts within a value (eg names) you apply the same approach with "~" and "^" respectively. The first field in each segment gives you the segment type. You are porbably looking for the PID (patient identification) segment. Within each segment the meaning of a field is determined by its position - rather like the parameters to a function call in Harbour except the values being "passed" are separated by "|" rather than ",". And like a Harbour function call some values can be omitted, ie you can have "||" just like "''".

The structure of the PID segment is as follows. Don't assume that a sending system will stick to the maximum length specified (which is just a silly part of the specification). Also different implementations can interpret what goes into some fields differently.

The fields in the PID segment are as follows:
SEQ LEN DT OPT RP/# ELEMENT NAME
1 4 SI O Set ID – Patient ID
2 20 CX O Patient ID (External ID)
3 20 CX R Y Patient ID (Internal ID)
4 20 CX O Y Alternate Patient ID – PID
5 48 XPN R Y Patient Name
6 48 XPN O Mother’s Maiden Name
7 26 TS O Date/Time of Birth
8 1 IS O _
9 48 XPN O Y Patient Alias
10 1 IS O Race
11 106 XAD O Y Patient Address
12 4 IS B Country Code
13 40 XTN O Y Phone Number – Home
14 40 XTN O Y Phone Number – Business
15 60 CE O Primary Language
16 1 IS O Marital Status
17 3 IS O Religion
18 20 CX O Patient Account Number
19 16 ST O SSN Number – Patient
20 25 DLN O Driver’s License Number – Patient
21 20 CX O Y Mother’s Identifier
22 3 IS O Ethnic Group
23 60 ST O Birth Place
24 2 ID O Multiple Birth Indicator
25 2 NM O Birth Order
26 4 IS O Y Citizenship
27 60 CE O Veterans Military Status
28 80 CE O Nationality
29 26 TS O Patient Death Date and Time
30 1 ID O Patient Death Indicator

The make up of the patient name is in XPN format as follows:

SEQ LENGTH DT OPT TBL # NAME
XPN.1 194 FN O Family Name
XPN.2 30 ST O FirstName Given Name
XPN.3 30 ST O Second And Further Given Names Or Initials Thereof
XPN.4 20 ST O Suffix (e.g., Jr Or Iii)
XPN.5 20 ST O Prefix (e.g., Dr)
XPN.6 6 IS B 0360 Degree (e.g., Md)
XPN.7 1 ID O 0200 Name Type Code
XPN.8 1 ID O 0465 Name Representation Code
XPN.9 483 CE O 0448 Name Context
XPN.10 53 DR B Name Validity Range
XPN.11 1 ID O 0444 Name Assembly Order
XPN.12 26 TS O Effective Date
XPN.13 26 TS O Expiration Date
XPN.14 199 ST O Professional Suffix

Typically you will only get the first 5.

Hope that helps. Will try to find my test code. But you could probably have your own basic code up and running in an hour or two.

Regards
Doug

[xProgrammer]

Hi Jeff

I forgot to mention that at one time you had to pay to get the HL7 specification but now it can be downloaded free of charge.

BTW the DICOM specification has always been available for download free of charge.

Regards
Doug

[xProgrammer]

Hi Jeff

I thought the following might be useful information just in case you run into a source of HL7 messages where the preferred deliniators were not used

In HL7 messaging, the separator characters are also known as the message delimiters or special encoding characters. The following are the HL7 recommended values:
(x0D) Segment separator
| Field separator, aka pipe
^ Component separator, aka hat
& Sub-component separator
~ Field repeat separator
\ Escape character



The segment separator is not negotiable. It is always a carriage return (ASCII 13 or HEX 0D). The others are suggested values only, but usually used as indicated above. The HL7 standard lets you choose your own as long as you show them in the MSH segment.

The MSH is the first segment of all HL7 messages (except HL7 batch messages). The field separator is presented as the 4th character in the message and it also represents the first field of the MSH segment. Since the first field of the MSH is typically only a pipe,’|’, counting MSH fields becomes tricky. Field 2 of the MSH (MSH-2) contains the other separator characters in this order: component, field repeat, escape, and sub-component.

Thus, the following is an example of the beginning of an HL7 message:
MSH|^~\&|…

The delimiter values used in the MSH segment are supposed to be the delimiter values used throughout the entire message. Encoding HL7 messages in this manner allows an application parser to simply use the special characters in the MSH to parse the message. However, beware that many application parsers just use hard coded values and ignore MSH-1 (Field Separator) and MSH-2 (Encoding Characters).

Regards
Doug

[xProgrammer]

Hi Jeff

Re DICOM

Parsing a DICOM file is not that hard but it is somewhat more involved than parsing HL7 files in that:

there are options as to how it is encoded

it supports binary data

you have to read the lengths of data elements to determine where the next one starts

can switch between MSB and LSB formats

etc

I can certainly help with extracting information including patient demographics from DICOM files as I am doing that in production.

What I haven't done is get DICOM querying working to get the files there. For the very small number I need to process (maximum of 4 and normally only 2 on any day I have to process them they can come to me on a DVD.

If and when you want to look inmto that possibility let me know and I'll do my best to help.

Regards
Doug