UK Imaging Informatics Group
IHE XDS & IOCM PreviousNext
UK Imaging Informatics Group > Questions & Answers > PACS Integration & Standards >
Message/Author
 Link to this message Rene Spronk  posted on Saturday, February 18, 2017 - 08:34 am Edit Post Delete Post Print Post
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?

Best regards,

-Rene
 Link to this message Neelam Dugar  posted on Sunday, February 19, 2017 - 05:46 pm Edit Post Delete Post Print Post
Hi Rene,

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.

Does this make any sense?
 Link to this message Neelam Dugar  posted on Sunday, February 19, 2017 - 07:45 pm Edit Post Delete Post Print Post
http://www.pacsgroup.org.uk/forum/messages/2/78816.html

Hi Rene,

See the last few postings from Graham King and David Clunie on this very subject.
 Link to this message Rene Spronk  posted on Monday, February 20, 2017 - 08:30 am Edit Post Delete Post Print Post
Hi Neelam,

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.

Thanks,

-Rene
 Link to this message Marko Jalonen  posted on Monday, February 20, 2017 - 10:55 am Edit Post Delete Post Print Post
Hello everyone,

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...?

Br,
Marko
 Link to this message Neelam Dugar  posted on Tuesday, February 21, 2017 - 07:24 am Edit Post Delete Post Print Post
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
 Link to this message Rene Spronk  posted on Tuesday, February 21, 2017 - 07:51 am Edit Post Delete Post Print Post
Hi Neelam,

..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.

-Rene
 Link to this message Kinson Ho  posted on Monday, February 27, 2017 - 10:22 pm Edit Post Delete Post Print Post
Hi Rene,

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 4.68.4.1.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.

Thanks,

Kinson
 
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users may post messages here.
Password:
Options: Automatically activate URLs in message
Action: