I am putting this under "known bugs" even though it might be considered to be a "desired feature". Basically, I believe I have confirmed that PacsOne.exe does not support all of the SOP classes that come from our Philips MR scanner.
This is a significant problem because we want to use PacsOne to archive all of our studies, and we need to be able to restore and rescan the same protocol used for a study. The custom Philips SOP classes store the protocol information necessary to perform a rescan. If we cannot find a way for PacsOne to store the custom SOP classes, we will have to find another solution. Also, I think that MR spectroscopy will also not be stored properly until the private SOP class associated with it is accepted by PacsOne.
Interestingly, import of files that are of the custom SOP type does work - at least for the ones tested so far. However, the MR scanners will be sending studies via a true DICOM connection - individual file import is not an option.
Below is a list of the SOP classes that may come from the Philips scanner:
Supported by PacsOne (appears in PacsOne.exe binary file)
=====================================
MR Image Storage = 1.2.840.10008.5.1.4.1.1.4
Enhanced MR Image Storage = 1.2.840.10008.5.1.4.1.1.4.1
MR Spectroscopy Storage = 1.2.840.10008.5.1.4.1.1.4.2
Secondary Capture Image Storage = 1.2.840.10008.5.1.4.1.1.7
Grayscale Softcopy Presentation State = 1.2.840.10008.5.1.4.1.1.11.1
Raw Data Storage = 1.2.840.10008.5.1.4.1.1.66
NOT IN PacsOne.exe
=============
Private MR Spectrum Storage = 1.3.46.670589.11.0.0.12.1
Private MR Series Data Storage = 1.3.46.670589.11.0.0.12.2
Private MR Examcard Storage = 1.3.46.670589.11.0.0.12.4
I hope there is a way to add support for these SOP classes. In fact, I think the best solution is to allow for user-defined custom SOP classes so that a user could enter the SOP class numbers into a text file that is read by PacsOne.exe A similar ability exists in many other DICOM devices that I have encountered.
Also, please let me know if this support is definitely not possible, because in that case we must move onto finding another pacs solution.
thank you,
ebw
Philips SOP classes
Re: Philips SOP classes
These are private storage SOP class definitions, which means there may be vendor specific data encoded in such images that can only be recognized by equipments from the same vendor.ebw wrote: Private MR Spectrum Storage = 1.3.46.670589.11.0.0.12.1
Private MR Series Data Storage = 1.3.46.670589.11.0.0.12.2
Private MR Examcard Storage = 1.3.46.670589.11.0.0.12.4
These private SOP classes used to be popular by major modality vendors as they help a lot to "lock-in" customers, because only applications from the same vendor will be able to receive/read/display such private images. That's one of the primary reasons why the Dicom standard committees have recommended strongly against using private SOP classes or private data elements, as doing so will disencourage vendor inter-operability and will eventually hurt the customers because of less choices available.
On the hand, it's pretty straight forward to add support for such private SOP classes to PacsOne Server, as all we need is a sample of such private image to test and verify our implementation. If you'd like to send us the samples, please send them to: mailto:pacsone@pacsone.net.
Thank you for your reply. I also think handling private/custom SOP classes is frustrating, but it is unfortunately a reality.
In this case, it is not necessary for PacsOne to do anything with the binary blobs of information which have the DICOM header wrapped around it. I just need for the files to be accepted by PacsOne and associated with the correct patient/study/series so that export and download of the "normal" images also has the private SOP come along too.
When I used the import feature of PacsOne, the private SOP classes were accepted and did come back out when performing an export or a download operation. The private instances added to count displayed in PacsOne, but they did not appear in the list to select as "images" - and that is okay.
The private SOP classes below are not images. There is no need for PacsOne to have to "render" or unpack anything beyond the DICOM header that surrounds the binary blobs. In other words, these files just need to go along for the ride. In fact, it is almost preferable that the instances of theses files do not appear in the list of series displayed by the PacsOne web interface.
Private MR Spectrum Storage = 1.3.46.670589.11.0.0.12.1
Private MR Series Data Storage = 1.3.46.670589.11.0.0.12.2
Private MR Examcard Storage = 1.3.46.670589.11.0.0.12.4
The series data and examcard allow for the series to be restored/rescanned fully onto a Philips MR scanner. There are also many pieces of useful information in the series binary blob. We have our own tools to unpack that information. We just need the file to be accepted and stored by the PACS so that we can export/download it from the PACS later. The spectrum storage is necessary to use spectroscopy tools available on the Philips MR scanner.
Because the direct data import accepted the private files, it is obvious that the PacsOne database is capable of storing the above private SOP classes. It is just a matter of changing the DICOM server to allow these SOP classes to come via a DICOM connection.
I really hope it is possible for changes to be made to allow the acceptance of the above private SOP classes. I will send example files to the provided email address asap. Please let me know if there is any other information that I can provide.
Thank you very, very much,
ebw
p.s. I am running PacsOne premium on Mac OS X Snow Leopard (10.6.2)
In this case, it is not necessary for PacsOne to do anything with the binary blobs of information which have the DICOM header wrapped around it. I just need for the files to be accepted by PacsOne and associated with the correct patient/study/series so that export and download of the "normal" images also has the private SOP come along too.
When I used the import feature of PacsOne, the private SOP classes were accepted and did come back out when performing an export or a download operation. The private instances added to count displayed in PacsOne, but they did not appear in the list to select as "images" - and that is okay.
The private SOP classes below are not images. There is no need for PacsOne to have to "render" or unpack anything beyond the DICOM header that surrounds the binary blobs. In other words, these files just need to go along for the ride. In fact, it is almost preferable that the instances of theses files do not appear in the list of series displayed by the PacsOne web interface.
Private MR Spectrum Storage = 1.3.46.670589.11.0.0.12.1
Private MR Series Data Storage = 1.3.46.670589.11.0.0.12.2
Private MR Examcard Storage = 1.3.46.670589.11.0.0.12.4
The series data and examcard allow for the series to be restored/rescanned fully onto a Philips MR scanner. There are also many pieces of useful information in the series binary blob. We have our own tools to unpack that information. We just need the file to be accepted and stored by the PACS so that we can export/download it from the PACS later. The spectrum storage is necessary to use spectroscopy tools available on the Philips MR scanner.
Because the direct data import accepted the private files, it is obvious that the PacsOne database is capable of storing the above private SOP classes. It is just a matter of changing the DICOM server to allow these SOP classes to come via a DICOM connection.
I really hope it is possible for changes to be made to allow the acceptance of the above private SOP classes. I will send example files to the provided email address asap. Please let me know if there is any other information that I can provide.
Thank you very, very much,
ebw
p.s. I am running PacsOne premium on Mac OS X Snow Leopard (10.6.2)
Re: Philips SOP classes
Hi, we would really appreciate it as well if you could implement this.