1 Stakeholder engagement in early stage product-service system development for healthcare informatics Man Hang Yip, Robert Phaal, David R. Probert Centre for Technology Management, Department of Engineering, University of Cambridge, CB3 0FS, U.K Abstract This paper presents the findings from four case studies on stakeholder engagement in new health information and communication technology (ICT) product-service system (PSS) development. The degree of connectivity between the new health ICT PSS and its operating environment has emerged to be an important contextual factor that may impact stakeholder engagement in the early stage development process. Along with the proposition of a four-level framework to guide systematic stakeholder identification for new PSS development, three other propositions for analyzing stakeholder engagement based on the degree of connectivity are developed. Analysis of the findings has shown that the connectivity between an ICT PSS and its operating environment can be separated into data connectivity and process connectivity. Moreover, each type of connectivity could be characterized in terms of three categories: independent, linked or incorporated. Furthermore, depending upon whether and to what extent the PSS has data and process connectivity with its intended operating environment, the stakeholder engagement needs in early stage development vary. The propositions presented in this paper provide important directions for future work exploring how contextual factors impact stakeholder engagement in early stage new PSS development in the healthcare industry. I. Introduction Western Europe’s aging population is demanding more intensive medical treatments. Patients and clinicians are expecting ever more from increasingly complex healthcare services. At the same time there is continual pressure to contain healthcare costs; therefore hospitals see the need to invest in new medical equipment and efficient healthcare services [20]. In this context, this research project explores what factors govern the engagement of stakeholders in the early stage of new product-service system (PSS) development in order to have a better perceived outcome, from the perspective of manufacturers in the healthcare industry. 2 One important aspect of this research is to understand how different types of PSS link to stakeholder engagement in early stage new PSS development. Here, PSS is defined as a commercial offering consisting of a collection of elements of products and/or services that fulfill a customer’s needs. Early stage is defined as the process steps taken after the manufacturer has set the new product/service strategy, but before commencing the product/service development tasks. This paper focuses on discussing the findings from four case studies on stakeholder engagement in new health information and communication technology (ICT) PSS. A brief overview of the methodology is presented in Section II, which is then followed by a literature review of stakeholder engagement in new product/service development (NPD/NSD) in Section III. Section IV gives the background of the cases and Section V presents and discusses the findings, followed by a conclusion in Section VI. II. Methodology This study intends to contribute novel perspectives to theoretical frameworks in new PSS development and stakeholder identification. The research addresses a gap identified in the literature, of a lack of new development process models and stakeholder theories in new product/service development. A multiple-case study approach is selected, as building theory from cases has the strength of having a higher probability of generating a novel theory that is more likely to be testable and empirically valid [5]. In this research, cases focus on development projects for a new PSS, a new service augmenting an existing product, or a new product that supplements an existing PSS. A conceptual framework developed from a literature review has been revised after 25 pilot interviews involving four cases and 13 stakeholder groups. Selection criteria for theoretically useful cases are then developed [5]. Four iterations, with four cases per iteration, employing semi-structured interviews as the primary data collection method are planned. The four cases discussed in this paper are part of the first iteration. 3 III. Literature A. Product-Service System The literature review of product-service systems (PSS) explored definitions of product and service. The distinction that products are tangible and services are intangible has been commonly used since the 1960s [27]. For this research, the definitions adopted for product and service are: a product displays the characteristics of independent existence and can be stocked without losing its identity [9]; a service is something that cannot be stored and cannot be independent from the interactions between the producer and the consumer [9, 21]. This definition does not rely on tangibility as the demarcation of product and service, and therefore does not confuse a digital (intangible) product such as software as a service. The idea of customers buying bundled offerings consisting of products and services was proposed and applied by researchers in the field of marketing, service marketing and management in the 1970s and 1980s [3]. As early as 1972, Levitt proposed the concept of product as “a tool to solve their [customers’] problems” and that service is an integral part of what is sold [13]. According to Baines et al. [2] the formal definition of PSS was first given by Goedkoop, van Halen, te Riele and Rommens [7]: PSS, or product service combination, is a “marketable set of products and services capable of jointly fulfilling a user’s need. This was not dissimilar from the earlier idea of Levitt: a “customer-satisfying entirety” or a “bundle of differentiating value satisfactions” that comprises layers of products and services [14]. Recognizing one school of thought behind PSS is to promote sustainability, Baines et al. [2] proposed that a PSS offers “the opportunity to decouple economic success from material consumption”. Since the PSS definition proposal by Goedkoop et al. in 1999, scholars in both marketing and sustainability communities have proposed various PSS classification schemes. The three frequently used classifications in the reviewed PSS literature, namely product-oriented, use-oriented, and result-oriented PSS, were first proposed by Hockerts and Weaver in 2002 [10], and was extended to include integration-oriented and service-oriented [17]. Table 1 captures the comparison among three existing classification schemes and also the comments on whether the examples provided by these schemes display product or service characteristics. As seen in Table 1, it appears that “result-oriented PSS” and the “change of system” may have confused service with intangible (digital) product. 4 Table 1: A comparison of PSS classifications Goedkoop, van Halen, te Riele, Rommens [7] Neely [17] Mont [16] Examples in literature Example displays product or service characteristics according to Shostack [21] and Hill [9] Product-Service (Ps) – services are connected to products Product-oriented – products plus product-related- services; ownership of tangible product transferred to customer Point of sales Personal assistance in shops Service Maintenance Installation service Service Revalorization Product recycling service Service Integration-oriented – products plus downstream services; ownership of tangible product transferred to customer Asset utilization advisory service Service Service-product (Sp) – service provider hands products to customer Result-oriented – replaces the product with a service Result-oriented Credit card (replaces cash) Credit card – product Lending & borrowing money – service, simplified by the use of credit card Service-product (Sp) – service provider adds product as a production aid Use-oriented – service delivers through a tangible product; often ownership of tangible product retained Use-oriented ATM ATM – product Cash withdrawal at ATM - service Product-Service (PS) – products and services are developed in combination Service-oriented – a coupled product and value added service; ownership of tangible product transferred to customer Products Services Combinations Intelligent vehicle health management Intelligent vehicle health management system is software (a product) and it exists independently. However, the provider could offer proactive maintenance (a service) that needs producer and consumer to interact. Change of system – a new system that substitutes a whole system Result-oriented PSS – replaces the product with a service Result-oriented; Products Services Substitutions Electronic money Voicemail Voicemail and electronic money do not require producer and consumer to be present at the same time. Their identities are preserved over time. They are intangible products. Use-oriented Lease of equipment Service Integration-oriented PSS Consulting service Service 5 B. New PSS Development Between the 1970s and 2000s, there were many proposals of new product development (NPD) and new service development (NSD) process models, and a few new PSS development process models. As observed by Maussang, Zwolinski and Brissaud [15], some of the design approaches for PSS had a product-focus and others a service-focus. Product-focused design approaches dealt with the extension of product life span (e.g. [1], [11]). Service-focused design approaches illustrate the interactions between customers and services (e.g. [8], [22]). Proposals that had less bias towards product or service were: [12], [15], [24], and [26]. However, these models remained at a business strategy level and could possibly be applied for NPD and NSD [12, 24], or did not provide any guideline in terms of the timing of execution of each suggested activity [26]. The exception was the proposal by Maussang, Zwolinski and Brissaud [15] that took an holistic approach to the design and development of both product and service elements in the PSS, and carried enough technical details required for product development. C. Stakeholders’ involvement in new development In this research, Freeman’s stakeholder definition is adopted: a stakeholder is defined as any group or individual who can affect or is affected by the new PSS [6]. The reviewed literature of stakeholder involvement in NPD/NSD examined the interactions between service providers and their customers and suppliers at strategic and operational levels. Some studies on lead users and customers’ involvement in NPD and NSD showed positive impact (e.g. [19], [25]). However, one study showed that no sales or competitiveness advantage resulted from customer involvement in NSD [4]. Moreover, limited studies investigated other stakeholder (non- customer) involvement [28]. One study showed positive impact when an external research organization was involved in NPD [23]. Another found supplier involvement in NPD was important, although there was no best way to do so [18]. In summary, there is no consensus on the impact of stakeholder engagement in new development [28]. 6 IV. Background to the cases Four case studies on new PSS development for healthcare informatics have been completed. The companies involved are manufacturers who have been developing new health ICT products and advisory services to improve hospital management and operations. Table 2 provides more details about the cases. Table 2: Background information of the cases Case 1 Case 2 Case 3 Case 4 Company background A small multinational specializes in developing health ICT software and product consulting services companies. A medium-size Nordic- based company specializes in developing healthcare and welfare IT products and consulting services. A large multinational that develops, produces, and delivers medical devices and health ICT software, as well as consulting services for hospital management and operations improvement. Purpose of the PSS To digitalize patients’ test completion and result recording, help hospitals to better manage wards’ workflows and have visibility of patient’s status at any time. To detect a deteriorating patient and send alerts to the right people for the right attention to be given to the patient. To reduce the turnaround time from patient diagnosis reporting to when the report is prepared and signed. To improve hospitals’ bed management and patient discharge processes. Commercialization status of the new PSS at the time of writing this paper Has been sold and operated in the UK. Has been sold and operated in the UK. Has been sold and operated in different markets including Australia and the UK. Has been sold and operated mainly in the US. Target outcome of the PSS To improve patient outcome and meet the CQUIN1 payment conditions. To improve patient outcome: safety and quality of care. To improve efficiency in the hospital, the accuracy of patient records and the quality of treatment. To reduce patient length of stay in the hospital. Key components of the PSS Product: 1. Database 2. Software product 3. Handheld device / computer (3rd party) Product: 1. Database 2. Software product (rule engines) 3. Handheld device / computer (3rd party) Product: 1. Software product 2. 3rd party software 3. Hardware accessories 4. Hardware computers Product: 1. Software product 2. Radio frequency identification reader and tags 3. Drop boxes 7 Service: 1. Patient test tracking service 2. End user training (provided by customers) 3. Configuration service 4. Configuration training (could be provided by customers) 5. Software implementation service 6. System integration service Service: 1. Patient status tracking and warning service 2. End user training 3. Configuration service 4. Software implementation service 5. On-going support and maintenance service Service: 1. Training 2. Implementation service 3. System integration service 4. On-going support service Service: 1. Training 2. Planning simulation sessions 3. Implementation service 4. Change management advisory service Roles of the informants Informant 12: Technical – product development Informant 2: Technical – product development and service development Informant 12: Technical – product development Informant 4: Commercial & Management – product & service development Informant 53: Technical & Management - Hospital’s healthcare informatics manager Informant 6: Technical – product management, service development and trainer Informant 7: Commercial – business development Informant 8: Technical – solution development Informant 9: Technical & Management – Solution development Informant 10: Technical – Advisory service development Note: 1. CQUIN stands for Commissioning for Quality Innovation. CQUIN payment framework is an initiative started in 2009 by the Department of Health in the UK to reward the excellence of quality of hospital operations in improving patient outcome. 2. Informant 1 was interviewed for both Case 1 and 2. 3. All informants are employees of the manufacturers, apart from Informant 5, who works in the customer’s organization that drove the co-development in Case 3 with the manufacturer, interviewed in 2010 in one of the pilot interviews. 8 The four PSS cases are different in terms of who the primary users are, the intended operating environment, and the requirements of the connectivity with the hospital’s operating environment. Table 3 details these various aspects. Table 3: The interaction of each PSS with its operating environment Case 1 Case 2 Case 3 Case 4 Primary users Nurses Nurses and Doctors Doctors Bed Managers Intended PSS operating environment Hospital – wards; part of the nursing operations. Hospital – wards, part of the acute patient care operations. Hospital - radiology department or outpatient; part of the radiology imaging operations. Hospital – wards, operating rooms (basically where there are beds); part of the bed management operations. Required data connectivity of the new PSS with the existing information systems in the operating environment The software product is required to interface with various existing information systems in the hospital. The software product is developed as a standalone product, and is not required to link with any other systems in the hospital. The software product is required to connect to other systems in the hospital in terms of data exchange, and also to be incorporated into the user-interface of an existing software application. The software product is developed to have data connectivity with other information systems in the hospital. Required changes to the existing procedures in the operating environment as a result of the new PSS The workflows of the nursing operations remain the same. The only difference introduced by this new PSS is that the input method will be changed from pen & paper to digital entry. The workflows of patient care operations remain the same, but the software product empowers junior nurses to alert senior consultants when attention is required for a deteriorating patient. The workflows in the radiology department and outpatient are required to be changed for the PSS to operate as intended. The PSS added new procedures and also changed the existing processes in the hospital’s operations. The new process connected the workflows of various departments within the hospital. 9 V. Findings and Discussions A. Stakeholders During the case interviews, informants were asked to identify stakeholders who were involved and who should have been involved during the development process, as well as the timing of their involvement. Eleven stakeholder groups were identified (see Table 4). Table 4: Stakeholders Identified Considering the stakeholder groups identified (see Table 4), the stakeholders have different degrees of proximity to the PSS operations. These levels are: (1) business environment, (2) system, (3) product and (4) service delivery. Fig. 1 shows the potential mapping between the identified stakeholder groups and the four levels of proximity. Case 1 is used as an example to explain this concept. In Case 1, nurses record patients’ test completions and results into the new ICT product within the PSS. The patients (P) receive the service while the nurses as the end users (Cu-U) deliver the service using the product. Stakeholders Identified Stakeholder’s Short-form Label Case 1 Case 2 Case 3 Case 4 Industry interest groups / authority / standard / domain experts Ex X X Patients' family & other care-giving organizations P-O X Supplier or partner to the company to develop the PSS V X - Customer's management Cu-M X X X X Company's management Co-M (X) (X) X X Company's commercial Co-Co (X) (X) X X Company's development Co-T X (X) X X Customer's informatics (IT support) Cu-S X X X Company's service delivery Co-U X X Customer's end users Cu-U X X X X Patients P X X X X Legend: “X” - the stakeholder group was identified explicitly by the informants “(X)” - the stakeholder group was identified implicitly by the informants An empty cell - the informants did not identify the stakeholder group “-“ - the stakeholder group was not applicable 10 The company’s service delivery (Co-U) trains the customer’s IT support (Cu-S) on how to perform configuration on the new ICT product and ensure they are able to provide end-user training. Therefore, P is associated with the service delivery level while Co-U and Cu-U are associated with both the product and service delivery levels. The company’s development (Co-T) configures the ICT product to the nurses’ needs, and also work with the hospital’s IT support (Cu-S) to ensure the new product is adopted into the nursing operations. Therefore, Cu-S is associated with the service delivery (end-user training), product (implementation) and system (PSS adoption) levels, while Co-T is associated with product (configuration) and system (integration and PSS adoption) levels. The hospital’s management (Cu-M), company’s management (Co-M) and company’s commercial groups (Co-Co) have an overall interest in the operations of the PSS, and so they are associated with the system level. Authority and domain experts (Ex) are associated with the business environment level, as their influence is not limited to this particular PSS, but other PSS within the ICT sector of the healthcare industry. Fig. 1: The levels of stakeholders emerged from the case studies Based on the above findings, proposition 1 is developed: Proposition 1 A framework could guide practitioners to systematically identify stakeholders for the new PSS development process. The framework would consist of four levels: business environment, system, product and service delivery. Business environment System Product Service delivery Patients (P) Customer’s IT support (Cu-S) Company’s service delivery (Co-U) Company’s end users (Cu-U) Company’s development (Co-T) Supplier / partner (V) Customer’s management (Cu-M) Company’s management (Co-M) Company’s commercial (Co-Co) Industry interest groups / authority / standard / domain experts (Ex) Patients’ family / care-giving organisations (P-O) Service delivery Product System Business environment 11 B. Connectivity with operating environment As seen previously in Table 3, the PSS in each case has different requirements in terms of how it is to interact with its intended operating environment. Two aspects of connectivity have been identified from the case interviews: (1) the required data connectivity of the new PSS with the existing information systems in the operating environment, and (2) the required changes to the existing procedures in the operating environment as a result of the introduction of the new PSS. These aspects are named here “data connectivity” and “process connectivity” respectively. Fig. 2 compares the PSS in the four case studies in terms of how each connects with its intended operating environment. Fig. 2: PSS connectivity with its operating environment (source: authors) As seen in Fig. 2, Case 4 not only required the software product to be integrated with other healthcare information systems in the hospitals (linked), but also the new process for bed management is required to be embedded into the hospital’s operating procedures (incorporated). Case 3 required backend data connectivity to other information systems in the hospitals and user-interface integration with another software application, in order to enable the users to have a “seamless” transition from an existing health information system to the new software product (incorporated). The new PSS in Case 3 also required the users and other hospital stakeholders to change their ways of working. Although it may not be as large-scale as that required in Case 4 (impact on the departmental level’s workflows versus impact on the whole hospital operations), nonetheless, the new process introduced by Case 3 is to be embedded in the existing radiology & outpatient workflows (incorporated). 1 2 3 4 Independent Linked Incorporated In de pe nd en t Li nk ed In co rp or at ed Pr oc es s C on ne ct iv ity D ire ct io n of in cr ea si ng c om pl ex ity Data Connectivity Direction of increasing complexity Case Number Legend: 12 The PSS in Case 1 and 2 have no process connectivity requirements with their operating environment (independent). Neither of these PSS requires changes to the existing operating procedures. Both software products in Case 1 and 2 replaced the paper-based methods in-use. However, Case 1 required backend data connectivity with another healthcare information system in the hospital (linked), which is lower than the data connectivity required by the PSS in Case 3 and 4. Case 2 was developed as a standalone PSS that does not required data connectivity with other healthcare information systems, and therefore is “independent” in the data connectivity aspect. Comparing the differences among the four cases in terms of the types of connectivity and the degree of connectivity, Proposition 2 and 3 have emerged: Proposition 2 The type of connectivity between an ICT PSS and its operating environment can be separated into that resulting from data interactions and that related to process interactions. Data connectivity is the level of data communications between the new PSS and the other systems in the environment. Process connectivity reflects the degree of linkage between and the assimilation of the new processes necessitated by the new PSS with the existing processes. Proposition 3 Data and process connectivity can be characterized in terms of three categories: independent, linked, and incorporated. A new PSS that is not going to have any connectivity with the existing systems in the operating environment is “independent”. If a new PSS is to interface with the existing systems, it is “linked”. If a new PSS is to become part of the existing systems, it is “incorporated”. C. Stakeholder involvement in new PSS development A new PSS development process framework was used to guide the discussion with the informants on stakeholders’ involvement in the early stage development process. This proposed process framework was a result of literature review and the pilot interviews conducted in the previous year. The framework was then 13 refined based on the four case studies. For reasons of clarity, the resulting process framework, with the early stage shaded (see Fig. 3), is presented as a linear flow-chart. Some of the steps can overlap and there can be feedback loops within the process. Fig. 3: Early stage new PSS development process (source: authors) Table 5 captures the informants’ opinions about which stakeholder group was engaged or should have been engaged in each of the early stage development process step. As the four cases have different degrees of process and data connectivity, it is possible to compare the requirements of stakeholder engagement with respect to the required level of PSS connectivity with its operating environment. This analysis is summarized in Fig. 4. In Fig. 4, the analysis concerning connectivity factors show: stakeholder engagement that is common to all PSS development regardless of the level of connectivity, stakeholder engagement for PSS with no connectivity, stakeholder engagement for PSS with data connectivity, and stakeholder engagement for PSS with both data and process connectivity. Non-connectivity related factors are observed, and some of these analyses are shown in Fig. 4. For example, both Case 3 and 4 have data and process connectivity requirements with its operating environment, but the customer initiated the former and the company initiated the latter. A comparison of stakeholder engagement between the two parties driving the PSS development is made. Comparisons with respect to three other non-connectivity factors are also made as an exploration of what other contextual factors could influence stakeholder engagement in the early stage PSS development process. Generate ideas & commit resources (can include early prototyping) Identify and assess problem Identify stakeholders Generate concepts for stakeholders feedback Identify & validate concepts with selected stakeholders Prioritise concepts Generate prototype and test with stakeholders Develop new PSS Commercialise PSS Collect feedback on new PSS Generate ideas: Generate new ideas to solve a potential problem or new way to resolve an existing problem Assess problem: Seek better understanding of the problem Generate concepts: Generate concepts of the potential solution with stakeholders Select concepts: Select a valid concept to proceed Generate and test prototype: Prototype concepts and test with stakeholders Identify stakeholders Identify who the stakeholders are for the problem Product & service strategy planning 14 Table 5: Stakeholder’s involvement in early stage new PSS development process - comparing the four cases Stakeholders Identified (Short-form label) In du st ry in te re st g ro up s / a ut ho rit y / s ta nd ar d / do m ai n ex pe rts Pa tie nt s' fa m ily & o th er ca re -g iv in g or ga ni za tio ns Su pp lie r o r p ar tn er to th e co m pa ny to de ve lo p th e PS S C us to m er 's m an ag em en t C om pa ny 's m an ag em en t C om pa ny 's co m m er ci al C om pa ny 's de ve lo pm en t C us to m er 's in fo rm at ic s (I T su pp or t) C om pa ny 's se rv ic e de liv er y C us to m er 's en d us er s Pa tie nt s (Ex) (P-O) (V) (Cu-M) (Co-M) (Co-Co) (Co-T) (Cu-S) (Co-U) (Cu-U) (P) Early stage development - main process step Case number & Process/Data Connectivity For each main process step, the stakeholder groups that were involved or should have been involved according to the informants of each case study was marked as “X” below (1) Generate ideas Case 1 X X X Case 2 X X X Case 3 X X X X X X X Case 4 X X X X (2) Assess problem Case 1 X X Case 2 X X X Case 3 X X X X X X Case 4 X X X X X (3) Identify stakeholders Case 1 X X X Case 2 X X X Case 3 X X X X X* Case 4 X X X X (4) Generate concepts Case 1 X X Case 2 X X X Case 3 X X X X X Case 4 X X X X (5) Select concepts Case 1 X X Case 2 X X X Case 3 X X X X X X* Case 4 X X X X X (6) Generate and test prototype Case 1 X X Case 2 X X X X Case 3 X X X X X Case 4 X X X X X X X Note: *For Case 3, it was mentioned by the informants that Cu-S was representing the interest of users during the development process. Therefore, Cu-U is added here even though they are not explicitly mentioned. P ro ce ss Data 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 15 Fig. 4: Summary of stakeholder engagement analysis based on the four cases Summarizing from the interview findings, Proposition 4, which is further detailed into four sub-propositions have emerged. Proposition 4 Stakeholder engagement in early stage development needs to be varied depending upon whether and to what extent the PSS has data and process connectivity with the systems in its operating environment. Proposition 4.1 Regardless of the required degree of connectivity between the PSS and its operating environment, there is a need to engage hospital’s management in the beginning to generate ideas, hospital’s end users in the middle as well as at the end of the early stage to generate concepts, select concepts and test prototypes. (1) Generate ideas (2) Assess problem (3) Identify stakeholders (4) Generate concepts (5) Select concepts (6) Generate and test prototype Customer’s management Common to all types of connectivity Data & process connectivity (Case 3 & Case 4) No connectivity (Case 2) Customer’s end users The beginning… The middle… Main steps in the early stage of new PSS development The end… If the development needs a supplier/partner If the idea is originated from a domain expert If the new PSS touches patients Data connectivity (Case 1,3,4) Customer’s informatics Company's development Company’s service delivery Difference when customer is driving development (Case 3) compare to company driven development (Case 4) Non-connectivity factors Domain’s expert Supplier/ Partner Customer’s informatics Company’s management Company's development Customer’s end users Note: in addition to data connectivity Company’s commercial Customer’s management Customer’s informatics Company’s commercial Domain’s expert Supplier/ Partner Customer’s management Company’s management or Customer’s end users Customer’s informatics Company’s commercial Company's development Customer’s end users Customer’s informatics Company’s service delivery or Domain’s expert Domain’s expert Domain’s expert Domain’s expert Patient care / Family Patient Customer’s end users Company's development Company’s commercial Customer’s management Company’s management or Customer’s end users Customer’s informatics Company’s commercial Company's development Customer’s management Note: Customer driven - in addition to those requires for company-driven Customer’s informatics Company’s management Company’s management Customer’s informatics Company’s management Customer’s informatics Company’s management Customer’s informatics Company’s management Customer’s end users Company's development Company’s management Customer’s informatics Company's development Company’s service delivery Company’s service delivery Company’s service delivery Company’s service delivery Customer’s management Company’s service delivery Company’s commercial Customer stakeholder Company (Internal) stakeholder Other external stakeholder Legend: Company’s management Company’s management Company’s management Company’s management Customer’s management Note: Company driven - in addition to those requires for customer-driven Connectivity factors Customer’s end users Customer’s management Customer’s management Customer’s management Company’s management or P ro ce ss Data 16 Proposition 4.2 For PSS with only data connectivity requirements and no process connectivity requirement, there is a need to: engage hospital’s informatics / IT support and hospital’s end users in the beginning to generate ideas, assess problems, and identify stakeholders; company’s development group and hospital’s informatics / IT support in the middle to generate and select concepts; and hospital’s informatics / IT support at the end to generate and test prototype. Proposition 4.3 For PSS with both data and process connectivity requirements, in addition to the stakeholders needed for “data connectivity only” PSS development (Proposition 4.2), four other stakeholder groups are identified: the management teams of the company and hospital in the beginning to assess problems, generate & select concepts, and test prototype; the company’s commercial group from assessing the problem to selecting the concepts; and the company’s development group to work with the company’s commercial group and management teams from the middle to the end of the early stage development process. Proposition 4.4 For an independent PSS, there is a need to engage company’s management and external experts (if needed) throughout the early stage development process. The need to engage hospital stakeholders or customer- facing internal stakeholders is lower in comparison to that of PSS with higher data and/or process connectivity. VI. Conclusion Four case studies of new PSS development for health informatics were explored, resulting in new approach to characterize PSS and new understanding of stakeholder engagement requirements in early stage development. It has emerged that the degree of data and process connectivity between an ICT PSS and its intended operating environment is an important contextual factor that may impact effective stakeholder engagement in the early stage development process. By analyzing and depicting the required level of data and process connectivity between the new ICT PSS and the other systems in its future operating environment, stakeholders could be more systematically identified and more effectively engaged in the development process. 17 Although only limited cases were included in this paper, the propositions presented provide important directions for future work in stakeholder engagement in new PSS development. Additional case studies are needed to investigate stakeholder engagement for new PSS with only process connectivity requirements, and to examine other affecting non-connectivity contextual factors, such as who initiated or originated the new development and how new the new PSS is. Cases for non-ICT sector in the healthcare industry will also be needed to allow further exploration. Reference [1] Aurich, J.C., E. Schweitzer & C. Mannweiler, “Integrated Design of Industrial Product-Service Systems,” in Manufacturing Systems and Technologies for the New Frontier, M. Mitsuishi, K. Ueda and F. Kimura, Ed. London: Springer, 2008. [2] Baines, T.S. et al., “State-of-the-art in product-service systems,” Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture, vol. 221, no. 10, pp.1543–52, 2007. [3] Bell, M., “Some strategy implications of a matrix approach to the classification of marketing goods and services,” Journal of the Academy of Marketing Science, vol. 14, no. 1, pp.13–20, 1986. [4] Carbonell, P., A. I. Rodiguez-Escudero and D. Pujari, “Customer Involvement in New Service Development: An Examination of Antecedents and Outcomes,” Journal of Product Innovation Management, vol. 26, pp.536–50, 2009. [5] Eisenhardt, K., “Building theories from case study research,” Academy of management review, vol. 14, no. 4, pp.532–50, 1989. [6] Freeman, R. E., Strategic Management A Stakeholder Approach, Marshfield, MA: Pitman Publishing Inc., 1984. [7] Goedkoop, M. J., C. J. G. van Halen, H. R. M. te Riele and P. J. M. Rommens, “Product Service systems, Ecological and Economic Basics,” Economic Affairs, Mar. 1999. [8] Gummesson, E., “Exit services marketing - enter service marketing,” Journal of Customer Behaviour, vol. 6, no. 2, pp.113–41, 2007. [9] Hill, P., “Tangibles, Intangibles and Services: A New Taxonomy for the Classification of Output,” The Canadian Journal of Economics / Revue canadienne d’Economique, vol. 32, no. 2, pp.426–46, 1999. 18 [10] Hockerts K. and N. Weaver, “Towards a theory of sustainable product service systems,” INSEAD-CMER research workshop on sustainable product service systems, 2002. Cited in Neely, A., “Exploring the financial consequences of the servitization of manufacturing,” Operations Management Research, vol. 1, no. 2, pp.103–18, 2009. [11] Juehling, E., M. Torney, C. Herrmann and K. Droeder, “Integration of automotive service and technology strategies,” CIRP Journal of Manufacturing Science and Technology, vol. 3, no. 2, pp.98–106, 2010. [12] Kindström, D. and C. Kowalkowski, “Development of industrial service offerings: a process framework,” Journal of Service Management, vol. 20, no. 2, pp.156–72, 2009. [13] Levitt, T., “Production-line approach to service,” Harvard Business Review, Sep./Oct., pp.41–52, 1972. [14] Levitt, T., “Marketing success through differentiation - of anything,” Harvard Business Review, vol. 58, no. 1, pp.83–91, 1980. [15] Maussang, N., P. Zwolinski and D. Brissaud, “Product-service system design methodology: from the PSS architecture design to the products specifications,” Journal of Engineering Design, vol. 20, no. 4, pp.349– 66, 2009. [16] Mont O., “Clarifying the concept of product-service system,” Journal of Cleaner Production, vol. 10, no. 3, pp. 237-45, 2002. [17] Neely, A., “Exploring the financial consequences of the servitization of manufacturing,” Operations Management Research, vol. 1, no. 2, pp.103–18, 2009. [18] O’Sullivan, A., “Why tense, unstable, and diverse relations are inherent in co-designing with suppliers: an aerospace case study,” Industrial and Corporate Change, vol. 15, no. 2, pp.221–50, 2006. [19] Oliveira, P. and E. von Hippel, “Users as service innovators: The case of banking services,” Research Policy, vol. 40, no. 6, pp.806–18, 2011. [20] PR Newswire. “The outlook for medical devices in Western Europe”, Retrieved 1/7/2013 World Wide Web, http://www.prnewswire.com/news-releases/the-outlook-for-medical-devices-in-western-europe- 148494335.html [21] Shostack, G. L., “Breaking Free from Product Marketing,” Journal of Marketing, vol. 41, no. 2, pp.73–80, 1977. [22] Shostack, G. L., “Designing services that deliver,” Harvard Business Review, vol. 62, no. 1, pp.133–39, 1984. 19 [23] Smirnova, M. M., D. Podmetina, J. Väätänen, S. Kouchtch, “Key stakeholders’ interaction as a factor of product innovation: the case of Russia,” International Journal of Technology Marketing, vol. 4, no. 2/3, pp.230–47, 2009. [24] Tan, A., T. Mcaloone, and D. Matzen, “Service-Oriented Strategies for Manufacturing Firms,” in Introduction to Product/Service-System Design, T. Sakao and M. Lindahl, Ed. London: Springer, 2009. [25] von Hippel, E, “The dominant role of users in the scientific instrument innovation process,” Research Policy, vol. 5, no. 3, pp.212–39, 1976. [26] Yang, L., K. Xing and S. Lee, “A new conceptual life cycle model for Result-Oriented Product-Service System development,” Proc. of the IEEE International Conference on Service Operations and Logistics and Informatics (SOLI) 2010, pp. 23–28, 2010. [27] Yip, M.H., R. Phaal, R., D. R. Probert, “Characterizing Product-Service Systems in the Healthcare Industry – an Internal Stakeholder Perspective,” Proc. of the IEEE International Conference on Industrial Engineering and Engineering Management (IEEM 2012), Hong Kong, December 2012, in press. [28] Yip, M.H., R. Phaal, R., D. R. Probert, “Value co-creation in early stage new product-service system development,” Proc. of the 3rd Service Design and Innovation Conference (ServDes. 2012), Espoo, Finland, February, 2012.