The worn cliche: Data is the new oil!

Your organization may be big. It might be small. It might be a mature business, with an approved device pipeline, or, it might be an early stage one. Your organization might have any number of adjectives describing its nature, size and characteristics. The commonality, is that, if it is a healthcare organization (or any type of organization, though we are focused on healthcare here), it has data, that can be classified and categorized in several ways, and can indicate to a point in the immediate or distant future, where it could have significant impact and ROI depending on how it is analyzed and applied in alignment with your organizational goals.

Thus, whether the cliche seems tired to you or not, there is a lot of truth to the statement that your data can be useful in several ways in the future – it could represent inherent value for investors, it could help with forensics and root cause analysis, in new designs, in optimizing performance, manufacturing, service, competitiveness and possibly in many different ways you haven’t yet imagined! This then indicates you should have a sound data strategy.

Storage is Tactical, Not Strategic

If you think, “well, our strategy is to acquire the data, store it in the cloud and back up for when we are ready for AI”, you are confusing tact with strategy. Some might argue that the act of storing data is even more banal than being tact. There might be truth to that, but let us make sure that you do have sound plans to acquire and store data with back up plans that are better than what MySpace appears to have been employing (for the Rip Van Winkles out there, I will provide a link of the recent disaster that MySpace was engaged in – essentially losing approximately a decade’s worth of its users’ music)!

So, your strategy for data needs to be a lot more than strategy.

However, do not take storage lightly! In my career, I have seen organizations with weak leadership that engaged in such stupid ways (and this is putting it kindly) of collecting and archiving data, that they lost critical and crucial, historic information relating to verification and validation!!

So, while it might seem simple, make sure your organization has well tested and trusted methods of collecting and archiving data, backed up appropriately and retrieved securely, with reasonable ease. At a minimum, you should consult with Data Scientists, if your size and budget does not permit developing a Data Science team in-house. It might be appropriate for the Quality and/or Regulatory functions within a small organization to bear the responsibility for this. For device and drug companies, regulations already require much of this, and yet you would be surprised how easy it is for organizations to miss the mark on this.

Labeling

There are several definitions for data labeling and definition of structure, as it pertains to data. I will leave this as a basic exercise for you, the reader, but I am sure, you have a commonsense understanding of what the terms allude to, and so let us use that as a yardstick to get to the thrust of this blog, rather than reducing it to pedantic and semantic exercises. Data labeling alludes to the fact that you mark data in terms of body temperature, instrument temperature, body weight, age, sex, heart rate and on and on. For anyone who has done even the simple exercise of bench top testing, it will be obvious that you already have to take a lot of care in labeling data, or the losses can be quite catastrophic.

Labeling tends to be the most expensive and time consuming exercise in preparing your data for Machine Learning, as anyone who has attended a talk by me on this topic has been clearly warned before!

Labeling should be understood in broad terms that go beyond merely the titles of columns and rows on a spreadsheet. For instance, being able to pull several spreadsheets, and readily understand which data came from acute or chronic studies, bench-top or human trials, real vs. simulated data must all be considered. Confuse these, and your machine learning might be trained with the wrong data and the results can be quite undesirable.

Data Labeling should also be very clear at every level and this cannot be stressed enough! If you have data collected by 4 thermocouples, two years from now, when someone pulls up the data for instance, they should be able to identify exactly where the data came!

In effect, you should establish a discipline of rigorous labeling for data, from the macro levels, going into the individual levels, through your SOPs, Work Instructions, Forms and make this a part of organizational culture.

Structuring Data

Data can be classified into Structured Data and Unstructured Data. Structured Data is reflected by the type of data discussed above – data obtained manually, through machines automatically, by programming, through logs, etc. (There is a note about data logs I will make in a moment). Unstructured Data on the other hand, could be data coming from sources such as online customer reviews (if you think this is not for you, just search for reviews on IUDs or Heart Burn Medications on the internet and you are in for a surprise), physician or nurse feedback, complaint information, procedure videos and other sources. Depending on the device, drug, biologic, app or the combinations thereof, your unstructured data can take many forms, and you should develop a very deep understanding of these sources, and how to collect, and structure this data as much as possible.

While, we all assume that some day, in the near or far future, depending on the various predictions, Artificial General Intelligence will allow us to completely skip data labeling (Neural Networks can do this to an extent currently), and analyze data, providing insights. However, there are limitations with current Machine Learning and Deep Learning Approaches, and you are better off providing as much structure to your data as possible.

For instance, if you are capturing procedure videos, whether on models or on humans, you might benefit from using fiducial markers for instance. Such markers are common in imaging systems already. Your device could also have identification markers on it, that show position, location etc., making human and machine understanding fast and easy. This can be very helpful when dealing with explainability and machine training. This could essentially convert the status of your data from ‘unstructured‘ to ‘semi-structured‘ or, if you can further template and refine it, ‘structured‘. Of course, you might hit a point where you get diminishing returns, or, as is the case, the machine can handle semi-structured data well enough.

Identifying the sources of your unstructured data, and striving to provide structure to your data, early, and strategically, will ensure that Data Analysis and Machine Learning Projects will be less expensive and better facilitated.

A note on Machine Logging

I was once involved in a project where the capital equipment logged critical data such as currents, voltages and other data associated with procedures. Various regulations require this, and for Failure Analysis, Adverse Event Investigation, etc. this is generally very essential. The fundamental problem with this (and others I have seen) particular data logging was the lack of foresight and poor implementation. Starting from the very labeling of the log files, to the time stamps, to the data collection frequency and various other features, it was a complete mess. The data had to be pulled from the logs into a spreadsheet program, and a number of routines had to be run on it, to make it passably useful. I used to wonder how a diligent auditor would take to the cumbersome and questionable logging, if he or she were to stumble on it!

Worse, the project leader prided himself in thinking that he had created an innovation in translating the gibberish into a-little-less-gibberish through the scripts! That sort of paucity in planning and respect for data will not help you, if you are to succeed.

The Bigger Picture

I want to make it clear. This is not just exhortation to make machine logs readily readable. And yes, your software team MUST do this. The point here is awareness, education, discipline and diligence towards data. Your organization needs to strive towards all of these aspects – and two more, which follow in the next section. It is not just leadership, but it is your entire organization that needs to focus on this for success.

Patient Privacy and Data Security

Increasingly, ranging from Government Organizations to Data Silo Owners and even other third parties, several organizations are admitting to failures in securing data, exposing data belonging to stakeholders. As you can imagine, exposing your patients’ data, erodes trust and is unforgivable, if the root cause for this is carelessness and sloppy, outdated practices.

Even when patient privacy is not involved, losing data of any other kind, such as test data, designs, manufacturing data etc. can be catastrophic to your competitiveness, and can make or break your organization.

Efforts to secure your data and protect your patients can never cease, and there can never be complacency in any of these areas!

Conclusion

The larger conclusion I want you to draw from my post here is this: you need a Data Strategy. Within that strategy lie elements such as labeling, structuring, security and privacy, none of which can be ignored. Your organizational members need to be educated of the importance of your strategy and they must have a healthy respect to help formulate, improve and maintain the strategy and discipline it will take you to succeed.

References:

  1. Tactic Vs. Strategy: https://en.wikipedia.org/wiki/Tactic_(method)
  2. Image of Tags: https://www.pexels.com/photo/several-assorted-color-tags-697059/
  3. Image of Book Stacks: https://www.pexels.com/photo/pile-of-books-on-gray-metal-rack-1853836/
  4. Image of Escalators: https://www.pexels.com/photo/building-escalator-1769356/
  5. Image of Labeled Beans: https://www.pexels.com/photo/assorted-beans-in-white-sacks-1024005/
  6. Image of Laptop: https://www.pexels.com/photo/low-angle-view-of-human-representation-of-grass-296085/
  7. Data Loss at MySpace (An NY Times Subscription may be required): https://www.nytimes.com/2019/03/19/business/myspace-user-data.html