Searching for commitment between PACS and VNA
Kyle Henson, DM
Helping CEOs & CIOs fix every IT issue in their healthcare system. If it’s broken, call me and your problem is solved.
Many moons ago when most PACS was designed the archive was local. It is the A after all in PACS. Now that the industry is moving inexorably to a deconstructed model, or PACS as a service the archive is rarely on the same LAN as PACS. Not only is it not on the same LAN but the fact that it is a separate application means that different rules may apply. For example, some systems accept DIOM studies with alpha characters in the study UID, others will allow series or images to be stored in two different studies with the same SOP instance UID. These variations in interpretation or enforcement of DICOM standards lead to problems when storing to the VNA. There are times when a DICOM store transaction is successful, but the study is not accepted into the VNA. There can also be a delay between the time a study is received by VNA and when it is actually stored to disk as many VNA’s have some sort of inbound cache or holding pen while processing data. This discrepancy can create a problem where PACS believes a study to be stored but it is not actually stored, which is of course heresy for an archive.\
It turns out that there is an old-school, little used solution for this very problem. It is the arcane process called DICOM Storage Commit, and I highly recommend that every VNA owner enable this process for all sources that support it. During the DICOM store transaction each image should be acknowledged as received and in theory any images that are not acknowledged as received would be resent by the PACS or other source system. In practice there are a number of places where this does not occur. The storage commit is a separate transaction that occurs after the DICOM Store. The sending system will generate a new transaction in which it lists every image that was sent. The response includes a list of every image with a success or failure. If any image is listed as a failure then the source system can resend the image or the entire study, most tend to resend the entire study.
One problem with using storage commit is that many vendors have ignored this transaction for quite some time the result is that it is often less than optimally designed or configured. Some systems have defaulted timeouts, and others batch up storage commit messages while others will not archive anything else until the commit is received. Even with these limitations it is worth it. The fundamental problem is that when a source believes that a study has been archived it is then available to be deleted or flushed from the cache. If for some reason it did not successfully archive there is then there will be data loss.
You can read all of my articles at kylehenson.org
VNA, PACS/ Imaging Informatics Project and Operational SME
6 å¹´Yes, without storage commit you are asking for trouble. However, you need a clean VNA and clean data storing to the VNA, or a PACS that doesn't retry storing infinitely; otherwise a 4,000+ object CT will become 400,000 object count ct paused in a queue until the study's reconciled. Therefore, DICOM storage commit must be implemented as a fully managed service and then it's benefits will be fully realized.
Focused Volunteer bringing critical healthcare technology systems to deserving people
6 å¹´One thing we are missing here of course is the concept of why aren't the VNA and PACS vendors recommending this in the first place? After all, if a customer places their trust (backed up by an army of lawyers and contracts of course) in a set of vendors, shouldn't those vendors (after all they are the SME in their domain aren't they?) know and understand the best practices to use? And if they don't know and understand the best practices to use, do they really deserve your trust and money?
Uniting Clinical Imaging, EHRs, Drug Trials and Patients
6 å¹´This type of feature is actually key to us where we work 100% over wireless where disconnection events are expected to happen. We need to fully reconcile before we can delete photos taken. Same goes for storing data over the cloud. In that scenario, its also important to do some simple checksum of the dataset to ensure that every byte is stored unaltered.
Focused Volunteer bringing critical healthcare technology systems to deserving people
6 å¹´As you noted in the article, DICOM has worked better in theory than in practice as many DICOM implementations out there are really in name only and not in working situations. I remember working with a hospital which wanted to use GE for their Radiology Department but McKesson for the rest of the facility - don't ask... long story on that one. Anyway, the IT analysis who was in charge told me that he found the solution to make everything work smoothly and it was DICOM 3.0. Unfortunately for the hospital, DICOM follows the old 80/20 rule - 80% of the time it works out of the box, 20% of the time you wonder did everyone read the same standards document?
The AI-guy, Assisting in AI technology deployment, entrepreneur, expert trainer/consultant on PACS, interoperability, standards.
6 å¹´Agree, storage commitment has gotten a second life, it has been useful as a hands-off between modalities and PACS but in my opinion it is essential between a PACS and long term archive such as VNA or cloud