.. specifically what part of the specification covers confirmation from the PACS to the imaging modality that images have been received?
Thanks

Isn’t DICOM some sort of hi-tech, underground enemy lair?

*sends black helicopters to peterfile’s location*

Are you talking “storage commit” or the way most modalities use the succesful end of negotiation to assume?

Need more information to point you in the right direction. Assuming you are not talking storage commit. Can you describe the problem? Would it be difficult to tell me the modalities?

Edited due to Baccus finger on the ipad

Modalities are sending to PACS. If PACS isn’t available, modalities show an error. But we had a case where the modalities were sending, no errors being shown, so modality operators were under the impression everything was ok when in fact it wasn’t as images weren’t being stored. PACS supplier claiming not their problem and attempting to weasel out of SLA penalty.
All modalities on one site affected, usual suspects, CR,CT,MR,US,XA
It’s all resolved now and we’re fighting about money

My stand – (I believe) the DICOM standard says that the SCP confirms the Storage Commit to the SCU and failing to receive the Storage Commit message is what triggers the error message on the console. I need to be sure of this so need to know the relevant part of the protocol to quote.

Cheers

Isn’t DICOM some sort of hi-tech, underground enemy lair?

not if you’re the enemy, then it’s a high-tech, underground, friendly lair. or fair for short. with XA (eXtra Acronyms)

Did the modalities have details for a Storage commit SCP? Assuming you are in UK it is not that common to be using Storage commit.

Your understanding is not quite correct as mentioned earlier lots of modalities put a tick in the sent box when the send association finishes orderly. This does not guarantee the images have been stored.The error on the desk you mention would most likely be generated by either a breakdown or timeout of the store association.As you say when PACS was offline. If it is 100% a commit field you had the ticks in then you may be able to pursue. Need to know for sure if you are using commit on the modalities. I would not expect this to be the case outside of US.

Off to work now as in a different time zone but will look in later.

We’ve been running quite successfully with this PACS for 7 or 8 years with no real problems and with all modalities sending – a fair size of site including about 10*CR 2*MR, 2*CT, different suppliers for different modality types. Then one day they all stopped sending. Normally, if the PACS is unavailable for any reason (PACs down, network issue, whatever) the modality consoles will display an error message making the operators aware and they contact me. But in this case, there were no errors and the first we knew was when end users tried retrieving from the PACS but images weren’t there. PACS supplier contacted, they checked logs couldn’t find a problem, but whatever it was resolved itself a few hours later. The support contract includes an SLA stating they will resolve problems of this severity in x hours, which in this case they didn’t do and are being hit with a penalty of sufficient amount that it’s worth my while spending time on it. They deny any responsibility as they (claim to have) found nothing wrong.

Given that there is normally an error message regardless of the fault it’s obvious that the PACS sends confirmation that the image has been stored (like a TCP ACK, and this is what I’m referring to as Storage Commit) and that this, along with the storage, failed. My understanding, and I’m getting close to digging out the manuals on this, is that this confirmation is a mandatory part of the DICOM v3 standard, not optional, and if so and this is what failed, then they (PACS suppliers) have no arguement that it wasn’t a PACS fault, nor any argument as to the severity of the fault. Arguing a DICOM compliance failure shortens the discussion, but even if this is an optional element to the standard, it has been selected on our modalities, so they fail anyway, but not on DICOM compliance and they will argue this point.

longer winded than I’d intended, but basically what I’m looking for is a pointer to the relevant sections of the DICOM v3 standard becasue I know there is a lot of it.

Cheers

Mornington Crescent.

I was trying to establish if you were using Storage commit or not to help me point you to the most relevant part of the standard.

Best guess from what I have got would be part 7: Message exchange.7.4.2 ASSOCIATION RELEASE Page. 14 Download from http://medical.nema.org/standard.html

😆 cougar

Not sure you are going to be able to argue compliance failure. Sounds like the PACS has conformed to the standard in so much as it has made and released all the associations correctly. Hence the ticks on the desks. What it has done with the images only the PACS guys will know.

Naughty boy Cougar.. just trying to help

Sure. I’m just trying to be stupid. We all play to our strengths.

Sounds like the PACS has conformed to the standard in so much as it has made and released all the associations correctly.

Not if I read it right because the images weren’t stored but the storage was confirmed to the modalities. If the images were stored anything like correctly, the resend when the issue was fixed would have caused problems because the unedited images would have had the same GUID. Unless (second cup of coffee kicking in) the images were actually stored correctly but the database wasn’t updated, so the resend would work because the GUID wouldn’t have been recorded. Although I would have thought that the database update would be the last thing to be done and the ACK/confirmation would have been triggered at that point. But

What it has done with the images only the PACS guys will know.

still points at a PACS failure in some respect and is probably good enough to start an arguement

Thanks

Yes PACS failure. Nothing to do with DICOM conformance though.

Stay clear of that argument. Stick to the fact all the associations negotiated and released (tick on desks) yet no images were present to review. Loss of service not arguing standards and their implementation.

If the penalty clause is big enough get someone in that knows their stuff. If not one of the suppliers of the modalities may be willing to help if you are a big enough account.

Good luck with it though.

got it – the term i was looking for was c-store response success/fail . possibly not a dicom conformance issue but definite service failure.

And that’s

? not getting that picture reference.

TV/numbers based/faster version of Mornington Crescent

WOW