Microsoft Digital Pharma

Transcription

1 m Microsoft Digital Pharma > Industry Architecture Technical White Paper Published June

2 The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property Microsoft Corporation. All rights reserved. Microsoft, Active Directory, ActiveSync, BizTalk, Excel, SharePoint, Visual Studio, Windows, Windows Mobile, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

3 Contents Executive Summary The Value of Architecture Speed to Insight Value for Cost Interoperability Across the Ecosystem Technology and Information Lifecycles Digital Pharma Business Areas Business Entities and Processes High-Level Capabilities Map Targeted Use Cases Business Summary Digital Pharma Technical Architecture Oriented Architecture Principles Connected Devices Collaborative Application Integration Infrastructure Other Dimensions Compliance Framework Governance Interoperability Framework Web and Standards Shared Real-Time Information Ecosystem Architecture to Implementation Use of Microsoft Products in the Architecture Adoption Approaches for Customers and Partners Conclusion Appendix A: Major Microsoft Products Appendix B: Implementation Models Base Infrastructure Release Strategy Deployment Model Partnering Strategy Appendix C: Key Technical Contacts

4

5 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 3 Executive Summary Research, commercial, and regulatory pressures are driving fundamental change in life sciences organizations. The need to form new partnerships is giving rise to a stronger focus on better collaboration and integration technologies. Pipeline pressures in research and development are pushing companies to evaluate and adopt high performance computing technologies in an attempt to locate better targets more quickly. Improvements in operational efficiency and efficacy within clinical development are leading organizations to re-evaluate their knowledge management strategies and focus more on information access and usability. And, the increasing difficulty in gaining access to physicians has many companies considering how to provide more value to physicians during detailing activities while also improving their own ability to market effectively. Microsoft believes that the traditional boundaries between enterprises and organizational units are disappearing as the industry moves toward a connected ecosystem of researchers, physicians, and consumers. To address all of these industry trends, Microsoft has created the Digital Pharma initiative. This white paper provides a high-level overview of the functional and technical architecture that Digital Pharma is built on. It describes the value that this architecture can provide for life sciences IT organizations and independent software vendors (ISVs). It reviews the Microsoft technology included in the Digital Pharma Architecture and defines an Interoperability Framework to help organizations integrate applications more seamlessly. In addition, this white paper reviews the key implementation considerations required for deploying this architecture within an enterprise. The Digital Pharma Architecture is standards-based and makes optimal use of industry wide initiatives including the Clinical Data Interchange Standards Consortium (CDISC) and Health Level 7 (HL7), as well as XML Web services. The Digital Pharma Interoperability Framework demonstrates Microsoft s ongoing commitment to open standards in the research environment and further underscores the company s view that integration will be the cornerstone for innovation. We believe this integration will not only facilitate collaboration between researchers and applications within an enterprise, but will also streamline collaboration between knowledge workers and systems that connect pharmaceutical companies to contract research organizations, physician s offices, clinical laboratories, medical device firms, biotechnology companies, and academic institutions. This white paper was written for chief technology officers (CTOs) and members of technical management teams who are responsible for designing, building, and deploying new technology solutions that address specific business needs; business analysts who serve as liaisons between business operations and IT organizations; and systems integrators who use Microsoft technology to implement solutions for the life sciences industry.

6 4 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER The Value of Architecture In computing, architecture is an overused and misunderstood term that many people find difficult to associate with a specific business value. In this section, we discuss the four main categories of value that customers and partners can expect to achieve through the adoption of the Digital Pharma Architecture. Microsoft does not believe that the challenges that the life sciences industry faces today can be addressed simply by buying the next wave of applications as they become available that approach to business improvement no longer delivers the value that it once did. Rather, we believe technology innovations that enable interoperability between disparate applications and information sources will drive fundamental business improvements. The Digital Pharma Architecture is a solid platform for growth that ensures that life sciences organizations can take advantage of existing investments in skills and technology while establishing a foundation for adopting new innovations. With the Digital Pharma Architecture, life sciences companies will have not only a robust infrastructure to build on, they will also be able to rely on the technology leadership that Microsoft provides to help them mitigate the risks of platform obsolescence. Speed to Insight Almost every company in the life sciences industry struggles with one aspect of their business: the quantity of information that is generated. In addition to the increasingly diversified and detailed data available through modern scientific methodologies and technologies, the industry is also being transformed from its traditional roots in R&D and manufacturing into a collaborative community of partners that span the broader global healthcare arena. Pharmaceutical organizations are supplementing internal R&D pipelines through partnerships that offer new capabilities beyond traditional drug product development and extend to medical devices and services. In-licensing new products for development from smaller biotechnology and medical device firms can serve to increase revenue for both partners while fulfilling the development resourcing needs of smaller firms. In addition, the role of the contract research organization (CRO) continues to expand as both pharmaceutical and biotechnology firms seek to supplement their operational capacity. In some cases, the traditional CRO is evolving to become more of a virtual pharmaceutical company. Even internally, pharmaceutical companies are restructuring product teams so that they span the broader life of a product (e.g., clinical development working with sales and marketing). This reorganization is driven by two objectives. First, pharmaceutical firms must be able to provide more efficient business handoffs between functional units. Second, the shift to broader market offerings requires a more comprehensive and long-term view of diseases and outcomes than is in place today. As this shift evolves, a greater need for transparency has given rise to new requirements that are critical to success: Scientists, information workers, and healthcare professionals need information to flow more seamlessly within and outside of the life sciences industry. Information workers need solutions that help them better assimilate data in order to make better decisions sooner. New and evolving partnerships need better, more collaborative business processes. Life sciences organizations need to focus on information management and delivery in order to meet the demand from consumers, governments, and providers for evidence-based medicine.

7 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 5 We call this category of needs which center around providing knowledge workers with the information and solutions they need to make sound decisions more quickly Speed to Insight. Speed to Insight also enables the analysis, modification, and monitoring of business processes that ultimately drive organizational performance and governance. The Digital Pharma Architecture enables IT organizations to deliver solutions that satisfy the business needs encompassed by the Speed to Insight imperative. It leverages Microsoft s R&D investments to create solutions that are simpler to implement, easier to use, and that scale more quickly to full production. Because it utilizes standards-based solutions that are already familiar to the enterprise IT organization, the architecture reduces the complexity that has typified technical infrastructure design. Common application and collaboration services can be provisioned across different environments. Disparate information systems can be linked with real-time information feeds and workflow. End users can interact with familiar interfaces regardless of device types. And applications can be deployed on an architecture grounded in years of Microsoft and industry research into developing robust, production-ready, and scalable business solutions. Value for Cost The advent of the Internet has enabled consumers to become better informed about their own diseases and treatment options. As the government and employers continue to shift costs to the consumer, those consumers will exercise more control and influence over the way their healthcare money is spent. The revenue impacts will in turn lead to continued pressure on life sciences organizations to improve operational efficiency and forge new partnerships. But the growing trend toward industry partnerships also brings with it increased technology complexity. Pharmaceutical organizations have already made tremendous investments in information technology. Lack of information access drives many businesses to consider replacing their existing applications at considerable expense. The real challenge is to find ways to unlock more value from the systems already in place. Cost avoidance and greater return on assets are fundamental principles in managing the business climate of today s life sciences organization. We call the need to get more value from existing technology while lowering the cost of future technology investments Value for Cost. The Digital Pharma Architecture provides a highly cost-effective platform for extending an organization s information technology portfolio with new capabilities. Organizations will benefit from Value for Cost in a number of ways. First, the platform provides common services that can be re-used in multiple business scenarios, thereby reducing licensing and operational costs. Second, the platform provides technology capabilities that can be easily exploited by IT professionals and application developers, thereby shortening time-to-benefit, reducing management costs, eliminating redundant programming efforts, and lowering the need for IT consulting services. And finally, the platform is based on commercial software that has an established record of low total cost of ownership and predictable product roadmaps.

8 6 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Interoperability Across the Ecosystem To achieve Speed to Insight and Value for Cost, the supporting information technology must meet certain requirements: 1. IT systems need to function across organizational groups. As business units continue to adopt new solutions in order to compete effectively, their ability to establish and maintain real-time information flow and share common services with other units will be critical to effective business performance and cost containment. 2. IT systems need to operate across internal and external boundaries. As interconnectedness and interdependency between companies grow, the need for real-time communication and information access is increasing. 3. IT systems need to provide a higher level of investment protection through open standards. The implementation of standards is a means of ensuring a higher level of future interoperability and solution longevity, resulting in solutions that are built to last. The Digital Pharma Architecture provides an Interoperability Framework that contains standards, methods, and processes for integrating applications. In addition to utilizing traditional methods for application integration, the Interoperability Framework focuses on new capabilities enabled through Web services and device integration. Because the framework uses common methods for application integration, it enables greater focus on the issues that drive value. This mature technology infrastructure requires minimal training for IT personnel and end users, shortening the time required to achieve the desired ROI. Technology and Information Lifecycles The impact of an interoperable ecosystem extends beyond individual applications. Regulatory concerns have resulted in tightly controlled IT deployments that make software and hardware updates, upgrades, and migrations cost-prohibitive. Information technology security is an ongoing process that requires periodic changes to operating environments as new threats are identified a process that should enhance regulatory compliance, not compromise it. In addition, interoperability implies that platforms transmitting information are under a different governance structure than systems receiving it a condition that holds regulatory consequences as well. As reliance on electronic tools increases, the line between unregulated and regulated information assets will blur, requiring careful consideration of information lifecycle policies and taxonomies in order to effectively meet regulatory obligations. The Digital Pharma Architecture is based on mature and stable technology that has been used in production enterprise solutions for years. As Microsoft works with industry groups and standards bodies to define new solutions, the Digital Pharma Architecture will provide a technology foundation that will drive innovation so that when emerging technologies such as RFID become available, they can be easily adopted by life sciences organizations.

9 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 7 Digital Pharma and Business Areas Business Entities and Processes Given the depth and breadth of the life sciences industry, it is difficult to create a single common functional view that represents the industry s entire business environment. However, certain business areas are found consistently across the industry that can be modeled. We have chosen to build this model with a focus on drug development, but the architecture is equally applicable to medical devices as well. Functional processes can be divided into four general business areas [see figure 1]: Drug Discovery. Processes related to the identification of novel medical treatments and preliminary research around those treatments. Drug Development. Processes related to the development of medical treatments through clinical trials and long-term studies in human populations. Manufacturing and Supply Chain. Processes related to the creation of experimental and production medical products, as well as the delivery of those products into the commercial distribution chain. Sales and Marketing. Processes related to the promotion and sale of commercial products to consumers, care providers, health plan administrators, and others. Drug Discovery Drug Development Manufacturing & Supply Chain Sales & Marketing Functional Processes Discover leads Develop and test leads Report results and drive product planning Manage external research relationships Manage organization, operations, and partnerships Industry Imperatives Rapid identification of targets and compounds Increase volume of NCEs Efficient information sharing Reduction in time and expense Functional Processes Design research programs and trials Run research programs and trials Report research program and trial results Manage research materials Manage organization, operations, and partnerships Manage physician and researcher relationships Manage regulatory issues and relationships Industry Imperatives Speed clinical trials Efficacy and safety insights Faster confirmation of marketable compounds Quicker decisions for less promising compounds Functional Processes Manufacture drugs Manage supplier relationships Manage distributor relationships Manage regulatory issues and relationships Manage materials Manage organization, operations, and partnerships Industry Imperatives Real time monitoring Rapid development of optimal production processes Accurate forecasting of demand and inventory Increased manufacturing efficiency Functional Processes Market drugs to physicians, consumers, and plans Manage customer relationships Manage regulatory issues and relationships Develop and deliver educational resources Manage care provider questions and contact Manage organization, operations, and partnerships Industry Imperatives Closed Loop Promotion Real time field analysis Faster decision making Faster response to physician s needs Reduction in cost of promotional materials Reduce clinical trial costs Figure 1

10 8 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Each of these processes requires a finite (but evolving) set of capabilities. For example, in order to run research programs and trials within Drug Development, organizations need the ability to manage a trial s progress and the resulting patient data capabilities often delivered through software for clinical data management and project management. The architecture must be able to account for processes in all four business areas while providing the framework for achieving Speed to Insight and Value for Cost. It must also facilitate rapid adoption and deployment of new technologies that will help the business realize competitive advantage and provide simplified ongoing management of those technologies. In analyzing these processes, a number of important factors emerge: 1. Functional processes that have historically been associated with one business area are increasingly being linked across business areas in order to drive efficiency and manage risk [see figure 2]. The resulting interdependencies generate architectural requirements for interoperability. For example, partnerships formed with biotechnology firms for drug discovery have often used different infrastructure solutions than partnerships formed with manufacturers for drug production. The growing complexity requires that organizations seek uniformity in the way they support these relationships (although it does not dictate that only one solution is possible). Drug Discovery Drug Development Manufacturing & Supply Chain Sales & Marketing Functional Processes Discover leads Develop and test leads Report results and drive product planning Manage external research relationships Manage organization, operations, and partnerships Industry Imperatives Rapid identification of targets and compounds Increase volume of NCEs Efficient information sharing Reduction in time and expense Functional Processes Design research programs and trials Run research programs and trials Report research program and trial results Manage research materials Manage organization, operations, and partnerships Manage physician and researcher relationships Manage regulatory issues and relationships Industry Imperatives Speed clinical trials Efficacy and safety insights Faster confirmation of marketable compounds Quicker decisions for less promising compounds Reduce clinical trial costs Functional Processes Manufacture drugs Manage supplier relationships Manage distributor relationships Manage materials Manage organization, operations, and partnerships Manage regulatory issues and relationships Industry Imperatives Real time monitoring Rapid development of optimal production processes Accurate forecasting of demand and inventory Increased manufacturing efficiency Functional Processes Market drugs to physicians, consumers, and plans Manage customer relationships Develop and deliver educational resources Manage care provider questions and contact Manage organization, operations, and partnerships Manage regulatory issues and relationships Industry Imperatives Closed Loop Promotion Real time field analysis Faster decision making Faster response to physician s needs Reduction in cost of promotional materials Information Assets for New Treatment Figure 2

11 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 9 2. As the volume of information related to a new treatment grows over time, information dependencies between business areas give rise to architectural requirements related to knowledge management needed to properly assemble and manage information assets. For example, physicians and regulators increasingly want deeper access to clinical trial results in order to make more educated decisions regarding patient care and safety. For many organizations, simply knowing what information is available can be a challenge as the quantity and complexity of research programs increases. 3. The increasing role of partnerships within the life sciences industry means that functional processes that have traditionally been handled in-house may now be executed by external organizations. Functional business processes are evolving into more modular and portable aspects of the business. High-Level Capabilities Map Figure 3 below depicts the top level of the design needed to support the Digital Pharma business processes and objectives described above. Drug Discovery Drug Development Manufacturing & Supply Chain Sales & Marketing Discover leads Develop and test leads Report results and drive product planning Manage external research relationships Manage organization, operations, and partnerships Design research programs and trials Run research programs and trials Report research program and trial results Manage research materials Manage organization, operations, and partnerships Manage physician and researcher relationships Manage regulatory issues and relationships Manufacture drugs Manage supplier relationships Manage distributor relationships Manage materials Manage organization, operations, and partnerships Manage regulatory issues and relationships Market drugs to physicians, consumers, and plans Manage customer relationships Develop and deliver educational resources Manage care provider questions and contact Manage organization, operations, and partnerships Manage regulatory issues and relationships Applications COTS Applications Custom Applications Application Development Collaborative Capabilities Shared Data Communities Communications Integration Data & Semantics Business Process Business to Business Infrastructure Operations Management Shared Resources Figure 3

12 10 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Since many of these business objectives are related to breaking down barriers within and across life sciences organizations, this design focuses on modeling functional processes based on organizational capabilities that drive performance across the four business areas outlined above. Capabilities include: Applications. The software that organizations use to support existing business processes. This software typically falls into one or more of the following categories: Commercial Off-the-Shelf Applications: Software that is commercially available from an external vendor. Examples include Microsoft s desktop productivity tools such as Microsoft Word. Custom Applications: Software designed, built, or substantially altered in order to support business processes. For example, many life sciences firms have built their own internal tracking software for clinical trials management. Technology Tools: Software used to create, modify, or manipulate software and data, such as Microsoft Visual Studio.NET. Collaborative Capabilities. The manual and electronic processes that enable knowledge workers to work together. These capabilities typically include one or more of the following: Communities: Groups of knowledge workers that share common interests or business processes. Communities include organizational units, clinical project teams, Web portals, and professional organizations. Shared Data: Common information assets shared by knowledge workers. Shared data typically includes study protocols, project plans, clinical trials results, sales performance information, organizational metrics, financial results, and physician and supplier information. Communications: Any mechanism used to distribute information between knowledge workers, including voice, paper, and electronic communication channels such as and Web portals. Integration. The mechanisms that organizations use to link people, systems, and information into a meaningful execution framework. This area includes: Data and Semantics: Common data structures and their corresponding interpretations (e.g., clinical data standards and coding dictionaries). Business Processes: The defined business workflow within and across business areas (e.g., clinical trial execution). Business to Business: The mechanisms used to share data, semantics, and business processes with external entities (e.g., clinical data interchange between a pharmaceutical company and a contract research organization for a clinical trial). Infrastructure. The people, processes, and technology resources businesses rely on to execute all of the other areas. Infrastructure typically includes two categories: Operations Management: Capabilities related to day-to-day business activities, including staff management, business performance indicators, and the ongoing oversight and maintenance of computing systems. Shared Resources: Common assets and capabilities that an organization uses in day-to-day operations. These assets might include staff (e.g., administrative and IT professionals), technology resources (e.g., shared access to the Internet), and relationships (e.g., physician and supplier relationships).

13 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 11 Targeted Use Cases Architecture is best derived from articulating real-world business capabilities. While the above taxonomy is useful for describing overall architecture requirements for the life sciences industry, the functional details depend on specific use cases. For Digital Pharma, a series of use cases served as the foundation for exploring the functional and technical aspects of the architecture. Each use case starts with the phrase What would be required in order to... Three samples are provided in the chart below: What would be required in order to provide a clinical project manager with a consolidated view of research and industry information related to their specific project interests upon logging onto their PC in the morning? 2. enable physicians, CROs, and central labs to exchange patient data in near real-time during a clinical trial? 3. create a comprehensive view of research and operational knowledge spanning discovery, preclinical and clinical trials, and marketing? Details There are multiple dimensions that define relevance to a particular user, including job role, organizational unit, therapeutic interests, project team membership, and opt-in topics. The corresponding data can exist across a number of different dimensions, including sources that are structured or unstructured, formal or informal, and internal or external. The architecture must provide information models and taxonomies that can be implemented consistently, while providing the flexibility to account for enterprise-specific requirements. It must also support multiple types of information delivery, such as Web portal components, , and alerts. Issues related to semantic interpretation are also a factor. Finally, the security of systems and information needs to be maintained. Despite the slow but steady adoption of EMR systems, integration of patient information systems with pharmaceutical research systems remains a long term goal for most life sciences organizations. Now that data models such as CDISC exist to support clinical data operations, the focus is shifting to the business processes and supporting architecture needed to effectively implement these models in production environments. Functional aspects include security, workflow definition and execution, collaborative services, guaranteed message delivery, data standard transformations, source records, regulatory requirements, and usability and value for study site staff. Like the first use case scenario, this example focuses on information assimilation through standardized data models. But where the first use case focuses on collecting ad hoc information to streamline individual use, this use case focuses on compiling scientific information for the purposes of reuse and process improvement. The goal is to provide an affirmative answer to the following questions: 1. Can clinical trials execution be improved by analyzing prior physician performance within the indicated therapeutic area (e.g., subject enrollment rate, patient population data, error rates, site visit findings)? 2. Can clinical protocol design be improved by comparing prior design methodologies within and across therapeutic indications, or by running feasibility trials prior to study start-up to look for potential problems? 3. Can information resources be structured and exposed in the architecture in order to fit naturally into staff workflow when creating a protocol document?

14 12 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Business Summary Based on the business processes, industry imperatives, and use cases already described in this white paper, some specific capabilities emerge as important aspects of any life sciences industry architecture: Secure, Agile Collaborative Spaces. The current concept of portals must evolve beyond simple shared document management to provide secure communities for business partners that enable application sharing and knowledge management. Information Availability. Timely decisions require timely access to information. Unstructured data must be readily discoverable, and analytical requirements will increase. Even sources of structured data will need to be utilized in new ways. Usability. Because users of Digital Pharma applications and processes will be geographically disparate, have different levels of technical expertise, utilize the same data to execute different business processes, and be online only part of the time, design and usability are extremely important. Technology Transparency Through Standards-Based Systems and Data. Organizations must be able to deploy and access applications more efficiently and more cost-effectively. Because many companies struggle to manage their own systems, coordinating governance across multiple partners is extremely difficult to achieve. Utilizing accepted standards and specifications is an essential step to solving this issue. Process-centric Solutions. Solutions in any industry should center on business processes. In the life sciences industry this requirement is particularly acute because of the interdependencies with external organizations that are responsible for significant (and sometime life-critical) business processes. Security, Management, and Compliance. Solutions must have strong mechanisms in place for reliability, user authentication, administration, policy enforcement, access management, data privacy, and activity tracking and monitoring.

15 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 13 Digital Pharma Technical Architecture Figure 4 illustrates the high-level Technical Architecture that supports the Digital Pharma Functional Architecture. Figure 4

16 14 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Service Oriented Architecture Principles In order for any technology platform to address the issues above, it is necessary to develop an enterprise-wide approach to the platform an agile architecture that customers and partners can agree to in order to achieve alignment between business and IT objectives. In doing so, efficiencies in standardization and interoperability can be unlocked. Without this architecture, every customer and partner is forced to reinvent the wheel as it works to achieve regulatory compliance, interoperability, migration, and operational excellence. A Service Oriented Architecture (SOA) typically describes interoperable, extensible, federated software models based on XML and Web services. SOA provides a means to offer software functionality to disparate applications and solutions using an autonomous service metaphor. It is commonly discussed within the context of an enterprise or industry architecture because it offers building blocks that can be reused across an enterprise. The Digital Pharma Architecture includes SOA elements that can be used to provide guidance to customers and partners regarding the design and operation of life sciences solutions based on Microsoft technologies. It also offers a framework for enabling partners and customers to develop interoperable solutions. Finally, a long-term goal of this architecture is to remove the contingency between solutions and product versions by offering an architectural lifecycle that is independent of product versions and capable of integrating with solutions based on non-microsoft technologies. The Digital Pharma Technical Architecture [see figure 5] is composed of five general services categories that are discussed in detail in the following sections: Connected Devices Collaborative Application Integration Infrastructure

17 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 15 Connected Devices Device Profiles User Interaction User Interface Storage Networking Management Security Collaborative Application Document Realtime Comm. Shared Team Resources Application Frameworks LOB Applications Analytics Smart Applications Development Real-time Data Synch. RPC Process Orchestration Workflow & Transaction Integration Batch Published Collaboration Security Structured Knowledge Unstructured Remote Data Asynch. Application Interfacing Data Transformation and Coding Messaging Applications Document Database Session Tracking Industry Data Models and Taxonomies Infrastructure Operations Management Shared Monitoring Asset Mgmt. Deployment Remote Operations Maintenance Storage Mgmt. User Mgmt. Security Directory Networking Telecomm Data File & Print Application Scheduling Figure 5 Connected Devices Connected Devices [figure 6] make up the highest layer of the architecture and include physical devices that are used today or likely to emerge in the near future. Examples include PCs, laptops, Tablet PCs, Pocket PCs, Blackberry devices, Smartphones, RFID hardware, and emerging consumer devices. Connected Devices Device Profiles User Interaction User Interface Storage Networking Management Security Figure 6

18 16 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER The diversity of devices (especially mobile devices) will increase dramatically over time and have a direct impact on life sciences organizations. A major requirement of the architecture is to easily accommodate this proliferation of devices. This requires a standards-based approach for integration through the interface services connecting the devices into the architecture. End-user devices have a variety of interfaces depending on the form factor (i.e., large screen vs. small); the level of intelligence embedded in the device in terms of central processing unit (CPU) and memory; the networking capability (i.e., Wi-Fi, Bluetooth, or network-attached); and the data entry capability (i.e. keyboard, touch screen, voice). The interface services provide the mechanisms for rendering applications in different form factors. The standardization of this interface is already embodied today in the work Microsoft is doing with ActiveSync and Windows CE-powered Pocket PC and Windows Mobile -powered Smartphone operating systems. ActiveSync allows data and logic synchronization between devices that run the same application but have dramatically different user interfaces. Through interface services, the architecture separates the logic required to present the user interface from the application itself. These services enable the same application to use a common service layer to support a wide range of client devices. This Connected Devices layer is composed of the following services: Device Profiles. Information related to the technical capabilities and management characteristics of individual devices. Device profiles describe the hardware, application, and locale parameters required to run an application. User Interaction. that provide local mechanisms for user input and output such as keyboard, handwriting recognition, and speech recognition. User Interface. related to the presentation of computing services to users for a specific device. Storage. that provide local information storage. Networking. that provide connectivity between a device and other computing resources. Management. that provide infrastructure management capabilities such as deployment, asset management, and monitoring. Security. that provide authentication and authorization capabilities for the hardware, system, application, and data associated with a device. Collaborative The Collaborative layer [figure 7] includes software components that enable synchronous, asynchronous, and structured collaboration within and beyond the enterprise. These services can be exploited by Application to deliver new solutions very quickly because development effort is not needed to recreate capabilities that already exist in the enterprise. Collaborative Document Realtime Comm. Shared Team Resources Figure 7

19 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 17 The Collaborative layer is composed of the following services: Document. Software components that handle document creation, editing, storage, version control, and access rights management. Real-time Communication. Software components that provide real-time delivery of text, audio, video, and presence information. Examples include , conferencing, presence, instant messaging, and alerting. Shared Team Resources. Software components that are used within a collaborative community to provide shared information resources for users. Examples include discussions, document repositories, lists, calendars, surveys, forms, and news. Application The Application layer [figure 8] refers to software components that encapsulate specific business logic. These software components can be horizontal and applicable to any industry, or vertical and specialized to the needs of the life sciences industry. A business productivity application such as Microsoft Excel is an example of a horizontal software component: a clinical database management system is a vertical software component. Application Application Frameworks LOB Applications Analytics Smart Applications Development Figure 8 The Application layer is composed of the following services: Application Frameworks. Fundamental application development building blocks that are used to create and deliver applications. Application Frameworks includes the Microsoft.NET Framework, J2EE frameworks, portal frameworks, device rendering, runtime environments, and specific business frameworks that provide unique encapsulated business functionality. Line of Business (LOB) Applications. Specific applications that fulfill business process needs. Many LOB applications are commercial off-the-shelf software, but some will be custom developed as well. There are 10 specific LOB applications that are strategic components in the implementation of the Digital Pharma Architecture: desktop productivity, project management, customer relationship management, enterprise resource planning, supply chain management, accounting, human resources, document management (including regulatory submissions), laboratory information systems, and clinical information systems. Analytics. Common information assimilation services used by Application Frameworks and LOB applications to provide data analysis and reporting capabilities. Service types include base science, clinical, business intelligence, and enterprise reporting services. Smart Applications. Client applications that are easy to deploy and manage that provide an adaptive, responsive, and rich interactive experience by accessing local resources and intelligently connecting to distributed data sources. While LOB applications are often commercial off-the-shelf software, smart applications are usually custom developed to meet the specific needs of an organization or business unit.

20 18 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Development. The tools needed during the software development lifecycle to define requirements, perform testing, and manage problems. Development include: Modeling : Provide support for the design and technical validation of service-oriented and distributed applications. Modeling services are used for designing and configuring composable systems, describing logical data center views, and design time technical validation of an application system against data center topology and configuration. Analysis and Design : Provide the tools to specify system requirements and implementation plans. Application Development : Provide the tools to program and build the system. Application Profiling : Provide the tools to ensure that secure, quality, performing code is implemented. Testing Tool : Capture, store, and maintain relationships between test conditions, test cycles, test data, and issue logs. Process Management : Provide the tools to properly sequence business process tasks and manage workflow for complex situations that include multiple groups or systems. Configuration Management : Provide the tools for managing version control, change control, and migration control to ensure that changes to components are properly captured and shared across the development team. Application Defect : Provide the tools to manage, track, document, and resolve system issues. Integration The Integration layer [Figure 9] refers to software components that provide for the common structuring, storage, access, retrieval, and workflow associated with life sciences processes and information. These services can be accessed by Application and Collaboration to facilitate data management and workflow automation. Real-time Data Synch. RPC Process Orchestration Workflow & Transaction Integration Batch Published Collaboration Security Structured Knowledge Unstructured Remote Data Asynch. Application Interfacing Data Transformation and Coding Messaging Applications Document Database Session Tracking Industry Data Models and Taxonomies Figure 9

21 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 19 The Integration layer is composed of the following services: Real-time Data. Software components that provide real-time or near real-time delivery of information between applications. These services include synchronous services, asynchronous services, remote procedure call services, session services, and tracking services (e.g., RFID), as well as application interfacing services that provide logical connectivity between disparate applications such as application adapters, APIs, database connectivity, and Web services. Process Orchestration. Software components that provide for data transformation and workflow between applications. These services include workflow and transaction services, batch services, and data transformation and coding services that exploit unstructured services. Published. Software components that give users or applications (internal or external to an organization) managed access to the architecture. These services include collaboration services, messaging services, security services, and application services. They are usually extensions of services that exist elsewhere in the architecture, but that require additional capabilities (e.g., access controls). Structured Knowledge. Information repositories that contain some level of structural or semantic metadata, usually provided through Industry Data Models. These services include: Unstructured : Capabilities for inferring, interpreting, or applying structure to otherwise unstructured knowledge sources. Document, Database, and Remote Data : Capabilities for accessing and indexing knowledge sources within and beyond the corporate enterprise. Industry Data Models and Taxonomies: Standardized knowledge structures within the life sciences industry such as CDISC, HL7, and medical coding dictionaries. Historically, data models are based on individual line-of-business applications. But as the complexity of information technology environments and business operations has increased, the ability to make broader use of the information within those systems has not kept pace with the business needs. These industry data models and taxonomies are important because they form the basis for cross-system interoperability. Without a common definition of clinical trial, for example, it becomes very difficult to orchestrate many different systems within one business process related to a clinical trial. Infrastructure The Infrastructure layer [Figure 10] provides services for the provisioning and management of a shared information infrastructure. Infrastructure Operations Management Shared Monitoring Asset Mgmt. Deployment Remote Operations Maintenance Storage Mgmt. User Mgmt. Security Directory Networking Telecomm Data File & Print Application Scheduling Figure 10

22 20 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER The Infrastructure layer is composed of the following services: Operations Management. related to the ongoing oversight and management of information technology assets and resources. Monitoring : Monitor the run-time state of an application including server load, job execution, and system error conditions and trigger notification events to software routines or human beings. Typically, exceptional conditions are routed to a systems management location or console. This systems management capability may automatically issue system commands to remedy problems that are logged. Client machines and logs also are monitored. Deployment : Provide a managed and controlled mechanism for the release of software and operating system changes to a specific location or facility. For example, a client image may be deployed in two steps first to a server and then loaded to the client at a specified time. The ability to revert to a previous image is also provided by this service. Before a new deployment occurs, it checks for software prerequisites and ensures that the physical hardware is adequate for new software releases (e.g., that there is enough disk space or memory on the machine). Maintenance : Provide the tools for centrally located staff to diagnose issues that are occurring on a device at a remote facility or location. This capability works along with remote operation to provide the ability to resolve issues from a central location. Asset Management : Provide visibility into the location and ownership of any device located within a specific location, including mobile devices, laptops, and desktop systems. This service also tracks the software versions installed on each hardware device. Remote Operations : Provide the tools for centrally located staff to control and change system configuration and settings on hardware that resides within a specific location. This capability includes the ability to take over the operations of a remote machine to resolve problems. It also should allow remote staff to shadow a user or take control away from a user. Shared. for common assets that an organization can use across multiple business areas. Storage Management: Provides tools to efficiently manage and optimize the use of storage technology. Security : Provide authentication and authorization capabilities for enterprise systems and users and include: Core Security : Provide the foundation for the other security services and authentication services to verify that an entity is what it claims to be; deliver authorization services that implement access policies and restrict which entities can access specific resources; and include encryption services that use cryptography to protect data within a transaction. System Security : Interact with the environment, information, and business logic services to provide certificate management, content and virus inspection, and intrusion detection. Application Security : Interact with the presentation, business logic, and integration services to provide single sign-on capabilities, registration and identification capabilities, non-repudiation services, and notarization and logging services.

23 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 21 Networking : Provide data communications within and across life sciences enterprises. Examples include LAN, WAN, VPN, RAS, and wireless protocols. These also include remote operating system protocols, base communication protocols, and communication control services. Data : Provide common capabilities for storing data. These services include storage, versioning, replication, synchronization, indexing, compression, stores, business intelligence, data analytics, and data warehouses. Application : Provide common functional services to hosted applications. Examples include basic operating system capabilities and search and index functions. User Management : The common enterprise services for managing user-oriented security services within regulated environments (e.g., unique user IDs). These services are sometimes included in Security. Directory : The common enterprise network services and data structures that provide input into Security. These services are sometimes included in Security. Telecommunication : Provide voice communications within and across life sciences enterprises. File and Print : Provide basic server capabilities across a life sciences enterprise. Scheduling : Provide capabilities to execute software components at specific times or time intervals.

24 22 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Other Dimensions Compliance Framework The Digital Pharma Architecture Compliance Framework provides the means to assess and address regulatory compliance requirements. Microsoft develops software products that are used in all markets for many different purposes. For example, Microsoft Windows Server 2003 can be used as a file server, printer server, Web server, application server, database server, messaging infrastructure, and more. Given the breadth of Microsoft s product offerings and the wide range of uses for each product, it is impossible for Microsoft to offer detailed guidance on regulatory compliance for individual products. However, Microsoft does play a role in helping customers understand the best ways to establish and maintain the compliant use of its technologies. A Compliance Framework offers a consistent mechanism for understanding and addressing the compliance issues related to Microsoft s platform and products. This framework also serves to help identify potential improvements in Microsoft products that will facilitate the adoption, use, and management of Microsoft technologies in compliant environments. More information regarding the development of this framework is available through the resources listed in Appendix C. Governance Governance refers to ongoing management and decision-making for all aspects of the architecture as they relate to industry business objectives. Customers and partners play an active role in this architecture governance. One of Microsoft s greatest assets as a technology platform provider is its global network of customers and partners that use Microsoft technologies to develop innovative solutions. In many ways, the value of Microsoft s technologies are made relevant to life sciences organizations by companies and individuals who can match Microsoft product offerings with their own industry experience to create new capabilities. Within Microsoft, there are two aspects to governance: 1. Managing a product roadmap over the life of individual Microsoft products. 2. Making ongoing recommendations to internal product teams regarding product enhancements that will better serve the needs of the life sciences industry. Customers that choose to make an investment in Microsoft technologies should have information about the relationship between a solution architecture, Microsoft s current recommended product architecture, and Microsoft s future architecture direction. Partners should have a clear understanding of how to develop scalable, reliable, and secure solutions on the Microsoft platform that will have a long shelf life with customers. Microsoft sees itself as a facilitator in driving consensus on these issues within the industry through open and active dialogues with customers and partners on business and technology needs.

25 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 23 Interoperability Framework Interoperability between applications is a key part of Microsoft s Digital Pharma Architecture. This section discusses interoperability between applications that have the following characteristics: They are on the same or a different platform They are in the same or a different physical location They are inside or outside the enterprise This framework defines the use of specific standards that are identified in this section. When organizations consider the business processes and technical relationships between application systems and their data, there are several types of interoperability to consider: Data Interchange. The process required for one system to read information from or write information to another application using defined data specifications. Historically, formats for delivering data integration in life sciences have included flat files, database tables, and statistical analysis data sets. Discrete formats such as XML have become the preferred format for data structures because they offer cross-platform acceptance and standardization. Application Integration. The process of data interchange that allows the execution of applicationspecific business logic in an automated way. In addition to directly exercising native application programming interfaces, asynchronous messaging techniques provide for resiliency in enabling reliable integration. Web services (based on XML) have become the preferred mechanism for providing cross-platform application integration. Application Interoperability. The capability of actions within one application to drive behavior within other systems in a logical way. This type of interoperability can be behind the scenes data driving the actions of other systems or it can occur within the user interface by coordinating the user experience of multiple applications through single sign-on and similar approaches. Mechanisms such as Web services enable this type of rich interoperability, and standards organizations such as HL7 have implemented standards to provide this functionality. Digital Pharma Architecture addresses these three types of interoperability by: Using Web services to link application components for use by multiple applications within an enterprise, such as medical coding or serious adverse event processing. Using a messaging and orchestration capability to pass information between applications. Using new and emerging technologies that enable application interoperability within and between enterprises. Associated with each of these classifications is a security layer that protects communications between applications. Security is increasingly being driven by standards such as WS-Security, and takes at least four forms in the world of interoperability: Data Encryption. The form of the data is changed so others cannot read or interpret it. Identification. The user or destination of the data is identified through a directory service such as Active Directory and/or Universal Description, Discovery and Integration (UDDI). Authorization and Access Control. Once users have been identified, their roles are checked against the data being sent to determine whether or not they have the authority to view requested data. Validation. Ensures that data passed on the network has not been tampered with en route to its destination.

26 24 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Web and Standards A Web service uses standards that allow applications to request information or services from each other. One of the basic tenets of Web services is to define the data content in XML using an agreed-to content schema such as CDISC or HL7. This removes the barrier of data format. Other communications standards are used to describe and locate the Web service within or outside the enterprise. These standards include Simple Object Access Protocol (SOAP), UDDI, and communication protocol standards for data transmission. A typical transaction flow is illustrated below [figure 11]. Application from Vendor A on Microsoft Microsoft.NET Platform XML Store Standard Vertical Schemas (CDISC, HL7, SPL) Application from Vendor B on Other or Microsoft Other or Microsoft.NET Cross Platform Global Standards (UDDI, SOAP, Standard Horizontal Schemas) Figure 11 Microsoft has a strong commitment to Web services architecture and its corresponding protocols. The WS-* standards form the foundation of Web services implementation within the Digital Pharma Architecture, and these standards allow life sciences organizations to take advantage of Microsoft s ongoing R&D investments in innovative software.

27 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 25 Shared Web services make it possible to share logical application components across multiple applications. A clinical trials management service can share status information between a project management system and a manufacturing planning system so that both systems provide accurate forecasting. A pharmaceutical company can offer a clinical data gateway where multiple contract research and laboratory partners can provide realtime patient data updates as clinical trials progress regardless of what software the partner used to collect and process the data. Pharmaceutical product catalog information can be exposed to distribution partners in real time without company-specific customizations and untimely updates. The Digital Pharma Architecture fully embraces Web services as a way to deliver application components that perform discrete activities. This approach allows a more modular extension of applications, provides speed and agility in performing business functions, and allows multiple application providers to work together more seamlessly to deliver solutions for life sciences enterprises. Virtual enterprises can be created as organizations align their services to facilitate common business processes. Restructuring business capabilities to account for new partnerships, mergers, acquisitions, and process improvement initiatives becomes more practical and cost effective. New virtual applications closely aligned to specific knowledge worker needs can be assembled, delivering unified application experiences across applications and infrastructures. Microsoft supports the development of shared Web services by: 1. Working with standards organizations like CDISC and HL7 to expand existing data standards efforts into broader industry interoperability frameworks (e.g., Single Source). 2. Creating and publishing reference architectures for the use of Microsoft products within life sciences business processes (e.g., Clinical Trial Initiation Reference Implementation for Microsoft Office 2003). 3. Working with ISVs, customers, and partners on the development of specific components of the Digital Pharma Architecture.

28 26 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Real-Time Information Ecosystem One of the primary advantages of the Digital Pharma Architecture is the ability to provide real-time information transfer and workflow between disparate platforms. For example, a life sciences firm can create a service that provides a patient data gateway that can be used by business partners. The gateway can receive data using a variety of communication mechanisms, including Web services, , file transfer, or HTTP post. Once the data is received, the gateway can populate a clinical data warehouse and initiate a workflow process in which the data is reformatted and passed on to subsequent destinations. This hub-and-spoke model [figure 12] enables the staging and use of patient and operational information wherever it is most appropriate. It enables near real-time access to critical information related to study performance that leads to more timely, event-driven actions (e.g., a protocol amendment for inclusion/ exclusion criteria). Note that because the applications in this example are loosely coupled, the architecture provides for flexibility in communications availability and application changes. Figure 12

29 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 27 The associated workflow can be as complex as the business process demands. In a simple case, the hub might simply wait to receive information from any source and, based on the source and the data itself, select an appropriate system to update. In a more complex scenario, the workflow might provide for the following: The physician s office uses an electronic medical record (EMR) system that is aware of a study for a given patient. When the patient data is collected by the physician, the EMR extracts relevant trial data and transmits it to the hub as a Web services call. The hub receives the data and verifies its integrity. Because the hub had been expecting data, it updates the status of the in-house clinical trial management system (CTMS). If data isn t received on time, an alert is sent to the study monitor. The hub also converts the data to a proprietary data format for loading into the pharmaceutical company s legacy clinical data management system (CDMS). It also updates the project management system with the current status of the site. Noting that this patient is having blood work done, the hub creates an electronic lab test order indicating that the lab handling samples for this trial should expect to receive a sample within 24 hours. The hub also creates a task to receive the lab results electronically from the lab in HL7 format within 96 hours. When the data is received, the HL7 format will automatically be converted to the CDISC lab format for internal purposes. For this trial, the pharmaceutical company has contracted with a CRO to provide statistical support Since their statistics department uses an in-house CDMS, the hub transmits a copy of the data to the CRO so that statisticians can work with the most current copy of the data.

30 28 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Architecture to Implementation Today, Digital Pharma is being implemented at life sciences organizations through Microsoft products and solutions, and many ISVs and systems integrators have developed enterprise solutions that conform to the Digital Pharma Architecture. This section identifies the alignment of Microsoft products and solutions with the Technical Architecture. It discusses the implications for enterprises and ISVs adopting the architecture within their own domain. This section also examines how disruptive technologies can be incorporated into a Digital Pharma Architecture adoption plan. Use of Microsoft Products in the Architecture Microsoft solutions fully support the Digital Pharma Architecture. Not only do they deliver the infrastructure required within the Technical Architecture, but they also support the core value propositions of enabling Speed to Insight and Value for Cost while providing a platform for long-term growth. It should be noted that the architecture does not require the exclusive use of Microsoft products. Please refer to Appendix A for a more detailed description of individual Microsoft products and their role in Digital Pharma. Adoption Approaches for Customers and Partners All organizations, whether focused on life sciences or another industry, utilize technology progressively. A company may start with a simple application to enable users to communicate electronically. As the organization becomes more accustomed to using , other features like calendaring, distribution lists, and common file shares might be deployed. With experience, companies can gradually increase both the capabilities of their technology investments (e.g., what they can do) as well as the reach of those technology investments (e.g., how far they can be used). The diagram on the next page [figure 13] illustrates what this model might look like for a typical pharmaceutical organization. This progressive capability approach is valuable for most organizations for the following reasons: 1. Disruption of business activities is minimized and distributed over time. 2. Organizational culture can play a more prominent role in decision making. 3. Risks are minimized as experience and knowledge is accumulated. 4. Foundational technologies are used to support higher-level capabilities.

31 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 29 External , fax Clinical trials Recruitment Marketing Detailing Drug knowledge portals Collaborative review Physician recruitment Extranet / VPN for B2B Real-time B2B Medical records integration CDISC integration NME licensing Submissions Real-time safety Point of care solutions Physician patient B2C Discovery marketplaces Genomic patient profiling Drug lifecycle portals Regulatory development MR-based trials Clinical workflows Organization , calendar Enterprise applications CRM, ERP, CDMS, CTMS, CTMM Intranet Project management Knowledge management Document management BI reporting Data-driven CRM Clinical repositories NME targeting Grid computing Business intelligence CDISC integration Drug lifecycle portals Clinical data mining Latent variable analysis Clinical trial prototyping Clinical workflows Reach Team Calendar Team portals Project management Live Meeting / Video conferencing Event-driven alerts Performance monitoring Workflow monitoring Extended virtual teams Mobility Worker Calendar Voic File sharing Teleconferencing Instant messaging Event-driven alerts Performance monitoring Workflow monitoring Mobility Messaging Collaboration Transactions E-Health Capability Figure 13 Most large pharmaceutical companies have explored solutions in many of these domains. Of course, exploring or even implementing a solution does not mean that it has proven to be effective. Today, many life sciences organizations are re-examining investments in some of the lower domains in response to changing business needs that have been expressed within the higher domains. Thus, the model is useful for exploring business capabilities, but it is not static it evolves as an organization changes over time. Enterprise adoption of Digital Pharma focuses on four primary activities depicted in the diagram on the next page [figure 14]. The enterprise must start with a baseline assessment of the IT applications and services being provided. Once the baseline is established, it is mapped to the Digital Pharma Architecture to identify new application requirements and capabilities that align with the Digital Pharma initiative. Functional gaps can then be determined and prioritized based on order of importance to the enterprise. From this information, an application development or acquisition plan can be built, and the plan for implementing new capabilities can be defined. The implementation model should define a road map for layering new capabilities and leveraging the Interoperability Framework to enable integration with existing IT applications and services. For specific prioritized capabilities, this plan should determine whether the enterprise will build solutions in-house or acquire them from software vendors or systems integrators. Appendix B describes implementation models in greater detail.

32 30 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER Microsoft Digital Pharma: An Incremental Approach Strategic Impact Base Infrastructure Digital Pharma Phase I Digital Pharma Phase II Digital Pharma Future Business Transformation Worker Productivity Operational Efficiency Integration technology Commodity hardware Directory services Use of XML, Web services, and WS-* Infrastructure and application management processes Technology and Solution Adoption Timeline Integration of disparate information sources Integrated business and financial management applications CRM Information sharing portals Business Intelligence Mobile devices Tablet PC, Pocket PC, Smartphone Adoption of industry standards such as CDISC Knowledge discovery tools Closed Loop Promotion Compliance monitoring Contextual collaboration High performance computing Drug development productivity tools Business analytics and performance management RFID tagging and tracking Business process management and automation Information insight tools Next generation collaboration tools Real-time monitoring and decision making across the value chain Knowledge reuse to generate new insights from existing assets New smaller form factors with increased computing power Social networking Figure 14 Many software providers have begun to deliver the foundational infrastructure for Digital Pharma as part of their ongoing platform investments. This may include databases, messaging capabilities, and reporting or query software. Digital Pharma provides a framework that gives ISVs the ability to concentrate on what they do best: develop and deliver application software. Microsoft is actively recruiting ISV partners to adopt and utilize this architecture.