[0001] The subject application claims benefit under 35 USC § 119(e) of US provisional Application No. 62/588,689, filed November 20, 2017. The entire contents of the above-referenced patent application are hereby expressly incorporated herein by reference.

BACKGROUND

[0002] Point of care testing may be defined as medical diagnostic testing that is performed at a location where care or other treatment is provided. Point of care testing may also be referred to as near-patient testing, remote testing, satellite testing, and rapid diagnostics testing. Point of care test results may be made available relatively quickly so that they can be acted upon without delay. This increases the likelihood that the patient, physician, and care team will receive the results quicker, which allows for better and more immediate clinical management decisions to be made.

SUMMARY

[0003] Disclosed herein are methods and systems for analyzing one or more samples. A point of care system may comprise a plurality of diagnostic engines and an instrument data manager (IDM) in electronic communication with each of the diagnostic engines. Each of the diagnostic engines may perform testing on a sample. The IDM may be configured to communicate with each of the plurality of diagnostic engines to enable a plurality of tests to be performed on multiple different samples substantially simultaneously by a plurality of users using the plurality of diagnostic engines and to present a single user interface for managing testing by the plurality of diagnostic engines and for receiving measured results of tests performed by each of the plurality of diagnostic engines.

[0004] The plurality of diagnostic engines may for example comprise at least one of a blood gas diagnostic engine, a cardiac diagnostic engine, a coagulation diagnostic engine, a diabetes diagnostic engine, and a urinalysis diagnostic engine, and one or more of the plurality of diagnostic engines may be different types of diagnostic engines. The one or more diagnostic engines may perform a test and may store (e.g., buffer) a measured result of that test for a limited period until the measured result is received by the IDM or until an application running on the diagnostic engine shuts down. The user interface may display one or more icons each representing a given one of the diagnostic engines associated with the IDM.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The following detailed description is better understood when read in conjunction with the appended drawings. For the purposes of illustration, examples are shown in the drawings; however, the subject matter is not limited to specific elements and instrumentalities disclosed. In the drawings:

[0006] FIG. 1 shows an example system diagram according to an aspect of the disclosure;

[0007] FIG. 1A shows an example diagnostic engine;

[0008] FIG. 2 shows a flow chart of an example method according to an aspect of the disclosure;

[0009] FIG. 3 shows a flow chart of an example method according to an aspect of the disclosure;

[0010] FIG. 4A shows example icons presented by a user interface for representing a plurality of diagnostic engines;

[0011] FIG. 4B shows an example operator login page of the user interface;

[0012] FIG. 4C shows an example prompt displayed by the user interface;

[0013] FIG. 4D shows an example patient information page of the user interface;

[0014] FIG. 4E shows example icons presented by a user interface for representing the plurality of diagnostic engines;

[0015] FIG. 4F shows an example prompt displayed by the user interface;

[0016] FIG. 4G shows an example patient information page of the user interface;

[0017] FIG. 4H shows example icons presented by a user interface for representing the plurality of diagnostic engines;

[0018] FIG. 41 shows an example prompt displayed by the user interface;

[0019] FIG. 4J shows an example patient information page of the user interface;

[0020] FIG. 4K shows example icons presented by a user interface for representing the plurality of diagnostic engines;

[0021] FIG. 4L shows example calculated results presented by the user interface;

[0022] FIG. 4M shows an example prompt displayed by the user interface;

[0023] FIG. 4N shows example icons presented by a user interface for representing the plurality of diagnostic engines; [0024] FIG. 40 shows example calculated results presented by the user interface;

[0025] FIG. 4P shows an example prompt displayed by the user interface;

[0026] FIG. 4Q shows example icons presented by a user interface for representing the plurality of diagnostic engines;

[0027] FIG. 4R shows example calculated results presented by the user interface;

[0028] FIG. 4S shows an example prompt displayed by the user interface;

[0029] FIG. 4T shows example icons presented by a user interface for representing the plurality of diagnostic engines;

[0030] FIG. 4U shows an example prompt displayed by the user interface;

[0031] FIG. 4V shows example icons presented by a user interface for representing a plurality of diagnostic engines;

[0032] FIG. 5A shows example icons presented by a user interface for representing a plurality of diagnostic engines;

[0033] FIG. 5B shows an example operator login page of the user interface;

[0034] FIG. 5C shows an example prompt displayed by the user interface;

[0035] FIG. 5D shows an example patient information page of the user interface;

[0036] FIG. 5E shows example icons presented by a user interface for representing the plurality of diagnostic engines;

[0037] FIG. 5F shows an example operator log out page of the user interface;

[0038] FIG. 5G shows example icons presented by a user interface for representing the plurality of diagnostic engines;

[0039] FIG. 5H shows an example operator login page of the user interface;

[0040] FIG. 51 shows an example prompt displayed by the user interface;

[0041] FIG. 5J shows an example patient information page of the user interface;

[0042] FIG. 5K shows example icons presented by a user interface for representing the plurality of diagnostic engines;

[0043] FIG. 5L shows example calculated results presented by the user interface;

[0044] FIG. 5M shows an example prompt displayed by the user interface;

[0045] FIG. 5N shows example icons presented by a user interface for representing the plurality of diagnostic engines; and

[0046] FIG. 50 shows example icons presented by a user interface for representing the plurality of diagnostic engines. DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0047] Point of care testing may be defined as medical diagnostic testing that is performed at a location where care or other treatment is provided. A point of care system or device may be located, for example, in a hospital, nursing home, clinic, or in the home of an individual patient. Point of care testing may also be referred to herein as near-patient testing, remote testing, satellite testing, and rapid diagnostics testing.

[0048] Point of care systems typically comprise a single diagnostic engine, a processor, and a user interface for viewing the results generated by the diagnostic engine. For example, a point of care system for diabetes testing may comprise a single diagnostic engine for receiving a blood sample, a processor that is configured to process a single blood sample test at a time, and a user interface for displaying the results of the test on that sample. In certain prior art systems, the user interface and the diagnostic engine are located within the same housing. Because the user interface is typically attached to the diagnostic engine, only one test may usually be performed at one time, by a single user, using the single diagnostic engine. Even in an example where the user interface is capable of being paired with more than one diagnostic engine, the user interface may not allow multiple tests to be controlled simultaneously, let alone allowing multiple different kinds of tests to be performed by a multitude of different users.

[0049] In point of care locations where multiple operators are performing tests on multiple patients, it may be necessary to have numerous point of care systems each having their own user interface. For example, a first user (e.g., a nurse or lab technician) may insert a blood sample into a diabetes diagnostic engine while a second user may insert a urine sample into a urinalysis diagnostic engine. The first user may receive results from a first user interface associated with the diabetes diagnostic engine while the second user may receive results from a second user interface associated with the urinalysis diagnostic engine. The multiple user interfaces may result in unnecessary costs to the testing facility and may take up unnecessary space in the testing facility. Additionally, if an upgrade were to be made to a given one of the diagnostic engines, it would be necessary to purchase a completely new point of care system, including a new diagnostic engine, a new processor and a new user interface. The same would be true if only a single component of the point of care system were to break or otherwise need replacement. Thus, numerous disadvantages are apparent from a technical standpoint in a point of care system where each of each of the components of the point of care system are located in a single enclosure. [0050] Disclosed herein is a point of care system comprising a plurality of diagnostic engines and an instrument data manager (IDM) in electronic communication with each of the plurality of diagnostic engines. Each of the plurality of diagnostic engines may perform testing on a sample. The IDM may be configured to communicate with each of the plurality of diagnostic engines to enable a plurality of tests to be performed on multiple different samples substantially simultaneously by a plurality of users using the plurality of diagnostic engines and to present a single user interface for managing testing by the plurality of diagnostic engines and for receiving measured results of tests performed by each of the plurality of diagnostic engines. Methods for interacting with the point of care system and the user interface are also disclosed.

[0051] The disclosed point of care system may include an IDM and a user interface that may be paired with any number of diagnostic engines. When improvements are made to a diagnostic engine, it may be possible to pair the newest diagnostic engine with the existing user interface. In addition, it may be possible to pair the IDM with multiple different types of diagnostic engines and to allow multiple operators to run tests simultaneously on the different types of diagnostic engines. This may allow users of the point of care system to customize the number and types of diagnostic engines to fit their specific needs. Further, since the IDM and the user interface may manage a plurality of diagnostic engines in a testing facility, it may be possible that the diagnostic engines themselves may have limited processing capabilities and little or no display capabilities.

[0052] The diagnostic engines disclosed herein may perform one or measurements on a sample in real-time. It is understood that the term“real-time” as used herein is intended to mean that the measurements must be obtained at a particular time and/or based on the occurrence of a particular event. In an example where the measurements must be obtained at a particular time, during testing of a blood sample by the diagnostic engine, data must be obtained at specific time points (e.g., exactly ten seconds after the test on the sample is initiated) in order for an accurate result to be calculated. In an example where the

measurements must be obtained based on a particular event, heating of a sample may be initiated and an instruction may comprise collecting one or more measurements of the sample when the temperature of the sample reaches 100 degrees. When, how and why data needs to be obtained is dependent on the design of individual diagnostic engines. The diagnostic engines may additionally determine one or measured results based on the measurements. The measured results may be determined either in real-time or in non-real time. It is understood that the term“non-real time” as used herein is indented to mean that the result does not need to be performed at a particular time or within a particular time interval in order to be considered valid. The measured results may represent a result of a test on a sample and may be based one or more of the real-time measurements performed at the diagnostic engine. The measured results may be sent by the one or more diagnostic engines to the IDM for further processing and/or displaying on a user interface. The one or more measurements may additionally or alternatively be sent to the IDM. For example, a diagnostic engine may send to the IDM only the measured results, only the collected measurements, or a combination of the measurements and measured results.

[0053] The IDM may receive the measured result from the one or more diagnostic engines and may generate a calculated result. The calculated result may be determined based on the measured result and one or more parameters. The one or more parameters may be parameters stored at the IDM, parameters received from a user via the interface of the IDM, and/or parameters received from the diagnostic engines. Example parameters may include but are not limited to demographic information associated the patient and a time of day at which the measured result was determined. Generating the calculated results may comprise performing a unit conversion (e.g., from Celsius to Fahrenheit) or computing a ratio of one measured result to another. The calculated results may be determined at the IDM in non-real time. It is understood that the IDM does not alter the measured results themselves, and instead generates new calculated results based on the measured results and possibly other parameters received at the IDM. It is further understood that no patient information may be sent from the diagnostic engines to the IDM in order to ensure the security of the patient information.

[0054] The IDM may receive patient information and may link the patient information with the measured results and/or the calculated results. It is understood that the diagnostic engines themselves may not receive any patient information. Regulatory standards may require that diagnostic engines not receive any information associated with the patient. Instead, this information may be received and stored at the IDM. The IDM may comprise a user interface for displaying the measured results received from the diagnostic engines and/or the calculated results determined at the IDM.

[0055] In an example, a diabetes diagnostic engine may test a blood sample to determine one or more measurements indicative of an Albumin level and/or a creatinine level of the blood sample. The diagnostic engine may have a real-time processor, and thus the measurements may be determined in real-time. A measured result may be generated by the diagnostic engine (in real-time or in non-real time) that represents a result of the test on the sample, such as the Albumin level and the creatinine level of the blood sample. The diagnostic engine may send the measured results to the IDM in real time or in non-real time. The IDM may generate a calculated result based on one or more of the measured results and parameters received at the IDM (e.g., using the user interface associated with the IDM).

Using the example above, the IDM may generate a calculated result by computing a ratio of the Albumin level to the creatinine level in the blood sample. The IDM may perform other operations including but not limited to unit conversions.

[0056] The diagnostic engine processing may be limited to performance of a test on a sample, computation of one or more measured results, and storage of the measured result until communicated to the IDM. Higher-level processing of the measured results may be performed by the IDM. For example, the IDM may generate calculated results from the measured results which are generated by the diagnostic engines and the parameters which are provided by a user (e.g., through the user interface). Limiting the processing necessities of the diagnostic engines themselves and generating and displaying calculated results at the IDM may allow for improvements to be made to the diagnostic engines without the need for bulky processors and user interfaces. Since the user interface at the IDM is diagnostic engine agnostic, diagnostic engines may be purchased at a later time and may be upgraded without the need to upgrade the user interface or their world interfaces.

[0057] FIG. 1 shows a point of care system 100 in accordance with an aspect of the disclosure. The system 100 may comprise one or more diagnostic engines 102A through 102/V, an instrument data manager (IDM) 104, a user interface 108, and a network infrastructure 122. The user interface 108 may be a part of the IDM 104. The system may optionally comprise one or more of a bar code reader 112, removable storage 116, a local printer 118, and a Bluetooth barcode reader 120.

[0058] The diagnostic engines 102 may perform one or more tests. The diagnostic engine 102 may perform one or more tests to determine one or more characteristics of a sample, such as a bodily fluid sample. For example, the diagnostic engine 102 may be a diabetes diagnostic engine configured to determine one or more characteristics of a blood sample, such as an HbAlc level associated with the blood sample, or may be a urinalysis diagnostic engine configured to determine one or more characteristics of a urine sample, such as the presence of one or more metabolites in that urine sample.

[0059] A diagnostic engine 102 may contain not only the physical components of the diagnostic engine 102 (e.g., heating element 146, mixing means 148, optical scanners 150, pumps 152, reagents 154, consumables, etc.), but may also control the series of steps in which use of those components are utilized to obtain a measured result. The diagnostic engine 102 may For example, a diabetes diagnostic engine may mix a sample using the mixing means 148, heat the sample to 80 degrees C using the heating element 146, mix the sample a second time using the mixing means 148, and take an optical reading of the sample using the optical scanner 150.

[0060] The diagnostic engine 102 may be configured to directly or indirectly receive a sample. A diagnostic engine configured to directly receive a sample may be responsible for handling that sample itself, coming into direct contact with the sample during the test. Examples of these types of diagnostic engines include so called“bench top” blood gas analyzers (such as the RapidPoint 500, sold by Siemens Healthcare Diagnostics Inc.) and automated urine chemistry analyzers (such as the Clinitek Novus, sold by Siemens

Healthcare Diagnostics Inc.).

[0061] Alternatively, the diagnostic engine, and physical components thereof, may not come into contact with the sample directly, but rather indirectly. Illustrative diagnostic engines of this type may receive a consumable that contains the sample, not the sample directly. A consumable may refer to any physical structure which can contain the sample. Examples of consumables include urine strips, cartridges, and lateral flow strips.

[0062] The diagnostic engine 102 may be a virtual diagnostic engine. A virtual diagnostic engine may utilize one or more features of the point of care system, such as a camera associated with the point of care system, to interface with a test sample. A virtual diagnostic engine may non-invasively determine one or more measured results from a patient, such as determining a patient’s blood pressure or pulse (e.g., using a blood pressure cuff or pulse monitor). A virtual diagnostic engine may determine other information such as ambient temperature, humidity, or may present a questionnaire that allows patient information to be entered. It is understood that the term“sample” as used herein is intended to include measured results from a virtual diagnostic engine.

[0063] The sample may be obtained from a patient using any one or a combination of methods known in the art. For example, in order to obtain a blood sample, a syringe can be used to withdraw blood from a vein of the patient. Additionally or alternatively, the blood sample can be separated (e.g., by centrifugation) to isolate and obtain a serum sample. A blood sample can additionally or optionally be obtained by lightly pricking one of the subject's fingers (e.g., with a sterile needle) and then collecting a desired volume of blood.

[0064] Following collection of the sample, the sample may be placed in a sample container or onto a consumable configured to be received by a given one of the diagnostic engines 102. For example, the sample container may be a plastic or glass container configured to receive a certain volume of the sample, or may be a test strip configured to receive a minor amount of the sample. It is understood that the sample container may comprise any type of container configured to receive any volume of a sample capable of being inserted into the diagnostic engine 102.

[0065] Bodily fluids capable of being tested by the diagnostic engines 102 include but are not limited to urine, blood, plasma, saliva, cerebrospinal fluid, pleural fluid, nasopharyngeal, and the like. Blood samples may be routinely analyzed to obtain

measurements of the partial pressures of C02 and 02 and concentrations of electrolytes and metabolites in the blood. A number of different diagnostic engines may be provided for making such measurements utilizing rigid layered sensor assemblies and electrical circuits. Such sensor assemblies may be used to assess the condition of medical patients through primary clinical indications, for example, through monitoring of pC02, p02, pH, Na+, K+, Ca2+, cl-, glucose, lactate, and hemoglobin values. However, it is understood that the samples are not limited to these types of samples and that the diagnostic engine 102 may be configured to process any types of samples.

[0066] The diagnostic engine 102 may include a chemical sensor. The diagnostic engine 102 may comprise a chemical surface, an integrated circuit structure, a micro electromechanical structure, an optical sensor, or another device responsive to chemical characteristics, such as a chemical type, blood gas level, pH level, existence of a particular chemical, amount of a particular chemical, or other characteristics. For example, the diagnostic engine 102 may comprise a chemical or biological recognition element with or without a permeable membrane and a signal transducer element, such as electrochemical (amperometry or potentiometry), electrical (ion-sensitive field effect transistor, conductance, impedance, potential, or current), optical (luminescence, fluorescence or refractive index), thermal and/or piezoelectric elements. An amplification or processing element may be integrated with the analyte responsive recognition element and/or the signal transducer element. Using membrane entrapment, physical adsorption, matrix entrapment, reaction chamber, covalent bonding, or another physical structure for exposure, a biological recognition phase (enzyme, antibody, receptor, DNA or other chemical) may interact with the analyte of interest to produce a charge or optical change at the sensor-transducer interface or electrode. Any now known or later developed chemical sensors, such as immunosensors, optrodes, chemical canaries, resonant mirrors, glucometers, biochips, and/or biocomputers, may be used. [0067] The system 100 may comprise multiple diagnostic engines 102 and/or multiple different types of diagnostic engines 102. For example, the system 100 may comprise a first diagnostic engine 102A configured for testing a first type of sample (e.g., a blood sample) and a second diagnostic engine 102B configured for testing a second type of sample (e.g., a urine sample). The system 100 may comprise any number of diagnostic engines 102 for testing any number of different types and combinations of samples. Example diagnostic engines 102 include but are not limited to blood gas diagnostic engines, cardiac diagnostic engines, coagulation diagnostic engines, diabetes diagnostic engines, urinalysis diagnostic engines, and blood pressure diagnostic engines.

[0068] A blood gas diagnostic engine may be configured to receive a blood sample and to determine one or more characteristics of that blood sample. For example, a blood gas diagnostic engine may be configured to measure one or more of hydrogen ions (pH), partial pressure of carbon dioxide (pC0 ₂ ) and partial pressure of oxygen (p0 ₂ ) in a blood sample. The blood gas diagnostic engine may also be configured to measure for the presence and/or concentration of electrolytes and metabolites in the blood sample.

[0069] A cardiac diagnostic engine may be configured to receive a sample and measure one or more cardiac health markers. In one embodiment, the cardiac diagnostic engine may receive a blood sample and may be configured to measure one or more of total cholesterol, low-density lipoprotein (LDL) cholesterol, high-density lipoprotein (HDL) cholesterol, triglycerides, non-HDL cholesterol, and high-sensitivity C-reactive protein in the blood sample. In addition, the cardiac diagnostic engine may be configured to test for and/or measure troponin levels in the blood sample.

[0070] A coagulation diagnostic engine may be configured to receive a blood sample and to measure one or more blood clotting characteristics. The coagulation diagnostic engine may perform one or more of the following tests: Prothrombin time (PT), Activated Partial Thromboplastin Time (APTT), and Activated Clotting Time (ACT). The coagulation diagnostic engine may apply a chemical membrane to one or more electrodes in a reaction chamber which may create thrombin in the blood sample. An activator may also be present to accelerate the creation of thrombin in the sample.

[0071] A diabetes diagnostic engine may be configured to measure one or more diabetes markers in a sample. In one embodiment, the diabetes diagnostic engine may measure a patient’s HbAlc levels using a monoclonal antibody addlutination reaction.

Additionally or alternatively, the diabetes diagnostic engine may be configured to test Albumin levels in the blood sample using an apoly clonal goat anti-human albumin antiserum and to test the creatinine level of the sample using a Benedict Behre chemical reaction. The IDM 104 may compute a ratio of the Albumin level to the creatinine level in the blood sample.

[0072] A urinalysis diagnostic engine may be configured to receive a urine sample and to test for one or more characteristics of the urine sample. Example methodologies may include the use of chromatographic detection pads, colorimetric reagent pads (which may change color depending on the concentration of the analyte in the blood), and optical testing systems in which an image of the urine is put under a microscope and an image recognition algorithm identifies substances in the sample.

[0073] FIG. 1A shows example components of a diagnostic engine 102/V. The diagnostic engine 102/V may comprise one or more of a processor 103, memory 140, wireless circuitry 142, heating element 146, mixing means 148, optical sensor 150, pump 152, and reagents 154. It is understood that a given one of the diagnostic engines 102 may optionally comprise any number or any combination of these elements. For example, a diagnostic engine may comprise multiple optical sensors 150 but may not comprise a pump 152. It is further understood that the diagnostic engine may comprise other components not shown in the figures or described herein, such as a separation means or any other components as would be understood by a person skilled in the art. In addition, a first type of diagnostic engine (e.g., a diabetes diagnostic engine) may comprise a different number and/or a different combination of components than a second type of diagnostic engine (e.g., a urinalysis diagnostic engine).

[0074] The processor 103 may be configured to process a sample. For example, the processor 103 may be configured to receive an instruction from a user to perform a test on a sample inserted into the diagnostic engine 102 and to output one or more values representing a measured result of the test on that sample. In one embodiment, the processor 103 may be a real-time processor configured to generate one or more measurements within a given time period, such as ten seconds. The processor 103 may additionally or alternatively be a non-real time processor configured to generate measured results based on the measurements from the test samples. In one example, diagnostic engines may comprise multiple processors, such as a real-time processor configured to obtain measurements in real-time and a non-real time processor configured to process the measurements to generate measured results.

[0075] The processor 103 may control the various components of the diagnostic engine 102 (e.g., heating element 146, mixing means 148, optical scanners 150, pumps 152, reagents 154 etc.) and may receive feedback from those components. The processor 103 may adjust one or more characteristics of the diagnostic engine 102 accordingly (in real-time) to keep the diagnostic engine 102 within the proper operating conditions and may obtain the measured results of a test performed by the diagnostic engine 102 .

[0076] The memory 140 may be configured to store information received or generated by the diagnostic engine 102. For example, the memory 140 may be configured to store one or more values representing a measured result of a test performed by the diagnostic engine 102. In one embodiment, the diagnostic engine 102 may comprise limited processing and memory capabilities such that the diagnostic engine 102 is configured only to process a particular type of sample, store one or more values representing a measurements and/or measured result of the test on that sample in the memory 140, and to send the measured results to the IDM 104.

[0077] The wireless circuitry 142 may enable the diagnostic engine 102 to communicate with one or more other components of the point of care system 100. For example, the wireless circuitry 142 may enable the diagnostic engine 102 to communicate measured results over a Bluetooth or WiFi connection to the IDM 104. The information may additionally or alternatively be communicated to a printer, an informatics management program, or any other type of information system.

[0078] The diagnostic engine 102 may comprise one or more components which can be in communication with the processor 103 and which may be controlled by the processor 103. For example, the diagnostic engine 102 may comprise one or more of a heating element 146 configured to heat a test sample, a mixing means 148 configured to mix one or more components of the test sample, an optical sensor 150 configured to determine one or more optical characteristics of the test sample, and a pump 152 configured to move at least a portion of the sample from one location to another in the diagnostic engine 102. The diagnostic engine 102 may comprise a user interface that enables a user to initiate a test of that particular diagnostic engine 102.

[0079] As discussed herein, the system 100 shown in FIG. 1 may comprise any number and any combination of types of different diagnostic engines 102. The diagnostic engines 102 may be configured to receive a test sample, perform a test on the sample, and to send a measured result of that test to the IDM 104. The diagnostic engine 102 may also be configured to store one or more measured results in a memory of the diagnostic engine 102.

[0080] The IDM 104 may be configured to receive as input one or more measured results from one or more of the diagnostic engines 102A through 102/V. The measured results may be received, for example, over the connection 110 between the one or more diagnostic engines 102 and the IDM 104. In one embodiment, the connection 110 may comprise a wireless connection. For example, the connection may comprise a Bluetooth connection. However, it is understood that the connection 110 may be any type of wireless connection, such as a Zigbee connection, a WiFi connection, or the like. In another embodiment, the connection may comprise a hardwired connection. The connection may be made via a USB cable or any other suitable communication cable interface technology. The measured result may comprise one or more values that represent a measured result of the test performed by the diagnostic engine 102. For example, the IDM 104 may receive a single value from a diabetes diagnostic engine representing an HbAlc value of a blood sample or may receive multiple values from a cardiac diagnostic engine corresponding to total cholesterol, LDL cholesterol, HDL cholesterol, and triglycerides levels of the blood sample.

[0081] The IDM 104 may be configured to communicate information to the diagnostic engines 102, such as an instruction to initiate a test, software updates, or changes to the diagnostic engine protocol that may be used by the processor 103 of the diagnostic engine 102 in generating one or more test results. However, it is understood that the IDM 104 does not control the diagnostic engines themselves after sending an instruction to the diagnostic engines to initiate a test. This limitation may be in place to conform with regulations for the IDM and/or the diagnostic engine. Instead, control of the diagnostic engines themselves may be performed by the processor 103 associated with the diagnostic engines and/or instructions received from one or more users at the diagnostic engines.

[0082] The IDM 104 may comprise a processor 105 and a memory 106. The processor may perform a variety of higher-level processing functions of the point-of-care system. Such higher-level functions may be performed by executing computer-executable instructions (e.g., program code) stored in a computer-readable medium, such as the memory 106. The IDM 104 may comprise any suitable computing device, such as a tablet computer, laptop computer, desktop computer, personal digital assistant, or other stationary or hand held computing device.

[0083] The processor 105, upon receiving a measured result from a diagnostic engine 102, may be configured to process the measured result so that a calculated result may be presented to a user of the point of care system. For example, the IDM 104 may receive one or more values (e.g., measured results) from the diagnostic engine 102. The processor 105 may be configured to determine which values correspond to certain health markers and may determine how to present those values to a user of the system 100. The processor 105 may be configured to generated calculated results by comparing a received value to one or more other stored or received values and may be configured to compute a ratio of one value to another, such as a triglyceride to HDL cholesterol ratio of a blood sample, in order to generate calculated results. The processor 105 may be a non-real time processor configured to convert measurements received from the diagnostic engine 102 into calculated results capable of being displayed to a user. The non-real time processor 105 may be configured to receive one or more measured results from the processor 103 upon completion of a test and may process the information as discussed above. In one embodiment, power for the one or more diagnostic engines 102 may be provided by the IDM 104. Additionally or alternatively, the diagnostic engines 102 may provide power for the IDM 104.

[0084] The memory 106 may be configured to store a measured result received from any of the diagnostic engines 102 and/or one or more calculated results generated by the IDM 104. The memory 106 may be configured to store any number of measured or calculated results before they are deleted (e.g., one thousand results) or may be configured to store the measured or calculated results for a determined period of time (e.g., one year). The memory 106 may further store information associated with one or more patients. For example, the memory 106 may store patient information such as an identifier associated with the patient, patient last name, patient first name, patient gender, and patient date of birth. The memory 106 may store patient’s test results along with the patient information so that they may be retrieved at a later date. While not shown in the figures, it is understood that one or more of the diagnostic engines 102 may comprise a memory similar to the memory 106 that is configured to store one or more measurements and/or one or more measured results.

[0085] The user interface 108 may be configured to present one or more calculated results to a user of the interface. The user interface 108 may comprise one or more of a display screen, a touch panel, an audio speaker, and a microphone. The user interface 108 may be controlled by the IDM 104. The functionality of the user interface may be implemented, at least in part, by computer-executable instructions (i.e., program code or software) executing on the processor 105 of the IDM 104. The IDM 104 may receive over the connection 110 one or more measured results from one or more diagnostic engines 102, process the measured results to generate calculated results, and present the calculated results and other information such as patient information via the user interface 108.

[0086] The user interface 108 may be diagnostic engine agnostic, meaning that it may be able to present results associated with any number of diagnostic engines and any type of diagnostic engine. The user interface 108 may allow multiple diagnostic engines to be operated at the same time and using the same interface. A user of the interface 108 may be able to begin a test, enter or view patient information, enter login credentials, view the time remaining on a particular test, and view the calculated results based on a test performed by a given diagnostic engine 102.

[0087] The interface 108 may allow for common screens and elements between different types of diagnostic engines, improving efficiency of the system as a user of the interface 108 may only need to leam a single interface. Common elements may be presented on the interface. Additionally or alternatively, specific instructions such as product specific instructions may be presented on the interface 108 which may be accessed from the single home screen.

[0088] The user interface may comprise a feature (e.g., a“past entry” or“last patient” feature) that enables a user via an icon on the user interface to populate patient information from one or more previous tests. For example, a user who is running a urine test may enter patient information such as patient name, patient age and patient gender. The user may then select to run that test. The user may then begin to prepare a second test (e.g., a blood test) and may opt to auto-populate, via an icon on the user interface, the information for the second test with the information from the first test, such as the patient name, patient age and patient gender. This feature may be available even if the first diagnostic engine is a different diagnostic engine than the second diagnostic engine.

[0089] The user interface 108 may enable remote login connections. For example, a user may access calculated results based on a test performed by a given one of the diagnostic engines 102 through a user interface on a cellular telephone of the device. However, the privileges provided to a user through a remote user interface may be limited. A user may be able to view calculated results from a remote user interface, but may be unable to manage the diagnostic engines themselves (e.g., to begin a new test) from the remote interface. In one example, if software is installed on a device (e.g., a cellular telephone) to enable control of the IDM 104, the device may only have the functionality to control the IDM and may not be able to perform any other functionality.

[0090] The user interface 108 may display the status or calculated results of a test. The user interface 108 may display the status or calculated results of multiple tests simultaneously. For example, if a user is running a urine test on a first patient and a blood test on a second patient, the user may be able to view one or more of the status or the calculated results of the urine test and the blood test on a single screen. This may be the case even when the urine test is being performed on a urinalysis diagnostic engine manufactured by a first company and the blood test is being performed on a blood testing engine manufactured by a second company. In one example, the user interface may be configured to simultaneously display calculated results associated with two different users of the interface 108. For example, the user interface 108 may simultaneously display a blood test result for a first patient that was initiated by a first user of the interface 108 and a urine test result for a second patient that was initiated by a second user of the interface 108. One or more of the blood diagnostic engine and the urine diagnostic engine may not be hardwired to the user interface 108.

[0091] In one example, one or more of the processor 105 and the memory 106 associated with the IDM 104 may be external to the IDM 104. For example, the processor 105 and the memory 106 may be located in a cloud.

[0092] The bar code reader 112 may be configured to read a bar code. For example, the bar code reader 112 may be configured to read a bar code on a test sample in order to determine a patient identifier (e.g., patient demographics) and type of test sample being received. Additionally or alternatively, the bar code reader 112 may be configured to scan an ID badge or other identifier of an operator of the user interface 108 in order to identify or authenticate the operator. The IDM 104 may receive, from the bar code reader 112 and over the connection 114, information including but not limited to patient information, test sample information and/or operator information. In one embodiment, the connection 114 may be a USB communication or a hardwired connection. However, it is understood that the connection 114 may be any type of connection such as a Bluetooth or a WiFi connection.

[0093] The removable storage 116 may be configured to store measured results, calculated results, patient information, and other information similar to that stored in the memory of the IDM 104. For example, the removable storage 116 may store patient information such as an identifier associated with the patient, patient last name, patient first name, patient gender, and patient date of birth, and may associate measured and/or calculated results with the stored patient information. The removable storage 116 may comprise, for example, an external hard drive or flash memory. However, the removable storage 116 may be any type of removable storage device.

[0094] The local printer 118 may be configured to print data received from the IDM 104. The data may comprise one or more of a calculated result, patient information, operator information, time and date of the test, and any other information that is capable of being printed. In one embodiment, the printer may communicate with and receive data from the IDM 104 over a Bluetooth connection. However, it is understood that the IDM 104 and the local printer 118 may communicate over any type of connection. [0095] The Bluetooth barcode reader 120 may be configured to read one or more barcodes. The Bluetooth barcode reader may operate in a similar manner to the barcode reader 112, except that its connection to the IDM 104 may be wireless (i.e., Bluetooth). For example, the bar code reader 112 may be configured to read a bar code on a test sample in order to determine a patient identifier and type of test sample being received. Additionally or alternatively, the bar code reader 112 may be configured to scan an ID badge or other identifier of an operator of the user interface 108 in order to identify or authenticate the operator. In one embodiment, the Bluetooth barcode reader 120 may be a handheld barcode reader, such as a mobile device, a wrist watch, or anything that behaves like a barcode scanner. Other operator information may include but is not limited to a key fob, an RFID or any type of biometric indicator.

[0096] The network infrastructure 122 may comprise one or more of an informatics system 124, a network printer 126, a network file system 128 and a web enabled device 130. The network infrastructure may communicate with the IDM 104 over the communications link 134. In one embodiment, the communications link 134 may be a WiFi communications link. However, it is understood that the communications link may be any type of communications link such as Bluetooth, Zigbee, Ethernet, etc.

[0097] The informatics system 124 may be configured to store information regarding how one or more users of the point of care system interact with the point of care system. The informatics system 124 may comprise one or more computing devices. For example, the informatics system 124 may be configured to download and store information associated with one or more patients and one or more operators of the system. The informatics system may comprise any type of system that is capable of receiving information from the IDM 104, including but not limited to a point of care system, a laboratory system, or other system implemented in a hospital.

[0098] The network printer 124 may print data received from the IDM 104. The data may comprise one or more of a calculated result, patient information, operator information, time and date of the test, and any other information that is capable of being printed. In one embodiment, the network printer 124 may communicate with and receive data from the IDM 104 over the WiFi connection 134 or any other connection.

[0099] The network file system 128 may store data received from the IDM 104. For example, the network file system 128 may be configured to store information including but not limited to calculated results, patient information such as a patient identifier, patient last name, patient first name, patient gender, and patient date of birth, time and date, and operator information. The network file system 128 may store measured or calculated results with the patient and/or operator information.

[00100] In an embodiment of the invention, one or more individual diagnostic engines are not able to directly interface or communicate with devices other than IDM 104 and any relevant consumable. Rather the diagnostic engines relay information to/from IDM 104 which, in turn, controls all communication to/from with the outside world via barcode reader 112, the removable storage 116, the local printer 118, the bluetooth barcode reader 120, the informatics system 124, the network printer 126, the network file system 126, or any other entity. By controlling these“world interfaces,” individual diagnostic engines need only contain those components necessary to arrive at a specific measured result while the IDM 104 houses those components needed to interface with other devices/databases— resources that can be shared among multiple diagnostic engines.

[00101] In yet another embodiment of the invention, one or more individual diagnostic engines have limited abilities to directly interface or communicate with devices other than IDM 104 and any relevant consumable. For example, a diagnostic engine may be able to receive information about a consumable (such as lot numbers, calibration information, and/or serial number) from the consumable itself using a device such as a barcode reader or a camera coupled to the diagnostic engine. In this embodiment, all remaining communications are relayed to/from the diagnostic engine and the IDM 104 which, in turn, controls all communication to/from with the outside world via barcode reader 112, the removable storage 116, the local printer 118, the bluetooth barcode reader 120, the informatics system 124, the network printer 126, the network file system 126, or any other entity. It should be appreciated that illustrative systems can have a combination of diagnostic engines with no or limited abilities to communicate to a device other than the IDM 104.

[00102] It is understood that the system 100 and any of the components described herein may be part of an“open system.” For example, the IDM 104 may be configured to connect and communicate with diagnostic engines 102 from a variety of manufacturers. The IDM 104 may be configurable to download or install new software that enables the IDM 104 to communicate with the variety of diagnostic engines 102. The user interface 108 may comprise an icon that enables one or more new diagnostic engines to be added to the IDM 104. In one example, a given diagnostic engine 102 may only be controllable by a single IDM 104. In another example, a diagnostic engine 102 may be controllable by a plurality of IDMs 104. [00103] In one example, both the diagnostic engine and the IDM may be developed by the same manufacturer. In another example, the diagnostic engine may be developed by an external partner of the manufacturer that utilizes both of the diagnostic engines user interface and world interfaces. The IDM software may need to be updated to accommodate such a diagnostic engine. In another example, the diagnostic engine may be developed by an external partner of the manufacturer that utilizes only the world interface of the diagnostic engine but not the user interface. In another example, the diagnostic engine may be a virtual engine that works in cooperation with the hardware and software of other external devices.

In an example, this could be a blood pressure monitor that allows the IDM to combine results from the blood pressure monitor with other measured or calculated results to generate new calculated results. In another example, the diagnostic engine may be a virtual engine that comprises only an application that can obtain and manipulate data. For example, the diagnostic engine may submit a questionnaire to a patient, measure ambient temperature, humidity, etc. These results may be combined with other measured or calculated results to generate new calculated results.

[00104] FIG. 2 shows an example method in accordance with an aspect of the disclosure. At step 202, a request to perform a test on a first sample may be received. The request may be received, for example, via a user interface associated with a point of care system and from a first user of the point of care system. The first sample may be inserted into a first diagnostic engine of a plurality of diagnostic engines associated with the point of care system. The plurality of diagnostic engines may perform testing on a sample inserted into the diagnostic engine. The plurality of diagnostic engines may comprise, for example, a blood gas diagnostic engine, a cardiac diagnostic engine, a coagulation diagnostic engine, a diabetes diagnostic engine and/or a urinalysis diagnostic engine. The user interface associated with the IDM configured to communicate with one or more of the plurality of diagnostic engines. The first sample may comprise, for example, a blood sample or a urine sample collected from a patient associated with the point of care system. The first user may be an operator of the point of care system, such as a doctor, a nurse, a lab technician, or a patient.

[00105] At step 204, an instruction to perform a test on the first sample may be sent to the first diagnostic engine. The user interface may display an icon representing the first diagnostic engine. The icon may indicate a status of the first diagnostic engine. For example, the icon may represent a status of the test performed by the first diagnostic engine in terms of a percentage complete or a time remaining. It is understood that the diagnostic engine may additionally or alternatively begin a test on a sample without receiving a command from the IDM. For example, a diagnostic engine may begin a test automatically upon insertion of a sample or based on one or more instructions received from a user at the diagnostic engine.

[00106] At step 206, a request to perform a test on a second sample may be received via the same user interface 108 from a second user, who may be different from the first user. The second sample may be inserted into a second diagnostic engine of a plurality of diagnostic engines associated with the point of care system. The second diagnostic engine may a different type of diagnostic engine than the first diagnostic engine. For example, the first diagnostic engine may be a diabetes diagnostic engine and the second diagnostic engine may be a urinalysis diagnostic engine. In another embodiment, the first diagnostic engine and the second diagnostic engine may be the same type of diagnostic engine.

[00107] At step 208, an instruction to perform a test on the second sample may be sent to the second diagnostic engine. The user interface may display an icon representing the second diagnostic engine. The icon may indicate a status of the second diagnostic engine.

For example, the icon may represent a status of the test performed by the second diagnostic engine in terms of a percentage complete or a time remaining of the test. The first test and the second test may be performed substantially simultaneously (e.g., such that at least a portion of the processing of the first sample and the processing of the second sample overlap).

[00108] FIG. 3 shows an example method in accordance with another aspect of the disclosure. At step 302, a first test of a first sample inserted into a first one of a plurality of diagnostic engines may be initiated. The first test may be initiated in response to a first user input received from a first user via the user interface 108 of the point of care system 100. At step 304, the IDM may receive one or more measured results from one or more of the diagnostic engines. At step 306, the IDM may determine one or more calculated results based on the one or more measured results and at least one other parameter.

[00109] At step 308, a second test of a second sample inserted into a second one of the plurality of diagnostic engines may be initiated. The second test may be initiated in response to a second user input received from a second user via the user interface 108 of the point of care system 100. The second diagnostic engine may perform testing on a second sample inserted into the diagnostic engine. The first test and the second test may be performed substantially simultaneously. Substantially simultaneously is understood to mean that the first test and the second test are being processed at the same time or nearly the same time. In one example, the first test and the second test may have the same start time and/or the same end time. In another example, the first test may be processed by the first diagnostic engine at the same time that the second test is processed by the second diagnostic engine such that at least a portion of the first test and the second test overlap. In another example, the first test and the second test may not overlap but may be performed within a similar time frame (e.g., seconds or minutes apart).

[00110] FIGS. 4A-4V show an example operation of a user interface of an IDM according to an aspect of the disclosure. As shown in FIG. 4A, the user interface may display one or more diagnostic engines that are available for use by one or more users. A diagnostic engine may also be referred to herein as an analyzer. The user interface may be configured to display one or more icons, each of the one or more icons corresponding to a diagnostic engine in communication with the IDM. The one or more diagnostic engines may be connected to the IDM using, for example, a wireless connection such as a Bluetooth connection, a WiFi connection, a Zigbee connection, or the like. Alternatively, a diagnostic engine may be connected to the IDM via a wired connection, such as via a USB cable or the like. The IDM, and hence user interface, may be in communication with any number of diagnostic engines and thus may display any number of icons corresponding to each of those diagnostic engines. In addition, the user interface may be in communication with multiple different types of diagnostic engines simultaneously. For example, the user interface may be in communication with one or more of a blood gas diagnostic engine, a cardiac diagnostic engine, a coagulation diagnostic engine, a diabetes diagnostic engine and a urinalysis diagnostic engine. Thus, while FIG. 4A shows a user interface in communication with three diabetes diagnostic engines, it is understood that the user interface may be in communication with any number and any combination of different diagnostic engines.

[00111] The user interface shown in FIG. 4A displays the current time and date, three icons corresponding to three HbAlc diagnostic engines, a drop down menu, and a prompt for a user to scan or enter an operator ID (e.g., user name). However, it is understood that that the user interface is not limited to this information or these configurations. For example, the icons presented by the user interface may comprise any shape or color. The icons may be small icons, large icons, square icons, gray icons, blue icons, etc., or the diagnostic engines may be illustrated using any other representation known in the art such as through a list of diagnostic engines. While the diagnostic engines shown in FIG. 4A are labeled“Analyzer 1,”“Analyzer 2” and“Analyzer 3,” it is understood that the diagnostic engines may be labeled using other information which may be changed or edited by the user. For example, a“Diabetes Analyzer” may be represented by a round, gray icon, a“Blood Gas Analyzer” may be represented by a square, blue icon and a“Urinalysis Analyzer” may be represented by a diamond-shaped, purple icon. The analyzers may be organized based on, for example, an alphabetical listing, by the most popular analyzers, by the most recently used analyzers, by the most recently connected analyzers, etc. It is understood that the user interface is not limited by any of the examples described herein or any of the examples shown in the figures.

[00112] As shown in FIG. 4B, upon selection of a given one of the diagnostic engines, the user may be prompted via the user interface to enter log on credentials (e.g., “Operator Login” information). As shown in the figure, the log on credentials may comprise a user identifier (e.g.,“Operator ID”) and a password. In one example, the first user may not be able to begin a test or otherwise interact with the plurality of diagnostic engines without entering the user’s log on credentials via the user interface. In another example, the first user may be able to begin a test without entering login credentials but may not be able to view a result of that test without entering login credentials. In yet another example, the system may not require the entry of login credentials either before beginning a test or before viewing the results of the test. In yet another example, the system may require the entry of login credentials both before beginning a test and before viewing a result of that test.

[00113] In one embodiment, the log on credentials may be encoded in a barcode that is scannable using a barcode reader associated with the user interface. For example, the user may select the“scan” button in order to enable a barcode scanner of the user interface to scan a bar code containing the user’s log on credentials. The point of care system may use voice recognition and biometric information such as facial recognition techniques in order to obtain log on credentials of a user. It is understood that the login credentials may be entered by any number of methods, such as through a keyboard presented by the user interface or using speech to text processing.

[00114] The user interface may comprise a list and/or a drop-down menu displaying a number of operator identifiers, such as all or a portion of the users that work in the location that the point of care system is located. The user may select from a given one of those identifiers in order to enter their login credentials. Additionally or alternatively, the user may be prompted to enter a password in addition to the operator identifier in order to gain access to the point of care system.

[00115] As shown in FIG. 4C, the user interface may prompt the user to insert a test cartridge into a diagnostic engine. For example, as shown in this figure, if the user selected an HbAlc diagnostic engine in a previous step, the user may be prompted to insert an HbAlc cartridge containing a blood sample into an HbAlc diagnostic engine. In the example that there are multiple HbAlc diagnostic engines connected to the user interface, the user interface may prompt the user to insert the HbAlc cartridge into any of the HbAlc diagnostic engines or may prompt the user to insert the HbAlc cartridge into an HbAlc diagnostic engine corresponding to the icon selected by the user. It is understood that the user interface may prompt the user to insert any type of test cartridge corresponding to the icon selected by the user. For example, if the user selected an icon corresponding to a urinalysis diagnostic engine, the user interface may prompt the user to insert a urine sample into the urinalysis diagnostic engine.

[00116] In one embodiment, the user may insert a test sample into a given one of the diagnostic engines prior to selecting a given one of the diagnostic engines. In this embodiment, the user interface may skip the step of prompting the user to insert a test cartridge, or may prompt the user to select from any of the available diagnostic engines or from a portion of the available diagnostic engines which diagnostic engine they would like to select. Upon insertion of the test sample into the diagnostic engine and/or selection of a given one of the diagnostic engines, the user may select the“OK” button to proceed to the next screen. It is understood that this may be any type of button, such as a“proceed” button. In one example, the user may communicate verbally with the user interface to proceed, such as by uttering the verbal command“next screen.” In another example, the user interface may proceed automatically to the next screen upon detection of a test sample being inserted into a given one of the diagnostic engines.

[00117] As shown in FIG. 4D, the user interface may display patient information and/or may prompt the user to enter patient information associated with the selected test sample. For example, the user interface may display or may prompt the user to enter an identifier associated with the patient, patient last name, patient first name, patient gender, and patient date of birth. The patient identifier may be any combination of letters, numbers, symbols, etc. It is understood that the patient information is not limited to this information. For example, the user interface may also display or prompt the user to enter the patient’s, height, weight, pre-existing conditions, past test results, etc. In addition, the user interface may not display some of this information, such as the patient’s name, in order to keep the patient information anonymous. In one embodiment, the user interface may be configured to scan a barcode in order to determine the patient information. For example, the barcode may be located on the test sample and may be read and decoded by the user interface in order to display the patient information. Additionally or alternatively, the user may need to manually enter all or some of the patient information via the user interface. [00118] The user interface may present additional icons such as a“recent patients” icon and a“patient list” icon in order to assist the user in entering the patient information. For example, the recent patient’s icon, when selected by a user, may cause the user interface to display a number (e.g., twenty-five) of the most recent patients associated with the point of care system. Rather than manually entering a patient’s information, the user may select the recent patient’s icon and may select the patient’s name or identifier from the list. Selecting of the patient list icon by a user may cause the interface to display a list of all patients who have ever been associated with a given one of the diagnostic engines or all patients associated with the location of the diagnostic engine, such as all patients in a nursing home where the point of care system is located.

[00119] As shown in FIG. 4E, after entering or confirming the patient information, the diagnostic engine may begin running a test on the test sample. The user interface, in response to the prompt from the user, may instruct the diagnostic engine corresponding to the selected icon to begin running a test on the sample. The user interface may be configured to display a status of one or more of the diagnostic engines. In one embodiment, the user interface may be configured to display an icon representing a status of each of the plurality of available diagnostic engines. As shown in this figure, the user interface may display a status of a test being performed by Analyzer 1 and may display that Analyzer 2 and Analyzer 3 are available for use. For example, the user interface may display that the test being performed by Analyzer 1 has two minutes and twenty -five seconds remaining until completion. The user interface may display the status of a given diagnostic engine in any number of ways. For example, the user interface may display a percentage complete, a time remaining, a time elapsed, and/or may display graphically the status of the diagnostic engine (e.g., using a graphical status indicator).

[00120] Each icon presented by the user interface may correspond to a single diagnostic engine. The icon corresponding to the diagnostic engine may allow the user to cancel a test after it has begun running, for example by prompting the user to click an“x” button, as shown in the figure. In addition, the user interface may allow a user to pause the test or to interact with the test in any number of ways. As also shown in the figure, the user interface may allow the same user or a different user to begin a new test while the first test is still running. In one embodiment, the user interface may prompt the user to enter their credentials each time a new test is selected, regardless of the user currently logged into the system. In another embodiment, the user interface may allow an operator to begin another test without requiring that operator to enter their login credentials. The user may“log out” of the system, for example, by selecting a log out option from the drop-down menu of the user interface.

[00121] As shown in FIG. 4F, in response to the user selecting a different one of the icons corresponding to a different one of the diagnostic engines, the user interface may prompt the user to insert a second test cartridge into a second one of the diagnostic engines. It is understood that the second diagnostic engine may be a different type of diagnostic engine than the first diagnostic engine. For example, the first diagnostic engine may be a diabetes test while the second diagnostic engine may be a cardiac diagnostic engine. As discussed herein, the user interface may be diagnostic engine agnostic, meaning that the user interface may be enabled to communicate with a plurality of different types of diagnostic engines. The user of the interface that selected the icon corresponding to the second diagnostic engine may be the first operator that prompted the first test or may be a second operator that is different than the first operator. The interface may prompt the user to enter login credentials prior to instructing them to insert a test cartridge into the diagnostic engine.

[00122] As shown in FIG. 4G, the user interface may display patient information or may prompt the user to enter patient information regarding the selected test for the patient associated with the second sample. For example, the user interface may display or may prompt the user to enter one or more of an identifier associated with the patient, patient last name, patient first name, patient gender, and patient date of birth. The second patient may be the same patient as the first patient. For example, the operator may wish to perform an HbAlc test on the patient using a first diagnostic engine and to perform a blood gas test on the same patient using a second diagnostic engine. Alternatively, the second patient may be a different patient than the first patient.

[00123] In one embodiment, the user interface may be configured to scan a barcode in order to determine the patient information associated with the second patient. For example, the barcode may be located on the second test sample and may be read and decoded by the user interface in order to display the patient information associated with the second patient. Additionally or alternatively, the user may need to manually enter all or some of the second patient information via the user interface.

[00124] As shown in FIG. 4H, the second diagnostic engine may begin running a test on the sample associated with the second patient. The user interface may instruct the diagnostic engine to begin the test on the sample after the user has entered or confirmed the patient information. The user interface may be configured to display an icon representing the status of each of the plurality of available diagnostic engines. As shown in this figure, the user interface may display a status of the test being performed by Analyzer 1 and a status of the test being performed by Analyzer 2, and may display that Analyzer 3 is available for use. For example, the icon corresponding to the first analyzer shows that Analyzer 1 has one minute and forty four second remaining while the icon corresponding to the second analyzer shows that Analyzer 2 has two minutes and twenty two seconds remaining.

[00125] The user interface may allow the same user or a different user to begin a new test while the first test and the second test are still running. In one embodiment, the user interface prompt the user for operator credentials each time a new test is selected, regardless of the user currently logged into the system. In another embodiment, the user interface may allow the same operator to begin another test without requiring that operator to enter their login credentials. The user may“log out” of the system, for example, by selecting a log out option from the drop-down menu of the user interface.

[00126] As shown in FIG. 41, in response to the user selecting a different one of the icons corresponding to a different one of the diagnostic engines, the user interface may prompt the user to insert a test cartridge into another one of the diagnostic engines, such as a third diagnostic engine in communication with the user interface. It is understood that the third diagnostic engine may be a different type of engine than the first diagnostic engine and/or the second diagnostic engine. For example, the first type of diagnostic engine may be a diabetes diagnostic engine, the second diagnostic engine may be a cardiac diagnostic engine, and the third diagnostic engine may be a urinalysis diagnostic engine. In another example, the third diagnostic engine may be the same type of diagnostic engine as the first diagnostic engine while the second type of diagnostic engine may be a different type of diagnostic engine.

[00127] As shown in FIG. 4J, the user interface may display patient information and/or may prompt the user to enter patient information associated with the selected test sample for the third patient. For example, the user interface may prompt the user to enter an identifier associated with the patient, patient last name, patient first name, patient gender, and patient date of birth. In one embodiment, the user interface may be configured to scan and/or decode a barcode in order to determine the patient information associated with the third patient. The barcode may be located, for example, on the third test sample. Additionally or alternatively, the user may need to manually enter all or some of the third patient information via the user interface.

[00128] As shown in FIG. 4K, the third diagnostic engine may begin running a test on the sample associated with the third patient. The user interface may instruct the third diagnostic engine to begin the test on the sample after the user has entered or confirmed the patient information. The user interface may be configured to display an icon representing the status of each of the plurality of available diagnostic engines. The user interface may allow a user to view a result by selecting an icon or other visual representation corresponding to the diagnostic engine that performed the test on the sample. The user may select to view a result independent of the status of any of the other diagnostic engines. It is understood that the result viewed by a user may be a calculated result. The calculated result may be determined by the IDM based on a measured result received from a given one of the diagnostic engines, as described herein.

[00129] As shown in FIG. 4L, the user interface may display a result (e.g., a calculated result) corresponding to a test performed by a given one of the diagnostic engines. In one embodiment, any user may view a result without entering their login credentials. For example, in response to an operator of the interface selecting the icon corresponding to Analyzer 1, the user interface may display a result corresponding to the test performed by Analyzer 1. In response to a user selecting the icon corresponding to Analyzer 2, the user interface may be configured to display a result corresponding to the test performed by Analyzer 2. In response to a user selecting the icon corresponding to Analyzer 3, the user interface may generate an alert indicating to the user that the test has not yet been completed, or may display a current result associated with the test even if the test is not yet completed. In another embodiment, the user interface may not display any results unless an operator is currently logged into the system. For example, a first operator that is logged into the system may be able to view results for any patient associated with that operator, such as all results that were initiated using the operator identifier associated with that operator. Additionally, the operator may be able to view results associated with any of the other operators as long as at least one operator is logged into the system. For example, a first doctor in a hospital comprising multiple doctors may be able to view results for tests initiated by that first doctor and may also be able to view results for tests that were initiated by a second doctor as long as the first doctor is logged into the system.

[00130] The user interface may be configured to display any type of information in response to selection of an icon by a user of the interface. For example, the user interface may display a value that was received from the diagnostic engine corresponding to a result associated with the test. In the example that the selected icon corresponds to an HbAlc Analyzer, the user interface may display a value corresponding to the patient’s HbAlc level, such as 5.6% as shown in this figure. In the example of a user selecting an icon corresponding to a cardiac diagnostic engine, the user interface may display one or more values corresponding to results received from the cardiac diagnostic engine. For example, the user interface may display values corresponding to a patient’s total cholesterol, LDL cholesterol, HDL cholesterol, triglycerides, non-HDL cholesterol, and high-sensitivity C- reactive protein.

[00131] The user interface may display information other than the information that was received from the diagnostic engine. For example, the user interface may display an operator ID, a patient ID, a date and time of the test, a diagnostic engine identifier, patient first name, patient last name, patient gender, and patient date of birth. It is understood that the user interface may display only a portion of this information and is not limited to the information described here.

[00132] The user interface may allow the user to comment on the results. For example, by clicking on the“comment” button, the user may enter information associated with the test, such as“HbAlc levels are within normal range” or“follow-up with patient in six months.” The user interface may further allow the user to print the results by clicking on the“print” icon or may allow the user to send the results to another entity by selecting the “transmit” icon. For example, upon the user selecting the“print” icon, the user interface may display a list of printers or may automatically print to a select one of the available printers. Additionally or alternatively, in response to the user selecting the“transmit” icon, the user interface may allow the user to manually enter a destination such as an email address or other system capable of receiving results, or may allow the user to select the destination from a drop-down menu.

[00133] As shown in FIG. 4M, the user interface may instruct the user to remove the test cartridge. The user interface may instruct the user to remove the test cartridge corresponding to the icon for which the user is currently viewing the results. The user interface may present this instruction to remove the test cartridge at any point before, during, or after the user has viewed the results associated with the test. In one example, the user interface may only display this message in response to a user selecting that they have viewed the results or that the user has printed or transmitted the results. The user interface may be configured to automatically store the results in a database. This process of storing results may also be performed before, during or after the user has viewed the results of the test performed by the diagnostic engine. The user interface may also display additional information such as how to properly dispose of the test cartridge. [00134] As shown in FIG. 4N, the user interface may display a status of all or some of the diagnostic engines that are connected to the user interface. After the user has viewed a result associated with a given diagnostic engine and has removed the test cartridge from that diagnostic engine, the user interface may display that the diagnostic engine is once again available. For example, the user interface may display an icon corresponding to that diagnostic engine that shows the diagnostic engine as being available for use. As shown in this figure, the user interface may display that Analyzer 1 is available, an indicator that a test performed by Analyzer 2 is complete, and a status of the test being performed by Analyzer 3 (e.g., twelve seconds remaining). It is understood that the user interface may display that the analyzer is available for use at any time after the test being performed by that diagnostic engine is complete.

[00135] A user of the interface may select any one of the icons to interact with the diagnostic engine corresponding to that icon. For example, the user may select the icon corresponding to Analyzer 1 in order to perform a test using that analyzer. The user may select the icon corresponding to Analyzer 2 in order to view the results of a test associated with that analyzer. In response to the user selecting analyzer 3, the interface may alert the user that Analyzer 3 is currently running a test and may optionally allow the user to view a partial result of that test.

[00136] As shown in FIG. 40, in response to a user selecting the icon

corresponding to Analyzer 2, the user interface may display a result of the test associated with that analyzer. For example, the user interface may display a value that was received from the diagnostic engine corresponding to Analyzer 2. In the example that the selected icon corresponds to an HbAlc Analyzer, the user interface may display a value corresponding to the patient’s HbAlc level, such as 4.3% as shown in this figure. The user interface may display additional information other than the information that was received from the diagnostic engine, such as an operator ID, the patient ID, the date and time of the test, a diagnostic engine identifier, patient first name, patient last name, patient gender, and patient date of birth. Additionally or alternatively, the user interface may allow the user to comment on the results, print the results, or transmit the results to one or more other locations.

[00137] As shown in FIG. 4P, the user interface may instruct the user to remove the test cartridge. The user interface may instruct the user to remove the test cartridge corresponding to the icon for which the user is currently viewing the results. The user interface may present this instruction to remove the test cartridge at any point before, during, or after the user has viewed the results. In one example, the user interface may only display this message in response to a user selecting that they have viewed the results or that the user has printed or transmitted the results.

[00138] As shown in FIG. 4Q, the user interface may display a status of all or some of the diagnostic engines that are connected to the user interface. After the user has viewed a result associated with a given diagnostic engine and has removed the test cartridge from that diagnostic engine, the user interface may display that the diagnostic engine is once again available. For example, the user interface may display an icon corresponding to that diagnostic engine that shows the diagnostic engine as being available for use.

[00139] As shown in FIG. 4R, in response to a user selecting the icon corresponding to Analyzer 3, the user interface may display a result of the test associated with that analyzer. For example, the user interface may display a value that was received from the diagnostic engine corresponding to Analyzer 3. In the example that the selected icon corresponds to an HbAlc Analyzer, the user interface may display a value corresponding to the patient’s HbAlc level, such as 6.9% as shown in this figure. The user interface may display additional information other than the information that was received from the diagnostic engine, such as an operator ID, the patient ID, the date and time of the test, a diagnostic engine identifier, patient first name, patient last name, patient gender, and patient date of birth. Additionally or alternatively, the user interface may allow the user to comment on the results, print the results or transmit the results to one or more other locations.

[00140] As shown in FIG. 4S, the user interface may instruct the user to remove the test cartridge. The user interface may instruct the user to remove the test cartridge corresponding to the icon for which the user is currently viewing the results. The user interface may present this instruction to remove the test cartridge at any point before, during, or after the user has viewed the results. In one example, the user interface may only display this message in response to a user selecting that they have viewed the results or that the user has printed or transmitted the results.

[00141] As shown in FIG. 4T, the user interface may indicate that all diagnostic engines currently connected to the user interface are available for use. For example, each of the results (e.g., calculated results) based on tests performed by Analyzer 1, Analyzer 2 and Analyzer 3 have been viewed, each of those diagnostic engines may be available for use by that same user or a different user of the point of care system. The user currently logged in to the user interface may select to log out of the point of care system through the user interface, for example, by selecting a log out option from the drop-down menu. Additionally or alternatively, the user may be logged out of the system after a period of inactivity, such as one minute. In another example, the user may automatically be logged out after viewing a result.

[00142] As shown in FIG. 4U, the user may be prompted to verify that they wish to log out. For example, the user interface may display the message“Are you certain that you wish to log out?” and may only log the user out of the system after they have confirmed, for example, by selecting the OK button on the user interface. At this point, the same or different user may log back in to the system by entering their operator credentials via the user interface.

[00143] As shown in FIG. 4V, the user interface may display one or more icons or other visual representations illustrating that one or more diagnostic engines are available for use. A given one of the icons may be selected by a user of the interface to begin a test on a sample.

[00144] FIGS. 5A-50 shown an example operation of a user interface according to another aspect of the disclosure. As shown in FIG. 5A, the user interface may display one or more diagnostic engines that are available for use by one or more users. A diagnostic engine may also be referred to herein as an analyzer. The user interface may be configured to display one or more icons, each of the one or more icons corresponding to a diagnostic engine in communication with the user interface. The one or more diagnostic engines may be connected to the user interface using, for example, a Bluetooth connection, a WiFi connection, a USB cable or any type of connection known in the art. The user interface may be in communication with any number of diagnostic engines and thus may display any number of icons corresponding to each of those diagnostic engines. In addition, the user interface may be in communication with multiple different types of diagnostic engines simultaneously. For example, the user interface may be in communication with one or more of a blood gas diagnostic engine, a cardiac diagnostic engine, a coagulation diagnostic engine, a diabetes diagnostic engine and a urinalysis diagnostic engine.

[00145] The user interface shown in FIG. 5A displays the current time and date, three icons corresponding to three different diagnostic engines, a drop down menu, and a prompt for a user to scan or enter an operator ID. However, it is understood that that the user interface is not limited to this information or these configurations. For example, the icons presented by the user interface may comprise any shape or color. The icons may be small icons, large icons, square icons, gray icons, blue icons, etc., or the diagnostic engines may be illustrated using any other representations known in the art such as through a list of diagnostic engines. While the diagnostic engines shown in FIG. 5A are labeled“Clinical 1,” “Clinical 2” and“Urine Analyzer,” it is understood that the diagnostic engines may be labeled using other information which may be changed or edited by the user. In addition, it is further understood that the user interface is not limited by any of the examples described herein or any of the examples shown in the figures.

[00146] As shown in FIG. 5B, upon selection of a given one of the diagnostic engines, the user may be prompted via the user interface to enter log on credentials (e.g., “Operator Login” information). As shown in the figure, the log on credentials may comprise a user identifier (e.g.,“Operator ID”) and a password. In one example, the first user may not be able to begin a test or otherwise interact with the plurality of diagnostic engines without entering the user’s log on credentials via the user interface. In another example, the first user may be able to begin a test without entering login credentials but may not be able to view a result of that test without entering login credentials. In yet another example, the system may not require the entry of login credentials either before beginning a test or before viewing the results of the test. In yet another example, the system may require the entry of login credentials both before beginning a test and before viewing a result of that test.

[00147] The log on credentials may be encoded in a barcode that is scannable using a barcode reader associated with the user interface. For example, the user may select the “scan” button in order to enable a barcode scanner of the user interface to scan a bar code containing the user’s log on credentials. In addition, the point of care system may use voice recognition and biometric information such as facial recognition techniques in order to obtain log on credentials of a user. It is understood that the login credentials may be entered by any number of methods, such as through a keyboard presented by the user interface or using speech to text processing.

[00148] In one embodiment, the user interface may display a list and/or a drop down menu comprising a number of operator identifiers, such as all or a portion of the users that work in the location that the point of care system is located. The user may select from a given one of those identifiers in order to enter their login credentials. Additionally or alternatively, the user may be prompted to enter a password associated with the login credentials in order to gain access to the point of care system. While FIGS. 5A-50 show that the user interface prompts a user to enter his login credentials after selecting a given one of the icons corresponding to a diagnostic engine, it is understood that the user interface may prompt the user to enter their login credentials at any point in the testing process. For example, the user interface may prompt the user to enter their login credentials before viewing and selecting a given one of the icons, prior to beginning a test on a given one of the diagnostic engines, and/or prior to viewing the results (e.g., calculated results) associated with a given diagnostic engine.

[00149] As shown in FIG. 5C, the user interface may prompt the user to insert a test sample cartridge into a diagnostic engine. For example, as shown in this figure, if the user selected an HbAlc diagnostic engine in a previous step, the user may be prompted to insert an HbAlc cartridge containing a blood sample into an HbAlc diagnostic engine. In the example that there are multiple HbAlc diagnostic engines connected to the user interface, the user interface may prompt the user to insert the HbAlc cartridge into any of the HbAlc diagnostic engines or may prompt the user to insert the HbAlc cartridge into an HbAlc diagnostic engine corresponding to the icon selected by the user. It is understood that the user interface may prompt the user to insert any type of test cartridge corresponding to the icon selected by the user. For example, if the user selected an icon corresponding to a urinalysis diagnostic engine, the user interface may prompt the user to insert a urine sample into the urinalysis diagnostic engine.

[00150] In one embodiment, the user may insert a test sample into a given one of the diagnostic engines prior to selecting a given one of the diagnostic engines. In this embodiment, the user interface may skip the step of prompting the user to insert a test cartridge, or may prompt the user to select from any of the available diagnostic engines or from a portion of the available diagnostic engines which diagnostic engine they would like to select. Upon insertion of the test sample into the diagnostic engine and/or selection of a given one of the diagnostic engines, the user may select the“OK” button to proceed to the next screen. It is understood that this may be any type of button, such as a“proceed” button. In one example, the user may communicate verbally with the user interface to proceed, such as by uttering the verbal command“next screen.” In another example, the user interface may proceed automatically to the next screen upon detection of a test sample being inserted into a given one of the diagnostic engines.

[00151] As shown in FIG. 5D, the user interface may display patient information and/or may prompt the user to enter patient information associated with the selected test sample. For example, the user interface may prompt the user to enter an identifier associated with the patient, patient last name, patient first name, patient gender, and patient date of birth. The patient identifier may be any combination of letters, numbers, symbols, etc. It is understood that the patient information is not limited to this information. For example, the user interface may also display or prompt the user to enter the patient’s, height, weight, pre existing conditions, past test results, etc. In addition, the user interface may not display some of this information, such as the patient’s name, in order to keep the patient information anonymous. In one embodiment, the user interface may be configured to scan a barcode in order to determine the patient information. For example, the user may select the“scan” button in order to enable a barcode scanner of the user interface. The barcode may be located on the test sample and may be read and decoded by the user interface in order to display the patient information. Additionally or alternatively, the user may need to manually enter all or some of the patient information via the user interface.

[00152] The user interface may present additional icons such as a“recent patients” icon and a“patient list” icon in order to assist the user in entering the patient information. For example, the recent patients icon, when selected by a user, may cause the user interface to display a number (e.g., twenty-five) of the most recent patients associated with the point of care system. Rather than manually entering a patients information, the user may select the recent patients icon and may select the patient’s name or identifier from the list. Selecting of the patient list icon by a user may cause the interface to display a list of all patients who have ever been associated with a given one of the diagnostic engines or all patients associated with the location of the diagnostic engine, such as all patients in a nursing home where the point of care system is located.

[00153] As shown in FIG. 5E, after entering or confirming the patient information, the diagnostic engine may begin running a test on the test sample. The user interface, in response to the user entering or confirming the patient information, may instruct the diagnostic engine corresponding to the selected icon to begin running a test on the sample.

The user interface may be configured to display a status of one or more of the diagnostic engines. In one embodiment, the user interface may be configured to display an icon representing a status of each of the plurality of available diagnostic engines. As shown in this figure, the user interface may display a status of a test being performed by Clinical 1 (e.g., one minute and forty-five seconds remaining) and may display that the Clinical 2 Analyzer and the Urine Analyzer are available for use. The user interface may display the status of a given diagnostic engine in any number of ways. For example, the user interface may display a percentage complete, a time remaining, a time elapsed, and/or may display graphically the status of the diagnostic engine (e.g., using a graphical status indicator).

[00154] As shown in FIG. 5F, the user may be promoted to log out of the point of care system. In one embodiment, the user may be automatically logged out of the point of care system after the diagnostic engine begins running the test. In another embodiment, the user may need to manually log out, but may be unable to begin another test without re- entering their login credentials. For example, if the user were to select the“Clinical 2” icon, the user interface may prompt the user to entire their login credentials prior to beginning the test. In another embodiment, the user interface may allow the same user to begin a new test without entering their login credentials. As shown in this figure, after selecting to log out from the user interface, the operator may be presented with the message“Are you sure you want to log out?” The user may need to click the OK button or otherwise verify that they want to log out of the system before beginning another test.

[00155] As shown in FIG. 5G, The user interface may once again display a current status of the one or more diagnostic engines. The user interface may enable an operator to select a given one of the diagnostic engines for running a test on a sample. The operator may be the first operator that ran the first test or may be a second operator that is different than the first operator. Upon selection of a given one of the icons corresponding to a diagnostic engine, the user interface may prompt the operator to enter their login credentials. In one embodiment, the user interface may prompt the operator to enter their login credentials each time they select a new test. Thus, even if the operator is the same operator that ran the first test, the user interface may still require that operator to enter their login credentials. In another embodiment, the user interface may allow the first operator to begin a second test without entering their login credentials as long as that operator is still logged in to the system.

[00156] As shown in FIG. 5H, the user may be prompted via the user interface to enter Operator Login information. As shown in the figure, the user may be configured to enter login credentials comprising any combination of letters, numbers, symbols, etc. It is understood that the operator identifier may comprise any kind of identifier, including but not limited to a user name, a password, a PIN number, and a barcode that is scannable using a barcode reader associated with the user interface. For example, the user may select the“scan” button in order to enable a barcode scanner of the user interface. In addition, the point of care system may use voice recognition and biometric information such as facial recognition techniques in order to identify a user. The login information may be entered by any number of means, such as through a keyboard presented by the user interface or using speech to text processing.

[00157] As shown in FIG. 51, the user interface may prompt the user to insert a test sample cartridge into a diagnostic engine. For example, as shown in this figure, if the user selected an HbAlc diagnostic engine in a previous step, the user may be prompted to insert an HbAlc cartridge containing a blood sample into an HbAlc diagnostic engine. Upon insertion of the test sample into the diagnostic engine and/or selection of a given one of the diagnostic engines, the user may select the“OK” button or may otherwise communicate to the user interface to proceed to the next screen.

[00158] As shown in FIG. 5J, the user interface may display patient information and/or may prompt the user to enter patient information associated with the selected test sample. For example, the user interface may display or may prompt the user to enter an identifier associated with the patient, patient last name, patient first name, patient gender, and patient date of birth. It is understood that the patient information is not limited to this information. For example, the user interface may also display or prompt the user to enter the patient’s, height, weight, pre-existing conditions, past test results, etc. In one embodiment, the user interface may be configured to scan a barcode in order to determine the patient information. The user may select the“scan” button in order to enable a barcode scanner of the user interface. The barcode may be located, for example, on the test sample. The user interface may present additional icons such as a“recent patients” icon and a“patient list” icon in order to assist the user in entering the patient information.

[00159] As shown in FIG. 5L, the user interface may display a result of test (e.g., a calculated result) associated with a test performed by a given one of the diagnostic engines.

In one embodiment, the user interface may prompt the user to enter their login credentials prior to viewing a result. In another embodiment, any user may view a result without entering their login credentials. For example, in response to a user of the interface selecting the icon corresponding to Clinical Analyzer 1, the user interface may display a result associated with a test performed by Clinical Analyzer 1. In response to a user selecting the icon corresponding to Clinical Analyzer 2, the user interface may be configured to display a result associated with a test performed by Clinical Analyzer 2.

[00160] The user interface may be configured to display any type of information in response to selection of an icon by a user of the interface. For example, the user interface may display a calculated result that is based on a measured result received from the diagnostic engine. In the example that the selected icon corresponds to an HbAlc Analyzer, the user interface may display a value corresponding to the patient’s HbAlc level, such as 5.6% as shown in this figure. In another embodiment, in response to a user selecting an icon corresponding to a cardiac diagnostic engine, the user interface may display one or more calculated results corresponding to measured results received from the cardiac diagnostic engine. For example, the user interface may display values corresponding to a patient’s total cholesterol, LDL cholesterol, HDL cholesterol, triglycerides, non-HDL cholesterol, and high- sensitivity C-reactive protein. The user interface may display information other than the information that was received from the diagnostic engine. For example, the user interface may display an operator ID, the patient ID, the date and time of the test, a diagnostic engine identifier, patient first name, patient last name, patient gender, and patient date of birth. It is understood that the user interface may display only a portion of this information and is not limited to the information described here.

[00161] The user interface may allow the user to comment on the measured results and/or the calculated results. For example, by clicking on the“comment” button, the user may enter information associated with the test, such as“HbAlc levels are within normal range” or“follow-up with patient in six months.” The user interface may further allow the user to print the results by clicking on the“print” icon or may allow the user to send the results to another entity by selecting the“transmit” icon. For example, upon the user selecting the“print” icon, the user interface may display a list of printers or may automatically print to a select one of the available printers. Additionally or alternatively, in response to the user selecting the“transmit” icon, the user interface may allow the user to manually enter a destination such as an email address or other system capable of receiving results, or may allow the user to select the destination from a drop-down menu.

[00162] As shown in FIG. 5M, the user interface may instruct the user to remove the test cartridge. The user interface may instruct the user to remove the test cartridge corresponding to the icon for which the user is currently viewing the results. The user interface may present this instruction to remove the test cartridge at any point before, during, or after the user has viewed the results. In one example, the user interface may only display this message in response to a user selecting that they have viewed the results or that the user has printed or transmitted the results. The user interface may be configured to automatically store the results received from the diagnostic engine in a database. This process of storing test results may also be performed before, during or after the user has viewed the results based on the test performed by the diagnostic engine. The user interface may also display additional information, such as how to properly dispose of the test cartridge.

[00163] As shown in FIG. 5N, the user interface may display a status of all or some of the diagnostic engines that are connected to the user interface. After the user has viewed a result of a test associated with a given diagnostic engine and has removed the test cartridge from that diagnostic engine, the user interface may display that the diagnostic engine is once again available. For example, the user interface may display an icon corresponding to that diagnostic engine that shows the diagnostic engine as being available for use. As shown in this figure, the user interface may display that the Clinical 1 Analyzer has completed a test, and that the Clinical 2 Analyzer and the Urine Analyzer are available for use. As shown in this figure, the user interface may display the operator identifier on the top portion of the screen in order to indicate the operator that is currently logged in to the system. It is understood that this information may displayed anywhere on the screen or may not be displayed at all.

[00164] As shown in FIG. 50, the user interface may automatically logout the operator currently logged into the system after a period of inactivity. For example, the user interface may automatically logout the current operator after sixty seconds of inactivity. It is understood that the user interface may log the operator out of the user interface after any period of time and that this period of time may be set by an operator of the user interface such as an administrator in a location where the point of care system is located. As shown in this figure, once the user is logged out of the system, the user interface may display the prompt “scan or enter Operator ID.” At this point, in response to a user selecting the icon

corresponding to“Clinical 1,” the user interface may require a user to enter login credentials.

[00165] While the methods and systems have been described in connection with preferred embodiments and specific examples, it is not intended that the scope be limited to the particular embodiments set forth, as the embodiments herein are intended in all respects to be illustrative rather than restrictive.

[00166] Unless otherwise expressly stated, it is in no way intended that any method set forth herein be construed as requiring that its operations be performed in a specific order. Accordingly, where a method claim does not actually recite an order to be followed by its operations or it is not otherwise specifically stated in the claims or descriptions that the operations are to be limited to a specific order, it is no way intended that an order be inferred, in any respect. This holds for any possible non-express basis for interpretation, including: matters of logic with respect to arrangement of steps or operational flow; plain meaning derived from grammatical organization or punctuation; and the number or type of embodiments described in the specification.

[00167] It will be apparent to those skilled in the art that various modifications and variations may be made without departing from the scope or spirit of the present disclosure. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practices described herein. It is intended that the specification and example figures be considered as exemplary only, with a true scope and spirit being indicated by the following claims. Example Embodiments:

1. A method performed by an instrument data manager (IDM) in electronic communication with a plurality of diagnostic engines, the IDM being configured to communicate with each of the plurality of diagnostic engines to enable a plurality of tests to be performed on a plurality of samples substantially simultaneously by a plurality of users using the plurality of diagnostic engines and to present a single user interface for managing testing by the plurality of diagnostic engines and for receiving measured results of the tests performed by each of the plurality of diagnostic engines, the method comprising:

receiving, via the user interface and from a first user, a request to perform a test on a sample associated with a first one of the diagnostic engines;

sending, to the first diagnostic engine, an instruction to perform the test on the sample associated with the first diagnostic engine;

receiving, via the user interface and from a second user, a request to perform a test on a sample associated with a second one of the diagnostic engines; and

sending, to the second diagnostic engine, an instruction to perform the test associated with the second diagnostic engine,

wherein the test associated with the first diagnostic engine and the test associated with the second diagnostic engine are performed substantially simultaneously.

2. The method of claim 1, further comprising:

prompting, via the user interface, the first user to enter information corresponding to the sample associated with the first diagnostic engine; and

prompting, via the user interface, the second user to enter information corresponding to the sample associated with the second diagnostic engine,

wherein the information includes one or more of a patient identifier, a patient demographic, a sample demographic, and order information.

3. The method of claim 2, wherein the prompt for at least one of the first user to enter information corresponding to the sample associated with the first diagnostic engine and the second user to enter information corresponding to the sample associated with the second diagnostic engine is displayed after the corresponding test has been initiated.

4. The method of claim 1, further comprising: displaying, via the user interface and after initiating the test associated with the first diagnostic engine, an icon representing the first diagnostic engine; and

displaying, via the user interface and after initiating the test associated with the second diagnostic engine, an icon representing the second diagnostic engine.

5. The method of claim 1, wherein the plurality of diagnostic engines comprise at least one of a blood gas diagnostic engine, a cardiac diagnostic engine, a coagulation diagnostic engine, a diabetes diagnostic engine, and a urinalysis diagnostic engine.

6. The method of claim 5, wherein first diagnostic engine and the second diagnostic engine are different types of diagnostic engines.

7. The method of claim 1, wherein the first user is the same user as the second user.

8. The method of claim 1, wherein the first user is a different user than the second user.

9. The method of claim 1, wherein the IDM receives measured results from one or more of the plurality of diagnostic engines in non-real time.

10. The method of claim 9, further comprising generating a calculated result based on the measured result and at least one other parameter,

wherein the at least one other parameter comprises demographic information associated a patient and a time of day at which the measured result was determined.

11. An instrument data manager (IDM) in electronic communication with a plurality of diagnostic engines, the IDM being configured to communicate with each of the plurality of diagnostic engines to enable a plurality of tests to be performed on a plurality of samples substantially simultaneously by a plurality of users using the plurality of diagnostic engines and to present a single user interface for managing testing by the plurality of diagnostic engines and for receiving results of the tests performed by each of the plurality of diagnostic engines, wherein the IDM comprises a processor and a memory, the memory storing computer executable instructions which, when executed by the processor, cause the IDM to perform operations comprising: receiving, via the user interface and from a first user, a request to perform a test on a sample associated with a first one of the diagnostic engines;

sending, to the first diagnostic engine, an instruction to perform the test on the sample associated with the first diagnostic engine;

receiving, via the user interface and from a second user, a request to perform a test on a sample associated with a second one of the diagnostic engines; and

sending, to the second diagnostic engine, an instruction to perform the test associated with the second diagnostic engine,

wherein the test associated with the first diagnostic engine and the test associated with the second diagnostic engine are performed substantially simultaneously.

12. The IDM of claim 11, wherein the instructions, when executed, further cause the IDM to perform operations comprising:

prompting, via the user interface, the first user to enter information corresponding to the sample associated with the first diagnostic engine; and

prompting, via the user interface, the second user to enter information corresponding to the sample associated with the second diagnostic engine,

wherein the information includes one or more of a patient identifier, a patient demographic, a sample demographic, and order information.

13. The IDM of claim 12, wherein the prompt for at least one of the first user to enter information corresponding to the sample associated with the first diagnostic engine and the second user to enter information corresponding to the sample associated with the second diagnostic engine is displayed after the corresponding test has been initiated.

14. The IDM of claim 11, wherein the instructions, when executed, further cause the IDM to perform operations comprising:

displaying, via the user interface and after initiating the test associated with the first diagnostic engine, an icon representing the first diagnostic engine; and

displaying, via the user interface and after initiating the test associated with the second diagnostic engine, an icon representing the second diagnostic engine. 15. The IDM of claim 11, wherein the plurality of diagnostic engines comprise at least one of a blood gas diagnostic engine, a cardiac diagnostic engine, a coagulation diagnostic engine, a diabetes diagnostic engine, and a urinalysis diagnostic engine.

16. The IDM of claim 15, wherein first diagnostic engine and the second diagnostic engine are different types of diagnostic engines.

17. The IDM of claim 11, wherein the first user is the same user as the second user.

18. The IDM of claim 11 , wherein the first user is a different user than the second user.

19. The IDM of claim 11 , wherein the IDM receives measured results from one or more of the plurality of diagnostic engines in non-real time.

20. The IDM of claim 19, further comprising generating a calculated result based on the measured result and at least one other parameter,

wherein the at least one other parameter comprises demographic information associated a patient or a time of day at which the measured result was determined.