Data Retention of interfaced data

[Bob Schmid]

We often are asked to produce historical snapshots of messages sent to/from a specific interface to “prove” certain results/charges….. were successfully passed/received by a system.

Our current retention is 30 days on disk….1 year utilizing Tivoli.

Is there a retention period that we should be adhering to specifically because of legalities that anyone knows about?

How much history are you guys retaining when it comes to SMATS?

Thanks for any specifics.

Topic

[Robert Milfajt]

We have space for and keep 90 days.

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Russ Ross]

We have been saving all SMAT for 4 months back.

I will tell you that often that isn’t far enough back but we have been limited on our current production LPAR SNA allocation.

I believe going back one year would be a good idea if possible.

The new SAN allocation I have built out on our new Cloverleaf 5.6 AIX 5.3 HACMP cluster has 200 GB of archive space which is enough to get me 9 months of SMAT.

I have on the wish list to write a script that is smart about what gets cleaned after how long because charge files are tiny when compared to a real-time SMAT file with documents in it.

Typically the charge files are the ones that get asked for from 6 months ago.

My initial thought on an intelligent script would be to have a default number of days to clean old files and if a special flag file exited in the specific archive directory then it would clean files older than what was specified in the flag file.

This would allow me to be selective if disk space was a problem but this is still on the wish list unless someone comes forth and post a solution I can use and saves me the time and effort.

Now that we will be saving back 9 months I have even less motivation to ever get a round-to-it to coin a phrase.

Russ Ross
RussRoss318@gmail.com

[Bob Schmid]

We had a request from Radiology directory on Wed asking for “proof” that the engine sent a Result to an outside billing company.  from…………………. 😯 12/2006!

So…the “interface process” is what is being questioned/audited.

[Jerry Tilsley]

We were keeping data for 290 days due to space limitations, but found that we actually needed at one point to go back 1 year.  Now we archive all smat files that are over 90 days old to a .tar file and is then compressed with gzip.  Now we could technically store data for several years, but we haven’t really decided exactly how far back we want to go.

I would definitely recommend at least one year though.

Jerry

[Russ Ross]

I agree with doing a tar and gzip to compress what is archived and we do that but even then 200 GB I have will only get us back 9 months or 290 days and still leave a slight cushion considering the message flow we have which is some N millions of messages a day.

Our message flow is so high that we save SMAT and tar/gzip them to our archive file system every 3 hours to make sure they stay under our max files size of 2 GB.

Russ Ross
RussRoss318@gmail.com

[Nate Kruse]

I believe that we only save 120 days.

[Bob Schmid]

As I have read though, if this is a legal matter and the challenging/opposing party has better historical records than they set the standard for what should be able to be recalled….the more the better seems to be the concensus under HIPPA rules…at least 7 years on clinical (ie rad results). The engine has become part of “delivery of care”.

By the way…”historical data”/> day or 2, would probably never be resent

[Tom Rioux]

On the server itself, we only keep about 30 days worth of data.  The server is backed up once a month and the backups kept off-site, So technically, we do have access to messages further back.  

However, I agree with Nate.  I don’t see a need to keep a years worth of data.  We do have 30 days worth of data but communicate to the downstream users that we only have access to about 5-7 days worth of data, depending on the system.   We too get requests from users asking us to retrace a message or find out what happened to it.   By limiting ithe time frame to a week, we instill upon the user an expectation that Cloverleaf is not a repository for data.  If the users know you can go back a year, believe me, they will ask you for it.

There are are times when we will have to pull messages from the 30 day stash, but those are rare.  I have yet to have a user ask for messages older than 30 days.

Tom

[Bob Schmid]

We utilize off-line storage and Tivoli to store SMATS older than 30 days.

Currently we go back a year.

“Delivery IS the issue”

A billing company and patient want to know whether a Result was delivered to the Radiology COmpany in December of 2006. “Successful Delivery” is the issue.  

Nuremburg defense” not applicable here..to say you dont know/dont have aint good enuff!

[Tom Rioux]

My first question is why is the billing company still fighting over a bill after almost 4 years?   It seems like that would have gone to collections long time ago.

Anyway, HIPAA requires the retention of PHI for at least 6 years.  Cloverleaf was not designed nor intended to be a repository for data for that length (or any length IMO) of time.  We have and there are other applications out there designed for that very purpose.  I completely understand that in your case, delivery is the issue.  However, IMO, in the big picture that we call HIPAA, I don’t think that the focus is on delivery to one system or another but rather that the patient have access to their PHI for that 6 year period and Cloverleaf shouldn’t be the source of they go to for that information.  The information should still (notice I said “should”) be with the sending system.

I guess we can agree to disagree on this one.   😀

[Bob Schmid]

yea…good discussion….  💡

Thanks for your input…..it really is my problem here….I’m not sure of the details as to why delivery has been raised as a factor in this case given it was 3 years ago 🙄 …..the Radiology group we have been working with…has had questionable billing practices…and this may just be 1 little detail to help substantiate whether it’s the “hospital’s fault” in not delivering or delviering more than one occurrence of the same exam or whether it’s the billing folks at the rad group who messed up.

Anyhow…..I personnally think that offline archival of data interfaced could be valuable……if there is doubt as to whether needed…I know what side I’d like to error on…..

[Michael Hertel]

So then you’ll probably want to SMAT your ACK’s too, right?  😯

[Bob Schmid]

Funny you mention that. We are in the process of handling all acks with recover_56  We were handling them in the PDL’s….

[Chris Williams]

We archive all of our inbound SMAT files. Recently it was very useful for backfilling our new installation of Epic. The system has only been up for a few months, but users are pleased that they can access results going back to 2002 in one place.

[Author]

Replies