The Marginal Value of the Smartphone

The post was originally featured on the Pristine blog. 

I've written about the marginal value of Google Glass. As I continue to make sense of Glass and what it can and can't do, I think it'd be worthwhile to try to make sense of the marginal value of smartphones.

To be clear, this post is focused on modern smartphones: iPhones and Androids. I'm looking at multi-touch capacitive glass smartphones capable of running 3rd party apps.

The marginal value of any hardware platform is defined first and foremost by hardware. The key sensors in smartphones relative to traditional PCs are:

1) mobile system on a chip (SoC)

2) accelerometer / gyro

3) gyro

4) cellular / Wi-Fi / bluetooth

5) digital compass

6) GPS

7) camera (front and back)

8) rear camera flash

9) ambient light sensor

10) multi-touch capacitive glass screen

11) mobile speakers

12) mobile microphones

13) fingerprint reader (iPhone 5S only)

Looked at in this light and with hindsight, it's clear that smartphones delivered the following forms of marginal value relative to their desktop counterparts:

1) mobile computing - you can process and store information anytime, anywhere.

2) mobile camera and mic - you can capture the audio and video of the world around you so that it can be processed, stored, and shared.

3) mobile connectivity - you can send and receive information anytime, any place.

4) context - your device knows your location, the time, its own orientation, and your data from an assortment of services. It can contextually take actions for your based on that information.

5) direct control, touch-based computing - the mouse and keyboard intrinsically disintermediate the human from the content. Interactive touch is clearly one of the most intuitive ways to interact with digital content. The simplicity and ability to control virtual objects through direct touch manipulation is incredibly powerful.

The two most important characteristics above are indubitably mobile connectivity and direct control. Direct control provided the front-end and sex-factor to drive consumer adoption, and mobile connectivity paved the way for cloud computing.

In retrospect, it's actually quite remarkable that people simply couldn't foresee what was possible in mobile computing. Technologists' lack of foresight is probably due to the fact that the rise of mobility coincided with the rise of cloud computing, and that the two fueled one another's growth. It was difficult to envision a future in which mobile computers could do so much even though they had so few local resources; the cloud solved that problem, and drove cross-platform and cross-form factor innovation that was never before possible.

Health IT Bubbles

This post was originally featured on HIStalk. 

Travis and I attended the Health 2.0 conference in Santa Clara. The most prominent trend I observed was that health IT startups are converging on a few big ideas.

Wellness platforms. I walked the exhibit hall and talked to the reps at every booth. There were at least eight vendors selling a platform to employers and payers to manage wellness. They all employed the same business model and there was no discernible difference between any of their products.

Patient engagement. I think "patient engagement" will win the award for most overhyped, under-delivered term of 2013. Fundamentally, engagement is about pushing and pulling data in using the right channel at the right time. The patient engagement startups were pushing and pulling across many spectrums. Many helped providers push information to patients, and many were predicated on patients initiating engagement with providers through data. None at Health 2.0 were particularly memorable.

Medication adherence. I can’t believe how many startups are trying to help patients take their pills on time. Similar to patient engagement startups, they’re trying different push and pull tactics: pill bottles, cloud services, and social contracts. I suspect the winners in this arena will successfully combine characteristics across all channels. Or they’ll take a completely different approach, such as Proteus Digital Health.

This makes me wonder: if we’re spending so much effort to get patients to take their pills, how on earth are we going to "engage" them? Taking pills at the right time requires almost no behavior change. Real engagement, on the other hand, is the holy grail of behavior change. I’m not optimistic.

These waves remind me of EHRs circa 2010. EHR companies were cropping up left and right in 2009 and 2010. By most accounts, most of the newer EHR companies aren’t doing particularly well, though there are standouts. Although many expected consolidation via M&A, they’re mostly just being left to die off. I suspect we’ll see a similar withering in the bubbles identified above.

All of this begs the question: what are the upcoming bubbles? I suspect we’ll see heightened activity in each of these spaces over the next 2-3 years:

Wearables for healthcare. This has already started, though most of the existing wearables track only the simplest data, primarily footsteps and vitals. There’s enormous opportunities to simplify and sex-ify more powerful wearables such as the Zephyr BioHarness. I suspect the most successful mass-market health-focused wearables will be those that can create provider awareness so providers can prescribe their solutions to their patients.

Google Glass apps for healthcare. I’m surprised by the lack of Glass healthcare startups given how many people are talking about Glass for healthcare. The only two that I’m aware of are Augmedix and my startup Pristine. I suspect we haven’t seen that many healthcare-focused Glass startups because: (a) hardware isn’t readily available and founders aren’t willing to start a business around a single unit of hardware; (b) Google won’t disclose a final commercial release date, so it’s hard to get investors on board; and (c)  the native Glass Development Kit isn’t out yet, though it’s supposed to be soon.

Feel free to leave a comment with your thoughts on existing and upcoming bubbles.

 

Deliberate Writing

I recently got picked up by TechZulu, a prominent tech blog. I'll be contributing general technology and healthcare-tech editorials for them. I never could've imagined writing for 2 major blogs - HIStalk and TechZulu - within 9 months. Blogging has been one of the best decisions I've made.

I've decided on my new years resolution for 2014: to write a book about running a healthcare technology startup.

I want to continue to improve and refine my writing, so I'm going to invest more time in it. I'm going to deliberately practice writing.

I'm going to begin a more structured writing process in which I outline every post in bullets at least a day before actually writing the post. Then, after writing and revising the post, I'm going to score myself on a scale of 1-7. Why 7? Because it's been shown that people score things on a normal distribution when asked to score things on a scale of 1-7. My goal is a score my posts along a normal distribution. The key metrics on which I'll assess my writing are: quality of thesis, clarity of explanation, and conciseness.

I'll track scores in an Excel sheet, and review them periodically as I get ready to write the book.

Below I've included the outline for this post. 

 

1. recap how i got here. get ready for writing a book about being a startup CEO, which will be my new years resolution for 2014

2. reference book - deliberate practice

3. how am i going to deliberately practice? bulletize every post first. then write. then edit. then self grade. going from 2 day to 4 day process.

4. how am i going to measure my performance? page views, tweets / likes, and qualitative self-score

5. scale of 1-7 because that allows for the best normal distribution. 1 is forgettable, 2 is almost forgettable, 3 is sub par, 4 is par, 5 is above par, 6 is memorable, 7 is a treasure. goal is to have a normal distribution of scores.

6. sub components: quality of fundamental thesis, clarity of explanation, conciseness

7. will revisit and analyze scores in early 2014

9 months into 2013, I've written at least 3 blog posts every week as I said I would for my 2013 new years resolution. I've maintained a perfect record.

 

Getting Data In and Out of Your Electronic Health Record

This post was originally featured on TechZulu. 

Epic is the most dominant electronic health record (EHR) company in the US. Although Epic is a private company, it boasts over 6500 employees, $2.3B in revenue, and 150M patient records.

Like most legacy healthcare IT companies, Epic runs an ancient technology stack. Its core database is a pre-SQL, cache-based database, which went out of style long before I was born. They’re currently in the midst of transitioning the front end from VB6 to .NET. Unfortunately, they decided to leave their core database technology untouched.

Epic doesn’t like working with 3rd party vendors. Epic wants to be THE solution for all hospital IT. Because of its ancient technology stack and business practices, Epic has been notoriously difficult to interface with. Epic doesn’t provide anything that even resembles an open API. They will, if a prominent customer makes enough noise, provide an HL7 ADT feed. Without getting into the technical details, I’ll say that HL7 is the opposite of a standardized, consistent API. To be fair, it’s not Epic’s fault that HL7 is lacking, it’s the government’s.

Epic recently held its annual user group meeting. They surprised the world by announcing open.epic, an open API. I almost had a heart attack out of excitement. Unfortunately, that was unwarranted. The API will allow developers to feed passively gathered wearable device data into an Epic database. The API doesn’t offer a protocol to reciprocate data exchange. Moreover, the launch was clearly a hastily thrown together soft launch. At this stage, Epic is just getting feedback from developers. They are years from a live solution at a client site.

This of course begs the question, why open an API at all? For the past 30 years, Epic has slowly built software modules for virtually every hospital function. Epic has never acquired another company, and tries to insource everything. I suspect that Epic concluded that it will never want to be in the business of manufacturing, marketing, and selling devices to consumers, so it actually found it in its own interest to open up a one-way API for passively collected patient health data.

The big winners here are Epic and analytics companies that can get their hands on Epic databases. Perhaps they’ll be able to drive new insights with wearable device data. Although there aren’t any explicit losers per se, relative to what the API should’ve and could’ve been, the big losers are the device makers that are going to feed the API. Just imagine how much more powerful this could’ve been if your Jawbone or FitBit could query an Epic database and return some intelligent insight to the patient. That’s a profound and unrealized concept.

Per the laws of capitalism, necessity is the mother of all invention. Developers want 2-way data exchange with EHRs, so they’re taking it upon themselves to make it a reality. Startups such as Human API and Validic are creating platforms that make it easy for developers to easily exchange data between previously silo-ed systems in real-time. Catalyze is simplifying the process of getting data out of complicated healthcare data files and stores.

 

Validic.png

Surprisingly, the major health information exchange (HIE) vendors, Mirth and Orion, aren’t going after these markets more seriously. They’ve been focused on connecting healthcare providers with one another,  and analytics on top of that data. They’ve been less interested in pulling in additional data from patients themselves.

The federal government has been pushing the Blue Button initiative for some time, though it’s a one-way read-only API that’s limited to claims data: demographics, problems, allergies, meds, and lab results.

The silos that have characterized health IT are being slowly breaking down, in many cases without the blessing of the monolithic EHR vendors. This is perhaps the least hyped sectors of health IT, but one of the most profound. The companies that support robust data exchange will be in a position of significant market power with strong networks effects.

Off to the races.