Abstract
Why couldn’t a Norwegian e-health firm replicate a successful digital application across two hospitals with similar functional needs? This teaching case follows TechCo, a mid-sized Norwegian e-health provider, as it works with two hospitals on a similar digital blood sampling workflow. Hospital E partnered closely with TechCo to co-develop the system. Hospital W, despite a comparable starting point, chose to develop the system internally. The case invites students to examine how digital service providers engage public-sector customers who hold deep workflow knowledge but rely on external partners for technological depth. As TechCo’s CEO prepared a strategic review, he questioned whether the company’s current way of engaging with customers still fit how public-sector hospitals wanted to work with digital suppliers. Through this contrast, the case asks why customers with similar functional needs may want to engage suppliers in fundamentally different ways, and how a digital service firm should adapt its customer engagement and delivery approach. The case draws on interviews with TechCo employees across organizational levels and with hospital representatives, supplemented by industry reports, tender documents, and company materials.
Setting the scene
“I just don’t understand why we can’t sell a ready-made system to others who need almost the same thing,” said Anna, a UX designer at TechCo who had worked on the digital blood sampling solution previously developed for Hospital E, after learning that Hospital W had declined to adopt a similar system.
Her remark stayed with Ben, TechCo’s CEO. The two hospitals operated in similar contexts, used the same electronic health record system, and had described overlapping needs. Yet, their procurement decisions had diverged: Hospital E partnered with TechCo to co-develop a solution, while Hospital W chose to build a similar system internally. Anna’s comment caught something Ben had been wondering about himself: whether people across TechCo had come to think of their business as selling standardized products, assuming that hospitals with similar needs would buy the same digital solution.
TechCo, a Norwegian e-health solutions provider, developed digital applications to improve clinical workflows in hospitals and municipalities. Its customers shared many operational needs but differed considerably in how they wanted to engage with external suppliers. As Ben prepared TechCo’s next strategic review, he needed to reconsider whether it was the case that customers with similar needs wanted to be approached in a similar way.
TechCo: Company background and internal organization
TechCo originated as a division of an industrial technology company founded in the early 1990s and began working with the healthcare sector in 2003. By 2025, the company employed more than 100 professionals across a range of technical and commercial roles, including product owners, system engineers, salespeople, developers, application specialists, testers, and designers. TechCo had collaborated with 80% of hospitals in Norway to deliver complex solutions, and had subsequently expanded its operations internationally.
Overview of TechCo’s digital healthcare solutions.
Source: Author-created based on public company information.
With three decades of experience, TechCo had developed deep knowledge of the Norwegian healthcare system and maintained long-term relationships with several hospitals. Much of this work focused on digital infrastructure and workflow optimization. TechCo placed strong emphasis on customer retention, continuously improving its systems based on user feedback to align with evolving clinical and administrative needs.
Internally, TechCo’s marketing, sales, and solution delivery processes were structured across distinct yet interrelated departments. TechCo’s standard way of organizing work followed a linear sequence across its departments, with each function entering the project at a particular point. The marketing team was responsible for building awareness and educating potential customers about TechCo’s offerings, the sales team ensured that proposed solutions were aligned with the customer’s needs and implementation capacity, and once a contract was secured, the engineering team took over to develop tailored digital systems with end-users. Co-development at the user-facing stage was a long-standing strength of the company, applied after the project’s broad shape had been set through procurement and project definition.
While this model ensured specialization and clarity in task allocation, it also created coordination challenges. Teams often brought different professional backgrounds and priorities. Marketing and sales staff focused on client relationships and business fit, while engineers prioritized technical feasibility and performance. As with many IT projects, no single actor had complete visibility into the entire development cycle. Cross-functional collaboration was necessary—yet difficult.
TechCo had delivered many projects, but not every engagement went smoothly. According to TechCo’s experience, some of the challenges arose from how hospital procurement and daily clinical work were organized. The people who served as the primary point of contact during procurement were often not the actual end-users of TechCo’s digital solutions—such as nurses, doctors, lab technicians, and ambulance personnel. As Anna put it: When you get a lot of people who either sit at some sort of configuration level or who don’t have any clinical experience, it’s easy to miss what the actual needs are for the people who are going to use the system.
This indirect engagement often resulted in less specific or evolving requirements by the time engineers and UX designers began implementing them. This complexity made it critical to build strong working relationships—not just with institutional buyers, but also with the clinical professionals using TechCo’s systems in their practice.
In internal discussions at TechCo, Anna remembered that Ben often emphasized the importance of early involvement with end-users to reduce misalignment. He believed that “the closer you get to a real situation, the more you learn and the fewer assumptions you need to make.” Deeper, earlier conversations with clinical stakeholders, he argued, would help TechCo anticipate needs and shape solutions that integrated more smoothly into everyday workflows.
Healthcare system in Norway
Norway’s healthcare system created a very particular kind of market for digital suppliers like TechCo. The system operated under a model broadly aligned with the Beveridge system, where healthcare was primarily funded through taxes and both financed and delivered by the public sector. Citizens had universal access to healthcare services, and hospitals were publicly owned and operated.
Procurement and governance, however, reflected a decentralized structure. Norway was divided into four regional health authorities (RHAs)—Southern, Northern, Central, and Western Norway—each responsible for planning and managing healthcare services in their respective regions. Together, these RHAs jointly owned the Hospital Procurement Group (Sjukehusinnkjøp HF), a centralized agency that helped streamline national and regional purchasing. Although the Hospital Procurement Group provided standardized national frameworks and coordination, individual hospitals still retained significant autonomy in procurement decisions. In practice, they often chose solutions based on local infrastructure, digital capacity, and specific user needs, even when a centralized contract or shared solution was available.
Since the COVID-19 pandemic, Norway had actively embraced digitalization in healthcare to handle societal challenges such as the shortage of healthcare personnel and the need to improve service efficiency. Many hospitals established internal ICT teams to manage and implement digital systems. In such cases, hospitals with well-developed in-house ICT capabilities might prefer to keep selected projects internally rather than involving external suppliers, even when external solutions were available.
Decentralization also influenced how customization was handled. Procurement in Norway was governed by strict transparency rules: all tenders were published on the Doffin platform, a centralized portal for public-sector purchasing, allowing suppliers open access to bid opportunities. At the same time, hospitals could request minor adaptations to existing solutions without triggering a full formal process. Digital systems also had to remain interoperable and adaptable, as hospitals continuously upgraded their digital environments. From TechCo’s experience, suppliers with rigid, proprietary systems tended to struggle under these conditions, which helped explain why large international suppliers with standalone systems and limited local flexibility often found the Norwegian market difficult to navigate.
While large multinationals were less visible in the Norwegian e-healthcare market, TechCo increasingly faced competition from small specialist firms that offered add-on functions or niche applications on top of the digital infrastructure TechCo had already delivered to hospitals.
Overall, Ben and his team perceived the level of competition as moderate to low. Norway’s relatively small population and heterogeneous demand—with hospitals and municipalities seeking modest-scale, tailored solutions—meant that many IT projects were not lucrative enough to attract the largest international suppliers. As a result, suppliers tended to specialize in specific service areas or regions, and competition occurred more through differentiation and relationship-building than through price wars or standardized solutions. This market structure shaped how TechCo positioned its own value proposition: emphasizing flexibility, local expertise, and long-term collaborative delivery.
Blood sample application: The different choices of hospital E and hospital W
In 2020, Hospital E issued a tender for a digital system that could track and control each step of the blood sampling process. The progress plan in the tender documents set a very tight schedule: the competition was announced on 18 February 2020, the tender deadline was 13 March, and delivery was expected to start in early May (Exhibit 2). Albeit the project was relatively small, such a compressed timeline confirmed that only suppliers who already understood the hospital’s digital environment and workflows could realistically commit to the project. Tender Timeline for Hospital E Blood Sampling Application (2020). Source: Author-created based on Tender document.
TechCo won the tender and delivered the digital blood sampling application for Hospital E. The system, developed to track and control each step of the sampling process, was co-created with healthcare staff and integrated into the hospital’s digital infrastructure. A dedicated TechCo team worked closely with end-users—lab technicians, nurses, and other clinical personnel—to ensure that the system aligned with actual workflows and performed reliably in daily operations. Together, they mapped existing routines, tested prototypes on the wards, and adjusted the design until it fit daily practice. By the time the system went live, it was fully integrated into Hospital E’s existing digital infrastructure and had been refined through several rounds of user feedback. Internally, Ben and his colleagues regarded the project as a great example of how collaborative solution development with a hospital.
When Hospital W later initiated a similar digitization effort for its blood sampling workflow, TechCo saw the potential to adapt the Hospital E system. The two hospitals used the same electronic health record (EHR) platform, and the blood sampling application developed for Hospital E had been designed to seamlessly integrate with the EHR environment. Given this compatibility and TechCo’s existing history of cooperation with Hospital W, the sales and engineering teams proposed reusing and modifying the existing solution to meet Hospital W’s needs. Steve, the manager of innovation and digitalization at Hospital W, was aware of the project that TechCo delivered to Hospital E. He initiated conversation with TechCo team regarding the possibility of working with TechCo regarding their project.
During early discussions, Steve raised concerns about specific workflow differences and infrastructure compatibility. Clinicians at Hospital W expressed a need for a more flexible process than the one designed for Hospital E. TechCo offered to tailor the system accordingly, but the proposed delivery still followed the company’s traditional model—where TechCo would design, implement, and maintain the full solution. Hospital W declined this proposal, signaling that it preferred to develop the system internally.
Recognizing the strategic importance of remaining involved with Hospital W, TechCo proposed alternative arrangements. The sales team offered flexible engagement: TechCo could contribute selectively to specific stages of the development process based on Hospital W’s needs, rather than taking on the project as a whole. The specific shape of this involvement, including which stages, what scope, and how to coordinate with Hospital W’s internal team, was left open and would be defined together with the hospital as the project unfolded. Steve declined this proposal as well. From his perspective, the project needed a short path to a working prototype, and an in-house team with direct access to clinicians could move faster than a flexible arrangement that would require ongoing coordination with TechCo. Hospital W proceeded with in-house development, relying on its internal ICT team, without issuing a public tender. Steve explained his rationale: Clinicians had lost faith that things could be done quickly and smoothly—our big digital projects took up to ten years and some never really finished. To restore that trust, we need a very short path to a working prototype.
He further clarified how he wanted to work with staff during development: We want developers to avoid disrupting clinicians’ daily work but still make them feel they had their hands on the wheel—they had to decide whether we were moving in the right direction.
Steve believed that the internal ICT team had better access to the actual users—clinicians—which enabled a more user-oriented development process and a deeper understanding of the hospital’s internal digital systems than TechCo could match for this particular project. TechCo’s strength was its technical depth and cross-hospital experience built up over years. For the blood sampling system, however, Steve judged that workflow proximity mattered more. The final delivery was as broadly in line with Hospital W’s expectations.
Reflecting on the decision, Anna, the UX designer who had worked on the Hospital E project remarked: I just don’t understand why we can’t sell a ready-made system to others who need almost the same thing.
Anna’s comment indicated that, despite TechCo’s willingness to tailor its systems, many employees still assumed the current solution as the baseline and looked for customers whose requirements matched it.
Over time, Steve came to view the decision somewhat differently. He noted that the blood sampling project had indeed strengthened Hospital W’s internal ICT capabilities, but he also began to question whether full in-house development had been the best long-term choice. Hospital W’s ICT team had grown, but it was still a hospital ICT team, not a software company. Building, testing, and maintaining a complex digital system end-to-end stretched the team beyond what its core role realistically allowed. In retrospect, he felt that involving TechCo at certain stages, such as pilot testing and maintenance, might have significantly improved efficiency: I also don’t think our goal should be to develop as much as possible ourselves. Looking back, I actually think the decision to build it in-house was a mistake in the long run.
Looking back, Steve recognized that TechCo’s earlier offer of modular engagement might have provided exactly the balance Hospital W needed. At the time, however, the urgency and the closeness of the in-house team to clinicians had made the in-house path feel like the only workable one. The moment for combining the two kinds of expertise had passed before either side could find a way to make it work.
Looking ahead: Rethinking the customer engagement approach
Two hospitals with very similar functional needs had made different choices—one had selected TechCo for an end-to-end delivery, while the other had chosen an internal solution despite clear technical overlap with TechCo’s existing application. For Ben, what stayed with him most after the Hospital W experience was not the outcome itself, but what the contrast revealed about how digital systems were coming together in the Norwegian healthcare sector. Hospital W’s ICT team had access to clinicians and understood the daily work because they were part of it. TechCo’s engineers and designers had built deep technical capability over three decades, but their engagement with the daily work of any particular hospital happened through a different rhythm, shaped by procurement and project definition. Some of what shaped a project sat in the daily routines of the hospital itself, in places a supplier could not easily reach until well after those routines had already informed the work.
Ben suspected this was not unique to Hospital W. Across the Norwegian healthcare sector, hospitals were building their own ICT capacity, getting closer to the daily work, and growing more confident in deciding what to develop internally and what to procure. They were not becoming software companies, and they would always need partners like TechCo for parts of the work. But the boundary between what they would buy and what they would build had moved, and might keep moving. Hospitals were differing not only in what they wanted the system to do, but also in how they wanted solutions to be developed, governed, and maintained. Some valued a complete, supplier-led delivery; others wanted to use external suppliers more selectively, combining internal development with outside support. In some cases, these preferences were not fully clear at the outset.
TechCo’s current way of working followed a largely linear path from marketing, to sales, to engineering. The question that pressed on Ben was whether this approach could keep up with this shift. The company had built long-term relationships and delivered complex systems, but the Hospital W experience suggested that being a reliable supplier might not be enough to remain a preferred partner. As he prepared for the next strategy meeting with his leadership team, one question stayed in his mind:
How should TechCo reshape its customer engagement and sales approach so that it better reflects hospitals’ preferences and positions the company as a preferred partner in Norway’s decentralized healthcare system?
Discussion questions
The questions below are intended to help readers analyze the case deeply for in-class discussion.
A. Understand the situation
(1) Drawing on your understanding of how TechCo organizes its work across marketing, sales, and engineering, what do the contrasting outcomes at Hospital E and Hospital W reveal about how TechCo currently engages with its customers?
(2) How well does TechCo’s current customer engagement and delivery approach align with how Norwegian hospitals appear to want to work with digital suppliers? Where does it work well, and where does it fall short?
B. Examining the underlying dynamics
(3) What kinds of knowledge sit on different sides of the supplier-customer relationship in this case, and what challenges does that create for both TechCo and its hospital customers?
(4) How could TechCo gain closer, earlier access to clinical workflows without overextending a 100-person firm? What would change about how the company works?
C. Strategic decision
(5) Given TechCo’s size, resources, and market position, what realistic changes should the company make to its customer engagement and delivery approach to position itself as a preferred long-term partner in Norway’s healthcare sector?
Footnotes
Author’s note
The names of the company, hospitals, and individuals in this case have been anonymized to protect confidentiality. Specifically, “TechCo,” “Hospital E,” “Hospital W,” “Ben,” “Anna,” and “Steve” are pseudonyms. The events described are based on actual experiences collected through interviews and supporting public documents, but identifying details have been removed or adjusted where necessary to prevent recognition of the organizations and individuals involved.
Funding
The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The research activities for this teaching case were funded by the Research Council of Norway, grant number 331903 - CoTecH (Co-created Health Technology).
Declaration of conflicting interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Use of artificial intelligence tools
Generative artificial intelligence tool (e.g., Claude) was used in a limited and supportive capacity during manuscript preparation to assist with language refinement, structural organization, and clarity of expression. All substantive content, case design, pedagogical framing, analysis, and final editorial decisions were developed and approved by the authors, who retain full responsibility for the accuracy, integrity, and originality of the work.