8000 C-Get association released after associate · Issue #1955 · fo-dicom/fo-dicom · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

C-Get association released after associate #1955

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Naruuchi opened this issue Apr 3, 2025 · 3 comments
Closed

C-Get association released after associate #1955

Naruuchi opened this issue Apr 3, 2025 · 3 comments
Labels
question

Comments

@Naruuchi
Copy link
Naruuchi commented Apr 3, 2025

I followed the C-Get implemented in the fo-dicom sample and was able to retrieve some of the data from Sante PAC, but there are some studies and series that were unable to receive.
When I ask for 3 series in the same study, it sends back 1, other requests got released right after association accepted without any response.

Some other studies in my server are having the same issue, How can I address this ?

And by the way, how can I know which series are duplicates or incomplete to filter them out ?
@gofal
Copy link
Contributor
gofal commented Apr 4, 2025

Did you have any error in fo-dicom (some exception or similar)?

What does the DICOM log say, did the server initiate to close the association? Then you have to contact someone who has access to the server log to tell you why the server did not send you all the images.
One thing you could check here, is, if you are sending all required PresentationContexts in advance
https://github.com/fo-dicom/fo-dicom-samples/blob/9625023aa49e44f1c926254073cba5f7f1cde965/Core/QueryRetreive%20SCU/Program.cs#L61-L70
This is the tricky thing with c-get that you as the requestor have to agree on the abstractsyntax and transfersyntax of the images in advance before sending the actual UIDs of the instances.
In a smart solution, you would first do a c-find to get the knowlege about what images are availabe at the server. There you take all the different SOPClassUIDs of the images and add them as PresentationContexts of the followng c-get request.

you cannot know for sure. By DICOM Standard the UIDs have to be unique and there should never be some duplicated series with same UIDs but different content. And there is no mechanism to know if the series is complete. Usually applications are collecting images and have some timeout. if for some minutes no further data is receiving then the series is considered to be complete. But your application has to be designed in a way, that if further images of a series arrive, that you then will be able to update the data correctly and restart your processings

@gofal gofal added the question label Apr 4, 2025
@Naruuchi
Copy link
Author
Naruuchi commented Apr 6, 2025

Thanks for your reply. I will try your approach even though some PAC will not allow to CFIND on Image Level

@gofal
Copy link
Contributor
gofal commented May 21, 2025

Hope the approach worked fine. If there is still some problem with fo-dicom, then please provide more informations and please reopen this isssue. Meanwhile I will close this issue.

@gofal gofal closed this as completed May 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gofal @Naruuchi
0