Why One Startup Turned Away from Medical Record Portability

Earlier this year, Drausin Wulsin and I set out to solve the issue of medical record portability for patients in the United States. What began in the spring as inspired musings over a beer accelerated into a full-time effort out of an apartment in Harlem by late summer. Last week, we called it quits. Below, we discuss why a problem exists, and why we pulled the plug nonetheless.

It has been said that every great startup is founded upon a secret. It is admittedly no secret that the United States healthcare system is still afflicted by costly and burdensome patient data siloing that effectively robs patients of the ability to easily discover, navigate, and share their complete health data. However, it still appears to be secret how a startup might profitably serve that capability to patients in light of complex market and technical hurdles facing anyone that might attempt it, as my partner and I have done over the last few months.

The Appeal of Solving Medical Record Integration & Portability

Our startup began, as many do, with a desire to solve pain that we had personally experienced. After a sports-related back injury, my partner, Drausin, found himself taking up an archaic and burdensome part-time job of personally connecting clinical dots between his primary care physician, orthopedist, surgeon, and physical therapists. There were CDs of imagery to personally courier, faxes to prompt and confirm (some sent correctly, some incorrectly and repeated), and of course paper documentation to collect. This medical episode was relatively limited in scope and fortunately treatable, as compared to the experiences of those with chronic conditions or complex acute episodes.

Ugh

As data engineers and product-minded people by background, we believed that surely there could be a better way to provide patients with access to their integrated health data. Such a record could incorporate and integrate many familiar medical data elements — records relating to historical episodes of interest (surgeries, hospitalizations, etc.), longitudinal tracking of routine tests and evaluations (annual blood work, etc.), current and past prescriptions, allergies, vaccination history, medical team contact information, etc. — alongside more novel data elements including mobile-based activity tracking, personal symptom monitoring, etc.

Ideally, such a record would conveniently provide helpful awareness and control to patients, while at the same time streamlining coordination among clinicians to ultimately deliver a more patient-friendly, effective, and lower-cost medical experience.

It was from this starting position that we began to explore the space and shape an offering.

Discovering the User

Who is best served by getting hands-on with integrated medical records? Who are the users?

There are several potential user groups from across the healthcare value chain might directly find utility, among others:

• Clinicians could get a more complete picture of each patient’s status and history;
• Patients could understand and contextualize their own health and those of loved ones better;
• Payers could perform speedier utilization reviews;
• Pharmaceutical companies and public health researchers could generate new insights through more comprehensive real world evidence.

Provider as the User

The potential user with the most immediate need for medical records is the provider — typically nurses and physicians that are actually interpreting patient history, creating new data, and developing plans of action.

On its face, it would seem appealing for physicians to have a patient’s complete medical record at their fingertips. However, this was ultimately not as compelling as we had anticipated.

Firstly, physicians seek relevant history, not exhaustive history. Several physicians we spoke with are actually quite dismayed when a patient shows up with binders of irrelevant information. They are to some extent obligated to ensure there are no landmines in the file, and yet most of those records pertain to unrelated body systems (i.e., a gastroenterologist doesn’t care about a history migraines). Physicians are financially incentivized to maximize patient volume (more patients/day yields higher revenue), and the obligation to review dozens or hundreds of pages of documentation would become slow patient velocity and therefore revenue.

In fact, one ask we consistently heard from physicians was for functionality that could parse unstructured medical records to highlight key information. This would require substantial NLP capability, and potentially with only modest success. Ciitizen may pursue this area in addition to their clinical trial focus.

Secondly, although every physician will complain about their EMR, they definitely don’t want to interact with multiple systems. Consequently, a new record portability service would likely devolve into a back-end pipe, rather than an informational interface. Various HIEs and Epic Care Everywhere already occupy much of this space.

Additionally, even though procedures may repeated from time to time, it is hard to consider all of those repeat tests as duplicative. Clinical measurements and scan results can change over time — sometimes rapidly, and clinicians want up-to-date data to make decisions. They may also have idiosyncratic preferences that guide their diagnostics — for instance, one patient was advised to undergo a very expensive MRI for a shoulder injury only to have the orthopedic surgeon ignore it in favor of a portable ultrasound in the examination room. Fundamentally, expansive data history is not necessarily useful data history.

Patient as the User

For the reasons above as well as personal identification with patients’ pain points, we were most drawn to directly serving the patient, and so we began with our focus there (of course with a mind to facilitate patient-to-provider sharing in due course). Starting out, however, we had only our own limited experiences as patients to draw upon, and so we started collecting more perspectives.

In course of numerous consumer interviews, we began to delineate between a few distinct user groups of interest to better synthesize their pain and their needs:

• Healthy young adults to middle age — the mass market;
• Parents of young children — keenly interested in the health of their children who have frequent medical interactions even when generally healthy;
• Caretakers for aging parents — eager to minimize complexity while ensuring quality care often addressing multiple body systems;
• Individuals managing complex or chronic conditions — those patients with the most challenging information management challenges.

Among the generally healthy user populations, there were several key findings:

• Patients and caretakers (parents, adult children) have substantial general trust and reliance on the system to steer them right — i.e., if something was important for me to know, my doctor would have told me.
• Among those that do collect some amount of personal or family medical records (in paper files, local drives, cloud storage, etc.), the value is generally perceived to be option-value — i.e., “This data has no current day-to-day value, but I expect that my investment in collecting and managing these records may have future value in the event that I experience an adverse medical incident.”
• Patient portals are filling much of the demand for personal health information. This was particularly notable among parents of young children, as those children usually have only ever had one medical home (their first pediatrician), and in our findings even many independent pediatrics practices had patient portals, some of which were integrated with local hospitals systems’ systems (i.e., via Epic Care Everywhere).
• For some generally healthy individual tracking certain long-running conditions (e.g., persistent orthopedic problems, genetic risk indicators, other manageable disorders, etc.), they may maintain records to ease any future doctor transitions and just for their own sense of security, but they actually make use of that data very infrequently.

To be sure, there were some interesting regular scenarios where we identified consistent pain — such as moving between cities, a parent’s burden of filling out school forms with vaccination histories, or difficulty remembering past prescriptions for recurrent but infrequent issue. Some patients and caretakers may keep records to ease these activities and avoid having to wrangle records down the line, but that cost is quite minimal (perhaps a max of two hours annually), and generally were not consistent or urgent enough to build a business around.

One particular challenge is that, for healthy people, the frequency of novel new data (i.e., other than fitness tracking data points) is low, and there isn’t a meaningful feedback loop. This is as opposed to fintech apps, for instance, which have many daily data points (new payment transactions, stock movements, transfer activity) and a strong feedback loop (“Whoops, I’m about to overdraw my checking account, I better not spend more money until I get paid.”).

For those managing certain common conditions for whom daily behaviors such as fitness are correlated with measurements such as high blood pressure, the feedback mechanisms are noisy and severely lagging. Certain more direct feedback loops such as diet → blood glucose levels are already largely addressed by specialty device-app integrations.

Consistently, healthy consumers regarded billing-related tasks as a much more painful aspect of seeking care: pricing is not transparent, payment portals are poorly designed and often require distinct credentials from the patient portal, and unexpected bills may chase frequent-movers around for years damaging their credit scores (even when for trivial amounts). We identified several startups focused on the patient payments and collections problem (Eligible, Cedar, Phreesia, Updox, etc.) and opted not to pursue the space further.

There is of course another population — the chronically ill — those experiencing the most record complexity and the most pain accordingly. They of course would be best aligned with our mission to improve patients’ lives. For them, the question was less of interest, but more about how we could best serve them given large volumes of data, often of complex record types, which we will discuss below.

Ultimately, our conclusion is that while an enhanced ability to view and manage personal medical records would be “nice” for many consumers, we struggled to discover how we could deliver significant consumer delight, or create the type of dopamine hit-type engagement that can drive engagement with social media, fintech, and other higher velocity data streams.

With some uncertainty about the levels of consumer engagement, we proceeded to understand who might actually trade value for this service, and how those economics might look.

Discovering the Buyer

Even assuming consumer-as-user, it wasn’t immediately clear who the most motivated buyer might be. There are several possible motivated buyers.

Consumer Subscription is straight forward as a revenue model. Both common sense and our interviews confirm that most people of even reasonable means probably have several media subscriptions (Netflix, Hulu, cable, newspapers), and Amazon Prime is near-ubiquitous among wealthier urban individuals. Beyond those, many tech-minded consumers subscribe to premium cloud storage tiers, pay for premium app memberships (though churn is high), and possibly subscribe to hobby-related specialty software (e.g., photo or music-editing).

However, the question on every consumer’s mind when weighing a subscription is, “How much value will I get for the monthly/annual fee?” If the value or the engagement with the service are low, consumers will not adopt or will quickly churn even at trivial price-points. Consumers will discontinue even a nominal $5/month fee if they are not active users of the service.

Most consumers we interviewed suggested they might be willing to pay around $2–5/month for a hypothetical integrated medical record wallet. Of course we had yet to design the actual app, which might drive greater engagement and value if executed perfectly, but we at least had a ball park figure for possible unit revenue, and consequently possible cost-to-service.

By comparison, one existing patient wallet, PicnicHealth, charges $299 to enroll and $33/month thereafter. Our interpretation is that they’ve abandoned the mass market to rent-seek in the neediest population, but with allegedly little success (more below).

Alternatively, PatientBank, a Y Combinator grad, operated a variable-fee model in which patients paid $9.99 for every new records request from one of their providers. Unfortunately, that business model ultimately failed.

Providers might plausibly want to reduce operational costs of data migration. We had expected that practices both large and small might want to reduce operational costs associated with sending and receiving medical data in unwieldy and manual ways (sending and receiving faxes, printing and mailing, burning and ripping CDs, etc.). Surely an effective digital solution could reduce back-office head count and perhaps allow staff to focus on higher value activities, we presumed. Unfortunately, we found that neither large hospital systems nor small provider groups are highly motivated to invest in streamlining these activities. Operational costs for data sharing are simply too small on the budget to merit attention — they pale in comparison to the blockbuster costs of medical devices, precision medicines, physician salaries, and so on. Furthermore, these operational staff may also perform helpful and context-specific data curating tasks that ease the burden on clinical staff who use the data.

Alternatively, small providers might theoretically want to sponsor patient participation in a health wallet to provide better patient experience and perhaps build an offering to oppose the information monoliths held by competing large hospital systems. However, the value is unclear, and selling into small provider groups was expected to be a challenging direct sales effort (as ZocDoc knows), or worse — given EMR fragmentation among small providers, onboarding new practices might lapse into complex sales, requiring significant customization, user training, etc.

Large hospital systems also appear to be reluctant buyers. It is important to note that clinicians are not the buyers — executives are. While executives are certainly mission-driven and financially incentivized (by CMS and others) to deliver quality care, they are still in the business of running a profitable enterprise. Many have made significant investments in EMR platforms (read: up to and over $1 billion) and aren’t exactly writing checks for additional data integration technologies. Furthermore, they are reluctant to risk increasing patient leakage by handing every patient their complete medical records to take across the street to a competitor.

Payers have significant incentive to reduce charges for duplicative care. To allow them to achieve this, first we would have had to demonstrate meaningful reduction in healthcare consumption due to information portability, which would require a substantial pilot engagements to build evidence. The model would presume that the insurer could lean on or incentivize the providers in their network sufficiently to facilitate adoption of the data portability technology. This would be a long and uncertain road.

Payers do have another interest in obtaining actual patient or anonymized population data to better model risk and interventions, but this model is cousin to the pharmaceutical-centric model, described below.

Employer-sponsored health perks are increasingly common for companies large and small. In our recent positions at Oscar and Palantir, Drausin and I enjoyed medical perks ranging from concierge primary care memberships to fertility program enrollment to mental health program membership. They are intended to reduce aggregate group health plan costs and also aid retention. However, the value-proposition is ultimately held in the ability to reduce total medical consumption for group policies (by volume or by shifting it to lower-cost channels) or that the benefit is so self-evidently valuable to the employee that they are motivated to keep their job and the benefit— effectively an indirect subscription model. Therefore, we must demonstrate that type of value, as described in the payer and consumer discussions, before having a compelling offering to sell to employers.

Pharmaceutical companies are universally understood to be where the money is in health data. Patient wallet technologies can be used to either identify candidates for clinical trial participation, and can then be used to manage participants’ health records and combine them with ongoing monitoring in the form of symptom tracking, etc., from the mobile device. This is a potentially lucrative, but is more focused on select user groups than a systemic improvement in patient experience. It is also, unfortunately, quite a crowded and growing market, as described below.

Serving the User (i.e., Get the Data)

In many ways, getting the data is itself a specialized business. Companies such as Redox, Medal, and HumanAPI have focused on developing techniques to move medical data point-to-point, and so far, reportedly without wild commercial success.

Given a fairly sober revenue outlook, we understood it would be necessary to obtain the data inexpensively.

We explored a number of techniques for obtaining patient data (once properly authorized, of course). Per the original problem statement, the methods to obtain data are very fragmented:

• Consumer-uploaded documents (usually PDFs or images);
• Faxes (often digitally as an image or PDF) directly from providers;
• Patient portal integrations (i.e., direct integration or scraping) using a patient’s credentials;
• Public FHIR endpoints of an EMR using patient portal credentials;
• Direct EMR integrations via vendor partnerships (as Epic, Cerner, and others engage in with select companies);
• EMR app ecosystem integrations (e.g., Epic’s App Orchard), which often exchange HL7 documents;
• HIEs and other data exchanges like CareQuality and Commonwell, which usually exchange C-CDA documents;
• Third-party integrators like Redox, Medal, and HumanAPI (which rely on some combination of the above).

Despite the multiple lines of attack, we concluded that each was afflicted by material weaknesses that, when combined with market uncertainty, substantially moved the needle on our confidence going forward.

Data not sufficiently usable — User-uploaded PDFs and faxes (which are sometimes/often are OCRed) need to be structured and separated into meaningful units (notes for a particular visit, diagnoses, prescriptions, etc), and this is often manually intensive.

HIEs and other data exchanges like CareQuality and Commonwell offer the simplest way to get this data, but that data (in the form of C-CDA document) is often quite sparse, often missing granular data like lab results, clinical notes/summaries, and prescriptions.

Intermediation by portal — Patient portal integrations (whether via scraping or FHIR endpoints) require the patient to have credentials already set up. While many patients have logins for some of their portals, they often don’t have them for that one-off doctor they saw 3 years ago, or who doesn’t have a portal, or has one but they never bothered to create a login for it.

Long implementation cycle — Direct EMR integrations are probably the best source of data (especially since it often allows for pushing data into the EMR as well), but they are the hardest to set up since they require coordination which every hospital system, something that’s often hard to do (or even get the meeting for) for a small startup.

One new player, OneRecord, has made tremendous progress by coming into space with a hybrid approach. By combining query based document retrieval with HL7 FHIR APIs, OneRecord’s application creates a clean longitudinal record using a novel aggregation engine and ML algorithm. OneRecord has taken a differentiated approach, and understanding a bit of their story underlined to us that the barrier to entry into the space was high.

Third-party integrations indeed solve some of the above problems, but not all of them. (e.g., Redox still requires coordinating directly with a health system; HumanAPI still requires patient portal credentials that patients may not have.) Furthermore, as data- and product-focused founders, the idea of outsourcing such a critical component (especially in the face of unclear business model and the non-trivial vendor costs) seemed untenably risky.

And this is just the technical context for obtaining data. Before even having a chance at this implementation challenge, one would need to obtain patient consent, and also wrestle with a number of business and regulatory blockers that hospitals often raise.

Unit Economics for a Start-up

We’ve established that potential buyers are willing to pay quite little per consumer (absent some surprising and remarkable product innovation), and it is likely quite expensive to service a single patient in both initial data engineering investments and likely recurring variable costs for each new record.

This is to say nothing of the customer acquisition cost. For patients, that cost would likely be quite high to establish a consumer brand even in a limited geography such as New York City. For providers, the population is smaller but would require closer engagement for each sale.

So How Might This Work?

Despite all of this, the field of companies trying to solve this problem is surprisingly well populated. So what’s their secret? How are these playing out?

In order of increasing complexity:

A) They Don’t

There are an alarming number of bodies in the field. Google Health was arguably too early, but even just this year patient wallets are struggling or folding.

• PatientBank set out to solve this problem and after raising over $2 million from VCs, including Khosla Ventures, but essentially gave up and publicly stating that they just couldn’t figure out a business model.
• PicnicHealth is reportedly trying to aggressively grow the clinical trial business due to weakness in the consumer-direct business.
• Gliimpse was an early adopter of the FHIR standard and was acquired by Apple to form the seed of their records business in 2016. It is difficult to discern if they could have succeeded as an independent company.

B) Blockchain — The Great Savior

Companies such as Embleema, Citizen, and Ciitizen (two different companies) are throwing blockchain at this problem. The pledge is to unite decentralization with incentive schemes that could reward both providers and patients for participation.

These efforts are too early to evaluate fully (none have publicly released), but ultimately, it seems that mostly they are combining standard storage with blockchain based authorization, which seems a bit contrived to just get the word “blockchain” into the company’s pitch.

Furthermore, they’ll ultimately be fighting a standards battle. There are many existing HIEs operating on open standards such as FHIR and direct messaging. Perhaps these blockchain-based solutions can become HIEs in themselves, but they will own a small part of the market.

C) Pharma Pharma Pharma

It seems that most established players in the market are racing to become the next Flatiron Health by curating and structuring real world evidence for clinical trials, possibly including AI. PicnicHealth, for instance, seems to have spun out a separate entity, PicnicAI, entirely dedicated to using AI to deliver more complete medical histories for clinical trial use.

Hugo is another one-time wallet company that is now pivoting to the clinical trial support space.

D) AI Improving Care Quality

Ciitizen is going far beyond just using blockchain though, and has a very promising team that can likely produce something distinctly valuable. Their founder is the same as Gliimpse — the same acquired by Apple in 2016.

It is understood that Ciitizen seeks to apply AI to provide faster and more complete diagnosis to patients, levering NLP of structured data as well as clinical notes. This approach has been very successful in the world of machine vision for imagery-based diagnosis, and if Ciitizen can demonstrate functional models, they’ll likely do extremely well.

E) Be Apple

Or you can be Apple. In January of this year, Apple announced Health Records, which allows consumers to view certain structured records such as lab results, prescriptions, vaccinations, etc. from supported health systems on the iPhone. Twelve systems were supporting the service at the time of its announcement, and over one hundred systems participate today.

The economics and opportunities look quite different for Apple.

Consumer access is solved — Apple doesn’t need to sell to consumers at all. The feature is installed on every recent iPhone in the US. If a consumer perceives even remote value or a mere curiosity, they can be up and running with a trusted service provider in minutes.

Data pipes are flowing — Apple is leveraging FHIR-based connectivity that it started investing in with its acquisition of Gliimpse. Reportedly, Apple is providing direct technical support hospitals that wish to implement new FHIR endpoints so that they may capture new incentive-based payments under ONC’s Promoting Interoperability program. Apple can do this quickly and relatively easily due to its operational scale, as well as vendor partnerships with EPIC, Cerner, Athenahealth, Meditech and AllScripts entered into under unknown economic terms.

Long-term survivability — Given positive regulatory trends, Apple has the capital and autonomy to wait out the market. They are delivering value today, but can invest with confidence in outsized longer-term dividends as we get to the mid-2020s and health data availability is more complete.

Apple has unique internal value opportunities — Apple has made it clear that they perceive the Apple ecosystem to have a meaningful role in health. For one, they have recently concluded data collection for a heart health study in partnership with Stanford (http://med.stanford.edu/appleheartstudy.html). Many speculate that Apple is keen to enter the medical devices market, either as an OEM or the backbone of a new ecosystem of internet-connected health devices. Whereas Theranos promised a world of ubiquitous personal health measurement but lacked (by a wide margin) the skills to bring that vision about, Apple is comparatively well positioned to deliver user-friendly and effective devices that converse seamlessly with each other, users, and providers.

GE and Philips should be scared, as should competing mobile OEMs. We expect they’ll be in an acquisitive mood, but we were reluctant to jump in the pool to start from scratch just hoping to get bought in a competitive fit.

F) Outlast and own the future

A combination of regulation pushing providers, and fear of more regulation pushing EMRs, has led to slow but monotonically improving integration among legacy players. In our discussions with physicians, it’s apparent that Epic CareEverywhere will continue to provide more and more data connectivity that physicians are seeking, thus reducing the burden on patients to move their records.

At the same time, the ONC has developed a 10-year roadmap to improve health data interoperability in a number of ways. Ten years is a long time for a startup to wait, but Apple and consumers can perhaps be patient.

Furthermore, that roadmap includes structural planning for a National Health Information Network. Essentially, an umbrella HIE to connect the smaller HIEs that are currently regionally-focused. This will, again, be a long-time in coming, but an effective, federally sponsored, national patient data discovery and transport layer would obviate the integration challenge — putting an end to one generation of patient wallets — and open it to a new generation who are most expert in intelligent recommendation systems, highly differentiated user experience, and novel uses of available data.

Conclusion

Medical record portability is still a problem — patients, providers, payers, and the American healthcare system at large all bear some pain. However, the pain is too diffuse and low-grade in any single population to motivate a change. Furthermore, there are in some cases incentives to perpetuate this backwardness. This, combined with the difficulty of obtaining and structuring patient data, led us to move away from this space as a target for a spirited new entrant.

And yet, it will be solved someday. Although data portability is not a sufficient use case for a business, it is likely be a necessary one for higher value use cases that well funded players will pursue — such as Apple seems to be working toward.

As patients and enthusiasts, we will eagerly watch the space as it evolves and wish everyone in the market well, but we won’t be holding our breaths.