CMedina84

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.

Hello Everyone, Hope someone out there is experiencing the same issue(s) we are. To briefly explain our current status we currently have actively interfaced two Ortho ProVue analyzers. On these analyzers we have successfully mapped orders for ABORh testing, Antibody Screens, DAT testing, Unit Confirmations, and Rh Phenotyping. During our validation testing was smooth and PERFECT. Once we went live and switched to production we noticed two issues: 1. Unit confirmations download beautifully but its on the upload where problems occur. Since we are not ISBT, we still have units with codabar. When Wyndgate/SafeTrace sends a unit confirmation order through the Instrument Interface it will translate a unit number 33FQ42432 to a numeric only 3142432. When the Provue processes this order and sends the result it sends it to the instrument interface with a specimen id of 3142432. The problem with this is, the Instrument Interface will compare this specimen id to the entire database to make sure there are no discrepancies. Well, our database is so large and patient id's which drive specimen id's are already in to the 7 digits so we are experiencing about 3-4% of our unit confirmations will error out in the Instrument Interface because the specimen id already exists in the database. Anyone experiencing this same issue? What is your work around for it? 2. Secondly, we are experiencing a significant amount of lag in our Two Way Holding table due to the size of our database. We opted not to have results autoupdate without user intervention. Has anyone chosen the same set up and experience the same lag when you query and try to release results? If so, Haemonetics said the Two Way Holding was not intended for the use of releasing results but only to catch results that fail the auto update criteria. Has anyone tried switching to Auto Update and has it improved lag times and the posting of results?

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.