Case studies are valuable tools in academics as well as in professional practice. Case studies illuminate how products or service

6 Bar Coding: It’s Hard to Kill a Hippo

Margaret Keller, Beverly Oneida, and Gale McCarty

For years, the quality improvement committee (QIC) at University Hospital had been collecting incident reports documenting errors in patient ID, medication administra- tion, and specimen collection. QIC became interested in the possibility of utilizing bar code technology to enhance patient care by decreasing these types of errors. After failing in an effort 2 years earlier, a bar coding project team was built consisting of rep- resentatives from admitting, pharmacy, clinical labs, clinical engineering, medical center computing (MCC), hospital procurement, operations improvement, quality improve- ment, and health unit coordination. The project was defined and divided into three phases for ease of implementation and cost control. The team decided to start with the least expensive and least controversial project, replacement of the “B-plates.” These plates are the embossed, credit card–like plates used to stamp patient ID information on all hospital and major procedure documentation and on ID bracelets. The Address- ograph typeface embossing machines used to make the patient ID blue plates were known as “hippos,” because of their resemblance to the open mouth of a hippopotamus.”

Valentine’s Day 2001

“One step forward and two steps back . . . ,” mused the usually optimistic Janet Erwin, director of value analysis and operations improvement, who was beginning to worry about the timeline she had set for implementation of phase I of her bar coding project. As the strains of her singing Valentine faded and the February 14 meeting began in earnest, she reviewed the phase 1 goal: replacement of the B-plate system of inpatient ID with bar coding technology in order to provide accurate and legible patient ID information at the time a patient presents to the health system for admission or for extended periods of care. The requirements for the bar coding project are:

• Use patient ID technology to support bar code and/or radiofrequency applications to enhance patient safety and to increase staff efficiency

• Limit noise production on patient care units • Eliminate hand writing of patient ID • Use technology that supports a secure patient ID band system based on patient age • Eliminate the need to replace patient ID bands when a patient transfers from unit

to unit

65

LTF6 10/11/2004 8:42 AM Page 65

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

• Produce printed patient information on patient ID bands and patient ID labels including the patient’s full name, medical record number, gender, account number, and date of birth.

Subsequent phases of the project were envisioned to include medication and lab spec- imen/collection tracking (phase II); equipment, personnel, and patient tracking; and mother/baby ID (phase III).

Janet had been brought into the project early in 1999 and had worked hard to deter- mine the problems with the current system as well as a technology solution. The entire project had been initiated not only in response to dissatisfaction with the current B- plate system but also because of an overall desire to eliminate errors in patient ID, medication administration, and specimen collection. Bar coding had been used in the lab for 15 years, and in the pharmacy for 5 years, so the technology base was familiar to end users. Janet felt there was no support in the medical center for keeping the current B-plate system, so replacing it with more advanced technology seemed to be a good initial project for the QIC. The discussion today centered on phase I of the total patient ID initiative and whether a solution should be developed in-house or pursued with a third-party vendor. The MCC division was reluctant to support in-house development.

The View from MCC

The quietly commanding voice of Carl Cusak, chief information officer, resonated from behind his desktop, laptop, and personal digital assistant (PDA), all on active screens, as he summarized the reasons why he needed to call “time out” on the bar code project and “regroup” to a prior point in the planning process. “Most projects involving advanced technology and informatics at University Hospital begin with fervor, energy and commitment, but often fail because pertinent points in process development are assumed or overlooked,” he noted. Carl spoke with the authority of his experience.

The lack of MCC involvement meant that technical requirements had never been defined, including details such as standards for data input, hardware infrastructure requirements, or a charter document stating the purpose, scope, timeline, or product development requirements. In addition, software specifications and interface require- ments were lacking. Carl also felt that little attention was being paid to the substruc- ture and interface problems inherent in bar coding, i.e., the capability of the bar code reader to read the code on a patient’s wrist band. The use of radiofrequency technol- ogy and the use of hardware such as PDAs into which the bar code could be uploaded via a software program, allowing real-time ID of patients and tracking, were consid- ered, but the benefits and drawbacks were not well researched. Backup strategies for unanticipated breakdowns in the system also had not been defined.

Carl complemented some of the long-standing individuals involved with the bar code project, such as Janet, for their commitment and effort. He noted that bar coding had long been used for applications in the pharmacy, the operating room, central supply, and the lab. Despite these varied uses of bar coding at University Hospital, however, no standards had evolved among these bar coding efforts. Carl admitted that MCC should have taken ownership of these disparate bar coding projects earlier and should have become the major shareholder in bar coding development. However, MCC personnel changes and priority mandates had kept it from assigning the necessary resources to the project.

66 Section III. Implementation

LTF6 10/11/2004 8:42 AM Page 66

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

6. Bar Coding: It’s Hard to Kill a Hippo 67

“I can’t believe that the bar coding initiative could still become an in-house devel- opment project at this point!” said Chris Matt, a QIC member who could remember when the idea of replacing the B-plates with bar code technology was brought up back in 1996. On the surface, the project seemed to be popular enough with anyone involved with direct patient care to ensure its success. MCC, however, had been so busy with other projects that the perceived lack of immediacy or of a high-level champion had tabled the bar coding initiative in the past.

With an increased focus on all patient safety issues, especially those related to ID, the QIC continued to identify and evaluate examples of potential problems. It seemed that once ID issues were examined, the scope of the concerns grew. Chris noted that the team went from a working goal of all patients having an ID wristband to that of all patients having a correct ID wristband. It became evident that something had to change to prevent a potential catastrophe. Processes tightened, but the basic difficul- ties surrounding the lack of clear, accurate, consistent patient ID were now in the spotlight.

On April 13, 2000, the request for proposal (RFP) was developed and distributed to certain third-party vendors for response. Chris was not happy to hear that phase I of the project could still end up being accomplished in-house, despite the RFP responses. If that was the decision, the project could have been completed a long time ago.

Needs of End Users

Charlotte Graham, inpatient admitting director, had been involved with the bar coding project from the start. After all, her area would be affected the most by any change in inpatient ID. Over the years, she had heard the complaints about the current system. She knew well how costly the “hippos” were and how much maintenance they required, and she was aware of the poor quality of many of the imprints. She also realized that the B-plates often did not get to their destination in a timely fashion, as they were gen- erated in admitting and put in a central location for transportation to pick up. Even after pickup, the plates were taken to a sorting area and often awaited transport to the units. Some plates never reached their destination and had to be regenerated. This was especially true for unplanned admissions that were brought directly to the floor or were admitted through a major procedure area. Charlotte realized that while mistakes could not be totally eliminated, there was a need to minimize the areas where mistakes could be made. She saw bar coding as a tried-and-true method of inventory control that could be easily adapted to track patients and match patients to their records, films, or specimens.

Charlotte was disappointed to be back at the point of considering an in-house solu- tion to the problem. If the project was not contracted out to a third-party vendor, it would need to be interfaced with the current admitting information system, which was very old and in need of being upgraded. The admitting information system was cur- rently used to maintain demographic, billing, and visit information on all patients seen at University Hospital. Charlotte also felt that the current admitting information system could not support phases II and III of the project in the future.

In addition to Charlotte and her admitting staff, the front-line people, including unit coordinators, nurses, doctors, therapists, etc., would be directly affected by a change in the method of patient ID. One of their representatives on the project team was Risi Kay, an administrative assistant with experience working on the inpatient units.

LTF6 10/11/2004 8:42 AM Page 67

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

Risi felt that despite the fact that most people would be happy to see the B-plates gone, a bar code system with labels would probably require a little more effort. This would especially be true during off-shifts, when unit coordinators were not available, as someone would have to be able to generate additional patient ID labels as they were needed. Just who would be trained to use the new system had not been determined. Time was often in short supply in completing day-to-day patient care activities. Ease of use and an institutionwide consistency of flow would be critical.

The Decision and the Implementation Plan

While awaiting the final word from MCC, Janet mused, “I would be delighted if we could do this project in-house, as long as we could meet goals and project deadlines. . . . It would be so much easier . . . it would help having MCC own this with us.”

On March 20, an update meeting was held. It was noted that MCC had successfully generated patient identified bar codes from the admitting information system and had designed a system that permitted additional patient ID labels to be printed on request. They had also been able to generate various font sizes that would be consistent with adult, pediatric, or neonate bandwidths. The RFP for phase I was then canceled. The RFPs for phases II and III would remain open to enable University Hospital to better evaluate the available technology solutions for future phases.

It had been a long time coming, but Janet enjoyed the feeling of satisfaction she was experiencing with a job well done. She finally had her project on the agenda of the information technology governance committee, and with their support she felt that it would become a reality. “I am not going to dwell on the issue that this should have been happening all along, but hopefully the process that we have all had to go through will have a positive effect on other projects that go forward and require everyone to be on the same page and same priority level.” Jane sat at her desk and smiled.

Questions

1. How could the MCC group have better worked with the end users on the bar coding project?

2. Develop a plan for moving patient identification to phase II. 3. What strategies could the QIC develop with the MCC to ensure future coopera-

tion? 4. Was bar coding a good first project? Why? Why not?

68 Section III. Implementation

LTF6 10/11/2004 8:42 AM Page 68

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

7 Developing an Emergency Department Information System

Duncan Belser, Dominik Aronsky, David M. Dilts, and Jose Ferreira

It was the summer of 1997 when executive leadership and managers from the emer- gency department (ED) and the informatics center first teamed up to contemplate implementing an information system to support clinical processes and administrative functions in the ED. Three years later, the same group, with a few new members, by then called the emergency department information system (EDIS) team, abandoned its efforts to purchase an off-the-shelf solution and commissioned the development of a set of custom interfaces to the institution’s multitude of existing applications. After two more years, the most central and publicly visible of these components, the elec- tronic whiteboard (eWB), successfully passed its first uninterrupted overnight usabil- ity test. After more than 5 years of effort, the passage of this milestone marked a long overdue win for the EDIS team.

Although the project achieved its stated objectives, why had it taken so long? What, if anything, could have been done differently to speed up the process? More impor- tantly, what could be learned from this experience to facilitate other healthcare infor- matics projects in the future? To answer these questions, we examined the history of the development and implementation of the EDIS from its inception to the imple- mentation of the eWB in September 2002. (See Table 7.1 for the EDIS project time- line.) Through interviews with key project participants, analysis of project documents, and discussions with other relevant stakeholders, it appears that the project was com- plicated and prolonged initially by the team’s inability to find a suitable solution in the vendor marketplace and subsequently by delays associated with designing and rapid- prototyping a custom information system. In retrospect, it is also apparent that the project is best described not as one activity but two that occurred as separate phases marked by distinct differences in scope, approach, goal setting, leadership, and out- comes. This chapter presents the relevant history of each phase and traces the major distinctions between them that we believe show the lessons to be learned from the experience.

Early History of the EDIS Project

By the spring of 1997, service levels in the ED required serious attention. Foremost, wait times were well above industry benchmarks and patient satisfaction was low. Addi- tionally, referring primary care providers consistently complained about poor notifica- tion while their patients were in the ED, and few were satisfied with the summary reports provided after discharge. Finally, according to an internal study, 76 percent of

69

LTF7 10/11/2004 8:43 AM Page 69

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

70 Section III. Implementation

TABLE 7.1. EDIS project timeline.

• July 1997—EDIS steering committee decides to investigate technology solutions to transform emergency department (ED) operations.

• November and December 1997—External consultants conduct ED operational review.

• January 1998—ED considers piloting an application to replace transcription. • July 1998—Computerization work group produces request for information entitled “Functional

Requirements for Patient Tracking System” for circulation to vendors. • July 1998—EDIS team begins investigating vendors of off-the-shelf patient tracking system

solutions.

• EDIS team continues investigating vendors of off-the-shelf patient tracking system solutions.

• March 2000—EDIS team holds kickoff meeting to discuss purpose, priorities, and issues related to implementing an information system in the ED.

• September 2000—EDIS team decides to build an ED patient tracking system that integrates with existing information systems and identifies key functional requirements, proposed data flow, and action steps.

• January 2001—EDIS team presents data flow diagram for ED processes. • March 2001—Hospital administration approves budget to update network and install hardware

in the adult and pediatric emergency departments for EDIS. • Spring 2001:

1. EDIS team gets new project manager with Informatics and ED experience. 2. EDIS team begins meeting with the ED staff weekly. 3. EDIS team presents prototype of an ED information system.

• June 2001—EDIS team introduces Web cam to broadcast the dry-erase board to the registration area.

• July 2001—EDIS team receives approval to hire a programmer/developer. • September 2001—EDIS team redesigns adult ED registration process by focusing on speed

(rapid registration). • October 2001—EDIS team implements rapid registration process in the adult and pediatric

EDs (including completing the installation of a wireless network). • Fall 2001:

1. EDIS team hires a programmer/developer to work on the Web-based EDIS as first priority. 2. EDIS team demonstrates early ED whiteboard prototype.

• March 2002—EDIS team completes early manual for ED whiteboard application and begins developing user training materials, including Web-based training tools.

• April–May 2002: 1. EDIS team presents electronic whiteboard (eWb) Overview presentation to the ED and

suggests a plan for a staged go-live, first using existing systems in tandem use, then without original marker board; includes documented contents to maintain and role-based responsibilities.

2. ED nurse educator, assistant managers, and managers conduct user training on the job. • September 19, 2002—eWB application completes first overnight operational usability test. • December 11, 2002—EDIS project manager produces first new reports on ED operational

statistics for September, October, and November using EDIS.

P h

ase I P

h ase I

1997 1998

1999 2000

2001 2002

the ED faculty and 58 percent of the ED nursing staff were dissatisfied with the exist- ing technology resources that were in place to facilitate the clinical and administrative functions of the department.

In reaction to these issues, the EDIS steering committee convened a team of infor- matics and ED staff members (Table 7.2) on July 14, 1997, to discuss how information technology might be applied to ease the operational problems in the ED. The team,

LTF7 10/11/2004 8:43 AM Page 70

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

7. Developing an Emergency Department Information System 71

composed of representatives and executives from a broad number of hospital func- tions, immediately targeted what it identified as two separate problems. First, they brainstormed a preliminary list of features the department would require in a system to manage its information needs; and, second, the group hired a team of external con- sultants to conduct an operational review of the ED and recommend key changes to improve satisfaction and performance.

Over the course of November and December of 1997, external consultants inter- viewed a number of patients and staff and examined most of the department’s core processes. In a February 1998 report, they highlighted five key factors that were nega- tively affecting the service environment in the ED. Specifically, they noted ambiguity among staff roles and a general lack of concern for patient or referring physician sat- isfaction. They also reported that staffing levels were not well matched to patient volumes, managers could not monitor occupancy levels efficiently in real time, and administration of the cross-function paper-based processes was highly cumbersome. They recommended that the department would benefit from service-oriented team- building exercises, focused discussions around job duties with respect to departmental responsibilities, and, as examined below, implementation of a suitable information system to measure and coordinate its activities.

Regarding the department’s need for an information system, the consultants specif- ically noted that volatility in daily and sometimes hourly demand for emergency serv- ices often resulted in gaps between the number of patients waiting to be seen and the number of providers available to care for them. It was primarily these gaps that caused excessive wait times and, consequently, drove down patient satisfaction. However, gaps were compounded by the fact that department managers could not efficiently monitor and adapt to changes in occupancy. Rather, they could only rely on retrospective and time-consuming analysis of historical throughput metrics (admissions, discharges, etc.) for ex post facto guidance in staffing model planning. The right information manage- ment system, it was expected, would enable dynamic monitoring of waiting and care delivery areas. Monitoring data collected by the system, combined with rules-based condition triggers embedded in the software, could alert managers to react when some- thing unusual happened, e.g., if, on a hypothetical Friday, demand peaked in the morning rush hour rather than as usual in the afternoon or early evening because of an accident on the nearby interstate.

TABLE 7.2. EDIS Team. Emergency department (ED) representatives Informatics department representatives

• Chair of the Department of Emergency Medicinea • Director of informatics centera

• ED administrative directora • Members of the order entry application team • Director of adult EDa • Members of the information systems support team • Director of pediatric ED • Chief technology officer • Manager of adult ED • Chief information officer • Assistant manager of adult ED • Information services consultants (to serve as • Manager of pediatric ED project managers until Spring 2001) • Assistant manager of pediatric ED • EDIS lead programmer/developer (since Fall • Director of admitting 2001 • Director of ED finances • EDIS project manager** (informatics faculty; • ED nurse educator since Spring 2001) • Director of ED registration (added in 2001)

a Member of the EDIS steering committee.

LTF7 10/11/2004 8:43 AM Page 71

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

72 Section III. Implementation

In addition to the lack of real-time activity monitoring and staffing-level planning capabilities, the consultants observed that data collection for care delivery and admin- istration required an unmanageable and often unorganized volume of paperwork. In fact, they observed, paper-based processes in the ED were so cumbersome that they were a major cause of dissatisfaction to all parties involved and a primary obstacle to preparing documents for referring physicians. Perhaps worse, some paperwork was the limiting factor in the speed of care delivery sequences. For example, in patient regis- tration, lengthy forms had to be completed before triage could be performed—a major source of patient dissatisfaction. In addition, discharge summaries were challenging to create because information was stored in collections of charts and shadow charts throughout the care delivery process. An appropriate information system, it was thought, could reduce the paperwork onus by separating information collection activ- ities from care delivery sequences. Such a resource would centralize information man- agement and enable report production on demand.

With these findings in mind, the EDIS team began discussing possible information technology solutions. Because the institution had considerable experience with build- ing its own clinical applications, the debate quickly centered around evaluating the classic “build-vs.-buy” decision. In many ways, however, these conversations were pre- mature because the question of what to buy or build had never been completely clar- ified. Some favored implementing a patient tracking system and advocated scouring the marketplace for vendor solutions. Others with a broader interest began defining the feature set of a tool to meet a variety of the department’s operational needs. As one might have expected, there were also a few who resisted the effort entirely, expect- ing that the ED physicians would never adopt such a system.

Eventually, because of the substantial patient satisfaction and care delivery issues associated with the department’s long wait and throughput times, the team focused on acquiring a system for real-time activity monitoring and resource management. In what ultimately was a fateful choice, solving the paper-based process challenges became a secondary priority. Instead, the dominant vision became that of a patient tracking system that could be used to capture time-and-motion statistics that would help man- agers identify those situations when waiting areas grew full or process bottlenecks that needed to be addressed. They planned that ED nurses and staff would keep the system current by recording the time of each patient’s check-in, triage, encounter, discharge, etc., and thereby the task of tracking patients through departmental areas would be accomplished. With this in mind, team members finalized their desired functional requirements for a tracking system by early July 1998 (Table 7.3) and began evaluat- ing vendor solutions in late summer.

Despite a rather confident start, success did not come quickly. To the contrary, the group corresponded with almost a dozen vendors for the next 18 months and held numerous meetings to no avail. There were, in fact, major issues with the team’s approach that complicated the project. Foremost, it proved impossible to find a system that could be cost-effectively integrated with the array of internally developed and continuously evolving applications already in use throughout the medical center. Although legacy system issues were common to similar information technology projects, they were particularly limiting in this circumstance because the environment was changing at a rapid pace of two or three major clinical application additions each year. Furthermore, the team eventually concluded that vendor dependency would reduce the organization’s flexibility to implement software design changes in future versions. Because flexibility was particularly important in the context of such a dynamic

LTF7 10/11/2004 8:43 AM Page 72

Co py ri gh t © 2 00 5. S pr in ge r. A ll r ig ht s re se rv ed . Ma y no t be r ep ro du ce d in a ny f or m wi th ou t pe rm is si on f ro m th e pu bl is he r, e xc ep t fa ir u se s pe rm

it te d un de r U. S. o r

ap pl ic ab le c op yr ig ht l aw .

EBSCO Publishing : eBook Collection (EBSCOhost) – printed on 3/9/2022 6:29 AM via WALDEN UNIVERSITY AN: 145750 ; Nancy M. Lorenzi, Joan S. Ash, Jonathan Einbinder, Wendy McPhee, Laura Einbinder.; Transforming Health Care Through Information Account: s6527200

7. Developing an Emergency Department Information System 73

system environment, the team was reluctant to make any commitment to an external party.

Perhaps even worse, the market for ED information systems was in its infancy at the time. As such, the risk of los

Collepals.com Plagiarism Free Papers

Are you looking for custom essay writing service or even dissertation writing services? Just request for our write my paper service, and we'll match you with the best essay writer in your subject! With an exceptional team of professional academic experts in a wide range of subjects, we can guarantee you an unrivaled quality of custom-written papers.

Get ZERO PLAGIARISM, HUMAN WRITTEN ESSAYS

Why Hire Collepals.com writers to do your paper?

Quality- We are experienced and have access to ample research materials.

We write plagiarism Free Content

Confidential- We never share or sell your personal information to third parties.

Support-Chat with us today! We are always waiting to answer all your questions.