- Email: [email protected]
Quality control for computers in blood banks
Transfus. Sci. 1989; 10:233-240 Printed in Great Britain. All rights reserved
Quality
09553886/89 $3.00+0.00 Copyright @ 1989 Pergamon Press plc
Control for Computers in Blood Banks Stanley C. Roberts, MA, SBB(ASCP)
n This is a report on the current quality control applications that may be applied to computer systems used in blood bank operations. The concepts and principals described have been used in the design of complete regional blood center computer operations but can also be applied to single use applications. The computer offers the opportunity to increase not only the quantity of work performed but it can also improve the accuracy. Before computers or software are used in the blood bank setting, however, there must be sufficient documentation of the design, testing, and validation to ensure that it is functioning according to specification. This report will describe some of the planning and methods used to accomplish this goal. n
a new technique or application. This has also been true for computer applications in the blood bank. Analytical systems have evolved in clinical laboratories from the manual systems of the early 20th century to mechanization in the 195Os, and to full automation and computer controls in the 1970s and 80s.’ It is not surprising that computers have become integrated into routine blood bank operations. For purposes of this discussion, a computer will be defined as an electronic device which either measures, records, or maintains critical data for blood bank operations, There are many examples where computers are used which may not be obvious. Two examples are the maintenance of donor or patient records with previous laboratory data, and automated equipment producing new test results. No one would disagree with the utility of computers in the blood bank, but as yet, the usual rule-making groups have not universally applied other agencies’ guidelines or industrial standards to blood bank applications. The computer offers blood banks the promise of precise and current record keeping with rapid data acquisition and storage. However, the real potential of computers is achieved only when the computer is to interpret and control critical steps in the blood bank operations. These steps would ultimately lead to the decision to transfuse a product, or more important, to discard a product that could transmit disease. Some people be-
INTRODUCTION
Blood bank operations have always required careful and well defined controls and procedures. This is usually accomplished by publishing rules, guidelines, and standards. These are written and published by several inspection agencies and organizations, e.g. the FDA, the American Association of Blood Banks, the College of the American Pathologists, and the American Red Cross. The process of writing guidelines and standards usually follows the introduction of FromtheAmerican Red Cross Blood Services, Connecticut Region, 209 Fannington Avenue, Farmington, CT 06032. 1911, U.S.A. 233
234
Tronsfus. Sci.
Vol. 10, No. 3
lieve that if a complete set of steps or a decision tree could be written, then it should be possible to program a computer to execute those logical decision paths. The benefit of such a program would be consistent and correct results accomplished through a mechanical device without the need of human intervention. The challenge, which is an issue for blood banking, is to define those rules, guidelines, and standards which will ensure that a consistent outcome is achieved when using a computer. The FDA has published a technical report on software development activities2 which describes the documentation needed when software is placed in use as a medical device. The FDA refers users to industrial standards and procedures published by the American National Standard Institute and the Institute of Electrical and Electronic Engineers, as well as others for detailed explanation of software and hardware requirements. While these are useful, they are written for the electronics expert, and may be difficult for other professionals to use. This report is an attempt to describe those quality control procedures which and imwill help in developing plementing computer applications in blood banking. ELECTRONIC
DATA APPLICATIONS
Bar codes have wide application in blood collecting and processing operations, and have increasing application in transfusion services. In 1979, the American Blood Commission published final guidelines for the use of bar codes in blood bank operations. These guidelines established codaba? as the blood bank industry standard. Codabart is the name of a specific algorithm using a linear black and white bar code symbol for machine-readable labels. Other systems in wide industrial use include: universal product code (UPC) used in grocery optical character recognition stores, (OCR), and code.39. tTrademark Ohio.
of Monarch
Marking
Systems Inc., Dayton,
More recently, the health care industry recognized the need for standardization in the use of bar codes for interindustry electronic business data interchange. In order to obtain a unified position, the Health Industry Bar Code Council, later renamed the Health Industry Business Communications Council (HIBC), proceeded to establish the documentation, guidelines, and solicitation of input necessary to publish standards acceptable within the health care industry at large.4 In February 1987, they finalized and published these recommendations.5 HIBC selected several bar code symbologies for use by the health industry. Included were: UFC, national drug code (NDC), national health related items (NHRI), and EAN- 13 which is similar to UPC. Each of these symbols contain a check digit format, which adds a significant quality control check of the data being scanned. One reason for HIBC not selecting codabar was the lack of a check digit format. Although it has been suggested that codabar could be modified to recognize the last digit as a check digit using modulus 11, it has not been widely adopted.6 Bar codes are used as machine-readable labels which eliminate the need for manual data entry, thus eliminating the inherent miskeying associated with manual entry. However, the use of bar codes does not guarantee error-free data acquisition. A bar code reader can make substitution errors, that is substituting one valid data element for another valid but incorrect element.’ These substitution errors may be reproducible or nonreproducible, which makes corrective action difficult. Therefore, it should not be assumed that bar code read data is error free, and it should be verified before it is accepted into the data base. Verification of data can be accomplished by a number of different techniques; some are hardware specific. For example, laser readers require that three successful data readings must match exactly before the reading is accepted. Another, the check digit, is a mathema-
Quality Control for Computers in Blood Banks
tical scheme contained within the bar code which confirms that the intended data was correctly interpreted by the computer. An example of a check digit scheme is modulus 43 which is used with UPC. In this scheme, each allowable data element is given a numerical value. There are 42 possible data elements: 26 alpha characters, 10 numeric, and 6 special characters. The last data element in the bar code label is the check digit, and is determined by the data elements that precede it. For example, if the data elements in the bar code are ARC33, in modulus 43, each of those elements is converted to a numeric, A = 10, R = 27, C = 12,3 = 3. These numerical values are summed, 10+27+12+3+3=55. This sum is divided by 43, which results in a quotient of 1 with a remainder of 12. The remainder of 12 is converted to a data element. In this example, it would be an alpha character C. Therefore, the actual bar code label for this example is ARC33C. Each time that bar code label is read, the bar code interpreter device will calculate the check digit. If this calculated check digit does not agree with the label check digit, the data will be rejected. The other obvious method of verification is eye-readable data printed on the bar coded label. The machine-read data is verified with the eye-readable data by the operator. The data will not be accepted into the data base until the operator has verified the data. An alternative approach requires that specific data ranges be pre-allocated into the active computer data base. Data will be accepted only when related to a record in the active data base. An example of this would be an inventory list of products available for distribution in the data base. Each time a product was selected for distribution there would be a check that the bar code read number did exist in inventory. This would prevent phantom data from being entered into the data base. Not only does the quality control of computers relate to machine-readable
235
labels, but extends into the control of processing and interpreting test results, Clinical laboratory devices range from relatively simple temperature sensing devices to self-contained systems which: read bar code labels, dispense reagents, control incubation time and temperature, interpret test results, transmit data, and archive records. Even broader applications can be made for regional blood centers where multiple computer devices provide a system approach for the production, processing, labeling, and disposition of blood products. Applying this concept, smaller computer devices are networked to a “host” computer which is the central repository for all laboratory records. The FDA has taken a position that computer systems are medical devices when they are used in place of competent human intervention in the manufacture or processing of drugs or biologicals. If the computer is only used in a “library” function, merely an extension of manual record-keeping, it is exempt from FDA regulation. Since the potential of computers far exceeds the application as an automated “library” device, most computer applications in blood banking will be subject to the 1976 Medical Device Amendment to the Federal Food, Drug, and Cosmetic Act. WHAT IS A COMPUTER
DEVICE?
Computers are generally considered to consist of a hardware portion and a software portion. The hardware portion is the mechanical portion that executes instructions that are programed for it. Software is a set of instructions which are executed by hardware to accomplish specific objectives. There are several different types of software that can be described. There are silicon chips which have permanently embedded programs. These chips contain software that cannot be altered by the user. These chips sometimes are referred to as firmware, ROM (read-only memory) or PROM (programmable read only memory), and are subject to the FDA
236
Tmnsfus.
Sci.
Vol. 10, No. 3
standards for software development and testing. There are operating systems, which are programs supplied by the vendor, which are written in machine language. These systems are proprietary and maintained by the vendor. The user has no ability to alter or modify these codes. The most common software is the programmable, user defined, software. This is designed, written, and tested by an end user of the device for a specific application. This software is most vulnerable to corruption since it is subject to user modification and is written in computer languages, which are in the public domain, e.g. basic. The protection against unauthorized modification or change is through the use of secured password systems. SOFTWARE DEVELOPMENT Reliable computer applications for blood banks, start with good planning. In computer science this is called systems analysis and design. It makes good sense that this process should follow the scientific method which includes documentation of critical steps. Planning the design of the computer application whether it is a single application, or an entire manufacturing system, should be approached in the same way. The only difference will be the length of time spent on each step and the amount of documentation. The design team should be composed of both blood bank experts and computer design experts. The names and qualifications of these individuals should be recorded in the documentation of the design process. The functional objectives of the device should be described. This could be accomplished by listing userdefined requirements. These requirements must include all of the functional activities for the system. If the system is to record information, the document must state it. If it is to interpret, display, or transmit data, it should so state. Subsequent to the design phase, if any additional requirements are identified,
they should be added to the original user’s requirements, and an analysis performed as to the effect these changes will have on the design characteristics. After the software program has been written, the functions of the program should be compared to the user’s document to ensure that the program meets all requirements. If the program as written does not meet all requirements or if it exceeds the requirements, the user’s requirements should be re-evaluated and changes made, as indicated. The user’s requirements should accurately reflect the program that is produced. Once the functional characteristics have been described, the detail characteristics of each data field must be identified. The flow of data and the specific data manipulations described by each operation must be determined. This detail must be written down before the computer technical staff begin writing the coded programs. The need for documentation can be overlooked or thought to be a waste of time. However, it is most valuable to have this information when future revisions are needed, and the staff involved in original design are no longer available. The original design documents should include the reason for the selection of an approach to a specific function, so that future changes can be correlated to the original design criteria. After the system design is complete, technical design can occur. Technical design includes the lay-out of data files, number of files, index keys for data fields, security, data validity checks, along with other design considerations. During this activity, the efficiency of program execution will be considered in the design of the architecture of the program. The determination of sub-routines, loops, logical arrays, the use of table driven algorithms vs hard-coded logic, as well as many other technical design considerations will be decided. Not to be forgotten, one must also consider the ease of operation of the program by the user. Before this phase of the design can be completed, the original user expert
Quality Control for Computers in Blood Banks
should review and approve the functional activities of the program. The work to this point must meet the need of the user. If technical design requires the elimination of certain functions or a compromise of certain functions, these should be explained, and the design document modified to account for these changes.
CODING The actual work of coding programs does not have to be done by the person who performed the system analysis. Depending on the methodology used in designing the software and the size of the project, multiple programmers may be used. The use of multiple people will ensure that the concepts and objectives are clear, since they will be reviewed and understood by multiple people. Clear documentation will prove invaluable at a future date when modifications are required. Writing lines of code is a highly technical skill which does not have a single correct method. It is much like technical writing, and is subject to the skill and cleverness of the author. Programs written by less skilled programers may be cumbersome. These inefficient programs tax computer speed, slow down operational productivity, are subject to errors by virtue of the fact that more testing and validation needs to occur, and will increase overhead costs when maintenance is required. To assist programing staff in addressing this problem, there are special software programs that evaluate the efficiency of a program, and indicate where improvements can be made. In addition, these programs test that each branch or line of code is functional within the program. this is useful to detect nonfunctioning lines of code which should either be eliminated or rewritten. This type of quality control should be provided by programing staff before it is released to the user for functional testing.
TESTING
237
AND VALIDATION
Testing and validation of software programs should become an integral part of every blood bank’s quality control activity. This should occur whenever a new system is installed, after modifications, after hardware maintenance, and periodically even though no changes are made, to ensure continuity. Even if a totally self-contained device is installed by a vendor, there needs to be a test and validation in the user’s environment and for the user’s application. As is true for many of these self-contained devices, they are connected to a host computer. The test methodology used to perform the functional testing in a simulated environment should include: (1) Program name, including version number and revision date. PI Description of the software’s function. of the test (3) Detailed description design to validate that all critical functions are exercised, and indicate the expected response or result for each critical step in the program. (4) The software should be tested multiple times and the printout, screen prints, or any other documents that were used to evaluate the effectiveness of the software, should be saved. If errors are discovered, these must be corrected, retested, and documented. should be stress 15) The software tested by attempting to exceed its design capacity. For example, if a file’s maximum capacity is 4000 records, the test should include 4001 records, or if a non-numerical character is added to a field specified as a numerical field only, does the program reject the erroneous data. After the software has been tested in the simulated environment, the person who reviewed the test, usually the system manager or designer, should approve transfer to live mode for final testing.
238
Transfus. Sci.
Vol. 10, No. 3
Testing in the actual user’s environment can present a new set of problems, since every possible variable may not occur during live testing. These possible, rare events, should have been tested in the simulated environment. The principle objective of the live test is to trace critical data elements, such as known control values, from the beginning or entry into the program to the final result or output. There must be a set of known values, either known samples to be tested, or a prepared test data base, which can operate in the real environment. If there are data transmission requirements, these must be tested as well. For blood bank systems, this testing should follow original test values, as they are processed and transferred through the various programs to final archiving. These results should be printed and saved as validation documentation. At this time validation should include security checks for hardware failure, loss of power, or breaks in communication links, and recovery from these untoward events. Once again, all testing activities should be documented, and the user should sign approval of the validation before the program is released for use. IMPLEMENTATION After the system has been validated, the users must be trained in the use of the software. There must be written instructions as to the program name, purpose of the software, version, and revision date. The user should be instructed in the proper use of the software, the possible error messages that might indicate a problem, and the method of preventing unauthorized access to data. Users must be informed as to the need for security. They should be informed not to write passwords or other security instructions near the key board. A current standard operating procedure should be available for the user as a reference. As is usual, documentation of the training is required.
VENDOR SUPPLIED COMPUTER SYSTEMS If a device can be purchased from a vendor that meets the exact requirements, the user’s validation testing may be less rigorous. The vendor should have on file all of the documentation prescribed for software development. Also, the vendor should have validated the programs in a simulated environment. If the application of the user is for more than a “library” function, the device is treated as a medical device, and requires FDA approval before being placed in use. The vendor may have already obtained the necessary FDA approval. However, the user may have to amend their FDA license on file with the FDA to indicate that this device is being placed in use at that location. As an example, consider a new automated blood grouping device which has received pre-market approval by the FDA as a medical device that can be sold. The user must still submit data to the FDA in support of the specific intended use at the licensed facility. For a new automated blood grouping device, for example, the application would specify if the Du test would be performed by the device. Assuming that the vendor’s device has received approval, it still requires validation testing in the user’s environment. The validation procedure should be provided by the vendor. This validation procedure should include the program name, version, and revision date. The test plan should include either known samples or a test program with test data supplied. The vendor should also review the results with the user, and agree that the device is functioning according to specifications before the device is placed in on-line operations. If the vendor supplies software that has been customized for the user, such as data transmission to a host computer, the design and testing should follow as described for software development.
Quality Control for Computers in Blood Banks
MODIFICATIONS
TO SOFTWARE
From time to time modifications to software will be necessary. If the vendor supplies a new software release, the vendor should also supply the validation protocol for the user. The user needs to include revalidation of all local modifications or interfacing made to the previous release, when the vendor supplies a new software version. Modification of locally developed software will require the same documentation as the original system analysis. Common sense will dictate when changes are extensive, and require that a new version be created. Any modification requires documentation and testing before release into the production environment, since any modification can create a problem in another area of the program. During the replacement of a line of code, there should be documentation of the date, and initials of the person who changed the code. For software used as a medical device, the obsolete software should be maintained in an archive. This will permit the chronological reconstruction of the exact processing criteria used during specific time periods. In any copies of outdated programs event, should not be discarded. The extent of revalidation required after a modification has been made should be determined by a computer programing expert. It is possible for small changes in one part of the program to have a significant and negative effect on another, possibly unrelated area. However, it is not useful to perform an entire system validation for every modification. Before the modification is released to the production environment, the results of validation should be reviewed and approved. HARDWARE CHANGE MAINTENANCE
OR
Whenever hardware or parts of hardware, such as electronic circuit boards, are replaced, the system should be validated
239
and documentation made of the acceptable test results. This should also occur after any maintenance. Whenever possible, replacement hardware should be operated in parallel with existing equipment in the operating environment during validation testing. The data from each device can then be compared under identical operating conditions. ROUTINE
QUALITY
CONTROL
In situations where no changes have occurred in either software or hardware, there should be regular quality control checks to test performance. One method is to maintain an error report log. This is simply a list of operator detected problems and their corrective action. This log should be reviewed periodically by a manager familiar with the software to determine the cause of the problems, and if the actions taken were correct. When a system is complex with many subsystems and interconnections between equipment, there should be a planned tracking of randomly selected test data through the system. For example, in a blood center where blood samples are tested on several devices, blood records are component production merged with testing records to provide computer-controlled labeling and release, and products are tracked to a user facility. A frequent check employing the tracking of a single donor sample from the beginning of processing to the disposition of the products would provide a reasonable check. The concept used would be to select a donor’s identification number on the day of collection, and for every subsequent day, check the progress of that donation through the system. The record should be observed to verify that events were happening in the prescribed manner, and that the systems were working as described by protocol. Again, this activity should be documented; any deviations should be noted and reviewed by the manager of the system.s From this quality control activity, patterns may emerge of system design
240
Transfis.
Sci.
Vol. 10, No. 3
weaknesses which will require corrective action, in turn, creating requests for software modifications, and beginning the cycle again.
tiveness of blood components, there will be expanded discussion of a need for more control of software and computers. REFERENCES
CONCLUSION The evolution of machines in the laboratory has advanced from mechanization of manual technic to full automation with the test tube being placed on one end of the machine and the results being transmitted to the host computer for integration into a product release processing system. This has been termed, “tube in/test out” technology. In the blood center of today, multiple testing devices can perform virtually all required blood donor testing, maintain blood component production records by the use of bar code readable labels, and accommodate distribution functions. It is through these systems that blood centers can succeed in an environment of fewer technically trained staff. However, as the computer potential of logical control and interpretation of critical steps in the production and release environment is expanded, the need for well planned and documented software design is essential for safe and effective blood component production. As regulating and inspecting agencies realize the significance of computer operations for the safety and effec-
1.
Burtis CA, Painter PC: Analytical systems for the clinical
laboratory.
Am Clin Lab
1989; 8:14-19. 2. U.S. Department of Health and Human Services, Food and Drug Administration, Technical Report: Software Development Activities, July, 1987 (obtained under the freedom of information act). 3. Guidelines for the Uniform Labeling of Blood and Blood Components: Arlington,
VA, The American Blood Commission, August, 1985. 4. Health Industry Business Communications Council: The Health Industry Bar 5.
6.
7.
8.
Code (HIBC) Supplier Labeling Standard, Phoenix, AZ, 1988. Health Industry Business Communications Council: The Electronic Data Znterchange Guidelines Manual, Phoenix, AZ, 1988, pp. 2-3. Wagstaff W: Automation in donor blood processing, in Greenwalt TJ (ed.): Methods in Hematology: Blood Transfusion, vol. 17. New York, Churchill Livingston, 1988, p. 36. Brodheim E, Ying W, Hirsch RL: An evaluation of the CODABAR symbol in blood-banking automation. VOX Sang 1981; 40:175-180. Weinberg S, Weinberg Associates Inc., personal communication.
Quality
09553886/89 $3.00+0.00 Copyright @ 1989 Pergamon Press plc
Control for Computers in Blood Banks Stanley C. Roberts, MA, SBB(ASCP)
n This is a report on the current quality control applications that may be applied to computer systems used in blood bank operations. The concepts and principals described have been used in the design of complete regional blood center computer operations but can also be applied to single use applications. The computer offers the opportunity to increase not only the quantity of work performed but it can also improve the accuracy. Before computers or software are used in the blood bank setting, however, there must be sufficient documentation of the design, testing, and validation to ensure that it is functioning according to specification. This report will describe some of the planning and methods used to accomplish this goal. n
a new technique or application. This has also been true for computer applications in the blood bank. Analytical systems have evolved in clinical laboratories from the manual systems of the early 20th century to mechanization in the 195Os, and to full automation and computer controls in the 1970s and 80s.’ It is not surprising that computers have become integrated into routine blood bank operations. For purposes of this discussion, a computer will be defined as an electronic device which either measures, records, or maintains critical data for blood bank operations, There are many examples where computers are used which may not be obvious. Two examples are the maintenance of donor or patient records with previous laboratory data, and automated equipment producing new test results. No one would disagree with the utility of computers in the blood bank, but as yet, the usual rule-making groups have not universally applied other agencies’ guidelines or industrial standards to blood bank applications. The computer offers blood banks the promise of precise and current record keeping with rapid data acquisition and storage. However, the real potential of computers is achieved only when the computer is to interpret and control critical steps in the blood bank operations. These steps would ultimately lead to the decision to transfuse a product, or more important, to discard a product that could transmit disease. Some people be-
INTRODUCTION
Blood bank operations have always required careful and well defined controls and procedures. This is usually accomplished by publishing rules, guidelines, and standards. These are written and published by several inspection agencies and organizations, e.g. the FDA, the American Association of Blood Banks, the College of the American Pathologists, and the American Red Cross. The process of writing guidelines and standards usually follows the introduction of FromtheAmerican Red Cross Blood Services, Connecticut Region, 209 Fannington Avenue, Farmington, CT 06032. 1911, U.S.A. 233
234
Tronsfus. Sci.
Vol. 10, No. 3
lieve that if a complete set of steps or a decision tree could be written, then it should be possible to program a computer to execute those logical decision paths. The benefit of such a program would be consistent and correct results accomplished through a mechanical device without the need of human intervention. The challenge, which is an issue for blood banking, is to define those rules, guidelines, and standards which will ensure that a consistent outcome is achieved when using a computer. The FDA has published a technical report on software development activities2 which describes the documentation needed when software is placed in use as a medical device. The FDA refers users to industrial standards and procedures published by the American National Standard Institute and the Institute of Electrical and Electronic Engineers, as well as others for detailed explanation of software and hardware requirements. While these are useful, they are written for the electronics expert, and may be difficult for other professionals to use. This report is an attempt to describe those quality control procedures which and imwill help in developing plementing computer applications in blood banking. ELECTRONIC
DATA APPLICATIONS
Bar codes have wide application in blood collecting and processing operations, and have increasing application in transfusion services. In 1979, the American Blood Commission published final guidelines for the use of bar codes in blood bank operations. These guidelines established codaba? as the blood bank industry standard. Codabart is the name of a specific algorithm using a linear black and white bar code symbol for machine-readable labels. Other systems in wide industrial use include: universal product code (UPC) used in grocery optical character recognition stores, (OCR), and code.39. tTrademark Ohio.
of Monarch
Marking
Systems Inc., Dayton,
More recently, the health care industry recognized the need for standardization in the use of bar codes for interindustry electronic business data interchange. In order to obtain a unified position, the Health Industry Bar Code Council, later renamed the Health Industry Business Communications Council (HIBC), proceeded to establish the documentation, guidelines, and solicitation of input necessary to publish standards acceptable within the health care industry at large.4 In February 1987, they finalized and published these recommendations.5 HIBC selected several bar code symbologies for use by the health industry. Included were: UFC, national drug code (NDC), national health related items (NHRI), and EAN- 13 which is similar to UPC. Each of these symbols contain a check digit format, which adds a significant quality control check of the data being scanned. One reason for HIBC not selecting codabar was the lack of a check digit format. Although it has been suggested that codabar could be modified to recognize the last digit as a check digit using modulus 11, it has not been widely adopted.6 Bar codes are used as machine-readable labels which eliminate the need for manual data entry, thus eliminating the inherent miskeying associated with manual entry. However, the use of bar codes does not guarantee error-free data acquisition. A bar code reader can make substitution errors, that is substituting one valid data element for another valid but incorrect element.’ These substitution errors may be reproducible or nonreproducible, which makes corrective action difficult. Therefore, it should not be assumed that bar code read data is error free, and it should be verified before it is accepted into the data base. Verification of data can be accomplished by a number of different techniques; some are hardware specific. For example, laser readers require that three successful data readings must match exactly before the reading is accepted. Another, the check digit, is a mathema-
Quality Control for Computers in Blood Banks
tical scheme contained within the bar code which confirms that the intended data was correctly interpreted by the computer. An example of a check digit scheme is modulus 43 which is used with UPC. In this scheme, each allowable data element is given a numerical value. There are 42 possible data elements: 26 alpha characters, 10 numeric, and 6 special characters. The last data element in the bar code label is the check digit, and is determined by the data elements that precede it. For example, if the data elements in the bar code are ARC33, in modulus 43, each of those elements is converted to a numeric, A = 10, R = 27, C = 12,3 = 3. These numerical values are summed, 10+27+12+3+3=55. This sum is divided by 43, which results in a quotient of 1 with a remainder of 12. The remainder of 12 is converted to a data element. In this example, it would be an alpha character C. Therefore, the actual bar code label for this example is ARC33C. Each time that bar code label is read, the bar code interpreter device will calculate the check digit. If this calculated check digit does not agree with the label check digit, the data will be rejected. The other obvious method of verification is eye-readable data printed on the bar coded label. The machine-read data is verified with the eye-readable data by the operator. The data will not be accepted into the data base until the operator has verified the data. An alternative approach requires that specific data ranges be pre-allocated into the active computer data base. Data will be accepted only when related to a record in the active data base. An example of this would be an inventory list of products available for distribution in the data base. Each time a product was selected for distribution there would be a check that the bar code read number did exist in inventory. This would prevent phantom data from being entered into the data base. Not only does the quality control of computers relate to machine-readable
235
labels, but extends into the control of processing and interpreting test results, Clinical laboratory devices range from relatively simple temperature sensing devices to self-contained systems which: read bar code labels, dispense reagents, control incubation time and temperature, interpret test results, transmit data, and archive records. Even broader applications can be made for regional blood centers where multiple computer devices provide a system approach for the production, processing, labeling, and disposition of blood products. Applying this concept, smaller computer devices are networked to a “host” computer which is the central repository for all laboratory records. The FDA has taken a position that computer systems are medical devices when they are used in place of competent human intervention in the manufacture or processing of drugs or biologicals. If the computer is only used in a “library” function, merely an extension of manual record-keeping, it is exempt from FDA regulation. Since the potential of computers far exceeds the application as an automated “library” device, most computer applications in blood banking will be subject to the 1976 Medical Device Amendment to the Federal Food, Drug, and Cosmetic Act. WHAT IS A COMPUTER
DEVICE?
Computers are generally considered to consist of a hardware portion and a software portion. The hardware portion is the mechanical portion that executes instructions that are programed for it. Software is a set of instructions which are executed by hardware to accomplish specific objectives. There are several different types of software that can be described. There are silicon chips which have permanently embedded programs. These chips contain software that cannot be altered by the user. These chips sometimes are referred to as firmware, ROM (read-only memory) or PROM (programmable read only memory), and are subject to the FDA
236
Tmnsfus.
Sci.
Vol. 10, No. 3
standards for software development and testing. There are operating systems, which are programs supplied by the vendor, which are written in machine language. These systems are proprietary and maintained by the vendor. The user has no ability to alter or modify these codes. The most common software is the programmable, user defined, software. This is designed, written, and tested by an end user of the device for a specific application. This software is most vulnerable to corruption since it is subject to user modification and is written in computer languages, which are in the public domain, e.g. basic. The protection against unauthorized modification or change is through the use of secured password systems. SOFTWARE DEVELOPMENT Reliable computer applications for blood banks, start with good planning. In computer science this is called systems analysis and design. It makes good sense that this process should follow the scientific method which includes documentation of critical steps. Planning the design of the computer application whether it is a single application, or an entire manufacturing system, should be approached in the same way. The only difference will be the length of time spent on each step and the amount of documentation. The design team should be composed of both blood bank experts and computer design experts. The names and qualifications of these individuals should be recorded in the documentation of the design process. The functional objectives of the device should be described. This could be accomplished by listing userdefined requirements. These requirements must include all of the functional activities for the system. If the system is to record information, the document must state it. If it is to interpret, display, or transmit data, it should so state. Subsequent to the design phase, if any additional requirements are identified,
they should be added to the original user’s requirements, and an analysis performed as to the effect these changes will have on the design characteristics. After the software program has been written, the functions of the program should be compared to the user’s document to ensure that the program meets all requirements. If the program as written does not meet all requirements or if it exceeds the requirements, the user’s requirements should be re-evaluated and changes made, as indicated. The user’s requirements should accurately reflect the program that is produced. Once the functional characteristics have been described, the detail characteristics of each data field must be identified. The flow of data and the specific data manipulations described by each operation must be determined. This detail must be written down before the computer technical staff begin writing the coded programs. The need for documentation can be overlooked or thought to be a waste of time. However, it is most valuable to have this information when future revisions are needed, and the staff involved in original design are no longer available. The original design documents should include the reason for the selection of an approach to a specific function, so that future changes can be correlated to the original design criteria. After the system design is complete, technical design can occur. Technical design includes the lay-out of data files, number of files, index keys for data fields, security, data validity checks, along with other design considerations. During this activity, the efficiency of program execution will be considered in the design of the architecture of the program. The determination of sub-routines, loops, logical arrays, the use of table driven algorithms vs hard-coded logic, as well as many other technical design considerations will be decided. Not to be forgotten, one must also consider the ease of operation of the program by the user. Before this phase of the design can be completed, the original user expert
Quality Control for Computers in Blood Banks
should review and approve the functional activities of the program. The work to this point must meet the need of the user. If technical design requires the elimination of certain functions or a compromise of certain functions, these should be explained, and the design document modified to account for these changes.
CODING The actual work of coding programs does not have to be done by the person who performed the system analysis. Depending on the methodology used in designing the software and the size of the project, multiple programmers may be used. The use of multiple people will ensure that the concepts and objectives are clear, since they will be reviewed and understood by multiple people. Clear documentation will prove invaluable at a future date when modifications are required. Writing lines of code is a highly technical skill which does not have a single correct method. It is much like technical writing, and is subject to the skill and cleverness of the author. Programs written by less skilled programers may be cumbersome. These inefficient programs tax computer speed, slow down operational productivity, are subject to errors by virtue of the fact that more testing and validation needs to occur, and will increase overhead costs when maintenance is required. To assist programing staff in addressing this problem, there are special software programs that evaluate the efficiency of a program, and indicate where improvements can be made. In addition, these programs test that each branch or line of code is functional within the program. this is useful to detect nonfunctioning lines of code which should either be eliminated or rewritten. This type of quality control should be provided by programing staff before it is released to the user for functional testing.
TESTING
237
AND VALIDATION
Testing and validation of software programs should become an integral part of every blood bank’s quality control activity. This should occur whenever a new system is installed, after modifications, after hardware maintenance, and periodically even though no changes are made, to ensure continuity. Even if a totally self-contained device is installed by a vendor, there needs to be a test and validation in the user’s environment and for the user’s application. As is true for many of these self-contained devices, they are connected to a host computer. The test methodology used to perform the functional testing in a simulated environment should include: (1) Program name, including version number and revision date. PI Description of the software’s function. of the test (3) Detailed description design to validate that all critical functions are exercised, and indicate the expected response or result for each critical step in the program. (4) The software should be tested multiple times and the printout, screen prints, or any other documents that were used to evaluate the effectiveness of the software, should be saved. If errors are discovered, these must be corrected, retested, and documented. should be stress 15) The software tested by attempting to exceed its design capacity. For example, if a file’s maximum capacity is 4000 records, the test should include 4001 records, or if a non-numerical character is added to a field specified as a numerical field only, does the program reject the erroneous data. After the software has been tested in the simulated environment, the person who reviewed the test, usually the system manager or designer, should approve transfer to live mode for final testing.
238
Transfus. Sci.
Vol. 10, No. 3
Testing in the actual user’s environment can present a new set of problems, since every possible variable may not occur during live testing. These possible, rare events, should have been tested in the simulated environment. The principle objective of the live test is to trace critical data elements, such as known control values, from the beginning or entry into the program to the final result or output. There must be a set of known values, either known samples to be tested, or a prepared test data base, which can operate in the real environment. If there are data transmission requirements, these must be tested as well. For blood bank systems, this testing should follow original test values, as they are processed and transferred through the various programs to final archiving. These results should be printed and saved as validation documentation. At this time validation should include security checks for hardware failure, loss of power, or breaks in communication links, and recovery from these untoward events. Once again, all testing activities should be documented, and the user should sign approval of the validation before the program is released for use. IMPLEMENTATION After the system has been validated, the users must be trained in the use of the software. There must be written instructions as to the program name, purpose of the software, version, and revision date. The user should be instructed in the proper use of the software, the possible error messages that might indicate a problem, and the method of preventing unauthorized access to data. Users must be informed as to the need for security. They should be informed not to write passwords or other security instructions near the key board. A current standard operating procedure should be available for the user as a reference. As is usual, documentation of the training is required.
VENDOR SUPPLIED COMPUTER SYSTEMS If a device can be purchased from a vendor that meets the exact requirements, the user’s validation testing may be less rigorous. The vendor should have on file all of the documentation prescribed for software development. Also, the vendor should have validated the programs in a simulated environment. If the application of the user is for more than a “library” function, the device is treated as a medical device, and requires FDA approval before being placed in use. The vendor may have already obtained the necessary FDA approval. However, the user may have to amend their FDA license on file with the FDA to indicate that this device is being placed in use at that location. As an example, consider a new automated blood grouping device which has received pre-market approval by the FDA as a medical device that can be sold. The user must still submit data to the FDA in support of the specific intended use at the licensed facility. For a new automated blood grouping device, for example, the application would specify if the Du test would be performed by the device. Assuming that the vendor’s device has received approval, it still requires validation testing in the user’s environment. The validation procedure should be provided by the vendor. This validation procedure should include the program name, version, and revision date. The test plan should include either known samples or a test program with test data supplied. The vendor should also review the results with the user, and agree that the device is functioning according to specifications before the device is placed in on-line operations. If the vendor supplies software that has been customized for the user, such as data transmission to a host computer, the design and testing should follow as described for software development.
Quality Control for Computers in Blood Banks
MODIFICATIONS
TO SOFTWARE
From time to time modifications to software will be necessary. If the vendor supplies a new software release, the vendor should also supply the validation protocol for the user. The user needs to include revalidation of all local modifications or interfacing made to the previous release, when the vendor supplies a new software version. Modification of locally developed software will require the same documentation as the original system analysis. Common sense will dictate when changes are extensive, and require that a new version be created. Any modification requires documentation and testing before release into the production environment, since any modification can create a problem in another area of the program. During the replacement of a line of code, there should be documentation of the date, and initials of the person who changed the code. For software used as a medical device, the obsolete software should be maintained in an archive. This will permit the chronological reconstruction of the exact processing criteria used during specific time periods. In any copies of outdated programs event, should not be discarded. The extent of revalidation required after a modification has been made should be determined by a computer programing expert. It is possible for small changes in one part of the program to have a significant and negative effect on another, possibly unrelated area. However, it is not useful to perform an entire system validation for every modification. Before the modification is released to the production environment, the results of validation should be reviewed and approved. HARDWARE CHANGE MAINTENANCE
OR
Whenever hardware or parts of hardware, such as electronic circuit boards, are replaced, the system should be validated
239
and documentation made of the acceptable test results. This should also occur after any maintenance. Whenever possible, replacement hardware should be operated in parallel with existing equipment in the operating environment during validation testing. The data from each device can then be compared under identical operating conditions. ROUTINE
QUALITY
CONTROL
In situations where no changes have occurred in either software or hardware, there should be regular quality control checks to test performance. One method is to maintain an error report log. This is simply a list of operator detected problems and their corrective action. This log should be reviewed periodically by a manager familiar with the software to determine the cause of the problems, and if the actions taken were correct. When a system is complex with many subsystems and interconnections between equipment, there should be a planned tracking of randomly selected test data through the system. For example, in a blood center where blood samples are tested on several devices, blood records are component production merged with testing records to provide computer-controlled labeling and release, and products are tracked to a user facility. A frequent check employing the tracking of a single donor sample from the beginning of processing to the disposition of the products would provide a reasonable check. The concept used would be to select a donor’s identification number on the day of collection, and for every subsequent day, check the progress of that donation through the system. The record should be observed to verify that events were happening in the prescribed manner, and that the systems were working as described by protocol. Again, this activity should be documented; any deviations should be noted and reviewed by the manager of the system.s From this quality control activity, patterns may emerge of system design
240
Transfis.
Sci.
Vol. 10, No. 3
weaknesses which will require corrective action, in turn, creating requests for software modifications, and beginning the cycle again.
tiveness of blood components, there will be expanded discussion of a need for more control of software and computers. REFERENCES
CONCLUSION The evolution of machines in the laboratory has advanced from mechanization of manual technic to full automation with the test tube being placed on one end of the machine and the results being transmitted to the host computer for integration into a product release processing system. This has been termed, “tube in/test out” technology. In the blood center of today, multiple testing devices can perform virtually all required blood donor testing, maintain blood component production records by the use of bar code readable labels, and accommodate distribution functions. It is through these systems that blood centers can succeed in an environment of fewer technically trained staff. However, as the computer potential of logical control and interpretation of critical steps in the production and release environment is expanded, the need for well planned and documented software design is essential for safe and effective blood component production. As regulating and inspecting agencies realize the significance of computer operations for the safety and effec-
1.
Burtis CA, Painter PC: Analytical systems for the clinical
laboratory.
Am Clin Lab
1989; 8:14-19. 2. U.S. Department of Health and Human Services, Food and Drug Administration, Technical Report: Software Development Activities, July, 1987 (obtained under the freedom of information act). 3. Guidelines for the Uniform Labeling of Blood and Blood Components: Arlington,
VA, The American Blood Commission, August, 1985. 4. Health Industry Business Communications Council: The Health Industry Bar 5.
6.
7.
8.
Code (HIBC) Supplier Labeling Standard, Phoenix, AZ, 1988. Health Industry Business Communications Council: The Electronic Data Znterchange Guidelines Manual, Phoenix, AZ, 1988, pp. 2-3. Wagstaff W: Automation in donor blood processing, in Greenwalt TJ (ed.): Methods in Hematology: Blood Transfusion, vol. 17. New York, Churchill Livingston, 1988, p. 36. Brodheim E, Ying W, Hirsch RL: An evaluation of the CODABAR symbol in blood-banking automation. VOX Sang 1981; 40:175-180. Weinberg S, Weinberg Associates Inc., personal communication.