posted on Saturday, February 18, 2017 - 08:34 am
Finland is working on a national IHE XDS-I infrastructure for the exchange of images and reports. The regions have LocalPACS systems (for intermediate terms storage, 6mo), and a central VNA. Anything stored on the VNA is automatically registered on the XDS registry.
They plan to use IOCM between the Local PACS systems and the VNA. Thus raises some interesting issues when it comes to XDS: what if the PACS system deletes an entire study (for reasons other than retention), this would lead to the necessity to delete the KOS manifest and the metadata from XDS. That sounds like a combination of IOCM and MUP, in terms of IHE profiles.
IOCM also would have to be used from the VNA to the PACS, in case third parties make changes to a study originally received via a certain PACS (they still maintain a local copy).
Does anybody have experiences with using IOCM bidirectionally between PACS and VNA?
We have implemented IOCM (Fujifilm PACS and Lexmark VNA).
VNA has 2 components 1. DICOM Archive (second copy of our image data for DR)--which also acts as the XDS-I source 2. XDS Registry and Repository
Images are sent from Fujifilm PACS to the VNA --only after the status has been changed to " report authorised". This acts as the trigger to send to the VNA. This ensures that any image errors--side markers etc are sorted out prior to getting to the VNA.
After authorised status --IOCM ensures that studies in PACS and VNA are in sync at all times.
http://wiki.ihe.net/index.php/Imaging_Object_Change_Management It seems you have have only 1 change requester in IOCM. Our VNA is the change requester --as our plan is to have cull images using the life cycle management algorithm within VNA. Hence, after authorised status--if ANY changes need to be made on the images they should be made on VNA (NOT PACS). This is essential training for PACS and VNA system admin.
See the last few postings from Graham King and David Clunie on this very subject.
posted on Monday, February 20, 2017 - 08:30 am
Your comments certainly make sense, the Finnish architectural spec has not been fully documented when it comes to change management, so your input is very helpful.
The infrastructure allows for two options: a region could have a PACS and a VNA (where the latter acts as a XDS imaging document source), *or* it could have a PACS and use a 'national VNA' hosted by the Finnish healthcare ministry. The latter can be done at zero cost, so most regions have a preference for that solution. The 'national VNA' also acts as a XDS imaging document source.
> Images are sent from Fujifilm PACS to the VNA --only after the status has been changed to " report authorised". This acts as the trigger to send to the VNA. > This ensures that any image errors--side markers etc are sorted out prior to getting to the VNA.
They use the same principle. The mere fact that a study is stored on the VNA is the trigger to register the images using XDS.
> if ANY changes need to be made on the images they should be made on VNA (NOT PACS).
Makes sense as an approach, and one avoids a lot of issues that way. I'll ask the Finnish architects whether they have thought about such a requirement. If they could define this as a requirement then the use of IOCM (which would then be solely initiated by the VNA), and change management in general, would become much simpler.
And thanks Rene for filling up on the Finnish architecture and thanks Neelam for informative discussions! Just some additional words on the Finnish system..
> The latter can be done at zero cost, so most regions have a preference for that solution.
Just to be accurate, not zero cost, but zero additional cost ;) - ie. included in the normal service fee as apportioned in the Finnish decree for the service fees for the national healthcare ICT infrastructure. It even seems that all the regions may be going the centralized direction. Some may still ALSO want to build their own XDS-infrastructure, but rely on the national system for long term archiving and data sharing outside the region.
>> if ANY changes need to be made on the images they should be made on VNA (NOT PACS).
> Makes sense as an approach, and one avoids a lot of issues that way. I'll ask the Finnish architects whether they have thought about such a requirement. If they could define this as a requirement then the use of IOCM (which would then be solely initiated by the VNA), and change management in general, would become much simpler.
For the retention control, we are set on the VNA as change requestor. But for the other cases (modality worklist issues, quality issues / patient safety) we did not even think another solution than to set the PACS into the role of change requestor. But I see your point there. However we have had national patient records archive running now for a couple of years and I think there are error corrections even into the older patient records. And generally, even though we allow for some time to make sure the most obvious errors are fixed before archiving to VNA, we encourage to store the studies ASAP as they are shared via VNA/XDS-I. I think this is somewhat similar as to what Shaun Smale wrote in the another thread linked here.
BTW, what does it mean that the changes should be made on VNA? I mean technically. Ours is a distributed system in such a fashion that the VNA is national and the operational PACS systems are local or regional. The changes would have to be made in the national system and we would need to open direct interface to VNA update data with changes. We have a certification process for PACS systems (and XDS viewers etc) that communicate with the national infrastructure. I don't think that The Social Insurance Institution of Finland / Kela (who is responsible for implementing this national part - "Kanta system") would like direct updates on the VNA data.
Does this make sense at all...?
posted on Tuesday, February 21, 2017 - 07:24 am
Rene and Marko, Just remembered something- PACS may still be required to be a "Change Requester" for IOCM due to addition of images as part of post processing workflow-e.g orthopaedic templating images are added after authorisation.
VNA needs to Change Requester of image culling-LCM algorithms
posted on Tuesday, February 21, 2017 - 07:51 am
..all the more so, because in principle one can have multiple local PACSs that add images / gsps and other objects to a study. Which leads to a 'versioning' and 'ownership' discussion.
But the basis of all of that will be IOCM, from PACs to VNA and vice versa.
posted on Monday, February 27, 2017 - 10:22 pm
With XDS-I.b, there are two scenarios:
1. With IOCM - When an Imaging Document Source also supports as an IOCM Change Requester, it will generate a rejection note for the rejected objects. Note that in IOCM, even when a study is fully deleted, there will still be one rejection note left behind. This means the Imaging Document Source can use the existing Provide and Register Imaging Document Set transaction [RAD-68] to submit a new manifest as a replacement of the existing manifest. The new manifest will have one object which is the rejection note. It is up to the Imaging Document Consumer to determine what needs to be done when it fetches the manifest and then retrieve the rejection note.
2. Without IOCM - When a study is fully deleted, there is nothing to replace the existing manifest. As a result, the Imaging Document Source should use the XDS Metadata Update mechanism to deprecate the existing manifest as you suggested. There is some wording already exist in XDS-I.b (See Rad TF Vol 3 Section 184.108.40.206.2.1). However, it is not very clear exactly how to use XDS Metadata Update. So a new CP-320 is created to clarify the exact behaviour. It is still a work-in-progress.
Hope this help. Let me know if you need further information.