BLOOD PROCESSING SYSTEM

Abstract: A computer system for controlling the dispensing of blood to a patient comprising a first data entry means for entering first patient record details including blood group and antibody screening details for the patient; second data entry means for entering second patient record details for the patient the computer system cross-checking the second patient record details against portions of the first patient record details the computer system determining a group of compatible blood packs for the patient from available blood stocks; third data entry means for entering details of a proposed compatible blood pack from the available blood stocks; and authorisation output means outputting an authorisation when the proposed compatible blood pack is one of the group of compatible blood packs as determined by the computer system. A computer system as claimed in claim 1 wherein the first data entry means is remote from the second data entry means.

Description: Blood Processing System Field of the Invention The present invention relates to the identification, storage and dispensing of blood and blood products to patients requiring blood transfusions. Background of the Invention In hospital procedures, it is often necessary for a patient to receive a blood transfusion as part of an operation or the like. The need to ensure that a patient receives a compatible type blood is of great importance, with the consequence of receiving incompatible blood including possible fatality. For a full discussion of likely blood transfusion errors which can occur in practice, reference is made to "A Report of 104 Transfusion Errors in New York State" by J V Linden, B Paul, and K P Dressier, published in Transfusion, Volume 32, No. 7, pages 601-606. This journal article reports that error rates for blood transfusions can occur in modern societies at approximately the rate of 1 error per 12,000 transfusions. It has been further found in practice that doctors, not wishing to be caught short in their blood supply, often choose to over order blood supply stocks so that blood is always on hand in case of emergencies, especially in casualty wards. This has lead to high levels of wastage or spoilage in that excessive supply is required to satisfy demands which may not be realised and depend substantially on chance. Further, with prior art blood dispensing systems, excessive amounts of clerical processing are normally required in addition to high levels of skill required in dealing with blood and knowing what blood types and tests must be carried out before blood can be made available for transfusion. SUBSTTTUTE SHEET(Rule26) Summary of the Invention It is an object of the present invention to provide an improved method for handling blood which is amenable to a reduction in the likelihood of transfusion errors and to allow for a system which results in a reduction m our blood wastage due to the leviation of storage requirements and also provides for an automated system allowing for persons with lower levels of professional training to handle blood and its dispensing. In accordance with an aspect of the present invention there is provided a computer system for controlling the dispensing of blood to a patient comprising: first data entry means for entering first patient record details including blood group and antibody screening details for said patient; second data entry means for entering second patient record details for said patient; said computer system cross-checking said second patient record details against portions of said first patient record details; said computer system determining a set of compatible blood packs for said patient from available blood stocks; third data entry means for entering details of a proposed compatible blood pack from said available blood stocks; and authorisation output means outputting an authorisation when said proposed compatible blood pack is one of said set of compatible blood packs as determined by said computer system. Preferably the blood group and antibody screening details can be obtained from testing a sample of the patient's blood and entering them in the first data entry means. Further, the authorisation can comprise printing out adhesive labels for the blood pack and, in an extra step the full details of the blood pack may be re-entered into - - the computer system at a later stage, for example, before dispensing. Of course, the system can be comprised from multiple computers interconnected in a predetermined manner by means of a network or the like. Both the test results of the patient and the blood products themselves can be time stamped and the computer system can take this into account in refusing to issue any authorisations when certain predetermined time periods have expired. Further, a patient's history can be "built up" and each time transfusion is to occur, this history can be examined to check for any anomalies. The system of the preferred embodiment has the significant advantage that blood release is completely controlled by a computer system. Hence, the preferred embodiment does not need to rely on intervention by laboratory staff during the blood release to ensure pre- transfusion requirements are met. In the preferred embodiment, the computer system performs all the checking functions and subsequently matches and selects the compatible pack(s) of blood from an inventory. This allows the preferred embodiment to operate away from the laboratory environment and to be used by non-laboratory hospital staff at remote hospitals interconnected into the computer system of the preferred embodiment. Brief Description of the Drawings Notwithstanding any other forms which may fall within the scope of the present invention, preferred forms of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Fig. 1 illustrates the process of a first embodiment in testing a blood transfusion sample; and Figs 2 illustrates a flow-chart for determining whether transfusion blood should be released by the first embodiment. Fig. 3 illustrates the interaction of computer systems when utilised by a user to dispense blood; and Fig. 4 illustrates a flow chart for establishing a EBRS record; and Fig. 5 illustrates a flow chart for the release of blood in accordance with the second embodiment. Description of the Preferred and Other Embodiments In the preferred embodiment, reliance is placed on the integration of parts of the blood transfusion process within a computer system to extensively monitor the process to detect possible errors. It is assumed that the preferred embodiment is to run in an environment in which donated blood for transfusion has been analysed and categorised by blood group and antibody screening with the details being stored on a blood bank computer system and the details of which can be accessed by the preferred embodiment. Further, blood stocks have been delivered to hospital in accordance with expected needs and the level of stocks has been recorded. The method of the preferred embodiment can be divided into two main parts, the first part comprises the testing of a patient's blood to determine its blood group and antibody screening properties. The second part comprises determining blood which should be released to the patient when transfusion blood is needed. Referring to Fig. 1, there is illustrated the steps involved in the transfusion testing part of the preferred embodiment. In a first step 2 a blood sample, taken from a patient, is received along with the patient details. The patient details include the patient's name, birth date, hospital from which the blood is received, and a unique medical record number (MRN) for the patient to which uniquely identifies the patient. The sample is tested 3 at the receiving pathology laboratory to determine the sample's blood group (G) in addition to performing an antibody screening of the blood (S) . The results of the testing process are first entered 4 into the computer system of the main pathology laboratory. These results are entered without any checks being performed against previous results. Details entered include a lab identification number, a patent's medical record number (MRN), the hospital, name, patient birth date and the blood group and antibody screening results. Secondly, the details are entered in a separate register 6 which is separate from the storage of details 4. In the register 6, the sample's lab number and the patient's name are utilised to identify the sample. After entry, this information is compared against the information stored in step 4. A further register is maintained of all patient's antibody details. Each time a patient's sample is entered, the antibody register is firstly checked to see if a discrepancy exists and secondly the patient's antibody details are updated. If a discrepancy exists, the process terminates with a relevant notification to the user. Next, the patient's blood group results are again entered at step 6. The entry must be a valid blood group code and the entered blood group code is then validated against all samples previously received for the same patient which had been previously stored in the main laboratory computer system 4 or have been stored in the patient antibody register. Again, any inconsistencies result in termination of the method 1 with an appropriate notice. The antibody screening results S are then entered 6 and checked against all previous records 4 for the same patient in addition to the patient antibody register. Any results that indicate an antibody has been detected, again results in program termination with an appropriate message. SU BSXΓΠΠB SHBBΓ (Rm e 26) If no inconsistencies are found, an Electronic Blood Release System (EBRS) record is created 7 which has a time out value of between either 3 to 14 days over which it will remain valid, with the validity period being determined depending on the transfusion history of the patient, including the patient's blood group and antibody screening results. This record is then stored on the main laboratory system for access at a later date. Referring now to Figs. 2 and 3 there will now be explained the preferred method of releasing blood at a remote station, such as a hospital or the like. To this end, it is assumed that the hospital's computer system is connected to the main laboratory computer system and able to exchange information therewith. In Fig. 3, there is illustrated one possible arrangement of computers of the preferred embodiment. In this arrangement, a user's computer 30, within a hospital environment is interconnected to the aforementioned main laboratory computer system 31, the hospital's computer system 32 and the blood bank's computer system 33 which contains records of blood donors and blood types. Referring to Fig. 2, access to the transfusion blood release system begins by utilising a password 21 to access the system running on computer system 30 (Fig. 3) . Preferably, a high level of security is provided by allowing for multiple passwords before access is achieved. Next, the computer informs the user to enter the required patient's full name, hospital identifier and the date of birth. This data entry is validated by checking for the corresponding EBRS record (7 of fig. 1) located on the main laboratory computer system 31 (Fig. 3), as well as checking the stored details of the results sample 4 and cross-checking against the information which may be available on the hospital's master patient index located on the hospital computer system 33 (Fig. 3) . Thirdly, the blood bank computer system records 33 are searched to - - ensure that no antibodies exist for the person needing the transfusion. If there are any abnormalities or errors, the transfusion blood release system 20 is designed to terminate after reporting any error. As noted previously, the EBRS record is examined to determine if the record is still valid. If a valid record is found, a list of compatible blood pack numbers are determined 24 from those blood packs which are available at the remote site. It is assumed that the blood packs have been pretested and categorised as is the normal procedure for handling donated blood. The user is instructed to choose one of the compatible blood packs. Importantly, the system only displays blood packs that are in date, and have a blood group as previously verified by the dispensing blood laboratory. Next, the user is instructed to enter a donation number previously printed on the selected blood pack in addition to the blood group barcodes on the selected pack. For convenience and accuracy, the information can be entered by means of bar codes or the like. This information is then checked to determine if it is correct and a matching label is printed. After affixing the label to the blood pack 26, the user is instructed to rescan all the blood pack package details. The system again checks that the blood pack is ABO compatible with the EBRS record of the patient. Upon confirmation, a release label 28 is printed for attachment to the patient's notes as a record of the blood transfusion release and the blood is available for us. Additionally, the laboratory computer system is updated to reflect the blood presently available at the local hospital system. This information can be utilised by the laboratory computer system producing warnings when stocks are running below minimum level and to advise on the necessity for further deliveries. Turning now to Fig. 4 and Fig. 5, there will now be described a further, slightly modified embodiment of the present invention. In this embodiment ABO and Rh(D) typing 40 of patients is performed using anti-A, anti-B and anti-D reagents. Serum typing is performed with Al and B cells against a 2 drop serum tube test. The antibody screening test is performed by a standard tube technique consisting of a ten minute, direct agglutination test at 37°C and a Low ionic strength solution indirect antiglobulm test (LISS-IAT) against a three cell sample screening panel. A second technologist independently 41 determines the patients blood type and enters the patient information and blood type result into the computer. The program validates the current and any historical data. Any discrepancies are flagged for resolution. The program creates a valid EBRS patient record 42 if i) a second blood type has been performed ii) current and historical 44 patient identification and blood type results match 46 and iii) there is no current or historical record of unexpected red cell antibodies 45. A full IAT crossmatch is performed for patients with red cell antibodies and an ISX is performed when no second technologist is immediately available to perform a check of the ABO and Rh(D) type. The EBRS patient record expires after 72 hours if the patient has been transfused within 3 months or is pregnant, otherwise a 14 day expiry applies. In Fig. 5, there is illustrated 50 the process of releasing blood in accordance with the second embodiment. Access to the EBRS programs requires dual passwords 51. The computer informs the user to enter 52 the patient's full name, unique hospital number and date of birth. This entry is validated by the laboratory information system, the EBRS database and the Hospital patient information database. For a remote-site user, the programs searches 53 for a valid blood type and the results of the antibody screen. If the antibody screen is negative a list of compatible RBC unit numbers available at the remote site is displayed 54. The user is instructed to scan the donor unit identifying number and blood type barcodes of the selected unit and if valid, a label is printed. After fixing the label to the unit, the user is instructed to confirm 55 the unit selection by again scanning the unit details. If confirmed, a second label is printed for completion by the medical staff at the time of transfusion for inclusion m the patient's medical record. Immediate electronic mail messages are sent to the central laboratory indicating the release details and to warn the central laboratory when stocks are falling below minimum levels. By utilising the aforementioned procedures, the likelihood of blood transfusion errors is substantially reduced, thereby resulting in a safer blood processing system. Further, when utilising a system in accordance with the preferred embodiment it was found that there was a significant reduction m the volume of units requested by medical staff. This is thought due to the case and speed with which compatible blood can be dispensed as a result of removal of the need for a serological cross match. Further, the availability of computer cross matched red blood cell units in emergency situations enhances patient safety. It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiment without departing from the spirit or scope of the invention as broadly described. The present embodiment is, therefore, to be considered in all respects to be illustrative and not restrictive.

Claims: CLAIMS : 1. A computer system for controlling the dispensing of blood to a patient comprising: first data entry means for entering first patient record details including blood group and antibody screening details for said patient; second data entry means for entering second patient record details for said patient; said computer system cross-checking said second patient record details against portions of said first patient record details; said computer system determining a group of compatible blood packs for said patient from available blood stocks; third data entry means for entering details of a proposed compatible blood pack from said available blood stocks; and authorisation output means outputting an authorisation when said proposed compatible blood pack is one of said group of compatible blood packs as determined by said computer system. 2. A computer system as claimed in claim 1 wherem said first data entry means is remote from said second data entry means. 3. A computer system as claimed in any preceding claims wherein said blood group and antibody screening details are obtained from testing a sample of said patient's blood. 4. A computer system as claimed in any preceding claim wherein said computer system further comprises a network of interlinked computers. 5. A computer system as claimed in any preceding claim wherein said authorisation includes an adhesive label for placing on said proposed compatible blood pack. 6. A computer system as claimed in any preceding claim wherein portions of said patient record details are - - entered twice and stored in two separate storage locations and cross-referenced to one another. 7. A computer system as claimed in any preceding claim wherein said first patient record details are time stamped and said computer system refuses to issue an authorisation when the elapsed time from said time stamp exceeds a predetermined timeout interval. 8. A computer system as claimed in any preceding claim wherein, said computer system further requires reentry of said authorisation details. 9. A computer system as claimed in any preceding claim wherein said cross-checking also includes checking said second patient record details against previously entered first patient record details. 10. A computer system as claimed in any preceding claim wherein said cross-checking also includes checking said second patient record details against available hospital record details for said patient. 11. A computer system as claimed in any preceding claim wherein said blood packs have associated timestamps and said group of compatible blood packs includes only those blood packs having timestamps less than a predetermined interval from a current time whose timestamps are greater then a predetermined time passed. 12. A system for dispensing blood substantially as hereinbefore described with reference to the accompanying drawings.

Inventors: COX CRAIG, ENNO ARNO, WOODFORD PHILLIP, COX, CRAIG, ENNO, ARNO, WOODFORD, PHILLIP
Applicants: COX CRAIG, ENNO ARNO, HUNTER AREA PATHOLOGY SERVICE, WOODFORD PHILLIP, COX, CRAIG, ENNO, ARNO, WOODFORD, PHILLIP
Application year: 1997
Main classification: G06F19
IPC codes: G06F19