cdx logo

Reliable and timely diagnostic test information is of paramount importance for the proper functioning of several components of the diagnostic and treatment cascade. These include patient management, epidemiologic surveillance, quality assurance, laboratory operations, and technical product support. When developing connected diagnostic instruments however, many manufacturers often fail to recognise the value of instrument data.

These data can be extremely beneficial, especially when just introduced to market or for smaller manufacturers to understand how the instrument is being used and its performance in the field. Data can be used to understand failure rates and error trends for post market surveillance, to provide proactive and preventive troubleshooting or to optimise the manufacturing of consumables. With the consumables often the main revenue generation for diagnostic instruments and with a limited shelf life, the overproduction or underproduction of them is often a costly mistake. Many manufacturers still however rely on guesswork when it comes to forecasting how many to produce when data from instruments could provide far more accurate forecasting based on customer utilisation. Why is this?

Quite often this is down to bad design and planning of the connectivity functions within the instruments. The mistake that is made is treating data as a singular entity and routing it to singular endpoints. Why shouldn’t data be routed to multiple endpoints, to different stakeholders dependant on their needs. Manufacturers tend to shy away from collecting personally identifiable patient information due to all of the regulatory compliance that goes along with it but why not treat clinical, operational and proprietary data differently?

Proprietary instrument performance data, that being of benefit to the manufacturer and of little value to anyone else needs to be sent back for the purpose as stated above but often this is more challenging than initially expected. There are a couple of reasons for this, the first being that the design of the connectivity function only supports the sending of data to one endpoint, this results in data either being routed in one of 2 ways.

The approach we saw at the introduction of connectivity for medical instruments was to initially route all data to the manufacturer where it would be offered to customers via some form of API or ability to download. This approach has been tried before and is often rejected by customers who wish to be control of their data and to avoid the additional process steps of collecting that data. Fears about how data is stored, protected and how it might be used were also issues in this approach. This approach was tried by manufacturers who thought they could somehow monetise the data in some way.

The other approach is to route all data to customer systems. Whilst this might seem normal, the ability to then derive the proprietary instrument performance data often fails. Even with the best intent in the world, customers are simply not going to take time to separate these data from clinical sets and send them on. The instrument itself needs to be able to send data back to HQ but is often prohibited from doing this by singular endpoint limitations or by the fact that they are now placed behind strict institution firewalls that don’t allow data to be sent out.

So how do you get the all important and valuable proprietary data out of the instrument?

There are a number of solutions here and it will ultimately depend on the what the intended use of the instrument is and where it is going to be placed. One option is to place a completely proprietary communications method such as a cellular chipset within that is only used for sending data back to the manufacturer. Whilst this approach is feasible there are challenges such as the cost of modems and data SIMs which inevitably become higher if you wish to produce a global product as opposed to regional variants.

Another approach is to develop the transmission protocol so that it can separate data according to stakeholders and route to multiple destinations. This has a number of issues in itself as needs will inevitably change over time and configuration will need to be changed.

Other options are to use integration engines that allow data not only to be routed to different stakeholders but also transformed into multiple data formats such as HL7, FHIR, POCT-1a etc. In summary there is no correct way of collecting proprietary data and whilst the challenges and options might seem daunting, the value of the data are well worth it and can offer many insights, benefits and advantages. The team at Connected Diagnostics have a wealth of experience in this area understanding both challenges and solutions.


Chris Isaacs

CEO - Connected Diagnostics