Journal of Medical Imaging will launch in 2014

September 17th, 2013 http://dejarnette.com

12 September 2013 – In early 2014, SPIE, the international society for optics and photonics, will launch the Journal of Medical Imaging (JMI), covering fundamental and translational research and applications focused on photonics in medical imaging.

The scope of JMI initially will mirror that of the annual SPIE Medical Imaging symposium. Topics will include imaging physics, tomographic reconstruction algorithms (such as those in CT and MRI), image processing, computer-aided diagnosis, visualization and modeling, image perception and observer performance, technology assessment, ultrasonic imaging, image-guided procedures and digital pathology.

"The new journal gives the field of medical imaging, which continues to be more and more interdisciplinary, a home for scientific presentation, discussion, review and archiving," said Dr. Maryellen Giger, A.N. Pritzker Professor of Radiology/Medical Physics at the University of Chicago, who has been appointed editor-in-chief.

Authors are invited to submit articles beginning 1 October 2013, with publication to begin in early 2014. More information is at http://www.spie.org/JMI.

JMI will be published in print quarterly and online in the SPIE Digital Library as each peer-reviewed article is approved for publication, with the online version freely available to all readers in the first year.

"The medical imaging community has a long association with SPIE through the annual symposium the Society has hosted for more than 40 years," noted SPIE President Bill Arnold. "Applications of these technologies have helped save lives through better diagnosis and less invasive treatments, and the field keeps expanding to meet more needs. Supporting the community with a home journal is a significant step forward."

"SPIE is delighted to be able to respond to the needs expressed by the medical imaging community, in particular authors who currently participate in the Medical Imaging symposium. The new journal will provide them a rigorous, peer-reviewed option for their work and help maintain and foster the already well-established connections within the community," said SPIE Publications Director Eric Pepper.

Because it is open to submissions internationally, JMI will also serve to strengthen connections and facilitate collaboration among researchers in academia, medical institutions, industry, and government labs throughout the larger imaging community, Giger said.

Provided by SPIE—International Society for Optics and Photonics

Archiving of non-DICOM data with xDLT

Http://dejarnette.com

A frequently asked customer question is, “how does xDL handle non-DICOM data?” The answer is both simple and complex. The simple answer is that xDL will handle any non-DICOM data from the perspective of an archive.

Non-DICOM data is any medical data that can be considered part of the electronic medical record. There are two problems with this type of data, how it is transported across a network and how the data is associated with information already existing in the archive so that it can be accessed and used logically.
There is no general purpose standard for communicating and requesting the storage and retrieval of medical documents other than XDS, which is not widely used today. As a consequence, the approach taken with xDL is to offer a number of options for the interface of such data producers and consumers. There are currently large numbers of systems in the field which provide for scanned documents encapsulated in a DICOM object. Similarly a common mechanism amongst hospital IT departments is to use HL7 to communicate “documents” that are outside the normal workflow. Both of these mechanisms require agreement between the different vendors providing systems to the customer as they are non-standard usages, generally. The xDL allows the use of all three of these transport methodologies XDS, HL7 and DICOM to provide the most compatibility with today’s existing equipment.

The use of the transports mandates data that allows the archive to associate the medical data with existing data within the archive. Patient level data is the minimum required by the archive to associate data and this is the minimum provided by all of the aforementioned transports. It should be noted that simple file transport methodologies such as CIFS or NFS do provide a common transport methodology but they do not allow any metadata to be associated with the storage. This is acceptable for a simple archive but not acceptable for an archive that is designed to associate like data together.

Non-DICOM data can be presented to the xDL for storage as a DICOM encapsulated document, a document presented within an HL7 message or an XDS document. Non-DICOM data today can be retrieved as a DICOM encapsulated document, a document within an HL7 message or as an XDS document. All non-DICOM data, unless it is presented as an XDS document, is stored as a DICOM object. Sufficient context information must be supplied via DICOM or HL7, to associate the document with a patient. XDS is guaranteed to provide sufficient context information.

As an XDS Repository any XDS document can be stored to and retrieved from xDL. The xDL does not need to interpret or “understand” this data in order to store it. Today, there are few devices that support the XDS profile, but that list will grow in the future. If the XDS document is a DICOM document then it is also possible to retrieve it via DICOM or HL7, to the extent that retrieval makes sense.

xDL also has the ability to store and retrieve non-DICOM data that is included as part of an HL7 message. For instance it is possible to store PDF, JPEG, TIFF and other image types in the xDL via HL7. This is a particularly flexible method to store non-DICOM data as the core of the company’s HL7 messaging technology is the ERI. ERI (external record interface) is a general purposes message parsing and generation facility that is driven by a customization file. The customization file allows for customization through “scripting”. The ERI is built upon the company’s 20+ years of experience in providing HL7 interfaces to the medical imaging world. It is possible to not only perform text data manipulation but also image format conversion.1

Through “scripting”2, data manipulation and format conversion can occur either on the way into xDL or the way out of xDL.
Table 1 below shows the various combinations of how non-DICOM data can be acquired, stored and retrieved.
Table 1
Today, most non-DICOM document interfaces are achieved through the described methods. It is envisioned that improved workflow and data quality can be achieved by more tightly coupling the xDL to non-DICOM data producers. For this reason, the company is to bring to market a general purpose non-DICOM Document Acquisition/QC station. The company has in the past developed and marketed acquisition stations for acquiring non-DICOM images and conversion to DICOM or other imaging standards.

Storage Method	Storage Format	Retrieval Method
		DICOM	HL73	XDS	WADO
DICOM Encapsulation	DICOM	Y	Y	Y	Y
XDS DICOM Document	DICOM	Y	Y	Y	Y
XDS non-DICOM Document	XDS	N	N	Y	N
HL74	DICOM	Y	Y	Y	Y

1 As xDL projects are deployed, the number and type of “off the shelf” data conversions increases. The development of these conversions is driven entirely by sales. Development and deployment of these conversion scripts are generally quick and safe, with regards to effect on the rest of the xDL system.
2 Perl is the primary scripting language used by the ERI. 3 Data manipulation is available at time of retrieval.
4 Data manipulation is available at time of storage. 

Medical Image Storing is Driving the Growth of Vendor Neutral Archive Systems

http://dejarnette.com

High growth in medical data storage in vendor-neutral archive (VNA) systems will drive strong demand for VNA solutions over the next five years, according to a report from market analysts IHS.

VNA is a general term for networked storage systems in which images and documents are archived in a standard format so they can be accessed by any computer system.

According to the IHS report entitled Medical Enterprise Data Storage — World — 2013, growth largely will be driven by the migration of picture archiving and communication system (PACS) images to VNA. In addition, other imaging departments are also adopting the concept of VNA interoperability.

The Asia-Pacific has been identified as a high-growth region, with the annual VNA study volume growth estimated at 83.3%. This is predominantly due to legislation and increasing support for interoperable care between departments and healthcare provider sites in Asia during the next five years.

“The migration to VNA has been the biggest trend in the healthcare IT market for the past 18 months,” said Shane Walker, senior manager for consumer and digital health research at IHS. “VNA is set to be at the forefront of how all hospitals manage their patient images during the next decade. The technology is moving beyond its initial goal of simply managing PACS images. Instead, migration of PACS to VNA also is leading to the establishment of solutions for non-PACS departmental information, thereby shaping the future of how all information is shared and stored in healthcare.”

The management of images is becoming more important. The key objective is to share images between physicians in multiple regions, and even countries, irrespective of vendor or location.

Taking Australia as an example, with its six states and multiple territories, vendors seek to provide state-level solutions in order to improve the interoperability of care. A similar approach is being taken in countries such as China at a provincial level, albeit at a slower rate compared to Australia’s VNA adoption.

At a healthcare provider level, all hospital departments using image archives have a growing need for VNA software that accommodates their imaging needs, which include both image sharing and providing business continuity. Although VNAs have served these needs so far, demand for improved interoperability is growing at a departmental level for image sharing.

Radiology and Cardiology are well ahead in this area, with PACS images increasingly migrating into VNAs. Dermatology images, endoscopy videos and sleep and gait analysis studies are touted as the next types of departmental image information suitable for migration.

To date, non-DICOM files (a standard for radiology images) — such as JPEGs, TIFFs, PDFs, MPEG videos and WAV audio — although falling within the VNA definition by IHS, have had little influence in the VNA market. However, with ever-increasing requirements for interoperable patient care within hospitals, the DICOM world is set to propagate beyond PACS, offering a wealth of new migration opportunities for VNA and healthcare information technology vendors.

Pathology, dermatology and ophthalmology departments are making significant attempts to follow in the footsteps of the PACS world. Changes at a departmental level in these areas to adopt VNA platforms will be a major factor for growth of study volumes in the VNA market.

The major challenges for image sharing between healthcare providers vary by region. In the United States for example, the prospect of a patient’s image being used and followed up on by another healthcare professional in another institution is unlikely, due to the inherent complexity of the US healthcare system and insurance providers.

On the other hand, Western Europe has an opposing view in that interoperable care will drastically improve clinical workflow efficiency, not only between departments, but also between healthcare providers.

Regional and even international sharing of healthcare image data is increasingly likely with wider VNA adoption. This is highlighted by the strong prediction for VNA study growth, with the five-year growth forecast at 990% for the EMEA region, 220% for the Americas and 1,960% the Asia Pacific region.

Context Management and Tag Morphing in the Real World

http://www.dejarnette.com/downloads/get.aspx?i=45048

Context Management and Tag Morphing in the Real World
Wayne T. DeJarnette, Ph.D. President, DeJarnette Research Systems, Inc. January 4, 2010

©DeJarnette Research Systems, Inc., 2013

A debate is currently raging in the medical imaging and DICOM connectivity worlds. This debate has been brought about by the recent interest in Vendor Neutral Archive products. The debate is over the need for what is referred to as “tag morphing” functionality when specifying an image archive. “Tag morphing” is the ability to retrieve an image or study from the archive in a fashion such that one or more of the DICOM elements (metadata fields) are created, deleted or manipulated to provide new value(s) for the DICOM element(s) so as to make the retrieving DICOM equipment function properly.

The History of “Tag Morphing”
The concept of “tag morphing” is more than 25 years old. It predates the existence of the DICOM standard. In the early days of digital medical imaging, it was not uncommon to want to acquire image data from modalities of different manufacturers and provide some useful processing capability for that data. Common early external applications included multi-planar reconstruction, radiation therapy planning, dental implant planning, etc.
In each application case, it was required that the image and demographic data be acquired in the modality’s native image format and converted to some “common format” for input to the processing application. Each vendor of add-on-equipment had their own “common format” for use by their application.
The ACR-NEMA1 V1 and V2 standards were an attempt by the ACR to standardize on an “image transfer format” and electronic transfer protocol so that interface development for these third-party applications would be lessened. While this standardization attempt improved the situation, it did not completely eliminate the need to understand each vendor’s modality “image transfer format”. Modality vendors made use of the ACR-NEMA standard, but, due to limitations and inconsistencies of the standard, programmer error and the desire for competitive advantage among the modality manufacturers, the “ACR-NEMA format” only succeeded in decreasing the magnitude of the problem. It was still necessary that users of these modality data sets account for variances in the implementation of the standard by the various modality manufacturers. The numbers and types of variances were large. This accounting for variances, converting from one vendor’s ACR-NEMA implementation to another vendor’s ACR-NEMA implementation was the beginning of what we today call “tag morphing”.

The release of the DICOM2 standard in September 1993 greatly improved the situation. Many of the limitations, inconsistencies and overly general specifications in the ACR-NEMA V2 standard were eliminated. There was wider vendor acceptance and commitment to the DICOM standard than there had been to the ACR-NEMA standard. All of this helped to further limit the amount of “tag morphing” required to effectively communicate between two equipment manufacturers’ equipment3. With the passage of 17 years since the standard’s release, DICOM implementations have become more consistent across manufacturers. The fact that there are now many more manufacturers making implementations has however compounded the communication problem.

The fact that more is being asked of the standard and its usage in ways never envisioned4 has redoubled the communication problem.

In a perfect world where there are only perfect DICOM implementations and vendors do not have a need to innovate and improve their products5, and where customers do not have new requirements, “tag morphing” would never be necessary for the effective communication of image data sets between systems of different manufacture. We, however, don’t live in such a world and as a result, “tag morphing” is still required in many cases.

21st Century Real World “Tag Morphing” Examples
The end user customer desire to share reading workload and/or patient image data between institutions and facilities with PACS products of different manufacture creates a requirement for “tag morphing”. A few easily understood examples appear below6:

• The Patient ID DICOM element needs to be changed when using one facility’s data at another facility. Without the facility’s correct Patient ID for an existing patient, the ingested image set will not be properly associated to the patient record. In some PACS, it is possible the ingested study will be held in QC until a manual “match” is done.
  
• The Study Description DICOM element may need to be changed so that the study hangs correctly on the PACS workstation of the ingesting institution.
  
• The Accession Number DICOM element may need to be changed to match the format of the ingesting institution’s standard format. Many institutions have coding built into the accession number, so an accession number must be formed to match the institution’s coding and then placed into the DICOM object so correct routing can take place.
  
• Private DICOM elements must be either removed or inserted for those PACS systems that can not handle the private elements or need specific private elements to be able to manage the data set correctly.
  
• The Institution Name DICOM element and the Department Name DICOM element may need to be manipulated when multiple facilities are using a single PACS/VNA7. When pre-fetching studies from the VNA, the PACS will not know which facility to send the study to unless the VNA indicates which destination the pre-fetched study is to be sent.
  

Even after 17 years of DICOM experience throughout the industry, programmers still make mistakes resulting in an incorrect implementation of the standard8. A few examples follow:

• Image level DICOM elements such as Image Laterality, Photometric Interpretation, etc. may need to be manipulated to be properly displayed on a new third-party workstation or PACS. This is a frequently observed problem when migrating legacy PACS data.
  
• Some PACS workstations misinterpret graphic overlay data generated by other systems, making the proper display of the graphic overlay impossible without the manipulation of the data prior to being displayed.
  
• At least one PACS vendor requires that the DICOM element Requested Procedure Description be populated by the modalities with known enumerated values, consistent with a list configured into the PACS, in order to accept the study and display it. Most modalities today have the ability to include this optional DICOM element in their DICOM data sets. A problem occurs when ingesting studies from outside the institution where the Requested Procedure Description element may not be provided or is provided but does not correspond to one of the values in the PACS enumerated list. This DICOM element was never intended to be used in this fashion. “Tag morphing” is the tried and true solution to this problem.
  
• CT images archived by at least one PACS vendor cannot be displayed properly by any other PACS or workstation vendor without changing the Pixel Representation DICOM element in all CT images coming from the PACS.
  Modality and PACS vendors continue to innovate with their products. This will sometimes result in the need to make use of private DICOM elements as no standard element has been defined for the innovated application. If the modality and PACS vendor are the same, there is generally no problem. When the PACS is replaced, frequently it will be observed that functionality pertaining to the modality is lost. Often, DICOM data manipulation can correct the problem.
  Similarly, innovation sometimes leads a manufacturer to make use of a standard DICOM element in an improper fashion8. An example:
  

• A particular modality / PACS vendor in an older revision of software assumed that the DICOM elements, Partial View and Partial View Description in the Digital Mammography IOD could be used as enumerated fields to provide for use in display station hanging protocols. The standard clearly defined these fields as free form text, not enumerated text. As a result, the PACS could properly display mammography studies produced by their Digital Mammography product, but would improperly display the mammography images produced by other Digital Mammography modality manufacturers. A software “tag morphing” solution solved this problem until the DICOM standard caught up9.

As can be seen, there are a number of ways to get into a situation where image data sets which are sufficient for usage by a particular product (PACS or workstation) are much less useful, or in some cases useless, to another DICOM conformant system without some type of “tag morphing” or DICOM header manipulation taking place between the two systems. The more complex the system under consideration, the more likely it is that this data manipulation capability will be required.

“Tag Morphing” is Insufficient – The Need for Context Management
In common usage, “tag morphing” refers only to the manipulation of DICOM elements in a DICOM object. This manipulation can include changing an element’s value, deleting the element altogether or inserting an element which had not previously been included in the DICOM object.

For modality to workstation or modality to PACS communication, “tag morphing” is sufficient to address issues of clinical utility. This is not the case when the communicating systems are larger, such as PACS to disparate PACS for data sharing, or shared archive to multiple disparate PACS, etc. To effectively correct for differences in the clinical utility of a particular data set, you must be able to manage the entire workflow context. This includes having the ability to manipulate DICOM data sets and the ability to manipulate and communicate data passing between the various information systems, such as RIS, PACS, digital dictation, HIS, etc. This requires HL7 communication and HL7 “tag morphing” capability.

A simple example will illustrate this point. Most PACS deployed today will either not accept or will provide highly limited workflow for an image study received for which there is not a pre-existing RIS order (generally provided by means of HL7 communication). Assume that a Vendor Neutral Archive is used to share image data between a number of disparate PACS at a number of different institutions. Assume that an image data set stored by PACS A is to be reviewed by PACS B at a different institution. In order for PACS B to make maximal use of the image data set stored by PACS A, PACS B should receive a RIS order associated with the data set stored by PACS A prior to receipt of the image data set. This can be accomplished by the Vendor Neutral Archive “preparing” PACS B for receipt of the image data set by sending it the appropriate order and report (if PACS B is not doing the primary read). This, of course, requires that the Vendor Neutral Archive sees all of the communication between each PACS and RIS so that it is synchronized and can act as a synchronizing agent.
In the above example, the Vendor Neutral Archive must appropriately manipulate the stored DICOM image data set and provide the appropriate order and patient information to PACS (and perhaps local RIS as well). This is an example of required Context Management capability for a Vendor Neutral Archive. DICOM element manipulation is only a piece of this broader solution.

Conclusion
Whether one needs “tag morphing” or Context Management capability depends on the problem you are trying to solve. If the problem is simply to store DICOM image data from a PACS or modality, and you don’t care about the ability in the future to have these data sets be usable, without migration, by a PACS of a different manufacturer, then you have no need of either “tag morphing” or Context Management in your DICOM archive.
If, however, you want to minimize the need for archive data migration and maximize the usability of the data you are storing in the DICOM archive, then “tag morphing” is required. If you intend to share data between disparate PACS then Context Management (which includes “tag morphing”) is required of the archive. These features are the primary distinction between a DICOM archive and a true Vendor Neutral Archive10.

1 The ACR-NEMA standard is the forerunner of today’s DICOM standard. The DICOM data transfer format is an extension of the ACR-NEMA data transfer format. The ACR-NEMA V3 standard was renamed DICOM so as to gain support for the standard outside of the U.S.2 A historical perspective of the making of the DICOM standard appeared in the article, DICOM – The Making of a Standard, published in Advance for Administrators in Radiology and Radiation Oncology in November, 1998. A copy of this article can be found at www.vendorneutralarchive.com in the White Papers section of the web site.3 In the 7 year period immediately after the publication of the 1993 DICOM standard, “tag-morphing” to facilitate the interconnection of various pieces of DICOM conformant equipment was still very common. The strangest example, a major modality / PACS manufacturer as late as 2000 required a third party protocol converting gateway (another name for a DICOM “tag-morphing” engine) in order to connect DICOM conformant MR systems they manufactured to the DICOM conformant PACS they also manufactured.

4 Today DICOM communication between PACS of different manufacture has replaced modality – PACS communication as the most challenging usage of the standard.5 Innovative new equipment usage frequently results in vendors defining and making use of proprietary, private DICOM elements.
6 The described “tag-morphing” requirements have been found while deploying Vendor Neutral Archive and inter-PACS image data routing applications.7 VNA – Vendor Neutral Archive

8 The author’s company, DeJarnette Research Systems, Inc. is the market and technology leader in legacy PACS data migration. The company has performed more than 250 migrations between more that 40 different vendor’s PACS products. The described problems are frequently observed in legacy PACS data migrations.
9 This situation ultimately led to additional DICOM elements being added to the DICOM Digital Mammography IOD, some years later.
10 A Vendor Neutral Archive is more fully defined in the White Paper, What is a Vendor Neutral Archive? A copy of this paper can be found in the White Papers section at www.vendorneutralarchive.com.

About Dejarnette Research Systems: First in Innovation.

http://www.dejarnette.com/about-us/company-history/default.aspx

From its inception, DeJarnette Research Systems, Inc. has been known for technical innovation. For many years, the company has been among the industry leaders in driving standards, such as ACR-NEMA V2, DICOM (ACR-NEMA's successor), and HL7. DeJarnette Research Systems designed, developed, and manufactured the highest performance, most robust, and most widely used ACR-NEMA V2 interface board (AT/ANSIF) and ACR-NEMA V2 Medical Network Gateway (ImageShare 910).

The company also was the first to bring to market a Film Digitizer acquisition station which supported DICOM Storage & DICOM Worklist Management (ImageShare 910/FD). The company's SureNet assured delivery, "store and forward" with route failover capability, set the standard for early Medical Network Gateway products. These products led the U.S. Military and Loral/Siemens to select DeJarnette ImageShare 910 products as their preferred modality interfaces for MDIS deployment.

DeJarnette’s AN/API (ACR-NEMA Application Programmers Interface) was the first medical imaging software toolkit to support DICOM. With the advent and deployment of DICOM, the company began to focus on application of this technology, realizing that a toolkit is not a solution, only a tool. In recent years the company's focus has been on best in class medical imaging applications. The company's ImageShare 2000/CR was the first Fuji CR interface to support DICOM Storage, DICOM Worklist Management and Siemens PACSnet protocols. This workstation included these capabilities along with quality control workstation functionality. The company's second generation ImageShare CR product took the industry by storm. This QC station includes the most highly developed network interface capabilities every, a "best in show" QC application along with heretofore unheard of performance. With a single box solution, this product replaced the functionality of what had required three boxes.

These are just a few of the innovations which have come out of DeJarnette Research Systems over the last decade. We have numerous other best in class applications nearing deployment and/or under development. As we move into our third decade, we will use this page to keep our customers informed about these innovations.

DeJarnette Research Systems leads the market in the legacy PACS migration business with its PACSware® Migration Gateway Toolkit. With the growing demand for enterprises to access older studies that reside on non-DICOM archive systems, the company applied its expertise in data conversion to the development of the Migration Gateway Toolkit. To date, the company has been contracted to migrate more than 35 million studies with this product.

The company’s dyseCT™ CT workflow engine has been in the market for nearly five years and continues to be the only automated solution for splitting whole body CT studies into separate studies based on the RIS order.

DeJarnette Research System’s latest product innovation, xDL™ Cross Enterprise Document Librarian software, operates in conjunction with a database server to provide DICOM storage and query/retrieve services. Available in two configurations - standard, single gateway configuration as well as a high availability cluster configuration - xDL serves as a standards-based image management gateway to both off-site storage and an enterprise-wide or cross-enterprise regional archive.

With its extensive product offerings, DeJarnette Research Systems is dedicated to increasing the efficiency of image management workflow for all types of health care institutions. Its commitment to breakthrough, best in class applications remains the standard by which additional company products are being developed and deployed in the near future.

What is a Vendor Neutral Archive?

http://dejarnette.com

Over the past few years there has been tremendous buzz in the industry about what constituents a “Vendor Neutral Archive”, sometimes referred to as a VNA. There are a number of industry consultants touting the virtues of these devices. Salesmen are actively trying to sell them. However as I talk to people in the industry, both end users and vendors, I find a great deal of confusion. I have heard time and again, “oh, you mean a DICOM archive?”, or “yeah, we are talking to our PACS vendor about a “Super-PACS”, or “yes, we have one.” I will attempt to bring some clarity to the issue of what is and is not a Vendor Neutral Archive.

Some of the issues which point towards the need for vendor neutrality
There are all types of vendor neutrality. In this instance the neutrality of concern is a neutrality that assures freedom from vendor imposed limits on how, when, where and what a healthcare enterprise does with its electronically stored images and documents. A common complaint among owners of PACS is that they do not feel they own their images and associated data. Anything they choose to do generally has a dollar cost associated with it and they must involve their PACS vendor. The PACS vendor is not always cooperative. There is a feeling of being held hostage and helpless. A PACS owner will often see as their only solution, changing PACS vendors when it comes time to replace their existing system. It is “pay-back time”. From this reality the concept of Vendor Neutral Archive was born.

A recently hired hospital CIO who came from the banking industry, when learning of his radiology director’s needs and issues commented on the craziness of this system. How “nothing talks to anything else”. How it is impossible for his IS people to effectively manage his institution’s imaging storage infrastructure, the way they were able with billing, patient records, employment records, etc. It is also from this reality the concept of Vendor Neutral Archive was born.

The problem with all of our PACS today is a fundamental architecture and business platform issue. A PACS has a number of logical components; a HIS/RIS interface engine, a workflow engine and database, modality gateway components, a storage system and a viewing system. All of these components are generally supplied by a single vendor. In order to lock a purchaser into a particular vendor’s products, all too frequently industry standards are only used by a vendor for getting images and order information into their PACS. All interest is lost in these standards once the image and order data has been acquired. A PACS purchaser may find it very difficult, expensive or in some cases impossible to add new functionality to their PACS. Desirable features all too frequently must wait until the purchase of the next PACS. Frequently it is the lack of extensibility in the current PACS that causes a PACS owner to purchase a new system before the current system has reached the end of its useful life. It is also from this reality the concept of Vendor Neutral Archive was born.
The characteristics required of a medical image “Vendor Neutral Archive”
A medical image archive, to be useful, in its most fundamental form consists of three components; 1) a storage sub-system, 2) an interface to the medical imaging application world which allows for the storage and retrieval of images and associated documents in a “clinically useful fashion”, and 3) a database that manages and remembers where, what, when, how and who stored images and associated documents into the storage sub-system. The phrase “clinically useful fashion” is significant. It is this characteristic that makes this particular set of components a medical image archive and distinguishes it from archives of employee files, financial data, etc. It is this characteristic that presents the greatest challenge to IT specialists in dealing with and managing medical imaging data.

When supplied as part of a PACS, the medical image archive or storage system database is traditionally a shared resource. It is frequently shared with the workflow engine, the HIS/RIS interface engine, a reporting engine if part of the PACS offering, and other sub-systems which need to remember and recall highly structured data. While this makes good engineering sense and was at one time a requirement in order to keep the cost of a PACS down, this architectural decision is the cause of many of the industry’s interoperability problems and the cost savings today from using a single database for all of these purposes is minimal.

The above characteristics are those of a medical image archive. In order to be vendor neutral, there are other requirements to meet. There are two types of vendor neutrality which are paramount; 1) the ability to function with no noticeable differences1 between similar storage products of different manufacture, and 2) the ability to function with no noticeable differences between similar imaging applications, ie, PACS vendor neutrality. It is this second requirement that provides the greatest benefit to the end user customer and provides the greatest challenge to vendors attempting to provide a true Vendor Neutral Archive product.

By now the reader should be getting a good “feel” for what a Vendor Neutral Archive is and the characteristics it must have. It should be noted that when discussing what a VNA is, this must be done in the context of the domain in which the archive is to operate. This paper only considers the question of vendor neutrality in the domains of radiology and cardiology. These domains may span a single medical treatment facility, a larger, multi-site enterprise or a region with many independent enterprises.
A Vendor Neutral Archive meets the following requirements:

• It must interface with other clinical systems and disparate PACS for the purpose of communicating imaging data, by means of DICOM;
  
• It must interface with other clinical information systems for communication of reports, results, workflow, etc., by means of HL7;
  
• It must have the ability to store the complete suite of DICOM SOP classes including presentation states and key image notes;
  
• It must store all objects in a non-proprietary format understood by the community at large, ie., DICOM part 102;
  
• It must support the most inclusive DICOM query/retrieve specification as a service provider for the information stored in the archive at all information levels;
  
• It must provide context management, i.e., the ability to manipulate DICOM tags so as to convert the DICOM implementation and demographic needs of one PACS vendor (or imaging application) to the DICOM expectations of another PACS vendor (or imaging application) with no significant impact on the customers daily operation3. Context management includes the ability to prepare a PACS through HL7 for ingestion of images from another, disparate PACS;
  
• It must handle ADT updates to the image files stored in the 
  It must support a wide variety of storage infrastructure solutions so as to facilitate storage hardware upgrades and replacement with little impact on the clinical enterprise;

• It must include a separate, independent, commercially available database product which supports SQL, so as to allow for easy integration into an IT department’s every day management operation4,5;
  
• It must ingest any type of electronic document through the use of an API and categorize that information with the lowest level association that can be made within the archive;
  These are the minimum requirements. Any product which does not meet all of these requirements, while it may be useful, is not vendor neutral and will not provide the benefits of a “Vendor Neutral Archive”. The vendor neutrality of this device spans PACS vendors, storage vendors, offsite storage providers and Vendor Neutral Archive software providers6.
  Some industry consultants and academics would include other requirements/characteristics. While these requirements/characteristics may be useful to the end user customer, they are at best irrelevant to vendor neutrality, and at worst antithetical to the concept of vendor neutrality7. Following is a list of useful features in an archive product (there are certainly others) which are consistent with and in no way interfere with the vendor neutrality of such a device.
  
  • Support for various IHE profiles (detailed later);
    
  • Support for high-availability hardware and software platforms so that the archive
    continues to operate when there is a single failure of a disk, server or network interface;
    
  • Highly scalable so that the enterprise archive can grow with the needs of the clinical enterprise;
    
  • Support for image compression in a non-proprietary, industry standard fashion;
    
  • Support for multiple departments: radiology, cardiology and any other departments with
    digital images requiring storage, not necessarily DICOM8;
    
  • Support for automatic pre-fetch of prior studies triggered by HL7 order messages that includes context management;
    
    

• Support for auto-routing of images and other documents that includes DICOM context management;
  
• Support intelligent management of the information within the enterprise archive independent of the clinical systems interfacing with the archive (CLIM – clinical life cycle information management);
  
• Simultaneous support for both onsite and offsite data storage; and
  
• Visualization tools that can interface with the enterprise’s EMR solution to provide access to the images within the archive outside of the clinical PACS9. It is imperative that these tools be based upon acquiring and interacting with the VNA through industry standard protocols. WADO (Web Access for DICOM Objects) is such an industry standard protocol.
  
  The benefits of a Vendor Neutral Archive
  
  There are numerous benefits provided by a Vendor Neutral Archive:
  
  • switching PACS systems without requiring a complex image/data migration;
    
  • making use of the latest storage hardware technology without requiring a complex
    image/data migration;
    
  • maximizing ROI on legacy PACS and imaging applications;
    
  • easily bringing online new imaging applications not supplied by your PACS vendor;
    
  • synchronizing the demographic data associated with your image data and your
    HIS/RIS10;
    
  • sharing common IT managed storage with other applications; and
    
  • effectively controlling your image data.
    There are other benefits depending on the additional features your VNA software provider supplies. For instance automated deletion of old unneeded data through CLIM; the ability to easily share image and report data; the ability to provide patients and referring physicians with access to their images over the Internet; etc.
    Alphabet soup may be harmful to your health (care practice)
    It should be noted that it is possible to build a Vendor Neutral Archive without supporting any of the IHE profiles. Today, IHE conformance adds little to the useful functionality of a VNA in a single radiology or cardiology department as the PACS themselves do not generally support IHE. This however changes as you attempt to provide a VNA that interfaces outside of a single department to provide for enterprise data sharing. This will also change in the future in the departments themselves as more PACS conform to IHE. Today, a prospective purchaser of a VNA should take with a grain of salt any sales pitch that includes addressing significant departmental issues through IHE conformance.
    This is not to say that IHE should not be part of a go forward strategy. It should be! Data sharing outside of the individual department and certainly across an enterprise will in future depend upon equipment which supports the IHE model. IHE will certainly be part of the solution in providing national electronic health records. This is already seen to be the case outside of the US where the western democracies are ahead of the US in deploying such solutions.

The following IHE profiles are thought to be most useful in the context of a VNA:

• Radiology’s Scheduled Workflow (SWF) integration profile;
  
• Radiology’s Patient Information Reconciliation (PIR) integration profile;
  
• IT’s PIX and PDQ integration profiles;
  
• IT’s Consistent Time (CT) integration profile;
  
• IT’s Audit Trail and Node Authentication (ATNA) integration profile;
  
• IT’s Enterprise User Authentication (EUA) integration profile;
  How is a “Vendor Neutral Archive” different from a DICOM Archive?
  A DICOM archive is not the same as a VNA. A DICOM archive supports only a subset of the functionality that a VNA does. DICOM archives have existed for more than 15 years. Some PACS vendors make use of a DICOM archive as their primary image storage cache. These products however have not solved the problems associated with replacing a legacy PACS without requiring a complex image migration. These products have not made the majority of PACS owners feel as if they own their image data. In very few cases have these products represented an investment that was useful beyond the life of the PACS that it was provided with.
  The single biggest difference between a DICOM archive and a VNA is the VNA’s ability to perform context management. This is the ability of the VNA to manipulate its stored data to provide a presentation of that data which is different from the presentation with which it was originally stored. We have all encountered the problem that one imaging vendor or PACS vendor’s DICOM is not always useable by another vendor’s products. Suppliers of legacy PACS migration software and services have to deal with this problem daily. Different PACS products use the non-image DICOM tags differently. A particular tag (DICOM element) that is missing may be acceptable to vendor A, but cause vendor B’s product to choke, and vendor C’s product to not display images correctly. This is the big problem that DICOM archives do not address and VNA’s do.
  Another significant difference is that a DICOM Archive does not interface to a HIS or RIS, while a VNA does. This allows the VNA to keep demographic and other non-image data synchronized between the stored image file and the HIS or RIS. The great majority of PACS in fact, whether they make use of a DICOM archive or not, do not provide this ability.
  Finally, a DICOM archive is just that. It stores DICOM objects. A Vendor Neutral Archive can store objects of other types, such as non-DICOM image files from other “ologies”, scanned documents, PDF files, etc. and provide a means for indexing them and associating them with other DICOM and non-DICOM objects.
  How is a “Vendor Neutral Archive” different from a Super-PACS?
  Super-PACS or Mega-PACS are a traditional PACS product offering which has been scaled to function across a larger enterprise. The net result of this type of architecture is that it accomplishes data sharing across an enterprise so long as the enterprise is populated totally by PACS of that single vendor. A Super-PACS solution does nothing to address vendor neutrality of storage. It is in fact antithetical to the entire concept of vendor neutrality. A Super-PACS has all the same problems that a traditional PACS does when it comes time to replace the product with a new PACS. The only difference is that the magnitude of the problem is much greater. The PACS owner remains locked into a particular vendor and will have to spend significant monies in order to move away from that vendor.
  

Vendor neutrality must drive next-generation system architecture!
It is difficult to imagine how a PACS vendor today can provide a VNA. Most of today’s PACS architectures suffer from the flaw of a shared storage and workflow management database. These systems also generally provide for advanced functionality of the vendor’s viewing components through database usage. The intertwining of these components through the database makes such systems a bad place to start in developing a VNA.
Vendor neutrality demands the usage of widely accepted standards at all component interfaces. Few if any PACS vendors today worry about these standards inside of their own PACS products. In future, true vendor neutrality will require a new PACS architecture, shared by all PACS and PACS component vendors. This architecture will of necessity split out the archive, if not the entire storage subsystem. The other major PACS components, workflow management and applications (including all viewing) do not have to be split out in order to assure that a customer maintain effective control over their imaging data. However splitting these components out of PACS is possible and desirable from the perspective of the customer. This breakup of PACS into these components would allow vendors to concentrate on their core competencies, increase competition and ultimately reduce prices. In such an environment it would be possible for non- medical imaging vendors with experience and generic products, such as workflow management products/vendors, to participate more easily in the PACS market, bringing a deeper domain experience and commitment to the market.
The DICOM and IHE standardization efforts have been driving towards vendor neutrality for 15+ years. At this point in time there is a high level of acceptance, adoption and experience with these standards. At this time, hospital and imaging center CIOs are beginning to demand solutions that allow them to effectively manage radiology and cardiology data in a shared storage environment. Computer and storage technology have reached a point where the addition of standard interfaces to provide for component neutrality does not result in significant application performance degradation. The confluence of these realities makes next-generation PACS architecture possible. One in which vendor neutrality is assured.

If you have any additional questions about Vendor Neutral Archive implementation, contact sales@dejarnette.com