Untethered Healthcare

Where Is The Open Software Platform For Healthcare?

Craig Brandis — Wed, 03 Mar 2010 21:07:15 +0000

The idea of what makes a good software application platform has changed radically in the last ten years. In the days when shrink-wrapped software ruled, application developers had to choose between Wintel world, the Mac world or the high-end workstation world. Software developers had to make their peace with becoming specialists in one particular native OS and the ever-changing libraries that supported it. Releases were high-overhead for customers and customers often delayed upgrades as long as they could to help manage costs. Pricing was impacted if your enterprise software depended on a commercial database or middleware solution. As a developer, sales calls from those vendors sometimes felt like being shaken down by the local mafia when they annually decided to “change their licensing structure” for software you supposedly already owned.

With the rise of the software 2.0, SaaS and virtualization, the game has changed. With Saas and platforms like Salesforce.com, the application stack is increasingly de-coupled from the operating system and hardware. You pay for application use “by the yard” and do not have to worry about maintaining your own servers or scaling from dozens to thousands of users. Life is good, right? Well, perhaps. Independence from hardware and OS vendors can definitely lower infrastructure costs. But what happens when those SaaS vendors start to find lots of incremental ways to charge you? The rules of customer lock-in still apply. How easy will it be to migrate away from your SaaS vendor when you find something better? I’m seeing more people question the long-term savings from Saas vendors, especially when you add up all the incidental costs. For now it is still a lot better than maintaining your own servers for a number of applications, but what is the long-term outlook?

What really changes the game is the ability to easily migrate your data into an open platform, quickly build new capabilities that run inside that networked platform, and export your data easily when you find something better. (Exporting your apps would be huge too, but if you can build them fast enough, that need is lessened.) Add to that a robust open source community around the platform and things start to look pretty good. Enter social media. The social media world has solved some of these issues. I’m amazed by the increasing sophistication of applications built on top of WordPress, Twitter and Facebook. Though the latter two are not really open source, each has a very sophisticated api that enables non-trivial apps to be developed quickly by small teams.

The significance of social media and open platforms as application development platforms is still somewhat below the radar screen of enterprise healthcare, even though some prominent CMIOs are saying that social media is the killer app for healthcare. Healthcare organizations legitimately worry about the security of data in social media platforms and the ability to partition them securely. These are valid concerns. But don’t expect big ticket HIT software vendors to solve these problems. They have too much to lose.

Are HIT and medical device companies keeping up with these trends? Not really. Medical device and HIT companies claim they are building open platforms, but often what they are really building is another analog of the vertically integrated Wintel world, hoping it will become another de-facto standard. The essence of a good software platform — from a customer’s perspective – is how open it is in three dimensions: open source, open migration of data and network in and out, and ease of application development where the app runs inside the platform. So where is the open software platform for healthcare going to come from? Google? Microsoft? Really?

Your thoughts?

Digital Curation, Open Innovation And Healthcare

Craig Brandis — Mon, 15 Feb 2010 19:22:38 +0000

More and more healthcare innovation thought leaders seem to be challenging the closed nature of most scientific research and the fact that most scientific data is not shared. Even the journal Nature devoted an issue recently to the need for openness in research and why scientists don’t share data well. Cambridge economist Rufus Pollock sums it up well : “The best thing to do with your data will be thought of by someone else.” Start-ups like NextBio are trying to address the problem by creating platforms for scientific data sharing and analysis. They are also providing value-add by hiring research scientists to curate data sets, both public and private. The dictionary says a curator “manages or supervises a collection, as in a museum or library”. In a world overloaded with information, digital curation also implies some amount of sifting and direction of attention. Curation is playing a larger role in journalism. Some tech journalists are staying away from splashy events like the iPad rollout, in favor of curating the swarm of tweets from people onsite and calling execs in real-time for reactions — essentially creating their own personal war room to get a better overall view.

The rise of digital curation bodes well for healthcare, as does the rising interest in applying open innovation to healthcare problems. Developing and bringing a new diagnostic parameter to market requires massive investments in data collection. If even a portion of this data were available publicly, development costs and time to market would go down. The best example I’ve seen of the time-to-market benefits of this approach is the work being done at the Myelin Repair Foundation. Ways to address the sharing problem seem to be related to creating a culture of sharing and mechanisms for managing how data is shared, particularly by competitors, prior to going to market.

Any other thoughts on how to do this?

Why Mobile Enterprise Apps Fail

Craig Brandis — Wed, 10 Feb 2010 20:19:23 +0000

In 2-3 years, 70% of all internet access will be from mobile devices. Most commercial enterprise application providers already have or are in the process of building mobile clients for portions of their main desktop and SaaS products. The quality and uptake of these clients will vary widely, as did the first generation of enterprise desktop applications. It is no mean feat to take an enterprise application, developed over decades perhaps, with fifty to one hundred screens and endless menu selections, and map it onto a smartphone-style screen with a chiclet keyboard for input. The key is to extract the mobile use cases — usually but not always the most common ones, simplify them with reasonable defaults, and build a client UI that is familiar in style to it’s larger cousin but doesn’t need a week’s training (or any training.) Paying for good design, rapid prototyping, user-feedback and iteration here are the keys to success. These types of apps will largely succeed or fail, based on how well mobile use cases are understood, the correct choice of mobile platform, the quality of the UI design and frequent iteration with the users.

Building a brand new enterprise application from the ground up with the intent of making it mobile is another matter. The biggest point of failure here is concentrating on the mobile application features at the expense of considering the whole end-to-end user experience. Every mobile enterprise app is a system. If you think of all the gritty details that make systems a delight or a pain to use, they are all about things working the way they should without much user intervention. Downloading, updating, configuring, authenticating, maintaining session state, syncing, failure recovery are the unglamorous but vital places where it only takes a few weaknesses to make users walk away. There is no substitute for relentlessly drilling down on all the corner cases that can frustrate users and finding solutions or simplifying. Good tools and simulation methods are available to “war game” the entire system in detail with the designers and end-users before a line of code is written. If you are automating workflows that have not been automated before, the more realistic simulation you can do with end-users during the requirements stage, the better. The ease-of-use bar for mobile enterprise apps is being set high by consumer apps and the app store experience. Mobile enterprise apps with all of their underlying complexity will sit side-by-side on a smartphone with simple, easy-to-use consumer apps. If the enterprise apps aren’t just as easy to use — as a complete system — they won’t get traction.

Your thoughts on what makes a good mobile enterprise app?

What Can Design Thinking Do For Healthcare?

Craig Brandis — Fri, 22 Jan 2010 20:02:00 +0000

Design thinking is a term coined by Tim Brown of Ideo. It means integrating user-centered discovery and consideration in all phases of developing a product or service. Understanding what people like, want, use, hate and love about a product through direct observation and feeding that back through an iterative process that keeps the end-users day-to-day needs front and center is a powerful tool. Focusing like a laser on the whole end-to-end user experience can even change the game — just look at Apple. Edison understood this too when he invented the electrical distribution industry after inventing the light bulb. But it is a relatively new phenomenon in healthcare.

I once spent six months on a worldwide Voice of the Customer research effort for a medical device company. One of the customer phrases that stuck in my head was “what does this button do?” It seemed a once-sentence, summary indictment of all of the overly complex user-interfaces adorning medical devices around the world. Another customer I interviewed, the head of pediatric intensive care at a large German hospital, told me the user interfaces to most of his devices were so complex, the annual training costs to keep people’s skills current made it unlikely he would seriously consider another vendor — even us. Talk about customer lock and high switching costs! He was so frustrated, he started consulting to medical device companies on user interface design.

Personally, I think the discipline of design thinking has a lot to offer healthcare. I’m even seeing the term “design” included in the name of what used to be thought of as pure engineering institutions, such as the Center for Bioengineering Innovation and Design at John’s Hopkins. I had a great conversation recently with Aaron Blackledge, the founder of the fastest growing and highest rated walk-in medical practice in San Francisco. He got professional help applying design thinking to all aspects of his user experience, from the office layout to how users access services via the web. He asks constantly for feedback from his patients on how he can make things better for them. Not rocket science, but it is clearly setting him apart from the competition.

In the medical device space, lack of good user-centered design can impact patient safety. What do suppose a medical product line and the related training, service and support would look like if it were designed from the ground up with goal of focusing like a laser on the entire user-experience?

Your thoughts?

Bringing Lean Methods To The Front End Of Medical Product Development

Craig Brandis — Sun, 10 Jan 2010 01:28:33 +0000

Most companies are familier with Lean principles. Lean is about eliminating waste from any business process, usually manufacturing. Institutionalizing the culture of holding regular kaizen events on the manufacturing floor to eliminate wasted time, effort and resources can achieve remarkable results in a very short time. However, the benefits may be harder to achieve or accept culturally when the process being optimized is less tangible and visible. Though the principles of using Lean across all phases of product development were well documented by Toyota, I’ve seen fewer companies, at least in the medical hardware and software/IT spaces, adapting Lean to the front end of product development. It may be that someone’s idea of waste in these functional areas may be someone else’s primary responsibility. That doesn’t mean that Lean can’t be used to optimize these functions, but be prepared for some surprises as to how much waste you find. I don’t mean don’t do it, though. My experience is that if engineers are aware up front that their jobs are safe, they will readily see the benefits of eliminating waste and being more productive, even if their roles or daily tasks change in the process. I suggest starting small with training in Value Stream Mapping and working up.

I’m curious to hear others experiences in bringing Lean methods into the front end of medical hardware or software product development. Your thoughts?

Making Mobile Apps Sticky

Craig Brandis — Tue, 22 Dec 2009 18:10:57 +0000

On most cell phones, data usage represents thirty percent of average daily use. On an iPhone, data represents seventy percent of average daily use. Apparently, as a smartphone platform is able to support richer applications and app distribution becomes nearly frictionless, people’s usage patterns change. Or do they? This interesting slide deck from Pinch Media shows that most iPhone apps are essentially disposables – less than five percent of the users of a typical app are still using it thirty days after download. The sticky mobile apps are the basics: Web surfing, email, music and SMS together make up fifty two percent of daily use. What about those hundreds of thousands of apps in the app store and the millions of downloads? They represent only three percent of daily use for most users.

Clearly we are still in the “irrational exuberance” stage of mobile app development with people throwing everything against the wall to see what will stick. The vendors and carriers are encouraging all this experimentation because it helps drive use, but the economics for small developers building apps on speculation are still marginal. As for the buzz about smartphones replacing PCs and laptops, does anyone really do serious document creation on a 3.5 inch screen?

So what does it take to make a mobile app sticky? Mobility changes how people interact, collaborate, locate each other and transact business. For the next generation of sticky mobile apps, look to Asia where smartphone use patterns are three to four years ahead of the US. The main focus there appears to be using smartphones phones as a payment vehicle and using highly optimized local search to facilitate transactions. This is in line with what I hear from custom mobile application developers who say the bulk of their business is e-commerce related. So one element of stickiness is “follow the money.”

On the mobile healthcare front, even though many of us expect smartphones to play a major role in wellness, I believe the early, rapid growth in mHealth applications may occur in developing countries with SMS-based systems like this one from the non-profit FrontlineSMS. This central communications management system for rural healthcare runs on a laptop, uses $10 recycled cell phones, and is already helping save lives. It is sticky because it improves workflow in a fundamental way. It saves countless miles of walking and motorbiking by rural healthcare workers to follow up with patients and update their status. It allows a hospital with a catchment area of 250,000 people to track and manage their care more efficiently.

Your thoughts on making mobile apps sticky?

EHR Conversion And Smartphone Supported Wellness At Kaiser

Craig Brandis — Thu, 17 Dec 2009 01:32:23 +0000

Given all the discussion about the difficulty and expense of converting a practice or hospital to electronic health records, it is refreshing to hear from someone at the front lines of digital health who says, in effect, “just do it.” Dr. John Mattison, CMIO for Kaiser Permanente, speaks from experience, having gone through the conversion process five or six times in different settings. Dr Mattison spoke at the Telecom Council of Silicon Valley’s Mobile Health Forum last week. Under his leadership, Kaiser Permanente was able to convert all their fifteen thousand physicians to EHRs within three years. “EHR conversion is about leadership and change management. I hear about a lot of first timers scanning paper into electronic records. The problem with that is that scanned images are not searchable. You just need to abstract the older records where necessary and only scan very selectively,” said Mattison. Kaiser Permanente’s kp.org EHR which is based on Epic now has three million users.

Dr. Mattison also talked about the key role smartphones will play in healthcare. “Smartphones are the wellness delivery channel of the future. This is going to explode; it is big and it is soon,” he said, indicating also that the mobility of the consumer will drive the development of new solutions. He highlighted some gaps in current smartphone technology that will need to be filled in order to facilitate healthcare workflows: status aware protocols for SMS when someone is away from the phone and mobile standards for role-based access, for starters. Dr. Mattison also discussed the role of social media in mobile, participative healthcare and the need for a “sustainable, lifelong model of privacy” where health information is easily quarantined from other social media interactions.

If the smartphone is going to be the wellness delivery channel of the future, I would add that today’s phones as application development platforms still have a ways to go to fully enable this. In developing mobile clinical applications you quickly run into the problems like fast, secure roaming across disparate networks. Maintaining application state and secure user context when roaming from the hospital WiFi network onto a commercial cellular network – when the physician leaves the hospital to go to lunch while reviewing patient data — can be problematic on a number of the main smartphone platforms. Currently Windows Mobile is the only platform with a full-on mobile VPN, though that is likely to change. Support for workflow applications, where a user is really interacting with multiple applications in a seamless way, is still limited for third party developers. As the dominant player in enterprise applications, RIM seems to understand this better than most.

Your thoughts on other barriers or enablers to widespread use of smartphones as a healthcare platform?

Making Your Clinical And Workflow Data Mobile

Craig Brandis — Sat, 05 Dec 2009 00:14:15 +0000

If 70% of clinicians are already carrying smartphones, then the obvious target for taking your clinical data with you is the smartphone. Everybody including the big telcos seems to be entering this space. There are already hundreds of healthcare apps for the iphone, including one with FDA approval. But suppose you are a network of hospitals and your clinicians don’t all carry iphones. Suppose you want to see your own data, your own way, on all your current phones. Developing custom apps for multiple types of smartphones is a headache. Smartphones are all different, with different screen sizes and ratios and different CPUs, and operating systems. Native applications must still be custom designed for each platform. There are some promising technologies emerging to help overcome this hurdle, but then you have the risk of building your apps on top of a proprietary technology layer from a small company. Lots of big and little projects have gone south this way when the small company gets sold, changes direction or stops support. For now, the only real “platform independent” solution is still using HTML to build web applications. I put the “platform independent” in quotes because the mobile browsers are all different and so you will still have to test, tweak and perhaps optimize your app for each. Also, HTML is still insufficient for some types of streaming data.

The bigger issues with using mobile platforms for clinical and workflow data are usability, network security and FDA scrutiny. Good mobile apps tend to do a few things really well. Many mobile apps in the Windows world are really scaled down PC apps with the attendant problems of putting one hundred pounds of beans into a fifty pound sack. Also mobility creates new potential workflows like viewing real-time patient vitals remotely, even allowing off-site clinicians to check on patients from home and direct care, while remaining transparently behind the hospital firewall. (My group at a previous employer developed a mobile clinician notifer application for doing this.) The skills of capturing the most essential, actionable workflow data and marrying them to a well-designed user experience so that people can use your application with minimal or no training may be challenging for many IT departments. Thought leader institutions like Mayo and Kaiser are spinning up groups to understand the issues and create the new mobile apps to support their workflows, but most hospitals can’t afford that level of effort. I won’t address the issues of network impacts and FDA scrutiny here, but they are significant. Tim Gee over at www.medicalconnectivity.com has good discussion of the enterprise network as a potential medical device here and there is a good summary of when FDA oversight is required for mobile clinical apps here.

I spoke with the CEO of a network of community hospitals and a new medical school in Oregon recently who said “our younger clinicians and incoming students already live and think this way.” The lifestyle driver is definitely there and lots of startups are entering the space. Uptake will depend on how well the mobile clinical solutions started with a need rather than a good idea, and thoroughly deal with the network security and regulatory impacts.

Your thoughts?

Will P4 Medicine Be The Killer Healthcare App?

Craig Brandis — Thu, 19 Nov 2009 01:44:42 +0000

Portland, OR – Dr. Leroy Hood of the Institute for Systems Biology (ISG) gave the keynote speech today at Supercomputing 09 conference on the emergence of P4 (predictive, personalized, preventive and participatory) medicine. Dr. Hood has serious street cred when it comes to making predictions about the future of healthcare, having co-founded some twenty startups including Amgen. He believes that medicine will become primarily an information science in ten years with the convergence of personal genomics, systems biology and grid computing. These tools will help create billions of physiological data points for each individual, enabling the creation of predictive and actionable models to explain emergent behavior.

How does this vision translate to primary care? According to Dr. Hood, you will first sequence your personal and family genomes and then show up at your doctor’s office every six months for a wellness assessment. Your physician will use a handheld blood assay device to profile 2500 blood proteins from a pinprick sample. The new assays will identify disease-related changes to organ-specific, blood protein fingerprints long before you become symptomatic. New therapies will stem from personal banking of stem cells and new drugs to “reengineer disease-perturbed networks.” “All the current business models will change,” says Dr. Hood. The time horizon for this vision becoming a reality? “Five to eight years.”

Given that the average timeline for a radical new technology to become ubiquitous in healthcare practice is seventeen years, I don’t know if I believe Dr. Hood’s timeline prediction. On the other hand, if he is right and the technology were available inexpensively today or in a few years time, wouldn’t you ask your physician for it? Your thoughts?

Can The Medical Device Industry Be Disrupted?

Craig Brandis — Thu, 12 Nov 2009 01:32:40 +0000

Perhaps it is an unfair question. Any industry can be re-invented or even disrupted. That is the history of industry. Maybe the better question is what sectors of the medical device industry have become static and how are they likely to be impacted, not only by changing how things are done, but also by the larger sea changes happening in healthcare. In some ways, the medical device industry today is similar to the mini-computer industry in the 1980s. In the 80’s, companies like Digital and Wang sold vertically integrated business computer systems, all based on proprietary hardware and software. Customers usually standardized on one vendor because systems from one mini-computer company were incompatible with systems from another. They couldn’t share data without a lot of custom development. Software was not portable between vendors and systems were expensive. Sound familiar?

In the mid-1980s IBM introduced the PC. Not only did it cost an order of magnitude less than a mini-computer, it had an open architecture with a published hardware/software specification. It was easy to modify and extend, write new software for and even replace hardware components. Design a better graphics card for it, write some custom CAD software and you could disrupt an industry like design automation, which was itself built on top of the old mini-computer silos. Digital and Wang and a host of other companies who depended on them never knew what hit them.

Hospitals today standardize on medical device vendors for some of the same reasons that people standardized on mini-computer vendors in the 1980s. Basically, they have few alternatives and plug-and-play between vendors doesn’t really exist yet except for HL7. ( When Welch Allyn recently came up with the Flexiport cuff to connect a single blood pressure cuff to devices from different vendors, this simple plug-and-play idea was a huge success. Nurses often waste time daily hunting through supplies looking for the right cuff to fit a particular device. ) Yet there is nothing preventing someone from developing a truly open PC-like architecture and toolset and radically lowering costs of both development and ownership. Commoditization is already a fact of life in segments like patient monitoring. Every year at Medica there are several new monitoring companies with lower-price products. However, commoditizing only deals with price/performance. It doesn’t really change the game. What happens when someone develops the equivalent of the IBM PC for the medical device industry? In some ways this is already happening bottom-up in patient monitoring with many high-level monitoring parameters available from multiple sources as off-the-shelf modules. One trend is clear, regardless of whether the full open-source, medical PC shows up: the software content of devices and their ability to synthesize multiple data streams into actionable information for a variety of user skill-levels is going to become a lot more important as hardware becomes cheaper, smaller, wireless and more re-targetable. (After all, the era of the disposable patient monitor isn’t far away. )

Better platforms and tools are only one part of the puzzle. Faster time to market is the other. Introducing Google’s concept of “fail faster to learn and succeed quicker” implies re-thinking the development process from the end stage backwards. Integrated design and test, much more sophisticated use of simulation, and re-thinking when and how to move under design controls are all elements of making the traditional development process more lightweight and Agile. Your thoughts?