The HIT 9

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).

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:

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)

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:

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.

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.

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.

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:

Written by