# Stable public PACS test server?

**URL:** <https://discourse.slicer.org/t/stable-public-pacs-test-server/19026>\
**Category:** Development\
**Created:** [August 2, 2021, 1:14pm UTC](https://discourse.slicer.org/t/stable-public-pacs-test-server/19026 "2021-08-02T13:14:27Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![rbumm](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rbumm/32/9404_2.png) [@rbumm](https://discourse.slicer.org/u/rbumm)\
**Post date:** [August 2, 2021, 1:14pm UTC](https://discourse.slicer.org/t/stable-public-pacs-test-server/19026/1 "2021-08-02T13:14:27Z")

</div>

Can anyone recommend a stable public PACS test server with a permanent CT or MRI (for reading) included?  
Thank you.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [August 2, 2021, 2:33pm UTC](https://discourse.slicer.org/t/stable-public-pacs-test-server/19026/2 "2021-08-02T14:33:28Z")

</div>

Unfortunately there aren’t any that I know of. The problem is that it costs computer, network, and administration resources to maintain a stable server and nobody has committed to that. Even the dicom standards committee and radiology societies haven’t stepped up to offer a stable testing implementation, which is a shame because it makes it hard to test dicom software.

The default one in the dicom module, [dicomserver.co.uk](http://dicomserver.co.uk), which I see you were using too has been up for many years now and has been a valuable contribution to the community but I think it’s a “best efforts” policy and the server and the contents are not assured to be stable.

I’ve been trying to convince Amazon and/or Google to host something a public archive with a wide range of valid (and invalid) dicom data and dicom networking protocols (dimse and web) but there’s nothing yet that I know of.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [August 2, 2021, 2:37pm UTC](https://discourse.slicer.org/t/stable-public-pacs-test-server/19026/3 "2021-08-02T14:37:23Z")

</div>

I should add that for our testing our [javascript dicom networking client](https://github.com/dcmjs-org/dicomweb-client/blob/master/test/test.js) we [set up dcm4chee running in docker](https://github.com/dcmjs-org/dicomweb-client/blob/master/test.sh) which is workable for continuous integration scenarios but probably not good for slicer testing.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [August 2, 2021, 3:21pm UTC](https://discourse.slicer.org/t/stable-public-pacs-test-server/19026/4 "2021-08-02T15:21:28Z")

</div>

For testing, you can also use [DCMTK’s Query/Retrieve Service Class Provider](https://support.dcmtk.org/docs/dcmqrscp.html). See [JRC2013Vis.py](https://github.com/Slicer/Slicer/blob/master/Applications/SlicerApp/Testing/Python/JRC2013Vis.py) as an example of using this server in an automated test.

Of course an enterprise-level server has many essential features that simpler DICOM servers typically don’t implement. DICOM actually does not even specify essential features, such as how to delete data sets or rename a patient, or provide solutions for fine-grained access access control. These are defined in higher-level protocols, such as [HL7/FHIR](https://www.hl7.org/fhir/). See for example the [list of services provided by dcm4che](https://dcm4che.atlassian.net/wiki/spaces/ee2/pages/2555933/Services+MBeans).

If you want to set up DICOM server on public internet for hosting non-public data then I would recommend to let a professional service provider (a hospital or a reliable cloud computing company) to manage it. It is not just about technical ability to set up and operating the server, but taking full responsibility for it. Large companies employ many experts in setting up and managing secure information systems, and they still buy liability insurance to cover the costs incurred by inevitable hacks and information leaks.

---

<div class="post-metadata">

**Author:** ![rbumm](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rbumm/32/9404_2.png) [@rbumm](https://discourse.slicer.org/u/rbumm)\
**Post date:** [August 2, 2021, 3:38pm UTC](https://discourse.slicer.org/t/stable-public-pacs-test-server/19026/5 "2021-08-02T15:38:12Z")

</div>

Thank you, Steve and Andras - the question was just related to have a default when a user presses “Load public PACS access data” in the (possibly upcoming) PACS Connector extension. A default setting, which reliably works on the first try on a normal internet connection with a permanently available public CT dataset, which I could provide resp which we already have.

---

<div class="post-metadata">

**Author:** ![rbumm](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rbumm/32/9404_2.png) [@rbumm](https://discourse.slicer.org/u/rbumm)\
**Post date:** [August 2, 2021, 3:46pm UTC](https://discourse.slicer.org/t/stable-public-pacs-test-server/19026/6 "2021-08-02T15:46:34Z")

</div>

Maybe we should set up one for testing purposes, read only

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [August 2, 2021, 7:02pm UTC](https://discourse.slicer.org/t/stable-public-pacs-test-server/19026/7 "2021-08-02T19:02:15Z")

</div>

Yes, that could be useful for test data. For testing real pacs integration there are a lot of dimse-level messages we’d ideally want to test (storing to the pacs, storage commit confirmation, etc). Realistically we’ve found that researchers don’t have access and shouldn’t be messing with the pacs anyway in most cases so it’s not been the highest priority for Slicer’s use cases.

In terms of reference data for testing here are some more notes:

> **[GitHub - pieper/dicomzoo: DICOM data for testing and tutorials](https://github.com/pieper/dicomzoo)**
>
> DICOM data for testing and tutorials. Contribute to pieper/dicomzoo development by creating an account on GitHub.

Also here are some more notes about using the dcmtk tools for testing:

> <https://github.com/commontk/CTK/blob/master/Applications/Testing/Cpp/ctkDICOMApplicationTest1.cpp#L30-L58>