microsoft digital pharma - idc-online · microsoft digital pharma architecture white paper 5....

www.microsoft.com/lifesciences

m

Microsoft Digital Pharma > Industry Architecture Technical White Paper

Published June 2005

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.

© 2005 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.

Contents

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The Value of Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Speed to Insight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Value for Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Interoperability Across the Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Technology and Information Lifecycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Digital Pharma Business Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Business Entities and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 High-Level Capabilities Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Targeted Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Business Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Digital Pharma Technical Services Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Services-Oriented Architecture Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Connected Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Collaborative Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Application Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Integration Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Infrastructure Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Other Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Compliance Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Interoperability Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Web Services and Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Shared Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Real-Time Information Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Architecture to Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Use of Microsoft Products in the Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Adoption Approaches for Customers and Partners . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Appendix A: Major Microsoft Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Appendix B: Implementation Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Base Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Release Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Deployment Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Partnering Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Appendix C: Key Technical Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

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.

MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER 3

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 InsightAlmost 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.

4 MICROSOFT DIGITAL PHARMA ARCHITECTURE WHITE PAPER

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 CostThe 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.


Interoperability Across the EcosystemTo 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 LifecyclesThe 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.


Digital Pharma and Business Areas

Business Entities and ProcessesGiven 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.

Figure 1

Drug Discovery

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

Drug Development


• Design research programs and trials

• Run research programs and trials

• Report research program and trial results

• Manage research materials


• Manage physician and researcher relationships

• Manage regulatory issues and relationships


• Speed clinical trials

• Efficacy and safety insights

• Faster confirmation of marketable compounds

• Quicker decisions for less promising compounds

• Reduce clinical trial costs

Manufacturing & Supply Chain


• Manufacture drugs

• Manage supplier relationships

• Manage distributor relationships


• Manage materials



• Real time monitoring

• Rapid development of optimal production processes

• Accurate forecasting of demand and inventory

• Increased manufacturing efficiency

Sales & Marketing


• Market drugs to physicians, consumers, and plans

• Manage customer relationships


• Develop and deliver educational resources

• Manage care provider questions and contact



• Closed Loop Promotion

• Real time field analysis

• Faster decision making

• Faster response to physician’s needs

• Reduction in cost of promotional materials


Drug Discovery


• Discover leads






• Rapid identification of targets and compounds

• Increase volume of NCEs

• Efficient information sharing

• Reduction in time and expense










• Real time monitoring

• Rapid development of optimal production processes

• Accurate forecasting of demand and inventory

• Increased manufacturing efficiency

Sales & Marketing










• Real time field analysis

• Faster decision making

• Faster response to physician’s needs

• Reduction in cost of promotional materials

Drug Development










• Speed clinical trials

• Efficacy and safety insights

• Faster confirmation of marketable compounds

• Quicker decisions for less promising compounds

• Reduce clinical trial costs

Information Assets for New Treatment

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).

Figure 2


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 MapFigure 3 below depicts the top level of the design needed to support the Digital Pharma business processes and objectives described above.

Figure 3

Drug Discovery

• Discover leads





Drug Development















Sales & Marketing







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


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 e-mail 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).


Targeted Use CasesArchitecture 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:

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, e-mail, 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?

“What would be required in order to...”

1. 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?


Business SummaryBased 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.


Digital Pharma Technical Services Architecture

Figure 4 illustrates the high-level Technical Services Architecture that supports the Digital Pharma Functional Architecture.

Figure 4


Service Oriented Architecture PrinciplesIn 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 Services Architecture [see figure 5] is composed of five general services categories that are discussed in detail in the following sections:

• Connected Devices

• Collaborative Services

• Application Services

• Integration Services

• Infrastructure Services


Integration Services

Process Orchestration Published ServicesReal-time Data Services StructuredKnowledge Services

Connected Devices

Device Profiles

Collaborative Services Application Services

User Interaction

Services

User Interface Services

StorageServices

Networking Services

Management Services

SecurityServices

DocumentServices

RealtimeComm.Services

Shared Team Resources

ApplicationFrameworks

LOBApplications

AnalyticsServices

“Smart” Applications

DevelopmentServices

Asynch.Services

ApplicationInterfacing

Services

Synch.Services

RPC Services

SessionServices

TrackingServices

Document Services

DatabaseServices

Unstructured Services

RemoteData

Services

Industry Data Models and Taxonomies

Workflow & Transaction

Services

Batch Services

Data Transformation and Coding Services

MessagingServices

ApplicationsServices

Collaboration Services

SecurityServices

Infrastructure Services

Operations Management Shared Services

MonitoringServices

DeploymentServices

Asset Mgmt.Services

RemoteOperations

StorageMgmt.

Security Services

NetworkingServices

Data Services

ApplicationServices

Maintenance Services

UserMgmt.

DirectoryServices

TelecommServices

File & PrintServices

SchedulingServices

Figure 5

Connected DevicesConnected 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.

Figure 6

Connected Devices

Device Profiles

User Interaction

Services

User Interface Services

StorageServices

Networking Services

Management Services

SecurityServices


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 Services. Services that provide local mechanisms for user input and output such as keyboard, handwriting recognition, and speech recognition.

User Interface Services. Services related to the presentation of computing services to users for a specific device.

Storage Services. Services that provide local information storage.

Networking Services. Services that provide connectivity between a device and other computing resources.

Management Services. Services that provide infrastructure management capabilities such as deployment, asset management, and monitoring.

Security Services. Services that provide authentication and authorization capabilities for the hardware, system, application, and data associated with a device.

Collaborative ServicesThe Collaborative Services 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 Services to deliver new solutions very quickly because development effort is not needed to recreate capabilities that already exist in the enterprise.

Figure 7

Collaborative Services

DocumentServices

RealtimeComm.Services

Shared Team Resources


The Collaborative Services layer is composed of the following services:

Document Services. Software components that handle document creation, editing, storage, version control, and access rights management.

Real-time Communication Services. Software components that provide real-time delivery of text, audio, video, and presence information. Examples include e-mail, 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 ServicesThe Application Services 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.

Figure 8

The Application Services 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 Services. 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.

Application Services

ApplicationFrameworks

LOBApplications

AnalyticsServices

“Smart” Applications

DevelopmentServices


Development Services. The tools needed during the software development lifecycle to define requirements, perform testing, and manage problems. Development Services include:

• Modeling Services: 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 Services: Provide the tools to specify system requirements and implementation plans.

• Application Development Services: Provide the tools to program and build the system.

• Application Profiling Services: Provide the tools to ensure that secure, quality, performing code is implemented.

• Testing Tool Services: Capture, store, and maintain relationships between test conditions, test cycles, test data, and issue logs.

• Process Management Services: Provide the tools to properly sequence business process tasks and manage workflow for complex situations that include multiple groups or systems.

• Configuration Management Services: 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 Services: Provide the tools to manage, track, document, and resolve system issues.

Integration ServicesThe Integration Services 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 Services and Collaboration Services to facilitate data management and workflow automation.

Figure 9

Integration Services

Process Orchestration Published ServicesReal-time Data Services StructuredKnowledge Services

Asynch.Services

ApplicationInterfacing

Services

Synch.Services

RPC Services

SessionServices

TrackingServices

Document Services

DatabaseServices

Unstructured Services

RemoteData

Services

Industry Data Models and Taxonomies

Workflow & Transaction

Services

Batch Services

Data Transformation and Coding Services

MessagingServices

ApplicationsServices

Collaboration Services

SecurityServices


The Integration Services layer is composed of the following services:

Real-time Data Services. 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 Services. 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 Services. Information repositories that contain some level of structural or semantic metadata, usually provided through Industry Data Models. These services include:

• Unstructured Services: Capabilities for inferring, interpreting, or applying structure to otherwise unstructured knowledge sources.

• Document, Database, and Remote Data Services: 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 ServicesThe Infrastructure Services layer [Figure 10] provides services for the provisioning and management of a shared information infrastructure.

Figure 10

Infrastructure Services

Operations Management Shared Services

MonitoringServices

DeploymentServices

Asset Mgmt.Services

RemoteOperations

StorageMgmt.

Security Services

NetworkingServices

Data Services

ApplicationServices

Maintenance Services

UserMgmt.

DirectoryServices

TelecommServices

File & PrintServices

SchedulingServices


The Infrastructure Services layer is composed of the following services:

Operations Management Services. Services related to the ongoing oversight and management of information technology assets and resources.

• Monitoring Services: 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 Services: 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 Services: 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 Services: 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 Services: 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 Services. Services 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 Services: Provide authentication and authorization capabilities for enterprise systems and users and include:

– Core Security Services: 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 Services: Interact with the environment, information, and business logic services to provide certificate management, content and virus inspection, and intrusion detection.

– Application Security Services: 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.


• Networking Services: 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 Services: Provide common capabilities for storing data. These services include storage, versioning, replication, synchronization, indexing, compression, stores, business intelligence, data analytics, and data warehouses.

• Application Services: Provide common functional services to hosted applications. Examples include basic operating system capabilities and search and index functions.

• User Management Services: 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 Services.

• Directory Services: The common enterprise network services and data structures that provide input into Security Services. These services are sometimes included in Security Services.

• Telecommunication Services: Provide voice communications within and across life sciences enterprises.

• File and Print Services: Provide basic server capabilities across a life sciences enterprise.

• Scheduling Services: Provide capabilities to execute software components at specific times or time intervals.


Other Dimensions

Compliance FrameworkThe 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.

GovernanceGovernance 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.


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 application-specific 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.


Web Services and StandardsA 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].

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.

Application fromVendor A on

Microsoft

Microsoft .NETPlatform XML Store

Application fromVendor B on

Other or Microsoft

Other orMicrosoft .NET

StandardVerticalSchemas(CDISC,

HL7, SPL)

Cross Platform Global Standards(UDDI, SOAP, Standard Horizontal Schemas)


Shared ServicesWeb 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 real-time 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.


Real-Time Information EcosystemOne 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, e-mail, 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


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.


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 Services 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 ArchitectureMicrosoft solutions fully support the Digital Pharma Architecture. Not only do they deliver the infrastructure required within the Technical Services 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 PartnersAll organizations, whether focused on life sciences or another industry, utilize technology progressively. A company may start with a simple e-mail application to enable users to communicate electronically. As the organization becomes more accustomed to using e-mail, 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.


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.

External

Organization

Team

Worker

E-mail, fax Clinical trials Recruitment Marketing Detailing

E-mail, calendarEnterprise applicationsCRM, ERP, CDMS, CTMS, CTMMIntranet

E-mail Calendar

E-mail Calendar Voicemail

Messaging Collaboration Transactions E-Health

Real-time B2BMedical records integrationCDISC integrationNME licensingSubmissionsReal-time safetyPoint of care solutions

Data-driven CRMClinical repositoriesNME targetingGrid computingBusiness intelligenceCDISC integration

Event-driven alertsPerformance monitoring

Event-driven alertsPerformance monitoring

Physician patient B2CDiscovery marketplacesGenomic patient profilingDrug lifecycle portalsRegulatory developmentMR-based trialsClinical workflows

Drug lifecycle portalsClinical data miningLatent variable analysisClinical trial prototypingClinical workflows

Workflow monitoringExtended virtual teamsMobility

Workflow monitoringMobility

Rea

ch

Drug knowledge portals Collaborative review Physician recruitment Extranet / VPN for B2B

Project managementKnowledge managementDocument managementBI reporting

Team portalsProject managementLive Meeting / Video conferencing

File sharingTeleconferencingInstant messaging

Capability


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.

Microsoft Digital Pharma: An Incremental Approach

Business Transformation

Worker Productivity

Operational Efficiency

Stra

teg

ic I

mp

act

• Integration technology

• Commodity hardware

• Directory services

• Use of XML, Web services, and WS-*

• Infrastructure and application management processes

• 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

• Knowledge discovery tools


• 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

• 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

Base Infrastructure

Digital Pharma Phase I

Digital Pharma Phase II

Digital PharmaFuture

Technology and Solution Adoption Timeline


Conclusion

Microsoft’s focus in life sciences is driven by work the company has done with customers to understand their specific business requirements. Microsoft customers have already made extensive investments in information technology. Although many life sciences organizations are constantly evaluating new commercial offerings for the competitive or productivity advantages they may offer, most life sciences companies are searching for ways to get more value out of their existing investments without having to adopt divergent strategies that lead to larger operating expenses. In this context, Microsoft can deliver great value to life sciences enterprises. Microsoft technologies are in widespread use across most life sciences organizations and are widely regarded as easy to use. Knowledge workers within life sciences organizations recognize the value of using familiar Microsoft software to do more creative things with information.

The technology landscape for life sciences continues to evolve, with new and potentially disruptive technologies constantly emerging. The increasing adoption of RFID, of high-performance computing, and of semantic Web applications will force many organizations to reconsider how best to use their existing technology assets while pursuing new business and technology innovation. The Digital Pharma Architecture is designed to help organizations manage ongoing change by abstracting certain layers of enterprise architecture into a more agile design.

Some of the scenarios that Digital Pharma addresses represent the very leading edge of capabilities in the life sciences industry, such as integration with physician EMR systems, “smart” applications, and semantic inference of unstructured data. Microsoft and its partners are exploring these evolving concepts, and as new capabilities emerge, they will be integrated into the architecture through standards and services.

As described earlier, Microsoft solutions can provide a significant portion of the Technical Services Architecture defined in this paper. Not only does Microsoft technology deliver production-ready, enterprise-scalable solutions, it can also deliver solution capabilities more efficiently than competing platforms. Microsoft solutions lower total cost of ownership by reducing overall solution complexity and simplifying installation and deployment processes.

The Digital Pharma Architecture is a starting point for life sciences enterprises and ISVs that are considering developing and delivering new and innovative capabilities. Over time, this architecture will continue to evolve to reflect the ongoing state of technology and the life sciences industry. This architecture will continue to be the foundation for Digital Pharma and the technology standard for Microsoft in the life sciences industry.


Appendix A: Microsoft Products and Technologies


Product Function

Microsoft Windows Server 2003 Windows Server provides basic platform support. It includes many services as part of the platform, including all UI and communications protocol functions. Other functions are highlighted elsewhere in the table with an asterisk (*).

Microsoft Active Directory* Active Directory delivers authentication and role security services.

Microsoft SQL Server™ SQL Server offers database support. It includes analytics, data transformation, and reporting functionality. A basic database engine, Microsoft Data Engine (MSDE), is available from Microsoft at no charge.

Microsoft Windows XP These operating systems provide basic client platform support. Windows XP Professional, Microsoft Windows Professional provides full desktop support for any client. Windows XP Embedded XP Embedded, and Microsoft allows a smaller image for function-specific devices. Windows CE is geared toward Windows CE wireless handheld devices or older terminals with less processing power or memory.

Microsoft Message Microsoft Message Queuing Center provides a guaranteed delivery messaging Queuing Center* capability between processors.

Microsoft BizTalk® Server 2004 BizTalk Server provides orchestration and messaging functions. It uses MSMQ for messaging.

Microsoft Internet Security Internet Security and Acceleration Server provides a firewall and supports a caching and Acceleration Server function for Internet applications.

Microsoft Systems Systems Management Server provides application deployment, security patch Management Server management, mobility terminal management, asset management, and integration with Active Directory through Windows Management Services.

Microsoft Operations Manager Microsoft Operations Manager delivers enterprise-class operations management by providing comprehensive event management, proactive monitoring and alerting, reporting, and trend analysis.

Microsoft Windows Windows SharePoint Services is a collection of services for Microsoft Windows Server SharePoint® Services 2003 used to create Web sites to share information and foster collaboration. Windows

SharePoint Services is used as a development platform for creating collaboration and information-sharing applications.

Microsoft Commerce Server 2002 Commerce Server 2002 provides a powerful set of capabilities for non-transaction-based sites, including user profiling, content targeting, multi-language capability, and advanced business analytics. Commerce Server 2002 features extend to transaction-based sites with capabilities for catalog management, order processing, and merchandising.

Microsoft Content Management Content Management Server 2002 enables companies to quickly and efficiently build, Server 2002 deploy, and maintain content-rich Web sites. By streamlining the Web publishing process, Content Management Server can reduce the need for costly site maintenance, empowering business users to manage their own content.

Microsoft Visual Studio Visual Studio .NET 2003 provides a single comprehensive development tool for creating the .NET 2003 next generation of applications. Developers can use Visual Studio .NET to create powerful

applications quickly and effectively, and link any platform or device. Visual Studio .NET is the only development environment built from the ground up to enable integration through XML Web services. By allowing applications to share data over the Internet, XML Web services enable developers to assemble applications from new and existing code, regardless of platform, programming language, or object model.

Appendix B: Implementation Models

Clayton Christensen wrote in The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail that the biggest struggle organizations face in introducing new and disruptive technologies is the discontinuity that change can bring to existing operations. How can an enterprise make radical changes to its environment without harming performance? Every enterprise will have a different road map for innovative change. Microsoft has identified four critical components that an enterprise should consider: base infrastructure, release strategy, deployment model, and partnering strategy.

Base InfrastructureThe basic premise of Digital Pharma is that it is process-led and technology-enabled. Critical to the deployment of new and innovative technologies is the establishment of a base infrastructure that is positioned for future innovations. Standards-based technologies that use Web services for integration and interoperability are a strong starting point. At a more fundamental level, the deployment of current releases of existing operating systems platforms and other infrastructure software positions organizations to implement new solutions that can take advantage of the underlying services that the latest versions provide. The adoption of an architecture such as Microsoft’s Digital Pharma provides a solid foundation for creating a base infrastructure that can support the implementation of future innovations.

Release StrategyOnce an enterprise has decided which innovations it will implement, it must develop an overall release strategy. Options span a spectrum that runs from bigger, fewer releases on one end to smaller, more frequent releases on the other end [figure 15].

Figure 15

Bigger, fewer releases target the delivery of long-term capabilities that require significant amounts of development, testing, and overall change management coordination. The focus is on building sustainable business benefits, expanding knowledge worker productivity and capabilities, and facilitating fundamental business process change. This release strategy is typically used when the desired change is complex and profound in its implications for the enterprise.


Focus on Long-TermCapabilities

Focus on Near-Term

Benefits

Release 2

Bigger/Fewer Releases

R4

Enablement Speed to Value

R1

R2

R3

Smaller/more frequent Releases

Release 1

Smaller, more frequent releases are more specific and targeted in their approach to driving business benefit. This release strategy prioritizes benefit goals and addresses opportunities that have the greatest value first. The goal is to develop and deliver multiple pilots and prototypes and accrue benefits in the short term that can fund the next set of programs. When innovation opportunities are more compartmentalized, this approach works well and builds momentum and a track record of success. A core principle of the Digital Pharma Architecture is that it should provide a flexible architecture that allows an enterprise to gradually implement new capabilities in a more modular fashion than previous architecture models have enabled.

Deployment ModelHow to phase in innovation is another tough issue for enterprises contemplating change. Four approaches to deployment are commonly used: Big Bang, Function by Function, Location by Location, and Combination [figure 16].

Figure 16

• Big Bang. Big Bang implementations involve the deployment of several new, innovative capabilities at once (after testing and validation have been completed). The benefits lie in reducing execution risk by minimizing the level of integration required and simplifying the conversion and cut-over process. The drawbacks of Big Bang are that management effort is greatly increased due to the planning requirements, the development effort is not phased so a substantial resource load is required, and the magnitude of change introduces substantial business risk.


Phased Combination

Phased Location by

Location

Phased Function by

Function

Big Bang

Lower Cost

Higher Risk

Lower Risk

Higher Cost

• Function by Function. Function by Function focuses on discretely enabling specific capabilities that lead to quantifiable business benefits. Often tied to a “quick wins” release strategy, benefits include more incremental change that can be more easily absorbed, reduced risk due to a more contained impact area, and the ability to gain experience quickly as the organization adapts to change, which makes subsequent implementations easier. The drawbacks are a more complicated shut-off procedure because some legacy business processes are eliminated while others remain, the requirement for more throw-away work to bridge the old systems and new, and the need to support parallel systems and processes for an extended period of time.

• Location by Location. This model takes advantage of characteristics that enable capability deployment that is reasonably isolated and has minimal collateral impact. Energy and resources are focused on delivering broad-based impact in a narrow space. Distractions are minimized with this model because new capabilities are implemented throughout a single business unit. A major drawback is that the development effort is not phased in this model. The entire new environment must be designed, built, tested, and deployed. This approach drives longer development cycles, more complex and rigorous testing processes, and creates significant execution risks. In addition, dual environments need to be maintained, increasing training and support costs.

• Combination. Combination strategies are frequently used because they enable organizations to mix and match various approaches into an overall solution and benefit case that meets their needs. The benefits are determined by the options selected (how many locations at once, which cluster of functions first, etc.). Typically, a combination model is more costly than any of the pure approaches noted above and often results in a lengthier implementation timeline.

Partnering StrategyChoosing the right partners is critical when pursuing a value-driven innovation agenda. Partners should have a stake in the success of the program and the right combination of flexibility, tolerance for risk, and innovation:

• Technology Partners. Technology partners must be able to develop new and innovative hardware and software solutions that deliver the desired benefits.

• Implementation Partners. Choosing the right implementation partner means carefully matching an enterprise’s innovation agenda with the assets, capabilities, experience, and leadership that a consultant can provide. Microsoft is collaborating with several systems integrators to deliver the programs described in this white paper.

• Business Partners. In today’s business environment, business partnerships play an increasingly important role in the life sciences industry. Partnerships must be built on a shared vision for the use of innovation and a value proposition that drives benefit for all parties.


Appendix C: Key Technical Contacts

For more information on Microsoft’s Digital Pharma initiative, please contact your local Microsoft representative. Information can also be found on the Web at:

http://www.microsoft.com/lifesciences

http://www.microsoft.com/architecture

http://www.microsoft.com/technet/security/default.mspx

http://www.microsoft.com/resources/practices/allreleases.aspx


m

www.microsoft.com/lifesciences

Microsoft CorporationOne Microsoft WayRedmond, WA 98052-6399800-426-9400

0605 Part No. 098-103132

C MICROSOFT DIGITAL PHARMA WHITE PAPER

microsoft digital pharma - idc-online · microsoft digital pharma architecture white paper 5....

Documents