Process Insights and Recommendations by Nick Steinwachs

Successfully developing and delivering interoperable IT solutions in Healthcare Provider Organizations is difficult. The HIT 9, a set of guidelines presented below, are here to help you navigate the challenges and bring your products and services into the Healthcare marketplace.

The Problems We Are Solving

HIT is not all about technology. There are many non-technical considerations within the current paradigm used for bringing novel HIT solutions to market: I am talking about having a strong go-to-market strategy, leveraging exquisite service design, and optimizing on implementation. 

Over the years, I’ve witnessed many healthcare IT organizations –big and small– skip crucial steps within the product design process. Every time this happens, the likelihood of failure increases: organizations typically encounter unforeseen costs (time or money), unhappy customers, frustrated investors, and might even end up closing their doors.

Companies seeking to deliver novel HIT solutions will often underestimate the length of sales cycles, the costs and complexity of bringing their products to market, and can sometimes have a narrow perspective on the design process. John S. Toussaint writes about this very host of issues, and how talented designers and business leaders coming from commercial B2C markets vastly underestimate timelines in healthcare startups. All of this can cause investors to pull the plug before the solutions see the light of day.

An ecosystem as large, complex, and dynamic as healthcare presents innumerable challenges to new products and services coming to market - some that can be seen ahead of time, and others that can’t. We need to design and build delightful products and services, and bring them to market in a commercially viable timeline.. So how can we do it?

Process Insights & Best Practices

This article outlines an applied product-thinking approach to bringing interoperable solutions to market in the healthcare ecosystem, and by the nature of collaboration, inclusivity, and some humble foresight, will demonstrate ways to avoid failure and manage risk along the way.

Implement the following HIT 9 Tips as practices within your product process, and adopt this mindset in your product thinking. It will help reduce the friction often associated with bringing products and services to bear.

The HIT 9 Nine Tips on Process for Market Fit through GTM

1. Work toward a Convergent problem statement: This is a non-trivial step in any product design (see Groundwork). In healthcare, the cost of conducting scrappy research to understand the problems you want to solve is often higher than in other markets. Doctors and healthcare providers are not always so accessible, and bringing necessary clinical insight into your problem definition is difficult. 

With interoperable solutions, start with this notion to guide your thinking in the problem domain: information and insights are not getting to the right people and places when they’re most needed. Work with users and business stakeholders to identify one or many problems to be addressed with the product and service (enabler).

• Ex: Quality measure data submissions are burdensome for clinics and EHR vendors to perform or implement when changed.
• Ex: Providers may miss important care planning steps that may lead to higher-quality patient outcomes, but are not made aware of these omissions at the point of care, leading to higher costs and suboptimal patient care.

Part of this step is determining the value of solving your problem with your business stakeholders, and how aligned that value is with those who would pay for it? For example, if your value prop is focused on quality improvement, aligning with preexisting or planned value-based reimbursement structures or novel care models is paramount. If you’re focused on cost reduction in clinics, the up-front costs of implementation and change management are going to be a major burden. 

2. Develop relationships with the right clinical partners (and HIT vendors as necessary): Isolation in healthcare product management and business strategy is dangerous from a number of perspectives:

First, the provision of healthcare involves a complex, interconnected ecosystem. Interoperable healthcare systems cannot be designed in a vacuum. Clinics’ operational and clinical workflows will vary from organization to organization. The impressive IT Infrastructure in one clinic might not exist at another. And if it does, it's unlikely they will be a mirror match. Cloud services will vary. On-premises configurations will vary. Same goes for resources, budgets, talent, and an organization's ability to adopt and adapt to change and scale. Furthermore, there are already myriad differences between EHR Vendors, including "their" ability to adapt and change.

Disregarding the need to co-design your product and service with users will lead to poorly set expectations. This can cause unforeseen costs when upset stakeholders and disappointed customers provide feedback that requires amelioration within your market deliverable. All of these variables and assumptions in the design of a product or service will need to be understood before you can scale. It also factors into how you balance your focus on service capabilities vs. product features and configurability… which brings me to the second perspective:

There are gatekeepers to entry into the healthcare market. EHR vendors, and regulatory agencies. A meaningful relationship with an EHR vendor is often predicated on a healthy relationship with at least one of their customers, and those customers and their EHR vendors are already accountable for meeting the requirements of regulatory bodies. To deliver the value you believe your product or service holds in a commercially-viable timeline, you need to work within the constraints of the EHR vendors of your initial market, and be compliant with regulations – barring a truly disruptive technology that would transcend the healthcare space, these might as well be immutable laws of physics. All parties affected by your product should be involved as early as possible in the development of your systems.

Many healthcare providers want to avoid being early adopters of technology, but everyone wants to reduce their costs or increase revenue before their competition does. To execute on this step, you must have something of value to offer, or otherwise have interests aligned. If you’re a HIT vendor trying to get off the ground with a new product or service, you may need to offer your product for free, or at cost, to your clinical development partner for some period of time. The ROI comes in the following forms:

• Rapid product feedback
• Positive word of mouth, endorsements, and references
• Trust and willingness to partner and experiment more

If you need a provider partner who has infrastructure and leadership to help support the development of innovative solutions, consider looking to academic medical centers with strategic investment funds, or other organizations with reputations for innovation.

Having a provider partner that can shortcut your path toward EHR (and adjacent systems) integrations while providing clinical and operational insights will lead you to success.

3. Identify the Clinical Champion: For your project you are going to need a single POC (point of contact) with appropriate clinical chops. Someone who can guide you through planning and communications, and who passionately believes in the project’s value. This clinical champion will have shared accountability to the success of your program, and you will be accountable for their reputation. To those ends, your goal is to make the clinical champion look good.

Here are some qualities to look for in your clinical champion (that are not comprehensive)

• They are respected by administrators and providers alike.
• They’re likable, and good communicators.
• They are likely to stick around in their organization for a long time.
• They’re passionate about their patient care.
• They’re empathetic toward their colleagues.
• They are process-oriented.
• They’ll benefit directly from your proposed product / service’s value proposition.
• They still practice / see patients.
• They don’t see so many patients that they don’t have time to devote to informing your product direction, testing, and providing feedback.
• They’re willing to take risks.
• They have a healthy degree of skepticism – they make you earn their trust, and rely on data and evidence before buying into any proposition of adding value to their practice.

If you can’t find a good clinical champion, it’s worth asking yourself some hard questions. Do I have the right clinical partner, in general? Does my partner provide enough value in other areas to make up for the risk of not having a good clinical champion (e.g. investment capital, vendor relationships)? Only you can answer these questions, but think about the maturity and potential complexity of your product when you do. If you’re trying to be embedded in clinical workflows with widely-varying clinics, the answer is likely to be “no”, and you should prioritize finding a partner who can champion your offering.

4. Prioritize evolvability and speed of development: Making decisions around technical architecture of your HIT solution early in its development can be difficult. Often these decisions are akin to Type 1 decisions - difficult to make amidst ambiguous requirements, and very expensive to reverse once made. However, your first priority should be to get something valuable in the hands of your customers without accruing insurmountable heaps of tech debt that will sink your ship later on. How do you do this without getting bogged-down with complex technical decisions that you may not have the resources nor expertise on hand to make?

Concert Health solved this dilemma by using Salesforce as their back end infrastructure while they quickly learned, grew, and scaled. The flexibility, ease of configurability, and data transparency Salesforce provided vastly outweighed the costs of the software licenses and other performance and long-term scalability tradeoffs. Tasks like building product metrics dashboards, which would typically require a team of software developers significant time to build, test, and iterate on, could be done relatively quickly by fewer developers, or even by non-technical or semi-technical resources. This decision lowered the cost and risks of iteration, and democratized product data in their organization. As a result, they were able to quickly build their product, and prove its value without ballooning their costs of maintenance and engineering.

5. Define your MVP. Use it to inform your MVS: How can you deliver value to your clinical partners as quickly as possible and learn from the experience? Answering this question needs to be a collaborative effort between your organization and your clinical partners. Keep in mind the following things:

• Focus on the right problems. This is product management 101: Do everything you can to focus on solving the smallest, most common, and most valuable problems you can. Consider using humans or non-technical services to address adjacent problems before you spend time developing a more configurable technical solution. It’s likely that you don’t yet know enough to design those configurations. And if you do, is that where you should be spending your time? You’ll learn more about what’s most important by getting people to use it.
• Quantify success with key success metrics. Your MVP is effectively worthless to your prospective customers if you can’t measure its efficacy in delivering its stated value. These metrics should be super clear, and reported by the users themselves. “Did the product [deliver the stated value]?” Yes / No

These shouldn’t be vanity metrics, but should still be viable for marketing purposes: you want the ability to quote your metrics within your marketing materials, so it will sell your product for you. Further, you won’t know how successful your product is without it.

• Clinical Partners. Your clinical partners are focused on the provision of patient care. Be judicious in the use of their time, and, to those ends, be your own worst critic. This practice will serve to build trust with your partners.
• Be transparent. Come to them with solutions, but don’t gloss over the associated risks and ways to mitigate those risks. Predict their questions and concerns before they are asked. Demonstrate that you are putting yourself in their shoes.
• Listen. If your clinical partner highlights shortcomings in your approach, and you don’t agree with them, you’re (a) not a good listener, or (b) you didn’t communicate your approach and what they’re expectations should be effectively. Be an active listener when they provide feedback regardless of how the feedback is delivered. They are the experts until you’ve implemented your solutions at hundreds of clinics.

6. Plan for the delivery of your solution: Better to under-promise and over-deliver. Be conservative on the amount of time necessary on both your side and theirs. Consider a factor of 2:1 or even 3:1 (actually necessary : what you think you will need). Be empathetic with your partner’s need to manage change with their staff and processes.

• Crawl-walk-run / friends-and-family-first approaches are the only approaches that are viable and will get the commitment of early clinical partners. Stage the delivery through small, seemingly insignificant increments that build cadence and consistent progress toward your end vision.
• Communicate a project plan, and get their feedback.
• Require a formal sign-off on the project plan, along with an explicit allocation of resources necessary to execute.
• Acknowledge that you will uncover new requirements and challenges at each stage of implementation. It’s the truth.
• Establish the lines of communication for technical and business stakeholders. The more collaborative, the better. Cross-org Slack channels promote collaboration and increase team performance.
• Customer success / Implementation managers who are not overburdened, are properly trained, and possess excellent communication skills will be enablers of success all-around. They should be brought into discussions with your partner well in advance of the execution phase to help plan for success. Make them accountable for the health of the relationship with your partner.

7. Execute your plan: You need to be the project manager for your organization, your clinical partner’s, and maybe even the vendors involved. Do not assume that they will manage their resources to ensure success. All you can do is communicate risks early and often, and ensure that all stakeholders are apprised of the project’s progress. Meet regularly with your clinical champion - bad news takes the elevator and good news takes the stairs.

• Document the clinic-side implementation process. Every subsequent customer and user will want these insights and understand what it means to implement your product or service. Ensure the technical, clinical, and operational steps, difficulties, and delays are captured as much as possible.

8. Monitor and share your success metrics: Success of early-stage interoperable healthcare systems requires strong clinical leadership, support, and change management. As the systems mature, so too does the implementation process, technology, and user experience. Strong clinical leadership at your partner-clinics becomes less and less of a factor in their success. Leverage your relationships with your clinical champions to ensure your early implementations are a success while you build market momentum.

9. REPEAT steps 1 through 8 with more clinical partners. Your reputation as a good vendor-partner is your biggest asset. Use your judgment for when you can cut costs by standardizing and dictating approaches, and where you will need to retain flexibility. As the saying goes, once you’ve seen one clinic, you’ve seen one clinic. Be OK with being surprised by your users.

And there you have it. 9 pieces of silver for your time. 9 guidelines that will help you identify what failure actually looks like so you can avoid it.   

BONUS: A note on Managing business stakeholder expectations as an HIT vendor:

This can be tricky with novel HIT solutions. Solving problems in healthcare (and getting paid) is both time-consuming and expensive. If done correctly, the benefits are that solutions in healthcare become very sticky, and will often result in helping a larger number of people. The goal is often to keep the scope small and costs down until you find ideas and concepts that work. Your goal gradually transitions to ideas and concepts that both work and scale, which means more technology and complexity, which means more costs. Nothing seems to move quick enough, including sales cycles and implementations, and isolation in a highly-connected ecosystem is dangerous. But, if you can identify strategic partnerships earlier, all processes will see increases in both speed and agility.

…All this means is, if you are projecting hockey stick revenue growth curves at your HIT solution board meeting, you may be misleading your stakeholders.

Contact Bellese for help with your product strategy and discover what we can accomplish together!

Definitions for Your Reference:

• HIT: Health information technology. We’re using this as a catch-all for solutions or vendors that help move, surface, or translate information to healthcare service providers.
• EHR: Electronic Health Record system / vendor. Epic, Cerner, Athena, etc. If you’re developing interoperable products, you might also substitute ideas of other systems of record as you read, e.g. LIMS (Laboratory information management system), PACS (picture archiving and communication system), HIE (health information exchange), etc.
• Provider: Clinicians, doctors, nurses, etc. People who provide clinical care to patients, or directly support those who do.
• Provider organization: a generalized term to encompass all kinds of organizations that provide some parts of healthcare to patients. For example, FQHCs, Hospitals, ASCs, ACOs, Healthcare Systems would all be included in this term.
• Administrators: Managers, front- or back-office staff, and leaders of healthcare provider organizations who help govern processes and procedures that impact their organizations’ clinical quality and outcomes, revenue, profitability, etc. Often in provider organizations, senior-level providers often play a dual role as an administrator, practicing medicine and treating patients while managing operations.
• MVP: Minimum Viable Product
• MVS: Minimum Viable Service