Q. How has information technology (IT) dealt with regulatory issues (e.g., Sarbanes-Oxley, the Health Insurance Portability and Accountability Act, 21 

 Part 11 have been well understood (and implemented) by the industry for several years. However, for the first time, the life sciences industry is feeling the need to manage regulatory compliance across regulations on a risk-based approach.  Often, there is one officer in the company who is charged with regulatory compliance, and this officer is keenly interested in mitigating risk proactively in a unified governance framework for the company. 

The cost of noncompliance has become almost unfathomable in the pharmaceutical industry. Companies that are affected by noncompliance (be it a SOX [Sarbanes-Oxley] associated restatement or an FDA consent decree) suffer far beyond the superficial commercial aspects.  Corporate culture, leadership, confidence in management, and even the capability to recruit and maintain talent are severely challenged.  As a result, chief regulatory officers in the life sciences industry are at a very strategic helm, and their direct relevance to business continuity and growth is becoming well understood by boards of directors and investors. 

Q. Which regulatory requirements are the most challenging and why?

For each company, a given regulation could impose challenges that are particularly difficult within their specific business. Sarbanes-Oxley provides great challenges because the extent to which companies interpret and implement regulatory compliance is sometimes subjective. As a result, companies usually go overboard in an attempt to remove regulatory risk altogether. On the other hand, with regulations such as 21 

Part 11 and the like, the scope is well understood, but the challenge with these initiatives is the cost of validation. Often the cost and complexity of validation is extremely high, enough to thwart continuous improvement initiatives. 

Q. What industry (outside life sciences) that you know of has a good handle in dealing with regulatory compliance, and why?

Financial services firms, by the nature of their business, have incorporated risk-based strategies in their regulatory compliance initiatives for years. This makes them extremely resilient to sporadic noncompliance, changing regulations, changing market conditions, and changing customer requirements. 

Q. How creative can software makers be when providing compliance solutions? Is there room for 'out-of-the-box' thinking?

Compliance is always a combination of process documentation and recording of deviations (potential, or real) from such processes. Scientifically speaking, unless all processes can be standardized across the industry, it would be impossible for any company to develop an out-of-the-box compliance solution. However, there are some process areas that are reasonably standard in the life sciences industry, and we are working toward some prebuilt compliance tools for some standard business processes and functions. 

Q. Do you have any comments on regulatory requirements outside the United States?

Local regulations (or "localizations") are the cost of doing business globally. In today's economy, this is a need that cannot be ignored. We, at Oracle, have seen a trend toward incorporating local financial regulations in shared service transaction processing environments.  

Q. Do you foresee unified global regulatory requirements?

To some extent, there already are unified world regulatory requirements. Market-leading regulatory bodies, such as FDA and the USDA, assume leadership roles in implementing world-wide regulations. Their regulations are immediately adopted with little or no variations by regulatory bodies in other countries. Often individual countries might adopt a superset of FDA regulations by combining FDA regulations with country-specific codes developed by their regulatory bodies. The cost of not doing business with the US is so great, that we believe that bodies such as FDA and USDA truly have a global impact. 

Q. What advice do you have for drug makers in meeting the regulatory requirements?

'Be ahead of the curve' is the best advice we could give the industry. If possible, work with regulatory bodies to understand key regulatory initiatives that are in progress and the potential impact of these regulations on the real world. Attempt to influence the regulations by positive collaborative efforts across the industry. Undertake research and development efforts to implement (or simulate), in a small laboratory environment, regulatory compliance before regulations are enacted. 

Q. What challenges do you have in integrating technology from different vendors with your product (for example, with a Windows server)?

Standards adoption is the most challenging aspect of integration projects.  If two technologies adopt open standards, integration becomes a nonissue. On the other hand, if two proprietary standards-based technologies need to be integrated, the result is expensive and complex integration. Oracle is doing its part to enable low-cost integration by basing its integration platform (Oracle Fusion Middleware) on open standards. Similarly, our application integration architecture (AIA), an open, standards-based platform for business process management across Oracle, third-party and custom applications make it easy to integrate our products with others. 

Q. What integration issues do you see up and coming in all type of industries, and any specific challenges in the pharmaceutical industry?

The traditional point-to-point integration model has outlived its utility.  In most industries, chief information officers are asking us for a hub-based integration framework that can incorporate an enterprise-wide common object model. Such an architecture makes it easy to plug and play applications over time, without undertaking massive integration projects. Pharmaceutical companies are beginning to adopt this model as well and are trying to understand the impact of regulatory constraints on the adoption of such models. 

Q. What are the top three applications that are typically interfaced with your products? And what are the challenges in interfacing with applications with different languages (character sets)?

1. Factory-level shop floor (such as process control and process scheduling applications) 

2. Statistical packages for highly advanced and specific data analysis  

3. Third-party (legacy) business intelligence products. As long as all these applications accept unicode characters, integration with these applications should not be an issue.  However, some applications are less "internationally robust" than others, and unique character sets, such as the Japanese character set, can pose a problem. 

Q. Some companies face challenges in integrating MES (Manufacturing Execution Systems) to Enterprise Resource Planning (ERP) applications. What is your company doing to help ease this integration?

Oracle is adopting the S95 standard aggressively and using this standard to guide our AIA strategy and approach, where appropriate. 

Q. Do you have any thoughts on virtualization (e.g., virtual servers) and the impact of this to your business and to the pharmaceutical industry?

[A few years ago, Oracle introduced] real application clusters, which support the deployment of a single database across a cluster of servers—providing strong fault tolerance, performance, and scalability. We aggressively promote the virtualization of an application environment through the implementation of machine clusters. This drastically lowers the cost of ownership, as a group of several smaller machines is often a small fraction of the cost of a much larger machine, and the risk of failure of a cluster is infinitesimal, as well. The adoption of this approach by the industry has been a strong validation of our commitment to lower total cost of ownership for our customers. 

Q. Do you outsource application development outside the US? Do you have any comments on the trend toward outsourcing?

Oracle has software development teams in several countries around the world. We have aggressively embraced globalization as a key option for attracting the required talent to fuel our research and development engine.  However, we do not typically call this outsourcing, as software development is undertaken by Oracle employees in these countries who are trained on our methodologies and standards and are subject to extremely stringent hiring criteria. So, we leverage a global pool of talent without having to outsource a key business function.

Q. What are the top three questions that your helpdesk gets from users in the pharmaceutical industry? And why do you think those are the most-asked questions?

Of the number of service requests logged in our support applications, very few actually require a software "patch." The vast majority of issues can be resolved by more aggressive end-user training.  We are attempting to integrate end-user training with the application footprint with products such as the Oracle User Productivity Kit, a synchronized, customizable solution that helps organizations quickly create the critical documentation, training, and support materials needed to drive project team and user productivity throughout the life cycle of a user's software.  

Q. What technology should be used more by members of the pharmaceutical industry in their 'supply-chain' business? Do you see the 'auto replenishment' feature being used in drug making?

Understanding downstream supply chain and 'demand' more accurately is a key area of focus for the pharmaceutical industry.  Auto-replenishment (loosely called 'KanBan') is already used for various direct materials and will continue to be adopted by the industry.   

Q. What advice can you offer the pharmaceutical industry about facing the challenges of counterfeiting?

Electronic pedigrees and RFID [radio frequency identification] solutions will greatly reduce the problems of counterfeits, grey-market sales, diversions and so on. In addition, product recalls, returns, chargebacks, and the like are all simplified and can be sources of significant savings through the adoption of such technology.  

Q. Can you talk more about how RFID is used in the pharmaceutical industry?

RFID is important from two perspectives. First, it is an efficient technology that can allow a large pallet of finished products to be "scanned" in a single pass without having to unpack boxes and scan bottles one by one. Secondly, RFID is accurate, and can enable supply-chain accuracy by automating supply-chain inventory information management. As the cost of RFID chips and scanners drop, we anticipate worldwide adoption of these technologies—not just across the supply chain, but also within manufacturing plants. 

Q. How is software being used in clinical trials? 

Companies are looking for a clinical platform that can manage all clinical operations in a consolidated and integrated technology base. This is becoming even more important as companies are buying pipeline from others (or are licensing them from biotechs), or are merging with and acquiring other companies.  Because clinical operations are the vital bloodline of these companies, it is strategically important to support this area with a comprehensive solution footprint and an overarching business intelligence approach. Our customers are asking the software industry for a comprehensive solution footprint that includes clinical trial management, clinical supplies management, financial management, investigator relationship management, remote data capture and clinical data management, product safety management, and overall clinical intelligence.  

Arvindh Balakrishnan is senior director of the Life Sciences Business Unit at Oracle, 

Articles

The senior director of Oracle's Life Sciences Business Unit tackles some of the technical issues regarding regulatory standardization, software integration, and the trend toward virtualization, among other things. Do you have something to ask Arvindh Balakrishnan? Click here to submit your questions.

Tech Talk: A Q&A with Oracle's Arvindh Balakrishnan

Bringing a pharmaceutical or biologic to market takes more than just good science. It takes an agile business that can respond to the changing market and environment by aligning business processes with flexible information technology (IT). Separate challenges confront research and development (R&D), manufacturing, sales, and marketing. R&D is compelled to accelerate time to market of novel treatments and extend its reach in global markets. Likewise, manufacturing is undergoing sweeping changes, incorporating more efficient, quality-centric methods, and streamlining processes that scale across regions and partners. Financial and regulatory demands on sales and marketing are forcing companies to evaluate ways to increase sales effectiveness, such as multi-channel business models, direct-to-consumer marketing, partnering, and new customer models. Technology integration challenges hamper all of these areas. Service Oriented Architecture (SOA) can help address these systems' integration challenges across the organization and serve as the new blueprint to help companies align business and IT. This article will feature how SOA can address challenges in manufacturing and is intended for business executives to explore how SOA can help them effectively respond to today's evolving and complex business models.  

Biotechnology and pharmaceutical companies (BioPharma) are challenged today by more complex scientific information and the need to make faster business decisions—all in the context of a global marketplace. Many organizations are actively collaborating and partnering to augment their core competencies and extend business beyond organizational and geographic boundaries. Companies have invested in many forms of technology to enable business processes, integrate their organization, and support innovation.  

Businesses seek flexibility within a compliant environment—their processes are not static—and they seek to constantly improve the way they implement their strategy. IT solutions need to support that flexibility. Today's integration approaches do not support the level of responsiveness for continuous improvement. SOA has the potential to dramatically address this challenge and benefit an organization when:  

Business users exchange information across multiple systems 

Business processes span several applications across partners

Businesses are transitioning to newly merged or acquired business owners

Business users need information in near real-time 

Point-to-point solutions prevail with fixed interfaces that are costly to maintain.

But what is SOA, and how can this architectural approach provide an organization with the levels of efficiency and responsiveness it needs to effectively compete in today's changing market?  

What is Service Oriented Architecture (SOA)? 

SOA is a style of developing and integrating software. It involves breaking an application down into common, repeatable "services" that can be used by other applications, both internal and external, in an organization—independent of the applications and computing platforms on which the business and its partners rely. Using this approach, enterprises can assemble and reassemble these open, standards-based services to extend and improve integration among existing applications. SOA can also be used to support collaboration, build new capabilities, and drive innovation at every point in the value chain. 

The power behind SOA is the ability to share services through system-to-system interactions that could improve efforts to adapt end-to-end processes. SOA helps automate process steps; remove redundancy; use messaging and alerts to trigger essential people-powered workflow; and enable new capabilities. When a company adds new applications and retires old ones, SOA can help facilitate the transition and migration. Over time, services may be modified, shared, and recombined to streamline activities across yet more applications. This approach allows companies to more efficiently automate regulated and compliance-driven activities—freeing people to perform higher-level activities and providing an integrated business view to authorized staff across departments and organizations. In time, SOA can support continuous improvement through monitoring and redesigning processes linked to technology services. 

SOA offers an integrated, collaborative approach to aligning business and IT services and supports evolving business needs. The business must be actively involved, however, to identify the processes that must be managed on an ongoing basis. Current IT integration methods can continue to exist because SOA preserves legacy systems through the use of services. SOA can be applied using a small, step-wise approach that can grow as companies add more processes and applications. As a skipping stone creates ripples in a lake, SOA can help create benefits that quickly ripple through many other areas of the organization and partners. 

SOA is easier to understand through real-life examples. Below, the authors examine an industry-specific critical issue within the manufacturing organization to show where SOA approaches enhance information sharing for internal systems and support tighter integration with manufacturing business partners. 

Manufacturing: Improving the product-release process

Today's regulatory agenda demands "quality by design"—a proactive approach that addresses compliance issues before they occur. Customers and regulators want nothing less than continuous supply, reliable product safety controls, and the ability to track issues efficiently. More parties are involved in manufacturing, as more complex products require more communication, which exposes the industry to risk from local variations and monitoring procedures managed by global partners. The authors will focus the discussion on a real-life scenario of getting manufactured products released into the market.  

BioPharma manufacturing is striving to create tighter integration among all the players: suppliers, technical development, manufacturing facilities, comarketing, logistics, and markets. At the same time, manufacturing is an inherently changing environment. The authors will look at one part of the release process and examine the many systems supporting this process. Companies often experience integration challenges when there is:   

One enterprise resource planning (ERP) application with many instances internally or externally at manufacturing sites

Many ERP instances with many best-of-breed applications

Different systems for each department discipline involved in the manufacturing process

A reliance on paper being generated from these different systems, with the legal requirement to retain the paper and show an audit trail for each released batch

Loosely enforced global IT standards within the organization or with partners.

Managing the product-release process today

The release process is complex and involves massive amounts of information from various sources. All compliance-based processes must come together at this point before a batch is released to the market. Staff is involved across the organization and outside the company that includes quality control, in-house or third-party manufacturing, engineering, quality assurance, and supply-chain operations. Figure 1 shows how a typical release process occurs today. 

Figure 1: Today's release process involes many manual, iterative processes. 

This process is triggered as a batch is completed. Today, the process is slow and inefficient because it is still largely paper-based, with many applications. It relies on humans to push the paper to its next step, or to transfer the information manually from one system to the next. Documents can become lost and can be difficult to trace during critical stages. Stand-alone applications may only have partial information, and the manual entry of information into multiple systems can lead to redundant or even conflicting data. Each discipline has its own reports to document the manufacturing of the batch. It is the collective set of documents from all activities and departments that comprises the information and basis to know whether or not the batch should be released. There are many document-related activities and issues that can occur as documents are collected. What Figure 1 does not depict is the iterative nature of document generation and collection loops that can prolong the process if no triggers exist to alert staff about ongoing issues or corrective actions. The result is a process that is difficult to measure and manage. 

To support good manufacturing practices (GMPs) of global regulators such as the US Food and Drug Administration in the United States and the European Medicines Agency in Europe, staff and equipment must be in compliance at all times. Compliance is often supported through business processes like those presented in Figure 1. In many cases to improve this process, companies need to eliminate the paper and have systems that can store and share required reports and documents systematically from system to system. This level of integration ideally would not impose custom programming requirements on the systems actually generating the reports. Figure 2 shows how the process improves with an SOA-enabled enterprise content management system (ECMS) that manages data stored in a database (structured data) and documents stored in a document store or repository (unstructured data).  

Figure 2: A revised productârelease process. 

The departments supporting the batch-release process continue to use their existing systems with a new efficiency that allows staff to focus on value-add activity. These systems communicate to an SOA-enabled content management system to store any required reports.

Paper generation and movement can be eliminated, removing the uncertainty that can potentially reduce overall cycle time 

The system can help manage the process, for example, only allowing the process to continue when all of the proper documents have been generated, collected, and stored appropriately

The qualified person who is responsible for releasing the batch, can now more easily see if there are open deviations in the documentation collected 

The development of a more efficient and effective process platform is possible by integrating the supporting systems using SOA. 

In the past, this platform development often required custom, point-to-point programming dependent upon proprietary platforms and programming interfaces provided by the software vendor. This has been notoriously difficult, complicated by the nature of storing documents and reports from various sources, in a variety of formats. The complexity is only increased when the process requires the integration of multiple business partners around the globe. There are many software solutions for enterprise content management. If the enterprise content management solution provides SOA services, a company such as IBM can provide the level of integration shown above with a compelling integration approach for both the sponsor's and the business partner's IT departments. Figure 3 shows how this level of systems integration can be achieved using SOA. 

Figure 3: A closer look at an enterprise content management system providing Service Oriented Architecture services. 

 Using Figure 3 and continuing with the example,  

If the quality assurance person had closed the release blocking incidents and wanted to publish an incident status report, he or she would use the Corrective and Preventive Actions (CAPA) system as normally done. The CAPA system would generate the report and would use the SOA service from the content management system and "store document" to store the report associated with the batch.

The qualified person who reviews all the documents in the content management system and wants to set the release decision would do so in the ERP system, as is done today. However, when the production order needs to be published, the ERP system would do so and would use the SOA service from the content management system and "store document" to store the report associated with the batch.

If the quality control department were releasing the batch and wanted to generate the certificate of analysis, it would do so in the laboratory information management system (LIMS), as is normally done. The LIMS would use the SOA service from the content management system and "store document" to store the report associated with the batch.

The SOA-enabled ECMS provides a standards-based approach allowing other systems to deposit reports and documents and maintain those documents over time. This approach involves defining SOA services for distinct document-management functions such as depositing a document or report, or retrieving one. In our example, not only can the initial batch documents be stored, but downstream documents that must be retained, such as the certificate of analysis and electronic batch records can be stored collectively by any system participating in the process. This can help simplify the generation of regulated documents. It enables staff to resolve issues that are tracked in the CAPA system and not have to chase after supporting documents.  

 SOA delivers tighter internal integration among players. The SOA-enabled ECMS solution is one example of how SOA can impact the manufacturing environment. SOA brings value to the overall organization as follows.  

SOA establishes an environment that supports the evolution to quality by design and continuous "real-time" quality assurance to help build in efficiency within the organization and with global partners. The use of a service-driven approach, such as SOA, enables processes that help departments, manufacturing sites, and organizations adapt to changes in the environment.

: In this example, services can be reused by any application producing documentation for the manufacturing process, which represents a common, high-impact process. Consider how valuable SOA services would be for other central or key applications such as ERP. 

 SOA services make it easier to adapt to changes in the business processes required for manufacturing. SOA makes system functionality more granular, so the process activities that use them can be easily accessed and applied to other systems. IT systems become more flexible and reduce development times as SOA services are reused. 

An SOA framework can also help monitor execution of a process. The same SOA services that connect two business applications can also support any of the monitoring applications. 

Support for automated processes across applications:

 SOA allows process management or workflow systems to "talk" to required applications needed to support the process. This helps reduce administrative burden and increase compliance. It also allows processes to extend into new areas of the organizations or to external partners.

 Business partners can be integrated with the BioPharma company in a nonintrusive manner using industry-standard interfaces. Business partners do not need to change their current software, nor does the BioPharma company. SOA offers a way to integrate without wholesale change to existing applications. 

SOA offers connectivity options for new partners and allows companies to explore new product capabilities. Support systems can be built more easily using portal technology and SOA services. 

Although the BioPharma industry is actively addressing its challenges, many current environments are not scalable or responsive enough to meet future demands or to efficiently compete on a global scale. Service Oriented Architecture enables companies to simplify the complex nature of today's BioPharma business to facilitate "smart" system interactions and "built-in" compliance.

More than ever, drug makers need to be fleet and flexible-and they need their software to be the same.

The New Biopharmaceutical Blueprint: Service-Oriented Architecture in Manufacturing

Many organizations consider their laboratory information management system (LIMS) to be a mission-critical component of their overall corporate information system (IS)—whether the company is in a regulated industry, such as drug development or pharmaceutical manufacturing, or in a nonregulated industry, such as petrochemicals. LIMS provides the integral connections to these companies' laboratory data, instruments, analysis, and reports. 

Today, LIMS is in the fourth generation of its evolution, and many organizations must upgrade, supplement, or modify their LIMS to ensure optimum interoperability with the overall corporate IS infrastructure. To ensure successful management of the LIMS implementation and maintenance, selecting the best LIMS architecture for an organization is more critical than ever. It is a task that becomes even more complicated because many of the terms used to describe very different LIMS and system architectures that are used interchangeably. This article provides clarification of the terms as well as the capabilities of potential solutions. 

From first-generation LIMS to web functionality

LIMS connects the analytical instruments in the laboratory to one or more workstations or personal computers (PCs). Analytical instruments, such as chromatographs, collect sample data, which is then forwarded to a PC, or further to a server, where the data are organized into meaningful information. This information is then stored to be mined by the laboratory and other departments, or it can be sorted and organized into various report formats based upon the type of report required. A full-featured LIMS will manage the various laboratory data collected from sample login to reporting the results and will address the needs of research and development (R&D) departments all the way through to quality management laboratories. 

The first commercial LIMS was introduced and developed in the 1980s by analytical instrument manufacturers. This first generation LIMS placed laboratory functions onto a single centralized computer, which offered greater laboratory productivity and functionality as well as the first automated reporting capabilities. These systems were quickly followed by second generation LIMS, which used third-party commercial relational databases (RDB) to provide application-specific solutions. Most relied on minicomputers such as Digital VAX, but PC-based solutions emerged soon afterwards.

The increase in computer-processing speed, the enhancements in third-party software capabilities, and, the reduction in PC, workstation, and minicomputer costs paralleled the introduction of the commercial LIMS. These advantages drove a migration away from proprietary commercial systems toward open systems that emphasized user-configurability, rather than customization by the vendor. By the time the third generation technology was introduced in the 1990s, LIMS combined the PC's easy-to-use interface and standardized desktop tools with the power and security of minicomputer servers in a client–server configuration. That is, its architecture splits the data processing between a series of clients and a database server that runs all, or part of, the relational database management system. In the mid-1990s, the fourth generation LIMS decentralized the client–server architecture further, thereby optimizing resource sharing and network throughput by enabling processing to be performed anywhere on the network. When the Internet took off in 1996, the first web-enabled LIMS was soon introduced, followed by web-based and thin-client solutions. 

Most of these thin-client solutions were developed in Java, and web-based systems on Microsoft's .NET platform. Some of these web-based systems leverage eXtensible Markup Language (XML), to transmit data between traditional client/server architectures and the .NET framework to offer a web-based application. 

Thick-client, web-enabled, web-based, and thin-client LIMS

Understanding the differences between thick-client, web-enabled, web-based, and thin-client LIMS is challenging because the terms are often used interchangeably, adding to the confusion and making it difficult to develop a well-informed decision when it comes to choosing the "right" LIMS. These terms actually apply to very different types of platforms. And using them interchangeably can prove costly when organizations find out that their new software does not deploy or function as expected. 

 is used to describe an application designed to run in a client–server environment, meaning that a portion of the software resides on the server, and the other portion resides on the user's workstation. "Clients" are essentially the PCs or workstations. Also known as a fat client, it is a client that performs the bulk of any data-processing operation and relies on its associated server primarily for data storage. A thick-client has the LIMS installed on the PC's hard drive. The thick-client connects to the database server, but the processing is done on the client side (See Figure 1). Each change to the configuration or the application must take place at the client level; that is, the modifications must be propagated to each individual workstation. To provide the interconnectivity of each of the end-user locations, thick-client LIMS rely on cross platform programs such as Citrix. 

 is used to describe the add-on web browser component of an application designed to run in a client/server environment. The web-enabled portion of the application may allow access to data from a web browser, but the user is limited to the product functionality that is available on the web portion of the system (see Figure 2). To access and exploit the full functionality of the application, users must have the local client installed on their desktops. To provide the interconnectivity of each of these end-user locations, the web-enabled LIMS must also rely on cross-platform programs such as Citrix. Similarly, modifications must be propagated to each thick-client. 

Thin-client or web-based applications offer end-users full application functionality from a browser. A thin-client does not have significant hard drive or memory requirements, as it does not store or process data. The LIMS resides on the application server(s) while the thin-client simply presents the screen display and allows users to interact with the application server via a keyboard and a mouse. Configuration changes or customizations made on the server to the software are immediately universally available to all end-users. There is no need to propagate the changes to the end-user client or leverage regional servers with cross-platform programs. 

A laboratory information management systems comparison 

The distinction between web-based and thin-client solutions is the amount of software residing on the client. A true thin-client LIMS is an application written specifically to run on the web, with zero-footprint on the end-user client. It only requires a browser or "dumb" client terminal to run the application residing on the server. No downloads, applets, or other programs exist on the end-user client, other than the browser (see Figure 3). 

Web-based LIMS built on Microsoft's .NET framework typically transmit data between the .NET framework and traditional client/server architectures to offer a web-based application. In such systems, the thick-client is somewhat hidden because it runs in a browser. However, there is more running on the client than just the browser. A .NET application that runs on the .NET framework installed on the end-user client is required to render the browser pages from the thick-client server. In essence, the browser is not showing HTML, but instead, is showing a thick-client-server-like application. In addition, these applications also rely on the local client for computer processing, and therefore require a rich, rather than, dumb end-user client (see Figure 4). 

 Integrating a LIMS into the overall IS should take into consideration the company's current infrastructure, long-term plans for the IS, and investment in hardware and human resources to manage the IS. This decision, in turn, affects the cost of clients and servers, third-party software needed to connect these LIMS clients, and the resources needed to deploy and upgrade the LIMS. Furthermore, it affects the robustness and security of the application as a whole as well as the flexibility of the system to later modification. Depending on the answer and the trade-offs to be made, the organization may decide to use either a thin-client, web-based, web-enabled, or a thick-client solution. 

 Thick-clients and web-enabled solutions typically require less network bandwidth. Because thick-clients themselves do much of the application processing, they do not require an application server for processing. However, it is important to remember that the database will likely reside at the server level, so communication to and from each thick-client is still required. Additionally, regional hardware and software is required to operate the cross-platform programs such as Citrix that enable such networked communication. Web-enabled and some web-based systems offer a hybrid to this approach, depending on where the functionality resides (i.e., on the client or on the server). 

  Thick-clients provide some level of redundancy. In a simple LIMS solution that uses a single thick-client, if the server–network goes down, the client can still collect sample data and hold it on the PC's hard drive until recovered data can be forwarded to the appropriate server. In a thin-client application, redundancy is achieved through clustered application servers that provide load balancing and fail-over, a process that routes client requests to servers within the cluster. If one or more servers fail, client requests are automatically routed to other servers within the cluster so there is no break in service. 

  Thick-clients tend to have advantages in multimedia-rich applications that would use up a lot of bandwith if fully served. For example, thick-clients are well suited for chemical drawing and molecular modeling programs, which require a significant amount of computing power. With that said, new technologies such as AJAX (Asynchronous JavaScript and XML), are offering more dynamic user experiences than previously available over the web. Moreover, thin-client LIMS can be easily scaled by adding servers to the cluster. 

  With a thin-client LIMS solution, users can access the LIMS from virtually any Internet-ready device. All of the laboratory's applications and data are maintained centrally, thus allowing any number of people to share them in a secure way by simply plugging in a thin-client browser. Thin-clients also enable connectivity by critical users external to the laboratory such as executives, customers, and partners. Moreover, thin-client solutions can leverage a "dumb" client or portable device, as opposed to some web-based systems that require a client to leverage the .NET framework to communicate with the server. Thick-client systems pose the most difficulty in enabling enterprise access. Such systems must be installed at each end-user client, and they have no remote access capabilities. Web-enabled systems offer some remote access, but only to the specific, limited functionality available via the browser. 

  With thin-clients, all the applications and data are maintained on a central server. For leading thin-client LIMS, access is role-based and password-protected for security, complying with 21 

 Part 11. Disabling a login account disables access to all company information. No application data ever resides on the client, hence files cannot be transferred to local hard drives and memory sticks. 

 A thin-client browser interface has the familiar web-site look and feel. Thus its use is intuitive, which keeps initial and ongoing training costs low. Because end-users are more comfortable with the interface and adoption is easier, the LIMS can be integrated with the organization's workflows more quickly. This enables organizations to leverage their investment and reap the benefits of enhanced productivity sooner. 

  Thin-client solutions reduce the cost per user and IT manpower requirements while delivering a solution that is easily upgradeable and expandable (without interrupting business). Software updates are done once from a central server and are immediately available to all; desktop upgrades are not required. A thin-client LIMS enables an information technology (IT) team to deploy, maintain, and support only one central LIMS, thereby increasing return on investment. Thick-client and web-enabled systems require the IT team to upgrade all end-user thick-clients around the world, along with each of the regional servers and cross-platform programs residing on them. Although some web-based systems achieve some of the benefits of thin-client systems, there are added costs to maintain the .NET framework on each end-user client, especially on portable devices. Moreover, such .NET systems are tied to Microsoft's proprietary browsers and application servers. 

Thin-client hardware is generally less expensive than thick-clients because they do not require as much local disk space, application memory, or powerful processors. The total hardware requirement for a thin-client system (including both servers and clients) is usually much lower as well. One reason for this is that the hardware is used more efficiently. A thick-client central processing unit is idle most of the time. With thin-clients, memory can be shared. If a LIMS application is being used by several users, it needs to be loaded into the random access memory only once on a central application server. With thick-clients, each workstation must have its own copy of the LIMS in memory. Ultimately, the real value of thin-client computing emerges through determinations of the "total cost of ownership," which includes not only the upfront price of the hardware and software, but also the much larger cost of installing, supporting, and updating the system over time. 

While the advantages of a thin-client strategy appear to be greater than that of a thick-client, that may not be the case for every organization in every instance. IT professionals must consider a number of variables pertinent to their particular organization. For example, consider a LIMS at a contract research organization that would like to provide secure Internet access for data entry, analysis, and reporting to external customers. It would be challenging to provide this capability with thick-client LIMS. Also, users should be aware that just because the application runs on a browser, it doesn't mean it is thin-client. Firms should also consider whether their external customers are running Internet Explorer with .NET, so they can support access to the firm's .NET LIMS. Do they allow .NET applications to be downloaded to their end-user clients? 

Another consideration for firms to determine is whether the technology behind the LIMS is associated with a single vendor and whether that raises concerns with the firm's own IT organization. For instance, a firm might ask whether its IT organization wants to limit itself to technology proprietary to Microsoft? This means that the LIMS most likely can only use Microsoft browsers and Microsoft back-end web and application servers. In this case, an existing Linux or Unix environment would not be able to run the .NET LIMS, thus complicating assessment of the actual cost for using such a solution since it may preclude use of existing technology. 

It may also be important to consider whether remote handheld devices are critical to the laboratory. If so, see whether the thick-client LIMS can run on a portable device and assess whether the necessary .NET support browser is available for PDAs and other handheld devices used in the laboratory. This can be a significant issue to organizations that conduct R&D in the field or perform activities such as environmental monitoring on the plant floor.  

There are significant differences between thick-client, web-enabled, web-based, and thin-client solutions. Thick-clients are desktop client applications that connect to a remote database. Web-enabled solutions are more oriented toward thick or rich clients, and web-based solutions offer some of the benefits of thin-client applications. Thin-clients, on the other hand, are true HTML applications that do not require additional end-user client downloads, applets, or frameworks. Just be sure a firm knows what it's getting by being aware of the differences, advantages, and disadvantages of each type of solution in relation to its existing or planned infrastructure. Many organizations are choosing thin-client solutions and paving the way toward a simplified infrastructure that delivers lower cost of ownership, better usability, and less complexity. Above all, firms need to make sure the laboratory information management system it selects is the best fit for the organization. 

 serves as the vice-president of corporate development for LabVantage Solutions, where he is responsible for directing LabVantage's long-term product strategies, global marketing initiatives, and business development opportunities. LabVantage Solutions, Inc., 1160 US Highway 22 East, Bridgewater, NJ 08807, tel. 908.333.0103, fax 908-842-0338, 

Before any information technology solution can be installed, a company must decide whether applications are going to reside on individual computers at each employee's workstation, on servers within or outside of an organization, or on a vendor's website.

Determining LIMS Functionality, Cost, and ROI: System Architecture Strengths and Limitations

Increasingly, pharmaceutical companies worldwide are recognizing the cost savings and efficiency increases of using mobile technology to streamline operations, increase customer satisfaction, and improve top-line revenues. Companies can adopt mobile technology throughout the entire spectrum of their business—from sales and customer service to research and discovery, manufacturing, and distribution.  

Mobile technologies help streamline business processes at all stages of the pharmaceutical life cycle. Many pharmaceutical companies use mobile technology to eliminate paperwork, meet 21  

 Part 11 and Prescription Drug Marketing Act (PDMA) guidelines, electronically capture signatures, streamline inspections, enable accurate data capture, and meet other performance objectives. 

At the start of the product life cycle, researchers must ensure their cleanrooms and laboratories meet compliance standards for contamination control, health and safety, hazardous chemical handling, and documentation. Firms are using mobile technology to enable paperless inspections that capture data on-site. Paperless inspections allow companies to take immediate action and store information for compliance and management decisions. 

More and more, companies are using mobile devices for electronic data capture in clinical trials. This capability gives firms immediate access to trial data and allows them to monitor events, derive accurate data, perform instant validation, and reduce data-entry time. A review of randomized controlled trials that compared data capture with handheld devices against paper methods demonstrated that data quality and timeliness increased with the use of handheld devices. Subjects also preferred using the handheld devices, and their convenience likely increased subjects' adherence to protocols (1). 

As an effective way to meet US Food and Drug Administration requirements, pharmaceutical companies have incorporated the e-signature and e-validation features of mobile technology applications into their production processes to create an unalterable, accurate electronic trail of accountability for inspectors to review. Mobile technology enables companies to track temperatures, data points, and inspection points to ensure a safe and secure work environment and to keep production on schedule. 

Many pharmaceutical firms use mobile technologies to make thousands of measurements that are the basis of decisions that affect drug quality. Calibrating instrumentation helps maintain product integrity throughout the production process. And to ensure that strict regulatory compliance and adherence to quality specifications be maintained, technicians using handhelds can capture production data. Mobile technology also makes calibration data easily accessible to others who must monitor it, such as plant managers. 

For these reasons, many pharmaceutical companies use handheld computers to ensure that measurement instruments are correctly calibrated. One pharmaceutical manufacturer uses mobile technology to track equipment temperatures, data points, and inspection points. 

A major reason that some companies are implementing mobile technology is that it allows the large-scale optimization of manufacturing tasks (i.e., maximizing the time, capital, and equipment used and streamlining raw-material handling and production). One pharmaceutical company, for example, labeled more than 8000 assets with barcodes that its technicians could track with its mobile technology application. As a result, the company has increased the number of completed work orders for preventive maintenance, and managers are better able to account for the work done on those assets. Such efficiency gains are not possible with a paper-based system. Of course, a hurdle for most pharmaceutical companies is to validate data capture for 21 

 Part 11 for compliance reporting. Mobile solutions can ensure that vital information is electronically captured to keep accurate repair and operating records for regulatory agencies. 

Pharmaceutical firms are also tapping mobile technologies to help their sales force focus on selling and to place products into customers' hands. Most sales professionals use automation systems to make sure they have relevant, accurate, and timely information, wherever they are. Pharmaceutical firms also strictly adhere to all 21 

 Part 11 and PDMA guidelines for electronic record management, sample distribution, signature capture, and inventory management. For example, each professional's eligibility to receive samples based on state license validation status should be clearly indicated and enforced by the mobile software throughout the sales process. Overall, mobile technology makes efficiency and success possible in many operations within the pharmaceutical organization. 

Seven reasons pharmaceutical enterprises are going mobile

 Pharmaceutical companies turn to mobile technology to automate routine but critical facilities functions such as safety checks, security rounds, and information technology asset management. An employee equipped with a handheld device featuring the latest mobile technology can instantly report the operating status of an asset after a visual inspection. Should the equipment require repair or replacement, the worker can create a work ticket on the spot and immediately file it in a data back-end system for quick retrieval by management. Many pharmaceutical companies believe that they can increase the exchange of better-quality data between workers on the plant floor, warehouse, or other locations with mobile technologies. Employees receive timely and more accurate data feeds into their system and provide critical information to technicians and other workers using handheld computers at the point of performance, thus improving productivity through an accurate, timely exchange that is not always possible via cell phones or other modes of communication. 

Mobile technology deployments also eliminate the need for technicians to spend valuable time on end-of-shift data entry, which translates into more time for asset repair and preventive maintenance programs.

Mobile technology helps companies ensure that laboratories, cleanrooms, and other production facilities are up to par. Cleanroom and laboratory inspections, live animal checks, and other monitoring functions required by FDA can be completed expediently and effectively when scientists and technicians instantly capture vital condition data with mobile technology. In addition, hours saved on such inspections result in more time for technical employees to devote to research, product development, and production processes or other important responsibilities that are directly related to production and compliance. 

A key reason pharmaceutical companies consider adopting mobile technology is the technology's ability to organize disparate functions into a unified process. For example, the supply chain operation at a typical pharmaceutical company has many steps that mobile technology can optimize and streamline by processing key data in real time.  

The supply-chain operation involves receiving items such as raw materials or regulated chemicals, warehousing them, and eventually using them in production or another activity. In a paper-based system, a written record must be collected at each step of this process. A mobile system, however, enables managers to track goods received at their facilities with more accuracy and speed, without requiring them to review a paper trail to stay on top of shipments. Mobile technology also improves tracking during the course of the life cycle of materials, from the time they are ordered through the time they are received. Better tracking leads to more effective consignment stock and trunk inventory management, better compliance reporting, and enhanced safety measures. 

Other areas of the organization benefit from real-time data collection, including customer service and satisfaction monitoring, partner and vendor support, cooperation among business units from production to distribution, sales, and service. 

4. Improving sales, distribution, and customer service. 

Mobile technology allows pharmaceutical companies to streamline supplier–vendor contract management, and enable efficient and accurate stock management from the dock to the storage bins. This streamlined workflow, in turn, improves distribution, order fulfillment, and tracking. For example, with a mobile technology-enabled process, a firm can keep track of the drug samples its sales representatives distribute, which provides vital information for sales, marketing, and compliance-reporting purposes. 

Companies reduce safety stock, stock-outs, and material shortages when workers can quickly track the location of items at any time. The progress of deliveries can be tracked through the data recorded by workers using handheld computers, which improves customer service. 

Mobile technology also streamlines communication, which enhances inventory handling and management and reduces bottlenecks. Furthermore, mobile technology allows pharmaceutical companies to minimize their material handling labor and reduce inventory waste through shrinkage or spoilage.  

In addition, mobile technology allows workers to capture real-time data on customer accounts and billing, purchase-order receipt verification, and shipping manifest—all at the point of performance. Transaction and transportation costs are reduced, and pharmaceutical companies can extend some of their savings to partners and suppliers. 

5. Mobile technology and 21 CFR Part 11 reviews. 

The presence of mobile technology in pharmaceutical manufacturing is supported by considerable research and an extensive exchange of information between the mobile providers and drugmakers. 

Although FDA doesn't mandate the adoption of mobile technology in  

Guidance for Industry: Part 11, Electronic Signatures—Scope and Application 

, the agency strongly encourages aspects of it, such as electronic record-keeping and signature capture. With a tamper-proof electronic record that can be sent and received through mobile technology to any data back-end system, pharmaceutical companies have complete records they can quickly provide at any time for 21  

Mobile technology can help streamline record storage. The electronic records generated by mobile technology also enable management to stay abreast of production developments within their facilities and make the adjustments necessary to reduce their risk of being out of compliance.  

An FDA team performing an inspection will find it helpful when electronic records can be immediately produced for the facility they are reviewing. As part of many of its inspections, FDA includes a review of a company's production records. Some of the most common compliance violations among pharmaceutical companies involve imperfect records. 

6. The value of investing in mobile technology. 

 The value of mobile technology is simple: it enables companies to do more for less expense. The technology lets companies execute key business processes more efficiently, with considerably less hassle than paper-based systems. 

Mobile technologies enable companies to spend more time developing products, serving customers, repairing equipment, and communicating timely and accurate information about the supply chain, manufacturing, and sales. This efficiency improves decision-making and the bottom line. End-of-day data entry by field staff is eliminated. Incomplete or illegible records are replaced by a system that captures and uploads accurate and complete electronic data. 

To keep production on schedule, companies use mobile technology to identify problems with equipment and to isolate potential failures before they occur. Adopters of mobile technology in the pharmaceutical industry find they can extend the life of key assets. Thus, mobile solutions give companies time to perform more planned work. 

7. Evaluating the bottom-line benefits of mobile technologies. 

The efficiency and cost-effectiveness of mobile technology appears on companies' bottom lines in several ways. One pharmaceutical company, for example, found in a recent study that, with mobile technology in place, its cost for handling an individual work order decreased from $4.90 to $0.84 because it used fewer administrative resources and eliminated redundant data entry. 

Mobile technology brings companies value because it makes processes run more effectively and assets last longer. These improvements effectively lower the total cost of the asset in question by as much as 30–50% in many cases and deliver a quantifiable and quick return on investment, sometimes in six months or less. 

Mobile technology also facilitates a more strategic approach to the allocation of human capital. It allows managers to reduce unnecessary foot traffic by their technicians and have them available when assets require attention. Mobile technology helps refine inspection and production processes, and improvements are reflected in healthy cost savings. 

Equipment uptime, of course, is crucial in the pharmaceutical industry, where production should be at full capacity, and downtime equals lost dollars. With the additional "wrench time" mobile technology enables, technicians can devote more of their schedules to preventive maintenance to keep assets in operation longer.

When companies end their dependence on paperwork, they typically experience productivity increases of 10–25% (2). They also see an improvement in first-time fix rates because their skill teams have more data at the point of performance. The labor savings and increase in productivity easily offset the initial investment costs.

Deploying multiple mobile products that use a single platform technology decreases application costs and results in exponential increases in data for better management.

In the pharmaceutical industry, the adoption of mobile technology is an ongoing trend. Organizations are adopting mobile technology to remain competitive. The seven reasons why mobile technology is taking off in the pharmaceutical industry are straightforward and time-tested. New uses for the technology continue to emerge as operational and organizational experts are exposed to the software and users see its convenience.

 is president and chief executive officer of Syclo, 1721 Moon Lake Blvd., Suite 300, Hoffman Estates, IL 60169, tel. 847.230.3800, 

1. C. Garritty and K. El Emam, "Who's Using PDAs? Estimates of PDA Use by Health Care Providers: A Systematic Review of Surveys,"  

 2. Syclo, "Syclo Mobile Results Customer Survey" (Syclo, Hoffman Estates, IL, 2004).

Seven Reasons Why Pharmaceutical Makers Are Adopting Mobile Technology

Going Mobile

Acentral issue for most pharmaceutical organizations, and all businesses, is the fragmented and reactive way governance, risk, and compliance (GRC) tasks are handled across the enterprise. Sales managers may be responsible for ensuring that next quarter's revenue projections aren't overblown. Information technology (IT) staff may be responsible for appropriately protecting customer data. The chief financial officer's office may be responsible for meeting financial reporting mandates. And as new GRC issues arise—because of emerging regulations, industry guidelines and frameworks, or a breaking news story—executives scramble to quickly put "point" GRC measures in place. In the pharmaceutical industry, for example, an individual Warning Letter focused on a specific issue may be addressed through a quick fix or point solution. 

This fragmented, reactive approach has several serious problems:  

It drives up GRC costs because efforts and expenses are constantly duplicated

It limits the effectiveness of each individual GRC initiative because each project team solves its problems in a unique way, rather than using proven processes and best practices that are already in place

It increases overall risk because risk mitigation is not sufficiently coordinated across the enterprise 

It delays time-to-fulfillment because each GRC project solves the same process and technology problems again and again

It does not produce board-level GRC confidence because it does not enable true enterprise-wide visibility of GRC status and practices.

For these reasons and others, it is crucial for executive management to bring order to GRC activities across the enterprise—that is, across all GRC mandates, all business functions, all business units, all underlying IT infrastructure, and all geographies.  

When pharmaceutical companies are dealing with multiple mandates, three basic requirements must be fulfilled to develop a coherent approach to GRC across the enterprise: 

a consistent corporate definition of GRC and GRC success; a common enterprise-wide framework for managing all GRC-related processes; and a single integrated technology platform for GRC automation, recordkeeping, and reporting. 

Chief compliance officers (CCOs) often step forward to take on the responsibility of developing this coherent approach to GRC. Although corporate integrity agreements are sometimes the impetus for these initiatives, CCOs often struggle to find a starting point to building a comprehensive GRC program. Each of these basic elements must balance the specificity necessary to ensure that each individual GRC objective is fulfilled with the flexibility necessary to ensure applicability to any and all GRC objectives across and beyond the walls of the enterprise. 

It's hard to blame anyone for the current fragmented state of enterprise GRC efforts. Corporate executives had no way to anticipate the scale of today's GRC workloads, the complexity of individual GRC mandates, or the pace at which GRC requirements would continue to change. In addition, new requirements have blindsided organizations, leaving them no time to step back and develop a holistic strategy for addressing all of their present and future GRC challenges. 

Every executive, however, is now aware of how big a burden GRC has become. They are aware that GRC burdens are not going to get any lighter and might get a whole lot worse. They're also well aware that their organizations' approaches to GRC are unacceptably fragmented. This fragmentation across the enterprise has serious consequences, the most troubling of which are described below. 

When corporate GRC efforts are fragmented, expenditures of time and money are constantly duplicated. Project teams must work through problems that others may already have solved. New systems are put in place when existing systems could readily be used across multiple mandates. Productivity is lost because employees get pulled away from their jobs multiple times for training, instead of just once. All of these inefficiencies divert financial and human resources that could bring much greater returns if they could be allocated elsewhere. 

Reduced effectiveness of each individual GRC initiative. 

When individual project teams use different policy and procedure formats, terminology, support systems, and processes, the effect on the workforce is multiplied. Understanding and following prescribed practices, getting direction, accessing procedures, dealing with uncoordinated training programs, lack of adequate records management, and available information for regulators all become unnecessarily burdensome. In addition, management is unable to maintain the access to information necessary for making informed business decisions. A fragmented GRC environment also prevents incremental improvements in process, policy, and technology from being replicated across the enterprise, further hindering the ability of all project teams to fulfill their full performance potential. 

When project teams can't adequately benefit from the work of their peers across the enterprise, it slows them down. They must rediscover resources and reevaluate technologies. They must negotiate new relationships with vendors and get new procurement approvals from purchasing. These delaying factors can be particularly problematic when it comes to meeting regulatory deadlines. Delays in order fulfillment can also extend an organization's exposure to a wide range of financial and legal risks. 

Low executive-and board-level GRC confidence. 

Board members and C-level executives can only have confidence in an organization's overall GRC posture if they have information about conditions and issues across the enterprise. A fragmented GRC environment does not provide this essential end-to-end visibility. Instead, it forces those ultimately responsible for the enterprise's GRC performance to monitor and consolidate multiple GRC information sources. 

In addition to being logistically cumbersome, this siloed approach creates more potential points of failure in the GRC chain wherever information from disparate systems must be consolidated. By implementing an integrated GRC program, organizations can reduce costs, improve effectiveness, accelerate the fulfillment of current and future mandates, and deliver the consolidated view of GRC status that upper management must safeguard their own interests and those of all corporate stakeholders. 

The first step in defragmenting GRC programs across the enterprise is to properly define GRC and GRC success. Companies must have a clear sense of what sorts of activities fall under the umbrella of enterprise GRC management and what common purpose those activities serve. 

Governance, risk, and compliance are distinct but closely related ideas. The following definitions, while technically incomplete, are simple enough for the purposes of this article:  

 is what companies decide to do. These decisions may be internally or externally driven, but either way governance is the management activity that draws the picture of what the company's behavior should look like if all goes according to plan.

 is what influences those decisions. All companies must make business decisions based on whether they want to accept, mitigate, or eliminate a given set of risks to minimize the downside and maximize the upside.

 is how companies decide to do it. Compliance consists of the policies, processes, people, controls, tools, and other measures that a company deploys to fulfill its governance objectives and reasonably minimize risk. 

The scope and complexity of GRC requirements are expanding so rapidly that businesses are struggling to fulfill them despite an increased willingness on industry's part to apply additional GRC resources.

Pharmaceutical Technology-11-01-2007

Tech Talk: A Q&A with Oracle's Arvindh Balakrishnan

The New Biopharmaceutical Blueprint: Service-Oriented Architecture in Manufacturing

Determining LIMS Functionality, Cost, and ROI: System Architecture Strengths and Limitations

Going Mobile

Defragmenting GRC: Confidence and Cost-Efficiency in a Time of Chaos

The Challenge in Bioprocess Development: From Data to Knowledge