LSIA-The Benefits of a Life Sciences Industry Architecture ... · The Life Sciences Industry Architecture (LSIA) team believes there is a comparable process that could be followed

DRAFT – FOR PUBLIC COMMENT

Page 1 of 23

The Benefits of a Life Sciences Industry Architecture Initial Report from the CDISC Life Sciences Industry Architecture Team Spring 2007 Version 1.0


Page 2 of 23

Executive Summary Life sciences organizations no longer tightly couple all dimensions of the drug development endeavor within the boundaries of a single corporation’s research labs. As the task of drug development has become more and more complicated and the pressure to innovate with speed and reduced cost continues to increase, we find alliances, partnerships, regulatory oversight, and outsourcing driving our industry. Corporations need to be dynamically reconfigurable, and are therefore seeking better ways to leverage the availability of new information technologies and standards to support these needs. However, there are many choices, and each possible path is expensive to follow. An instructive early parallel was the expansion of the railroad - a fast, economical and effective means of sending products cross-country. Imagine the chaos and wasted time if a train starting out in New York had to be unloaded in St. Louis because the railroad tracks did not line up with the train’s wheels. Well into the 19th century the U.S. still did not have one "standard" railroad gauge, and the major problem was interoperability. If you could work out both a standard gauge for cars to interoperate between different railroads and a business model that would allow you to ship freight from one railroad line to another without having to take the freight out of the car owned by Railroad X and put it into a car owned by Railroad Y – you could then have an actual network as opposed to a conglomeration of vaguely interconnected subsystems. Thus a “railroad architecture” was created, which specified – in an evolving manner – a set of rules of the road (e.g., standard gauge for cars, standard time zones to coordinate shipping) for how goods could be moved across multiple expanding and changing railroad lines. The Life Sciences Industry Architecture (LSIA) team believes there is a comparable process that could be followed to dramatically simplify the environment for collaboration within and across organizations. Data standards are a cornerstone of what is needed to reach a solution, but are not sufficient in and of themselves. In addition to data standards, commonality across industry constituents is needed regarding how the various standards are to be implemented; that is, we need a standard architecture. The LSIA team recommends that the industry pursue a standard industry-level architecture with the goal of establishing a common framework for interoperability across organizations, systems, business processes, and people. This architecture would define abstract system requirements and associated business rules and principles, but would not be so fine-grained as to prescribe particular implementations. By defining a substrate of expected functionality for individual applications and services that play particular roles, a commonality is established that allows individual organizations to choose which application, provider, or service they wish to use for which role without placing constraints on the organization’s IT strategy and infrastructure. The commonality makes the process of technical integration dramatically easier, but standards development organizations must work together in establishing the role of various standards in a broader and more comprehensive industry context. In this document, we present a survey of the opportunity around architecture. We describe the business benefits in productivity, collaboration, agility, and compliance associated with its adoption, and we articulate what actions we believe are required to achieve this goal. Specifically, we request information technology and standards leaders sponsor a summit across the various standards efforts with the goal of forming and resourcing an industry-level architecture practice. This coordinated effort will serve to collaboratively develop the design and corresponding governance structure that will shape a stronger and more interoperable life sciences ecosystem.


Page 3 of 23

Table of Contents

EXECUTIVE SUMMARY .......................................................................................................................... 2 TABLE OF CONTENTS ............................................................................................................................. 3 ABOUT THE LIFE SCIENCES INDUSTRY ARCHITECTURE TEAM ............................................. 4 INTRODUCTION ........................................................................................................................................ 5

INDUSTRY CONTEXT ................................................................................................................................... 5 THE STATE OF STANDARDS ......................................................................................................................... 5 THE CONCEPT OF ARCHITECTURE ............................................................................................................... 8

DEVELOPING AN ARCHITECTURAL PRACTICE .......................................................................... 12 STRATEGIC, VALUE-BASED ARCHITECTURE .............................................................................................. 12 ARCHITECTURE PRACTICE......................................................................................................................... 13

VALUE PROPOSITION ........................................................................................................................... 15 PRODUCTIVITY .......................................................................................................................................... 15 COMPLIANCE ............................................................................................................................................. 16 AGILITY .................................................................................................................................................... 16 COLLABORATION ...................................................................................................................................... 16

THE PATH FORWARD ........................................................................................................................... 17 APPENDIX: LSIA PARTICIPANTS ....................................................................................................... 18 APPENDIX: PROJECT PRINCIPLES ................................................................................................... 19

BUSINESS PRINCIPLES ............................................................................................................................... 19 FUNCTIONAL PRINCIPLES .......................................................................................................................... 19 TECHNICAL PRINCIPLES ............................................................................................................................ 20

APPENDIX: PARTIAL STANDARDS INVENTORY ........................................................................... 21


Page 4 of 23

About the Life Sciences Industry Architecture Team The Life Sciences Industry Architecture team is a group of IT architects and business end-users actively evaluating the feasibility and corresponding business value of developing an industry-wide technology strategy capable of functioning across companies and technology platforms. Jointly sponsored by representatives of CDISC and PhRMA, the team’s initial charter is the development and delivery of this document. The LSIA team grew out of a grass-roots effort to improve how life sciences organizations introduce new technology into their operational environments. Through a series of industry discussion forums, conference presentations, and publications, it was determined that a focused group of representatives from pharmaceutical companies as well as platform technology providers needed to come together to develop a recommended course of action. In 2006, CDISC – in conjunction with representatives from PhRMA – agreed to jointly sponsor a team to evaluate the opportunity. LSIA team participants are listed in the appendix.

Figure 1. Historical timeline

This document represents the first deliverable from this effort. The objectives behind this document are to:

• provide a high-level understanding of the idea behind an industry architecture

• describe some of expected business value associated with developing and implementing this architecture

• recommend next steps in pursuing this idea

Said another way, this document does not attempt to describe the actual architecture design; rather, it describes why a design is needed and how one might be pursued. Though this content has been reviewed by many business experts, architects, and vendors across our industry, the hope is that the document will serve to ignite further discussions and feedback on how to improve information technology development, implementation, and utilization within life sciences. The primary audience for this document is senior information technology leaders responsible for overseeing technology investments within life sciences organizations, especially those related to technology standards and enterprise architecture. A secondary audience consists of the leaders of life sciences standards development initiatives. For both audiences, our goal is to request support for a cross-standards initiative focusing on “how” technology standards should be implemented, as opposed to just the details of specific data standards and models.


Page 5 of 23

Introduction Industry Context Collaboration has become a mainstream and critical dimension of drug development. We no longer tightly couple all dimensions of the drug development endeavor within the boundaries of a single corporation’s research labs. Instead, alliances, partnerships, regulatory oversight, outsourcing and outpartnering dominate our industry. Our corporations have become more and more unbundled and need to be dynamically reconfigurable. On top of this, the task of drug development has become more and more complicated and the pressure to innovate with speed and reduced cost continues to increase. In recent years the life sciences industry has witnessed, and in some cases created, an explosion of available information technologies and standards. These offer tremendous potential for improvement in areas where the industry needs and desires it: public safety monitoring, organizational productivity, regulatory compliance, and process quality to name a few. All types of life sciences organizations – biotechnology companies, pharmaceutical companies, and health authorities, but also the myriad of related supporting vendors and academic research centers – are struggling with how best to take advantage of new technologies and standards. The landscape is incredibly complex, and getting more so every day. There are many choices, and each possible path is expensive to follow; there is presently no clear pathway to success and longevity in adoption. Despite the complexity, the utility of standards is widely recognized, and the FDA’s Critical Path initiative recognizes the need for increased attention among life sciences constituents in addressing the challenges of interoperability.

The State of Standards The data standards now being used to exchange clinical data between sponsors, CRO’s, regulators, and investigators have made good progress towards simplification. But issues continue to arise in understanding which standard(s) to use in a particular situation and how to weave these standards into a coherent application fabric that addresses real business needs. Given its necessary focus on the unique and novel, the research aspect of the pharmaceutical enterprise has served as a barrier to standardization within the industry. As an example, unlike other industries (e.g., manufacturing, telecommunications, finance) we do not have agreement on the basis for establishing and managing partner interactions:

1) Standards for data integration (master data, schemas)

2) Standards for application integration (security, compression, object ids, transmission protocol)

3) Rationalized set of common business processes (e.g. clinical transaction set)

We also lack a governance structure to guide and influence across all 3 of the above. Currently available standards are likely to have far greater value when used in conjunction with a pluggable architectural framework that would simplify integration and orchestration, while retaining the flexibility to meet the challenges of new technologies and use cases as they arise.


Page 6 of 23

An instructive early parallel was the expansion of the railroad - a fast, economical and effective means of sending products cross-country. Imagine the chaos and wasted time if a train starting out in New York had to be unloaded in St. Louis because the railroad tracks did not line up with the train’s wheels. Well into the 19th century the U.S. still did not have one "standard" railroad gauge. At the time of the Civil War, even though nearly all of the Confederacy's railroad equipment had come from the North or from Britain, 113 different railroad companies in the Confederacy operated on three different gauges of track. The major problem was interoperability. Railroads, in attempting to build more efficient networks, found that the 19th century-equivalent of the gateway – the transfer point where you had to shift freight from one gauge to another – meant that traffic was slowed. If you could work out both a standard gauge for cars to interoperate between different railroads and a business model that would allow you to ship freight from one railroad line to another without having to take the freight out of the car owned by Railroad X and put it into a car owned by Railroad Y – you could then have an actual network as opposed to a conglomeration of vaguely interconnected subsystems. Hence standard gauge emerged as a clear concept. In addition, the nation adopted standard time zones to allow the coordination of train schedules, and the Interstate Commerce Commission was created, not only as a source of standard tariffs for railroad services, but also as an umpire for allowing standardization of various components of railroad technology as they became mature. The ICC stayed out of the actual engineering of things, only getting involved with technical standards that actually affected the abilities of railroads to interoperate. Thus a “railroad architecture” was created, which specified – in an evolving manner – a set of rules of the road for how goods could be moved across multiple expanding and changing railroad lines using relatively interchangeable equipment. In life sciences, technology companies and service providers focusing on life sciences are required to develop and manage extensive technical implementation factors rather than focusing on innovation. A lack of standards also makes it difficult for startups and mid-size companies to enter in this space to develop and deliver innovative products. The following figure illustrates the relationships between a partial list of standards initiatives and other constituents in the industry.


Page 7 of 23

Figure 2. Partial map of existing standards constituents

Practically speaking, this network of standards results in implementations that are costly and inconsistent. Consider for a moment 5 silos of business process activities within the research and development space, as illustrated in the following figure. Within each silo, a series of activities (circles) are linked together in a flow of activities (arrows connecting the circles). Within each circle, systems and processes that rely on standards are used to successfully complete the activity. The color of each circle illustrates a particular standard in use; for example, the green standard is used in 4 of the 5 silos, whereas the red standard is only used in 3 of the silos.


Page 8 of 23

Figure 3. Current standards implementations

Problems with the operational environment today include the following:

1. The specific flow of activities and standards within a silo is constructed differently and ad hoc across different organizations. Said another way, there is no way of knowing what an organization’s flow of circles looks like.

2. A given standard (e.g., a colored circle) is not used consistently within the flow of a silo’s events; in other words, it may be orange within one company or therapeutic area but blue in another.

3. A given standard is not linked across the 5 organizational silos, so there is no synergy of scale.

The Concept of Architecture IEEE defines architecture as “the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” In practice, there are two primary subcomponents of architecture-related work: design and governance. Architecture design provides the long-term “blueprint”, illustrating the components, their respective boundaries, and their interrelationships. Governance describes the process and principles by which those designs evolve over time and those corresponding decisions are made. Though there are many different types of architectures at differing levels of detail (e.g., application, network), the concept of architecture discussed here is at a fairly high level of abstraction (e.g., enterprise architecture) because it relates to interoperability across organizations and systems. The following figure illustrates one potential view of architectural boundaries that are common across life sciences organizations today. The diagram represents solutions as horizontal boxes whose organizational scope and sophistication increases from the bottom to the top. Capabilities applicable at multiple scales are shown to the left.


Page 9 of 23

Figure 4. Example architectural framework

As described earlier, there are a plethora of standards-related projects and initiatives already underway in life sciences today. Looking across these initiatives, it is possible to map the intended scope of each effort to its corresponding architectural domains. The following figure is a partial mapping of current standards work to the architectural framework.

Figure 5. Example framework with partial standards overlay


Page 10 of 23

In considering the overlay of standards to the architectural framework, a few conclusions can be drawn:

1. The overwhelming focus of existing standards efforts are confined to knowledge representations.

2. Among the knowledge representations standards, different approaches to a standard can be found – some standards are focusing on syntax, some are focusing on ontology, and some are offering a hybrid of the two approaches. This diversity makes broader adoption of any standard in different scenarios very difficult.

3. No single standards effort currently spans the majority of architectural domains; in other words, there is no common way of unifying the architecture.

4. Higher-order architectural domains (e.g., workflow), which typically equate to process innovation/automation and correspondingly larger returns on investment, are not strongly represented in current industry investments in standards.

5. In considering the diversity of industry-related data and technology standards, each standard should address a particular purpose within a particular box, and clearly articulate how it interacts with other neighboring boxes. It is probable that some existing standards efforts are duplicating efforts because clear guidance has not been established across initiatives.

One could draw an analogy to a paper mail process. To date, we have focused heavily on the contents of a letter – how is the letter formatted, what size paper, and in what language we wish to communicate.

Figure 6. Mail delivery analogy

A more architecture-centric approach would assume those agreements continue, but would ask other questions as well:

1. What does the envelope and mailbox look like?

2. How are the arrows defined and communicated?

3. What is the mail carrier – a pigeon?

4. How are mail pickups and deliveries handled and ensured?

Note that we don’t actually have to decide between pigeons, horses, or courier jets. We just need to establish functional attributes that any solution must follow. Some functional attributes might be required (e.g., envelopes must contain postage) while others are allowed or even desired (e.g., envelopes can have different sizes and weights). Choice should be based a balance of cost and benefit, and may vary case to case (e.g., this letter absolutely, positively has to be there overnight). By having these agreements in place, we have a much greater ability to


Page 11 of 23

introduce flexibility and change; for example, I could replace my mailbox with a slot in the door or adopt a third-party, hosted solution (P.O. Box). In summary, it is agreement on the interfaces between the architectural framework boxes that facilitates integration and moves us toward interoperability, and such agreement at a functional level would be a considerable step forward. Ideally, the interaction between boxes should be neutral to the choice of implementation in other boxes. The agreements stop short of full technical specification of each detail, but instead provide a reference for expected capabilities of systems that play particular roles in the architecture. The industry should collaborate upon a functional architecture to address the issues described above. While individual organizations will have their own architectures – in some aspects well-designed, in others very ad hoc – the true power of the architecture is only realized when it is common to all stakeholders. It makes much less sense to work without collaboration. Quick on the heels of considering a collaborative effort is the need for a governed organization to oversee the effort. Accordingly, an industry-level Architecture Practice is needed to do this work. This will require significant commitment and resources on the part of the industry, especially on the part of existing standards initiatives. It will mean redirecting experienced IT architects and business process experts from creating internal harmonization, and instead focusing these resources on developing synergies across business processes, standards specifications, and corporate boundaries. However this is both more powerful and much cheaper to do collaboratively than to do individually.


Page 12 of 23

Developing an Architectural Practice Strategic, Value-based Architecture Architecture is fundamentally about aligning business objectives to technology capabilities. This requires that a methodology or framework be put in place to govern the logical progression of the alignment work. There are many architecture-related methodologies available across the IT community ranging in scope and focus1. Despite the proliferation of different approaches, Forrester reports that over half of organizations with enterprise architecture frameworks in place rely on custom approaches that are matched to the specific needs of the organization. Since the intended audience for this initiative’s work includes both technical and non-technical industry professionals, it is important to use an approach that is simple to understand and easily communicated to broad audiences. Accordingly, a 4-tier methodology was adopted as a guiding structure. This methodology, based upon a successful practice within one constituent pharmaceutical company, serves as our guide to the exploration of potential industry architecture. The methodology, which proceeds in a top down fashion, is depicted in the following figure.

Figure 7. Methodology

The tiers of the methodology are defined as follows:

• Objective – defining the value in pursuing this initiative from a business perspective

• Vision – defining the desired end business state that achieves the objective

• Architecture – defining and managing the corresponding components needed to deliver that vision

• Project – defining and managing the portfolio of projects that, over time, will deliver those components

The first two tiers of this methodology provide the strategic business context for the architecture. These two tiers are critically important in that they establish consensus for the scope of the technology under consideration and thereby help prioritize areas of architectural focus.

1 For example: Zachman’s Enterprise Architecture Framework, The Open Group Architecture Framework (TOGAF), Gartner’s Architecture Framework, IEEE 1471-2000, SEI’s Views, and others.


Page 13 of 23

The last two tiers of this methodology describe the technical underpinning required to achieve interoperability. As organizations have many different architectures in place today, any methodology must differentiate between two different architectural dimensions: what time frame is being examined (e.g., are we considering an architecture for this year or five years from now), and what is the state of readiness necessary (e.g., whether the architecture is an idea, a planned piece of work, or already implemented). The following figure illustrates the relationship between these two dimensions.

Figure 8: Architecture priorities

Accordingly, this methodology enumerates two different types of architectural blueprints:

• Reference architecture – the long-term conceptual framework that primarily serves as a guide, since it is conceptual in nature it may never be fully implemented.

• Target architecture – a specific, achievable instantiation of the architecture that is assumed to apply to only part of the overall reference architecture. The target architecture is evolved over time towards the reference architecture design.

Any industry-wide architecture specification should not be viewed as a constraint on information technology vendors or implementers. An architecture at this scale would only be feasible and practical if defined at a level of granularity that provides significant flexibility in the design and implementation of adherent solutions. An industry architecture should be seen as an enabler of solutions, establishing a common set of expectations by which any solution – regardless of the attributes of its specific technical implementation – can reliably communicate and function.

Architecture Practice Developing this architecture will require the input from many vendors, architects, and business experts across our industry. This broad base is required not only to validate the business needs being addressed but also to assure that the technical requirements can be satisfied in a reasonable timeframe and fit with current best technical practices at a cost that is practical. A common methodology to assess software requirements is the development of use cases. For purposes of this document, a use case is a specific business need described in a hypothetical but relevant business scenario. A use case includes information such as the business process being


Page 14 of 23

addressed, the roles of people involved in the process, the way the process is currently performed, and a future state delineating a new way in which the process could be accomplished. Use case based approaches have the advantage of elucidating complete business processes in formats that allow ready communication between stakeholders with varied backgrounds and areas of expertise. Use cases have proven to be a powerful and reliable way of articulating software requirements, and they are one way of ensuring that architecture is grounded in what we do rather than theoretical ideas. They serve to guide and validate the architecture. As these use cases are created and refined, we expect the architecture will evolve and a number of best practice patterns will be created to assist organizations in putting solutions in place. These use cases and patterns will form the basis of the “living architecture” both in identifying areas needing improvement and also assisting the promulgation of experience gained by fielding systems. For reasons of simplicity, business priority, and standards diversity, the uses cases we have used to explore this topic are currently focused on research and development areas of the industry. The longer-term goal of an industry architecture should encompass other areas of business processes as well (e.g., sales, marketing, manufacturing, supply chain, broader healthcare). We have adopted a detailed set of principles (available in the appendix) to ensure the viability of the architectural deliverables. These principles are designed to ensure vendor neutrality while providing opportunities for vendors to innovate. The architecture must be extensible in a principled manner to allow the standards to remain relevant in the face of (inevitable) changes in technology and business processes.


Page 15 of 23

Value Proposition The proposition that systems playing a role within the pharmaceutical industry’s practice meet a collection of industry-specified requirements in its functional capabilities is obviously ambitious, but would be a huge stride forward. There are several dimensions of value associated with providing an industry-level architecture. As with any proposal involving envisioned change, especially one on this scale, that value is difficult to quantify. However, it is possible to characterize the nature of the change and identify how organizations and the people within them would operate differently in the presence of a collective architectural framework. In this section we characterize four facets where we anticipate significant payoff based on the use cases we have evaluated. These are, briefly:

• Productivity: increased organizational or individual effectiveness

• Compliance: demonstrating that business processes and supporting systems meet applicable regulations

• Agility: the ability of an organization to create and adapt to new business processes and conditions

• Collaboration: increased effectiveness specifically in the interactions between organizations and individual contributors

These areas are of course inter-related and some benefits do not fall cleanly into one category or another.

Productivity The most direct productivity gains from an industry architecture would occur in the realm of organizational effectiveness in evaluating and adopting new tools. When both enterprises and software vendors adopt an industry architecture, the complexity of procuring tools and implementing new solutions drops dramatically. With an industry architecture, vendor products compete less on “technology fit”, but instead on "business fit". Tools will still have to 'fit' from an IT standpoint, but how they fit is sufficiently common that any tool that doesn't fit will not be viable in the marketplace. It should be clearly stated that "fitting in" here is most often not as straightforward as a simple add or replace of one software package for another. Industry architecture will provide a 'functional' architecture, describing in the abstract the expected behaviors of a package serving a particular role in the enterprise. Those behaviors will often not be as explicit as an outright expression of interface detail, but rather an expression of capabilities that the package must make available. In other words, we will have 'pluggable architecture', but not always 'plug-n-play' architecture in which all components are guaranteed to work together in all cases due to tightly constrained technical specifications. This little bit of “play” in the architecture is a good thing … it is what allows evolution to better solutions. A completely constrained specification in all detail can severely constrain innovation.


Page 16 of 23

Compliance In trying to adapt and innovate there are always issues of assuring system compliance with applicable regulations. A system with greater innovation and hence greater novelty necessarily entails higher compliance costs. Not only must each novel aspect of the system be shown to be compliant, but the complete system must also show its adherence to the applicable requirements. This additional burden of cost raises the investment hurdle for any new process, with the cost at best proportional to the novelty of the system being composed. A system assembled from proven components that have been previously integrated successfully necessarily reduces compliance risk and simplifies testing and validation procedures. But more importantly, adherence to an industry architecture should serve to reduce variance and therefore risk, two principle drivers behind compliance. Said another way, it is easier to test and manage compliance against a published industry-wide benchmark specification than against a purely individual system specification.

Agility In most organizations today, business processes supported by one or more information technologies can be slow to adapt to change. Often putting the technology in place within the business involves custom integration or outright custom development of software code that executes business logic specific to the business process. Making a change to that configuration can be very expensive, carrying with it a complex process of development and validation involving both IT and the business. This expense in turn causes more expense in terms of oversight – trying to decide in which parts of the business it makes sense to incur the expense of change, and in which parts to live with processes that are adequate but not optimal. Articulation of industry functional capabilities and expectations via a shared architecture encourages a much more agile way of organizing work. Increasingly, we can express a business process at a higher level as data (rather than software code) – data that software can then use to execute and automate workflow. This way of documenting what happens is both simpler and more transparent from the perspective of a business user, and also easier to achieve and validate from the perspective of IT. The organization is much more able to institute changes in business processes since those changes produce less of an impact to operational environments.

Collaboration collaborare – Latin: to labor together. This simple definition effectively describes what has become a mainstream and critical dimension of drug development. We no longer tightly couple all dimensions of the drug development endeavor within the boundaries of a single corporation’s research labs. Instead, alliances, partnerships, regulatory oversight, and outsourcing dominate our industry. Our corporations have become more and more unbundled. On top of this, the task of drug development has become more and more complicated and the pressure to innovate with speed and reduced cost continues to increase. Creating a pluggable industry architecture represents a powerful method for enabling innovation and collaboration. Since the existence and functionality of these interfaces are well defined and extensible, business and technical solution providers have well-documented and tractable points for innovation. No longer will it be necessary to solve the complete problem to become part of the solution. Robustly addressing a single aspect of the problem will suffice.


Page 17 of 23

The Path Forward The value of creating and implementing an industry-class architecture will not be accrued quickly, and it will not be accomplished with the industry’s current approach. In order to obtain the benefits of a more standardized and interoperable ecosystem, industry constituents – organizations, standards bodies, and individual contributors – must be willing to move beyond local priorities and participate in a broader business improvement effort.

Call for a summit. We ask leaders of pharmaceutical and information technology firms to unite in sponsorship of a summit on the topic of industry architecture. Attendance at this summit should be open to all interested industry constituents, and priority attendance should be established for leaders of industry standards initiatives and coordinating bodies (e.g., CDISC, PhRMA, HL7, CRIX). The goal of this summit is an open exchange of ideas on the topic of industry architecture, and a shared commitment to move forward in addressing an architecture focus across industry organizations. Provision an architecture practice. Much like the progress to date in the development of data standards, progress towards an industry architecture will only happen when knowledgeable contributors come together and begin the hard work of creation. The architecture practice would have 2 primary functions: design of the architecture (e.g., principles, specifications, reference and target designs), and governance of the architecture (e.g., the evolution of the specifications, the management of the process). The practice will need to first enumerate the critical use cases that will serve as the basis for design. The architectural framework defined earlier (e.g., the boxes) will need to be evaluated for completeness and accuracy, and functional definitions of the various components will need to be established. There will need to be a more rigorous review and mapping of existing standards, especially as they relate to the framework. Use cases will be used to elucidate the various dimensions of reference and target architectures as per the methodology presented earlier.

Given the capabilities of modern information technology, the challenges are no longer technical (if indeed they ever were). We recognize that what we are describing is substantial, but we believe the opportunity for the industry is far too significant to ignore. We stand at the precipice of a new age of information management and business productivity, and it is incumbent on each of us – business leader or IT architect, research organization or technology vendor – to help shape a stronger life sciences ecosystem. We invite your feedback and participation in an ongoing dialogue around the ideas represented in this document:

Email: Greg Anglin, [email protected] Jason Burke, [email protected] Richard Ferrante, [email protected]

Web: http://groups.google.com/group/lsia-whitepaper-review


Page 18 of 23

Appendix: LSIA Participants

Sponsors: CDISC, PhRMA IMPACC Team Members Jim Ahman, Sanofi-Aventis Greg Anglin, Eli Lilly (co-chair) Jason Burke, SAS (co-chair) Barry Crist, Eli Lilly Susan Duke, GSK Richard Ferrante, RDF Software Group (co-chair) Terry Hardin, IBM Robert Hayden, Hewlett-Packard Don Rosen, Don Rosen Consulting


Page 19 of 23

Appendix: Project Principles Any architectural effort needs to operate under a set of principles that establish the scope and nature of the work being performed. As such, we have adopted the following business, functional, and technical principles that have been established for this initiative.

Business Principles 1. The scope of interest for this initiative covers biomedical research and its various touch

points with providers, payers, and all life sciences constituents. Though many of the use cases have intentionally focused on clinical trials, the architecture is intended to cover much broader areas of the life sciences business.

2. The life sciences industry has not historically placed much (if any) emphasis on standards as they relate to architecture. Accordingly, in order to help move this concept forward, the project will need to focus on why architecture matters from a business point of view. This document is intended to provide that justification.

3. Given efforts within the information technology and life sciences communities that are already developing technology-related standards, the focus of this effort will be around how to exploit these existing efforts. Though there will undoubtedly be new standards-related components that will be required in order to support the architecture, the intention will be to leverage existing teams and their deliverables as appropriate.

4. The output of this initiative is not designed to be a static design for technology solutions. Rather, this initiative will define a “living architecture” – one that is actively governed and versioned over time to reflect changes in the industry, learnings from target architecture implementations, and advancements in information technology.

5. The intention of this effort is not to develop open source software. Though some software code may be developed in the course of the initiative for various purposes (e.g., demonstrations, validation of concepts), the work will not include implementation-specific deliverables (should we keep this? Everything else is framework level?).

Functional Principles 1. The design of the architecture will be driven by functional requirements as elucidated in

use cases. As described above, use cases provide a good mechanism for ensuring the accuracy and applicability of functional requirements.

2. The initiative will address at least 3 different functional dimensions of an architecture:

a. Architectural principles – the rules and guidelines by which the architecture should be instantiated. To use an analogy, architectural principles are equivalent to principles you might see in the design of automobiles – it should carry 2 or more passengers, it should provide strong protection in the event of accidents, etc. If these principles are not followed, the resulting product no longer really looks and functions like an automobile (e.g., a motorcycle).

b. Foundational styles – the generally supported approaches to addressing particular functional requirements. In the automobile example above, a foundational style might represent the type of automobile – sedan, coupe, minivan, etc. The design follows a style intended to maximize certain function aspects: carrying capacity (i.e., minivans), sporty visual appeal (i.e., coupes), etc.

c. Patterns – designs that are functionally consistent across differing use cases and functional requirements. These patterns help ensure the consistency,


Page 20 of 23

extensibility, and simplicity of specific implementations of the architecture. From our automobile example, patterns might be equivalent to the inclusion of a steering wheel, a gearshift, or other constructs that are found in multiple automobiles, and therefore represent opportunities for standardization (e.g., steering wheels are typically round and turn).

Technical Principles 1. This initiative will take a “top down” approach to architecture. Following the

methodology defined above, a top-down approach starts at a conceptual design level of detail and works successively towards lower levels of detail. Architecture practices often take the form of a “bottom-up” approach, focusing design priorities on software code module designs, invocation methods, and deployment architectures. Since the type of architecture being explored in this initiative is intended to cover a broad and expanding set of enterprise and application architectures, use of a bottom-up approach is not practical.

2. As per the business principles above, the intention of this effort is to work across multiple standards efforts to drive clarity and consistency in how standards are deployed and used. With good reason, a tremendous amount of work has been expended to date on the development and adoption of standards from CDISC and HL7. Though this effort will rely heavily on those standards, the scope of technical standards explored and used will not be limited to those organizations. It is anticipated that standards from W3C, SAFE, WS-I, IETF, and other organizations will provide foundational aspects to this architecture.

3. The architecture will be software, hardware, language, and otherwise vendor-agnostic. The purpose of this effort is not to endorse any particular implementation of an interoperable architecture; rather, the purpose is to provide a mechanism by which business processes and information can interoperate across all technology platforms. The degree to which any particular software application, operating system, software development language, or vendor platform supports the implementation of this architecture is a commercial decision for the vendor.

4. The architecture development will use a component-driven / pluggable design principle. There is a strong focus in this initiative on interoperability, and one crucial aspect of interoperability is ease in establishing an interoperable environment between two or more systems (and oftentimes organizations). By encapsulating design into pluggable components, the architecture should be easier to accommodate in design activities, faster to implement in new solutions, and simpler to manage in production environments.

5. Data integration will be a central component of the architectural effort, but a deeper level of integration will be sought beyond simple file or message exchange. Data integration in this context refers to the overall process of integration, not just the data structures (“payloads”). Said another way, the architecture will apply and improve payload standards through broader technical definitions that define “how” to integrate, not just “what” to integrate.

6. To the extent possible, this architecture will be self-describing. In other words, a user of the architecture (i.e., a human or a software application) should be able to exploit built-in constructs for discovering the specifics of an architectural implementation – what standards are supported, how to interact with the system, etc. Reliance on written documentation for implementation issues should be minimized, as systems should be able to openly communicate how they can and do function within the architecture.


Page 21 of 23

Appendix: Partial Standards Inventory Standard Description BRIDG The Biomedical Research Integrated Domain Group (BRIDG) Model is a domain analysis

model representing protocol-driven biomedical/clinical research. It was developed to provide an overarching model that could readily be understood by domain experts and would provide the basis for harmonization among standards within the clinical research domain and between biomedical/clinical research and healthcare. http://www.bridgproject.org/

caBig The National Cancer Institute ( NCI) has launched the caBIG™ ( cancer Biomedical Informatics Grid™) initiative to accelerate research discoveries and improve patient outcomes by linking researchers, physicians, and patients throughout the cancer community. caBIG™ serves as the cornerstone of NCI’s biomedical informatics efforts to transform cancer research into a more collaborative, efficient, and effective endeavor. http://cabig.nci.nih.gov/

CaDSR The caDSR is a database and tool set that the NCI and its partners use to create, edit and deploy the CDEs. The NCI, together with partners in the research community, develops common data elements (CDEs) that are used as metadata descriptors for NCI-sponsored research and for the caCORE applications. The caCORE objects are represented by UML Models. The UML Model is used to facilitate a semi-automated load from caCORE UML into ISO/IEC 11179 Administered Components. This is discussed in more detail in the Software Developers Toolkit (SDK). http://ncicb.nci.nih.gov/NCICB/infrastructure/cacore_overview/cadsr

CDISC define.xml

ecifies the standard for providing Case Report Tabulations Data Definitions in an XML format for submission to regulatory authorities (e.g., FDA). The XML schema used to define the expected structure for these XML files is based on an extension to the CDISC Operational Data Model (ODM). http://www.cdisc.org/models/def/v1.0/index.html

CDISC Lab The mission of the Lab Team is to: • Define requirements for improving operational laboratory data interchange. • Develop a standard content model for the acquisition and interchange of clinical trials laboratory data • Test the model with complex real laboratory data to assure its functionality • Explore other opportunities to improve laboratory data processing with standards http://www.cdisc.org/models/lab/v1.0.1/index.html

CDISC ODM The Operational Data Model (ODM) provides a format for representing the study metadata, study data and administrative data associated with a clinical trial. It represents only the data that would be transferred among different software systems during a trial, or archived after a trial. It need not represent any information internal to a single system, for example, information about how the data would be stored in a particular database. http://www.cdisc.org/models/odm/v1.3/index.html

CDISC Terminology

http://www.cdisc.org/glossary/CDISCGlossaryV5.pdf


Page 22 of 23

CRIX Firebird

he Clinical Research Information Exchange (CRIX) is a collaborative effort among government, the bio-pharmaceutical industry and academia to implement a common, secure standards-based electronic infrastructure to support the sharing of clinical research data for faster, more efficient development of new drugs. The CRIX Steering Committee, formed in April 2005, is charged with guiding the CRIX effort through its initial start-up and to document and propose a permanent operational management and governance structure for CRIX. The Committee is responsible for identifying partners, establishing priorities, and providing guidance in the overall development and deployment of CRIX service modules. To date, the Committee has developed the CRIX Business Plan and business strategy for the first CRIX module, FIREBIRD. The next step is to align and confirm industry partnership in the formation of CRIX as a non-profit business entity and transition FIREBIRD to CRIX for government and commercial use. http://crix.nci.nih.gov/

eCTD The eCTD is defined as an interface for industry to agency transfer of regulatory information while at the same time taking into consideration the facilitation of the creation, review, lifecycle management and archival of the electronic submission http://estri.ich.org/eCTD/

HL7 EECG http://www.hl7.org/Library/standards.cfm HL7 Lab Laboratory Automation Equipment status, specimen status, equipment inventory,

equipment comment, equipment response, equipment notification, equipment test code settings, equipment logs/service.

HL7 RIM RIM Version 3 uses an object-oriented development methodology and a Reference Information Model (RIM) to create messages http://www.hl7.org/Library/standards.cfm

Janus JANUS is intended to serve as the core date repository for clinical trial data (CDISC SDTM) and for pharmacology/toxicology trial data (CDISC SEND). http://gforge.nci.nih.gov/projects/janus/

MedDRA MedDRA - the Medical Dictionary for Regulatory Activities - is a pragmatic, medically valid terminology with an emphasis on ease of use for data entry, retrieval, analysis, and display, as well as a suitable balance between sensitivity and specificity within the regulatory environment. It was developed by the International Conference on Harmonisation (ICH) and is owned by the International Federation of Pharmaceutical Manufacturers and Associations (IFPMA) acting as trustee for the ICH steering committee. http://www.meddramsso.com/MSSOWeb/index.htm

SAFE SAFE delivers unique electronic identity credentials for legally enforceable & regulatory compliant digital signatures across the global bio-pharmaceutical environment. SAFE is intended for business-to-business, and business to regulator transactions. http://www.safe-biopharma.org

Snomed SNOMED Clinical Terms® (SNOMED CT®), is the universal health care terminology that makes health care knowledge usable and accessible wherever and whenever it is needed. This strong foundation is leading the health care industry in building a seamless infrastructure of worldwide care while integrating an overwhelming amount of clinical data. http://www.snomed.org/


Page 23 of 23

SPL The Structured Product Labeling (SPL) is a document markup standard approved by Health Level Seven (HL7) and adopted by FDA as a mechanism for exchanging medication information. http://www.fda.gov/oc/datacouncil/spl.html

Documents

LSIA-The Benefits of a Life Sciences Industry Architecture ... · The Life Sciences Industry Architecture (LSIA) team believes there is a comparable process that could be followed