10 Steps to Prepare your Health App for Monetization

So you released a health app, now what? While waiting for your creation to do its thing and fix health care, there are some steps you can take to increase the odds of its success. Obviously, marketing is very important, but if you are a really good software developer, you probably released something that looks pretty on the outside, while needing many more iterations before it becomes a robust and really useful application. You should have a fairly good idea of what needs to be fixed, what needs to be added and what needs to be changed, if the funds to pay you and your team were forthcoming. Fortunately, this is a perfect time to obtain funding for health apps. There are all sorts of competitions, challenges, incubators, accelerators and crowd funding opportunities specifically for those working on fixing health care, that will not only get you exposure and buzz, but also a few extra development dollars. Make sure you take advantage of them all.

Chances are that you discovered by now that health care apps users won’t pay you a red cent to use the software. This is fine, because I’m sure you know that Larry, Sergey, Zuckerberg and that cute boy from Tumblr made billions of dollars at very short notice without charging anybody for using their software either, so why not you? The modern software paradigm has nothing to do with pricing products. It has to do with getting as many users on your platform, as fast as you can, and the money will follow. Unfortunately, unlike the olden days of social media, your innovation is competing against thousands of others that look just as good on the surface, 99.9% of which will die an uneventful death. When the dust settles, the spoils will go to those thoughtful entrepreneurs who had the wisdom to prepare for success. So make sure you set aside some of the prize money you win at the next health care app fair to get your invention ready for the day when its name becomes a verb, and here are some suggestions:

1. The Cloud – Yes, cloud is getting a bad rap right now, but don’t worry. People have short memories and even shorter attention spans, and by the time you are ready to rake in the cash, nobody will remember the NSA storm in a teacup. Make sure yours is a truly multi-tenant application with one database that can scale to hold the millions of profiles you will soon have. Whatever you decide to store on a user device should be replicated to the cloud religiously.
2. Open Standards – Even if you rigged a couple of things here and there, now is the time to replace all your data definitions with standards based frameworks. Health care, thank goodness, has an ample supply of those. Use SNOMED, LOINC, RxNorm and keep tabs on national standards development. Even if your app is about fixing lifestyles, you should use standards for your data. No, there are no standards (yet) for eggplant parmesan at lunch, but there are standards for weight, height, BMI, cholesterol levels, smoking status, gender preference, and of course, most importantly, last name, first name, DOB, address, zip, phone numbers, email, marital status, and whatever else you can get without creating suspicion (more below). You probably don’t need all the standard libraries, but make sure your metadata dictionaries (i.e. unique database IDs) are standards based.
3. Data Completeness – Whatever your app does, you should always strive to complete your datasets. If your app is providing eating habits modification tools, you should try to obtain all information pertaining to any possible research regarding food intake, and also any possible research where diet may affect results. If you think about it, this is a very tall order, and you may need to do a little research yourself, but a simple diet app could provide you with opportunities to amass data on people’s race, ethnicity, mental status, family situation, occupation, education, income, leisure activities, medications, acute and chronic conditions, etc. To keep your users calm, you should not make any of these items required fields, but instead gently remind them at various points in the lifestyle modification workflow that, for example, evidence shows that optimal caloric intake is affected by say, ethnicity, and give them an opportunity to update their profile to obtain more accurate evidence-based advice from the app. 
4. Data Validation – Data that is misspelled and inconclusive is useless, so make sure your app knows exactly what the user meant. For example, when you baseline your user’s dietary habits and she says that she is consuming one candy bar at 3 pm every day, ask which candy bar. Snickers? Twix? Kit Kat? Have some pictures display and let her click on her favorite. Is she eating that because that’s what the office machine usually stocks, or because her kids make her buy lots of these products? If your app is a trusted confidant, you can get all sorts of information that will make your profiles well-rounded, and let you provide truly useful advice. Maybe she would be open to switching to PayDay because it has less sugar, or a nice fat protein bar.
5. Open Architecture – Good software is built with growth in mind, and nothing grows software faster than a good set of APIs that you can hook to additional functionality developed by others, or by different teams in your own shop. You don’t have to build those extensions now, but you should have the infrastructure to easily add them in the rosy future. So for our Kit Kat lady, you may have APIs available for candy vendors to provide her a healthier alternative right then and there, such as a coupon for Luna bars which are created specifically for her. You can take it one step further and if you have a pill box reminder app, you can suggest that your user may want to talk to her health care professional about certain new meds that evidence shows are helpful to others with similar drug regimens, and if she doesn’t have the money, AstraZeneca can help. So encapsulate your functionality really well, and use generic interfaces for all your class objects.
6. Personalization – This is the age of personalized medicine, and the deluge of genomics is almost upon us. It is probably too early for most health care app developers to take advantage of that, but there are other smaller things you can do right away. The most important one is to have your users upload their picture. You can say it’s for safety and security, or you can say it’s for before and after progress tracking, depending on what your app does. Either way, I don’t need to tell you what can be accomplished with cross platform face recognition. Another way to personalize a health app is to surround people with friends and family. Give your users the opportunity to add family members to their profile and to discover close friends who may be using your app as well. It doesn’t have to be a social forum. Sometimes people feel better just knowing that others are in the same boat, and all you really need is the social connectivity map (degrees of separation). Be careful here so you don’t blow the trust relationship with your users, and make this 100% permission dependent.
7. Usability – There is nothing more useless than an app that does only one thing, no matter how well. Even if you start with a specific functionality, such as say, tracking calories, you should quickly expand to other services. Sticking with a narrow scope, and refining it ad nauseam, puts your app in danger of becoming a module for someone else’s comprehensive platform. You want your app to eventually be THE platform, so add whatever you can add to your open architecture quickly. Social media links are always a hit. Letting your users tweet about their incredible Crab Shack dinner while also adding the outing to their calorie log, is an example of good usability. Maybe you can enable them to post a picture of the crabs on Facebook to support their active social lives. By the way, if your app has bad news to deliver (e.g. you just ate all the recommended calories for an entire week), don’t be a party pooper; save it for the morning after, when your users are already miserable, thus more receptive to reprimand, and constructive advice on alternative eating establishments.
8. Mobility – This is definitely preaching to the choir, since almost all health apps are available for iPhones and most also for Android. If yours isn’t, fix it now. There is absolutely no point in developing solely for the old web any more. And don’t be shy about utilizing all the goodies that come with geo-location (with permission, of course). If you can capture the location and time where Kit Kats are consumed, you have something really unique, like everybody else.
9. Gamification – Here too, you are probably ahead of the game (no pun intended), but if you don’t have stars, badges and happy sounds in your app, you’ll have to add them. Even 80 year olds in a nursing home enjoy a gold star here and there, not to mention the youths in their thirties and forties. People need to be reminded often that they are special and provided with multiple instant gratifications on the road to healthy lifestyles. An app that constantly tells you how great you are is more likely to be used than one nagging you to do better. Needless to say that you should skimp on text and lavish your users with pictures, sounds and infographics, because people who can actually read entire paragraphs of plain text are not your target market. If you created an open architecture as mentioned above, this is a good place to throw in an API for some personalized (with user name) electronic coupons and other exciting freebies.
10. Taste Your Own Dog Food – The culmination of all your hard work is the creation of a big set of interlinked profiles that can be combined with other available information to provide insights into consumer needs, wants and possibilities thereof. To make sure you are producing marketable goods, you should simulate how others may consume your output. Once you have a little extra cash, go out and purchase readily available data sets, or obtain some that are already in the public domain, and mash them all up to see what happens. If you followed all the steps above, this should be like throwing Mentos into a bottle of Coke. Myriads of luscious patterns will emerge to guide your future development, sales & marketing efforts.

Maybe your app will fix health care when it grows up, and maybe it won’t. But as long as you can bring convenience and perhaps a sense of accomplishment to millions of users, along with some serious cash to dozens of customers, you should be all good. Keep your eyes on the prize at all times, because despite all the cheesy inspirational quotes out there, the mega joy is not so much in the journey as it is in the billion dollar destination.

The Holy EHR Wars

"In the same day the LORD made a covenant with Abram, saying, Unto thy seed have I given this land, from the river of Egypt unto the great river, the river Euphrates:" --Genesis 15:18

Some four thousand years later, after numerous detours, major scope reductions, tragedies, compromises and constant upheaval, the Promised Land project is very much a messy work in progress. This is the nature of great promises, and in the here and now, we are contemplating yet another, albeit smaller, promise: ““Hospitals, physicians and other health care providers are clearly taking advantage of recent incentives to embrace the promise  of technology [emphasis added],” said John R. Lumpkin, MD, MPH, senior vice president at the Robert Wood Johnson Foundation.”  The Promise of Technology, as you may have guessed, was not made to us by the Lord Almighty, but instead it seems to be a product of spontaneous creation with mysterious origins.

A few years ago, before the incentives mentioned by Dr. Lumpkin became available, there were dozens of EMR vendors trying to sell software to physicians and hospitals, and like every vendor of any product, they were actively and creatively marketing their wares. Save time and money was a common marketing slogan. EMR websites were sporting all sorts of fancy calculators comparing the costs of doing business on paper to doing business on a computer. The costs of new charts, dividers, paper, ink cartridges, each chart pull, forms, printing paper, etc. were carefully added and compared to the almost zero cost of using software instead. Some fancier calculators even factored in the rent for the additional space needed for chart racks. There were estimates of the number of FTEs that could be let go, or used for worthier causes, and the number of additional patients you can see, if you just buy this or that EMR. Some vendors went as far as advertising better care for patients, with advanced features like automated lab results, pre-built clinical templates and clinical decision support. Folks were kicking tires, shopping around and buying when convinced by ads, sales guys and gals, or even a special discount for the month of August. It was a market, like selling beer, or cars.

But then something strange happened. The United States Government became a believer in the EMR vendors’ marketing slogans. Health care was expensive and not as good or as accessible as it could be, and the EMR vendors promise of saving time and money while providing better care was the perfect solution, particularly since nobody else had anything to offer. Thus the Promise of Technology was born with a silver spoon in its mouth, and was immediately and extensively showered with millions and billions of incentives and resources. The messages on EMR vendors’ websites changed practically overnight from preaching to the infidels to preaching to the choir. Get your incentives, guaranteed, or your money back, was the new slogan. It wasn’t like selling beer anymore. It became missionary work. And, like all great mythological promises, the religion based on the Promise of Technology developed its high-priests, prophets, masses of passive followers, skeptics, and blasphemous heathens destined for martyrdom. The Holy Wars are now in full swing.

Obviously, since the Promise of Technology is promoted by the federal government, its campaigns are better coordinated, better funded and better staffed, and often the full color, multi-media splendor is breathtaking. The latest artillery salvo brings to bear the forces of mighty institutions, such as the Robert Wood Johnson Foundation, the Mathematica Policy Research and the Harvard School of Public Health, in a glossy 82 page report cleverly titled “Health Information Technology in the United States: Better Information Systems for Better Care, 2013”. The report, which does not address either better systems or better care, is a lengthy and multifaceted analysis of the highly successful Meaningful Use program and its effects on EHR technology prevalence and composition in the U.S.  To support the main front, Health Affairs published the research papers and convened a media event to showcase “Health Information Technology Adoption & Use” at the National Press Club in Washington, DC, featuring a star studded panel of experts, heavily promoted through social media, articles, and even national radio. This was the most impressive display of firepower superiority to date.

Basically, the loudly broadcasted, and widely amplified, drumroll is that the Meaningful Use program is working exceedingly well, everybody is buying EHRs and although many “challenges” remain, we are resolutely moving forward, and the Promise of Technology is certain to be fulfilled at an unspecified date in the future. Ample data was presented from multiple sources, processed through multiple software analytics packages, resulting in tables, bar charts, line charts and scatter plots, showing that the prevalence of EHRs of a particular type most conducive to Meaningful Use has increased by 12.4% among physicians and by 28.9% among hospitals since 2010 when the Meaningful Use program commenced and all EHRs were required to be able to support it. This is a very specific way of analyzing EHR adoption numbers, but we need not quibble with the details here. In addition, the Medicaid program for the poor paid out $4.2 Billion to almost 80,000 eligible professionals and 3,000 hospitals for adopting, implementing or upgrading their EHR, and $820 Million dollars to 8,187 eligible professionals and 1,197 hospitals for actually meeting Meaningful Use requirements by February 28, 2013.

The non-believers come in many flavors and as always in history, are disorganized, fearful, delusional and in violent disagreement with each other. There are those who question only the particulars of the Technology, but basically believe in the Promise, and very carefully profess their deep belief in magic in every article or opinion piece criticizing the current state of Technology. This is a very diverse group ranging in interests from those who aspire to be the high-priests of a new (e.g. open-source, modular, iPad based, interoperable) Promise of Technology to those who just want a more transparent way of managing the journey to the Promised Land.  This group has had some limited success in changing the official rhetoric and in obtaining lucrative positions for its better connected leaders. Then there are the heretics who question the Promise itself in studies or opinion pieces, searching for an ounce of evidence that the Promise will actually be fulfilled. Those are summarily burned at the stake.

And then there is a silent majority that is just trying to survive and pay the bills, but sometimes is compelled to vent anonymously on social media forums, with no tangible results. Once in a while there are skirmishes on the ground like the Affinity Medical Center RNs in Massillon, Ohio who went public with their call to delay EHR implementation, or the California Nurses Association press release highlighting the safety and patient care issues caused by a new EHR at Sutter corporation East Bay hospitals, which stand in stark contrast to the official line: “Electronic Health Records Seen as Key Tool for Hospital Nurses”. These things make the industry headline news for a few days and then are promptly eclipsed by some other spectacular fireworks display from the Promise of Technology bottomless arsenal.

As of June 2013 CMS has paid out over $15.5 Billion in combined Medicare and Medicaid incentives to wealthy individuals and corporations, and spent hundreds of millions more in grants, operations and consent manufacturing efforts. The day quickly approaches when the Promise of Technology will be running out of cash to sustain enthusiasm of the masses for the projected decades-long trek through the desert, but resourceful leaders should manage to elicit additional infusions of dollars by hitting various budget rocks really hard, and perhaps other miracles will occur as well.

Collateral Damage

And then there are the poor, the sickest and the most vulnerable; those who pay the highest price before, during and in the aftermath of all Holy Wars. The White House has a map on its website to answer a simple question: “How will the sequester hurt your state?”, and hurt it will. Tens of thousands of children will not be receiving immunizations, millions of dollars in disaster relief will not be available, thousands of teachers will be fired, millions of meals will not be delivered to sick and homebound seniors, clean air and water will no longer be protected, thousands of schools will not be able to help children who are poor, disadvantaged or have special needs and early education for poor kids will be practically eliminated. A map of local reactions and reports from all over the country is maintained by the Center for American Progress.

There are also the poorest of the poor, the schoolchildren on military bases and Native American reservations whose lives are being derailed for the lack of $67 million, which is 20% of what CMS paid out in Meaningful Use incentives just in the month of June. No, the Promise of Technology did not cause sequester cuts, but it’s not like the billion dollar bills spent on Meaningful Use are rigged to explosive devices designed to blow up if misused to help a child in need either.

Should the DoD Buy Epic, or Cerner, or GE, or…?

The Department of Defense (DoD) is in the market for an EHR solution… again. After a lengthy foray into building its own EHR from scratch (AHLTA), with miserable results, and another shorter detour through the fantasy land of an open-source integrated EHR (iEHR) with the Veteran Administration (VA), during which no material progress was made, other than spending taxpayers’ money of course, the DoD announced that it will begin looking for a commercially available product to suit the DoD’s unique needs. This decision is the source of much angst for some and much excitement for others, because no matter what the DoD decides to do, many more billions will be flowing out of taxpayers coffers and into the hands of a lucky few.

On one hand, since most people served by a DoD EHR will eventually be served by a VA EHR, it makes sense that these two government agencies should use the same product and aggregate a lifelong record for their patients. On the other hand, the VA EHR (VistA), although held in high esteem by its creators and users, is very old, and the VA itself is engaged in a major refurbishing effort through a public open-source framework. Answering to a highly frustrated House Committee on Veterans’ Affairs, looking for explanations and bemoaning the death of the iEHR, the DoD’s Frank Kendall reiterated the insurmountable costs and difficulties inherent in building a brand new EHR from scratch (better late than never, I guess) and highlighted the reasons why VistA is not as obvious a choice for the DoD as it is for the VA. Since the VA has VistA already deployed in all its facilities and it already employs an army of experienced VistA developers, a salvage operation for the aging VistA may make perfect sense for the VA, but none at all for the DoD which will be conducting a complete rip and replace program in the next couple of years.

Now that the self-developed iEHR delusion is dead, the technical controversy is focused on whether the DoD should select an open-source product, either VistA or a derivative thereof, or a proprietary system, such as Epic, Cerner, GE, Siemens, etc. The main arguments against a commercial solution are that the DoD should leverage the billions of dollars already invested in VistA, and that it should adhere to this administration’s preference for transparency and open-source technology. To better understand this conundrum, perhaps some terminology clarifications are in order.

Computer software comes in several flavors, and you may recognize most of these flavors if you researched your own EHR purchase recently:

• Proprietary – Commercially Licensed Software - Licensed commercial proprietary software is software you purchase as a black box. You can install it on your computer and use it as is for as long as you want. This is a license to use the software, and implies no ownership rights for the product. The vendor will usually charge you for upgrades. Most often, particularly for business software, you can supplement this one-time acquisition with a maintenance and support subscription fee that will provide you with upgrades and assistance from the vendor. Think Microsoft Office.
• Proprietary – Commercially Licensed Software + Source Code - Commercial proprietary software may include the source code (for additional fees) and rights to extend the original product for private use. Sometimes instead of the entire source code, or in addition to it, selected integration points (Application Programming Interfaces - APIs) are exposed to clients so they can add/customize certain functionalities on their own. Rights to enhance and augment the original source code for commercial resale are usually corporate arrangements not really intended for mere users of software.
• Proprietary – Subscription Based Software - A more modern variation on the above is software-as-a-service (still commercial and proprietary), where you don’t purchase a license for the product, but instead pay monthly fees for using the software, which is maintained and operated by your vendor. These fees are usually a bit higher than the maintenance and support fees for licensed software, mainly because the vendor has to bear the infrastructure costs in this scenario. This goes by the name of “cloud”. Although the vendor may expose APIs for third party developers, this type of arrangement almost never comes with source code, since the buyer is not running the software. Think Microsoft Office 365.
• Proprietary – Free Software - Free software is software you can obtain without paying either a license fee or maintenance fees. Free software may refer to software that you can download and use for free, or more often, free services provided through software residing in the developer’s datacenters (“cloud”). The larger the provider and the more individually geared the software is, the more likely it is that the provider will expose APIs to third party developers. Think Google anything.
• Open Source – Free Software + Source Code – This is what comes to most people’s minds when they say open-source. This type of software is usually developed and managed in a public framework by an all-volunteer squad of techies who have an irresistible urge to donate their labor to better humanity. There are mountains of open-source projects, some highly professional, others not much more than a hobbyist pastime, and there are almost none in wide consumer use, other than a handful of exceptional non-profit foundations (e.g. the Mozilla Foundation and its Firefox browser or the Apache Foundation and its development tools and modules). Open-source pieces of software are often utilized by commercial software companies to speed up their internal development process. For example, IBM’s Watson includes various open source modules, but Watson itself is neither free nor open source.
• Open Source – Maintenance Subscription Services + Source Code - A slightly different business model is an arrangement by which the software itself is provided for free, including source code, but maintenance, improvements, installation and training are billed on an ongoing basis. Sometimes special requests for features or premium functionality are also available for purchase. The software products available through this model are either developed in house by the service vendor, or obtained from a conventional community developed open-source project and enhanced by the service vendor. This model allows clients to customize the software on their own, if they wish to do so, but it may void or complicate maintenance agreements with the vendor.

Regardless of the model employed to obtain software, extensive APIs may or may not be available to third party developers who may be actual users, but most often are not. Software products that expose a good amount of well documented APIs are said to have an open architecture, which is based on accepted and open standards. APIs come in various flavors as well. Some are just plug-ins allowing third party developers to add minimal functionality that does not affect the main product in any way, and certainly does not affect the data layer. Tighter integration that may affect data integrity in the main product is harder to come by and usually requires approval from the original vendor if the software is proprietary. If you have access to the source code, either free or purchased, you can obviously do whatever you want, if you are reasonably certain that you can maintain the software on your own going forward. People or businesses without an IT department are rarely interested in tinkering with source code, so this conversation is really between IT shops, large businesses and true believers in this or that paradigm for software development.

Before returning to the DoD situation, one more word about vendor lock-in is in order. There is no doubt that having the source code (open source or purchased source), and particularly the database schema, makes transferring your data from one product to another a lot easier, if and only if, you have proper IT resources at your disposal. It is possible though, and most often very likely, that if your old product and your new product are very different, data loss will occur no matter how good your IT guys are and no matter how open both products are. Also, it is usually not necessary to have access to every line of code in order to migrate data from one system to another. A clean open architecture based on widely accepted standards is much more important for preventing vendor lock-in and for interoperability in general. Unfortunately none of the choices available to the DoD fit this bill currently, although some may be better than others. So what are the options available to the DoD?

1. Adopt the VA VistA – The DoD rejected this option, but it may be helpful to review it just in case they change their mind again. The DoD could of course obtain the entire VA source code for free, and could also benefit from the VA meritocracy-based framework of open-source freebies donated by selfless defense contractors and eventually by some guy in the Ukraine that is inclined to help the U.S. military save money on software development.
2. Obtain a different open-source product – There are none. The only viable open-source EHR option for large systems, other than the VA VistA is the privately enhanced and maintained VistA offered by Medsphere, which is also contributing enhancements to the VA open source framework. The other VistA derivative is WorldVistA.
3. Buy a commercial EHR – None of those are of course open-source, although if you buy Epic for example, you get the source code, and I would assume that the same is available from all others. A commercial EHR will most likely still need to be tweaked and enhanced for military purposes, whether by the vendor or by the DoD, but it should come out of the box with a lot more bells and whistles than VistA, some useful and others not so much, depending on which one is selected.

Basically, no matter what the DoD chooses to do, they will have access to the source code, and significant programming effort will be required to tailor the product to DoD needs. Most products that could be considered by the DoD have some useful APIs and increasing adherence to standards, but open architecture is not a term that comes to mind in this context. The DoD could hope and pray that the open-source framework established for VistA will produce the software improvements the military needs, or most likely, the DoD will have to pay for all enhancements and new features. In addition to software programming, deploying an EHR requires funds for training and implementation which can easily exceed the software costs by orders of magnitude, particularly since the military has very unique deployment locales.

We may believe that software purchased or built with taxpayers money should reside in the public domain, which almost never happens by the way, but this entire discussion is not really about open-source vs. proprietary products, which is largely irrelevant for the DoD itself, but very much about the plum Pentagon contracts to oversee this mammoth change to its medical records system. The choices are: internally developed DoD resources, a ragtag team of VistA veterans, a newer service entity like Medsphere, a commercial EHR vendor like Epic, or an entrenched usual suspect like SAIC, and most likely a combination of a defense contractor with any one of the lottery winners above. No doubt that as is always the case, the Pentagon will be making a wise, frugal decision, free of biases and bereft of the undue influence of special interests.

Correction 7/14/2013: The original text mistakenly and regrettably stated that WorldVistA is not in active development based on this WorldVistA page. According to the WorldVistA home page, the EHR is very much active and Meaningful Use certified. My sincere apologies to the WorldVistA folks.

Health Care Transformation – It’s not Personal, It’s Business

Why are we transforming health care? Why do we feel compelled to act with such urgency and in such broad reformative strokes? Did we just wake up one morning shaken to our very core by the enormity of having to fill the same medical history form multiple times? Are we driven to bleak despair by the thought of an elderly homeless person having to suffer multiple bouts of disease requiring frequent hospitalizations? Is our battle-forged sensibility to human rights egregiously offended by the realization that some Americans live a few months less than people residing on the French Riviera?  Or is it perhaps the American Dream, having fulfilled itself in all other aspects of our lives, that is now expanding to the next frontier of taming the health care system to individually and respectfully cater to our quest for eternal happiness?  Or maybe it has something to do with cold hard cash…..

Health care, we are told, is way too expensive. We are also told that this is really our fault because it is our job as consumers to police markets, and health care is a market. The original sin occurred in 1965 when we allowed government and subsequently third party payers to insert themselves into a well-functioning market, which relieved us from the need to exercise stewardship of our finite resources, and induced us to engage in reckless binge consumption of health care resources fueled by opportunistic greed of health care providers. The party, with its smorgasbord buffet and open bar, is over, we are told, because the institutions sponsoring this, decades long, shindig are going broke and cannot sustain our health care debauchery any longer. The obvious solution is that we resume our duties as consumers and actively engage in shopping for health care on our own dime, and at the same time our sponsoring benefactors will endeavor to restructure the wild array of colorful and inefficient sellers into a lean health care machine better suited for modern day mass consumption.

Mass consumption requires mass production, which in turn requires proper division of labor, machines and networked computer software. Mass production increases the value and convenience of services for consumers. Pay attention to the terminology. We are talking about value, as in “how much car for the dollar”, not about absolute quality. A high enough value attribute allows cheap, low quality products and services to be presented as high value bargains for savvy consumers. The term convenience is a lot simpler to parse, since it is really an inverse measure of calories expended for the purpose of obtaining a particular service. You can buy anything today with half a dozen taps on your iPad, while sitting on the toilet, benefiting from the aggregate advice of thousands of similarly situated consumers. Nothing should prevent a modern day consumer from obtaining health care advice from the same locale.

Seriously now, the transition to mass produced health care, or any other product or service, involves the consolidation of physical plants and also consolidation of financial transactions over the supply (or delivery) chain. These administrative simplifications are at the root of so called economies of scale. For example, let’s look at the beef industry, which is much more advanced than health care. First, you consolidate all small ranchers into large operators, and as large as feasible feed lots. Some businesses are vertically integrated and do process their own meat, while others act as subcontractors to meat processing companies. Either way, whether for internal accounting or payments to contractors, the pricing calculations are per head. Nobody bills or gets paid for individual services to cows (e.g. food for cow 1, antibiotics for cow 2, transportation for cow 3, etc.). Obviously some cows eat more than others, or maybe cause more trouble than others, but these differences are averaged out to calculate a capitated cost, which is paid in bulk through contractual supply agreements. In fully integrated businesses, feed lot operators are of course paid fixed salaries and perhaps even productivity bonuses if all the cows can ambulate from the truck to the bolt gun without incident.

Paying per head instead of fee for service has other competitive advantages, since it incentivizes service providers to innovate and manage costs down without micro interference from the purchaser. Obviously some quality assurance and spot checks are in place to make sure that those who pay for health care (or cows) get their money’s worth, and educated consumers get valuable service (or steak). For example, if a broken and fragmented primary care practice with say 5 physicians takes care of say, 10,000 people in a fee for service environment, once the per head model is adopted, the practice is free to fire 3 costly doctors and replace them with a couple of NPs and three or four RNs (i.e. proper division of labor), and save the cost of at least 1 physician FTE. May not be much, but aggregating over large scale operations, the new owners of this once fragmented practice, can realize significant economies. The trick of course is to keep the cows calm and blissfully ignorant while these transitions take place. To that end, satisfaction and experience are religiously measured frequently and all personnel, including any remaining physicians, are trained in soothing bovine communication skills, such as “DON'T SAY THIS: They are making me use this laptop with all my patients, and I can't find anything on it! SAY THIS: Our practice is using a new computer system, so I will be typing what you tell me as we talk. Please let me know if I fail to answer one of your questions.” Openness, honesty and candor, may be important for human relationships, but have no beneficial effects on large scale operations, and may even cause costly disruptions to standard work flows.

Another innovation made possible when purchasers stop paying for actual work or materials and start paying a fixed sum per head, is the ability to empower people to do some of the work by themselves. Computers that are quickly becoming ubiquitous in medical facilities and thousands of consumer facing mobile health (mHealth) apps are aiming at doing just that. Remember the days when you had to call the operator for a phone number, or the store to find out how late they’re open? In the not so distant future, calling a doctor’s office for advice on simple things will be just as anachronistic. So if you are still tinkering with your iPad on the toilet and are getting really annoyed by the mosquito bite on your driving finger, scoot over to your favorite triage app and they’ll tell you what to do.

Holy Mary Mother of God! Louise!!! I have to go to the ER… the computer says no treatment is necessary but the ER thing is right on top… maybe there’s something going around…  and there’s no waiting… I’m making an appointment… go start the car honey… what… you arguing with the computer now?

Wait a second…. What just happened here? Every symptom you punch into this app, no matter how minor, brings up the ER at the top of the list for appropriate choices for this condition, and a list of all ERs in the area with some “more fortunate” ones sporting a button for you to fill out a form letting them know you’re on your way.  Perhaps the new mHealth app developers are much more concerned with people’s health than their legacy EMR predecessors, or maybe we are overlooking something.

We are. Although health care expenditures are bankrupting the nation, they seem to have an opposite effect on some stakeholders. Health insurance companies are thriving. Large health systems are awash in cash. Pharma and device stocks seem to be doing just fine. Health IT vendors are growing by leaps and bounds and private capital is pouring into mobile health app development. Employers on the other hand are the only ones putting money into the system, other than us of course, and they simply can’t afford it anymore, which is the main reason workers’ wages are stagnating. For example if you are single and you made say $50,000 at the turn of the new millennium, and your employer paid for all your health care, and you managed to keep your job to this day, and like your wages, health care costs did not go up faster than inflation, you could be looking at a whopping $71,000 instead of your measly $68,000 due to escalating health care costs. Somehow the inability to pay you this extra bounty is driving your employer to bankruptcy, not to mention despair.  And although the Dow Jones Industrial Average is hovering at an all-time high, hardly indicative of any corporate hardships, the difficulty associated with leaving $3,000 on the table for those who never leave anything behind, is understandable.

So why are we transforming health care, considering that the needs and wants and “rights” of individuals in this country are of no concern to anyone but the individuals themselves? We are transforming health care because $3,000 is a lot of money for those who moved their entire operations offshore for a lot less than that. And we are transforming health care because, as strange as it may sound, there is still some more money to be made from herding people into mass produced health care, as the innovative slaughterhouse pioneers have clearly demonstrated. It’s just good for business, and this is America.