Patent Description:
Modern scientific and clinical concerns can include a wide variety of laboratory equipment devices acquired from a correspondingly-wide variety of manufacturers, spanning several generations of hardware interfaces and data computing formats and protocols.

It is accordingly common to find, in such environments, a heterogeneous mix of laboratory equipment devices accruing a similarly-heterogeneous suite of data output connectors, wherein some devices may comprise only serial data output connectors conforming to the Recommended Standard <NUM> (`RS-<NUM>') format ; some more recent devices may also, or instead, comprise Universal Serial Bus (`USB') connectors and at least one <NUM> position <NUM> contact ('8P8C', `also RJ45') connector for local and wide area network interfacing; and some other, still more recent, devices may comprise wireless network connectivity conforming to the Bluetooth® or Wi-Fi® networking standard.

It is also increasingly common to find laboratory information systems (`LIS') and/or laboratory information management system ('LIMS') implementing networks both for interconnecting such laboratory equipment devices with information management systems which, typically, host databases for storing test data output by the laboratory equipment and facilitating its analysis; and for integrating the set of diverse and disparate laboratory equipment devices as a data-coherent whole, to the extent permitted by legacy interfaces and data formats.

Efforts have been undertaken to standardise data formats, messages and communication protocols for facilitating such integrating. ASTM standard E1238 is one of the earliest standards in the field of clinical data transfers between independent computers, and is still in use for batch and reference laboratory interfaces. E1238 is technically aligned with a set of international standards promulgated by Health Level <NUM> (`HL7') International, and which focus on the application layer, being "layer" <NUM> in the Open Systems Interconnection ('OSI') model. HL7 standards are more recent standards than ASTM E1238, and are the most commonly used in the United States for numeric, textual, and coded clinical data, under which data messages are sent in an ASCII delimited format such as. csv or, according to more recent developments, in eXtended Markup Language ('XML') or JSON formats.

Such normalisation efforts notwithstanding, the sheer volume of scientific and healthcare segments, procedures and data-producing equipment, maintains an inherently high degree of heterogeneity across laboratory data connections, file and data types, data messaging conventions and protocols, which is compounded by the device-independent character of LIS and LIMS and the pace of software and operating systems development of computers.

For example, whilst most laboratory equipment makers have long configured the firmware in laboratory devices for outputting test data in flat files of a generic format (such as the afore-mentioned. csv formats) and, in more recent times, designed such laboratory devices with local network connectivity to permit the exporting of flat files to a local network storage address, such as a shared file directory, the purchase of an instrument by a scientific or medical site rarely engages the equipment maker to customize the instrument connectivity and data transfer to accommodate that site's LIS parameters. Reciprocally, it is impractical for a LIS supplier to design and implement connectivity and data templates for every possible legacy, up to state-of-the-art, laboratory equipment.

Further, most modern computers now lack a serial-type data input port and, as their operating system is in constant need of updating for security patching and interoperability implementing, administrators of data networks and system in scientific and clinical concerns often introduce procedural barriers to the acquisition and subsequent sharing of laboratory data, for instance when the administrator stipulates permanent real-time anti-virus protection on computers, but the laboratory equipment maker or the LIS or LIMS supplier stipulates incompatibility of its equipment or software with real-time virus protection. Various systems have been proposed in published patent applications such as <CIT>) and <CIT>).

However a number of problems with the above implementations is that connectivity solutions and data conversion procedures are frequently engineered ad hoc, invariably requiring additional computing resources to bridge connectivity data format and procedural incompatibilities, irrespective of where and how they arise. Notwithstanding the existence of simple solutions to bridge incompatible connectors, such as a conventional serial-to-USB adapter for example, known technologies all still appear to require a distinct computer terminal, bespoke software from the laboratory equipment vendor and/or the LIS supplier and user interaction with both, in order to acquire data from a laboratory equipment device and process it into a usable format, i.e. to extract the values, parameters and similar quantitative data corresponding to the actual sampling results output by the laboratory equipment.

Accordingly there is a long standing requirement for a solution, which should desirably remove any legacy requirement to process or otherwise reformat data output by laboratory equipment at a user-operated workstation.

The present invention mitigates shortcomings associated with the prior art of reference by providing a networked set-and-forget device, adapted to obtain and automatically convert test data output by laboratory equipment and/or stored in a local file server, into a second data format, then automatically communicate the processed data to one or more remote servers across one or more networks.

According to an aspect of the present invention therefore, there is provided a networked data capturing device, comprising networking means for connecting to one or more remote servers over networks ; at least one local data input interface for connecting to at least one laboratory equipment device ; memory means storing computer executable instructions ; and at least one processor configured to access the memory means and to execute the stored computer executable instructions to poll the at least one local data input interface for any data output by the at least one laboratory equipment device ; automatically obtain output test data representative of testing performed by the laboratory equipment device and formatted according to an application layer protocol, wherein the output test data is obtained based upon a polling result, by intercepting a bit stream output by the at least one laboratory equipment device through the at least one local data input interface;
automatically process the obtained data into an alternative format according to a remote parameterisation of the device, wherein the remote parameterisation includes data formatting parameters downloaded by the device from the at least one remote server; and automatically communicate the processed data to at least one remote server with the networking means, wherein the networked data capturing device is connected, firstly, to a single serial port of the laboratory equipment device with a serial cable, having a single-side connection engaged with the serial port of the laboratory equipment device, a first of dual-side connector of the serial cable engaged with a matching serial connector of the networked data capturing device, and a second of the dual-side connector engaged with one of: a user terminal or a local laboratory information system (LIS) fileserver, to duplicate data signal output by the laboratory equipment device, and permit passive streaming of test data to the networked data capturing device.

Advantageously, the combination of software and hardware as the device of the invention automates both the capture of laboratory data from a variety of data protocols and, after its real-time processing for transforming it into a usable format, its downstream processing at remote network locations, usefully removing any requirement for manual intervention in the laboratory environment, thus removing any potential for communication delays, for processing delays and for introducing errors in the data or in communication procedures. It will be appreciated that the invention can collect data from a range of devices that carry out laboratory testing, process only the data as determined in the software driver contained on the device, evaluate that data against defined rules and limits, and alerts the user via a display on the device. In one embodiment if the data is good (for example the colour green) or bad (for example the colour red) can be easily displayed. The evaluation of the data can be performed in a standalone manner by the device or by learning and receiving data from a system connected via LAN or from the internet. Utilising the flexibility of IoT (internet of things) technology the device can work as a standalone entity for evaluating performance of the instrument or as a part of a system receiving information back on the data evaluation.

Additional advantages of the device is that the device can work independently to collect, transform, evaluate, and notify of good or bad data without the requirement for interaction with other systems. Through identifiers in the data stream, the device is configured to build up a history of data types and then select the data to process based on the identifiers it has collected and determined to be the relevant ones.

It will be further appreciated that the device can be scaled to work as part of an overall distributed IoT system by collecting, transforming, and submitting data to a centralised system which communicates information back to the device after evaluating the data and allows the end user to be notified by a visual identifier on the device as to the nature of the data (good or bad). In addition, the device combines hardware and software in one enclosure, removing the requirements for separate collection devices that must communicate with another software system to transform the data into usable format.

In an embodiment of the networked data capturing device, the at least one processor is configured to execute the stored computer executable instructions to obtain test data by intercepting a bit stream output by the at least one laboratory equipment device through the at least one local data input interface.

In a further or complementary embodiment of the networked data capturing device, the at least one processor is configured to execute the stored computer executable instructions to capture the data into a first-in-first-out buffer instantiated in memory for processing substantially in real-time by a translating module according to downloaded formatting parameters to automatically obtain the test data. Through identifiers contained in the data stream, the device is configured to build up a history of data types and then select the data to process based on the identifiers it has collected and determined to be the relevant ones.

In a further or complementary embodiment of the networked data capturing device, the at least one processor is configured to execute the stored computer executable instructions to automatically process the obtained data into the alternative data format by recognising data type, value and format in the output test data including positions and identifiers used for data nomenclature by the at least one laboratory equipment device and generating the processed data having the alternative data format defining alternative positions and identifiers.

In a further or complementary embodiment of the networked data capturing device, the at least one processor is configured to execute the stored computer executable instructions to alternatively obtain test data by loading test data from a laboratory information system (LIS) file server.

In a further or complementary embodiment of the networked data capturing device, the at least one remote server is one selected from the group comprising a client file server connected to a local area network, a database server connected to a local area network, a database server connected to a wide area network and a web server connected to a wide area network.

In a further or complementary embodiment of the networked data capturing device, the at least one local data input interface comprises a serial data input connector, or a Universal Serial Bus (USB) connector, or an <NUM> position <NUM> contact (8P8C) connector.

According to another aspect of the present invention, there is also provided a laboratory data distribution system comprising at least one laboratory equipment device having a local data output interface and adapted both to process one or more samples and to output sampling results as the test data through the local data output interface, and at least one networked data capturing device as described and/or claimed herein, having its at least one local data input interface connected to the local data output interface.

In an embodiment of the system, wherein the at least one laboratory equipment device is connected to a laboratory information system or laboratory information management system through the local data output interface, the connection between the at least one laboratory equipment device and the at least one networked data capturing device comprises a split connection passing test data through to the laboratory information system or laboratory information management system.

In a further or complementary embodiment of the system, the remote server hosts a database of test data.

Thus the system of the invention can effectively obtain data either as test data directly from laboratory equipment, or as file exports from middleware systems or laboratory information systems at a file server, process that obtained data to extract only relevant or pertinent portions thereof into a database-compatible format, and submit the processed data to another location such as a central database store or wide area network destination location. Embodiments of the system may further provide mapping capabilities, wherein a system user is able to specify a specific format into which the obtained data is processed onto the outgoing data stream. According to a further aspect of the present invention, there is also provided a method of distributing test data output by at least one laboratory equipment device, the method comprising the steps of connecting at least one local data input interface of a networked data capturing device according to any of claims <NUM> to <NUM> to the at least one laboratory equipment device ; polling the at least one local data input interface for data output by the at least one laboratory equipment device ; automatically obtaining the test data, wherein the test data is representative of testing performed by the laboratory equipment device and formatted according to an application layer protocol, wherein the test data is obtained based upon a polling result, by intercepting a bit stream output by the at least one laboratory equipment device through the at least one local data input interface, automatically processing the obtained data into an alternative format according to a remote parameterisation of the device, wherein the remote parameterisation includes data formatting parameters downloaded from the at least one remote server; and automatically communicating the processed data to a remote server with the networking means, wherein the networked data capturing device is connected, firstly, to a single serial port of the laboratory equipment device with a serial cable, having a single-side connection engaged with the serial port of the laboratory equipment device, a first of dual-side connector of the serial cable engaged with a matching serial connector of the networked data capturing device, and a second of the dual-side connector engaged with one of: a user terminal or a local laboratory information system (LIS) fileserver, to duplicate data signal output by the laboratory equipment device, and permit passive streaming of test data to the networked data capturing device.

In an embodiment of the method, the step of automatically obtaining the test data may comprise the further step of intercepting a bit stream output by the at least one laboratory equipment device through the at least one local data input interface, based upon a polling result; or the step of loading test data from a data file stored at a local file server connected to the network.

In a further or complementary embodiment of the method, the step of automatically processing the obtained data may comprise the further steps of registering the or each networked data capturing device to the at least one remote server, inputting and storing parameterisation of the device at the at least one remote server; and downloading the stored parameterisation with the or each networked data capturing device from the at least one remote server.

In a further or complementary embodiment of the method, the at least one remote server is preferably selected from the group comprising a client file server connected to a local area network, a database server connected to a local area network, a database server connected to a wide area network and a web server connected to a wide area network. A variant of this method may comprise the further step of loading a set of computer-readable instructions into the networked data capturing device from the database server or the web server over the wide area network for configuring the networked data capturing device to perform steps of the method according to the invention.

In one embodiment the step of automatically obtaining the test data comprises the step of capturing the data into a first-in-first-out buffer instantiated in memory for processing substantially in real-time by a translating module according to downloaded formatting parameters to automatically obtain the test data.

In one embodiment the step of automatically obtaining the test data comprises the step of recognising data type, value and format in the output test data including positions and identifiers used for data nomenclature by the at least one laboratory equipment device; and generating the processed data having the alternative data format defining alternative positions and identifiers.

According to yet another aspect of the present invention, there is also provided non-transitory computer-readable medium storing computer-executable instructions that, when executed by at least one processor, configure the at least one processor to implement a method as described hereinabove and thus to perform operations comprising polling a local data input interface connected to a data output interface of at least one laboratory equipment device, for any data output by the at least one laboratory equipment device ; automatically obtaining test data, wherein the test data is representative of testing performed by the laboratory equipment device and formatted according to an application layer protocol, wherein the test data is obtained based upon a polling result, by intercepting a bit stream output by the at least one laboratory equipment device through the at least one local data input interface; automatically processing the obtained data into an alternative format according to a remote parameterisation of the device, wherein the remote parameterisation includes data formatting parameters downloaded from the at least one remote server; and automatically communicating the processed data to a remote server with networking means, wherein the networked data capturing device is connected, firstly, to a single serial port of the laboratory equipment device with a serial cable, having a single-side connection engaged with the serial port of the laboratory equipment device, a first of dual-side connector of the serial cable engaged with a matching serial connector of the networked data capturing device, and a second of the dual-side connector engaged with one of: a user terminal or a local laboratory information system (LIS) fileserver, to duplicate data signal output by the laboratory equipment device, and permit passive streaming of test data to the networked data capturing device.

In any of the device, system, method, computer-executable instructions and their various embodiments introduced hereinabove, the obtained test data is preferably formatted according to an application layer protocol compliant with a messaging format, for example the Health Level <NUM> messaging format.

Other aspects of the present invention are as stated in the appended claims.

The invention will be more clearly understood from the following description of an embodiment thereof, given by way of example only, with reference to the accompanying drawings, in which:-.

There will now be described by way of example a specific mode contemplated by the inventors. In the following description numerous specific details are set forth in order to provide a thorough understanding. It will be apparent however, to one skilled in the art, that the present invention may be practiced without limitation to these specific details. In other instances, well known methods and structures have not been described in detail so as not to unnecessarily obscure the description.

Referring now to the figures and initially <FIG>, there is shown a distributed data processing environment comprising a laboratory environment <NUM> having a plurality of data processing devices, including a networked data capturing device <NUM> according to an embodiment of the invention, laboratory equipment devices <NUM><NUM>,<NUM>,<NUM>, a user terminal <NUM> and a local LIS fileserver <NUM>.

In the example, at least one laboratory equipment device <NUM><NUM> is a device processing biological or chemical samples, which outputs sampling test data through a single RS232 port, such as a DB9 connector. The laboratory device <NUM><NUM> is connected, through a compatible serial cable, to a serial or USB data input connector of the user terminal <NUM>, respectively through a matching DB9 connector or via a USB socket configured with a serial-to-USB pass-through connector. It will be readily understood to the skilled person that the laboratory equipment device <NUM><NUM> may be connected to the local LIS fileserver <NUM> instead of the user terminal <NUM>, since either configuration corresponds to a conventional configuration and is immaterial to the inventive principle disclosed and described herein.

Each of the user terminal <NUM> and the local LIS fileserver <NUM> is a personal computer device, which emits and receives data encoded as digital signals over wired and/or wireless network messages, wherein such messages are routed by a router device <NUM> implementing a wired local area network (`LAN') <NUM> operating according to the IEEE <NUM>-<NUM> Gigabit Ethernet transmission protocol, and optionally a high-bandwidth wireless local area network (`WLAN') operating according to the IEEE <NUM> Wi-Fi wireless transmission protocol. The router device <NUM> is itself also connected to a wide area network ('WAN') <NUM> via a conventional ADSL or optical fibre connection to a wired telecommunication network <NUM>, wherein the router device <NUM> interfaces either the user terminal <NUM>, or the local LIS fileserver <NUM>, or both computers with the WAN <NUM>.

A server <NUM> is also shown in <FIG> and which is remote from the laboratory environment <NUM>, but which is likewise interfaced with the WAN <NUM> through a local router device <NUM> which implements its own LAN <NUM> and which is similarly connected to the WAN <NUM> via a conventional ADSL or optical fibre connection to a wired telecommunication network <NUM>.

In the embodiment described, the networked data capturing device <NUM> is adapted to listen passively to the output test data streamed by the laboratory equipment device <NUM><NUM> serial port, to automatically process any such output test data for extracting sampling values, parameters and similar other quantitative data from same, formatting same according to predefined parameters, and lastly to automatically forward the processed data to the remote server <NUM> across the WAN <NUM>, including through any firewall device, apparatus or construct implemented by the router <NUM> in the laboratory environment <NUM>.

Accordingly the networked data capturing device <NUM> is connected, firstly, to the single RS232 serial port of the laboratory equipment device <NUM><NUM> with a Y-shaped splitter serial cable, having its single-side DB9 connection engaged with the serial port of the laboratory equipment device <NUM><NUM>, a first of its dual-side DB9 connectors engaged with a matching serial DB9 connector (or a USB socket configured with a serial-to-USB pass-through connector) of the networked data capturing device <NUM>, and the second of its dual-side DB9 connectors engaged with the user terminal <NUM> or the local LIS fileserver <NUM>: this configuration effectively duplicates the data signal output by the laboratory equipment device <NUM><NUM> and permits passive streaming of the test data to the networked data capturing device <NUM> without hindering the legacy connection.

It will be readily understood by the skilled person from the present disclosure, that the above configuration is provided by way of example only, and may be subject to many ad hoc changes depending on the connectivity hardware featured by laboratory equipment devices, on whether a laboratory equipment device requires any connection to a computer such as the user terminal <NUM> and/or the LIS fileserver <NUM> for its use, on whether such a connection can or cannot be passed through a third party device such as networked data capturing device <NUM>, and more, without impacting the functionality of the networked data capturing device <NUM> and the inventive principles described herein in any way.

For purposes of automatically forwarding the processed data to the remote server <NUM> across the WAN <NUM>, the networked data capturing device <NUM> is also connected, secondly, to the router <NUM> through the LAN <NUM> or WLAN, whereby network connectivity and interoperable networking protocols of each described data processing device <NUM>, <NUM>, <NUM>, <NUM> allow the terminals to connect to one another and communicate data to and receive data from one another according to the methodology described herein. In that context, the router <NUM>, or an associated firewall device if firewalling is not implemented by the router itself, is preferably configured to allow outbound network messaging from the networked data capturing device <NUM>, i.e. network data addressed to the remote server <NUM>, through one or two specific ports, for instance <NUM> and/or <NUM>, to balance the conflicting requirements of permitting non-monitored communications by the networked data capturing device <NUM> to the remote server <NUM> outside the laboratory environment <NUM> and LAN <NUM>, and of maintaining network and data security at the laboratory environment <NUM>. The device can be set to communicate outbound on whatever port a user would like. An advantage of using ports <NUM> or <NUM> is that these are common ports that are usually open for communication outbound at most laboratories and this makes the device more user friendly and limits the requirement for user based intervention. The internet based server can listen for communication on port <NUM> or <NUM> which are standard ports used for internet communication.

<FIG> shows a bloc diagram of an embodiment of the networked data capturing device <NUM> of <FIG>, in this example a single board computer device <NUM>. The capturing device <NUM> accordingly includes a central data processing unit ('CPU') <NUM> such as a general-purpose microprocessor, for instance conforming to the Cortex™ architecture manufactured by ARM™, acting as the main controller of the capturing device <NUM> for providing task co-ordination and data processing functionality. Sets of instructions and data for the CPU <NUM> are stored in memory means, comprising of volatile random-access memory (RAM) <NUM> and/or non-volatile random-access memory (NVRAM) <NUM> and/or a combination thereof.

Embodiments of the capturing device <NUM> may further comprise a selectively removable memory means, shown in the example as a micro Secure Digital™ ('mSD') card reader-writer module <NUM>, to facilitate ad hoc expansion of the data storage capacity of the capturing device <NUM> beyond the onboard RAM/NVRAM storage volume. Embodiments of the capturing device <NUM> may instead include only that selectively removable memory means <NUM> which, when containing a suitable flash memory storage medium (not shown), dispense with the requirement for onboard RAM <NUM> and/or NVRAM <NUM>.

A universal serial bus (USB) input/output interface <NUM> facilitates connection to one or more laboratory equipment device(s) <NUM>N, optionally with the adjunction of an external serial-to-USB interfacing adapter depending on the hardware connectivity format of the laboratory equipment device <NUM>, and which permits the output test data stream to pass through to the user terminal <NUM> and/or LIS server <NUM> unimpeded when used in conjunction with a splitter cable as previously described. Embodiments of the capturing device <NUM> may also, or instead, comprise a legacy serial input/output interface <NUM>, having substantially the same purposes and functionalities as the USB interface <NUM> and dispensing with the need for an external serial-to-USB interfacing adapter when the hardware connectivity format of the laboratory equipment device <NUM> is also of the serial type.

A wired network interface card (NIC) <NUM> provides the interface to the LAN network connection <NUM> with the router device <NUM>, and all of the above-described components of the capturing device <NUM> are both connected to a data input/output bus <NUM>, over which they communicate, and powered by a power supply unit <NUM>, which receives electrical power from a local mains power source and transforms same according to component ratings and requirements. Accordingly, test data output by a laboratory equipment device <NUM> may be received from USB I/O interface <NUM> and/or serial I/O interface <NUM>, stored in the memory means <NUM> or <NUM> or <NUM>, processed by the CPU <NUM> according to a set of instructions also stored in the memory means <NUM> or <NUM> or <NUM>, and the processed data communicated to the remote server <NUM> through the NIC <NUM>.

For the sake of not obscuring the present description unnecessarily, the following assumes an embodiment of the networked data capturing device <NUM> comprising a CPU <NUM> associated with a RAM module <NUM>, wherein the contents of the memory means <NUM> of <FIG> during operation of the networked data capturing device <NUM> are shown in <FIG>.

An operating system ('OS') is first shown at <NUM>, which may be a variant of Linux@ suited to the CPU <NUM>, for instance Archlinux ARM, Ubuntu ARM or mbed OS when the CPU is a Cortex™ chip as previously described, and which includes both instructions for governing the basic data processing, interdependence and interoperability of the device hardware components e.g. as described in <FIG>; and communication subroutines <NUM> to configure the capturing device <NUM> for unilateral (RX) data communication with a connected laboratory equipment device <NUM> and for bilateral network communication via the NIC <NUM> interfaced with the wired connection <NUM> to the local router <NUM>.

A set of instructions is next shown at <NUM>, which is interfaced with the OS <NUM>, particularly the network communication subroutines <NUM> thereof, via one or more suitable Application Programmer Interfaces ('API') <NUM>, and which configures the capturing device <NUM> to capture and process test data output by a directly-connected laboratory equipment device, to acquire one or more data files stored at the local fileserver <NUM> over the LAN and process output test data therein, and to forward the processed data to the remote server <NUM> across the WAN <NUM>.

Accordingly, the set of instructions <NUM> firstly comprises a listening-fetching module <NUM> adapted to listen passively to the output test data streamed by a laboratory equipment device <NUM><NUM> serial port, and to acquire output test data from one or more data files stored at a networked terminal such as the local user terminal <NUM> or the local fileserver <NUM>. The listening-fetching module <NUM> comprises a driver sub-module <NUM> adapted to recognise data type(s), value(s) and format(s) in a data stream output by a connected laboratory equipment device <NUM>N, for instance conforming to the ASTM standard which defines the positions and identifiers used for data nomenclature by the instrument <NUM>, and to extract sampling values, parameters and similar other quantitative data from the test data.

The set of instructions <NUM> next comprises a translating module <NUM> adapted to automatically process any extracted test data communicated to it by the driver sub-module <NUM> into an alternate data stream having a different format defining alternative positions and identifiers. The translating module <NUM> thus stores data-formatting parameters <NUM> that are user-predefined at the remote server <NUM>, and is adapted to format the sampling values, parameters and similar other quantitative data in the test data extracted by the driver <NUM> according to the said predefined parameters.

The set of instructions <NUM> next comprises a networking module <NUM> adapted to automatically establish a network session with the remote server <NUM> across the WAN <NUM>, including through any firewall device, apparatus or construct implemented by the router <NUM> in the laboratory environment <NUM>, for downloading the predefined data-formatting parameters <NUM> when the networked data capturing device <NUM> is first switched on, according to principle described herein. The networking module <NUM> is further adapted to forward any processed data communicated to it by the formatting module <NUM>, to one or more networked terminals such as the local user terminal <NUM> and/or the local fileserver <NUM> across the LAN <NUM>, and/or the remote server <NUM> across the WAN <NUM>. The networking module <NUM> thus stores one or more target LAN and/or WAN network addresses <NUM> that are user-predefined at the remote server <NUM>, besides the WAN network address of the server <NUM>, so that the networking module <NUM> can correctly address network messages representative of the processed data being transmitted.

Further local and network data <NUM> may be stored in the memory means <NUM> of the capturing device <NUM> at runtime, some or all of which may be processed either by the set of instructions <NUM>, or by or for the OS <NUM> being processed by the device components in parallel with the set of instructions <NUM>. With reference to <FIG> described herein, examples of local data include for instance buffered test data <NUM> captured by the listening-fetching module <NUM> through the USB or serial I/O interfaces <NUM>, <NUM> for processing by the driver <NUM> and translating module <NUM>, buffered file data <NUM> loaded by the listening-fetching module <NUM> from the local fileserver <NUM> for processing by the driver <NUM> and translating module <NUM>, processed test data <NUM> for network messaging by the networking module <NUM>, and component device drivers loaded for the invoking by the OS <NUM>. Examples of network data include for instance incoming network messages being received from the local fileserver <NUM>, incoming network messages being received from the remote server <NUM>, outgoing network messages addressed to the remote server <NUM>, and keepalive (KA) network messages being sent by the OS <NUM> and received from the router <NUM> and those connected amongst remote terminals <NUM>, <NUM>, <NUM>.

In use, networked data capturing devices <NUM> of the invention are distributed to users by the administrator of the server <NUM>, each with a unique device identifier such as a serial number or simply the respective media access control ('MAC') address of the NIC <NUM> therein, and with the set of instructions <NUM> and at least the network address of the server <NUM> loaded in the memory <NUM> or <NUM>, but without any formatting parameter <NUM> nor further network address(es) <NUM>. After taking delivery of it, a user must first parameterise the networked data capturing device <NUM> remotely at the remote server <NUM>, and steps of a main logic performed by the user terminal <NUM> shown in <FIG> for registering and inputting parameterisation of the networked data capturing device <NUM> at the remote server <NUM> are now described with reference to <FIG>.

The user terminal <NUM> is initially switched on, and conventionally loads its operating system, for example Windows <NUM>® manufactured and distributed by the Windows Corporation of Redmond, USA, inclusive of networking subroutines to configure the user terminal <NUM> for bilateral (TX-RX) data communication with the wired connection <NUM> to the local router <NUM> and thence to the remote server <NUM> across the WAN <NUM>, at step <NUM>. A conventional browser application is next loaded, and directed to a web user interface distributed by the remote server <NUM> across the WAN <NUM>, at step <NUM>. At step <NUM>, the user of the laboratory terminal <NUM> inputs authenticating data, such as a unique user identifier, in the web user interface and validly logs on at the remote server <NUM>.

At the next step <NUM>, the user of the laboratory terminal <NUM> inputs the unique device identifier of the delivered the networked data capturing device <NUM> in the web user interface, for registering a unique association between the user account corresponding to the authenticating data and the respective unique device identifier of the delivered the networked data capturing device <NUM> at the remote server <NUM>. After receiving and validating the respective unique device identifier, by checking whether a registration record for the same device identifier is not yet stored, the remote server <NUM> validates the registration by creating and storing a new registration record with the authenticating data and received unique device identifier, then distributes a formatting selection template to the browser at the user terminal <NUM>.

Accordingly, a first question is asked at step <NUM>, about whether one ore more formatting parameter(s) <NUM> are required. When the question of step <NUM> is answered positively, the remote server <NUM> distributes a formatting selection template to the browser at the user terminal <NUM>, so that the user of the laboratory terminal <NUM> may associate, or 'map', data type(s), data positions and data identifiers in the ASTM stream of test data output by the instrument <NUM>, with alternative data type(s), data positions and data identifiers desired in the processed data output by the set of instructions <NUM> and forwarded to remote server(s), for instance an alternative data nomenclature corresponding to field names in a database hosted at any such remote server(s). In one embodiment the activation form will allow the end user to select a driver based on the information provided about the instrument model or the LIS/middleware output file. This can be provided in advance so the driver is already developed and ready for selection by a user. A mapping screen is on the IAMQC Transfer Management Console where the output from the device will be to a predefined format (CSV for example). The mapping screen will allow the end user to input "translations" for data received on the ASTM stream for specified fields/columns that go in the CSV file. Simplified examples of an ASTM stream of test data <NUM> output by the instrument <NUM>, and of an association with alternative data type(s), data positions and data identifiers by way of illustrating predefined data-formatting parameters <NUM>, are shown in <FIG> and <FIG>.

When the question of step <NUM> is answered negatively however, a next question is asked at step <NUM>, about whether a new or alternative repository of stored output test data in the LAN <NUM> and/or the network address of an additional target terminal for the processed test data, should be recorded in the repository <NUM> at the networked data capturing device <NUM>.

When the question of step <NUM> is answered positively, then the remote server distributes a networked resource pathway template to the browser at the user terminal <NUM> so that, at step <NUM>, the user may input in the web user interface, either the network pathway across the LAN <NUM> corresponding to a shared drive, folder or other structure of the user terminal <NUM> or the local LIS file server <NUM>, in which any test data directly output to it by the laboratory equipment device <NUM> is ordinarily stored; and/or the network pathway across the LAN <NUM> and/or across the WAN, corresponding to a drive, folder or other structure of the user terminal <NUM>, the local LIS file server <NUM> and/or a further remote server besides remote server <NUM>, to which any test data processed by the capturing device <NUM> should be automatically sent.

When the question of step <NUM> is answered negatively however, a question is last asked at step <NUM>, about whether a log off interrupt has been input, for instance an interaction of the user with the graphical user interface of the user terminal OS of the user terminal <NUM>, to close the browser application started at step <NUM>. When the question of step <NUM> is answered negatively, control returns to the question of step <NUM>, the remote server <NUM> polling the remote user terminal <NUM> for any further input or interrupt in a processing loop, until such time as the question of step <NUM> is eventually answered positively, whereby the session with the remote server <NUM> is closed, and the user terminal <NUM> may be used for another purpose and/or switched off eventually.

User inputs and selections defining parameterisation through steps <NUM> to <NUM> are received at the remote server <NUM> and stored in the registration record associated with the respective unique device identifier of the delivered networked data capturing device <NUM>. On a first use of the networked data capturing device <NUM>, steps <NUM> to <NUM> correspond to a first basic parameterisation of the new networked data capturing device <NUM>, sufficient to provide basic data processing functionality to the device for capturing output test data from the laboratory equipment device <NUM>, processing it with the application modules <NUM>, <NUM>, <NUM> and forwarding it to the remote server <NUM>.

Further or alternative parameterisation of the networked data capturing device <NUM> may be performed at the remote server <NUM> in a subsequent session, for instance when alternative formatting parameters <NUM> are required relative to those first entered at registration, and/or when processed test data should be forwarded to a different or additional networked terminal. It will be appreciated that further configuration can be carried out using a Transfer Management Console which can be installed at the laboratory on a PC there. The configuration is then updated to the remote server <NUM>. Steps <NUM> and <NUM> are repeated, wherein the initial registration record of step <NUM> is then identified by the remote server <NUM> based on the unique association between the user account associated with the logon of step <NUM> and the respective unique device identifier of the capturing device <NUM> in the registration record, then steps <NUM> to <NUM> are repeated to input the alternative parameterisation and/or LAN/WAN network addresses.

After its physical delivery at the laboratory <NUM>, and an initial registration of the networked data capturing device <NUM> by performing steps <NUM> to <NUM> for that device for the first time, the capturing device <NUM> is sited, connected to the LAN <NUM>, optionally also connected to the laboratory equipment device <NUM>, then powered up. Steps of the main logic performed by the set of instructions <NUM> and modules <NUM>, <NUM>, <NUM> according to the remote parameterisation of steps <NUM> to <NUM> are now described with reference to <FIG>, when the capturing device <NUM> is first powered up.

At step <NUM>, the networked data capturing device <NUM> loads its operating system <NUM> inclusive of the networking subroutines <NUM> and the set of instructions <NUM>. At step <NUM>, the networking module <NUM> looks up the WAN network address of the remote server <NUM> in the repository <NUM> and establishes a network session across the LAN <NUM> and WAN <NUM> with the remote server <NUM>. At step <NUM>, the translating module <NUM> downloads any formatting parameters <NUM> stored by the remote server <NUM> as input by the user at step <NUM>, and the networking module <NUM> downloads any LAN pathway data <NUM> representative of shared drive(s), folder(s) or other structure(s) of the local user terminal <NUM> or LIS file server <NUM>, as stored by the remote server <NUM> after input by the user at step <NUM>. Further to completing the downloading of step <NUM>, the networked data capturing device <NUM> is fully configured to operate autonomously as described hereafter, until and unless it should be switched off, for relocation, maintenance or another non-data capturing purpose.

A first question is then asked at step <NUM>, corresponding to polling of the USB and serial I/O interfaces <NUM>, <NUM> by the listening-fetching module <NUM>, about whether there is any output test data <NUM> being received from a connected laboratory equipment device <NUM>. With reference to <FIG>, if the question of step <NUM> is answered positively, then the data stream <NUM> is captured by the device <NUM> into a first-in-first-out buffer instantiated in memory <NUM> at step <NUM>, for processing substantially in real-time by the translating module <NUM> at step <NUM> according to the downloaded formatting parameters <NUM>, wherein the size of the buffer corresponds substantially to the processing latency of the device components and overall processing logic of the instructions <NUM>.

If the question of step <NUM> is answered negatively however, then a next question is asked at step <NUM> corresponding to, with reference to <FIG>, querying the shared drive(s), folder(s) or other structure(s) of the user terminal <NUM> or LIS fileserver <NUM> through the LAN pathway data <NUM> by the networking module <NUM> and the driver <NUM>, about whether there is any new or updated data file of output test data <NUM> stored at the user terminal <NUM> or local LIS file server <NUM>. If the question of step <NUM> is answered positively, then the new or updated data file of output test data <NUM> is again loaded in memory <NUM> at step <NUM>, again for processing substantially in real-time at step <NUM> by the translating module <NUM> according to the downloaded formatting parameters <NUM>.

Any data <NUM> processed by the translating module <NUM> at step <NUM> is output to the networking module <NUM> substantially in real-time, which communicates it likewise substantially in real-time to the one or more target(s) networked terminals specified in the repository <NUM> at step <NUM>, thus any one or more of the user terminal <NUM> the LIS fileserver <NUM> and the remote server <NUM>, invariably in the format <NUM> expected by the target terminal as predefined by the user at step <NUM>.

A question is then asked at step <NUM>, about whether there remains output test data <NUM> stored either in the FIFO buffer or in the data file loaded from the user terminal <NUM> or LIS fileserver <NUM> in the memory <NUM> to process at step <NUM>. If the question of step <NUM> is answered positively, control returns to step <NUM>, whereby the output test data from the laboratory equipment device <NUM> or the LIS fileserver <NUM> continues to be processed as it is being fetched and buffered/loaded, then communicated to the remote server <NUM> substantially in real-time, and so on and so forth as represented by a circular dashed arrow in <FIG> and <FIG>.

Alternatively, the question of step <NUM> is answered negatively and, likewise when the question of step <NUM> is answered negatively, then control proceeds to a next question at step <NUM>, about whether a switch off interrupt has been received, for instance an interaction of the user with an on/off hardware switch of the networked data capturing device <NUM>. When the question of step <NUM> is answered negatively, control returns to the initial question of step <NUM>, so that any further output test data being received from a connected laboratory equipment device <NUM> or new/updated data file at the LIS fileserver <NUM> may be detected, captured, processed and so on and so forth. Alternatively, the question of step <NUM> is answered positively, whereby the networked data capturing device <NUM> is eventually switched off.

Claim 1:
A networked data capturing device (<NUM>), that comprises:
networking means for connecting to one or more remote servers (<NUM>) over networks (<NUM>, <NUM>, <NUM>);
at least one local data input interface (<NUM>, <NUM>) for connecting to at least one laboratory equipment device (<NUM> i);
memory means (<NUM>, <NUM>, <NUM>) storing computer executable instructions; and
at least one processor (<NUM>) configured to access the memory-means (<NUM>, <NUM>, <NUM>) and to execute the stored computer executable instructions to
poll the at least one local data input interface (<NUM>, <NUM>) for data output by the at least one laboratory equipment device (<NUM> i);
automatically obtain output test data (<NUM>) representative of testing performed by the laboratory equipment device and formatted according to an application layer protocol, wherein the output test data (<NUM>) is obtained based upon a polling result, by intercepting a bit stream output by the at least one laboratory equipment device (<NUM> i) through the at least one local data input interface (<NUM>, <NUM>);
automatically process the obtained data (<NUM>) into an alternative data format according to a remote parameterisation of the device (<NUM>), wherein the remote parameterisation includes data formatting parameters downloaded by the device (<NUM>) from the at least one remote server (<NUM>); and
automatically communicate the processed data (<NUM>) to at least one remote server (<NUM>) with the networking means, wherein the networked data capturing device (<NUM>) is connected, firstly, to a single serial port of the laboratory equipment device (<NUM> i) with a serial cable, having a single-side connection engaged with the serial port of the laboratory equipment device (110i), a first of dual-side connector of the serial cable engaged with a matching serial connector of the networked data capturing device (<NUM>), and a second of the dual-side connector engaged with one of: a user terminal or a local laboratory information system, LIS, fileserver, to duplicate data signal output by the laboratory equipment device (110i), and permit passive streaming of test data to the networked data capturing device (<NUM>).