Both our VNA and PACS will get ADT updates, ORM and ORU messages indendently. So the only issue is Image related changes made by PACS admin on PACS. We need a way for those changes to flow into the VNA. Any suggestions?
posted on Thursday, May 07, 2015 - 08:24 am
And changes made to RIS, in particular patient merges. This happens where a patient record exist on RIS but not PAS. For example where only the most recent clean data is migrated from the old PAS to a new EPR
Each system will always require a level of manual administration to fix synchronisation issues. Shaun
There is an overlap between the services provided by PACS and VNA.
There was a time when PACS was viewed as an enterprise solution – but I think PACS vendors missed the boat a little by; • Failing to fully embrace open systems within their architectures and limiting the future usability of data in their systems (this was the main reason for the birth of Vendor NEUTRAL archives – right?) • Not providing tools to use and visualise data in meaningful ways beyond radiology. A web image viewer is not a tool to help you see complex records and interrelations of data • Failing to capture and successfully manage non-radiology images
This is why a market demand that could be fulfilled by a similar product was created.
Now we see a day-to-day tussle over the boundary between PACS and VNA.
To answer the question ‘when to forward from PACS to VNA’ I have two answers. Answer 1: we have to be realistic – IOCM is in its infancy – not every system is able to implement it. So a practical solution is to leave the storage of the data in the VNA until the exam and results are complete – minimising the chance of changes being required. You should also take into account the customer view; if the VNA is viewed as your long term repository, then this method also makes sense. If, however, you want to view your VNA as a communication hub and a mass distribution tool, moving the Communications System CS from your PACS to the VNA – why not say VNACS? ;) then you come to answer 2 .. Answer 2: In future times I am sure we will see wider robust adoption of ICOM, and this introduces the possibility to make you VNA a reliable VNACS – in line with Neelam’s message.
posted on Thursday, May 07, 2015 - 09:07 am
Re IOCM: the principle is quite simple: 1) send a message to all subservient systems with an instruction to delete ALL copies of erroneous data; 2) send corrected replacements.
The practical implementation is far more complex for the source of the data.
......And if the modality is the source, it will need the ability to correct the data and issue the IOCM.
Robin, I agree with what you say. The birth of VNA has been a blessing though. XDS Registry and Repository is now enshrined in it
Thanks Shaun. This is very helpful. "Re IOCM: the principle is quite simple: 1) send a message to all subservient systems with an instruction to delete ALL copies of erroneous data; 2) send corrected replacements."
So we would need a master and a slave. We would decide PACS is the master, as any changes made on PACS and flow into VNA. However, what about updating XDS registry and repository as VNA is the XDS-I source.
Despite the cautious advice from Herman and Robin, I do think dual send from modalities is the right way to go for a "clinically useful" Enterprise Archive.
We would expect our Fujifilm PACS to be the "Change Requester" actor (as this is where the changes will be made by PACS admin) Perceptive VNA as the XDS source would act as the "Change Importer/Exporter" XDS Consumer (Fujifilm) will act as the "Change Consumer"
When I have looked at the connectathon results for IHE connectathon for IOCM. There are 4 actors 1. Change Requester--for us this is the PACS --as changes on the images are made on the PACS by the PACS admin 2. ImageManager-I presume this will be the VNA--as it will recieve and act on the changes made on PACs. (although the PACS also is a ImageManager in the true sense) 3. Image display: this will be the XDS consumer--which will query the VNA for image display. 4. Document source: will this be the PACS (in our situation) as the PACS is supplying images to the VNA? (although the VNA is actually the XDS-I source in our architecture.)
Have I got this correct? Any help from the experts would be appreciated.
There are 4 actors in IOCM profile. 1. Change Requester--for us this is the PACS --as changes on the images are made on the PACS by the PACS admin. 2. ImageManager-For the purpose of IOCM profile this will be the VNA--as it will receive and act on the changes made on PACs it and update itself. 3. Image display: this will be the XDS consumer--which will query the VNA (XDS registry/repository) for image display. 4. Document source: This refers to XDS document source (for us this is the VNA acting as XDS-I document source)
So going back to Chris's view about direct Modality Connection to VNA, I do think it should be very much possible, provided the VNA, is able to support a. HL7 ADT, ORM and ORU messages from PAS and RIS--to update the information recieved from modalities correctly b. Supports IOCM profile as Image Manager and XDS Document Source actors for IOCM Profile (and PACS Supports the Change Requester Actor)--Afga, Fujifilm, Rogan Delft etc support IOCM Profile as per IHE connectathon resullts.
Herman: IOCM is in the TFv13 with the CR, IM and ID actors.
Neelam: IOCM suggests that the Change Requester actor can be implemented in a different system than the PACS. The reasoning is that the CR needs to recreate the changed instances completely, including UIDs, and ideally also UID's in private fields. This requires knowledge about the structure of the images that may not be available in the PACS, but is available at the Modality. In that case the PACS is really acting as the IM in the IOCM model. But if the PACS is also the CR, it has the responsibility to create the new instances and send them to the VNA. The VNA must then (in your architecture) create a new KOSD for the study, incorporating the UID's of the changed instances and omitting the ones that were passed in the IOCM message. The XDS Consumer can therefore remain blissfully unaware of all the IOCM activities.
Thanks so much Pim for your help in this. Much, much appreciated
I do understand what you say. However, in our local workflow all the image related changes are made on PACS by PACS admin. The only reason quoted for not having a direct modality connection, was that changes would be made on the images on PACS-and these changes would not be on the VNA.
However, I feel comfortable that provided the PACS and VNA support IOCM, a. PACS as Change Requester b. VNA as Image Manager c. VNA as XDS document Source we can easily move to a direct modality connection to the VNA--as described by Chris.
And just to come back on the IOCM point, I agree totally with Pim's post. If the PACS and the VNA are using IOCM properly, the Image Display Actor / XDS-I consumer doesn't need to be aware of the IOCM activities.
A PACS acting as a Change Requester will send the VNA a list of instances/images to be deprecated within a DICOM Key Object Selection (KOS) document.
A PACS which conforms as a Change Requester actor will also send Replacement Instances (with completely new Study, Series and SOP Instance UIDs) to the Image Archive, which will store them.
Both transactions are often needed together. Consider a scenario where the wrong patient is selected on a modality worklist but the mistake is not detected till after the study has been archived to VNA.
Correction involves moving the image from the 'wrong' Study A to a 'correct' Study B on PACS, but with communication of this change to the VNA as well. The corresponding transactions are
a. PACS (Change requester) tells VNA (Image Archive) to deprecate the images in Study A by sending a KOS document with the deleted image. b. PACS (Change Requester) publishes Replacement Instances to the VNA (Image Archive) for the new image to be added to Study B.
And there is one other specific scenario which I don't think has been mentioned in posts so far. The flow can be reversed : VNA can be the Change Requester and PACS the Image Archive.
This happens where a VNA is the long-term archive with information lifecycle capability and the PACS has "store and remember" functionality which requires it to maintain a list of Study UIDs sent to VNA.
In this case, when a study meets purging criteria, the VNA deletes it.
Then the VNA acts a Change Requester to send a KOS object to the PACS, informing the PACS that the study no longer exists. The KOS document contains a specific title "Data Retention Policy Expired"
For the PACS-VNA correction and VNA-PACS retention policy deletion exchanges to be supported, both the PACS and VNA need to support the IOCM profile with both actors : Change Requester AND Image Archive.
I spoke on PACS-VNA change management at the RCR Autumn Meeting in 2013. The presentation is attached below. Pages 21-29 of the PDF hopefully give a nice, pictorial view of what I've discussed above for those who are interested.
Thanks Graham. Your post and presentation is very very good indeed. Thanks for your input.
IOCM has become much clearer to me now. We need PACS and VNA to be in sync. IOCM is critical. a. Any changes/corrections to the images made on PACS by PACS admin (adding any extra images by radiologists) would automatically update VNA due to IOCM (PACS acting as Change Requester and VNA acting as image manager) b. However for lifecycle management--deletion of images will happen in VNA --so VNA will act as Change Requester and PACS as the image manager You summarise it well "For the PACS-VNA correction and VNA-PACS retention policy deletion exchanges to be supported, both the PACS and VNA need to support the IOCM profile with both actors : Change Requester AND Image Archive. "
This is the architecture I think we should go for at Doncaster:. 1. All Modalities are connected to PACS 2. PACS will send images to VNA directly with updated DICOM tags (from HL7 ORM messages from RIS to PACS)--INSTANTLY--so VNA archive is up-to-date at any time (and does not lag behind PACS) 3. VNA will act as XDS-I source and send registry and repository entry 4. VNA receives HL7 ADT updates--A08 and A40 messages to ensure the patient demographics are up-to-date 5. Any Changes made on images on PACS would flow automatically to VNA (no extra manual intervention required in VNA by PACS admin)--via IOCM profile 6. When changes are made on PACS and replacement images are sent to VNA--VNA will send an updated XDS Registry and Repository entry--via IOCM profile
Graham, Do you think this above architecture will work?
Graham, My biggest concern at this moment --is a XDS source for non-radiology content. We really need a "Print-to-XDS" functionality from devices like audiograms and other documents creaters--clinic letters, histopathology reports, blood results, visible light etc. Good workflow is critical for adoption by Enterprises. Any advice?
Regarding Connectathon Results, Vendors send prototypes, pre-release SW and Production SW to Connectathon. How do you know what is what? Vendors self certify by publishing IHE Integration statements. Vendors subject to independent testing labs for attestation of the certification. A pilot was done at this year's connectathon. Even if you use these tools, this does not preclude the necessity of writing good acceptance requirements which may further constrain the expectations of the products you wish to integrate.
We would not simply rely on connectathon results. We would do formal acceptance testing as part of the contractual agreement.
A. Study related changes made on PACS a. add images to a study b. delete images from a study c. Side markers added on the image d. image rotation etc (any other image correction task carried out by PACS admin) We will see if the images in the VNA have be corrected or not
B. We will also see if the images culled in VNA are automatically deleted in PACS or not.
C. We will also check to see if the XDS consumer calls up the corrected set of images from the VNA
Is there anything else we need to test, Robin?
posted on Monday, May 25, 2015 - 04:05 pm
When you bought you VNA and PACS in 2013 what were the results of A, B & C in your acceptance testing?
As you do not have IOCM how have you kept your live systems synchronised in the last two years so that they are clinically safe? Do you have to manually fix things in two places??
We did not feel it was acceptable for PACS admin to manually correct in PACS and then in VNA. Hence in the "interim" our PACS is being mirrored, to a provide a back-up and provide disaster recovery. IOCM is critical for us.
VNA database and archive will be tested for a. IOCM for image related changes sync with PACS b. ADT updates from PAS c. XDS registry and repository d. Life cycle management tested and signed off.
Once we have tested and signed off we will remove PACS mirrored back-up--- as VNA will act as the back up, disaster recovery, XDS registry repository, life cycle management. Hope to be completed by end of 2015.