Electronic Health Records: Who do we build this for?
Who is the true customer in enterprise medical record software? Who do we ultimately build electronic health records (EHRs) for? Let’s move more influence downstream to the patient, and those that care for them.
Listen to the post on your podcast app under: Gregory Schmidt; or via YouTube
Close Alignment
Many open-source projects have close alignment between their contributors and users.
Often, the software developer who contributes to an open-source project is the same ones who benefit from using the software. There is a clear incentive to contribute because it makes the tools you use better. What to work on? How is 'better' defined? When you are the end-user (and software developer), this question is much easier.
But in most software, there is a gap between the developer and the user. This gap is perhaps most acute in the case of electronic health records.
Huge Gap
I've asked myself: who is the user we build enterprise medical records for? The answer is complex.
a. The medical record is primarily built for the patient. (Sometimes we forget that the only reason the healthcare 'industry exists' is to help heal the sick).
b. But in today's healthcare structure, patients most often need to see a care provider. That care provider interacts with the medical record tool.
c. Other members of a healthcare organization benefit from the information stored within the medical record, such as managers who (ideally) help ensure the system is providing patients optimal care.
d. The clinicians and managers who use the medical record, in general, are obligated to use the medical record their local government or organization provides. For this reason, for many, the 'administration' becomes the primary 'customer' of the clinical system.
As you can see, the end user and the developer are not the same person; and like most enterprise software nor is the product purchaser and the end user the same.
Selling to the top
In most enterprise software, there is an incentive to ‘sell to the top’ as that is where the cash is held.
We have seen the effects of selling clinical systems to 'admin'. In the West, most clinicians dislike or strongly dislike their clinical tool. In general today, it is rare to find someone who 'loves their EHR'.
Most contemporary medical record systems have been designed for the organization's administration (aka the Chief Financial Officer) to be the primary customer. Which does make sense, but I think is the wrong approach to building good software.
This is likely why a lot of enterprise level software falls beyond consumer software in terms of user satisfaction.
Three possible routes to widespread EHR adoption
If an electronic health record organization wants widespread adoption of their product, they could consider these three routes.
1. The first approach is to view the Chief Financial Officer as the primary customer. In this model of growth, after the administration adopts the product, they force all users to use the new system.
This has been the traditional model of installation and growth for electronic health records in the USA. We have seen the results of this, with all-time high levels of physician burnout, dissatisfaction, and sub-par EHR products.
2. The second approach is to view the clinician as the primary customer. In this model of growth, the tool is optimized to clinician's needs. Clinicians within an organization ask for (& demand) that they are given the same great EHR tools they see their colleagues at neighbouring health institutions use. In turn, the CFO and administration look for ways to install that product.
3. The third approach is to view the patient as the primary customer. I think philosophically this is the most correct. The information contained in the record is entirely theirs, and its purpose is to help serve their health.
In producing enterprise-level electronic health record tools, name-brand recognition could be something patients 'look for' when they seek care. Patients, for instance, may ask if their clinicians or health organizations are using a particular EHR tool, just as patients ask certain medications, investigations, and procedures.
(I suspect companies such as Apple, IBM, Salesforce, Amazon, Microsoft, Google, etc are all working on ways to produce medical record tools directly for patient use. This is different, though than producing enterprise-level software for clinician use. Perhaps the approach is to first secure patients data, and then to move into enterprise clinical tools. This approach I think in the long-run will work.)
What is the best route forward?
The American experience has proven that viewing the administration as the primary customer of an electronic health record is an effective way to sell a product, but an ineffective way to develop a product that clinicians actually love to use.
I think that building an enterprise product around patient name-brand recognition is an interesting idea, but I don't see it as the 'first step'.
I'm particularly interested in the growth potential of building an EHR specifically targeted at delighting clinicians, to the point that they demand and request their organization to adopt it.
Anticipated Feedback
Who is the customer? Some may say, the one with the means and the ability to pay is the customer. That is why enterprise software often is sold to the hospital’s Chief Financial Officer / admin. I understand that. However, healthcare financing is complicated. The true customer at the end of the day is the patient. The layers of complexity we wrap around the patient in terms of care providers, healthcare organizations, and governments - ultimately are there to serve the patient. If we believe this, it’s important to move more influence downstream towards them, and those that care for them.
