In this two-part series, we examine several common misconceptions
made by health tech start-up companies in working with Health Systems and
offers advice on how to recognize and address each. From approaching systems
with a solution-first mentality to not understanding the context in which
health systems work, we look to provide constructive criticisms meant to
support more effective partnerships between health systems and digital tech
and Reactions from the Industry
Understand the Current System Environment We Are Working In: In some cases,
technology solutions are barricading healthcare systems inside. In other
cases, they are allowing us to seamlessly interact with other systems. Typically, large healthcare systems have a
combination of both. For outside solutions to be effective,
start-ups need to be intimately familiar with the existing (and on-the-horizon)
systems that healthcare organizations are using or contemplating. Rarely
will a solution not have to interact with existing software solutions – and
this goes well beyond just the EMR.
Have an Integration Plan: A
stand-alone solution, which doesn’t tie to one or more of the healthcare
institutions key systems of record (SoR) or systems of engagement (SoE) is a
useless solution. Your solution should be able to stand alone in the first few
weeks, as users begin to use it and get familiar with its capabilities.
However, as soon as value is realized
(not necessarily achieved), it’s crucial that your solution support either SMART on FHIR, FHIR,
HL7v2.x, or all of the above. If you don’t have a believable integration story
fully worked out, you’re not ready to launch into the health system market. Go
back and do your homework.
Having a Clinician Is Nice, But Not Enough: The physician, nurse, or other clinician on your team helps credibility but we also understand the incentives associated with selling solutions, and this takes away from the altruism you think we will blindly swallow. And they are rarely businessmen or women who understand both the complexities of solving a problem that isn’t theirs and starting, let alone, running a company. Pair an MD with an MBA? Now we’re talking.
Start-ups are an increasingly important “node” within the
healthcare ecosystem. They are challenging status quo concepts that have
long been ingrained in the healthcare system, like questioning the value of
traditional EMR systems, or shifting the power of information to patients, or
breaking down cost and quality transparency barriers. They may be the future of
the industry, but startups have a long way to go to truly transform the
system. The reasons are many, from an incredibly convoluted and bureaucratic
review process and rigid risk-controlling regulations and policies, to the
large-scale organizational inertia most of our healthcare systems have.
And while all of these hurdles can and will be overcome if we work
together, there are still several lessons each “node” in the ecosystem can learn to more effectively work with each other.
This article is directed at the emerging digital solutions trying
resiliently to help transform this stubborn industry. It provides some critical
lessons in dealing with healthcare systems and is accompanied by reactions from
a digital solutions expert with serial digital health entrepreneurship
experience. We hope to provide perspective from two people living and
breathing, and surviving, from both sides of the
equation every day.
and Reactions from the Industry
Healthcare Startups Must Understand how Provider
Systems Operate: Most
health systems are increasingly becoming rightfully skeptical about new
solutions because they feel the solutions don’t understand the environment of
their system. To help overcome the challenges of introducing your innovation into a complex business and
clinical environment, startups must understand how health systems operate to
include how they make decisions, contract and evaluate solutions.
Recognize that Decisions are Consensus-driven and Permissions-based: Unlike
other industries, where “shadow IT” is rampant and there can be one or two “key
decision makers,” in health systems you’re not likely to get very far without
figuring out how to build consensus among an array of influencers and then
figuring out how to get permissions from a group of key decision makers. You
should seek a “Sherpa” that understands enough about your solution to champion
the idea of change – which is really what you’re seeking when you’re
selling a new solution (the solution is just the means to accomplish the change,
it’s the change that’s hard). The first thing to focus on is to identify the
group of decision makers and how you convince them that the status quo should
be abandoned in favor of any change –
then, once you know how to convince them of some
change you’ll work with the group to get the right permissions to work on the
change management process – which will then influence a purchase of your
The authors of this article like to believe that we can remain humanists while transitioning from a paper-native to a digital-native industry. We even believe you can remain a humanist while following regulations and sticking to industry guidelines. Margalit Gur-Arie doesn’t seem to feel that way. We have read her work over the years and established that she takes a staunchly humanistic approach to health IT. But even though she’s a leader in that space, she appears to doubt the contributions that either technology or regulation make to a humane health system.
Gur-Arie’s most recent posting dismisses all the tools that electronic health records throw in the way of the doctor: clinical decision support (now often called evidence-based medicine–were we Gur-Arie, we’d say it’s because who can argue against evidence?), reminders, pull-down menus to provide a limited range of choices, and more.
One immediate response is to suggest that, instead of blaming the tools, one should blame the requirements imposed on clinicians by payers and governments–the “thousands of meaningless regulatory words” as Gur-Arie writes eloquently. But the real answer is that these requirements (well, the ones that were thought through) enhance the health care system, and that the problem with current EHRs is that they just “pass through” the requirements, intensifying the burden placed on doctors, instead of finding true innovations when implementing those requirements.
Last week I was invited to attend the second annual NIST forum for EHR Usability called “A Community-Building Workshop: Measuring, Evaluating and Improving the Usability of Electronic Health Records.” NIST, in collaboration with the ONC, unveiled its initial discussion points for what it might consider as the “Usability Criteria” in the upcoming Meaningful Use Stage 2 regulations. At the event I met with Dr. Melanie Rodney, Distinguished Researcher at Macadamian and a member of the HIMSS Usability task force; I was impressed by the work that she and her firm were doing in EHR usability space. At the NIST forum I was able to spend time with experts in the both the fields of EHRs (like me) as well as in usability and user experience (like Melanie). We learned that the government believes that while usability can be key in increasing product effectiveness, speed, enjoyment, etc., NIST is going to focus on EHR usability for the improvement of patient safety. I asked Melanie and Lorraine Chapman, Director of User Research at Macadmian, to share with us what we in the EHR technical community should do in light of what we learned at the NIST forum last week. Here’s what Melanie and Lorraine said:
While the specifics are still forthcoming, vendors have a window of opportunity today to get ahead of NIST – and ahead of competitors – by proactively addressing meaningful use in advance of the 2013 deadline. Let’s look at what vendors can do, combining the information NIST has given so far with fundamental usability best practices:
Step 1: Set Usability Goals related to Patient Safety
These are specific, measurable goals such as “Our EHR must provide a 99% error-free rate of medication entry”. NIST has given the following examples of use error categories, each of which might be driving 1 or more goals.