Jump to content
Sign in to follow this  
R1R2

Not issued in the LIS

Recommended Posts

Hi everyone,

Please tell me how you solved your "not issued in the LIS" problem. Thanks for your replies.

R1R2

Share this post


Link to post
Share on other sites


You mean components are just given out . . . no documetation? If so . . . retraining . . . if continual I will look for a new BB tech. If you can't do it as per procedure, you can't do it.

Share this post


Link to post
Share on other sites

If it's a one time occurrence have a non-threatening conversation with the tech, explaining the problems with this deviation from procedure. Document this conversation. Also look at the why? Massive bleeder, working multiple depts, staffing, that kind of stuff.

If this is a "repeat offender" take the "conversation" to the next level and tie it to a patient safety issue. I agree with David, look at retraining (document this) and if the problem persists maybe this tech is "not a good fit" for the Blood Bank or your organization. Did I mention documentation?

Share this post


Link to post
Share on other sites

We used to have a process where I worked before that set people up to forget to hit enter at the end of the issue process in the computer and so it wouldn't record the issue. If it is happening to multiple people really look at the nitty gritty of the process to see if you can build in a step to protect from this pitfall (if that is what you have going on).

Share this post


Link to post
Share on other sites

I agree with Mabel. Keep documenting like David said. But then trend it to see, If you have multiple techs doing same error, may be you need to look at your process and make the process such that you do not allow for the blood go out without issuing blood in LIS.

1) Do not keep printed crossmatch/component tag.

2) Allow them to print only at the time of issue.

after trending we changed our process completly, invested in new printer for crossmatch/component sticker. changed the process so transfusion tag prints at the time of issue with the issue date and time on it.

We hardly have any error, once/twice a year and that even during system downtime only. In that case we give a benefit of doubt and just remind the staff to complete the transaction after systme is up.

We have zero tolerance for all other cases due to carelessness.

Share this post


Link to post
Share on other sites

We have Sunquest/Misys as our LIS and it is very easy to miss an issue. It's not a matter of the techs being careless, but more a matter of poorly written software. If you are distracted at the "save" portion of the computer issue (phone call for example), the system will just "time out" and will erase the transaction from the screen. The time for this to happen may be as little as 10 minutes depending on your site parameters. This is a spot where the computer should keep the transaction on the screen until acted upon, but I doesn't work that way. We are in the process of upgrading to version 7.0 and I have NOT had a chance to see if they've improved this process.

Share this post


Link to post
Share on other sites
We have Sunquest/Misys as our LIS and it is very easy to miss an issue. It's not a matter of the techs being careless, but more a matter of poorly written software. If you are distracted at the "save" portion of the computer issue (phone call for example), the system will just "time out" and will erase the transaction from the screen. The time for this to happen may be as little as 10 minutes depending on your site parameters. This is a spot where the computer should keep the transaction on the screen until acted upon, but I doesn't work that way. We are in the process of upgrading to version 7.0 and I have NOT had a chance to see if they've improved this process.

We have upgraded to 7.0 and they have NOT improved this process. It still times out. And it is very easy for a tech to get distracted during this process particularly if they are the only person in the department at the time.

I would be very interested in hearing what process others are using to prevent this. For those who don't print the unit tag until time of issue do you identify units in the refrigerator prior to issue? Obviously the process to issue will take longer and I am not sure that the nurses who come to pick up blood will be happy about that since they are always in a hurry to get back to their patients.

Share this post


Link to post
Share on other sites

Failure to issue in the LIS is one of the most common reportable errors for a TS. As said above, its easy to get distracted and miss this step, but its important because it provides documentation that the product remains acceptable for use. I wish I had a good suggestion for how to improve compliance with the requirement.

Share this post


Link to post
Share on other sites

We have the same distraction/time out issues, where a tech does evrything but hit the final accept key. What helps is that when we result a crossmatch our LIS prints out an 8 1/2" x 14" form. This consists of an 8 1/2" x 11" record of blood transfusion form (ends up as the chart copy of the transfusion) with two smaller perforated 4" x 3" forms on the bottom. The little guys are identical. One is the bag tag that stays on the unit, its twin stays in the blood bank after issue with the issue time recorded on it. Next morning we print a transfusion log from the day before which should match up with the pile of saved stubs. If someone "forgot to do it in the LIS" we can see that readily, plus the inventory would be off. Serves for downtime documentation too.

Noncompliance is dealt with as above.

Share this post


Link to post
Share on other sites
I agree with Mabel. Keep documenting like David said. But then trend it to see, If you have multiple techs doing same error, may be you need to look at your process and make the process such that you do not allow for the blood go out without issuing blood in LIS.

1) Do not keep printed crossmatch/component tag.

2) Allow them to print only at the time of issue.

after trending we changed our process completly, invested in new printer for crossmatch/component sticker. changed the process so transfusion tag prints at the time of issue with the issue date and time on it.

We hardly have any error, once/twice a year and that even during system downtime only. In that case we give a benefit of doubt and just remind the staff to complete the transaction after systme is up.

We have zero tolerance for all other cases due to carelessness.

Thank you aakupaku for your ideas. We have institued your suggestions several months ago and they have helped. Our last error occured because tags were printed out ahead of time because of special patient requirements. I am looking for zero errors. Perhaps that is not possible?

R1R1

Share this post


Link to post
Share on other sites

One easy workaround for printing tags ahead of time to "save" special units for someone (besides handwritten scraps of paper tucked in the holder), is to have a regular laser/paper printer also set up which you can print to. You can just send the tag there instead, have all the info on the paper about when xm done, who its for, etc, but theres no holes or 3 part paper or unit sticker, so it cant be mistaken for a ready to issue tag. Its a quick way to see physically which units are on hold for someone and cue the door/issue person to investigate if say a crossmatched platelet near expiration might be able to be freed.

Share this post


Link to post
Share on other sites

Those you can include as outliers. But then you need to see how often it happens. We have cerner classic and if patient has low incidence antibody eg. anti-cw, the LIS will not allow to dispense unit without password if the unit is not tested Cw-. Only sopervisor has password no one alse has password. The techs can print the tag at the time of croosmatch so we end up printing transfusion record manually at the time of crossmatch and hand write the time on it. Next day the unit get issued by supervisor and it appears on exception log.

Thank you aakupaku for your ideas. We have institued your suggestions several months ago and they have helped. Our last error occured because tags were printed out ahead of time because of special patient requirements. I am looking for zero errors. Perhaps that is not possible?

R1R1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.