Everything You Wanted to Know about Qualcomm's 2net App SDK

The 2net App Software Development Kit (SDK) from Qualcomm Life is now available to developers on a variety of data-enabled platforms. Ten companies, including FitBit and Withings, have opened up their data streams to developers using the SDK. Instead of dealing with individual data streams, the service aggregates data streams and pulls it into the cloud. And now, with the APIs, the service allows data miners to come in and look at how they can create apps that will interpret and present that aggregated data.

In addition, Qualcomm has announced the 2net App Developer Challenge to choose the best 2net-enabled applications. The top three will be awarded cash prizes ranging from $5,000 to $20,000. Winners will be announced at the upcoming Wireless Health Conference held October 23 in San Diego. 

“We want to attract the best and most creative developers to the challenge,” says Kabir Kasargod, wireless health business development at Qualcomm Labs (San Diego). “[In addition to the cash prize], one of the key things that we are doing, which we have never done before, is invite the developers to be part of the Qualcomm pavilion and showcase their app,” he adds. “So in addition to the cash prize, one of the things that we are doing is immediately making them one of our key partners and introducing them to the right ecosystem players and making them a part of the ecosystem right away.”

To learn more about the SDK as well as the prize, Brian Buntz, editor-at-large for UBM’s medical device group and Bill Betten, medical technology director at UBM TechInsights sat down for an in-depth discussion with Kasargod. 

MD+DI: What do you think is the most important thing that you feel digital health companies should know about the 2net SDK?

Kabir Kasargod, Qualcomm Labs: For us, it is really important that developers now have an opportunity to have one consolidated data stream across multiple radio technologies—across apps. They can now have one way of unifying all of that content and visualizing the data inside of the applications so that they don’t have to use any of the siloed apps and services. Rather, they can have one consolidated platform to get all of that data.

MD+DI: Could you explain how the availability of the 2net SDK will ultimately help the end user?

Kasargod: The key thing for us is that the end user should have multiple ways to access their own data. When you look at it from an end user’s perspective, today, they have to download multiple applications in order to see data across different devices, apps, and services.

What we wanted to provide is an easy mechanism so that any developer who is creating unique case studies has the ability to provide those visualizations back to the end user. I, the end user, can then completely take control of all of the different biometric information coming from my devices as well as have an easy way to share that with my physician, my caregiver, or the enterprise that is monitoring me. It is really intended to transition that data from disparate sources and bring that down very easily to the end users and ultimately enable that user to track their health in more than one way using the unique applications that these developers are creating.

MD+DI: I saw that ten companies, including FitBit and Withings, have opened up their data streams to encourage app development. How will biometric data from companies like these foster innovation?

Kasargod: They are very good partners. For us, it was really important that, if you already use a FitBit or a Withings, you can continue to use information from them. But if you also want to blend the FitBit or Withings information with data coming from other devices, then you have the option to have one aggregated stream that enables you to visualize that in a single dashboard. Depending on the specific use case for the user, you could essentially have just the app or service.

You could also have an aggregated view with a specific outcome that is being provided for you. For example, if you have a disease or sleep management application or if your caregiver wants to see whether you are taking your meds, or if you are moving around, we want to make sure that you have the option to have multiple data sources to give a much more holistic view of your health. 

If you are using just a FitBit or a Withings, those applications and services are excellent because they go deep into [the data generated from] those specific devices. But if you are looking for a consolidated view, we have provided a platform that enables an aggregated set of data coming through.

MD+DI: Can you provide an idea of what that aggregated platform might look like?

Kasargod: [Assuming] an end-user’s perspective, I would be able to go into my settings area inside my application and then link all of my accounts with whatever credentials that particular device requires. For example, if Withings requires my e-mail, address, password, and a three-letter nickname, if I enter that, then the application starts pulling the data in.

Similarly, from a provider’s perspective, if the user provided the right opt-ins, the provider can start pulling all of that data into an EMR or into an HIE. Depending on the specific visualization, that particular user would be able to see the data.

From a developer’s perspective, we have provided a website with Open RESTful APIs. Essentially, a developer goes in and we give them access to our service and we give them specific ways in which they can request data from each of the different sources. If I am a developer who has already developed an app or who is developing a brand new app, I can create a brand-new dashboard inside of my application that is visualizing the data coming from the data stream from the APIs.

A developer could be an application developer, it could be a website developer as well. We are platform agnostic because these are Open RESTful APIs. The plan is to have anyone who has the ability to create a visualization or a user experience to pull in data across a disparate set of sources and then blend that into their experience so they create the outcome specific to their solution.

MD+DI*: Can you comment in terms of how you are interacting with Continua Health Alliance and the relevance of that to the data aggregation?

Kasargod: To step back, there are four ways to collect data from various different devices, applications, and services. We call them gateways. We then aggregate that and provide that to our enterprise customers who provide visualizations to their customers. The first one is our 2net Hub, which plugs in the wall. It has multiple radios in it: Bluetooth, Bluetooth Low Energy, ANT+ local area radio protocols, and WiFi. Continua is one of the standards that we are supporting on the Hub. So that is the interoperability standard between the Hub and Bluetooth-enabled devices or sensors that are connecting to it. 

We have three other ways to collect data. We use the smartphone itself as a biometric sensor using the accelerometer/gyroscope/GPS and any applications that leverage those components. We have the ability to connect with them and pull data from those applications as well.

The third is really more of a server play. Server-to-server, we have RunKeeper, MapMyFitness, as well as Withings and BodyMedia, which are back-end services. We connect with those as well.

The fourth one is our embedded gateway. When we incorporate our wireless chip to new biometric sensors, we enable them to have the ability to connect back to our platform as well.

MD+DI*: So the API specifically is going to be for people to be able to mine the cloud-based service and tap into that data stream?

Kasargod: I would think about it as the cloud-based exposure of our platform for all of our gateways. It is a device that is connected to the Hub that is transmitting the data to the Hub and then onwards, or if it is RunKeeper that is connecting to our cloud, it is an aggregated stream regardless of the gateway from which the data came. It is a cloud-based set of APIs that we are exposing to developers.

MD+DI: Regarding the 2net App Developer Challenge, how will Qualcomm determine which three winners?

Kasargod: For us, it is about doing what is right for the end user. We are going to look at it closely in terms of what is going to be the most useful application from an end user’s perspective. That is going to be one of the benchmarks, of course. Other factors include usability and whether it is a practical application from an overall mass-market appeal standpoint.

The underlying premise is: is it trying to solve a problem of the two pillars that Qualcomm Life is founded upon, which are: reducing healthcare costs and improving connectivity. If the application is really able to address those two issues in a meaningful and usable way, that application will be one of the ones we will pick as a winner. 

MD+DI*: Are you really focusing on the home environment or how do you see you penetration into a hospital environment?

Kasargod: The 2net offering is a B2B environment for our enterprise customers. The specific use cases that they are looking at run the gamut. One could be chronic disease management where you have just transitioned from the hospital and you have gone home and now the hospital continues to want to monitor your health or they have provided an extension of their service home so you can continue to have your vitals measured. You also could measure the home monitoring service that enables a caregiver to see your data. It also could be simply a remote monitoring service where there is a physician available. Depending on the specific use case, the dashboard and the related connectivity is done by that particular enterprise who is creating that solution.

MD+DI*: Can you say a little more about how the data will be de-identified?

Kasargod: Simply put, we don’t know the human being behind the readings. We don’t know who exactly is the one who is providing us the readings. We just use identifiers to correlate a particular human’s readings across multiple devices. We cannot reverse engineer back to that specific individual who has provided the readings.

The way it works is on the enterprise side, whoever is actually providing that consumer experience, they have a look-up table to know which identifier corresponds with which human. That look-up table is abstracted from us. We will only be communicating with them in the context of unique identifiers. 

MD+DI: Do you have an idea of how many enterprise customers are using the 2net platform?

Kasargod: We are at various stages of development. Some of the ecosystem partners will be actually announcing on our website very soon. So far, we had announced more than 40 partners active in mHealth and that number has now gone up considerably. 

MD+DI: What can you tell me about the plan for 2net—other than what you have already touched on?

Kasargod: Our plan is, from an industry perspective, to have that open ecosystem so that any developer, and device manufacturer is able to plug into our platform. When you look at the trend in devices, you are starting to see lots of different kinds of devices. On the one side, you are seeing specialty devices and specific sensors that use the phone as a dashboard. On the flipside, you are seeing the phone itself being very powerful and having multiple applications using the sensors on the phone itself. In the middle ground, you are seeing some accessory sensors—things that connect to the phone and then convert the phone into a biometric sensor as well.

For us, it is really important to continuously evolve. We keep the ecosystem open so that regardless of which of these segments ultimately becomes the most dominant one, they have a place in the ecosystem. And from an enterprise perspective as well as from an end-user perspective, they don’t have to worry about which ecosystem that particular device belongs to.

Now it is more of a service play but I definitely anticipate multiple platforms leveraging our Hub capability. 

MD+DI: What prompted Qualcomm to step in and provide this 2net service?

Kasargod: If there is one thing we do right at Qualcomm it’s wireless. For us, it was really important that the main problem we solve is the fragmentation of the radio technologies and how multiple devices were coming out with their own standards. I think Continua does a good job at trying to standardize part of that. But we just wanted to make sure that our years of experience in wireless could be applied in the context of healthcare and provide one consolidated stream.

Because we are an open ecosystem, other aggregators are absolutely welcome to plug into our system as well. The key thing for us is that the end user has one place to have all of this information. With the evolution of wireless technology in general, it is not just a cell phone any more that has wireless. Everything is going to have some kind of wireless capability. We feel that it becomes all the more important that we solve the connectivity issues.

*The questions marked with an asterisk where posed by Bill Betten, medical technology director at UBM TechInsights. 

Brian Buntz is the editor-at-large at UBM Canon's medical group. Follow him on Twitter at @brian_buntz.