Difference between revisions of "VNA Study Management - Proposal"

From IHE Wiki
Jump to navigation Jump to search
(Created page with "__NOTOC__ ==1. Proposed Workitem: ''<initial working name for profile/whitepaper/etc>''== * Proposal Editor: Kinson Ho * Editor: Kinson Ho * Date: N/A (Wiki keeps history)...")
 
Line 22: Line 22:
 
* If there is a viewer attached to the VNA, which key attribute should be displayed? How can it present the other equivalent values?
 
* If there is a viewer attached to the VNA, which key attribute should be displayed? How can it present the other equivalent values?
 
* More generally speaking, should the VNA consider the multiple copies of the same study as independent?
 
* More generally speaking, should the VNA consider the multiple copies of the same study as independent?
 +
* If XDS-I.b is involved, should each copy of the study be a separate manifest, or should they be all considered a single manifest?
  
 
The value of this profile is to strengthen the operational interoperability of a VNA.
 
The value of this profile is to strengthen the operational interoperability of a VNA.

Revision as of 13:46, 25 August 2014


1. Proposed Workitem: <initial working name for profile/whitepaper/etc>

  • Proposal Editor: Kinson Ho
  • Editor: Kinson Ho
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

2. The Problem

With the increasing interest and adoption of Vendor Neutral Archive (VNA) archicture, it is not unusual that the VNA / Centralized Archive receives the same study multiple times. These studies can be sent from different sites, each receive a copy of the same study (via CD Import, network transfer, retrieve from VNA, etc.). Each copy of the study may have different key attributes due to coercion to local values (e.g. patient ID, accession number, etc.)

This imposes several problems to a successful deployment of a VNA:

  • How can the VNA recognize that these different key attributes are equivalent, not data corruption or old/stale values from an old copy?
  • Should the VNA be able to maintain these different key attributes such that when it returns the study back to the same originating site, it can return the right value?
  • What if a 3rd site request the study? What values should the VNA return?
  • If there is a change request sent from Site A to the VNA (e.g. following IOCM), should the VNA reflect the same change to the study sent from Site B?
  • If there is a viewer attached to the VNA, which key attribute should be displayed? How can it present the other equivalent values?
  • More generally speaking, should the VNA consider the multiple copies of the same study as independent?
  • If XDS-I.b is involved, should each copy of the study be a separate manifest, or should they be all considered a single manifest?

The value of this profile is to strengthen the operational interoperability of a VNA.

3. Key Use Case

The common scenario is as follow:

  • Site A acquires a study (Study A)
  • Site A shares the study with Site B
  • When Site B receives the study, it reconciles the study to local patient and order information but retain the same UIDs, including the Study Instance UID. This is according to IRWF profile. Site B now has a slightly different version of Study A, let's called it Study A'.
  • Site A and B eventually both archive the study to the shared centralized VNA
  • When the VNA receives the studies, when it received the second copy, it detects that the same object has already been received but the new copy has different key identifiers (e.g. Patient ID, accession number, etc.)


4. Standards and Systems

Existing systems: Image Manager/Image Archive, Change Requester, Image Display, Evidence Creator, Imaging Document Source/Consumer

Existing standards: SWF, IOCM, IRWF, XDS-I, DICOM

5. Discussion