Patent Description:
In certain arrangements, a supplier may provide a sample analyzer (possibly also including various supplies and support for the sample analyzer) to a user's facility. The supplier may then charge the user according to the number of tests performed by the sample analyzer. In billing systems for those sample analyzers, not all sample measurements performed by the sample analyzer may be billed. Instead, only sample measurements that are agreed upon between the device provider and the user (e.g., by contractual obligations) may be billed. In such implementations, even if the agreement or contract between the analyzer provider and the user is complicated, it is necessary to accurately identify the sample measurements that are to be charged and reflect those sample measurements in the charged amount.

Existing billing systems may charge a user according to the number of times the analysis server provides analysis data to the user. In such systems, when a sample analyzer installed in a user's facility measures a sample, the measurement data is transmitted to an analysis server via a network, and the analysis server analyzes the measurement data and uses the analysis data. The billing amount is then determined according to the number of times the analysis data is provided.

However, the existing billing systems may charge uniformly for sample measurements that are the source of the analysis data, and any sample measurement performed by the sample analyzer may be charged. Existing billing systems do not judge whether such sample measurements actually exist, or whether such sample measurements should be billed. Therefore, existing billing systems cannot accurately specify the sample measurement to be billed in consideration of various factors.

Accordingly, there is a demand for a new billing system that can accurately identify the sample measurements to be billed and accurately reflect those billable sample measurements in the charged amount. Further, there is a need to provide such sample measurement to a medical doctor. <CIT> discloses a sample analyzer for analysing patient samples based on user selected tests.

In accordance with various embodiments, a method and system for billing for sample tests is disclosed. The billing method takes into account various factors and data in order to provide an accurate billing amount that properly reflects the billable test results.

In one embodiment, a method includes receiving, via network, a plurality of test results from at least one sample analyzer of each of a plurality of customers, selecting test results from the plurality of test results based on a plurality of determination rules adaptable to each of the customers, and determining, for each of the customers, a number of the selected test results for billings to each of the customers. The determination rules may be adaptably defined for each of the customers. The determination rules may be adaptably defined to determine, for each of the customers, whether to select or exclude the test result. The determination rules may be adaptably defined to determine, for each of the customers, which type of test is subjected to a target of the billing.

In certain embodiments, the determination rules are for selecting the test result which is reportable to at least one of a medical doctor or a billing entity, or are for excluding a test result which is not reportable to a medical doctor or a billing entity. In such an instance, the method may further include determining, according to the determination rules for excluding a test result, that a first test result of the plurality of test results is not to be excluded, and incrementing a count number corresponding to a number of reportable test results.

Specifically, the determination rules may include a first rule for selecting the test result of a sample collected from a subject, wherein the first rule is for excluding the test result of a quality control sample, a calibrator sample or a fluid for background check. The determination rules may also include a second rule for excluding the test result which is associated with an error. The determination rules may also include a third rule for excluding the test result which is a duplicate of a retesting, or for excluding the test result whose test item is the same as that of the retesting. The determination rules may also include a fourth rule for selecting the test results based on one or more test items subjected to a target of the billing. With such a fourth rule, determining the number of the selected test results may include determining numbers of the selected test results for each of the test items or a group of the test items.

In another embodiment, a computing system comprises a controller connected to at least one sample analyzer of each of a plurality of customers via network. The controller may be programmed to receive a plurality of test results from the at least one sample analyzer, select test results from the plurality of test results, based on a plurality of determination rules adaptable to each of the customers, and determine, for each of the customers, a number of the selected test results for billings to each of the customers.

In another embodiment, a system includes at least one sample analyzer of each of a plurality of customers, and a computing system connected to the at least one sample analyzer via network. The computing system may be programmed to receive a plurality of test results from the at least one sample analyzer, select test results from the plurality of test results, based on a plurality of determination rules adaptable to each of the customers, and determine, for each of the customers, a number of the selected test results for billings to each of the customers.

<FIG> is a block diagram of an exemplary system configuration in accordance with various embodiments. A system may include a server <NUM>, a database <NUM>, and analyzers <NUM>. The server <NUM> (optionally along with the database <NUM>) may comprise a computing system. As discussed below, the server <NUM> may further comprise a controller. The analyzers <NUM> may be deployed in a customer's laboratory <NUM>. Each laboratory <NUM> may include a single or a plurality of analyzers <NUM>. The analyzers <NUM> may be connected to a network <NUM>. The network <NUM> may be the Internet. The network <NUM> may be established as a virtual private network. The analyzers <NUM> may be connected to the server <NUM> (e.g., connected to the computing system and/or the controller) via the network <NUM>. The analyzers <NUM> send a result of a measurement to the server <NUM> via the network <NUM>. The server <NUM> may store the received results in the database <NUM>. Also, the server <NUM> may execute a plurality of determination rules defined by the database <NUM> to determine a count of reportable sample test results that are to be charged. The determination rules may be used for selecting the reportable sample test result. The rules may be adaptable to each of a plurality of customers. The rules may be adaptably defined for each customer so that, for example, the rules may be defined differently for each customer to suit individual situations (number and types of frequent sample tests) in the laboratory of each customer. The database <NUM> may also store the plurality of determination rules for each customer. The determination rules may be prepared or produced based on a contract between each customer and the provider of the sample analyzers <NUM>. Contracts may be different among customers. Therefore, the plurality of determination rules may also be different among customers. The determination rules may be prepared or produced based on arrangements, other than the contract, between each customer and the analyzer provider. In various examples, multiple laboratories (e.g., 1A, 1B, and 1C) may exist, each of which may be associated with the same or different customers, and which may also include one or more analyzers <NUM>.

The customer may have a contract with a provider of the analyzer <NUM>. The contract may define that the customer shall pay a certain price for a number of reportable test results measured by the analyzer <NUM>. The payment may mean a monthly payment. The server <NUM> calculates, based on the results sent from the analyzers <NUM>, the number of reportable test results for determining the billing amount for the customer.

<FIG> is a block diagram of an exemplary computing system <NUM> in accordance with various embodiments. The computing system <NUM> may include the server <NUM> and, optionally, the database <NUM>. The server <NUM> may include controller <NUM>, which may in turn include a test report calculator <NUM>. The test report calculator <NUM> calculates a number of reportable test results. Based on the number of the reportable test results, a billing amount to a customer for a certain period (e.g., monthly) can be determined. The reportable test result may be a measurement result that can be reported to a doctor or physician who issued an order for a test, or reportable to a billing entity (e.g., an insurance company). For example, the test result may include an erroneous result or a result for a quality control sample measurement. Such result may not be reported to the doctor or physician or the billing entity. If such non-reportable test results are included in a calculation process for the billing amount, the calculated billing amount may not be accurate. Instead, the test report calculator <NUM> according to the present disclosure accurately calculates the reportable test result by excluding the non-reportable test result in the calculation process. The aforementioned determination rules may be adaptably defined to determine, for each of the customers, whether to select or exclude such test result. It may depend on each customer which test result is to be selected to be charged and which test result is to be excluded so as not to be charged. For example, the test results such as the erroneous result or the result for the quality control sample measurement may be selected to be charged for a customer while such test results may be excluded so as not to be charged for other customers.

The test report calculator <NUM> may include a data collector <NUM>, a data retriever <NUM>, a counter <NUM>, and a notifier <NUM>. The data collector <NUM> receives the test results from the analyzers <NUM> and stores the received results in the database <NUM>. For example, the data collector <NUM> may receive a first plurality of test results from one or more sample analyzers <NUM> in a first laboratory (e.g., laboratory 1A) of a first customer, and may receive a second plurality of test results from one or more sample analyzers <NUM> in a second laboratory (e.g., laboratory 1B) of a second customer. The data collector <NUM> may receive the plurality of test results from the one or more sample analyzers <NUM> either periodically (e.g., once a day, once an hour, etc.) or every time the one or more sample analyzers <NUM> perform a sample testing. The data retriever <NUM> retrieves, from the database <NUM>, necessary information for the calculation process for the number of reportable test results or the billing amount. The counter <NUM> calculates the number of reportable test results based on the retrieved information. The notifier <NUM> notifies the customer of the calculated billing amount. Alternatively, the notifier <NUM> notifies another system (such as an enterprise system) of a calculated number of reportable test results, wherein the other system will calculate a billing amount for the customer based on that calculated number of reportable test results.

In accordance with various embodiments, a computing system <NUM> may include the server <NUM> and the database <NUM>. The server <NUM> may comprise a controller <NUM>, which may be configured to perform various functions and/or method steps as described below and herein. The server <NUM>, and/or the controller <NUM>, may include one or more processing devices coupled to one or more memories, for example, with a data bus. The processing device may be a Central Processing Unit (CPU), microcontroller, or a microprocessor, and/or may include or be implemented with an Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD), or Field Programmable Gate Array (FPGA); or as circuitry that includes discrete logic or other circuit components, including analog circuit components, digital circuit components or both; or any combination thereof. The circuitry may include discrete interconnected hardware components or may be combined on a single integrated circuit die, distributed among multiple integrated circuit dies, or implemented in a Multiple Chip Module (MCM) of multiple integrated circuit dies in a common package, as examples. The memory may comprise a flash memory, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM), a Hard Disk Drive (HDD), other magnetic or optical disk, or another machine-readable nonvolatile medium or other tangible storage mediums other than a transitory signal. The memory may store therein software modules and instructions that, when executed by the processing device or the controller <NUM>, cause the processing device or the controller <NUM> to implement any of the processes described herein or illustrated in the drawings. The memory may also store other data for use by the processing device or controller <NUM>. The server <NUM>, and thus, the controller <NUM>, may include one or more network interfaces configured to communicate over a network. Additionally, the analyzers <NUM> may include a similar structure, including a processor, memory, storage, and a network interface. In this manner, the server <NUM> or controller <NUM> may communicate with the analyzers <NUM> via a network.

<FIG> is a block diagram of an exemplary data structure of a database <NUM> in accordance with various embodiments. The database <NUM> may be configured by a relational database (RDB). The database <NUM> stores data representing list of analyzers <NUM> deployed in the customers' laboratory <NUM> or laboratories <NUM>. The customer ID <NUM> may represent a customer. The site ID <NUM> and instrument ID <NUM> may represent the customer's laboratory <NUM> and analyzers <NUM> deployed in each laboratory <NUM>, respectively. The instrument ID <NUM> may represent various analyzers <NUM> such as hematology analyzers, smear slide makers, urine analyzers, immunology analyzers, blood coagulation analyzers, or gene testing analyzers. That is, in various embodiments, the data shown in <FIG> may represent a laboratory configuration of the customer per customer ID.

<FIG> is a block diagram of an exemplary data structure which may represent the contract between the customer and the provider of the analyzer in accordance with various embodiments. The contract ID <NUM> may represent the contract between the customer and the provider of the analyzer <NUM>. For example, the analyzer <NUM> corresponding to at least one of the instrument ID <NUM> is a hematology analyzer. For example, the hematology analyzer may be able to measure following measurement items: RBC, HCT, MCV, MCH, MCHC, PLT, MPV, WBC, NRBC#, NRBC%, BASO#, BASO%, HGB, WBC, NEUT#, NEUT%, LYMPH#, LYMPH%, MONO#, MONO%, EO#, EO%, IG#, IG%, RET#, RET%, PLT, IRF, RET-He, etc. In various embodiments, as shown in <FIG>, the contract ID <NUM> may be associated with each instrument ID <NUM> via a particular site ID <NUM> at which the analyzer corresponding to the instrument ID <NUM> is installed. In other approaches, the contract ID <NUM> may be directly associated with each instrument ID <NUM>.

In various examples, the contract may define the payment structure and arrangement for the measurements by the analyzer <NUM> according to various measurement items. The contract may include cost information <NUM> for various reports, which may include one or more prices <NUM> and target type of tests <NUM>. The price <NUM> may represent an amount of payment per measurement. The price <NUM> may be associated with a target type of test(s) <NUM>. The target type of test(s) <NUM> may contain a list of measurement items subjected to the price <NUM>. In some examples, some target type of test(s) <NUM> may combine all of or more than one of the measurement items into one price <NUM>. In other examples, some target type of test(s) <NUM> may correspond to individual measurement item (e.g., the price <NUM> may be defined for each of the measurement items) or groups of measurement items. In certain approaches, the target type of test(s) <NUM> may contain a list of some measurement items among all of items. In various examples, the contract may define non-target type of test for which the provider does not bill to the customer. The non-target type of test may include a test for a non-patient sample (such as a quality control sample, a calibrator sample, a fluid used for a background check), a test that are associated with an error (such as a measurement error, a sample ID read error), duplicate test (such as a rerun test, reflex test). The aforementioned determination rules may be adaptably defined to determine, for each of the customers, which type of test is subjected to a target of the billing. It may depend on each customer which type of test is to be defined as the target type of test and which type of test is to be defined as the non-target type of test. Therefore, tests such as the test for the non-patient sample, the test associated with the error and the duplicate test may be defined as the target type of test for a customer while such tests may be defined as the non-target type of test for other customers. It may also depend on each customer which sample is defined as a sample for the non-target type of test among the non-patient samples (such as the quality control sample, the calibrator sample, the fluid used for the background check), or which error is defined as an error for the non-target type of test among the errors (such as the measurement error, the sample ID read error), or which test is defined as a duplicate test for the non-target type of test among the tests (such as the rerun test, reflex test). The target type of test and the non-target type of test may be adaptably defined for each customer.

The contract may be established per discipline such as hematology, urine, blood coagulation, immunology, etc. For example, between the customer and the provider of the analyzer <NUM>, the contract may be established for the hematology discipline. In such an exemplary case, the instrument ID <NUM> associated with the contract ID <NUM> may represent an analyzer <NUM> for hematology testing, and the target type of test <NUM> may represent measurement items for hematology testing.

<FIG> is a block diagram of an exemplary data structure of a measurement result in accordance with various embodiments. The test result <NUM> may represent the measurement result of the analyzer <NUM> which is represented by the instrument ID <NUM>. The test result <NUM> is associated with the sample ID <NUM> and the instrument ID <NUM>. The sample ID <NUM> and instrument ID <NUM> are associated with the customer ID <NUM>. The test result <NUM> may comprises a type of test <NUM> and, optionally, a value <NUM> associated with the type of test <NUM>. The type of test <NUM> may represent one of the measurement items. In the exemplary data structure shown in the <FIG>, the test result <NUM> represents a result of a hematology test, though other types of tests are possible. The value <NUM> may represent a measured valued of the measurement item (e.g., test item) subjected to a test order.

The test result <NUM> may be associated with one or more flags. Each flag may include specific information associated with the flag, such as which test generated the flag or other information. In various embodiments, the rest result <NUM> may be associated with a rerun flag <NUM>, a reflex flag <NUM>, an error flag <NUM>, a patient sample flag <NUM>, and/or a date and time <NUM>. The rerun flag <NUM> identifies whether the test result <NUM> is a result of a rerun test. The analyzer <NUM> may set the rerun flag <NUM> flag as "<NUM>" if the rerun test is issued, and may associate it with a test result corresponding to a measurement which causes the rerun test, and then may send the test result with this flag to the server <NUM>. The reflex flag <NUM> identifies whether the test result <NUM> is a result of a reflex test. The analyzer <NUM> may set the reflex flag <NUM> as "<NUM>" if the reflex test is issued, and associate it with a test result corresponding to a measurement which causes the reflex test, and then may send the test result with this flag to the server <NUM>. The error flag <NUM> identifies whether the test result <NUM> is an erroneous result. The analyzer <NUM> may set the error flag <NUM> as "<NUM>" if the error (e.g., a measurement error) occurs, and may associate it with corresponding test result, and then may send the test result with this flag to the server <NUM>. The measurement error may relate to mixing, blood too thick, or other conditions with the patient's blood where the analyzer's internal verification process did not allow a result. The patient sample flag <NUM> identifies whether the test result <NUM> is a result for a measurement of a non-patient sample, such as quality control sample, a calibrator sample, a fluid used for background check, etc. The analyzer <NUM> may set the patient sample flag <NUM> as "<NUM>" if, for example, a measurement is performed for a predetermined sample such as a QC sample, a calibrator sample, or the fluid used for background check, etc. The analyzer <NUM> may set the patient sample flag <NUM> as "<NUM>" if the measurement is performed for a patient sample. The analyzer <NUM> may send the test result with the patient sample flag to the server <NUM>. The date and time <NUM> represents a date and time of the measurement. Other flags may be possible, as well. For example, a LIS (Laboratory Information System) flag may indicate whether or not the test result <NUM> was sent to the LIS for the laboratory <NUM>.

Referring briefly to <FIG>, in various approaches, the data collector <NUM> of the server <NUM> may receive, from the analyzer <NUM>, information corresponding to the sample ID <NUM>, the instrument ID <NUM>, the test result <NUM>, flags <NUM>-<NUM>, and the date and time <NUM>. The data collector <NUM> may associate the received information with the customer ID <NUM> and then store the information into the database <NUM>. The data collector <NUM> may recognize the corresponding customer ID <NUM> to be associated with the received information based on a sender's address (e.g., IP address of the sender). The database <NUM> may contain relation information between the customer ID <NUM> and the sender's address, and the data collector <NUM> may refer to the database <NUM> and recognize corresponding customer ID <NUM> based on the sender's address.

<FIG> is a flow diagram of an exemplary algorithm or method for test report calculation in accordance with various embodiments. In various embodiments, the server <NUM>, the controller <NUM>, the computing system <NUM>, generally, and/or the analyzers <NUM> are configured and/or programmed to perform the various steps depicted in the method of <FIG> (and in <FIG>, described below). In accordance with various embodiments, the test report calculator <NUM> of the server <NUM> calculates the number of reportable test results according to the exemplary algorithm shown in <FIG> and <FIG>.

At S90, the data collector <NUM> receives the test results from the analyzers <NUM> and stores the received results in the database <NUM>. For example, the data collector <NUM> may receive a first plurality of test results from one or more sample analyzers <NUM> in a first laboratory (e.g., laboratory 1A) of a first customer, and may receive a second plurality of test results from one or more sample analyzers <NUM> in a second laboratory (e.g., laboratory 1B) of a second customer. The data collector <NUM> may receive the plurality of test results from the one or more sample analyzers <NUM> either periodically (e.g., once a day, once an hour, etc.) or every time the one or more sample analyzers <NUM> perform a sample testing.

At S100, the data retriever <NUM> of the server <NUM> retrieves data relating to the test report calculation. For example, the data retriever <NUM> retrieves data relating to or indicating (e.g., listing) customers subjected to the test report calculation. Then, the counter <NUM> identifies a customer ID <NUM> corresponding to a customer subjected to the test report calculation. After the test report calculation for the identified customer ID <NUM> is completed, then the counter <NUM> identifies another customer ID <NUM> corresponding to another customer subjected to the test report calculation. This process may repeat until test report calculations for all customer IDs subject to the test report calculation are completed.

The counter <NUM> identifies a contract ID <NUM> associated with the identified customer ID <NUM>. If a plurality of contract IDs <NUM> are associated with the identified customer ID <NUM>, the counter <NUM> then identifies those contract IDs <NUM>.

At S102, the counter <NUM> identifies a site ID <NUM> associated with the customer ID <NUM>, and then identifies an instrument ID <NUM> associated with the identified site ID <NUM>. If a plurality of site IDs <NUM> are associated with the identified customer ID <NUM>, the counter <NUM> identifies these site IDs <NUM>. If a plurality of instrument IDs <NUM> are associated with the identified site ID <NUM>, the counter <NUM> identifies these instrument IDs <NUM>. For example, the counter <NUM> identifies all site IDs <NUM> and instrument ID <NUM> corresponding to the customer ID <NUM>. As discussed above, the contract may associate the sample analyzer (e.g., instrument ID <NUM>), one or more test items (e.g., target type of tests <NUM>) subjected to a target of the billing, and a price <NUM> per testing.

At S103, the counter <NUM> performs a process for calculating the test report calculation. An exemplary algorithm or method for step S103 is shown explained below with respect to <FIG>.

At S104, after the counter <NUM> completes the test report calculation for a certain customer, then the counter <NUM> may move to the calculation process for another customer. The counter <NUM> repeats the calculation process until the process for all customers subjected to the test report calculation is completed. Alternatively, the counter <NUM> may perform the calculation process for one or some customers, one or some locations, or one or some analyzer.

At S105, the notifier <NUM> sends a calculated number of the reportable test results to customers or to another computing system such as an enterprise system. The notifier <NUM> may send a notification including the calculated number to the customers. The notifier <NUM>, for example, identifies correspondences (e.g., e-mail address) of the customers based on the information stored in the database <NUM> and then may send the notification to the identified correspondences.

<FIG> is a flow diagram of additional details of the exemplary algorithm or method for test report calculation of <FIG> in accordance with various embodiments. In particular, <FIG> illustrates additional details of the step S103 of <FIG> for calculating the number of test reports during a certain period. Specifically, <FIG> illustrates details of a method for selecting test results from the plurality of test results, based on a plurality of determination rules (e.g., S1033 - S1036) adapted to the customer identified at S100 which are applied to the test result, and a method for determining a number of the selected test results for a billing to the customer. As stated above, the server <NUM>, the controller <NUM>, the computing system <NUM>, generally, the counter <NUM>, and/or the analyzers <NUM> are configured and/or programmed to perform the various steps depicted in the method of <FIG>.

At S1030, the counter <NUM> selects the site ID <NUM> identified in step S102. If a plurality of site IDs are identified in the step S102, the counter <NUM> selects one of the site IDs <NUM> identified in S1030. At S1031, the counter <NUM> selects the instrument ID <NUM> associated with the selected site ID <NUM>. If a plurality of instrument IDs are associated with the selected site ID <NUM>, the counter <NUM> selects one of the instrument IDs <NUM> in step S1031. In this step, the counter <NUM> selects an instrument ID <NUM> which has not yet been selected.

At S1032, the counter <NUM> selects the test result <NUM> associated with the selected instrument ID <NUM>. The counter <NUM> selects the test result <NUM> which corresponds to a measurement by the analyzer <NUM> during the certain period (e.g., a test result <NUM> measured within a month subject to the test report calculation). If a plurality of test results <NUM> are associated with the selected instrument ID <NUM>, the counter <NUM> selects one of the test results <NUM> in this S1032 step. In this step, the counter <NUM> selects a test result <NUM> that has not yet been selected. In this manner, the method further includes selecting test results based on the contract, the plurality of determination rules, and the analyzer identification information for identifying the one or more analyzers which are installed in the laboratory.

In the following steps (i.e., steps S1033-S1036), the counter <NUM> tests or compares each test result according to a set of determination rules to determine whether to count them as a reportable test result or to exclude them from the count of reportable test results. If, after being tested or compared to the determination rules, the counter <NUM> determines that the test result is not to be excluded, the counter <NUM> increments a count number that corresponds to the number of reportable test results. In one example, the determination rules can be considered as being for selecting test results which are reportable to a medical doctor or a billing entity (e.g., an insurance company or other entity that ordered the test). In another example, the determination rules can be considered as being for excluding a test result that is not reportable to a medical doctor or a billing entity. In various embodiments, the determination rules can comprise first, second, and/or third rules (or more), which are discussed in further detail below.

At S1033, the counter <NUM> examines whether the test result <NUM> is a result of the measurement for a non-patient sample (such as quality control sample, a calibrator sample, a fluid used for background check) or not. Stated another way, the counter <NUM> applies a first determination rule for selecting the test results of a sample collected from a subject. The first determination rule thus may be for excluding the test result of a quality control sample, a calibrator sample or a fluid for background check. For example, the counter <NUM> examines, based on the patient sample flag <NUM>, whether the test result <NUM> is a result of the measurement for a non-patient sample or not. If it is not a patient sample, the counter <NUM> skips to step S1038, and thus does not increment the count number for the target type of test. However, if counter <NUM> does determine that the test sample is a patient sample, the counter <NUM> then moves to step S1034. Thus, by performing step S1033, the counter <NUM> excludes test results <NUM> associated with the non-patient samples (such as a QC sample or a calibration sample) from the counting process of the reportable test results. It may be adaptable to each customer whether to apply the first determination rule to the test results. The first determination rule may not be applied when determining a count of reportable test results for some customers.

At S1034, the counter <NUM> examines whether the test result <NUM> relates to an error or not. Stated another way, the counter <NUM> applies a second determination rule for excluding test results that are associated with an error. For example, the counter <NUM> examines, based on the error flag <NUM>, whether the test result <NUM> relates to an error or not. If it is a test result relating to an error, the counter <NUM> skips to step S1038, and thus does not increment the count number for the target type of test. However, if the test result is not related to the error, the counter <NUM> then moves to step S1035. Thus, by performing step S1034, the counter <NUM> excludes test results <NUM> relating to the error from the counting process of the reportable test results (e.g., the erroneous result may not be suitable for reporting to the doctor/physician or billing entity). It may be adaptable to each customer whether to apply the second determination rule to the test results. The second determination rule may not be applied when determining a count of reportable test results for some customers.

At S1035, the counter <NUM> examines whether the test result <NUM> is a duplicate of the rerun or reflex test. Stated another way, the counter <NUM> applies a third determination rule for excluding test results that are a duplicate of a retesting, and/or for excluding test results corresponding to a test item that is the same as that of the retesting. For example, the counter <NUM> examines, based on the rerun flag <NUM> and/or the reflex flag <NUM>, whether the test result <NUM> is the duplicate of the rerun or reflex test. If the test result <NUM> is a duplicate of the rerun or reflex test, the counter <NUM> skips to step S1038, and thus does not increment the count number for the target type of test. However, if the test result <NUM> is not a duplicate, the counter <NUM> moves to step S1036. Thus, by performing step S1035, the counter <NUM> excludes the test result <NUM> which are duplicate of a rerun or reflex test from the counting process of the reportable test results (e.g., such duplicative test result may not be suitable for reporting to the doctor/physician or billing entity). The counter <NUM> may examine whether the test result <NUM> is a duplicate of the rerun or reflex test by checking the sample ID. If the same Sample ID already exists in the Database <NUM>, the counter <NUM> may determine the test result <NUM> is duplicate. It may adaptable to each customer whether to apply the third determination rule to the test results. The third determination rule may not be applied when determining a count of reportable test results for some customers.

At S1036, the counter <NUM> may examine whether the test result <NUM> includes the value <NUM> of the target type of test <NUM> associated with the customer ID identified at S100. For example, the counter <NUM> examines whether at least one of the type of tests <NUM> of the test result <NUM> corresponds to the measurement items listed in the target type of test <NUM>. The counter <NUM> may identify the target type of test <NUM> according to the instrument ID <NUM> selected at step S1031 (as shown in <FIG>, the target type of test <NUM> is associated with the instrument ID <NUM>). If the test result <NUM> includes the value <NUM> of the target type of test <NUM>, the counter <NUM> performs step S1037 by incrementing the count. If the test result <NUM> does not include the measured value <NUM> of the target type of test <NUM>, the counter <NUM> skips to step S1038, and thus does not increment the count number for the target type of test. For example, by performing step S1036, the counter <NUM> excludes test results <NUM> that do not include the result subjected to the contract. For example, the test result <NUM> relating to the selected instrument ID <NUM> may be related to a discipline not corresponding to the contract ID <NUM>, therefore, such test result <NUM> may be excluded from the counting process of the reportable test results since the test result <NUM> does not correspond to the contract. The measurement items listed in the target type of test <NUM> may be different among customers. Therefore, at S1036, the counter <NUM> executes or implements a determination rule adapted to the customer identified at S100 to examine whether a test result corresponds to the measurement items listed in the target type of test <NUM>.

At S1037, the counter <NUM> determines that the test result <NUM> is to be included in a count of reportable test results. Put another way, the controller <NUM> determines, according to the determination rules for excluding a test result, that a first test result of the plurality of test results is not to be excluded. Accordingly, the counter <NUM> increments a count number for the target type of test <NUM>. In one example, a count number is provided for each of the target type of test <NUM>. In other examples, a count number is provided for sets or groups of target types of tests <NUM>. In another example, one count number is provided for all target types of tests <NUM>.

At S1038, the counter <NUM> examines whether all test results <NUM> have been examined. For example, a plurality of test results <NUM> are associated with the instrument ID <NUM> selected at S1031. The counter <NUM> examines if all of the plurality of test results <NUM> have been examined though one or all of steps S1033-S1036. If not, the counter <NUM> moves to step S1039. If the counter <NUM> has examined all of plurality of test results <NUM> for an instrument ID, the counter <NUM> moves to step S1040.

At S1039, the counter <NUM> selects another test result <NUM>. The counter <NUM> selects a test result <NUM> that it has not selected yet. Then, the counter <NUM> moves back to step S1033 to repeat the process with the newly selected test result <NUM>.

At S1040, the counter <NUM> examines whether all instrument IDs <NUM> have been examined. For example, a plurality of instrument IDs <NUM> may be associated with the site ID <NUM> selected at step S1030. The counter <NUM> examines if all of the plurality of instrument IDs <NUM> (really, all of the test results <NUM> of all of the plurality of instrument IDs <NUM>) have been examined through one or more of the steps S1031-S1040. If not, the counter <NUM> moves to step S1041 to select another instrument ID. If the counter <NUM> has examined all of the plurality of instrument IDs <NUM>, then the counter <NUM> moves on to step S1042.

At S1041, the counter <NUM> selects another instrument ID <NUM>. The counter <NUM> selects an instrument ID <NUM> that has not yet been selected. Then, the counter <NUM> returns back to step S1032 to repeat the process with the newly selected instrument ID <NUM>.

At S1042, the counter <NUM> examines whether all site IDs <NUM> have been examined. For example, a plurality of site IDs <NUM> may be associated with the customer ID <NUM> identified at step S100 (in <FIG>). The counter <NUM> examines if all of the plurality of site IDs <NUM> have been examined though one or more of steps S1030-S1042. If not, the counter <NUM> moves to step S1043. If the counter <NUM> has examined all of the plurality of site IDs <NUM>, then the counter <NUM> moves to step S1044.

At S1043, the counter <NUM> selects another site ID <NUM>. The counter <NUM> selects a site ID <NUM> that has not yet been selected. Then, the counter <NUM> moves back to step S1031 to repeat the process with the newly selected site ID <NUM>.

At S1044, the counter <NUM> determines the count number as number of test reports. For example, the count number is provided for each of the target type of test <NUM> or groups of target types of tests <NUM>. Therefore, the counter <NUM> may determine the number of the test reports for each of the target type of test <NUM>. In this exemplary case, an amount of the payment is determined per the target type of test <NUM> (e.g., the price <NUM> is multiplied by the number of the test reports for the corresponding target type of test <NUM>). In one approach, the counter <NUM> may determine the amount of the payment per instrument ID <NUM>. In this exemplary case, the counter <NUM> summarizes the number of test reports corresponding to the instrument ID <NUM>. The counter <NUM> may determine the amount of the payment per site ID <NUM>. In this exemplary case, the counter <NUM> summarizes the number of test reports corresponding to the site ID <NUM>. The counter <NUM> may determine the amount of the payment per customer ID <NUM>. In this exemplary case, the counter <NUM> summarizes the number of test reports corresponding to the site IDs <NUM> and the instrument IDs <NUM> for the customer ID <NUM>. In another embodiment, the counter <NUM> may simply communicate, e.g., via the notifier <NUM>, another computer system (such as an enterprise system) of the calculated count of the test reports corresponding to each instrument ID <NUM>, each site ID <NUM>, and/or each customer ID <NUM>. Thereafter, the other computer system may be tasked with determining a final bill based on the count, the contract, and/or one or more other factors.

Returning to <FIG>, at S104, the counter <NUM> may determine if there are any other customer IDs <NUM> that require counting. If so, the counter <NUM> will repeat the above process for the test results associated with that customer ID <NUM>. Specifically, the counter <NUM> may select second test results from the second plurality of test results received from the one or more sample analyzers in the second laboratory, based on a second plurality of determination rules adapted to the second customer, which are applied to the second test results. The second plurality of determination rules may be different from the first plurality of determination rules. The counter <NUM> may then determine a number of the selected second test results for a billing to the second customer. This process can repeat again for a third and other customer IDs <NUM>. Accordingly, an accurate count of reportable test results for one or all customers can be determined.

In various embodiments, the above described methods and systems may be implemented in a cloud-based system. <FIG> is a block diagram of an exemplary cloud-based system configuration in accordance with various embodiments. A cloud system <NUM> is connected over the network <NUM> to the laboratory <NUM> of the customer. The laboratory <NUM> may include a local system <NUM>, the analyzer(s) <NUM>, and a laboratory information system (LIS) <NUM>. The local system <NUM> may include a local manager <NUM> that acts as an agent for transferring data back and forth between an interface concentrator <NUM> and a server <NUM> of the cloud system <NUM>. The local manager <NUM> may be the same device having functions of the interface concentrator <NUM>, or may be separate from the interface concentrator <NUM>. The interface concentrator <NUM> may simplify interfaces between the analyzer(s) <NUM> and minimize the LIS <NUM> connectivity to a single interface. The single interface may use, for example, ASTM, HL7 or the like.

The cloud system <NUM> may have a plurality of servers <NUM> (e.g., servers 20a-20n). The servers <NUM> may be implemented in a data center. The details of the server <NUM> are described in the <FIG> and corresponding descriptions. The cloud system <NUM> may be accessible from a web browser deployed in a user terminal such as a computer, PC, tablet, smartphone, etc. The cloud system <NUM> may be accessible by multiple laboratories <NUM> and accessible from anywhere having Internet access. The cloud system <NUM> can consolidate multiple test results <NUM> from multiple laboratories <NUM>.

<FIG> is a block diagram illustrating communication with a local or cloud-based system in accordance with various embodiments. The system shown in <FIG> illustrates an exemplary embodiment for communication of a user terminal <NUM> with the cloud system <NUM>. The user of the user terminal <NUM> may be, in various embodiments, laboratory workers accessing the test results <NUM> and the amount of payment. The communication by the user terminal <NUM> with the cloud system <NUM> may be through the network <NUM>. The user of the user terminal <NUM> may access to the cloud system <NUM> via the web browser or other software of the user terminal <NUM>. The user terminal <NUM> may be a computer, PC, tablet or smartphone and may include an input device, a display, or a camera which constitutes a user interface. The input device may be a keyboard, touch panel, keypad, a cursor control device, etc..

<FIG> is a block diagram of an exemplary local manager in accordance with various embodiments. The local manager <NUM> may include a data synchronizer <NUM> that transfers data to the servers <NUM> of the cloud system <NUM>. The data synchronizer <NUM> also receives data from the cloud system <NUM>. The data synchronizer <NUM> may also transfer the test result <NUM> sent from the analyzer <NUM> to the cloud system <NUM>. The data synchronizer <NUM> may transfer/receive the data to/from the cloud system <NUM> automatically and without user intervention. An IP address may be assigned to the local manager <NUM>. The cloud system <NUM> may recognize the IP address assigned to the local manager <NUM>. The cloud system <NUM> then allows access via the IP address. The data synchronizer <NUM> uses the IP address to communicate with the cloud system <NUM>. The data synchronizer <NUM> may operate in a background to be automated and without user intervention. The data synchronizer <NUM> may be able to transfer the test result <NUM> to the cloud system <NUM> without intervention since it operates in a background of the laboratory system. The operation in the background may mean that the data synchronizer <NUM> automatically receives the test result <NUM> from the analyzer <NUM> without the user intervention. The operation in the background may mean that the data synchronizer <NUM> automatically transfers the test result <NUM> to the cloud system <NUM> without the user intervention.

The local manager <NUM> may include an order manager <NUM>. The order manager <NUM> manages a test order, which may be issued by the LIS <NUM> or the cloud system <NUM>. The LIS <NUM> or the cloud system <NUM> may issue a rerun/reflex order. The order manager <NUM> sends, to the analyzer <NUM>, the test order and the rerun/reflex order.

The database <NUM> may store information relating to the test order and the test result <NUM>. The database <NUM> may store information relating to the test result <NUM> sent from the analyzer <NUM>. The database <NUM> may store information relating to the test order sent from the LIS <NUM> or the cloud system <NUM>. As information relating to the test result <NUM>, the database <NUM> may store: the sample ID <NUM>, the instrument ID <NUM>, the type of test <NUM>, the value <NUM>, the rerun flag <NUM>, the reflex flag <NUM>, the error flag <NUM>, the patient sample flag <NUM>, the date and time <NUM>. The data synchronizer <NUM> may transfer the above mentioned information to the cloud system <NUM>.

<FIG> is a block diagram of an exemplary cloud-based system in accordance with various embodiments. The server <NUM> may include the test report calculator <NUM> as shown in <FIG>, a user management <NUM>, and a result management <NUM>.

The user management <NUM> manages user accounts which are allowed to access to the cloud system <NUM>. The user management <NUM> manages a user's login according to account information (e.g., a user name, a password, information for biometric authentication, etc) stored in the database <NUM>. When a user accesses the cloud system <NUM> for logging in through the web browser of the user terminal <NUM>, the user management <NUM> may require a user ID and a password to allow the user to log in.

The result management <NUM> may provide a GUI which allows a user to manage the test results sent from the analyzer <NUM> via the local manager <NUM>. The result management <NUM> may provide the GUI to the user terminal <NUM>. The user may be able to view the test result and the amount of the payment relating to the test result via the GUI shown in the user terminal <NUM>. In this exemplary case, the notifier <NUM> of the test report calculator <NUM> may provide the amount of the payment calculated by the counter <NUM> to the GUI shown in the user terminal <NUM>.

So configured, and in accordance with the various methods, systems, and embodiments disclosed above, various technical advantages are realized. Primarily, accurate reportable test result counts are possible, which account for test results that cannot otherwise be counted. As such, accurate and transparent client billing can be achieved.

The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media, or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment and the phrase "in another embodiment" as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

For example, terms, such as "and", "or", or "and/or," as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, "or" if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term "one or more" as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as "a," "an," or "the," may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context.

Claim 1:
A method implemented by a computing system, comprising:
receiving, via network, a plurality of test results from at least one sample analyzer of each of a plurality of customers;
selecting test results from the plurality of test results, based on a plurality of determination rules adaptable to each of the customers; and
determining, for each of the customers, a number of the selected test results, wherein
the determination rules are for selecting the test result which is reportable to a medical doctor,
the determination rules comprise a first rule for selecting the test result of a sample collected from a subject,
the first rule is for excluding the test result of a quality control sample, a calibrator sample or a fluid for background check,
the determination rules comprise a second rule for excluding the test result which is associated with an error, and
the determination rules comprise a third rule for excluding the test result which is a duplicate of a retesting.