posted on Saturday, November 12, 2011 - 06:42 am
We had an interesting discussion on this topic on Monday. Various views and suggestions from NHS (Andrew) and standards (Shannon & Dave). Prior to the meeting, I could not get a single PACS supplier wanting to speak on this topic for 7th Nov . However, now many are looking at this intently as this issue does not just affect us--the problem is global--as mentioned by Shannon. I joined a teleconference with RCR on Thursday as they are looking at simplifying their existing guidance on retention which I will make implementation easier in the real world--we will need to wait for this.
Some Trusts may wish to take a stronger view of retaining data for longer periods using standard compression. However I think even if we extend data retention for a 100years, we do need to cull the data after that period, so this this issue is relevant to everyone--whether you wish to compress data as an intermediary stage or not.
I am working on version 9 of the PACS Spec document & this is how I have reworded the relevant sections. I have put the onus of informing of informing the PACS team of a requirement to extend culling dates on the individual departments--Medicolegal, Research Trials etc. Comments please.
"6. CULLING OF IMAGES The PACS MUST be able to cull data based on local policies relating to data retention periods. The deletion of culling of exams will be arrived at using an algorithm.
Below is a simple ALGORITHM for date of culling using current RCR retention guidance for England (algorithms should be modifiable for countries, local Trust policies etc) STEP 1 establishing a patient folder level date of culling a. 25years after DOB—Date a.a.a b. 8years after date of last exam—Date a.a.b c. Manually entered date of patient folder culling (allowing extension for medico-legal, research trials, oncology patients etc etc)—Date a.a.c d. Overall date for folder culling---Date a.a.d ---(this will be the later date for a.a.a , a.a.b & a.a.c)
STEP 2 establishing exam level date of culling a. Overall Date for patient folder culling (from step 1)—Date a.a.d b. Obstetric exams –after 25years—Date b.a.a c. Manually entered date for exam level culling (slow growing tumour, hip replacement etc).—Date b.a.b d. FINAL date of culling for a particular exam ---Date b.a.c (will be the later date is chosen from the above dates in step 2 –a.a.d , b.a.a , b.a.b)
--Algorithm for arriving at the final date for exam culling (Date b.a.c) may be arrived in any IT system—PACS, RIS, Independent IT system ---Above algorithm ensures that all exams will be retained for a minimum of 8years. Robust processes MUST be in place to prevent accidental deletion before 8years. --PACS MUST be able to incorporate & display the final date of culling for an exam (Date b.a.c) for ANY clinical user to see --PACS MUST be able to cull date according final date from its PACS archive --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 (Date a.a.c) or exam level (date b.a.b)"
Neelam, Personally I think this is a little over complex, or over specified. I find it difficult to follow the a.a.b./b.a.a. logic myself. We would be better specifying sample rules we expect the supplier to implement, and ask them how they intend to do it, than specify the method ourselves, especially while no standard exists. The PACS will be able to cull data based on local policies relating to data retention periods. The deletion of culling of exams will be arrived at using an algorithm. The PACS will be able to set/adjust a retention date based on a set time period after the date of acquisition The PACS will be able to set/adjust a retention date based on date of birth The PACS will be able to set/adjust a retention date based on manual date entry, or on receipt of a date, or revised date, from another IT system such as RIS. Where two dates are provided (e.g. an existing date and a newly supplied or calculated date), the later date will usually take precedence (exceptions might include updating based on date of death). Where a date is adjusted for one study, the PACS will be able to set/adjust the date for all other studies that have the same patient identifier. The exact dates and rules will be adjustable, as required by the customer, but the default retention date for studies, applied at acquisition, would typically be 8 years. The PACS will be able to delete studies based on these rules, ensuring all studies are retained for at least the minimum retention period (typically 8 years). Robust processes will be in place to prevent accidental deletion before 8 years. The retention date will be stored in such a manner that it will be retained during any future data migration. The retention date will be stored in such a manner that it will be viewable by clinical users.
Meanwhile my proposal at EHI Live was to define a standard way of storing such dates, and adjusting them through messaging, such as between RIS & PACS. The method I proposed (based on discussion elsewhere on this board earlier in the year) wasn’t intended to be definitive, but a starting point for discussion; Dave Harvey had some ideas for developing it for instance. However what I proposed was as follows: Every study has a DICOM field for a “Display Until” date, until which a study can not be deleted. At acquisition PACS could set this to 8 years hence for every study PACS (or another IT system) would set the date to the patient’s 26th birthday, if that was further in the future than 8 years. Manual editing, or a message from another IT system, would allow the date to be modified in other ways, such as 30 years hence if a user marks the patient as an oncology patient in a tick box in RIS, or back to 8 years if the PACS or RIS receives a date of death. If the retention date for one study is set or extended, PACS could automatically update all other studies with the same patient ID to match, thus retaining the whole patient record, and obviating the need to have a separate patient retention date in the database. The date would be retained during a migration if it is in a DICOM field.
Neelam intends to put the EHILive talks on the site, mine includes a couple of slides with mocked up DICOM data to illustrate these ideas.
Andrew, I agree with your comments. However, the reason my algorithm was more complex than yours---I was trying to accomodate the DOH guidance and allowing for a differential retention for a film packet vs a film. For example we could only retain CT scan of chest abdo pelvis in a research case--rather than retaining the entire film folder for the patient (film packet). However, I suppose we could simplify the algorithm to ONLY allow for folder level retention. And allow for complexity to be developed by vendors if they can or customers demand it.
I agree with your view---Keep it as simple as possible to start with.
I avoided the issue of study retention in my reply, but there is no reason a software routine to update a date couldn't specify whether it should be applied to all that patient's events, or just the one being referenced.
An update routine simply needs a flag "Update all" or "Update this only".
This would allow for obstetric/maternity records as well as clinical trials.
I was keen to avoid the complexity of having dates stored at study level but also in a separate patient database.
posted on Wednesday, November 23, 2011 - 10:01 pm
I have taken Andrew's advice & simplified this. What do you think?
6. 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)