Stable public PACS test server?

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

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, 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.

1 Like

I should add that for our testing our javascript dicom networking client we set up dcm4chee running in docker which is workable for continuous integration scenarios but probably not good for slicer testing.

1 Like

For testing, you can also use DCMTK’s Query/Retrieve Service Class Provider. See 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. See for example the list of services provided by dcm4che.

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.

1 Like

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.

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

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:

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