Searching for commitment between PACS and VNA

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.

Which comes first the PACS or the VNA?

 

This is a question that several years ago was philosophical and interesting but not terribly relevant.  Today as the landscape is changing the answer for your organization is vital to your overall success.  Like all good questions the answer is….. It Depends!

First what do we mean by PACS  or VNA First?  It simply means in your environment after images are acquired, are they stored to a PACS, presumably for interpretation and then archived to the VNA for storage, or are they sent to the VNA first and then routed elsewhere.  As one might expect there are pros and cons to each strategy and the determination really relates to how each is used.  I hesitate to use the term workflow because it, like “train the trainer” is one of the overused terms in the industry.

A PACS first orientation is the more classical approach to a VNA.  The study is acquired by modalities, typically reviewed by a technologist at a PACS workstation in which demographics are verified.  There may be some study manipulation such as window leveling, deleting of images and general image QA.  Often times additional information is added in the form of scanned documents which can be anything from the insurance card, to technologist notes and worksheets.  Finally, the exam is marked as ready to be viewed by the physician or radiologist.  When the study is interpreted, and a report created the study is marked complete or reported.  At some point in this flow the study is put into the archive queue and it is sent on to the VNA.  In this flow the VNA is acting primarily as the archive, and in some cases is called the deep archive or cold archive.  If the study is ever needed again as a prior and it is not in local storage PACS will retrieve it as needed.

A VNA first orientation is a different flow.  After the images are acquired they are sent to a technologist imaging system.  At this step the image manipulation occurs, this can be done in a department-based system like a PACS, it could be on a dedicated QC workstation, web system or components in the VNA itself.  Then the study is sent to the VNA, which likely maintains a local cache, but could be a cloud-based system.  After the study is in the VNA it is ready to be read.  The study is then sent from the VNA to the reading station where the interpretation takes place.

One of the keys in the distinction between the two is how quickly the study is available in the VNA.  In a VNA first scenario the study is almost immediately available on the VNA.  This becomes important when there are multiple consumers of the image, such as an EMR integration that is serviced by the VNA not PACS.  A PACS first orientation the study is interpreted prior to archival which means the likelihood of the images changing is very low.  I would opine that the images should NOT change once they have been reported.  If they do, then an addendum is warranted.  This data flow also maintains a linear nature and is relatively simple.  There is value in simplicity and that should not be understated.   The downside of this is the time required for the image to get to the VNA and the relative inflexibility of the system.  If there is an issue with PACS or the study is “missed” it will not be available to downstream systems.

In the VNA first method there are multiple systems at play any of which could be down.  It is also a more complex workflow involving several steps.  The benefit however is near immediate access in downstream systems to the images as well as significant flexibility to integrate multiple data flows and systems.  A VNA first architecture allows for a reduced PACS footprint that can lower overall maintenance costs (often 15-20% annually of the PACS license cost).   It also supports the integration of multiple viewing systems for referring physicians, specialist viewers and outside contracted radiology groups.  I would also argue that it better supports the transition to PACS as a service or “deconstructed PACS” or PACS 3.0 whichever is your favorite term, as well as a multi facility multi PACS environment in which a single study needs to “live” in many places at once.

So back to the question, which is better?  It depends on what the current imaging needs are, in terms of access to images, how many systems are integrated and   what the future vision is for the system.  For simple systems stick with PACS first (your PACS vendor will love it!) if the intent is to implement more exotic workflows or there are multiple downstream systems it would be worth investigating a VNA first data flow.

 

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

The DICOM is in the Details! Part 2 the Query Retrieve

 

Given the apparent interest in some of the details about DICOM store transactions, thank you to all who read it!  I thought I would add in a brief description of Query / Retrieve and then next week I will write about my favorite, Storage Commit.

A DICOM Query Retrieve transaction is a fairly simple transaction. First there is a query, and then a retrieve, luckily the standards team didn’t go crazy with the names. The first part is of course the query, which is a C-FIND transaction. In a C-FIND we again have a service class user (SCU) and a service class provider (SCP). The provider is going to be the “server” and the user the “client” or the one making the request. The query can be for a study or for a patient. However, it does not have to be only one. The query could be for “all” patients, or All studies done on a certain date, or if you get a wild hair, all dexa studies completed on Friday the 13th that have a patient who’s first name begins with the letter Q.

No matter what the C-FIND attributes are (specifics of the query) the user will send the query to the SCP (provider) and the provider will then issue a C-FIND response. The response is the list of studies that meet the criteria.  Different systems have built in mechanisms to deal with large C-FIND requests, some will reject the request if it is too broad, others will limit the number of responses to and arbitrary number such as 300, while still others don’t mind at all and simply send back a very long list of matches.

The client or SCU now has a list of studies and may decide to retrieve the studies. The command to retrieve a study is typically not “send me x study” it is often a C-MOVE command. Which roughly translates to “send X study over there” with the there usually being the requester. This is mostly semantical, but interesting to me. The C-MOVE command consists of what study is to be sent and where it is to be sent. The where is an Application Entity or AE title. Once the C-MOVE provider has this information, it then begins a DICOM Store transaction with the AE title requested.  For info on the DICOM Store,

see The DICOM is in the Details!

(Yes, shameless plug for clicks)

One interesting note here, in the C-MOVE command the only destination is the AE title, it does not include the IP address or port! This gets complex because almost every PACS and modality has a standard AE title that the vendor uses for EVERY SINGLE INSTALLATION, I won’t call out a single vendor, because they all do it. This was not a problem back in the day because relatively few systems queried each other, and they were often different vendors. Now however, when you are building an enterprise system like a VNA it is not uncommon at all to have many PACS or CPACS from the same vendor. Which brings AE uniqueness into play.

Some PACS will have the ability to use multiple AE titles so you can simply add a new AE for your VNA to send back to, and not change the modalities. Other PACS will only support one AE title and you may have to reconfigure all modalities sending to it. Last tangential point on Query / Retrieve is that this process of C-FIND and C-MOVE is pretty much what all data migration companies do. They simply do a lot of transactions!

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

When a picture ISN’T worth a thousand words, where do reports fit into VNA’s and Enterprise Imaging?

 

In traditional imaging systems like Radiology and Cardiology PACS the report is always with the images. In Radiology, the dictation system sends a copy of the report to PACS via HL7 which is ok since it is text. In cardiology it is either a textual report, or the cardiology system creates the report and therefore has a copy. As we get outside of the walls of those two systems, where does the report really live?

For those that don’t read to the end … the answer is DICOM SR  in your VNA but please keep reading!

In an environment where all users are logged into the EMR and launching images from there, it is not an issue as the EMR is now the system of record for the reports and will have a copy. Now, IMAGINE A WORLD (queue deep commercial voice) where images are sent for reading to various physician groups who are not logged into the EMR.  Reading the newest image is not an issue, but what about priors? In some teleradiology workflows prior reports are faxed, others copy and paste prior reports from the EMR, and still others simply read what is in front of them.

I submit that there is a better way. As we move forward with outsourcing reads, and facilities are divested and acquired regularly it makes no sense whatsoever to not keep reports with the images. The two are intrinsically linked and are important for different reasons as part of the patient record. Luckily there are several mechanisms to resolve this. Surprisingly I don’t see them often implemented.

Let’s start with the low hanging fruit, cardiology. Since most CPACS have reporting modules within the system the report is already with the images before the images are archived and / or sent elsewhere. While I am all for FHIR and emerging solutions I prefer to stick with what I can implement today, now, and yes there are options. The simplest is to do an HL7 export to the EMR. This will provide the text but no images. Often times CPACS will generate a PDF report but that ends up being imported as a separate document into the EMR and not linked. There are actually 3 options to export a content rich report besides emailing the pdf.

The first is to utilize HL7 and the encapsulated document (ED) standard. The standard does exist, and it can be done but I have not seen it nor talked to anyone who has tried. The second is to store the PDF document in the XDS, I am all about standards and a big believer in XDS. The problem is that first you have to HAVE an XDS repository which many don’t, and secondly you need a system to act as the XDS source, which many (most) imaging systems don’t do. There is a very easy answer to this problem and one that has been around for a very long time it just isn’t used.

The easy answer is to DICOM Encapsulate the PDF report and store it with the images as another series. Many CPACS do this natively, it is as simple as clicking a button in the configuration to “archive report with images”.   Why this is not done more often is a mystery to me. This is a very good option for CPACS which commonly creates pdfs as the report product but for other systems that rely more on plain text is the PDF the way to go?

There are several options for textual reports as well. HL7 interfaces between systems is an option but HL7 tends to be more of an all or nothing proposition. Again, XDS offers several opportunities, we stored the text reports as CDA objects in XDS, however this shares some of the previously stated limitations with XDS, namely the lack of adoption so far. Still, there is an old school solution to this problem. The DICOM Structured Report (SR).  By using the DICOM SR one can store the report with the images, any time the images are viewed or sent to another location the report goes with it with no additional steps.

I did this with my VNA from the beginning and it has been a huge success as my EMR Viewer can process the SR and therefore when looking at priors for history the report is available for review without the hospitalist having to go back and forth to the EMR to view the interpretation that goes with the images. Similarly, any time images are requested by another facility or need to be shared for patient care the report is always with the images, either as a DICOM SR or an encapsulated PDF. See that was worth reading to the end wasn’t it?

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

The DICOM is in the Details! but how does it work?

Most of us use DICOM every day, we smell it, we live it and we talk about it. However, often the deep dark secured is that we don’t really know how it works. What is a SOP? What is a Transfer syntax? And why do the engineers keep talking about Endians?

To begin with lets quickly review how a DICOM Store occurs, the sending system initiates a transaction. The sending system is the USER of DICOM Store (Service Class User or SCU) and the receiver is the Provider of DICOM Store or the Service Class provider (SCP). The user says I have this study that I want to store. The provider (receiver) says great, here I am. Then the user says I want to send a Breast Tomosynthesis Image.

*nerd alert- The type of image to be sent is defined by the SOP Class, the SOP stands for Service-Object Pair which is the Information Object Definition (image type) and DICOM Service Elements (DICOM Wrapper).   The SOP for Breas Tomo is 1.2.840.10008.5.1.4.1.1.13.1.3, which is in a supplement.

https://www.dicomlibrary.com/dicom/sop/

At this time the provider will reply back with yes, no problem or no, I don’t know that that is. If the answer is yes and the receiver (SCP) supports that SOP (see how you are starting to get the lingo!) it will also send back the list of languages it speaks. We are all pretty familiar by now with the 3 types of compression, uncompressed commonly called DICOM, lossless compressed which is compressed but still ok for reading and lossy compressed in which image data is lost but is much smaller. Each of these along with several others are called in DICOM Speak a transfer syntax.

Once the sender and receiver have agreed on what will be stored, the receiver sends back a list of languages it speaks, or transfer syntaxes. The sender or SCU will then select one of these to send the image. Thus, it is the sender the decides whether or not the image is sent compressed or not. Implicit VR Endian is the default DICOM transfer syntax and therefore supported by ALL vendors.  Because of this, many vendors take the easy road and simply accept the default. This is … OK… within a LAN but when the data is stored or transferred over a WAN compression becomes very important.

https://www.dicomlibrary.com/dicom/transfer-syntax/

Now that SCU and SCP have agreed on what is to be sent and how it will be sent the data transmission goes. The transmission can be at the instance level which refers to individual images or at the study level in which many images are sent on the same association. Once the association is complete the sender may initiate a Storage Commit, which I highly recommend when sending to VNA across a WAN.

Briefly in a storage commit message the sender reaches back out to the provider and sends a list of all individual images that were sent. The Provider then responds back either positively that ALL images were received or negatively in which something wasn’t. In the case of negative the entire study is considered a failure and will be resent, which takes up a lot of your bandwidth.

Please like, share and comment. I would love to know what topics are of interest to the imaging people out there!

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org

How Big is a Mammography Study??

 

How big is a mammo study?

It depends. I was recently asked what is the average size of a mammography study. I asked for clarification, what do you mean? I received a somewhat strange look and the response mammography, you know breast imaging….

Bottom line up front, somewhere between 20 MB and 1GB per exam

The problem is that there is no easy answer to that question because well, it depends. For starters there is as we all know a huge difference between tomography and plain film mammo. So averaging the two would vary greatly depending on the ratio of tomo to mammo. If you look in your VNA they will often share the modality code MG so how do you tell the difference? Number of images? You could assume that anything over 10 images is tomo. Ok so the next way to tell would be to get into your database and do a query for the SOP Class Breast Tomosysnthesis Image Storage (1.2.840.10008.5.1.4.1.1.13.1.3) however, you will find that within a study you will have a few tomo images and plan mammo images stored. Then again, you may be working with a popular vendor who stores the tomo images in a proprietary and much small format using the secondary capture SOP class (1.2.840.10008.5.1.4.1.1.7) easy right? All you need to do is isolate out the 2D exams from the exams containing a 3D image, then find out if you are using the BTO SOP class or the secondary capture SOP, THEN you can average your exams and get the average study size, right? Well sort of..

NOW we need to determine if they are compressed or not. To figure that out you need to look at the transfer syntax. Many modalities will default to Implicit VR Endian, which is transfer syntax (1.2.840.10008.1.2) this is uncompressed. Many PACS will take the syntax that the modality sent and refuse to change it for fear of impacting image quality. Therefore, the study is stored on disk and in the long-term archive or VNA in the same format. Unless you get into inbound and outbound compression which is a whole different topic. There are of course many different transfer syntaxes with varying compression, but we will take the other common one, JPG 2000 lossless (1.2.840.10008.1.2.4.90). Either compression can be applied to any of the SOP classes described above.

So, the question stands, what type of mammo do you mean? Standard format or proprietary (but very common) and compressed or uncompressed. How you ask the question will skew the answer dramatically.  Given the trend in the market tomo is growing so the average in Dec 2017 is very different than the average in Dec 2016.

If you have read all the way through this, the breast tomo format lossless compressed averaged out to be 711 MB, while the secondary capture format also lossless compressed averaged in at 194 MB.

Kyle Henson

Please let me know what topics you would like to discuss

Kyle@kylehenson.org