Back to Basics

5 years into my VNA experience the one thing I can say is that, the KISS principle applies.  The only way to easily maintain your system, after it is up and running, is if the build is very orderly from the beginning.  To that end, it cannot be stressed enough that sticking to the basics of system design and deployment is critical.  One way this is achieved is by utilizing well thought-out naming conventions and time-proven, standardized processes.

Before the first system is brought online the team should focus (obsessively so) on the naming conventions.  These naming conventions need to be easily identifiable and baked into every nook and cranny of your system; from AE titles all the way to network shares.  Typical things that one should consider including in naming conventions are: site name, the type of system and the function.  Bearing in mind that AE titles are limited to 16 characters, it is important that the names be easily and consistently identifiable.  During troubleshooting situations, the VNA team will be looking for these names in the logs, so ease of use is paramount.  An example might be HOSA_FS_R_AE standing for hospital A, Fuji Synapse, Radiology, AE title.  The last two characters could be changed to DB for database, ST for storage or any other internal component related to each particular system.  Once the naming convention is set it needs to be passionately enforced as there is often enticement to loosen the standard to fit this site or that site.   Although there might be a circumstance that truly requires it, under 99% of situations you should not give in to this temptation!  Consistency in troubleshooting and training of new VNA team members are only two, of the many, reasons as to why uniformity is key during name convention decisions.

Similar to the idea of constancy in naming conventions is the creation of standard operating procedures.  The team needs to create a checklist for regularly occurring actions, such as: adding systems to VNA, testing new VNA releases, starting and finishing data migrations and verifying during PACS upgrades.  Each of these line-item tasks needs to be simple, straight forward, and DOCUMENTED.  There are many tools available in the VNA and there may be a temptation to get fancy with tag mapping / morphing, adding in sophisticated routing rules or any one of the myriad of features and functionalities that are available.  While these features are useful, remember that customization is the antithesis of supportability.  The team should determine what features and functions to use, and site 100 should be configured similarly to site 1.  This is not to say that there are no circumstances under which customizations should be used, however, they should be build-necessary customizations and not simply because one wants to play with all the cool tools in the toolbox.

There is a myriad of things to consider when planning and architecting a VNA, of which, naming conventions and SOPs are but two.  And, while this idea of a back-to-basics approach is neither new, nor specific to VNA design, it is an intelligent and proven method to utilize when laying the foundation upon which to build your Enterprise Imaging system.

What ever happened to “deconstructed PACS”? More to the point, what would it take to achieve?

Several years ago, “deconstructed PACS” was the hot topic, also called PACS as a service, PACS 2.0, PACS 3.0, de-coupled PACS etc.  During that time many organizations made purchases based on the idea.  These were often a Vendor Neutral Archive (VNA) and a Zero Footprint Viewer (ZFV) for web and EMR viewing of radiology images.  Dictation systems have remained constant and have for the most part always been separate from the PACS.  There are several global worklist companies out in the market that have been around for a long time.   For the most part these worklist systems have been focused on the needs and requirements of teleradiology and large radiology groups.  That said they do a very good job of consolidating multiple sources of data, usually many hospitals and EMRs into a single worklist and assignment engine to get the right radiologist to read the study at the right time.  With all of this technology, why have we not seen the panacea of a deconstructed PACS come to fruition?

The answer surprisingly is that as an industry we have focused on many of the hard problems and forgotten that we still need a system to do what the PACS of yore did, and that is a departmental workflow system for the technologists.  There are several functions that need to occur before image data can be submitted into the machinery of the Enterprise Imaging Systems.  These are, while seemingly mundane extremely important:  DICOM Modality Worklist, Document Scanning, Quality Control (QC) and image management, and order validation, all tasks that are completed by the traditional PACS.  We will explore each of these in turn.

DICOM Modality Worklist (DMWL) is essential, as it ensures that images match an order, and all demographics are correct.  In my belief, a manual process is a broken process and typing in a 16 character accession number correctly is a recipe for disaster. In short something must provide DMWL and it should be used in all cases.

Document Scanning is an area I struggle with as in this day and age we should be able to remove all paper from the process.  I firmly believe that the only documents to be scanned, or electronically completed are documents that are required to be viewed by the radiologist and will alter the diagnosis.  This MUST be stored as a series with the images.  I submit that there is probably a better place for the data (the EMR) but that is another topic.

QC and image manipulation is simply verifying that the images are good and possibly adjusting the window/level.  There is sometimes a need for splitting, merging, deleting and moving images but this has gone down over the years and most of this is done at the modality.  The main point of this step is that this is the last opportunity for a technologist to review the study.  As soon as the image is released it becomes “ready to read” and will be picked up by a radiologist somewhere in the ether.  Given that in the new model it is unlikely that the tech can walk down the hallway and speak to the radiologist this step gains significance.  Like a bad picture on the internet, once it is out, it can’t be taken back.

The final task is order validation, with consistent use of DMWL this step should be not necessary, but in the real-world things happen.  In a distributed system where the worklist is driving reads from HL7, any study that does not match an order will not be read.  It can’t, as the dictation system needs to respond to an order with the report.  The viewer can’t launch it because the accession number does not match an order.  This last verification step is a gatekeeper step to ensure that every study has an order, as my old coach said, “no pass, no play”.

Again, PACS does all of these tasks, so what happens in a deconstructed model?  These tasks could be performed by the incumbent PACS, however most of the old guard has an inflated pricing structure and huge service maintenance contracts.  They tend to be not interested in this market, (or even the imaging center market).  Most of the smaller PACS companies are fixated on the diagnostic reading license and will not un-bundle the software at a relative price point to service this need.  We need a vendor or vendors to supply a light weight low cost departmental workflow system to feed into the enterprise imaging stack.  The only thing holding us back from deconstructing PACS is performing the simplest tasks that PACS does at the right price.  My challenge to the vendors out there is, who wants to fill this need and gain a footprint in almost every large organization?  Bear in mind that as a component of enterprise imaging this could be a foot in the door to then service one of the other components…. I would think that would be an attractive proposition, but the market has not responded thusly.