As I see it, there are two approaches to building a successful EHR. The first is to build The Perfect Product. This is very, very hard. Maybe once in a generation, a Steve Jobs comes along with the right combination of vision and obsessive attention to detail to be able to execute this consistently.

Needless to say, the attempts we have had at The Perfect Product have been far from perfect. Gregory Schmidt points to a 2016 Medscape EHR report which shows that the most widely used EHRs are poorly rated, and that user satisfaction decreased between 2014 and 2016.

In fact, the track record of big tech companies attempting to enter health and failing indicates to me that The Perfect Product, at least when it comes to EHRs, is impossible to produce; our needs as clinicians are too disparate. The obstetrics ward, the radiology department, the lab, and the ED all want information presented in drastically different ways. Thus far no single software vendor has been able to produce a program that satisfies all parties under one hospital roof.

I think an easier approach, one more reliably likely to iterate towards success, is to build A Mediocre Platform, and have third-party developers create modular tools that cater to end-users’ specific needs. At its foundation is a central database with all patient info. The end-user is presented only those facets of the patient he or she cares to know. Third-party developers compete with each other to produce apps that offer the best user experience in the presentation of that info. The apps access the central database through a common application programming interface, or API.

As far as I know, nobody has tried the second approach.

Those in tech are probably more familiar with this crucial difference between products and platforms. For those coming from healthcare, I point you to Steve Yegge’s infamous Google Platforms Rant as a primer. Yegge is a tech industry veteran who has worked at Amazon and Google. (Ironically, the original post was posted to Google+, which no longer exists because, as a product, it could not compete with Facebook’s platform of third-party offerings.)

I’ll summarize the salient points:

Around 2002, when Amazon was still more or less an online bookstore emerging from the dot-com bubble and squeezed by shrinking margins, Jeff Bezos issued a single mandate via email that set Amazon on the path to become the dominant online retailing platform in the world. The keyword here is platform: Amazon doesn’t sell everything itself (ie, buy things from wholesalers, store them warehouses, and ship them to customers). It provides the interface between buyers and sellers.

In one email Bezos changed the culture of the company from one focused on products to one focused on services. In doing so he also made the company vastly more efficient and turned cost items into revenue streams.

Essentially, the genius of the mandate was to make all of the teams of programmers working for Amazon communicate via the same interface (API), and to make the internal services that the teams provide to each other accessible to third party programmers outside the company, at scale, at the flip of a switch. In this way Bezos drastically reduced the amount of redundant work the independent teams had to do. Instead of building a software tool yourself, just look for it in the directory of services — chances are someone has done it already. The fundamental resources that Amazon programmers needed — things like computing power, online storage, database management, data analytics — were now services that could be offered to the outside world for profit. In 2019 this collection of online services, known as Amazon Web Services (AWS), generated revenues of $35 billion USD, 12.5% of Amazon’s total. AWS remains the dominant player in cloud computing today (Netflix, Twitch, Facebook, Twitter are just some of the big names that rely on its services). Before the famous Mandate, none of this would have been possible — the massive amounts of computational resources that Amazon consumed would have purely been an expense on the balance sheet.

Elsewhere in the technosphere, Google saw Facebook’s success as a social network and tried to copy it with Google+, but failed to grasp the allure of Facebook as a platform with a killer app. Per Yegge: 

Google+ is a knee-jerk reaction, a study in short-term thinking, predicated on the incorrect notion that Facebook is successful because they built a great product. But that’s not why they are successful. Facebook is successful because they built an entire constellation of products by allowing other people to do the work. So Facebook is different for everyone. Some people spend all their time on Mafia Wars. Some spend all their time on Farmville. There are hundreds or maybe thousands of different high-quality time sinks available, so there’s something there for everyone.

Our Google+ team took a look at the aftermarket and said: “Gosh, it looks like we need some games. Let’s go contract someone to, um, write some games for us.” Do you begin to see how incredibly wrong that thinking is now? The problem is that we are trying to predict what people want and deliver it for them.

You can’t do that. Not really. Not reliably. There have been precious few people in the world, over the entire history of computing, who have been able to do it reliably. Steve Jobs was one of them. We don’t have a Steve Jobs here.

The architects of EHRs cannot predict what people want and deliver it for them. The best way forward is to create a marketplace of third-party modular apps that can be mixed and matched to fulfill a clinical niche. In later posts I will explore how we can create such a a marketplace.