Cornput. Bml. Med.

Pergamon Press 1975 Vol 5, pp. 69-76.

Prmted I” Great Britam

AN INTERACTIVE COMPUTER-BASED MANAGEMENT SYSTEM HERBERT Department

of Industrial

Engineering,

(Rrcriued

DONOR

R. LUDWIG

Stanford

University,

Stanford,

California

94305, U.S.A.

8 April 1974 and in rrt:ised,forn~ 72 July 1974)

Abstract-Observations made at the regional and federal level confirm the urgent need for the application of computer techniques to the automation of blood banks. The increase in heart surgeries due to modernization of techniques has sent the demand for blood to a new high in areas where hospitals perform these types of operations. If whole blood could be stored indefinitely the problem of blood shortages could be alleviated in part; however, whole blood outdates in 21 days from the time it is drawn. making it imperative that blood banks allocate these units “optimally” (if possible) throughout a region of hospitals. There are two ways to partially solve the problem of unit outdating: (I) develop an inventory system that minimizes outdating of units; and (2) develop a donor pool such that all demands for blood can be met. This paper addresses itself to the second method and describes a donor retrieval system that allows for the “creation”. “updating”, “interrogation” and “reporting” of donor characteristics for the purpose of donor recruitment. Information retrieval formation system

Interactive File structure

Computers Blood bank Indexes programming procedures

Donor retrieval FORTRAN

In-

1. INTRODUCTION 1.1 The prohlern The purpose of this paper is to present a computerized approach to the problem of donor recruitment faced by all major blood banks or transfusion centers. Observations made at the regional and federal level confirm the urgent need for the application of computer techniques to the automation of blood banks [2]. The increase in heart surgeries due to modernization of techniques has sent the demand for blood to a new high in areas where hospitals perform these types of operations. If whole blood could be stored indefinitely the problem of blood shortages could be alleviated in part; however, whole blood outdates in 21 days from the time it is drawn, making it imperative that blood banks allocate these units “optimally” (if possible) throughout a regional network of hospitals. There are two ways to partially solve the problem of unit outdating: (1) develop an inventory system that minimizes outdating of units; and/or (2) develop a donor pool such that all demands for blood can be accommodated. This paper addresses itself to the second method. 1.2 Solution

A donor retrieval system has been developed for the Central California Red Cross Blood Center that runs on the IBM 360/67 time-sharing computer at Stanford University. This “information system” allows for the “creation”, “updating”, “interrogation” and “displaying” of donor characteristics. Special reports are generated that allow recruiters to “call in” donors to give blood. A primary objective of the system is to maintain and develop a donor pool of repeat donors. In this manner the center can be reasonably 69

70

H. R. LUDWIG

assured that all blood demands can be met by their donor-pool. If a donor does not repeat within a given specified time after he becomes eligible to give blood again (58 days), he is purged from the file automatically allowing the file to stabilize in a dynamic way on a set of repeating donors. For example, if a donor gave blood 6 months ago, and each time he has been contacted to donate blood again he has refused or had some sort of conflict, then he should be purged from the donor pool. 2. METHODOLOGY 2.1 The system

The system executes in the ORVYL partition (timesharing) in conjunction with WYLBUR, the Stanford Text Editor [l] on the IBM 360/67 computer located at Stanford University. It is non-procedural and demands no previous computer experience on the part of the user. Extensive use ofthe ORVYL file system is also made with respect to the indexing the storage of donor records. The system can be operated by remote terminals located throughout Santa Clare County. Blood requests can, therefore, be met during any time, day or night. 2.2 Ovrrtliew qf system All records are stored on a disk and are pointed to by a set of indexes. Indexes are set up according to blood type (A + , A -, B + , etc.). Each donor record is given a displacement relative to some base value depending upon his blood type. Donor records are, therefore, stored in contiguous blocks by blood type, 30/black, and the donor indexes that point to these records are stored 255/black. By this method of indexing, the indexes themselves can be sorted by blood type, date of last donation, etc. relatively easy so that one particular set of donors can be dealt with individually. The “date-of-last-donation” is a crucial parameter carried along with the indexes (Table 3). It determines whether or not a donor is in “suspense’‘-his name has appeared on a generated report list, but has not yet been updated (he has not given blood). Each time his name appears on a “suspended” list a counter-number of times appeared on report-is updated by 1.When this counter reaches 7, this particular donor record is purged from the system, insuring the file of a set of donors who constantly return and donate blood. Two main sets of reports are generated on a weekly basic--eligible and suspense reports. Eligible reports contain names and phone numbers of donors who have not appeared on a report since becoming eligible to give blood again. i.e. 58 days have elapsed since they last donated. Suspense reports contain the same information except that these reports are donors who are designated as suspended. In other words, these are donors who have appeared on an eligible list before, but have not yet come in to donate blood, or who have not responded to a phone call from an eligible list. Thus, the eligible lists or reports that are generated each week are free from those particlar donors who appeared on last week’s list, insuring a fresh set of possible donors. The system will handle 29,940 donors, but can be expanded to handle more if necessary. The justification for this figure stems from the size of the area or region handled by the Central California Regional Chapter of the American Red Cross. As stated previously, the actual physical donor records are stored contiguously through a second order indexing scheme, 30 per block. Each blood type has an approximate distribution. Utilizing this dis-

Computer-based

donor

management

71

system

XTR

30 Records/ block

352 3 353 _ El+

,

998

Fig. 1.

tribution, a number of blocks (each containing 30 records) can be allocated to each specific blood type (Table 1). These pseudo block numbers (l-998) act as an index to a list (JCI’R, Fig. 1) that contains the actual physical block numbers. Thus, the blocks are kept in contiguous order decreasing the cost of storage. If the pointer value, [IPTR(I), I = 1.299401 for a specified donor is known, the physical block number (l-998) and the logical record number (l-30) within that block can easily be obtained by the following calculations: (1) Physical block no. determined by: IRECNO = IPTR(1) - ITYPE(JBLOOD) IBLKNO = [(IRECNO - 1)/30 + 1] + KTYPE(JBLOOD) = LOGICAL BLOCK NUMBER Table

Blood type A+ ABf BOf OABf AB-

1. Blood

type distribution

Number 1 2 3 4 5 6 I 8

(Blocks

and Records)

Block displ. (KTYPE)

Records (ITYPE)

0 250 350 450 530 770 870 940 998

7,500 10,500 13,500 15,600 23,100 26,100 28,200 29,940 total records

73

H.

R. LUDWIG

where IPTR(1) = pointer value for ith index; JBLOOD = numerical value of blood type, (A+ = 1,. . . .); ITYPE(JBLOOD) = record displacement; KTYPE(JBLOOD) = block displacement: THEN

IBLKNO

= JCTR(IBLKN0)

= PHYSICAL

BLOCK

NUMBER.

(2) Logical record no. (inside physical block) determined by: IRECDX = IRECNO

-

[(IRECNO

- 1)/30]* 30

For example, if the pointer value for the ith donor is 23,985 his record would reside on physical block JCTR (550) and the logical record within that physical block would be 15. Example

For donor with IPTR(1) = 23985, then JBLOOD

= 5 (Of)

ITYPE(5) = 23100 KTYPE(5) = 520 and IRECNO

= IPTR(1) - ITYPE(JBLOOD) IBLKNO

= 23985 - 23100 = 885

= [(SSS - 1)/30 + 1 + 520(logical block no.)]

giving IBLKNO

= JCTR(550) = physical block no.

To determine the logical record number within that physical block just calculated set IRECDX = 885 -

[(885 - 1)/30]* 30 = 885 - 29*30 = 885 - 870 = 15

3. SYSTEM

STRUCTURE

AND

STRATEGY

The solution to the donor retrieval problem is relatively simple if one has an unlimited budget and costs are of no consequence. However, as we all know, this is never the case. Various strategies must be developed to reduce costs so they fall within the limits set by management. These strategies fall into categories such as file design, index design (which depends on file design), and index reading to name a few. Once you have determined one certain strategy a limit is usually placed upon other succeeding strategies. In other words, certain other strategies are then eliminated. Thus, if one can determine the overall strategy first (hopefully, it is “semi” optimal) then the process of determining other strategies is not so difficult. 3.1 File desigrl The overall file design (for donor records) was discussed in Section 2.2. In this particular section a more detailed analysis and justification shall be given for the file design utilized. The computer system used for this application allows the user to read/write blocks of 2048 bytes to a file system called “ORVYL”. Having previously defined the donor records to consist of 30 records/block, a “logical” record will, therefore, contain 68 bytes of information (2048/30). Some of this information is stored as character, some as integar, and some as byte (coded). Table 2 describes a donor record in detail along with its designated storage allocation.

Computer-based

donor

management

Table 2. The donor

record

Bytes utilized

Field name

24 28 4 4 2 4

1 Name 2 Address 3 Home phone 4 Business phone 5 Extension 6 Date of birth 7 Sex (2 bits) 8 Availability (2 bits) 9 Blood type (3 bits) 10 Occupation (3 bits) Total

13

system

I 68

Stored as Character Character Integer Integer Integer Integer Code Code Code Code

Note the fields 7-10 are coded using bit representations to designate a particular value. These two bytes can be easily coded or decoded by the use of binary arithmetic. One strategy of locating a particular donor would be to read a block at a time and compare names. This strategy would not be too successful if one of the donors was on a block at the end of the file. For instance, if the record for donor “Jones” was in the 500th block, the succeeding 499 blocks would have to be read until that particular block was read on which his record was stored. Some strategy must be developed that reduces these number of block reads. This can be achieved by executing a search on a list that contains information allowing us to locate the donor desired and also a pointer to the correct block and position within that block where the record resides. This procedure is known as “indexing”. Thus, if a scheme can be determined that allows us to scan list and determine the exact location of a donor without reading every’block in the file, much time will be saved. For the donor file being described here such an index was set up and is described in the next section. 3.2 Index design Note that the index is made up of several “values” or “attributes” (Table 3). These are as follows: Record key-index. The key value for each record is made up of the first three letters of the last name and the birthdate. This code is too large to store as characters (9 bytes) so an algorithm that reduces this donor I.D. to two bytes (an integer number between 32,768 and + 32,768) is applied. Key = i

(~$26~-‘) + J - 2400

i= 1

where ai denotes the numerical value of each of the first three letters of the last name, e.g. A= l,B=2,... and .I denotes the Julian value of the birthdate with the base being 1900. Pointer. The pointer contains information that specifies the particular “physical” block and the “logical” record number within that block. For example, if the distribution of blood types is allocated according to Table 1 and the pointer value of 7501 is encountered then (using integer arithmetic) (7501 - 1)/30 + 1 = 251 gives the “logical” block number.

-

number from determination

A

1 of

29,940. blood type

TO

Knowing the

pointerallows

(A+,B-,etc.)

To get the physical block number the array JCTR (Table I) is used. Calculating IBLKNB = JCTR (IBLKNB) = physical block no. = 1 on the right hand side of the physical block number IBLKNB = 1 is obtained. At this point the physical block number has been determined, however, it still remains to determine the “logical” record number or position within this physical block (of 2048 bytes) that locates the &or record. Knowing the blood distribution and the block type the logical record number can be easily determined. Calculating IRECNB = 7501 - ITYPE (JBLOOD) where 7501 is the pointer, and JBLOOD = 2 refers to A- blood type coded 2. Using Table 1 the values of IRECNO = 1 is determined. Thus IRECDX = 1 - [(l - 1)*30] gives the logical record number as 1. We have now determined that the index with the pointer 7501 refers to the 1st physical block in the file and the actual donor record is the 1st logical record (68 bytes) of this 1st physical block. Date-of-last-donation. The date-of-last-donation plays a very important role in the philosophy of operation of the total system. This is why it is included as part of the “index”. In order to reduce the size of the date being stored a Julian date is used in all calculations.

Computer-based

donor

management

system

75

The Julian date (date-of-last-donation) can be set to positive (+) or negative (-). If the date is positive, then the donor has been updated and can again donate blood once 58 days have passed since his date-of-last-donation. If the date is negative the donor is in “suspense”. This means that the donor has appeared on an eligible list once and attempts have been made to contact him to advise him that he is available to donate blood again. The reason for this type of strategy is as follows: If no distinction is made between donors as to the eligibility and non-eligibility (suspense) the donor lists from which donors are contacted would grow to an unusable degree. In other words, there has to be a method of keeping a donor off an eligible list until he or she is again eligible to donate blood. This is accomplished by determination of eligibility or suspense (positive or negative) date-oflast-2lonation. This keeps the “dead wood” donors off the lists. Two l-byte jfields. These two fields (see Table 2) are used for coding information. The information coded into the two bytes is as follows: Byte lPno. of times appeared on list, total donations to date; Byte 2: rare, suspense, total donations/year, blood type. This information is used as needed by the system. However, the advantage in carrying it along within the index is that one does not need to retrieve the total donor record from the file when the above information is required. There may be times when you just desire a report on donor availability, or the number of rare donors in the file, etc. 3.3 Index reudings strategy Setting up the indexes to reflect certain attributes of the file can now assist us when desiring to read and use those indexes. If we are just going to update donors-change their data-of-last donation from negative to positive, (to make the donor eligible again, but not necessarily available), then there is no reason to read in the positive donor indexes. The same holds true for the addition of new donor records to the file. The only indexes that need to be read in this case are are those that have a “zero” index value, i.e. the key index value has been zeroed out, but the pointer has been saved, thus saving time in searching for an empty space for a new donor record. Many different strategies can be developed by reading indexes depending upon the requirements of the user. The form that we are using in this system. (1) (2) (3) (4)

All (reads all indexes into core). Eligibles (reads only eligibles into Core-positive DOLD)*. Suspense (reads only suspended donor indexes-negative DOLD). Open slots (reads only zero indexes, with positive pointers).

Blood type can be specifed on any of the above. In other words the user may wish to read all B+ suspended donors. This is easily accomplished with the current indexing scheme. 4. COSTS

AND

BENEFITS

The costs of this system are nominal when compared to the benefits obtained. No longer is it necessary to shuffle donor cards around in file cabinets. Reports can be generated on demand or on a weekly basis, depending upon the demand for blood usage. The task of sorting and storing all donor records is now left to the computer which now allows the recruiter to spend his “full-time” recruiting blood donors! , * DOLD--date-of-last-donation.

76

H. R. LUDWIG

SUMMARY More and more demand is being placed upon regional blood centers across the country for whole blood and its derivative components. Because of this increased demand for blood and its various components, these centers are critically evaluating donor recruitment procedures. In order for a blood center to operate efficiently and supply the proper amount of blood necessary to its region of hospitals, the donor pool for any particular region must be dynamic in nature, i.e. a large percentage of the donor population must be made up of repeating donors-donors that give more than once a year. A donor retrieval system has been developed for the Central California Red Cross Blood Center that runs on the IBM 360/67 time-sharing computer at Stanford University. This paper addresses itself to the procedures utilized by this computer “information” system that makes this particular region’s donor population “dynamic”. These procedures are applicable to any region and are presented here in order to facilitate other centers who are considering the possibility of switching to a computerized donor-retrieval system in the near future. REFERENCES 1. R. Fredrickson, Wylhur on the IBM 360/67. Stanford University Computation Center. Stanford. California (1969). 2. C. F. Hogman and 0. Ramgren, Computer system for blood transfusion service, Transfusior~ 10, 3 (1970). 3. H. R. Ludwig and J. Vallee. Medical data management in time-sharing: findings of the DIRAC proJect, Rrwurch Report Nunlber III. Stanford University Computation Center, Stanford, California (1970). 4. J. M. Stengle, The National blood resource program and data processing systems; Transfusion, 10. 3 (1970). 5. R. A. Stewart and W. B. Stewart. Computer program for a hospital blood bank. Trmsfusion 9, 2 (1969).

ABOUT

THE

AUTHOR

HERBERT R. LUDWIG received his B.A. in 1958 and M.B.A. in 1963 from the University of California at Los Angeles and completed doctoral work in Industrial Engineering and Management Science at Northwestern University in 1967. Before coming to Stanford University in 1970 as a Systems Analyst/Data-Base Administrator for the Information Systems Department at the Stanford Computation Center, he was a Systems Analyst for R. R. Donnelly and Sons in Chicago, a scientist with Decision Science, Inc. in San Diego and served as Assistant Professor in the Information Systems Department at Sah Diego State University. Since 1972 Dr. Ludwig has been an Acting Assistant Professor in the Department of Industrial Engineering at Stanford. Dr. Ludwig has a continuing interest in the use of computers in medicine and has done extensive research and writing in that field. He is presently associated with the Central California Regional Red Cross in San Jose; the Department of Radiotherapy, Department of Surgery and the Clinical Laboratory at Stanford Medical Center. His newly published book, Computer Applicatiorls arld Techrliques in Clinical Medicine describes many of the systems he has developed.

An interactive computer-based donor management system.

Cornput. Bml. Med. Pergamon Press 1975 Vol 5, pp. 69-76. Prmted I” Great Britam AN INTERACTIVE COMPUTER-BASED MANAGEMENT SYSTEM HERBERT Department...
566KB Sizes 0 Downloads 0 Views