Is there anyone out there who has successfully interfaced their ProVue with Wyndgate? We are currently in the process and are having problems "mapping" our cord bloods.

Thanks.

We have the ProVue and Wyndgate mapped for the bidirectional interfaces. My LIS manager worked with Wyndgate (Haemonetics), Data Innovations and Ortho to get this completed. The only tests that we have crossing the interfaces are ABORH, Type/Screen, DAT and a baby type. We did not work on interfacing the unit typings, panels, crossmatches to cross, that will be for a future project.

Our site managed to get patient ABORh's, Unit confirmations, Crossmatches, Cc Ee antigen typings, cord bloods, and a few other tests to successfully download and upload to and from SafeTrace. However, we have ran in to a problem with Unit Confirmations that I think anyone who has a Provue to SafeTrace interface will run in to. When SafeTrace/wyndgate sends an order for a unit confirmation through the instrument interface, the unit # is stripped of its first two numeric characters and the alpha characters are converted to numbers based on the table definitions. So unit 33FQ42432 will be sent to the Provue with an ID of 3142432. When the analyzer is done and releases the results, it releases it with an ID of 3142432 to the SafeTrace Instrument Interface. The instrument interface then goes ahead and compares that specimen ID to the entire database to make sure it is "unique." Well the problem with that is, that number can be occupied as a specimen ID by a previous or current patient in our system. If the number exists as a patient specimen it will error out in the SafeTrace Instrument Interface and not send the results to SafeTrace giving the tech no clue on what happened with those results since the instrument interface lives on a server for IT use only. Our site and database is relatively large so manually creating a specimen has been out of the question. I'd be glad to give you insight on mapping the others but I just want to warn you of issues you will eventually see.

CMedina84,

I would be very interested in knowing how you mapped your cord bloods with ProVue and Safetrace. Also, do you use the ABD&Reverse card or the ABD/ABD card? Thanks.

CMedina84,

I would be very interested in knowing how you mapped your cord bloods with ProVue and Safetrace. Also, do you use the ABD&Reverse card or the ABD/ABD card? Thanks.

Hi Butlermom,

My apologies, all we have mapped for Cord Bloods are Cord Blood Rh's. To give you an exact idea of what we have successfully mapped are:

2 Cell Antibody Screens

Unit ABO with Rh Confirmations

Unit ABO only Confirmations

Patient ABORh with Reverse Group Type (We have the ABD&Reverse Cards)

Patient ABO Front Type Only

Patient ABO Front and Reverse Type (No Rh)

Patient Rh type only with rule built to add on Control

Rh phenotyping (C, c, E, e)

Cord Blood Rh Type with a rule built to add on Control

Full Crossmatch with Immediate Spin add on rule

Immediate Spin Crossmatch only

DAT IgG

DAT Polyspecific AHG

All of these orders have been mapped are a fully functional in downloading orders and uploading results with minor exceptions. For Full Crossmatch w/ Immediate spin since we use Instrument Manager, we cannot get a final interpretation sent to Wyndgate because the interpretation for the Full Crossmatch and Immediate Spin are sent in two separate messages in Instrument Manager. In Instrument Manager you cannot build a rule to combine or deliver a final interpretation based on two separate messages, its just not possible. For this minor issue we are having the tech review the results that post from the analyzer, input the final interpretation, and saving/releasing the result.

The other unpredictable issue we discovered when we switched from VALI to PROD was doing unit confirmations. Orders download fine, but since we are not ISBT, unit codabars are translated from eye-readable values (values containing numeric and alpha characters) to numeric values only. This conversion from alpha and numeric (i.e] 33FQ12345) characters to numeric characters (3112345) is causing a problem when results are sent. The eye-readable values after conversion are labeled by the Instrument Inteface on the Wyndgate server as a "specimen id." When results are sent, the Instrument Interface on the Wyndgate server will first run the specimen ID through the entire database to make sure it is "unique." If you have a database with patient id's in the six figures and you automatically generate specimen id's using the generate key, then you will run in to this issue as well. The issue is for patients who have a patient id with six figures, when you create a specimen id, you now have a 7 digit specimen id in the database. So...if you bring a unit like the mentioned (33FQ12345), once the order is processed and resulted, the instrument interface will compare it to the database as 3112345, and if there is a patient with an id 311234 and they have a 5th generated specimen with a specimen id of 3112345 it will error out in th instrument interface and the users will have no idea why it did not cross without having access to the instrument interface on the server. We have explained this issue to Wyndgate over and over again and they have no fix currently in place to solve this issue. The only way around it is to manually create the specimen id's but the task is actually very daunting and hard to keep track of when you have a database full of 400000+ patient id's.

I'd be glad to give you some advice on our set up if your's is simliar to ours. Let me know what you use. We are currently on SafeTraceTX/Wyndgate version 3.5.1.0 SR1. We use Data Innovations Instrument Manager middleware.