angonzalez

That's a great point. I agree that there could much more communication and cooperation between blood banks using the same software.

Yes. We have used Loadrunner to load test PROGESA. That is to stress the system with large load of simulated users. Other blood banks have as well. ePROGESA uses openSTA for load testing. You cannot do load testing without these automation tool. We also have Quicktest Pro but it has been used sparingly for unit testing/validation because that requires a lot of time to set up for the benefit it can provide. The problem is time. Essentially to use an automated validating tool, someone in your validation team needs to perform the validation manually and write it up. Then the script has to be written to do the same thing. The benefit comes when you regression rest the same functionality, you don't have to perform the manual process again. This is very useful if your doing a lot of regression testing, for example if you are development shop. But from my experience it has limited value in your typical blood bank setting. In such a setting, major new implementations or upgrades of commercial software do a one time validation. Minor upgrades or patches after that are not fully regression tested. The next major validation would only come with a new implementaion or major upgrade which would probably make any previous automation script obsolete. Another set of tools that could be used would be a test management or change management suite. A test management suite like Mercury Quality Center is software that lets you manage the manual or automated validation process electronically as opposed to using Excel/Word/file folders. It's useful but like with automation tools, it takes some time to set up and use and under the time crunch experienced in most blood bank deployments, this may be hard to pull off. Test management software also requires buy in from QA and management so this is another hurdle.

Given the cost and quality of blood bank software that gets 510k certification, I would agree, somebody is getting paid. I think there was a short lived attempt at it. See http://bloodbank.sourceforge.net/. But it went nowhere. Unless someone does the bulk of the work, and it would be a lot, I don't think you could get enough open source programmers to be interested in such a small niche project. And I don't think there is enough interest by blood banks to make it viable. It's a shame really because it would be in the long range interest of the blood banks would be more supportive of such an effort.

There was a similar discussion in these forums some time back LEAN lab and Blood Bank - BloodBankTalk (found through Google)

As Cliff mentioned, for more precise validation, the sample size is based on your margin of error, confidence level and population size. Luckily, there are online calculators for sample size, for ex at http://www.surveysystem.com/sscalc.htm and http://www.surveysystem.com/sscalc.htm. According to the above calculators, and as Cliff mentioned, for a 95% confidence level with a 5% margin of error and a population of 350,000 records you need a sample size of 384. Just FYI at the BB where I work, we used a 3rd party vendor to validate HCLL and the Hemocare to HCLL data conversion. Mediware only checks 10 patients per site when they do the conversion. The 3rd part vendor did a thorough job and checked a couple of hundred records. They arrived at the number of records to check using the FDA rule of thumb for electronic spreadsheets, "the square root of the actual number of clients plus one." The FDA formula can be found in http://pharmtech.findpharma.com/pharmtech/Technical-Considerations-for-the-Validation-of-Ele/ArticleStandard/Article/detail/42756. This rule of thumb yields a relatively low sample size for smaller numbers of patients. So for something like 20,000 patient records, they checked 142 patients. However, this rule of thumb has been criticized, for example here http://pharmtech.findpharma.com/pharmtech/article/articleDetail.jsp?id=56537 "The accuracy of the 95% confidence probability statement for mean was compared for three distributions for sample size obtained from the square root of N plus one rule with the Edgeworth approximation derived sample size.Results showed that the sample size obtained from this rule is not even enough to declare less than 20% of defectives in a moderate size population with a high degree of confidence.Therefore, the author concludes this rule should not be used to select a sampling plan to infer a population defective rate. ... A simple method for choosing a sample size from a population is through what quality engineers refer to as the square root of N plus one sampling rule. This rule is apparently not statistically motivated nor is it mentioned by sampling theorists, practitioners, or reviewers of the field"

To make concrete what I posted above. Say for example that a BB buys a software product for $50,000 and that they will validate and deploy it in the course of 1 year. Let's say the maintenance cost is $5,000. Further suppose that over the course of the year, 3 staff spend 1/3 of their time validating the software. Assuming the average salary is $75,000, the the total validation cost is, naturally, $75,000. Staff have to learn to use the software. Even if taught in house, that takes time. Say 1 full person month is spent on training, that is roughly $6,000. The software had to be installed on a new server. Let's say that is $5,000. There had to be some IT support cost. Even if the BB pays a flat fee for IT support, it should still be counted as a cost because time spent supporting the new software is not time spent doing something else. Again say IT spent 1 full person month on support, that is another $6,000. So the total cost of ownership, before the product is ever used, is not $50,000 but $147,000. And that is assuming no problems, no cost overruns, and not taking into account the cost for making the initial purchase decision, converting old data, disaster recovery, etc. As for the public communication of problems with BB software...there is very little in comparison with the public communication that is made regarding other software. If you go to various technical forums, user groups and sites for products such as Microsoft SQL Server or Oracle, even on sites owned by vendors, you will see very frank discussions of exactly what is wrong with the software including bugs, performance issues, problems with vendor support and lack of features. Such discussions are very rare for BB software, including this forum. Very few people have given reviews of the products they use. Of the BB software I have seen, I would rate about half fair or meeting expectations. But the other half is unbelievably bad. I am talking about some of the major BB software vendors. Some of the software is badly designed, unstable, full of bugs and completely lacking in support, extremely expensive and yet in wide use throughout BBs.

I disagree. Speaking from both sides of the user/programmer equation, the programmer does not need to be a user of the software in order to program it the right way. Keys to producing a good product are clear communications between user and programmer, well defined program specifications and a rigorous testing program. If designed properly, there should be no need for sacrifices beteen features. The only "sacrifices" that are needed are those of quality versus speed and cost. But if managed correctly, one can deliver a product of quality in a timely manner and for a reasonable cost. The fact that BB software is often of such low quality is because BB software companies are often managed poorly and have poor proceses for software development and software support. However that state can only exist in my opinion because BBer's do not require more of their software vendors. They are often willing to pay highly just to settle for an inferior product. Partly this is because BBer's often have pressing business goals in mind. That is, if good enough works to insure safety and getting product out the foor then good enough is settled for. Partly, I think this is due to non-profit mentality. That is, in my opinion, non-profits pardoxically do not processes in place or put an emphasis in cutting costs. Before you can even say that $50k is a good price, first you have to be able to say that you are actually paying $50k for what you are getting from the vendor alone. Often I find BBer's will only consider the initial software cost when they state they paid $50k for a product. They do not take into account the total cost of ownership which would include such things as the cost of validation, user training and maintanence. One also has to count time lost to outages or to finding workarounds for the limitations of the system. And finally, I do not think BBer's do enough to communicate publicly to each other problems encountered with particular vendors or products.

Lots of those. For a generic card just look at any office supplier like Staples http://www.staples.com/office/supplies/c17_Computer-Carts_10478_Business_Supplies_2_10051 http://www.officeworld.com/Worlds-Biggest-Selection/1275/09Q1/ http://www.tigerdirect.ca/applications/Category/category_tlc.asp?CatId=221&name=Furniture Or you can find more health-care specific computer carts like but they cost more http://www.flohealthcare.com/computercart.html http://www.artromick.com/prod_med_ws-imc.html

If you have not alredy done so, see the discussion on the exception report at the HCLL user's group at http://www.hcllusers.org/articles/exception-review (you need to get a logon to view).

I have not experienced this issue nor has anyone else I know. The release notes for the firmware upgrade do not mention this issue. Zebra firmware upgrades are some times a hit or miss. But upgrading is relatively easy and so is going back to your original firmware. The problem seems intermittent but if you can recreate, I would first recommend testing to see if it is the printer by printing to it from another application, other than the ones you have. I'm not sure of your set up, but if you can print from another application, then chances are it is not the printer. Assuming the printer is connected through TCP/IP, you could install as a TCP/IP printer on your PC and download some labeling software, Zebra Designer and ID Automation and other have free demos. Or you could just use lpr on the Windows command line, 'lpr -S printer_ip -P printer_name zpl_file_name. The zpl file could be a simple txt file like ---start of file---- ^XA ^FO50,50^ADN,36,20^FDxxxxxxxxxxx ^FS ^XZ ---end of file---- After, you can try using Wireshark to trace the network traffic between the PC / server and the printer. Wireshark is free and relatively easy to use. If you filter on the printer TCP/IP address you can get a pretty clear picture. If the PC / server is sending a request and the printing is returning an error packet or not returning a packet, then it could be a problem with the printer or not. You can get a lot of info from the network trace but the main thing to see is request and ACKnowledgements going back and forth between PC/server and printer. Unfortunately, solving this problems usually involves slow and tedious trial and error, at least for me.

There seem to me to be several reasons why there are so many BB systems and none is technical reason. Speaking as a technical person, I don't see a technical reason why a single customizable app might not emerge. I can't speak to how similar BB operations are but extreme similarity is not a necessary for a single customizable app to emerge. For example, SAP is deployed by vastly different companies -- organizations which are as much more different then BBs are from each other. Now of course, the deployment of SAP to an enterprise is serious, time consuming and expensive project but its doable. If we look at the growth of SAP, the necessary component is not so much the similarity of operations but the need by customers to have both a custom app that suits there needs and one that cuts costs too. Since these two requirements are in conflict with each other, a compromise must be made with both. Perhaps one reason is that a single app has not arisen is that BB's are sacrificing cost cutting for customizability, or the perceived need for customization? Even though BB's are non-profits, this does not necessarily mean that they put as much emphasis on IT cost cutting as, say, a for profit business. The question is not, what is the right system for a BB but what is the best system at the price the BB wants to pay. To do this analysis the BB must understand the "total cost of ownership", not just the cost of the software and hardware, but the support costs, training costs, management costs, costs of bugs, costs of customization, costs of changing customization, etc. For ex, if a BB's extremely customized app needs 2 years to get a required change, say to move to ISBT, then that represents a huge cost, implementation, maintenance, validation, etc. Only when the total costs is taken into account can the management of a BB answer, is customization X worth Y dollars? And it might be or it might not. Making this problem worse is that BB's are a niche market and that there aren't many providers of software. There is nowhere near the level of competition that exists or existed in other, larger markets. When there are fewer providers in a small market, there tends to be less competition for price. Providers may depend on propietary technology and customization to compete and seperate themselves from other players in the market.

I'm writing this post to confirm what other blood centers, like Florida Blood Systems, have already reported. Zebra ZM400 printers had a bug in their LPD software that made them unusable as IP printers from UNIX. If an lpd request to print 1 label was sent directly to the LPD server of the ZM400 printer from UNIX, the printer would continously print the label. This was because the Z400 printer did not appropriately acknowledge the network packets from the UNIX server and the UNIX print job would keep resending the label. As a result, we were forced to use the ZM400 with terminal servers. However, the latest firmware for the ZM400, V53.16.5Z, fixes the problem although the printer still reports some packet errors. The Zebra external 10/100 print server with the latest firmware revision, V1.01.6, also does not have the LPD problem and it reports no packet errors.

The problem is fixed. After 2 1/2 weeks of going back and forth with Mediware and Digi-trax, we finally got to a tech at Zebra named Dan. He suggested: "The last thing we need to try and it does not look like any one tried this. If it’s a 10 base T Print server disable bidirectional …if it’s a 10/100 change parallel port mode from nibble to compatibility and the Zebra link mode to disable. Attached are screen shoots of where to do it." Since our printers were 10base-T based Z4M Plus'es, we disabled bidirectional printer and that did the trick! Thanks again Dan, wherever you are. NYBC

Update: We got a new 10/100 network card from the Zebra printer vendor for the Z4M Plus but this did not fix the problem.

Thanks for the response. I can tell you that the batch printing does work if we use a Zebra ZM400 printer which is the newer Zebra printer. The Z4M Plus were discontinued by Zebra but they were bought a year ago for this project. Currently, the Digi-trax (Zebra reseller, Hematrax vendor) has suggestd that we try swapping the network card on the Z4M Plus. Hopefully he will send us the card in a few days.