How Medtronic Manages Machine Data in MongoDB

Matt Asay


While many think Big Data is all about “big,” the reality for most organizations is that data variety is a far thornier problem to tackle.

Just ask Medtronic.

Medical equipment maker Medtronic, perhaps best known for its pacemakers, offers devices and therapies that address more than 30 diseases. Last year the company served 9 million patients and this year the company announced that it serves a patient in some way every three seconds. In addition, Medtronic collects more than 30 million data samples about its devices every day.

Matthew Chimento, principal test engineer and project manager at Medtronic, notes that more than 150 data collection and processing steps have been added to Medtronic’s manufacturing process in the last three years, and 40% of all of Medtronic’s stored data has been collected in the last two. Humans aren’t great at collecting data, but machines are, and “we have a lot of machines.”

Now if only those machines all spoke the same language.

Data Variety: Problem And Opportunity

Unfortunately, with a proliferation of machines comes a proliferation of different data types. And while the media likes to talk about “Big Data” as if it were all about volume, companies like Medtronic realize Big Data is primarily a matter of data variety, as a NewVantage Partners survey discovered:

Furthermore, for regulatory reasons, Medtronic must save device data for 10 years after the last implant of the device. Since those devices can last 20 years, some data is 30 years old, which means that Medtronic must contend with information spread across a multitude of obscure database systems, in a wide variety of formats.

Does Your Data Speak MongoDB?

To manage this data complexity, Medtronic turned to MongoDB.

About two years ago, Chimento’s colleague, Jeff Lemmerman, a senior software engineer at Medtronic, heard about MongoDB. Intrigued by the NoSQL database and its potential to help Medtronic tame its ever-changing data requirements, Lemmerman launched a proof of concept, which “basically consisted of choosing one battery model that we manufacture.” When the battery goes through electrolyte fill – a step in the manufacturing process – all of the component data is loaded into MongoDB. “This is a very simple place to start,” he said.

Lemmerman has high hopes for the next steps with MongoDB. He hopes to begin loading manufacturing data on every component Medtronic makes directly into MongoDB, and aggregating that data into a device-level view, and MongoDB’s data model will make that easy. “You’re trying to facilitate analysis across components, and you really want simple, fast queries … instead of doing those nasty joins that we saw in my relational example, I’m able to find the complete history for a component with a very simple query.”

What Can MongoDB Do For You?

Like Medtronic, your data changes constantly as business requirements change. And, like Medtronic and most enterprises, you likely use a relational database to manage that data. For reasons noted above, as well as here, an RDBMS is a poor fit for data that changes often or for applications that need to scale.

We therefore invite you to check out the RDBMS to MongoDB Migration Guide to determine how best to migrate data from your RDBMS to MongoDB.