9812836055

961

Transcript of 9812836055

This page intentionally left blank

HANDBOOK ON BUSINESS INFORMATION SYSTEMSedited by

Angappa GunasekaranUniversity of Massachusetts, USA

Maqsood SandhuUniversity of Oulu, Finland

World ScientificNEW JERSEY

LONDON

SINGAPORE

BEIJING

SHANGHAI

HONG KONG

TA I P E I

CHENNAI

Published by World Scientific Publishing Co. Pte. Ltd. 5 Toh Tuck Link, Singapore 596224 USA office: 27 Warren Street, Suite 401-402, Hackensack, NJ 07601 UK office: 57 Shelton Street, Covent Garden, London WC2H 9HE

British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library.

HANDBOOK ON BUSINESS INFORMATION SYSTEMS Copyright 2010 by World Scientific Publishing Co. Pte. Ltd. All rights reserved. This book, or parts thereof, may not be reproduced in any form or by any means, electronic or mechanical, including photocopying, recording or any information storage and retrieval system now known or to be invented, without written permission from the Publisher.

For photocopying of material in this volume, please pay a copying fee through the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, USA. In this case permission to photocopy is not required from the publisher.

ISBN-13 978-981-283-605-2 ISBN-10 981-283-605-2

Typeset by Stallion Press Email: [email protected]

Printed in Singapore.

PrefaceThe contemporary state of rapid information technology (IT) development has led to the formation of a global village that has swiftly transformed business, trade and industry. It has impacted business management processes in health care delivery, data mining management in industry, and created business information systems as strategic tools to manage businesses. Information technology has led to the development of sophisticated supply chain models, and the evolution of comprehensive business information systems. Overall, the business models have changed from a traditional hierarchical control to more customers oriented via e-business models with a network of information systems. This handbook explores the need of business information management in different contexts and sectors of businesses. The competitive environment dictates intense rivalry among the participants in the market. Similar value propositions and products coupled with broad range of choices available to the customer both in terms of delivery and product differentiation has made business information systems and its management as one of the key drivers for business success and sustainable competitive advantage. The Handbook on Business Information Systems is divided into six major parts dealing with different aspects of information management systems in various business scenarios. A total of 37 chapters cover the vast eld of business information systems, focusing particularly on developing information systems to capture and integrate information technology together with the people and their businesses. A brief introduction of each part is summarized below. Part I of the book, Health Care Information Systems, consists of four chapters that focus on providing global leadership for the optimal use of health care IT. It provides knowledge about the best use of information systems for the betterment of health care services. These chapters deal with healthcare supply chain information systems, the role of CIO in the development of healthcare information systems and information systems in handling patients complaints. Part II, Business Process Information Systems, composed of nine chapters, extends the previous theory in the area of process development by recognizing that improvements in intraorganizational information systems need to be complemented by corresponding improvements in inter-organizational processes. The chapters cover topics such as modeling and analysis of business processeses, reengineering business processes, implications of culture on logistics and information systems, performance measures in information systems, socio-management systems, knowledge management systems, and risk management in ERP.

v

vi

Preface

With eight chapters, Part III deals with Industrial Data and Management Systems and captures the main challenges faced by the industry, such as the changes in the operations paradigm of manufacturing and service organizations. These chapters are comprehensive in terms of covering signicant topics in business information systems including information systems in sustainability, strategies for enhancing innovation culture, decision support system for line balancing, innovation in logistics using RFID, implications of RFID, implications of information systems on operational efciency, interactive technology for strategic planning and key performance indicators in information systems evaluation. Next, Part IV Strategic Business Information Systems with ve chapters discusses the use of information technology in small industries and analysis of digital business ecosystems. The following are the important topics considered by these chapters: applications of IT/IS in small companies, relationships between information systems, business, marketing and CRM, transfer for business information systems, digital business ecosystem analysis and information contents of accounting numbers. Part V with ve chapters on Information Systems in Supply Chain Management deals with different challenges and opportunities in the eld and discusses supply chain performance along with applications of various technologies. These chapters provide an excellent overview of the implications of supply chain enabling technologies, supply chain management, managing supply chain performance in SMEs, information systems in service learning, and RFID applications in supply chain. Finally, Part VI, Evaluation of Business Information Systems, discusses the adoption of systems development methodologies and the security pattern of the business systems along with useful mathematical models. This part has six chapters dealing with tools for decision-making in IT/IS, application of quantitative models in information management, measurement challenges in IT/IS, object-oriented meta-computing, B2B architecture using web-services technology, and the role of computer simulation in supply chain management. An edited book of this nature can provide useful conceptual frameworks, managerial challenges including strategies and tactics, technologies, and practical knowledge and applications to a variety of audiences including academics, research students and practitioners interested in the management of business information systems. The editors are most grateful to the authors who have chapters in this handbook and have gone through several cycles of revisions and for their continued cooperation in nalizing the chapters. We are thankful to the excellent reviews of over 100 reviewers who have read chapters and helped to improve their quality. The authors are deeply indebted to the editorial team of the publisher for their highly constructive comments that have greatly enhanced the quality of this work. Without their timely support and insightful editorial changes, this handbook would not have been completed. We are especially grateful to Ms. Shalini, the in-house editor for her prompt responses and co-ordination throughout the compiling of this manuscript.

Preface

vii

Also, we are thankful to the publisher, who has been a great source of a inspiration in completing this book project in a timely manner. Finally, our heartfelt thanks go to our families, for their patience and support over the last two years. Angappa Gunasekaran University of Massachusetts Dartmouth, USA Maqsood Sandhu University of Oulu, Finland and UAE University, UAE

This page intentionally left blank

Editor Biographies

Angappa Gunasekaran is a Professor of Operations Management and the Chairperson of the Department of Decision and Information Sciences in the Charlton College of Business at the University of Massachusetts (North Dartmouth, USA). Previously, he has held academic positions in Canada, India, Finland, Australia and Great Britain. He has BE and ME from the University of Madras and a PhD from the Indian Institute of Technology. He teaches and conducts research in operations management and information systems. He serves on the Editorial Board of 20 journals and edits several journals. He has published over 200 articles in journals, 60 articles in conference proceedings and edited three books. In addition, he has organized several conferences in the emerging areas of operations management and information systems. He has extensive editorial experience that includes the guest editor of many high prole journals. He has received outstanding paper and excellence in teaching awards. His current areas of research include supply chain management, enterprise resource planning, e-commerce, and benchmarking. He is also the Director of Business Innovation Research Center at the University of Massachusetts Dartmouth. Dr. Maqsood Sandhu is Associate Professor at Oulu Business School, University of Oulu, Finland. Currently, he is working at the Department of Management, College of Business and Economics at United Arab Emirates University, Al Ain. He earned a PhD from the Swedish School of Economics and Business Administration in Management. Dr. Sandhu has been working over ve years in projectbased industry. He has about 15 international journal articles and book chapters. He has presented over 50 papers and published approximately 40 articles in international conferences. Currently, he is interested in doing research in the areas of project management, knowledge management and entrepreneurship. He is also the Head of Innovation Laboratories at the Emirates Centre for Innovation and the Entrepreneurship.

ix

This page intentionally left blank

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editor Biographies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Part I: Health Care Information Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 1 Healthcare Supply Chain Information Systems VIA Service-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . Sultan N. Turhan and Ozalp Vayvay The Role of the CIO in the Development of Interoperable Information Systems in Healthcare Organizations . . . . . . . . . Ant nio Grilo, Lus Velez Lap o, o a Ricardo Jardim-Goncalves and Virgilio Cruz-Machado Information Systems for Handling Patients Complaints in Health Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zvi Stern, Elie Mersel and Nahum Gedalia How to Develop Quality Management System in a Hospital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ville Tuomi

v ix 1 3

Chapter 2

25

Chapter 3

47

Chapter 4

69

Part II: Business Process Information Systems . . . . . . . . . . . . . . . . . . . . . . . Chapter 5 Modeling and Managing Business Processes . . . . . . . . . . . . . Mohammad El-Mekawy, Khurram Shahzad and Nabeel Ahmed Business Process Reengineering and Measuring of Company Operations Efciency . . . . . . . . . . . . . . . . . . . . . . Nataa Vujica Herzog s Value Chain Re-Engineering by the Application of Advanced Planning and Scheduling . . . . . . . . . . . . . . . . . . . Yohanes Kristianto, Petri Helo and Ajmal Mian Cultural Auditing in the Age of Business: Multicultural Logistics Management, and Information Systems . . . . . . . . . Alberto G Canen and Ana Canen

91 93

Chapter 6

117

Chapter 7

147

Chapter 8

189

xi

xii Contents

Chapter 9

Efciency as Criterion for Typication of the Dairy Industry in Minas Gerais State . . . . . . . . . . . . . . . . . . . . . . . . . . Luiz Antonio Abrantes, Adriano Provezano Gomes, Marco Aur lio Marques Ferreira, Ant nio Carlos e o Brunozi J nior and Maisa Pereira Silva u A Neurocybernetic Theory of Social Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Masudul Alam Choudhury Systematization Approach for Exploring Business Information Systems: Management Dimensions . . . . . . . . . . Albena Antonova A Structure for Knowledge Management Systems Assessment and Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Joao Pedro Albino, Nicolau Reinhard and Silvina Santana Risk Management in Enterprise Resource Planning Systems Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Davide Aloini, Riccardo Dulmin and Valeria Mininno

199

Chapter 10

221

Chapter 11

245

Chapter 12

269

Chapter 13

297

Part III: Industrial Data and Management Systems . . . . . . . . . . . . . . . . . . Chapter 14 Asset Integrity Management: Operationalizing Sustainability Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R. M. Chandima Ratnayake How to Boost Innovation Culture and Innovators? . . . . . . . . . Andrea Bikfalvi, Jari Jussila, Anu Suominen, Jussi Kantola and Hannu Vanharanta A Decision Support System for Assembly and Production Line Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. S. Simaria, A. R. Xambre, N. A. Filipe and P. M. Vilarinho An Innovation Applied to the Simulation of RFID Environments as Used in the Logistics . . . . . . . . . . . . . . . . . . . Marcelo Cunha De Azambuja, Carlos Fernando Jung, Carla Schwengber Ten Caten and Fabiano Passuelo Hessel

321 323 359

Chapter 15

Chapter 16

383

Chapter 17

415

Contents

xiii

Chapter 18

Customers Acceptance of New Service Technologies: The Case of RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alessandra Vecchi, Louis Brennan and Aristeidis Theotokis Operational Efciency Management Tool Placing Resources in Intangible Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Claudelino Martins Dias Junior, Osmar Possamai and Ricardo Gon alves c Interactive Technology Maps for Strategic Planning and Research Directions Based on Textual and Citation Analysis of Patents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elisabetta Sani, Emanuele Ruffaldi and Massimo Bergamasco Determining Key Performance Indicators: An Analytical Network Approach . . . . . . . . . . . . . . . . . . . . . . . Daniela Carlucci and Giovanni Schiuma

431

Chapter 19

457

Chapter 20

487

Chapter 21

515

Part IV: Strategic Business Information Systems . . . . . . . . . . . . . . . . . . . . . Chapter 22 The Use of Information Technology in Small Industrial Companies in Latin America The Case of the Interior of S o Paulo, Brazil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a Ot vio Jos De Oliveira and Guilherme Fontana a e Technology: Information, Business, Marketing, and CRM Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fernando M. Serson Transfer of Business and Information Management Systems: Issues and Challenges . . . . . . . . . . . . . . . . . . . . . . . . . R. Nat Natarajan Toward Digital Business Ecosystem Analysis . . . . . . . . . . . . . Aurelian Mihai Stanescu, Lucian Miti Ionescu, Vasile Georgescu, Liviu Badea, Mihnea Alexandru Moisescu and Ioan Stefan Sacala The Dynamics of the Informational Contents of Accounting Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Akinloye Akindayomi

537

539

Chapter 23

565

Chapter 24

585 607

Chapter 25

Chapter 26

639

xiv Contents

Part V: Information Systems in Supply Chain Management . . . . . . . . . . Chapter 27 Supply Chain Enabling Technologies: Management Challenges and Opportunities . . . . . . . . . . . . . . . . . . . . . . . . . . . Damien Power Supply Chain Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avninder Gill and M. Ishaq Bhatti Measuring Supply Chain Performance in SMES . . . . . . . . . . Maria Argyropoulou, Milind Kumar Sharma, Rajat Bhagwat, Themistokles Lazarides, Dimitrios N. Koufopoulos and George Ioannou Information Sharing in Service Supply Chain . . . . . . . . . . . . . Sari Uusipaavalniemi, Jari Juga and Maqsood Sandhu RFID Applications in the Supply Chain: An Evaluation Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Valerio Elia, Maria Grazia Gnoni and Alessandra Rollo

653 655 675 699

Chapter 28 Chapter 29

Chapter 30 Chapter 31

717

737

Part VI: Tools for the Evaluation of Business Information Systems . . . . Chapter 32 Tools for the Decision-making Process in the Management Information System of the Organization . . . . . . . . . . . . . . . . . . Carmen De Pablos Heredero and M nica De Pablos Heredero o Preliminaries of Mathematics in Business and Information Management . . . . . . . . . . . . . . . . . . . . . . . . . . . Mohammed Salem Elmusrati Herding Does Not Exist or Just a Measurement Problem? A Meta-Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nizar Hachicha, Amina Amirat and Abdelfettah Bouri Object-Oriented Metacomputing with Exertions . . . . . . . . . . Michael Sobolewski A New B2B Architecture Using Ontology and Web Services Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . Youcef Aklouf The Roles of Computer Simulation in Supply Chain Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jia Hongyu and Zuo Peng

763 765

Chapter 33

791

Chapter 34

817 853

Chapter 35 Chapter 36

889

Chapter 37

911 945

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Part I Health Care Information Systems

This page intentionally left blank

Chapter 1

Healthcare Supply Chain Information Systems Via Service-Oriented ArchitectureSULTAN N. TURHAN Department of Computer Engineering, Galatasaray University Cra an cad. No: 36 34357, Ortak y Istanbul, T rkiye g o u [email protected] OZALP VAYVAY Department of Industrial Engineering, Marmara University G ztepe Campus, 34722 Kadk y Istanbul, T rkiye o o u [email protected]

Healthcare supply chain management differs from other applications in terms of its key elements. The misalignment, high costs for healthcare providers and heavy dependence on third parties, distributors, and manufacturers are the main trouble making issues for the healthcare supply chain. At the same time, some of the supply chain components of the health sector have a different position compared to the other materials that are taking place in the other supply chains. In particular, the specic consumables used in the surgical operations bear a signicant importance in terms of the usage and the costs. In some cases, the doctors may not have a strict opinion on the exact quantity of the consumables they will use during the operation before starting it. On the other hand, it is not always possible to have all these materials in the stock because of their high cost. Moreover, due to the inefciencies in the social security system in Turkey, the social security institutions do not always accept to pay the price of the materials used. Worse still, the related information generally reaches with a signicant delay to the hospital management. Keywords: Healthcare; supply chain management (SCM); service oriented architecture (SOA); vendor managed inventory (VMI).

1. Introduction Ferihan La in Hospital is a medium-scale 53-bed hospital. Four different groups c of materials are used during a work day: 1. Ordinary Supplies: These are the materials used in a hotel management like paper towels, bedclothes, soap, cleansing agent, or disinfectants. This kind of material is not included in the scope of this research.3

4

S. N. Turhan and O. Vayvay

2. Drugs: This group consists of the typical drugs used in a hospital including anesthetic drugs. 3. Medical Materials: This group contains medical disposable items, surgical dressing, medical papers used in medical devices such as electrocardiographs, etc. 4. Special Surgical Materials and Equipment: This group contains special surgical materials such as stents, thin tube inserted into a tubular structure (e.g., a blood vessel) to hold it open or remove a blockage, or prosthetic and orthopedic products. This group has a difference from the other groups. For the other groups, the hospitals employers such as doctors, practitioners, nurses, and technicians have the opportunity to decide the quantity of materials that they are going to consume while working. The decision on the use of materials by this group may only be made by specialist(s) like surgeon(s); however, even they, most of the time, do not have any exact idea on how many they will consume during the operation. They need to make this decision during the operation. Because of this constraint, the management of supply chain of these materials is completely different from the others. Currently, in the hospital, there are neither any rules dened for the inventory management nor for a complete SCM. There is only a pharmacist and a staff member working in the hospitals pharmacy. All purchasing affairs for all materials are done by them. In fact, working understaffed is a very common feature that we face in small- and medium-sized hospitals. The pharmacists mission is to control and audit all the drugs used all over the hospital, especially the anesthetic drugs. They are also responsible to assure the presence of the medical materials. It is also the pharmacists responsibility to update supplier information, net cost of procurement, batch sizes, and so forth. On the other hand, their performance measure is to provide the correct materials, at the required time. In healthcare cases, time is a big constraint because even a delay of a second may cause a big problem for the life of a person. The staff working with them are not qualied personnel who have a formation of pharmaceutics. They are responsible to manage the orders and the payments, control the bills, enter the bills information to the information system of the hospital, check the boxes, and get the proposals from the suppliers. The proposal must contain the information about medical supplies unit prices and the conditions of payment. All the proposals are examined by pharmacist and purchasing director, and they decide together on the supplier from which the materials will be purchased. A simple order process done by the staff consists of following steps: 1. Taking the proposal from the different suppliers. 2. Introduce the candidate suppliers proposal to pharmacist and purchasing director to determine the right one. 3. Call the supplier determined by the pharmacist and the purchasing director via phone, fax, and e-mail. 4. Make the order.

Health Care Supply Chain Information Systems VIA SOA

5

This system has several weaknesses. First, there are no prescribed parameters to dene the quantity of such orders. The pharmacist decides the quantity of the materials intuitively. This process is also time consuming because the pharmacist must check the materials one by one every day and the staff must spend hours and hours to communicate with the suppliers to get the proposals, and place the orders. On the other hand, the system has also a bad effect on the suppliers side. They are always enforced to provide the necessary item in a short period, sometimes in a day. They always have to be ready to answer the hospitals demands quickly and this causes a big competition in the market. The last weakness is caused by the payment schedule of Turkish government. The major part of the healthcare costs in Turkey is still being covered by the government. The market share of the private health insurance companies that exist in this sector is not signicant. Today, only 1 out of 162 people has a private health insurance. However, the Turkish government can only disburse the payments to private hospital in 3 months. Under these circumstances, the hospitals also propose to suppliers to make payment with a delay of 3 months. Most of the medical materials are very expensive with a big cost; both suppliers and hospitals face the difculties to manage their nancial situation. All these problems are getting worse in the case of special surgical materials and equipments. On the other hand, the competition among the small- and medium-scale hospitals is growing intensely; therefore, all hospitals have to improve their quality of healthcare services while reducing their operational cost. The research has started with analysis of business process and system requirements of this specic application in a hospital.a Then, a new idea has been developed to control the purchases and consume the special medical and surgical devices especially during the operation. A telemedicine application is implemented between the hospital information system and government system to provide a real-time online observation for the surgical operation. On the other hand, all processes have been designed according to service-oriented architecture (SOA) because SOA provides a much more agile environment for process orchestration, for integration across applications, and for collaboration between users. Each process has been dened as a Web Service (WS). With this architecture, another problem may be possible: The structure of the information exchanged. Allowing cooperation among distributed and heterogeneous applications is a major need for the current system. In this research, we try to model an efcient pharmaceutical SCM to eliminate the problems cited above. The new system is developed to optimize inventory control, reduce material handling cost, and manage the balance of payment among the government and the suppliers. SCM is a strategy for optimizing the overall supply chain by sharing information among material suppliers, manufacturers, distributors, and retailers (Dona et al., 2001). Our supply chain consists of suppliers, hospitals, and the government. Thea Ferihan La in Hospital, Istanbul, Turkey. www.ferihanlacin.com c

6

S. N. Turhan and O. Vayvay

key element of SCM is information sharing (Dona et al., 2001). Information sharing improves collaboration among the supply chain to manage material ow efciently and reduces inventory cost (EHCR Committee, 2001). Therefore, we decided to adopt a vendor-managed inventory (VMI) model to optimize the inventory control and then reengineer the processes according to a new architecture SOA. Besides, we try to propose a different management style for the usage of special surgical materials and equipment and their SCM. In Sec. 2, the suggested process remodeling will be revealed item by item while dening VMI. Section 3 illustrates all the technologies used. Finally, benets of the developed system will be discussed. 2. Process Remodeling 2.1. Constraints It is very difcult to design an efcient pharmaceutical system to improve the Quality of Services (QoS) given to the patients, while there are not any rules determined by the hospital management. Of course, the hospitals management takes the TQM rules seriously, but the processes are never examined, and never documented. On the other hand, the nature of supply chain is very complex. The rst objective of this supply chain is not only to lower procurement cost and improve cash ow, but also to assure the appropriate drug, medical materials, or special surgical materials at the right time, in the right place. Another important issue is the preservation of the drugs. Each drug has an expiry date and some of them, for example, anesthetic drugs need to be more safely preserved. The innovation and changes in the drug sector are very often and it is very usual to substitute a drug not found with an equivalent one. Then, an information system adoption is needed but information sharing (IS) adoption in healthcare affects and is affected by human and organizational actors (Vasiliki et al., 2007). Thus, it is not only the information systems that need to be put in place, but also an effective process solution for how to transfer demand is needed (Riikka et al., 2002). As there is no efcient and effective inventory control in the hospital, we decided to adopt our new SCM system modeled according to SOA principles with VMI techniques. Before implementing our system, the information shared between supplier and hospital, between hospital and government, and between supplier and government was insufcient. Eventually, this results in a high rate of emergency order calls, high stock levels, bad balance of payments, and, of course, patient dissatisfaction. To solve this problem, we rst started to implement a VMI system in hospital warehouses. We show that by effectively harnessing the information now available, one can design and operate the supply chain much more efciently and effectively than ever before.

Health Care Supply Chain Information Systems VIA SOA

7

2.2. What is VMI? VMI approach can improve supply chain performance by decreasing inventoryrelated costs and increasing customer service. Unlike a traditional supply chain wherein each member manages its own inventories and makes individual stocking decision, VMI is a collaborative initiative where a downstream customer (a hospital in our case) shifts the ownership of inventories to its immediate upstream supplier and allows the supplier to access its demand information in return. In particular, a VMI process involves the following two steps: (1) a downstream customer provides demand information to its immediate upstream supplier and leaves the stocking decisions to that supplier; and (2) the upstream supplier has the ownership of the inventories till the inventories are shipped to the customer and bears the risk of demand uncertainty. It is not difcult to see that the VMI structure promotes collaborations between suppliers and customers through information sharing and business process reengineering. VMI is an alternative for the traditional order-based replenishment practices. VMI changes the approach for solving the problem of supply chain coordination. Instead of just putting more pressure on suppliers performance by requiring ever faster and more accurate deliveries, VMI gives the supplier both responsibility and authority to manage the entire replenishment process. The customer company (a hospital in our case) provides the supplier access to inventory and demand information and sets the targets for availability. Thereafter, the supplier decides when and how much to deliver. The measure for suppliers performance is no more delivery time and preciseness; it is availability and inventory turnover. This is a fundamental change that affects the operational mode for both the customer and at the supplier company. Therefore, the advantages to both parties must be evident to make the shift to VMI happen (Lee and Whang, 2000). We cannot deny the advantages of VMI in our case. Before implementing VMI, it was the pharmacists mission to manage the inventory which resulted in inefciencies. The adoption of VMI is started by contracts among suppliers and hospital. These contracts are realized not only on the paper, but also via WSs too (which will be described in the next section). In the contracts, the role of controlling inventory level of each drug or medical supply is given for an appropriate supplier by dening the unit price and payment schedule. With this system, the suppliers experts control the stock level instead of the pharmacist. The new system allows the pharmacists do their own job, and also create the time available for the supplier to plan deliveries. It is obvious that the more time the supplier has for planning, the better it is able to serve the hospital and optimize operations. The other problem faced in hospital inventory management is having no proper classication schema. There are so many different drugs and medical supply. Each of them is produced by different manufacturer and may be used as a substitute for

8

S. N. Turhan and O. Vayvay

a different one. It is very inefcient to manage all these products without a proper classication because it is not possible to make a contract for each of them. We already mentioned that the stock control will be done by suppliers experts. Here, the main question is who will decide for order quantity. We did not leave the decision of order quantity either to suppliers expert or to pharmacist. Order quantities are calculated by the information system based on demand forecasting and safety stock levels. The hospital has its own information system to manage the stock level of each product. Our system will use information produced by this system to get order quantities. 2.3. Information and Document Sharing IS is a collaborative program in which the downstream rm (referred to as the hospital herein) agrees to provide demand and inventory status in real time to the upstream rm (referred to as a supplier herein) (Lee and Whang, 2000). VMI provides a closer collaboration between the supplier and hospital in our case. That is why the hospital must be able to reengineer its process through real-time information sharing, enabled by electronic data interchange (EDI). With this system, we propose to provide an integrate information sharing between hospital and suppliers, and between hospital and government. By sharing information about product usage between them, it is much easiest to keep the inventory level at a proper level. Besides, the system must have the ability to keep the logs of products, insurance codes, and information about new drugs. We designed the system to be accessible in real time, and to be integrated via WSs with any service provider including government. With the new architecture, all the processes are remodeled according to SOA principles. While remodeling the processes, we took into consideration the WSs policy dened by the Turkish government, the standards, and protocols produced by Health Level Seven which is one of several American National Standards Institute (ANSI)-accredited Standards Developing Organizations (SDOs) operating in the healthcare arena, for a particular healthcare domain such as pharmacy, medical devices, imaging or insurance (claims processing) transactions, the codes dened by Anatomical Therapeutic Chemical Classication System with Dened Daily Doses (ATC/DDD) index published by WHO, and by National Information Bank (UBB) published by Ministry of Health of Turkey. On the other hand, the hospitals traditional method of exchanging and processing orders and orders documents via phone or fax machine results with time inefciency and high rate of error. The process depends totally on staffs performance, which is not acceptable in the healthcare case. The system offers the to suppliers to get the order requirements, to control the inventory level of hospitals central warehouse and exchange documents in XML formats, via WSs. With this system model, order processing of supply chain participants can be enhanced signicantly.

Health Care Supply Chain Information Systems VIA SOA

9

2.4. What is Service Oriented Architecture (SOA)? With the growth of real-time computing and communication technologies like the Internet, batch interfaces were posing a challenge. When the latest information about a given business entity was not updated in all dependent systems, it resulted in a loss of business opportunity, decreased customer satisfaction, and increasing problems. SOA may be seen as the new face of enterprise application integration (EAI). We can also dene SOA as a business-driven information technology (IT) architectural approach that helps businesses innovate by ensuring that IT systems can adapt quickly, easily, and economically to support rapidly changing business needs. SOA is not a technology. It is an architectural approach built around existing technologies. SOA advocates a set of practices, disciplines, designs, and guidelines that can be applied using one or more technologies and being an architectural concept, it is exible enough to lend itself to multiple denitions. SOA offers a unique perspective into business that was previously unavailable: It offers a realtime view of what is happening in terms of transactions, usage, and so forth. In anticipation of the discovery of new business opportunities or threats, the SOA architectural style aims to provide enterprise business solutions that can extend or change on demand. SOA solutions are composed of reusable services, with well-dened, published and standards-compliant interfaces. SOA provides a mechanism for integrating existing legacy applications regardless of their platform or language. The key element of SOA is the service. A service can be described as a component capable of performing a task (David and Lawrence, 2004). Although a service can be seen as a task or an activity, it is more complicated than these concepts. This is due to the fact that every service has a contract, an interface, and an implementation routine. Josuttis (2007) states that a service has the following attributes: Self-contained: Self-contained means independent and autonomous. Although there can be exceptions, a service should be self-contained. In order for the services to be self-contained, their inter-dependencies should be kept in a minimum level. Coarse-grained: It indicates the implementation detail level of services for consumers. Implementation details are hidden for a service consumer because the consumer does not care about such details. Visible/Discoverable: A service should be visible and easily reachable. This is important also for reusability which means that a service can be used multiple times in multiple systems. Stateless: Services, ideally, but not always, should be stateless. This means that a service request does not affect another request because service calls do not hold invocation parameters and execution attributes in a stateless service.

10

S. N. Turhan and O. Vayvay

Idempotent: Idempotent means the ability of redo or rollback. In some cases, while a service is executing, a bad response can be returned to the service consumer. In such a case, service consumers can rollback or redo the service execution. Composable: For a composable service, the service can contain several subservices, where they can be separated from the main service. A composable service can call another composable service. QoS and Service Level Agreement (SLA)-Capable:A service should provide some non-functional requirements such as runtime performance, reliability, availability, and security. These requirements represent QoS and SLA. Pre- and Post-conditions: Pre- and post-conditions specify the constraints and benets of the service execution. Pre-condition represents the state before the service execution. Post-condition represents the state after the service execution. Vendor Diverse: SOA is neither a technology nor a product. It is also platform (or vendor) independent. This means that it can be implemented by different products. When calling a service, one does not need to be familiar with the technology used for the service. Interoperable: Services should be highly interoperable. They can be called from any other systems. Interoperability provides the ability of different systems and organization to work together. In other words, services can be called from any other system regardless of the types of environment for them. The second important issue is to dene explicitly two key roles in an SOA: the service provider and service consumer. Service provider publishes a service description and provides the implementation for the service, whereas service consumer can either use the uniform resource identier for the service description directly or can nd the service description in a service registry and bind and invoke the service. In Fig. 1, the relationship between a service provider and a service consumer is illustrated. As we mentioned above, a service is a software resource with an externalized service description. This service description is available for searching, binding, and invocation by a service consumer. The service provider realizes the service description implementation and also delivers the QoS requirements to the service consumer. Services should ideally be governed by declarative policies and thus support a dynamically re-congurable architectural style. The services can be used across internal business units or across the value chains among business partners in a fractal realization pattern. Fractal realization refers to the ability of an architectural style to apply its patterns and the roles associated with the participants in its interaction model in a composite manner. It can be applied to one tier in architecture and to multiple tiers across the enterprise architecture. That is why dening the services according to SOA concepts must be the most

Health Care Supply Chain Information Systems VIA SOA

11

Figure 1.

SP&SC relationship ( c IBM).

crucial step while modeling a system. Conceptually, there are three major levels of abstraction within SOA: Operations: Transactions that represent single logical units of work (LUWs). Execution of an operation will typically cause one or more persistent data records to be read, written, or modied. SOA operations are directly comparable to objectoriented (OO) methods. They have a specic, structured interface, and return structured responses. Just as for methods, the execution of a specic operation might involve invocation of additional operations. Services: Represent logical groupings of operations. Business Processes: A long running set of actions or activities performed with specic business goals in mind. Business processes typically encompass multiple service invocations. According to Ali Arsanjani, PhD, Chief Architect, SOA and WSs Center of Excellence, IBM, the process of service-oriented modeling and architecture consists of three general steps: identication, specication and realization of services, components and ows (typically, choreography of services). Service identication: This process consists of a combination of top-down, bottom-up, and middle-out techniques of domain decomposition, existing asset analysis, and goal-service modeling. In the top-down view, a blueprint of business use cases provides the specication for business services. This top-down process is often referred to as domain decomposition, which consists of the decomposition of the business domain into its functional areas and subsystems, including its ow or process decomposition into processes, subprocesses, and high-level business use cases. These use cases often are very good candidates for business services exposed at the edge of the enterprise, or for those used within the boundaries of the enterprise across lines of business.

12

S. N. Turhan and O. Vayvay

In the bottom-up portion of the process or existing system analysis, existing systems are analyzed and selected as viable candidates for providing lower cost solutions for the implementation of underlying service functionality that supports the business process. In this process, you analyze and leverage APIs, transactions, and modules from legacy and packaged applications. In some cases, componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality. The middle-out view consists of goal-service modeling to validate and unearth other services not captured by either top-down or bottom-up service identication approaches. It ties services to goals and subgoals, key performance indicators, and metrics. Service classication or categorization: This activity is started when services have been identied. It is important to start service classication into a service hierarchy, reecting the composite or fractal nature of services: services can and should be composed of ner-grained components and services. Classication helps determine composition and layering, as well as coordinates building of interdependent services based on the hierarchy. Also, it helps alleviate the service proliferation syndrome in which an increasing number of small-grained services get dened, designed, and deployed with very little governance, resulting in major performance, scalability, and management issues. More importantly, service proliferation fails to provide services, which are useful to the business, that allow for the economies of scale to be achieved. Subsystem analysis: This activity takes the subsystems found above during domain decomposition and species the interdependencies and ow between the subsystems. It also puts the use cases identied during domain decomposition as exposed services on the subsystem interface. The analysis of the subsystem consists of creating object models to represent the internal workings and designs of the containing subsystems that will expose the services and realize them. The design construct of subsystem will then be realized as an implementation construct of a large-grained component realizing the services in the following activity. Component specication: In the next major activity, the details of the component that implement the services are specied: Data Rules Services Congurable prole Variations

Messaging and events specications and management denition occur at this step. Service allocation: Service allocation consists of assigning services to the subsystems that have been identied so far. These subsystems have enterprise components that realize their published functionality. Often you make the simplifying

Health Care Supply Chain Information Systems VIA SOA

13

assumption that the subsystem has a one-to-one correspondence with the enterprise components. Structuring components occurs when you use patterns to construct enterprise components with a combination of: Mediators Fa ade c Rule objects Congurable proles Factories

Service allocation also consists of assigning the services and the components that realize them to the layers in SOA. Allocation of components and services to layers in the SOA is a key task that requires the documentation and resolution of key architectural decisions that relate not only to the application architecture but also to the technical operational architecture designed and used to support the SOA realization at runtime. Service realization: This step recognizes that the software that realizes a given service must be selected or custom-built. Other options that are available include integration, transformation, subscription, and outsourcing of parts of the functionality using WSs. In this step, which legacy system module will be used to realize a given service and which services will be built from the ground-up will be decided. Other realization decisions for services other than business functionality include security, management, and monitoring of services. In reality, projects tend to capitalize on any amount of parallel efforts to meet closing windows of opportunity. Top-down domain decomposition (process modeling and decomposition, variation-oriented analysis, policy and business rules analysis, and domain specic behavior modeling (using grammars and diagrams) is conducted in parallel with a bottom-up analysis of existing legacy assets that are candidates for componentization (modularization) and service exposure. To catch the business intent behind the project and to align services with this business intent, goal-service modeling is conducted. In SOA terms, a business process consists of a series of operations which are executed in an ordered sequence according to a set of business rules. The sequencing, selection, and execution of operations are termed service or process choreography. Typically, choreographed services are invoked to respond to business events. Therefore, we have to model our business processes according to service concepts. SOA and design are another concepts from the other analysis and modeling. Service-oriented modeling requires additional activities and artifacts that are not found in traditional OO analysis and design. Experience from early SOA implementation projects suggests that existing development processes and notations such as Object Oriented Analysis and Design (OOAD), Enterprise Architecture (EA), and business process management (BPM) only cover part of the requirements needed to

14

S. N. Turhan and O. Vayvay

support the SOA paradigm. While the SOA approach reinforces well-established, general software architecture principles such as information hiding, modularization, and separation of concerns, it also adds additional themes such as service choreography, service repositories, and the service bus middleware pattern, which require explicit attention during modeling (Olaf et al., 2004). There is one more important point that we have to mention here. When one starts an SOA project, the rst thing that comes to mind is to dene WSs. Yet, the SOA research road map denes several roles. The service requester or client and provider must both agree on the service description (Web Service Denition Language WSDL denition) and semantics that will govern the interaction between them for WSs to interact properly in composite applications. A complete solution must address semantics not only at the terminology level, but also at the levels that WSs are used and applied in the context of business scenarios the business process and protocol levels. Thus, a client and provider must agree on the implied processing, context, and sequencing of messages exchanged between interacting services that are part of a business process. In addition to the classical roles of service client and provider, the road map also denes the roles of service aggregator and operator. Service modeling and service-oriented engineering service-oriented analysis, design and development techniques, and methodologies are crucial elements for creating meaningful services and business process specications. These are an important requirement for SOA applications that leverage WSs and apply equally well to all three service plans. SOA should abstract away the logic at the application or business level, such as order processing, from non-business-related aspects at the system level, such as the implementation of transactions, security, and reliability policies. This abstraction should enable the composition of distributed business processes and transactions. The software industry now widely implements a thin Simple Object Access Protocol (SOAP)/WSDL/Universal Description Discovery and Integration (UDDI) veneer atop existing applications or components that implement the WSs, but this is insufcient for commercial-strength enterprise applications. Unless the components nature makes it suitable for use as a WS (and most are not) properly delivering components functionality through a WS takes serious redesign effort (Papazoglou et al., 2007). On the other hand, our job would not be complete by only dening these services according to SOA. While migrating to SOA, there are some other points that should be taken into consideration. These include: Adoption and Maturity Models: Every different level of adoption has its own unique needs; therefore, the maturity level of enterprise in the adoption of SOA and WSs must be determined at the beginning. Assessments: During the migration, controls and assessment must be done after each step.

Health Care Supply Chain Information Systems VIA SOA

15

Strategy and Planning Activities: The steps, tools, methods, technologies, standards, and training which must be taken into account must be declared at the beginning. Therefore, a roadmap must be represented. Governance: SOA has the ability to use legacy applications API as a service. Every API must be examined to decide which one is eligible? Every service should be created with the intent to bring value to the business in some way. 3. Case Study Our main goal in this study is to implement the application of both new working areas to transform the supply chain to a single, integrated model to improve patient care and customer service, while decreasing procurement costs. The rst one is to reengineer business processes with SOA. The second one is to be able to make an SOA modeling. As stated in the paper of Zimmerman et al. (2004) SOA modeling is a very new area, and there are no dened strict rules on this subject. Therefore, we rst debuted by modeling VMI that we described above according to SOA. All the departments request necessary items and the items are delivered from hospitals warehouse to the requesting departments. As a requirement of the denition of VMI, the supplier needs to manage the hospitals overall inventory control system and order processing system and then makes the order delivery schedule according to the contract signed by the supplier and the hospital. In a traditional VMI system, the supplier takes both responsibility and authority to manage the entire replenishment process. The customer company provides the supplier access to the inventory and demand information and sets the targets for availability (Riikka et al., 2002). Here, instead of allowing the supplier to intervene directly to the legacy system used by the hospital, we believe that it would be more appropriate to produce the information needed by the supplier by a service architecture and orchestration on the system. Although one may think that such a business process modeling may be realized by other modeling types like OOD or EA, it is certain that Service OrientedArchitecture Design (SOAD) will be more efcient in dening the human-based task that we eventually need in this modeling. SOAD must be predominantly process, rather than use-case driven. The method is no longer use case-oriented, but driven by business events and processes. Use case modeling comes in as a second step on a lower level. In the SOA paradigm, business process choreography, maintained externally to the services, determines the sequence and timing of execution of the service invocations. SOAD provides an excellent solution to these issues. As it groups services on the basis of related behavior, rather than encapsulated (behavior plus data), the set of services will be subtly different from a business object model. The order is created when stock amount is less than Stock Keeping Unit (SKU) calculated by the legacy system of hospital. For each pharmaceutical, a separate

16

S. N. Turhan and O. Vayvay

order item is created, containing details of order quantities and the rules dened in the contract. As the supplier manages the hospitals stock, hes ready to provide the necessary amount of this pharmaceutical. The main problem is the delivery lead time. A suitable shipping way needs to be scheduled for each pharmaceutical. Each dispatch may contain one/several pharmaceutical. It must be determined which pharmaceutical has urgency, or which one may be dispatched with the others. When the items come to the hospital, the pharmacist and the employee must verify the boxes and approve the task waiting on the system to declare that the order is correct. If it is not correct, they must specify the details, and a new job will start for the mistakes. When they approve that the order is correct, the suppliers legacy system will produce the invoice and send the invoice via WSs to hospital to get the payment. The second part of supply chain is the receipt of the payment of the necessary amount of the consumed products either from the insurance companies or the government. In this way, it is expected that the invoices of the products that have been used for the favor of the patients should be sent to the Ministry of Health and the payment should be done against these invoices. The payment part includes the payment that will be done to the suppliers from the hospitals and to the hospitals from either the government or the insurance companies upon the control and the approval of the invoices. These transactions are structured again on the WSs and the orchestration among them. The main point here, as we mentioned before, is to provide the supply of the expensive products that have been decided to be used during the operation while their usage number and their payment conditions are still unknown. The system established may send the necessary information to the information systems of both suppliers and of the Ministry of Health or the related insurance company once the date and venue of the operation, and the type and the estimated amount of the products that will be used during the operation are decided. The telemedicine support that we explained earlier, steps in here. To enable the doctors to communicate easily and to access the system from anywhere independently from their daily computers, a telemedicine module has been designed by using the Adobe Flash technology, which is very common nowadays. With the help of this module, the end users may communicate with each other either interactively or in the way of one-sided video conference. To make all the correspondence possible to be watched again, the le extension .v has been selected. These les are stored under the folders that have been named by the variables that belong to the system and that determine the owners. There is also another separated database where all the data related to these les are stored. This method has been selected to facilitate the management and to diminish the load into the database. The Red5 Open Source Flash Server that uses the Real Time Messaging Protocol (RTMP) protocol that provides the simultaneous exchange of information has been selected as server. On the other hand, the Flash Media Server can also be used as an alternative to this server. In this way, the operation may be watched both in real time or later on in the desired period. This also provides

Health Care Supply Chain Information Systems VIA SOA

17

the opportunity of making a decision on the necessity of the products used during the operation not only from the epicrisis, but also from watching the actual operation. This is certainly an important step to decide unbiasedly without any external inuence. Processes are modeled according to SOA and we obtained the services cited below in the gure: 1. Supplier service a. Lookup the supplier by contract b. Create the new supplier c. Get the supplier information 2. Inventory service (legacy system) a. Determine the quantity on hand of item b. Comparing with SKU level c. Determine the order quantity d. Expected arrival date e. Inventory management i. Physical review ii. Closing 3. Order service a. Create the order b. Schedule the order date and time c. Get the offerings d. Delivery order e. Receive the delivery 4. Scheduling service a. Take the delivery schedule b. Schedule the delivery date and time 5. Payment service a. Hospital-Supplier b. Government/IC-Hospital 6. Telemedicine service a. Approval of medical supply usage and its quantity b. Rejection of medical supply usage and its quantity 7. Utilization service a. Create the new utilization by departments b. Status tracking of delivery request c. Decrease the stock quantity d. Increase the usage amount e. Markup the patients le

18

S. N. Turhan and O. Vayvay

Services are modeled in Fig. 2:

Figure 2.

Services.

4. System Implementation While modeling and implementing the system, we used IBM DB2 Express-C, IBM Websphere Application Server 6.1, IBM Websphere Business Modeler 6.1, IBM Rational Software Architect 6.1, IBM Websphere Integration Developer 6.1, IBM Websphere Process Server 6.1, and IBM Websphere Monitor 6.1. We have used Websphere 6.1 Feature Pack for WSs, which has been installed on our application server, namely, Websphere Application Server 6.1. We decided to select this software because it allows us to communicate with other vendors in a more reliable, asynchronous, secure, and interoperable way. It also enables support for the Java API for XML Web Services (JAX-WS) 2.0 programming model and the SOAP 1.2 that may remove most of the ambiguities that existed in the previous versions of SOAP. As it may be well known, JAX-WS 2.0 is a Java programming model to create WSs. Its most important feature is that it provides an asynchronous client model. This makes easier to develop and deploy WSs. Another important feature of the JAX-WS can be cited as supporting WS-I Basic Prole 1.1. The WSs that have been developed by using the JAX-WS can be consumed by any client which has been previously developed by any programming language supporting this basic prole.

Health Care Supply Chain Information Systems VIA SOA

19

XML Binding for Java (JAXB) enables data mapping between XML Schema and JAVA. XML is contained in the SOAP message, and without knowing how to parse SOAP and XML messages, JAXB denes this binding for us. On the other hand, SOAP with Attachments for Java (SAAJ) enables dealing with XML attachments in SOAP messages. Figure 3 illustrates which product is used in which step. Before coding the WSs, we have rst modeled the BPM with Websphere Business Modeler 6.1. The process ow is shown in Appendix A. Then we dene the services one by one as illustrated in Fig. 2. For the service orchestration, SOA needs a middleware which is generally Enterprise Service Bus (ESB). In our project, we prefer to use WebSphere Business Process Execution Language (WS-BPEL) as service orchestration tool. WS-BPEL is an orchestration language. An orchestration mentions executable process which means to intercommunicate with other systems dynamically and the control of this process is done by an orchestration designer such as WebSphere Process Server. This language combines two notions: 1. BPM and 2. Web Services (WSs)

Figure 3.

Software used.

20

S. N. Turhan and O. Vayvay

The most crucial step in todays business world is to manage and improve their business processes while workow components must be loosely coupled and run interoperable. In this point, Web Services are in action. Web Services are self-contained, modular business blocks that achieve interoperability between applications. They use Web standards such as WSDL, UDDI, and SOAP. In real life scenarios, we need to join different WSs and to use them as a whole entity of WSs. This is where, we need a new language that encapsulates, all WSs needed and exposes the business process as a unique WS: the WS-BPEL. In WS-BPEL technique, the business process is dened as follows: A business process species the potential execution order of operations from a collection of WSs, the data shared between these WSs, which partners are involved and how they are involved in the business process, joint exception handling for collections of WSs, and other issues involving how multiple services and organizations participate. (Sanjiva and Francisco, 2002). WS-BPEL extends the WSs interaction model and enables it to support business transactions. WS-BPEL uses WSDL to specify an interface between the business process and the world outside by describing actions in a business process and the WSs provided by a business process. The business process itself and its partners (services with which a business process interacts) are modeled as WSDL services. So, WS-BPEL has a role to compose existing services. The business process is described as a collection of WSDL portTypes, just like any other WS as illustrated in Fig. 4. WS-BPEL is the top layer which uses a middleware layer WSDL using SOAP, a protocol to exchange structured information. UDDI is on top of SOAP, which is a registry of all publishing WSs. We prefer to model the orchestration of WSs with WS-BPEL because WS-BPEL can handle complex cases. For example, it is usable with loops and scopes in a business process logic, which is not supported by an ESB. We need long-running business processes where we need to maintain the state information of the process, which is also not supported by an ESB.

Figure 4. WS dened by WS-BPEL.

Health Care Supply Chain Information Systems VIA SOA

21

With WS-BPEL, we are able to orchestrate a business process where we use WebSphere Process Server as the business process choreographer. One of the major features of WPS is that it supports human tasks, which enable human activities to be invoked as services. And human activities have an important role in healthcare industry. Our requirements are process-centric so WS-BPEL is the better choice in this project. In our scenario, each pharmaceutical is provided from a specic medical supplier in a specic quantity. All this information is kept in database tables. In the SUPPLIER table, there is a eld named Endpoint Address, there is information about the medical suppliers end-point address. So when a pharmaceutical quantity is not sufcient in the stock, a trigger is red and a WS request is sent to WS provider, the medical supplier. This is where we are a consumer. There are WSs that we offer to our partner medical suppliers. They can control our stock to learn the quantity of pharmaceuticals that we have, and to hold ready their own stock. This is where we are a provider. In the big picture, we are a consumer and also a provider, this is where SOA begins. 5. Conclusion When analyzed, it has been observed that the system that we try to establish has many benets. First, thanks to the VMI application, the workloads of the pharmacists and the other employees have been decreased. In Turkey, there is no obligation of employing a pharmacist for the hospitals that have less than 100 beds. Taking this account, this system by the unication of the different applications of the telemedicine may also help the pharmacist to support more than one hospital. This situation will be the subject of another study. On the other hand, thanks to this application, the pharmacist is no longer expected to be knowledgeable about the stock management or the cost reduction but on the contrary these operations will be realized by the real experts. Moreover, there are many benets in the stock management as well. The drugs are difcult materials to store and preserve. In fact, each drug has an expiry date. There is an enormous number of different drugs and most of the drugs may be used equivalently instead of each other. Besides, as we mentioned before, in the healthcare sector, the nonexistence may produce more serious results as the human life is concerned. Therefore, an effective stock management that has been structured in this way, and an efcient material handling at the same time, will certainly improve the quality of the service offered to the patients in the hospital. Second, the information integration and a successful supply chain will eventually result in a strong integration among the partners of the system, i.e., the government, hospitals, and wholesalers. Thanks to the services produced, all the required information may be used by the other institutions within the limit of the permission given by the service provider institution. The only constraint here is that each provider and the consumer must work with the same semantic to understand the WSs. Furthermore, the applications liable to human error, such as lost papers among the les, the products that are forgotten to be ordered, and numerous phone calls, will be totally removed. When the specic importance of the sector studied is taken

22

S. N. Turhan and O. Vayvay

into account, it is extremely important to minimize the deadlocks arising from the human mistakes. The system established provides also a serious prot both in making the orders and in the stock management. We still do not have feedback on the results of the government/insurance company hospital integration that has been recommended especially for consumables, as this system has not been yet implemented when this chapter is written. However, it is obvious that the system is extremely interesting. A pharmaceutical including the special purposed ones, SCM system to optimize the supply chain has been modeled and developed in this research. Although the whole supply chain is composed of raw material suppliers, pharmaceuticals companies, wholesalers, hospitals, and patients, we focused especially on implementing a new model, non-traditional VMI system in hospital warehouse by sharing electronic data via WSs between hospitals and wholesalers. We cannot deny that there is a lot of effort still required to improve the efciency of the total supply chain with regard to manufacturers, the government, and insurance companies. Also, hospitals must be willing to adopt this system, have total trust in their wholesalers, and share their inventory information with them. To extend the benets presented in this chapter, standards for exchanging information electronically must be established and adopted. This is where semantics of WSs begins and occupies a big place in exchanging the data. ReferencesArbietmann, D, E Lirov, R Lirov and Y Lirov (2001). E-commerce for healthcare supply procurement. Journal of Healthcare Information Management, 15(1), 6172. Arsanjani, A (2004). Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA. IBM Whitepaper, November 2004, http://www. ibm.com/developerworks/library/ws-soa-design1 Cingil, I and A Dogac (2001). An architecture for supply chain integration and automation on the internet. Distributed and Parallel Databases, 10, 59102. EHCR Committee (2001). Improving Supply Chain Management for Better Healthcare http://www.eccc.org/ehcr/ehcr/ Erl, T (2005). Service-Oriented Architecture, A Field Guide to Integrating XML and Web Services. Prentice Hall, NJ, USA. Josuttis, NM (2007). SOA in Practice, The Art of Distributed System Design. e-book, OReilly Media Inc., USA. Jung, S, T-W Chang, E Sim and J Park (2005). Vendor managed inventory and its effect in the supply chain, AsiaSim 2004, LNAI 3398, 545552. Kaipia, R, J Holmstr m and K Tanskanen (2002). VMI, What are you loosing if you let o your customer place orders? Journal of Production Planning & Control, 13(1), 1725. Lee, HL and S Whang (2000). Information sharing in a supply chain. International Journal of Manufacturing Technology and Management, 1(1), 7993. Leymann, F, D Roller and M-T Schmidt (2002). Web services and business process management. IBM Systems Journal, 41(2), 198211. Mantzana, V, M Themistocleous, Z Irani and V Morabito (2007). Identifying healthcare actors involved in the adoption of information systems. European Journal of Information Systems, 16, 91102.

Health Care Supply Chain Information Systems VIA SOA

23

Omar, WM and A Taleb-Bendiab (2006). Service-oriented architecture and computing. IT Professional, 3541. Papazoglou, MP and B Kratz (2007). Web services technology in support of business transactions, Service Oriented Computing and Applications, 1(1), 5163. Papazoglou, MP, P Traverso, S Dustdor and F Leymann (2007). Service-oriented computing: State of the art and research challenges. Journal of Computer, IEEE Computer Society, June, 3845. Polatoglu, VN (2006). Nazar foods company: Business process redesign under supply chain management context. Journal of Cases on Information Technology, 214. Siau, K (2003). Health care informatics. IEEE Transactions on Information Technology in Biomedicine, 7(1), 17. Simchi-Levi, D, P Kaminsky and E Simchi-Levi (2008). Designing and Managing The Supply Chain, Concepts, Strategies, and Case Studies, 3rd Edn., Mc Graw-Hill Irvin. Sprott, S and L Wikes (2004). Understanding service-oriented architecture, CBDI Forum. The Architectural Journal, 1, 2. Weerawarana, S and F Curbera (2002). Business process with BPEL4WS: Understanding BPEL4WS, Part 1, concepts in business processes. IBM Whitepaper, August 2002. http://www.ibm.com/developerworks/webservices/library/ws-bpelcol1 Yao, Y and M Dresner (2008). The inventory value of information sharing, continuous replenishment, and vendor-managed inventory. Transportation Research Part E, 44, 361378. Zimmerman, O, P Krogdahl and and C Ghee (2004). Elements of service-oriented analysis and design, an interdisciplinary modeling approach for SOA projects. IBM Whitepaper, June 2004 http://www.ibm.com/developerworks/webservices/library/ws-soad1

Biographical Notes Sultan N. Turhan received her ASc degree in computer programming in 1992 from Bo azi i University, her BA degree in business administration in 1998 from Marg c mara University, and her MSc degree in computational science and engineering in 2003 from Istanbul Technical University. She is currently a PhD student of Engineering Management in Marmara University and her research subject is industrial applications of datawarehouses. Between 1992 and 1998, she worked as database administrator, IT project coordinator, and IT manager responsible in different institutions. Since 1998, she has been working as senior lecturer in Computer Engineering Department of Galatasaray University. Since 2002, she has also been working for Intelitek Element A.S as an academic consultant for distance learning and e-learning platforms. Her professional interests are synchronized distance learning, e-learning, databases, datawarehouses, data mining, and knowledge management. Ozalp Vayvay, PhD, is working in Industrial Engineering Department at Marmara University. He is currently the Chairman of the Engineering Management Department at Marmara University. His current research interests include new product design, technology management, business process reengineering, total quality management, operations management and supply chain management. Dr. Vayvay has been involved in R&D projects and education programs over the past 10 years.

24

S. N. Turhan and O. Vayvay

Workow diagram

Appendix A

Chapter 2

The Role of the CIO in the Development of Interoperable Information Systems in Healthcare Organizations ANTONIO GRILO,$ , LU VELEZ LAPAO , IS RICARDO JARDIM-GONCALVES and VIRGILIO CRUZ-MACHADO, UNIDEMI, Faculdade de Ci ncias e Tecnologia e da Universidade Nova de Lisboa, Portugal INOV INESC Inova ao, Lisboa and CINTESIS, c Faculdade de Medicina da Universidade do Porto, Porto, Portugal UNINOVA, Faculdade de Ci ncias e Tecnologia e da Universidade Nova de Lisboa, Portugal $ [email protected]; [email protected] [email protected]; [email protected]

A major challenge for business information systems (BIS) design and management within healthcare units is the need to accommodate the complexity and changeability in terms of their clinical protocols, technology, business and administrative processes. Interoperability is the response to these demands, but there are many ways to achieve an interoperable information system. In this chapter we address the requirements of a healthcare interoperability framework to enhance enterprise architecture interoperability of healthcare organizations, while maintaining the organizations technical and operational environments, and installed technology. The healthcare interoperability framework is grounded on the combination of model driven architecture (MDA) and service-oriented architecture (SOA) technologies. The main argument in this chapter is to advocate the role of chief information ofcer (CIO) in dealing with challenges posed by the need to achieve BIS grounded on interoperability at the different layers, and in developing and executing an interoperability strategy, which must be aligned with the health organizations business, administrative, and clinical processes. A case study of the Hospital de S o Sebasti o is described demonstrating the a a critical role of the CIO for the development of an interoperable platform. Keywords: Interoperability; healthcare; chief information ofcer; complexity; model driven architecture (MDA); service-oriented architecture (SOA); healthcare interoperability framework.

25

26

A. Grilo et al.

1. Overview The healthcare sector is characterized by complexity and rapid developments in terms of clinical protocols, technology, business and administrative processes. This poses a major challenge for the BIS design and management within healthcare units, as there is a need for ICT infrastructure to accommodate the changes while simultaneously responding to the pressure to have integrated information ows. Interoperability is the response to these demands, but there are many ways to achieve an interoperable information system. In Sec. 2 of this chapter we describe the existing general approaches for developing information systems that are able to cope with interoperability requirements, and review the main concepts of the model-driven architecture (MDA) and serviceoriented architecture (SOA) approaches. In Sec. 3, we point out the importance of information systems (IS) in the healthcare sector, the IS functions on healthcare units, the case for the need for interoperability and nally, a generic healthcare interoperability framework that combines MDA and SOA. The main argument of this chapter of the book is laid out in Sec. 4, where we advocate the critical role of the CIO in developing and implementing adequate but complex information systems strategies, supported by a exible and robust healthcare interoperability framework that leads to integration/interoperable platforms. The argument advanced is grounded on the increasing business, cross-functional, and leadership skills that are required to convince decision makers to produce the investment (resources, time, patience) needed for the deployment of interoperable ICT infrastructures. Section 5 describes the case study of Hospital S o Sebasti o a a (HSS), an innovative and vanguard Portuguese hospital that has implemented an interoperable platform for internal purposes, as the information systems strategy was grounded on having best-of-breed for each functional business, administrative and clinical applications. The case illustrates how the CIO of the HSS has developed and implemented the interoperable platform grounded on the healthcare interoperable framework (HIF) and the importance of his different skills in order to achieve success in the endeavor. Finally, Sec. 6 concludes with a look at the increasing relevance that the CIO will have in healthcare units as the dynamics of healthcare continues to accelerate and evolve. Moreover, it addresses, as future challenge, the need to understand and model the role of the CIO using complex systems theory. 2. Business Information Management Systems and Interoperability Today, many proposals are available to represent data models and services for the main business and manufacturing activities, and the same holds true for the health sector. Some are released with International Standards (e.g., ISO, UN), others are developed at the regional or national level (e.g., CEN, DIN), and others are developed by independent project teams and groups (e.g., OMG, W3C, IAI, ebXML).

The Role of the CIO in the Development of Interoperable Information Systems 27

Most of the available healthcare standard-based models have been developed in close contact with the health service industry, including the requirements of public and private organizations, following an established methodology. They use optimized software architectures, conferring congurable mechanisms focused on the concepts of extensibility and easy reuse. However, in the foreseen and desired BIS scenario of collaboration and exibility, the heterogeneity and inadequacy to support interoperability of the selected and needed objects is delaying and even preventing its full integration, even when the objects are standard-based. Studies have shown that interoperability within and across public and private health organizations is far from being a reality, particularly in health public sector organizations (Kuhn et al., 2007). For the adoption of standardized models, processes, and services to be considered appropriate, applications must be prepared with suitable mechanisms and standardized interfaces easily adaptable for fast and reliable plug-and-play. Hence, the use of effective and de facto standards to represent data, knowledge, and services has shown to be fundamental in helping interoperability between systems. Thus, today this poses a major challenge to those responsible for designing and implementing BIS for health organizations. 2.1. Model-Driven Architecture The object management group (OMG) has been proposing the model-driven architecture (MDA) as a reference for achieving wide interoperability of enterprise models and software applications. MDA provides specications for an open architecture appropriate for the integration of systems at different levels of abstraction and through the entire information systems life cycle (Mellor, 2004; Miller and Mukerji, 2001). Thus, this architecture is designed to incite interoperability of the information models independently of the framework in use (i.e., operating system, modeling and programming language, data servers, and repositories). The MDA comprises three main layers (Mellor, 2004; MDA, 2006). The CIM (computation-independent model) is the top layer and represents the most abstract model of the system, describing its domain. A CIM is a stakeholders-oriented representation of a system from the computation-independent viewpoint. A CIM focuses on the business and manufacturing environment in which a system will be used, abstracting from the technical details of the structure of the implementation system. The middle layer is the PIM (platform-independent model), and denes the conceptual model based on visual diagrams, use-case diagrams, and metadata. To do so it uses the standards UML (unied modeling language), OCL (object constraint language), XMI (XML metadata interchange), MOF (meta-object facility), and CWM (common warehouse metamodel). Thus, the PIM denes an application protocol in its full scope of functionality, without platform dependencies and constraints. For an unambiguous and complete denition, the formal description of the

28

A. Grilo et al.

PIM should use the correct business vocabulary, and choose the proper use-cases and interface specications. The PSM (platform-specic model) is the bottom layer of the MDA. It differs from the PIM as it targets a specic implementation platform. Therefore the implementation method of the MDA, also known as model-driven development (MDD), is achieved through a transformation that converts the PIM to the PSM. This procedure can be followed through automatic code-generation for most of the systems backbone platforms, considering middleware-specic constraints, e.g., CORBA, .NET, J2EE, Web Services. The research community is also developing and validating other proposals, including those known as executable UML. With it, the abstract models described in UML are implemented and tested at a conceptual level, i.e., PIM, before transforming them to be implemented in the targeted platform (Mellor, 2004). 2.2. The Service-Oriented Architecture The World Wide Web Consortium (W3C) refers to the service-oriented architecture (SOA) as a set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C, 2006). Also, and according to Microsoft, the goal for SOA is a world-wide mesh of collaborating services that are published and available for invocation on a service bus (SOA, 2006). SOA does not consider the service architecture from a technological perspective alone, but also proposes a normalized service-oriented environment (SOE) offering servicesdescription, registration, publication, and search functionalities (Figure 1). Placing its emphasis on interoperability, SOA combines the capacity to invoke remote objects and functions, i.e., the services, with standardized mechanisms for active and universal service discovery and execution. The service-oriented architecture offers mechanisms of exibility and interoperability that allow different technologies to be integrated with great effectiveness, independent of the system platform in use. This architecture promotes reusability, and it has reduced the time to make available and gain access to a new systems functionalities, allowing enterprises to dynamically publish, discover, and aggregate aService Broker

Publish Register

Search Find

Service Consumer

Bind/InteractClient

Service description Service Service Provider

Figure 1. Service-oriented environment based on SOA.

The Role of the CIO in the Development of Interoperable Information Systems 29

range of web services through the Internet. Thus, SOA encourages organizations to focus on their business and services, free of the constraints of the applications and platforms. This is an essential feature for organizations to achieve information technology independence, business exibility, agile partnership, and seamless integration into collaborative working environments and digital ecosystems. Well known organizations include Microsofts DCOM, IBMs DSOM protocol, and the OMGs Object Request Brokers (ORBs) based on the CORBA specication. Today, the use of W3Cs web services is expanding rapidly as the need for application-to-application communication and interoperability grows. These can implement a business process integrating services developed internally and externally to the company, providing a standard means of communication among different software applications running on a variety of heterogeneous platforms through the Internet. Web services are implemented in XML (eXtended Markup Language). The network services are described using the WSDL (Web Services Description Language), and the SOAP (Simple Object Access Protocol) is the communication protocol adopted. The registration of the services is in the UDDI registry (Universal Description, Discovery and Integration). Although providing a signicant contribution, the SOA alone is not yet the answer to achieve seamless interoperability between applications. For example, despite the efforts undertaken to ensure compatibility between all the SOAP implementations, there still exists no unique standard. The Web Services Interoperability Organization, WS-I, is a good example of an organization supporting Web services interoperability across platforms, operating systems, and programming languages. WS-I has been developing mechanisms for the convergence and support of generic protocols in the interoperable exchange of messages between web services (WS-I, 2006).

3. Interoperability in the Healthcare Context Healthcare services have been pushed toward change mostly due to the awareness of the increasing costs and large inefciencies in the system. It is now accepted that healthcare is one of the most complex businesses, with a large diversity of types of interactions (Plsek and Wilson, 2001; Lap o, 2007a). Using IT to support the sera vices delivery may overcome part of the complexity. New IT solutions for sharing and interacting indeed represent an opportunity to further enhance citizens participation in the healthcare process, which could improve the services outcomes. Smith (1997) and IOM (2001) have proposed that only IT can bridge this chasm. IT represents a hope to help process change to occur and to create new sorts of services focused on satisfying citizens real needs. It is therefore necessary to develop communication strategies toward citizens properly aligned with the healthcare network services delivery strategy.

30

A. Grilo et al.

Interoperability of healthcare systems can play a critical role in this process of communication. Several e-Health initiatives and projects have been developed in recent years, some more successful than others, but in general, the Information and Communication Technologies (ICT) used were not integrated into a broader egovernment strategic plan. There is the awareness that these projects also represent an opportunity to learn and improve the way we are using ICT in healthcare. Todays healthcare technologies allow easy and fast detection of tumors, probing of tiny catheter into the heart to clean arteries, destruction of kidney calcications without touching the skin. Nevertheless, simple things, such as distributing the right medicines at the right place or making sure the doctors appointment takes place at the right time, can still represent enormous challenges (Lap o, 2007b; a Mango and Shapiro, 2001). Progress has been slow. Healy (2000) considers that healthcare ICT Systems are simply following a logistic curve, evolving like other industries, only lagging behind. Some examples of how ICT can be combined to offer high-valued services to end-users, either domain experts or patients are