WO1994015270A1 - Method and apparatus for providing a data interface between a plurality of test information sources and a database - Google Patents

Abstract

A data interface (508) which is capable of receiving test information from a variety of biological fluid testing instruments (530) employs first and second processes (512, 522). The first process determines the type of data which is provided by analyzing the format of the test information using a master rules file. Once the type of the source is identified, the first process passes the data and a set of rules to use to parse the data to the second process. The second process extracts the test data from the information provided by the testing instruments using the set of rules identified by the first process. Furthermore, if the test information is received in pieces the present invention can marry the pieces to provide a complete data set to be stored in the database.

Description

METHOD AND APPARATUS FOR PROVIDING A DATA INTERFACE BETWEEN A PLURALITY OF TEST INFORMATION SOURCES AND A DATABASE

FIELD OF THE INVENTION

The present invention relates generally to a data interface and, more particularly, to an data interface which enables a database to collect and maintain test information related to biological fluids from different types of test information sources.

BACKGROUND OF THE INVENTION

There are many reasons for testing biological fluids. For example, the donation of blood typically requires that the blood be screened for various diseases and/or foreign bodies. Blood screening of donors at blood banks is a large and ever growing market requiring accurate and reliable testing. Other biological fluids, such as urine and saliva, are routinely tested and/or screened to detect diseases, chemicals or other substances. Over the years, as both the amount of blood being donated and the number of required tests have increased, a degree of automation has occurred. Systems such as the Commander System™ by Abbott Laboratories, have partially automated many of the steps involved in blood testing.

The Commander System™ can be divided into four main parts: a Flexible Pipetting Center (FPC) which transfers samples to test wells in sample trays, a Parallel Processing Center (PPC) which adds reagents and reads optical absorption test results, a Dynamic Incubator (DI) which incubates the samples, and a Data Management System (DMS) which stores the test results for access by other programs. Under this system, a donor's blood sample is initially bar coded. This information is stored in a local database with the same information residing in the DMS database. The bar coded samples are then transferred to the FPC for pipetting into test wells. The bar coded blood samples have their exact well position in the holding tray entered into the database. This position information is supplied by the FPC in pipetting the samples and is used by the PPC and DMS.

Each holding tray is also bar coded. This bar code is read as soon as the tray is placed into the FPC.

The bar code information on the tray, combined with the bar code information on each blood sample, provides for accurate data gathering and tracking of the blood samples through the testing process. Next, the tray containing the samples moves either to the DI or to the PPC, depending upon the tests being run. As an example, assume the tray moves next to the PPC, the bar code of the tray is again read, to insure tracking of each individual blood sample contained in the test wells. A connection, such as a serial data

connection, links the FPC to the PPC to track the blood sample through the entire testing procedure. The PPC reads the test results. The test results, which are linked to a particular blood sample by way of the bar code, are then ported over to the DMS via, for example, a serial data connection.

The DMS takes the information provided to it from the PPC to provide a report of the test results for each blood sample. In the example of the Commander System™, the system components are linked by a communication interface which allows for a continuous "chain-of-custody" to be established for the tested samples. This is illustrated in Fig. 1a, in which, pipettor 110 passes its information along to reader 112 which, in turn, passes a complete package of test information to database 114. Because many vendors produce biological fluid testing instruments, however, multi-vendor testing

environments are commonplace. Fig. lb illustrates a possible configuration, where a pipettor 120 and a PPC 122 are not compatible and, hence, not linked by a

communication interface. In this case, pipettor 120 passes its information to database 114 where it is temporarily stored. Subsequently, PPC 122 requests the pipettor information from database 114 via a special driver; links the test results, which were obtained by reading the sample tray, with the pipettor information; and passes the complete package back to database 114.

In systems of this type, in order to accommodate the numerous system configurations that may arise, database 114 desirably interfaces with a variety of potential sources of test information.

Fig. 2 shows an example of a data interface for the database 114 of Fig. la. In Fig. 2, reader 210 sends test information to driver 212 which handles the

communication interface and completed receipt of the test information. The test information is then processed by demon 214 which parses the data file and enters it into database 114. The word "demon" as used herein means a process running on one of the computer systems which are coupled to the system. Although the term as it is used in the art typically designates a background process which does not terminate, the present usage of the word is not so limited. In the system shown in Fig. 2, the reader 210 can be one of several different instruments. Examples of such include a PPC, a Quantum II, a Quantumatic or a VP all made by Abbott Laboratories.

Fig. 3 shows an example interface used for the system configuration of Fig. lb in which pipettor 310 supplies information to database 114. The interface of Fig. 3, similar to that of Fig. 2, uses a separate driver 312 and demon 314 combination for each pipettor supplying information. However, in Fig. 2b, the information is only temporarily stored in database 114 until it is requested by PPC 122 (Fig. 1b). The pipettor information is then transferred via a special driver, PPC_com 318, to PPC 122 which reads and delivers a complete test information package to database 114 via the interface configuration of Fig. 2a.

The requirement that different drivers and demons be created and used for each new system

configuration is complicated, time-consuming and impedes the efficient development and integration of multi-vendor testing environments.

SUMMARY OF THE INVENTION In a system for collecting biological fluid test information from any one of several test information sources and maintaining the biological fluid test

information in a database, the present invention is embodied in a system which provides an interface between each of several information sources and the database. The data interface includes a driver which automatically adapts itsel'f to communicate with each of the several sources, to receive test information. According to one aspect of the invention, the system includes a post-demon which, based on the identity of the information source and the corresponding information format, parses test information received from any one of a plurality of information sources. The post-demon also enters the parsed information into the database.

According to another aspect of the invention, the system includes a preprocessing demon (pre-demon) which is used to examine, based on a set of predetermined rules, the received test information to identify its source.

Additionally, a postprocessing demon (post-demon) is provided which parses the test information, based on the identification made by the pre-demon using a second set of predetermined rules. The post-demon also enters the parsed information into the database. According to another aspect of the invention, the system includes a demon which can link or marry partial information records from two sources to generate a complete record. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is described by way of nonlimiting example with reference to the following figures in which: Fig. 1a (prior art) is a high-level functional block; diagram of a prior art biological fluid testing system configuration employing a compatible pipettor and reader;

Fig. 1b (prior art) is a high-level functional block diagram of a prior art biological fluid testing system configuration employing a non-compatible pipettor and reader;

Fig. 2 (prior art) is a functional block diagram of a data interface suitable for use with the prior art configuration of Fig. 1a;

Fig. 3 (prior art) is a functional block diagram of a data interface suitable for use with the prior art configuration of Fig. 1b, in combination with the interface of Fig. 2; Fig. 4a is a high-level functional block diagram of a biological fluid testing system according to the present invention which employs a processing system to correlate test information before sending it to a database; Fig. 4b is a high-level functional block diagram of a biological fluid testing system according to the present invention in which the pipettor and reader send their information to the database individually; Fig. 5a is a functional block diagram which shows a first embodiment of a data interface, employing a post-demon, suitable for use with the present invention;

Fig. 5b is a functional block diagram which shows a second embodiment of a data interface, employing a pre-demon and a post-demon, suitable for use with the present invention;

Fig. 6 is a more detailed functional block diagram which illustrates the interaction of the pre-demon and post-demon in the data interface of Fig. 5b; Fig. 7 is a program listing which shows an example of a master rules file suitable for use with the data interfaces of Figs. 5a and 5b;

Fig. 8a is a program listing which shows an example of a rules file suitable for use with the data interfaces shown in Figs. 5a and 5b;

Fig. 8b is a program listing which shows an example of a run file, used by the data interfaces shown in Figs. 5a and 5b and described by the rules file shown in Fig. 8a; Fig. 8c is a program listing which show an example of an alternative rules file, used by the data interfaces shown in Figs. 5a and 5b;

Fig. 9 is a flowchart diagram which illustrates the data marriage function which is performed in the data interfaces shown in Figs. 5a and 5b.

DETAILED DESCRIPTION OF THE INVENTION

I. Overview

The present invention provides a data interface for a database which receives and maintains test

information which may be generated by a variety of

different sources having a variety of different formats. In the exemplary embodiment of this invention, the test information is related to test results of biological fluids.

As mentioned, the test information may be generated by a variety of instruments, for example, test information related to the identification of fluid samples in a tray can be generated by pipettors. Test results associated with the fluid samples can be generated by equipment which adds reagents to the samples and then analyzes the light transmitted through the samples once the reaction is complete. The portion of this equipment which generates the data values is generically known as a reader. Both readers and pipettors are available from many

different vendors. In addition, other types of information about the biological fluids may be developed using other types of instruments which measure sample properties other than optical absorption. Consequently, many different types of test information can be collected and maintained in a database and the data may be provided in many

different formats.

Figs. 4a and 4b, by way of example, illustrate two contemplated system configurations for collecting test information. In Fig. 4a, data processing system 410, such as a personal computer (PC), controls and coordinates the activities of a pipettor 412 and a reader 414. First, pipettor 412 loads the wells of a tray to be tested with fluid samples. The identification information associated with the tray and the samples is passed by the pipettor 412 to the PC 410. Next, reader 414 performs the selected test(s) on the tray previously prepared by pipettor 412. The results of the test(s) are sent to PC 410 which couples the pipettor information and the reader information. PC 410, then, passes a complete test information file to database 416. A database system suitable for use as the database 416 is the Euro Blood Bank System (EURO-BBS™) which is manufactured by Abbott Laboratories.

In contrast, Fig. 4b illustrates a system configuration not governed by a separate local data processing system. In Fig. 4b, pipettor 422 passes its information to database 416 first, then, after the samples are tested, reader 424 passes its results to database 416. In this case, the test information is received in pieces. In this example, the processing functions performed by the PC 410 of Fig. 4a may be consolidated in processing hardware coupled to the pipettor 422, database 416 or reader 424. Alternatively, these functions may be

distributed among this processing hardware. As seen from Figs. 4a and 4b, depending on the system configuration, the test information can be sent to database 416 from various sources (e.g., PC 410, pipettor 422 or reader 424). Thus, the present invention enables the database 416 to receive and maintain test information from a variety of sources.

Fig. 5a is a first embodiment of a data interface 508a suitable for use with the present invention. Data interface 508a comprises a device driver 510, a post- demon process 522 along with particular rules files 518a-n which are associated with a particular device by a system administrator (ADMIN) 540. In the discussion that follows, the entire data interface 508a (excluding Administrator 540) is assumed to be running on a single computer system, for example, the PC 410 shown in Fig. 4a. It is

contemplated, however, that parts of interface 508a may be implemented on respectively different computer systems with the functionality being divided among the pipettor and database processors as well as other processors that may be coupled to the system. The exemplary environment in which data interface 508a operates includes a source of test

information (which, in this case, is reader 530), a system administrator 532 (an application interface which uses database 416), a database 416 and a data management system (DMS) 533 which allows applications programs (not shown) to access the database.

In Fig. 5a, post-demon 522 parses a received data file and places the information into database 416.

Prior to processing the received data file, however, post- demon 522 needs to know the information source type (i.e., the identity of reader 530) and the file format of the received data file so it can properly parse the received data file and enter it into database. In this embodiment of the invention, the source type and file format

information are configured by an administrator 540 before the data file is generated. In the exemplary embodiment of the invention, the administrator 540 assigns a particular rules file, corresponding to a respective particular data source type, to a corresponding input port to the post- demon 522. One rules file may be associated with multiple input ports. All data from sources having an identified source type is applied to the post-demon 522 via the input port that has been defined for that source type. This information is parsed using the file format information which is contained in the assigned one of the rules files 518a-n. Alternatively, the data source may be coupled to the post-demon 522 via a network (not shown). In this configuration, the rules file which is used to parse the data is determined from a directory accessible to the post- demon 522.

Exemplary data source types, in this case, readers 530 include the Olympus PK7100, manufactured by Olympus; the Groupamatic manufactured by Kontron, the Autogrouper manufactured by Technicon or the EPOS

manufactured by Eppendorf. To date, driver 312 and demon 314 have been specifically designed to interface with the particular instruments/tests being used/run. Thus, a different driver and demon need to be generated for each instrument/test providing test information to the database 114. The phrase "instrument/test" is used because it is possible for a single instrument to perform two or more different tests having different test information formats each of which needs a separate, dedicated demon to parse the test results.

Fig. 5b is a second embodiment of a data interface 508b suitable for use with the present invention. Similar to the interface 508a, Data interface 508b

comprises a device driver 510 and a post-demon process 522 along with particular rules files 518a-n. Data columns 7- 16 of the run file line is the sample ID, the value in columns 1-3 is the tray position, the value in columns 20- 22 is the sample absorbance and the value in column 27 is the result of the test. The six values in step 824 translate the single character results to field values for the test result.

In general terms, each step in a rules file indicates a character string to be found at a defined location in the line in the run file and a data format for the data values in the which uniquely identiine from a data file goes through four phases. If a line satisfies at least one rule in a phase, the line does not proceed to the next phase, but finishes all of the checks in the current phase.

Phase 1 checks each line to see if it contains a configured error. A configured error is an acceptable or known error that can be expected from the particular source. If an error is found, a configurable action

(accept as NON-POSID, ignore, reject) is performed. If the action is reject, the batch data is rejecis treated as valid. If the action is to accept the batch as NON-POSID, the type of the batch data is changed to NON-POSID which means the samples are dissociated from their sample ID'S. This action requires that a successful data marriage, described below with reference to Figure 9, be achieved before the batch data may be entered into the database 416. Phase 2 checks each line in the run file to determine if it contains a header record. If a header record is found, this line is ignored and

processingExemplary items checked in this phase are:

Batch Name, Procedure, Tray ID, Tech ID, Master Lot, Controls, Control Averages,

Control Ranges, Control Differences, Cutoff,

Cutoff Formula

Phase 4 checks for the sample data. A batch is considered NON-POSID if no valid sample IDs can be read from the data file. If at least one sample ID can be read and verified, then the run is considered POSID. A sample ID is verified with the standard database sample

verification routines. In the exemplary embodimente are: Sample ID, Tray Position,

Absorbance, Subbatch Information

If the post-demon 522 does not find a match for a given line in any of the phases, the line is ignored.

After the data file has been completely read, the final checks are performed. If the run is POSID and there were no errors, the batch data is entered into the database 416.

If the run is NON-POSID, two configuration parameters, which may be specified by the user, are checked and aand the batch data is NON-POSID, then the run data is entered into the database 416. If NON-POSID runs are not allowed and the batch data is NON-POSID, the run data is rejected.

If the new run data has the same tray ID as unaccepted data that already exists on the system, the new run data overwrites the run data currently existing in the database 416. d. Data Marriage The data marriage section is used when a NON- POSID run is received. The run could have been initially

NON-POSID or could have been

co ≠ ≠ ≠ ≠ ≠ ≠ . ≠ O ^a " 5

Y , a ^{a a a} ?

' ^{- -} öìè Ñì Ñì Ñ

,Ntion, indicating which of the tray positions

contain samples, is available from the run file. If not,

the marriage is rejected at step 912. If the position data

is available then control is transferred to step 916. At

step 916, the post-demon 522 determines if pipettor

information corresponding to this tray ID is available in

the database 416. If it is not, the marriage is rejected

at step 912, otherwise control passes to step 918.

not null, then, at step 922 post-demon 522 attempts to get the subname data from the

database 416 using the test number from the pipettor data

and the assay number from the run data. If no test data

can be found, the marriage is rejected at step 924. If,

however, subname data is found, then control is passed to

step 926. At step 926, the subname data recovered from the database 416 is compared to the batch name in the run file. If these data do not match then the marriage is rejected at step 924, d which maintains data representing the biological fluid test information in a database, a data interface which processes the information provided by each of said sources to extract data to be stored in said database, said data interface comprising: driver means, adapted to communicate with any one of said plurality of sources, for receiving said test information; preprocessing demon means for examining the format of the test information, based on a set of master rules, to identify the respective source otion test information and the database contains data provided by a pipettor related to biological fluid samples which were processed by the reader to generate the optical absorption test information, the method further comprising the steps of: examining the test information provided by the reader to obtain data which may be used to match the test information to the pipettor data in the databTYPE ALL

CLAIMS WITHOUT PARAGRAPH RETURNS IN BETWEEN. AFTER TYPING LAST CLAIM, COPY THE LAST DIVISION MARKER INTO SCRAP. PUT YOUR CURSOR ON THE CLAIM NUMBER AND HIT "INSERT," STARTING WITH CLAIM 2 AND CONTINUING FOR EACH CLAIM. u _ , @ f _" ^ _p _@_@

Claims

1. An interface system which collects and maintains biological fluid test information from a plurality of sources, each source having an identity and providing test information in a respective format, and which stores data derived from the test inem in accordance with claim 6, wherein said database includes data generated by a pipettor concerning samples processed by the

biological sample reader and the post processing demon means marries the stored pipettor data and to the data extracted from the test information before the data is stored into the database. u _ ,@ f ^ _P _@

_@

8.

information and to provide an indication of the

identification; and post processing demon means, responsive to the indication provided by the preprocessing demon means, for parsing said test information to extract the data therefrom and for entering said extracted data into said database. u _ , @ f ^ _p _@

_@

6. A system in accordance with claim 4, wherein said test information includes optical absorption information provided by a biological sample reader . u _ ,@ f ^ _p _@

_@

7. A systcombining the data extracted from the test information with the pipettor data from the database before storing the data extracted from the test information in the database. u _ , @ f ^ _p _@

_@

A data interface which is capable of receiving test information from a variety of biological fluid testing instruments employs first and second processes. The first process determines the type of data which is provided by analyzing the format of the test information using a master rules file. Onces the first line of the run file shown in Fig. 8b. The text on this line, "MP7000" does not match any of the rules in the rules file shown in Fig. 8a and so, is ignored. Next, the second line in the run file is read. This line is parsed by line 808 of the rules file shown in Fig. 8a. To parse this line, the post-demon, at step 808, determines that this is a tech ID line because columns 1-8 contain the character string "Tech ID".

Columns 9-15 are identified by the rule at step 808 as containing the acttest which provided the data and, so, the rules file to be used to transfer the data to the database 416. When data is transmitted across the network, however, the run files are not made available for use by the pre- demon 512 until the file is complete.

Before it processes any run files, pre-demon 512 reads and parses the master rules file 514 to verify that each of its entries are syntactically correct. This processing step enforces a format for the master rules file 514 which is described below in the Master Rules File section with reference to Fig. 7. As described below, each set of rules in the file corresponds to respectively different run file formats. In the exemplary embodiment of the present invention, every five seconds, pre-demon 512 looks for new run files which may have been generated by driver 510.

When a new run file is available, each line of the run file is compared to every rule in master rules file 514. If a line satisfies a rule, then a counter for that rule is incremented. A set of rules is considered the "most satisfied" set if the total value of its counters is greater than the value of the counters of any other set of rules and if each rule in the set of rules has been satisfied.

If no rule sets in the master rules file are satisfied at the end of the run file or if two rule sets are equally satisfied, the data is rejected, and the run file is moved to the save directory.

The one set of rules from the master rules file that most satisfies the run file determines which rules file 518a-n is selected for further processing of the run file. Once this determination has been made, the pre-demon 512 passes the selected rules file 518a-n and the run file (or pointers to the files) to post-demon 522. Pre-demon 512 continues processing new run files while post-demon 522 finishes processing the passed run file.

In the exemplary embodiment of the invention, if the driver process 510, pre-demon process 512 and post- demon process 522 are all running on the same computer system, the rules file and run file may be stored in fixed locations in random access memory (RAM), or on a disk drive. In this instance the passing of this information from one process to another may be accomplished by simply passing the address or file name. Alternatively, if the processes are implemented on different computers, the actual file data may be transferred between the computers. a. Master rules file 514

A separate master rules file 514 is generated for each location (i.e., bloodbank or other fluid testing facility) depending on the system configuration and the instruments available at that facility which can generate the test information.

An example of a master rules file is shown in Fig. 7. In this Figure, the first test is for information received from an HBS assay. Pre-demon 512, using master rules file 514 as a guide, checks the received data file to determine if columns 1-23 of a line in the file contain the character string "Microtiter Results Data" (step 710), and if columns 1-18 in another line in the file contain the character string "Test Name: HBS EDI" (step 712). If these fields match and no other rule set in the master rules file has a better match, pre-demon 512 has identified the run file as satisfying the master rules for an HBS output.

Based on this identification, the pre-demon 512 indicates to post-demon 522 which of the rules files 518a-n to use, in this case, the appropriate rules file would be

"/usr2/bbs/demon/rules/rules.hbs" as specified in step 712 of the first set of master rules. As described above, the pre-demon 512 compares the run file to each set of master rules before it declares a match. This is done because equipment purchased from the same manufacturer may have subtly different data formats as may different tests performed using the same instrument. These differences are reflected by slight differences in the rules in the master rules file which correspond to the different test formats. By checking the run file against all of the rules, the system ensures that the proper set of rules will be used for each instrument or test.

If the second or other set of rules presents a better match than the first set, the pre-demon 512

indicates that the rules file associated with that other set of master rules provided the data that is stored in the run file. At this point, pre-demon 512 indicates to post- demon 522 the appropriate rules file, as listed in the master rules file, to be used to parse the run file.

3. Post-demon 522

Referring back to Fig. 5b, post-demon 522, using the selected rules file 518a-n, parses the data file to extract the relevant test information and enter it into database 416. Additionally, post-demon 522 can perform a data marriage.

First, post-demon 522 checks the selected rules file 518a-n for correctness. The format of rules files 518a-n is described below in the Rules File section with reference to Figs. 8a-c. Next, post-demon 522 parses the run file and checks the test information which is extracted. If the information is POSID (the test results are associated with sample IDs) then the information is entered into database 416. If the information is NON-POSID (test results without sample IDs), post-demon 522 may look for the related pipettor information in an attempt to combine or "marry" the separate sets of information. Marrying of information is described below in the Data Marriage section with reference to Fig. 9. b. Rules Files 518a-n

A separate rules file 518a-n is generated for each type of instrument/test which may provide test information to the database 416 at a particular location. As mentioned, for the present invention, it is contemplated that a variety of sources (e.g., host system, reader, pipettor, or any other instrument/test desiring to place information in the database) can be supported.

Each of these rules files corresponds to the list of rules files in master rules file 514 (see Fig. 7).

The following table, Table 1, shows the basic form of a rules file:

It should be noted that there are four groups that form each phase of the parsing of a given line. The reading of every line progresses through each phase starting at phase 1 going through to phase 4. If a line fulfills at least one item in a phase, then the line does not continue to the next phase. Phase 1 contains the Errors item. Phase 2 contains the Header section. Phase 3 contains the Procedure, Tray ID, Tech ID, Header, Master Lot, Control, Control Average, Control Range, and Control Difference items. Phase 4 contains Sample ID, Tray

Position, Sample Absorbance, and Sub Batch Info items.

These phases are described below in the Run File Processing section with reference to Fig. 8b. Fig 8a is an example of one of the rules file listed in the master rules file of Fig. 7 (ALT rules file). And, Fig. 8b is an example run file corresponding to the ALT rules file of Fig. 8a. The rules file of Fig. 8a describes the data format of the run file of Fig. 8b produced by an ALT type information source. This type of information source provides data from an ALT-type liver function test.

With reference to Figs. 8a and 8b as a preliminary step to processing the rules file shown in Fig. 8b, the post demon 522 generates a blank record which will be stored in the database 416 and sets the BATCH_NAME field of the data record to "ALT". This identifies the data record as containing information concerning the ALT liver function test.

To begin parsing the run file, Post-demon 522, using the rules file as a guide, reads the first line of the run file shown in Fig. 8b. The text on this line, "MP7000" does not match any of the rules in the rules file shown in Fig. 8a and so, is ignored. Next, the second line in the run file is read. This line is parsed by line 808 of the rules file shown in Fig. 8a. To parse this line, the post-demon, at step 808, determines that this is a tech ID line because columns 1-8 contain the character string "Tech ID". Columns 9-15 are identified by the rule at step 808 as containing the actual Tech ID. The post demon retrieves the character string "CHRIS" from these columns and stores the string into the TECH_ID field of the data record for this test. Next, at step 812, post-demon 522 reads the second line of the run file and determines that this is a tray ID line because columns 1-7 contain the character string "Tray #:." Columns 8-14 contain the actual tray number which is entered into the field TRAY_ID of the database record. Skipping to line 6 of the run file, at step 814, post-demon 522 determines that this is data that defines the low control samples that are used in the tray because columns 14-16 contain the string "LOW". the run file entry for this type of line indicates that columns 20- 22 contain the optical absorbance value for the low control sample and that columns 1-3 contain the control position string. The two quoted strings in the rules file step 814 contain the regular expression for the control string and the control type to update in the control table,

respectively. The control absorbance information is added to the control table and indexed in the table by the control position string "LOW."

At steps 816, 818, 820, 822, and 824 of the rules file, the post demon 522 is instructed to interpret any line in the run file, which has a ten-character value in columns 7-16, a three-character value in columns 1-3, a three character value in columns 20-22 and a one character value in column 27 as containing data for a test. In the example shown in Figures 8a and 8b, the value in columns 7- 16 of the run file line is the sample ID, the value in columns 1-3 is the tray position, the value in columns 20- 22 is the sample absorbance and the value in column 27 is the result of the test. The six values in step 824 translate the single character results to field values for the test result.

In general terms, each step in a rules file indicates a character string to be found at a defined location in the line in the run file and a data format for the data values in the which uniquely identifies the data contained in the line. For lines which contain data that is to be stored into database records, the step in the rules file also indicates the field name of the data. Fig. 8c is an example of a CMV type rules file as listed in the master rules file of Fig. 7. Fig. 8c shows examples of some of the other items of Table 1 not shown in the example of Fig. 8a.

c. Run File Processing

Each line of the run file is treated as a separate entity, which means a data file cannot have a header record such as "POS CONTROLS" and then contain control values in the following lines. In other words, in the exemplary embodiment of the invention, each line of the run file contains a complete data item; a data item cannot be split across more than one line. It is contemplated that, in other embodiments of the invention, data items split across multiple lines may also be processed. It is also contemplated that run files may be processed which include multiple data items in a single line.

The evaluation of a line from a data file goes through four phases. If a line satisfies at least one rule in a phase, the line does not proceed to the next phase, but finishes all of the checks in the current phase.

Phase 1 checks each line to see if it contains a configured error. A configured error is an acceptable or known error that can be expected from the particular source. If an error is found, a configurable action

(accept as NON-POSID, ignore, reject) is performed. If the action is reject, the batch data is rejected. In the exemplary embodiment of the present invention, a batch is defined as one or more trays which have a single set of control samples and to which a common test sequence is applied. As described above, the driver 510 may also receive a multiple batch input where each batch includes only a single tray. In this case, the driver 510 splits the input into separate and distinct run files, one for each batch.

If the action is ignore, no further processing is done on this line but the rest of the data is treated as valid. If the action is to accept the batch as NON-POSID, the type of the batch data is changed to NON-POSID which means the samples are dissociated from their sample ID'S. This action requires that a successful data marriage, described below with reference to Figure 9, be achieved before the batch data may be entered into the database 416.

Phase 2 checks each line in the run file to determine if it contains a header record. If a header record is found, this line is ignored and processing is allowed to continue. Phase 3 checks for any non-sample information and, in so doing, builds a template to translate the file. The template information can be placed in a standalone file or can be in the form of flags placed in the original run file. The Phase 3 information includes the type of test that was run, the identity of the technician who ran it and information which governs how the results obtained from the batch are interpreted. Any given line can satisfy multiple rules in this section. Exemplary items checked in this phase are: Batch Name, Procedure, Tray ID, Tech ID,

Master Lot, Controls, Control Averages, Control Ranges, Control Differences, Cutoff, Cutoff Formula Phase 4 checks for the sample data. A batch is considered NON-POSID if no valid sample IDs can be read from the data file. If at least one sample ID can be read and verified, then the run is considered POSID. A sample ID is verified with the standard database sample

verification routines. In the exemplary embodiment of the invention, the first digit of each sample identifier is a checks-digit. The position of this digit may be changed by the administrator using a configurable parameter. In this instance, the sample verification routines determine if the sample ID is valid by recomputing this check-digit using the other digits in the sample ID. In general, the sample verification routines check the sample information for form and content based on the current system configuration.

Exemplary items checked in this phase are:

Sample ID, Tray Position,

Absorbance, Subbatch Information

If the post-demon 522 does not find a match for a given line in any of the phases, the line is ignored. After the data file has been completely read, the final checks are performed. If the run is POSID and there were no errors, the batch data is entered into the database 416.

If the run is NON-POSID, two configuration parameters, which may be specified by the user, are checked and acted upon. The first configuration parameter

indicates whether a data marriage operation is to be attempted. This operation is described below in the Data Marriage section with reference to Fig. 9. If the

parameter indicates that a data marriage is allowed, the post-demon 522 attempts a data marriage operation. If data marriage is not allowed, the run will be considered NON- POSID.

The second configuration parameter determines whether NON-POSID batches may be entered into the database 416. If this parameter indicates that NON-POSID runs are allowed and the batch data is NON-POSID, then the run data is entered into the database 416. If NON-POSID runs are not allowed and the batch data is NON-POSID, the run data is rejected.

If the new run data has the same tray ID as unaccepted data that already exists on the system, the new run data overwrites the run data currently existing in the database 416. d. Data Marriage

The data marriage section is used when a NON- POSID run is received. The run could have been initially NON-POSID or could have been converted to NON-POSID due to an error condition. In order to perform a data marriage, data from the data file is compared to data in the trays table (not shown) of the database 416. If a match is found, the samples are loaded and the status of the pipettor data is changed to archived. If the match is unsuccessful, the batch remains in its NON-POSID status. The data for this batch may be either accepted or rejected, as described above, as determined by a configuration parameter.

It should be noted that in the exemplary

embodiment of the present invention, a slots table is maintained which correlates tray IDs to sample ids, thus, providing a one to many relation for trays and samples.

The minimum data required for a successful match is the tray ID, the procedure name or assay number, tray position, and the number of samples. If a match of these items is found, then the sample id's from the pipettor data for the batch can be attributed to the sample data in the run file. If a successful match is found, the samples are copied into the results table based on position number. After the data is copied, the batch is considered POSID. The above-described process of a data marriage is summarized and presented as a flowchart in Fig. 9. In Fig. 9, at step 910, the Tray ID is received from the run file. If there is no Tray id, the data marriage fails and control is transferred to the reject step 912. If a tray ID is found at step 910, control is passed to step 914. This step determines if tray position information,

indicating which of the tray positions contain samples, is available from the run file. If not, the marriage is rejected at step 912. If the position data is available then control is transferred to step 916. At step 916, the post-demon 522 determines if pipettor information

corresponding to this tray ID is available in the database

416. If it is not, the marriage is rejected at step 912, otherwise control passes to step 918.

At step 918, the post-demon 522 checks the test number in the pipettor data which is stored in the database 416. If this test number is null, control is passed to step 920. This step attempts to get the sub name from the procedures table in database 416 using the assay number from the run file. If no subname information can be found, the marriage is rejected at step 912. If, however, subname information is found, then control passes to step 926.

At step 918, if the test number in the database 416 was not null, then, at step 922, the post-demon 522 attempts to get the subname data from the database 416 using the test number from the pipettor data and the assay number from the run data. If no test data can be found, the marriage is rejected at step 924. If, however, subname data is found, then control is passed to step 926.

At step 926, the subname data recovered from the database 416 is compared to the batch name in the run file. If these data do not match then the marriage is rejected at step 924, otherwise control passes to step 928. At step 928, if the number of results in the run file matches the number of samples in the pipettor data, control is passed to step 930, otherwise, the marriage is rejected at step 924.

At step 930, the post-demon 522 determines if the tray position data recovered at step 914 matches the pipettor data in the database 416. If any mismatch is found, the marriage is rejected at step 924. If the data are found to match, the sample ID data from the pipettor data in the database 416 is combined with the result data in the run file and the combined data is entered into the database 416. At the same time, the pipettor data in the database 416 is purged at step 934.

The present invention has been described in terms of exemplary embodiments. It is contemplated, however, that it may be practiced with modifications, some of which are outlined above, within the scope of the appended claims.

What is Claimed: 1. An interface system which collects and maintains biological fluid test information from a

plurality of sources, each source having an identity and providing test information in a respective format, and which stores data derived from the test information in a database, said interface system comprising: driver means for receiving said test information from any one of said plurality of sources; means for providing an input value indicating the identity of the one of said plurality of sources and the respective format of said test information provided by the one of said plurality of sources; post processing demon means, responsive to said input value, for parsing said test information received from the one of said plurality of sources to extract the data to be stored into the database. 2. A system in accordance with claim 1, wherein: said post processing demon means includes input means for receiving data from the one of said plurality of sources; and said input value is predetermined for the one of said plurality of sources and associated with the input means. 3. A system in accordance with claim 1, wherein said input value is determined and provided by a post processing demon which compares the received test information to a set of predetermined formats to determine the input value to be provided to the post processing demon means. 4. An interface system for collecting and maintaining biological fluid test information from a plurality of sources and for storing data derived from the test information in a database, said interface system comprising: driver means for receiving said test information from any one of said plurality of sources; preprocessing demon means for examining and identifying said source of said received test information and for providing an indication of the identified source; post processing demon means, responsive to the indication provided by the preprocessing demon means, for parsing said test information to extract the data to be stored into the database. 5. In a system which collects biological fluid test information from a plurality of sources, that provide the information in respectively different formats, and which maintains data representing the biological fluid test information in a database, a data interface which processes the information provided by each of said sources to extract data to be stored in said database, said data interface comprising: driver means, adapted to communicate with any one of said plurality of sources, for receiving said test information; preprocessing demon means for examining the format of the test information, based on a set of master rules, to identify the respective source of the information and to provide an indication of the identification; and post processing demon means, responsive to the indication provided by the preprocessing demon means, for parsing said test information to extract the data therefrom and for entering said extracted data into said database.

6. A system in accordance with claim 4, wherein said test information includes optical absorption information provided by a biological sample reader. 7. A system in accordance with claim 6, wherein said database includes data generated by a pipettor concerning samples processed by the biological sample reader and the post processing demon means marries the stored pipettor data and to the data extracted from the test information before the data is stored into the database. 8. In a system which collects biological fluid test information from a plurality of sources, that provide the test information in respectively different formats, and which maintains data derived from the biological fluid test information in a database, a computer implemented method for processing the information provided by any one of said plurality of sources to generate the data to be stored in the database, said method comprising the steps of: a) receiving, from any one of said plurality of sources, said test information; b) examining said received test information, based on a set of master rules; c) identifying, based on the examination, the one of said plurality of sources which provided the test information; and d) parsing said test information, based on the identification, to extract the data to be stored in the database. 9. A method in accordance with claim 8, wherein the one source of test information includes a biological fluid sample reader which provides optical absorption test information and the database contains data provided by a pipettor related to biological fluid samples which were processed by the reader to generate the optical absorption test information, the method further comprising the steps of: examining the test information provided by the reader to obtain data which may be used to match the test information to the pipettor data in the database; locating the pipettor data in the database which matches the data obtained by examining the test

information; combining the data extracted from the test information with the pipettor data from the database before storing the data extracted from the test information in the database.