Jump to content

Do you use NP, TNP or QNS to override a blood type in Meditech


Recommended Posts

We are using Meditech C/S version 5.66.

 

Discovered that Meditech allows user (without any warning) to enter NP, TNP or QNS and override a calculated blood type and file/verify. 

 

In other words, we enter our serological tests results for anti-A, anti-B, anti-D, Rh control, A1 cells and B cells and Meditech calculates the blood type, e.g. OPOS.  User can position cursor on that result field and change the OPOS to NP!

 

Does anyone do this as part of your routine workflow to address a problem (computer or serological)?

Edited by Dansket
Link to comment
Share on other sites

Aren't those mechanisms to generate a credit? Couldn't you just delete the test in another function if need be? The only result we put in is the actual calculated blood type (although we do have a "Unable to determine" blood type in there as an option).

 

If we have a problem typing where back and front type don't match up, we record the original reactions as we saw them but also order and result non-reportable tests like Cold Backtype, Prewarmed Backtype, Saline-Replaced Backtype etc. to document what we did that enabled us to get the reported result.

Link to comment
Share on other sites

A Group and Screen (by Echo method) is automatically added to any product order. If we performed a manual Group and manual (by tube/Gel etc) antibody screen, we will NP the Echo Group and Screen result sometimes. We typically do this if we have a patient using a lot of product. If we don't, every order will create a new specimen since the software will be looking for the Group and Screen result and not find any since the Group and Screen was done by tube method using different test codes.

Link to comment
Share on other sites

In your statement "Meditech allows user w/o any warning", this depends on how the facility set up the calculation to work, not Meditech.  The facility must add the warning to the calculation.  You most likely need to evaluate how the calculation is set up, and possibly the ACCESS Dictionary.

 

Here is how we set up the Calculation in Meditech:

Triger Tests:  ORD=Y, Res=Y, NP=N, ND=Y, QNS=N.  If you answer "Y" for NP (No Print) or QNS, these results of "Y" are used as part of the calculation. 

 

In the Truth Table, this is the logic we used:

IF{'X [bbk err msg]("Invalid blood type calculation.")},

X;

 

Also be sure that your truth table is set up correctly.  I made a spreadsheet of every possible result, and then created a Blood type outcome for each type.  That is ~30 different combinations to create all of the blood types for an adult (w/o DU testing).  For example, you may allow users to use A,B, but it is not required.  To report an adult OPOS blood type, the truth table would be set up like this:

Anti-A NEG

Anti B NEG

Anti-A,B NOT POS (user can answer NEG or NOT Done, but not POS)

ANTI-D POS

RHCONT NOT POS

A CELL POS

B CELL POS

 

There are four(4) possible combination of results that are allowed to create a blood type of O POS.

 

In the Access Dictionary, OVERRIDE BLOOD TYPE CALC MISMATCH?  is answered "Y".  If your forward type did not match your back type (eg. pt has anti-M causing A or B cell to be positive, but is neg when antigen neg A or B cell is used for typing), user would enter actual results, and at our facility we add comment as to what was performed to verify result.  The user can then manually enter the blood type that should be reported and blood type is accepted.  This will appear on the "Override Warning Report".

 

You also have the choice of entering the "corrected" value for the A or B cell as a result and entering a comment as to what the original result was and why it is different (Antigen neg cell used).  This way, the calculation will not have a mismatched outcome.  I wouldm't recommend this, but it could be used.  This action would not appear on the override warning report.

 

If this is answered "N", the user will not be able to define a blood type when there is a mismatch.

 

Our facility is comfortable with BBKers performing this function because of their excellent training.  Some facilities may feel that only the supervisor should enter these "mismatched" results.  In that case, I would resort to downtime and issue "O" until the blood type can be entered by supervisor.  I would never have an invalid blood type be an acceptable blood type used in the system.

Link to comment
Share on other sites

whbb,

 

Please re-read my post. 

 

This issue is not about a BBK  calculation nor the way the ACCESS dictionary is configured, it is what you can do in Meditech after the "calculation rule has fired" and displayed the Blood Type. 

 

Try this yourself on your system.  Let the system display the calculated result and press return to go to the next line. Then reposition the curser back to the line with the calculated result.  Delete the calculated result of OP and replace it with NP, TNP or QNS. Press enter.  The blood type field has NP and Meditech generated no warning.   You can file the result of NP and you have successfully overridden the calculated blood type. 

 

Dan

Edited by Dansket
Link to comment
Share on other sites

Dan, this is yet another example of Meditech's lousy programming. I tried your scenario.

The good news:

- No billing was generated.

- NP etc did not go into the patient's history as a blood type.

- No results were reported.

The bad news:

- The typing was not performed or reported.

- It did not qualify for the Override Report.

Aside from making one very uneasy that a worker can override the correct interpretation of the most sacrosanct of lab results and not get tattled on, I don't see the potential for bad things happening to the patient. That doesn't make it good, though. This would be a nice thing to bring to Meditech's attention for a bug fix. It sounds more useful than 95% of the other fixes they make you validate before an upgrade.

 

Phil

Link to comment
Share on other sites

Phil,

 

The bad that can happen is substantial delay in the provision of blood in a timely manner.  For example,  the original request is a Type and Screen done at 3PM.  At 3AM the following morning, an urgent request for transfusion of red blood cells is received.  Night Shift is prompted by Meditech that units are incompatible with patient, no one sees the NP recorded as a blood type.  Supervisor is finally called, at this point 30 minutes have gone by..  Etc, etc.

 

I have submitted a service request to Meditech and they argue that this is "standardly" behavior and would require a $3200 custom fix!  Meditech suggests that within the Meditech BBK user base, there are users that routinely enter NP, TNP or QNS to override a calculated blood type for various reasons.  That is why I posted this thread

 

 

Dan

Edited by Dansket
Link to comment
Share on other sites

In test I ordered 1 RBC unit on the spec resulted NP, that being the only typing. I got a message "Missing blood type on patient", which would make me look up at the typing result and see the NP. No type in the header either, which we check as we're going in and hopefully would have noticed. Without a type I wouldn't have known what to try to allocate anyway. If there was a previous type on file, it didn't seem to mind that the typing on that spec was NP, it let me XM the blood. Am I not creating the scenario correctly? It sounds like the bad thing has happened to you, I would prefer to avoid the patient delay (and the 3 AM call) if I can.

Link to comment
Share on other sites

Phil,

 

I'm in a very small facility staffed with generalists who have limited problem-solving skills with computers and Blood Bank.  I feel that a BBK computer system should work very hard for me by limiting what the user can do.  Meditech repeatedly sabotages my efforts!.

 

Dan

Link to comment
Share on other sites

  • 2 weeks later...

In test I ordered 1 RBC unit on the spec resulted NP, that being the only typing. I got a message "Missing blood type on patient", which would make me look up at the typing result and see the NP. No type in the header either, which we check as we're going in and hopefully would have noticed. Without a type I wouldn't have known what to try to allocate anyway. If there was a previous type on file, it didn't seem to mind that the typing on that spec was NP, it let me XM the blood. Am I not creating the scenario correctly? It sounds like the bad thing has happened to you, I would prefer to avoid the patient delay (and the 3 AM call) if I can.

 

 

Phil,

 

I'm in a very small facility staffed with generalists who have limited problem-solving skills with computers and Blood Bank.  I feel that a BBK computer system should work very hard for me by limiting what the user can do.  Meditech repeatedly sabotages my efforts!.

 

Dan

 

 

Dr Pepper if your patient has a previous history of blood type, someone can NP the current specimen but the history will still display the historical value. Our type and screen result entry field still has a spot for anti-A,B and it also displays a bucket for ProVue Blood Type and ProVue Rh. So if someone is doing a manual blood type they have to NP those values out and sometimes the NP ends up in the blood type field. This exact scenario has caused some confusion for even our veterans.

 

 

When our ProVue interface was established I was told we had to include a value field in result entry for the provue values to interface, is that true? I don't see any reason for them, other than to cause problems - that and the custom report I use to identify the number of specimens performed on PV compared to manual testing.

Link to comment
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
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Advertisement

×
×
  • Create New...

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.