Wednesday, April 26, 2017

I’m sick to death of moonshots

Risky and ambitious projects are exciting, inspiring and valuable, but calling them moonshots is getting a little bit annoying.

Google – specifically, X, their research division – seems to be responsible for the current trend of overusing the term moonshot. A Google-style moonshot is defined as any project that’s groundbreaking, expensive and has unclear chances of success. By this standard, almost any project qualifies. One of X’s projects is LinkNYC, a project to provide free WiFi in New York City – definitely a huge project, but questionable whether it deserves “moonshot”

The Cancer Moonshotchampioned by former Vice President Joe Biden, is healthcare’s most prominent Google-style moonshot project. Anything having to do with cancer is groundbreaking. With $1.8 billion appropriated over seven years, it’s expensive. Success, which is defined as making 10 years’ worth of progress on cancer research in only five years, is not guaranteed.

Let’s contrast this to the original moonshot from 1961, when John F. Kennedy challenged the nation to land astronauts on the moon. The project statement was just one sentence: “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to earth.”

That one sentence gives us an archetypical example of a SMARTgoal, even though the concept wasn’t invented for another 20 years. SMART is an acronym for five adjectives that describe a well-constructed goal: specific, measurable, agreed-upon, realistic, and time-bound. The SMART criteria are usually applied to personal, rather than organizational goals, but Kennedy showed that successful moonshots follow the SMART pattern.

Kennedy’s goal has two specific parts: land a man on the moon, and – importantly – return him safely to Earth. He could have simplified the sentence by omitting the part about returning, but then the return trip would have been implicit, and not a SMART goal.

The original moonshot goal is also measurable because it’s easy to tell if we’ve landed a man on the moon and returned him safely. Ideally, SMART goals also have regular milestones for tracking progress. The space program contained milestones like putting an animal into orbit and then a human, but the milestones were not as linear and easy to track as LinkNYC’s, for example. LinkNYC aims to install 7,500 kiosks. Progress toward the goal can be tracked one installation at a time to show a “percent complete” metric. Right now, they’re about 10% complete.

The A in SMART stands for “agreed-upon,” which means knowing who is committed to what. This works well for personal goals, but for organizational goals the responsible parties can be tough to nail down. Kennedy stated it generally as “this nation,” but at least that’s more than the Cancer Moonshot, which doesn’t specify who is supposed to be working toward the goal.

Was it realistic to land a man on the moon in 1961? It was definitely ambitious. Realistic is the hardest part of a SMART goal because realism needs to be balanced with challenge. Otherwise, there’s little need for a goal. But a “realistic challenge” is a much better goal than the Google-style criterion of “uncertain chances of success.”

Time-bound is an often-overlooked aspect of goal-setting. It’s absent from the Google-style moonshot definition, but it was present in Kennedy’s challenge. He specified the end of the decade, a deadline that was met with several months to spare. 

The space program not only achieved Kennedy’s SMART goal; it had a broad impact on science, politics, and especially technology. One of dozens of examples is that electronic circuits were based on vacuum tubes in 1961. Tubes are bulky and prone to failure – not a good option for a mission to the moon – so MIT invented integrated circuits (IC’s).

ICs made it possible to include onboard navigation computers on space vehicles, and as a side effect, gave birth to the computer industry (as well as dozens of others). In many ways, the side effects of the moonshot were more important than the main goal.


When I mentioned at the beginning of the article that I am sick to death of moonshots, I was talking about today’s watered-down moonshots that are expensive and risky. If you’re going to work on a moonshot, make it the Kennedy kind with a SMART statement and constructive side effects that will pay for the project even if you don’t achieve the main goal.

Tuesday, April 4, 2017

Fundamental problems of interoperability: Why is it hard?

Once again, interoperability is near the top of everyone’s healthcare IT “to do” list this year. This evergreen health IT trend remains unresolved, which executives, clinicians, and patients find exceedingly frustrating. Other industries, from credit card companies to airlines, integrate systems with what appears as minimal hassle. Why does the healthcare industry have such a hard time?

There are some technical, nuts-and-bolts difficulties with getting systems to interoperate, but there are also fundamental, conceptual roadblocks that make healthcare different and harder than other industries.

Follow the money

Financial motivations are a main driver of interoperability in any industry, either reducing the cost required to complete a transaction or increasing the volume or value of transactions. Credit card companies, banks, airlines and other industries interoperate smoothly when doing so facilitates sales.

This is why billing data flows with reasonable efficiency from healthcare providers to insurance companies. It’s a place where interoperability improves cashflow, and it’s an often-overlooked example of effective interoperability in healthcare.

One reason that other types of data don’t move around very smoothly is that one party or the other (or both) are not incentivized to make it easy to share data. In fact, if a hospital holds patients’ medical records as a way of keeping them from seeking care elsewhere, there is actually a financial disincentive to sharing.

The Meaningful Use program’s incentives for sharing healthcare records have somewhat changed the equation, but an artificial, external, one-time-only financial incentive is seldom an effective long-term solution.

Who’s in charge here?

USB is sometimes used as an example of ideal, plug-and-play interoperability. The strict USB standard is one reason this level of interoperability can be achieved, but part of the standard includes clear distinctions between the master and the servant. Your computer commands the hard drive to write a file. There’s no negotiation.

Similarly, financial transactions like credit card charges include one party initiating an authorized transaction and the other party being contractually obligated to fulfill it. Again, no negotiation.

In healthcare, the roles are less clearly defined, and that causes an obstacle to easy integration. One EHR can push a patient’s record to another, but nothing requires the receiver to accept the data. Or, an EHR can try to pull a patient’s record from elsewhere, but there’s no guarantee that the far end of the interface will comply with the pull request.

The absence of an exchange agreement that defines commitments is one problem, but there’s also medicolegal issues at stake. An EHR doesn’t automatically accept every record that might be pushed to it because institutions don’t want external parties contributing data into their official, legal medical records.

Mismatched Models

Consider this use case: a patient presents in the emergency department with symptoms of pertussis. The doctor orders a lab test and confirms a diagnosis of pertussis and notifies the local public health department.

In this scenario, there’s a single subject: a patient with pertussis. But each of the three interested parties has a different conceptual model of the event. The doctor has a patient-centric approach that focuses on diagnosis and treatment. The laboratory’s unit of work is a sample that needs testing. The patient’s information is recorded for administrative and billing purposes but is irrelevant to the test or the results they send back to the doctor. The public health department’s view of the situation is in terms of a case of pertussis that may indicate an outbreak or the need for an intervention.

Doctors think about patients. Labs think about samples. Public health thinks about cases. These different points of view carry over into the workflows and – more importantly for this discussion – the software they use. Different kinds of software have different data models of the healthcare domain. In fact, the same kind of software (for example, two different EHR products) may have different data models because different vendors have solved the problem differently.

In order to interoperate between systems with different data models, two translations are required. The sending system has to convert its proprietary model into a standard format. Then, the receiver has to convert the standard format into its own native format. Each translation is an opportunity to lose fidelity. Even if the participants are willing to exchange data, the results may be far from perfect.

One solution to the problem of different data models would be to make everyone use the same model. This is how HL7 v3 approached interoperability. Unfortunately, a model of healthcare that’s rich enough to satisfy all stakeholders is intractably complex and turns simple integration projects into impractical ones. When everyone shares a model of healthcare, no one shares it.

So now what?

Interoperability fails in healthcare because there are rarely business cases for sharing data, poorly-defined technical contracts built into the standards, and different domain models. So, what’s the answer? Blaming vendors and providers is unproductive. While there is plenty of fault to go around, they can’t solve the problem just by changing their attitude. There is, however, some hope on the horizon.

Value-based reimbursement systems, such as ACOs, may motivate stakeholders to work together to optimize each patient’s care and minimize costs, providing the needed financial incentives to share data. Integration profiles like the ones from IHE prescribe roles, not just data formats, for the participants and provide at least a modicum of compliance testing. Emerging standards like FHIR are creating a healthcare data model that is standardized but lightweight enough to be practical.

We’re still pretty far from solving the interoperability problem, but with persistence maybe it will someday fade from the top of everyone’s list of major health IT initiatives.