“Maps are like campfires — everyone gathers around them, because they allow people to understand complex issues at a glance and find agreement about how to help the land.”
Sonoma Ecology Center, GIS/IS Program Web Site
The Age of Transformation
It seems like every Canadian healthcare organization is involved one type of transformational initiative or another. The creation of Health Teams in Ontario, the Clinical and Systems Transformation project in BC, and Canada Health Infoway’s ACCESS 2022 are three examples of large-scale initiatives that ultimately seek to improve patient centred care.
The potential of these initiatives to improve the patient experience of care, improve the health of the population, and lower the per capita costs of care is enormous. However, a significant amount of work and applied nuance lies ahead in order to provide return on the considerable financial and resource investments. The purpose of this article is to examine the importance of disciplined business model creation efforts when delivering high value use cases that rely on multi-stakeholder adoption and integrated digital health solutions.
Imagine that you’re about to embark on a road trip from Victoria to Halifax for a friend’s wedding. You need to arrive on time, and you don’t have unlimited funds to get there. You could start driving East with the best intentions of getting there, but the likelihood that you arrive hurdle-free and on time is incredibly low. But input the exact coordinates of your destination into your GPS and you’re prompted with a wealth of information (ferry times, road closures, anticipated traffic volumes, toll ways, etc.) that allow you to plan your trip accordingly and pivot along the way if needed.
Developing and implementing transformation projects is remarkably similar. The more discipline you apply in continuously acquiring detailed information about the environment, stakeholders, roadblocks, incentives (and disincentives), the more likely you are to build business processes and technology that can successfully navigate around barriers and solve sticky problems.
When Trailblazing Leads Us Astray
Microsoft HealthVault recently announced that they will be ending the 10-year health record service line on November 20th, 2019 (1). MS HealthVault failed to achieve critical levels of adoption, following the path of Google Health which closed in 2012. Critics of these “too big to fail” eHealth platforms believe the products were disconnected from their users; failing to adequately address existing patient/provider workflows and reimbursement patterns as well as offer patients meaningful insights or convenient alternatives to the status quo (2)(3)(4).
Canadian Health IT initiatives aren’t immune to building leviathan systems that are put at risk by unmet user needs, market changes, and lack of buy-in from stakeholder groups. The challenges encountered by these initiatives are rarely attributable to the strategic vision. No one is going to argue that patients shouldn’t have access to their data or that systems shouldn’t be integrated to improve care transitions between organizations. The challenges start to surface in the “how are we going to get there?” stage.
Charting an Eastward Course
Transformational initiatives have broad scopes and require large numbers of stakeholders to change current practices in pursuit of common goals. The logical next step for dealing with anything complex is to break it down into manageable components, often in the form of several high value use cases.
In the world of citizen access to health data, access to lab results is a common use case to start with. Giving citizens electronic access to lab result information is a promising avenue to reduce duplicative testing and increase patient self-management (5)(6). At face-value, lab results seem an obvious destination for citizen access work. Consider, however, that successful delivery at scale requires simultaneous delivery on the value propositions required for patients, providers, community and hospital lab facilities, numerous different vendors (e.g., lab information systems, personal health records, etc.), and operators of provincial repositories, to invest in the use cases. Careful compromises will need to be made to gain initial adopters while balancing the need for technology designs and business models that can scale. A successful approach will need to address all these and more…with algorithmic-like precision.
So how do we move forward when there are so many challenges that lie ahead? We start by recommending the creation of a carefully calibrated business model that forces us to define and validate a narrow set of use case(s) that will deliver the highest return on investment at the lowest barrier to entry.
A successful business model canvas includes (7):
- Key Partnerships: The people and organizations that will need to provide buy-in for the project to be successful, as well as those that will provide inputs and resources required to gain buy-in
- Key Activities: The critical activities/actions the project needs to perform
- Key Resources: The assets required to offer and deliver on activities
- Customer Segments: The people, roles, and organizations that the project is intended to provide value and mitigate pain points
- Value Proposition: The benefits each customer segment receives from interacting with the project/solution, typically has its own canvas that maps the customer profile (gains, pains, jobs) to product fit (gain creators, pain relievers, products and services)
- Customer Relationships: The type and nature of the relationship between the solution and each customer segment, e.g. transactional, long-term, self-service, human interaction dependent
- Channels of Outreach: How value propositions are communicated to customer segments
- Cost Structure: The direct and indirect costs incurred to operate the proposed business model
- Revenue Streams: The financial inputs that allow the proposed business model to operate
Two common mistakes projects make when working through the business model canvas is: 1) assuming that the individual entities in a stakeholder group have homogenous needs and motivations; and 2) failing to ask the individual entities the hard questions.
To illustrate this point, imagine an eReferral initiative that requires integration with primary care EMRs in the region. One EMR vendor could have secured new venture capital and is actively looking to grow its customer base with new features, another vendor is in the midst of an amalgamation and wants to minimize change during the multi-year transition period. Product architectures and roadmaps, quarterly sales targets, strategic plans, revenue models, and competing customer demands are unique to each vendor and have a big impact on the near-term and ongoing incentives they would require to participate in the eReferral initiative. The same type of analysis can be applied to the physicians and specialists using the EMRs, as both groups have different revenue and cost models that will lead to distinct benefits and incentives. Understanding these differences is critical to selecting the integration approach and overall business model that will position the initiative for success.
Once the motivational differences of entities within stakeholder groups have been identified, the next step is to ask the hard questions that people might not want to hear the answers to. Critical questions include: “Would you invest your own money in this? What would you give up for this? Are there other products or services you need more than this?”. These questions help differentiate between the products and services stakeholders see as “nice to have” versus “must have”, and help ensure the business model and technical approach survive contact with reality.
Business model canvasses help us map the particulars of the targeted environments as well as the ways in which the proposed use cases will impact those environments. A use case requires additional design iterations if it’s missing gain creators or pain relievers that are critical for customer segments to participate.
When no amount of re-configuring can produce a viable evaluation of a business case, it’s appropriate to move-on to a different use case and keep re-iterating until a viable business case and technological approach evolves.
One applied methodology that puts stakeholder evaluation and buy-in at the root of statewide and national use case design is Michigan’s Health Information Network Use Case Factory™. The Use Case Factory has four distinct stages: Conceptual Design, Planning and Development, Implementation, and Adoption. Stakeholder sign-offs act as gateways between each stage, enabling more complex use cases to go through multiple iterative cycles (8).
One strength these methodologies is the commitment to identifying direct and indirect costs/gains for impacted stakeholder groups in the earliest stages of conceptualization. Having a good design process is not a guarantee of success. A successful model delivers a platform for participants to provide candid information about what levers need to be in place for their individual participation. These levers can be technical (integration with a particular vendor), financial (offset implementation costs, insurer-driven incentives), and relational (member-driven participation). Understanding each potential participant’s adoption trade-offs and combining them into a configuration that is technically and financially viable for all those involved, is difficult but critical work.
Designing and delivering transformation initiatives within a narrow set of use cases or geographies is difficult; ensuring the business model and technological approach can appropriately scale is even more challenging. The desire to build momentum by just moving in one direction is understandably tempting, but the idiom of “putting one foot in front of the other” can actually create significant downstream risks to projects of this size and complexity. We stand a much better chance of reaching our destination if we take the time to collaboratively map how our course will navigate through intersecting environments, competing interests, and collective hurdles.
(1) Foley, Mary Jo. “Microsoft Is Closing Its HealthVault Patient-Records Service on November 20.” ZDNet, 5 Apr. 2019, www.zdnet.com/article/microsoft-is-closing-its-health-vault-patient-records-service-on-november-20/.
(2) “10 Reasons Why Google Health Failed.” MobiHealthNews, 1 Dec. 2015, www.mobihealthnews.com/11480/10-reasons-why-google-health-failed.
(3) “Why Google Health Really Failed-It’s About The Money” TechCrunch, 26 June 2011, techcrunch.com/2011/06/26/why-google-really-failed-money/.
(4) Truong, Kevin, and Kevin Truong. “Microsoft HealthVault Is Officially Shutting down in November.” MedCity News, 18 Apr. 2019, medcitynews.com/2019/04/microsoft-healthvault-is-officially-shutting-down-in-november/.
(5) “Connecting Patients for Better Health: 2018.” Canada Health Infoway, https://www.infoway-inforoute.ca/en/component/edocman/3564-connecting-patients-for-better-health-2018/view-document?Itemid=0
(6) Kaelber, David, and Eric Pan. “The Value of Personal Health Record (PHR) Systems.”, https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2655982/
(7) Osterwalder, Alexander, and Yves Pigneur. Business Model Generation: a Handbook for Visionaries, Game Changers, and Challengers. 2010.
(8) “MiHIN 101.” MiHIN PR Slideshare Website, Apr. 2015, https://www.slideshare.net/mihinpr/mihin-101-overview-v4-04-0815. Slides 15-23