Catalyzing the app store for EHRs

Dr. Lumpkin serves as director of the Robert Wood Johnson Foundation’s Health Group, where he is responsible for planning and program management. Prior to joining RWJ, Dr. Lumpkin led the Illinois Department of Public Health for 12 years. As  assistant vice president, Downs plays a leading role on the Foundation’s Pioneer Portfolio team. During his tenure at the Foundation he has created, developed,  or overseen the  Foundation’s investments  in such key initiatives as Project HealthDesign, InformationLinks, the Health e-Technologies Initiative, the Public Health Informatics Institute, Connecting for Health, and Common GroundHis writings may be found at Pioneering Ideas, where this post first appeared.

Iphone_health Recently, Steve posted about the idea, floated by Ken Mandl and Zak Kohane, that EHRs (or health IT more broadly) could move to a model of competitive, substitutable applications running off a platform that would provide secure medical record storage.  In other words, the iPhone app model, but, for example, you could have an e-prescribing app that runs over an EHR instead of the Yelp restaurant review app on your iPhone.  We’re thinking about the provider side of the market here, as Google Health and Microsoft HealthVault are already doing this on the consumer side.

It’s nice to ponder these “what ifs,” but we’re a bit more action-oriented here and we’ve turned our attention to asking what it would take to make this happen.  It seems that there are two things that are needed. First, we need the platform.  Some of the most notable platforms started out as proprietary that were then opened up.  The IBM PC comes to mind as an example. Some were designed from the beginning to be open platforms with limited functionality until the market started developing applications.  A recent example is the development of iGoogle and the tons of applications that are available for free.  Finally, there was the purely public domain development from the beginning to end that we’ve seen in the Linux world.  Or perhaps we don’t need a common platform and maybe what is needed is to stimulate the market for health IT products that have open application programming interfaces (APIs) that allow for third-party application development?  Several ideas come to mind.

A venture fund for platform providers.

Perhaps the key is to put more money behind companies that offer EHRs that allow 3rd party app development.  Will seeding a fund convince other investors to get in?  Are there startup ventures out there that could take advantage of the fund?
A venture fund for app developers.  Apple and Kleiner Perkins did this – they set up a $100 million fund to invest in companies that would develop applications for the iPhone.  Makes some sense, but there are some differences.  Apple already had the platform and a developer community was emerging.

A prizeBob Hughes has posted before on Pioneering Ideas about prize philanthropy, which is an intriguing approach to stimulating desired breakthroughs.Could a prize that awards a pot of money for development and ultimately use of a platform/app approach to health IT catalyze a competition among vendors?  Prizes tend to work well when companies believe that winning the prize will give them a leg up (through the innovations they developed to win the prize or the reputational capital earned by the publicity) on a new market.  The cash doesn’t hurt either, but it’s often not enough.  Would that be the case here?  What accomplishment should a prize reward in this case?  Apple made some headlines by announcing that a billion iPhone apps had been downloaded.  Could the prize target be a certain number of app downloads?  The intriguing idea is that a group of vendors could collaborate to share the prize by developing a common API (see OpenSocial as a model).  Would the publicity alone (assuming there was lots) stir up demand for this approach?

Other ideas.  We’d love to hear them. As you can see, we don’t have the answers here and need a lot of input.So if you have some thoughts on this, post a comment or contact us.  And if you know others that might care, please pass this on.

Categories: Uncategorized

Tagged as: , , ,

13 replies »

  1. A hoover is the very best of cleansing tools; it may also
    be the more costly. You will find several different
    sorts of vacuum with various characteristics.
    Therefore before you buy a top-rated vacuum-cleaner be
    sure you know what class of vacuum cleaner is
    perfect for your demands.

    Picking the best vacuum cleaner could be perplexing.
    To simply help make things better you should be aware of what the various
    sorts of hoover are, what the primary qualities you’ll be able to find on a
    vacuum cleaner, and want you sort of flooring you’re going to
    be using a vacuum-cleaner on.

  2. Thanks all for the helpful comments. Among other things, they give me a sense of how a metaphor can be a double-edged sword – it can give people an image that can help to translate a concept but at the same time, the details of that image can distract from the basic point. While the image of iPhone and its apps evokes the innovation that can be unleashed when developers have a popular distribution channel and a well-defined programming interface, the same image can seem a bit too simple, too glossy and too glib for the EHR discussion.
    The part of the metaphor that intrigues us is of course the opportunity for innovation, flexibility and competition at the application level. Some of the comments suggested that interoperability is at the heart of the platform concept – or rather (my interpretation) that interoperability specs and an API are closely related concepts. It makes me wonder, rather than thinking of a “common platform,” there’s an opportunity in the industry for vendors to publish APIs, based on interoperability standards, that enable third-party development and then take it a step further and try to harmonize those APIs so developers don’t have to write too many different versions of their apps. The OpenSocial effort – a set of common APIs for multiple social networking services such as MySpace and LinkedIn – comes to mind.
    We got many comments on the overall idea of separating the data stored in EHRs from the applications that use that data to help people provide care – and it’s clear that this idea needs more explication and exploration. We got fewer comments on the different ideas we floated for how to catalyze the market to adopt this vision. I’d love to hear more thoughts on those. Tom Leith suggested that endowing the free distribution of the key standards and implementation guides could have a significant effect. What do people think of that? Sherry Reynolds pointed out that the “market” is often more of a prize than the cash itself and asked what our real purpose was. Good question. John and I were interested in ways to catalyze a market in which, in Mandl and Kohane’s vision, EHR customers could choose from competing applications to perform certain tasks while not having to swap out entire EHR installations. I think a key question about the prize approach is whether a critical mass of EHR vendors could see competitive advantage in opening their products to third party development so they could give their customers access to a greater range of new applications. A follow-on question is whether a well-publicized prize would create an incentive for vendors to move in this direction (or embolden those who were inclined to do so in the first place). I’d love to get comments on these two questions.

  3. Dr. Mandl & Dr. Kohane,
    I think you are correct regarding the lack of ability to integrate new products with existing EHRs. This was probably done by design partially in order to reduce the risk for the EHR vendor and partially because of the obvious limitations of client/server architectures.
    It seems to me that the proper recourse would be to demand (enforce?) open standards of interoperability and integration. I am not at all convinced that fragmentation of the EHR functionality package is beneficial to physicians, both from a usability point of view and mainly from a cost perspective. I also believe that in this age of communications, vendors that insist on isolation, will suffer dire consequences.
    I know that the iPhone looks sexy and all the Web 2.0 graphics and promises look even better (I do have an iPhone 🙂 and I play on twitter). However, EHRs are clinical tools. They can, and unfortunately sometimes do, harm people. None of this new gadgetry is at the point where it can support a complex, mission critical, transactional application, nor was it meant to. Maturity of technology is one of the most important aspects in mission critical applications and there is plenty mature technology today to provide a truly interoperable environment in health care. We just need to use it. Now. There is no need and no reason to wait for the iPhone or whatever it symbolizes.

  4. Interesting comments. We should be so lucky that current healthcare applications should be so substitutable and therefore removable as applications are on most operating systems. Instead, if you buy an EHR, you are buying into a very monolithic solution and cannot easily integrate with new products in the marketplace. We hope that a platform will address this and help create a market for innovative offerings. Without really wanting to defend the iPhone as a product, we do recognize that even its early incarnation, applications share access to contact lists and phone services with more interoperation to come.

  5. I have to admit that the analogy to the “open iPhone platform” escapes me at every level.
    First of all the iPhone is hardware; the “platform” is really the OS, which is not at all open – it can only be used on Apple iPhones.
    The fact that people can write apps for the iPhone may be innovative in the mobile phone world, but it is how things have been working all along in the computer world. Anybody can write an app for Windows, package it and sell it, or make it available for free download. So what is different about the “open iPhone platform”? Maybe it’s the App Store, which is the only, Apple approved, way of getting an app to a consumer iPhone. So this would be a bit more restrictive then Windows or Linux, wouldn’t it?
    As to the actual applications, none of the iPhones apps are interacting with each other – they don’t talk to each other, data is not shared. You can’t even run more than one app at a time. The same is true for the iGoogle apps that you can put on your page. Most of these applications are simple, simple things. I am not discounting the usability and innovation of the iThis and iThat, but I really don’t see how these examples are pertinent to EHR functionality.
    I agree with MarkS. What we need is standards of communication. However, as Francois pointed out, having separate modules interact in real time to form an EHR requires more than just transferring data back and forth. Context management is a complex undertaking even if a unified platform is used, such as Websphere Portal, or any free implementation of the same(The word “platform” here refers to an application platform as opposed to an OS).
    It is worth noting that while building extensions for a certain platform/application is possible, i.e. salesforce.com, there still is one main, comprehensive vendor that controls the platform and the data. In the EHR world, this would translate to building small peripheral modules, such as custom reporting or connectivity aids. I am having trouble envisioning a completely open EHR implementation where various vendors offer various versions of the main modules. There is really no business case to develop software that way.

  6. While it’s true that this is a good idea – to use records with immediacy when needed, we must also weigh the cost of privacy and especially the loss of data through theft and mishandling. I don’t think I want any of my family members’ information floating out there to be misused due to a hacker or a sorkers incompetence.

  7. There are already some open source platforms that try to address HealthCare components integration issues.
    (e.g. openeHealth.org)
    As MarkS pointed-out, one of the most critical part is context management: how aggregate components/services efficiently and share user/patient contextes while keeping high level of security and privacy? CCOW tried to solve this at the application level, but is too cumbersome for components (e.g. widgets/portlets). We need a something lighter.

  8. Great conversation starter. I assume that everyone is aware that we already have an open source software that links to National Health Information Network? http://www.connectopensource.org/display/Gateway/CONNECT+Community+Portal
    “Connect is an open source software gateway that connects the organizations health IT systems to the Nationwide Health Information Network (NHIN). Built through the collaboration of more then 20 federal agencies, the CONNECT Gateway can reap the benefits of health information exchange with other health institutions around the country.”
    The VA already also has more patients and providers on their open source system (VA Vista) then live in most European countries and the largest private vendor Epic has over 150,000 providers and 22% of all patients on theirs. Epic now has a module (free) that will link all of their customers to one another and almost over night you will have a critical mass of patients and providers to create applications for.
    There is currently a 10 million dollar xPrize for Health http://www.xprize.org/future-x-prizes/healthcare-x-prize that is currently open as well and is asking for feedback. In general it is the “market” that is the prize although seed capitial can be critical the first question I would ask is what specific outcome are you trying to achieve?
    The critical thing to always remember is that the goal is high quality, effective, patient centered care. There are very low cost highly effective solutions for example http://www.jopsa.org/ using SMS (text messaging) and mhealth (cell phones) that are being deployed in Africa. One uses a donated laptop, cell phones that are paid for by recycling old phones in the US (Hope Phones) and links to a local hospital that provide health care outreach to over 1.5 million people for less then $500.
    Personally I would like to see some of the $46 billion that will flow through CMS directly to providers and hospitals to purchase EMR’s to be redirected into a social venture capital investment model. Stimulus isn’t sustainable and we have a unique opportunity to dramatically accelerate the use of new tools and techniques and meet the needs of both payers, patients and providers.
    Sherry Reynolds – Alliance4Health

  9. I think you’ll see this sooner than later. It’s really a no brainer. Luckily, we’re in an industry 10 years behind everyone else so all we have to do is observe what happened 10 years ago and emulate the best of breed.
    But don’t worry, it’s close. I promise.

  10. Science today has changed, I hope you used the right way, because there are medications such as vicodin, oxycodone, Lortab, etc, are anxiolytic and although much help to soothe the pain, can be double-edged weapon to control pain, so indicate in http://www.findrxonline.com to be confident that this discovery is beneficial to all.

  11. There is nothing “obscure” about the protocols most EHR and PM type systems use, but MarkS is right — the protocols are the platform: HL7, DICOM, NCPDP, X12.n, ASTM, and CCR/CCD family of “stuff” I think is probably most useful to practitioners and patients in cross-organizational use cases.
    We have these already. For one of them in particular (HL7) the greatest current problem is what I call “minimal implementation”. Especially with Version 3, it will be much harder for vendors (and hospital CIOs) to get away with minimal implementation in the future, one hopes the NEAR future. The HL7 Reference Information Model (RIM) has many decades of business analysis in it and studying it gives anyone familiar wih the art of data management and analysis lots of insight — using the RIM is worth a whole career of increasingly responsible experience in medical informatics, probably more. I do not mean that criticism is impossible, but I do mean that any one team working on its own will not do any better.
    So building on the theme from a couple weeks ago, maybe the prize ought to be some kind of endowment that makes the standards and good implementation guides free of charge to anyone who wants them, even hobbyists. That would probably get you the most bang for the buck. Bill Gates could fund this out of petty cash, but Larry Ellison and Scott McNealy will probably be more sympathetic to the idea…

  12. You don’t need a ‘platform’. An interoperability specification is the platform and it needs to be open to ensure wide adoption and innovation. EHRs now are closed systems with limited data import and export over largely proprietary and/or obscure protocols. This keeps the customer captive but stifles the kind of innovation you are trying to foster.
    In order for this to work, you will need to have open interoperability specifications. You need to have a way that an eRx application can talk to the patient index to get patient demographic information and also talk to the EHR to get allergy and current drug information.
    Each of these modules needs to be able to generate and respond to messages to send and receive the information it needs. This should all be done through open interoperability specifications.
    If you do this, anyone can create a new application that can find the information it needs and adds value.
    You can give grants and prizes but I think these should be given for the open interoperability specifications and implementations. Once these are in place, the new applications will arrive.