UK Imaging Informatics Group
Life cycle management PreviousNext
UK Imaging Informatics Group > Questions & Answers > Network & Storage Issues >
Message/Author
 Link to this message John Parker  posted on Wednesday, March 21, 2012 - 02:44 pm Edit Post Delete Post Print Post
Along with lots of other buzz words - VNA, cloud, IHE blah blah, this is something we hear, but I don't see that much discussion about, so to start the ball rolling......

Lets just assume (big breath in) for a minute, that we all agree that we can't keep everything for ever (breath out).....

In the good old days of film, it was relatively easy to colour code packets to indicate age of films/ retention stickers etc, so the annual purge of packets could happen (we have historically always accepted the need to do this!).

How could we translate this into a system -archive where we can set some basic rules, and update as we go along?

Should this be a function of the application used to view images (viewing s/w or PACS/ s/w, or is this a function of the archive itself - in which case, how do clinicians/ users, update the status??

if we were to follow current guidance on image retention:

7 yrs +current
Paeds -age 21
certain medico legal cases for ever....

what other rules or 'default rules' would you want to see?

I'm not sure I've seen this sort of functionality on current PACS systems (but are prepared to be proved wrong!)

Data storage firms/ VNA's etc seem to have some functionality as standard. How could users, who might want to make these decisions 'on the fly' do so, without having to jump through lots of admin hoops??

Would some 'middleware' be the answer (if indeed it exists)??

OK - plenty to go at....any takers??

John
John
 Link to this message William Saywell  posted on Wednesday, March 21, 2012 - 02:59 pm Edit Post Delete Post Print Post
John,

some companies are starting to bring this in, and I believe there is something DICOM in the pipeline [if not already extant].

It's easy to produce purely time-based rules such as inactive patient aged <19 at first exam has stuff deleted after age 21

or 7 years if older than 18 etc.

Where it gets complicated is when you factor in cancer patients' films being kept for longer, or those with implants.

These would require sentient input, preferably at the time of reporting, or [harder] in retrospect. Flags would then have to be set so that the rules engine could take this into account.

William
 Link to this message Neelam Dugar  posted on Thursday, March 22, 2012 - 09:43 pm Edit Post Delete Post Print Post
John,

The following I have included in the Group PACS Spec doc which has been much discussed & debated on another thread.

"CULLING OF IMAGES
The PACS MUST be able to cull data from its archive based on local policies relating to data retention periods.
Algorithm for arriving at the final date for exam culling may be arrived in any IT system—PACS, RIS, Independent IT system
Algorithms MUST be modifiable for use in different countries, local Trust policies etc
Robust processes MUST be in place to prevent accidental deletion before certain predefined period (8years in England) .
PACS MUST be able to display the date of culling for an exam for ANY clinical user to see
PACS must be able to inform other systems which also may store the same data (Backup Vendor Neutral DICOM archive, Hosted Datacentres etc)—using standard IOCM profile of IHE when data is culled.
The onus is on the medicolegal departments, Research Trials departments, Oncolology, and other departments if they wish to extend the date of deletion beyond the minimum retention periods of 8years or 25years after birth. Trust local processes/policies need to be in place so that these departments/clinicians can make a request to the PACS Office/PACS Team to manually extend the date of deletion at patient level.

EXAMPLE: Simple algorithm (choose the later date from the 4 dates below) to cull the patients image folder
1. 8 years after last visit to X-ray dept
2. 25 years after DOB
3. 25 years after an obstetric ultrasound exam
4. Manual Extension of date of culling (medicolegal, oncology, research trials, slow growing tumour, hip replacement etc)

More complex algorithms maybe required by different institutions/countries may include date of death, differential retention periods for particular types of images (separate from patients folder)"

Most PACS suppliers will be able to deliver the simple algorithm described above. Those replacing PACS most include this in your functional spec.
 Link to this message John Parker  posted on Monday, March 26, 2012 - 01:20 pm Edit Post Delete Post Print Post
Hi William, Neelam,

Thanks for the responses....

I've heard much regarding LCM with regard to VNA - much less so in respect of PACS...

If the PACS is 'responsible' for this, what happens when you change your PACS provider, but keep your VNA?

Users being able to see the current deletion date is excellent, but I don't think is widely available. In addition, how users request extensions should also be considered - will they need to phone, write letters/ mail PACS support teams, or use a 'messaging'function from within the PACS - these decisions are often made some time after the images are taken, and we should consider this workflow....


Do any PACS providers have this functionality now (as in March 2012)??


John
 Link to this message Neelam Dugar  posted on Tuesday, March 27, 2012 - 10:34 am Edit Post Delete Post Print Post
Yes John. I too have heard of VNAs talking about LCM. However, my problem is that PACS needs to "know" when an image is deleted (as the PACS is the clinical user interface). For this to happen--- VNA and PACS need to talk a common language---i.e. common standards. The IOCM profile of IHE tends to address this. However, if customers do go down the path of VNAs providing LCM---MUST make sure both PACS & VNA vendors adopt IOCM profile of IHE.

"Users being able to see the current deletion date is excellent, but I don't think is widely available."
Rather than accept a PACS salesmans response--that this is not available in PACS---write it is your "operational specification for PACS". It is upto customers to demand what they need and to choose a PACS supplier who is willing to deliver this--2013 provide huge opportunities for us. PACS suppliers must move on & do R&D to support customer needs.

"how users request extensions should also be considered - will they need to phone, write letters/ mail PACS support teams, or use a 'messaging'function from within the PACS - these decisions are often made some time after the images are taken, and we should consider this workflow"
In my view, we would use the PACS helpdesk system that we have working for IEP, CDs etc--so that there is only 1 number to call for all PACS related issues. However, other suggestions are welcome as always.

"Do any PACS providers have this functionality now (as in March 2012)?"
Why dont you ring around and ask the PACS suppliers yourself. Or you can ask this through your formal procurement process--PQQ, IPCD etc
 Link to this message Pim Philipse  posted on Monday, April 02, 2012 - 08:05 am Edit Post Delete Post Print Post
Hi John,

You wrote:

"If the PACS is 'responsible' for this, what happens when you change your PACS provider, but keep your VNA?"

One can already synchronise some patient and study data in PACS and VNA using the IHE SWF/PIR profiles.
If you use the existing mechanism (HL7 messages) to convey the deletion date as well, the VNA can at least remember the culling dates that were created in the PACS. An alternative would be to issue a change proposal for the IOCM profile (which is in Trial Implementation anyway) and add a date/time on which the deletion should take place.
In HL7, Patient Death Date is in PID-29. Together with this information, the VNA could cull the images without intervention by the PACS. If the IOCM KOSD's that have a future date of 'execution' are visible in queries, users can inspect this date for studies in the VNA and possibly send an updated version.

I hope to address this in my upcoming proposal for a Long Term Archiving IHE profile.

Pim Philipse (Rogan-Delft)
 Link to this message David Clunie  posted on Monday, April 02, 2012 - 01:25 pm Edit Post Delete Post Print Post
There is already a CP in process (DICOM CP 1152) to add "Data Retention Policy Expired" as a KOS document title.

This would allow IOCM to be used for this, and for non-IOCM archives, the KOS with this title to be found with a search or to be apparent on retrieval.

Death (or supposed death) is not necessarily a reason to purge; indeed quite the opposite if litigation ensues. These may be reasons why, in the US, the Medicare Death List is not often used for this purpose (not everyone on it is dead, and it may not be appropriate to trigger purging even if they are). It may be a reason to remove the images from general accessibility though (and perhaps we should add a KOS reason "Sequester for litigation").

I am not sure the date of when to purge itself is relevant, as opposed to the external "decision making rules engine" specifically saying purge as of "now" (the content date of the KOS, for example). This avoids needing to add specific semantics to the document title of the KOS linked to other content items or attributes in it.

Of course, with a "message" like this, the decision maker doesn't need to be in the PACS or the archive, but could be an external system (like a RIS or HIS), and both the PACS and the archive recipients of it.

David
 Link to this message Neelam Dugar  posted on Monday, April 02, 2012 - 04:41 pm Edit Post Delete Post Print Post
Thanks David & Pim.

I am really reassured to see that both credible vendors like Rogan & standards people like David are talking about data culling.

I like the term David has used "decision making rules engine" which can be in HIS/PAS, RIS, PACS, VNA or even separate to all this. This rules engines simply " informs" all relevant systems--PACS,VNA etc regarding the date for culling.

David,
Should this be part of IOCM profile or a new IHE profile do you think?
 Link to this message David Clunie  posted on Tuesday, April 03, 2012 - 03:44 pm Edit Post Delete Post Print Post
Hi Neelam

This use case is already covered in IOCM.

Whoever is the Change Requester actor sends the KOS.

David
 
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: