News

• Analyst Viewpoints
• Awards
• e-newsletters
• Features
• Media Coverage
• Press Center
• Press Releases
• sascom online Magazine

The Era of Architecture

Why all those new software applications won’t deliver what you need

Part 2 of a 3-part series
By Jason Burke

Innovation often occurs at boundaries between existing processes, organizations, information systems and people. Architecture describes technology boundaries and thus provides a crucial blueprint for how to enable business and scientific innovation through software. In our last issue, I made the case that architecture, not just new software applications, offers the key to unlocking the improvements in productivity and science being sought by most life sciences companies today. But how?

You can start by describing the existing barriers to business and scientific innovation that any architecture might need to address. Anyone working in our industry today - whether in discovery, development, sales, marketing, manufacturing or any other function - is faced with trying to work beyond historical boundaries. How do we work more effectively with business partners around the world - some of whom are now intimately involved in our business operations? How do we interpret data coming from other organizations such as labs and academia? Even within a specific job function, we explore the boundaries - how do I reduce the time of one task so I can spend more time in another, higher-value task? The boundaries represented in these challenges include:

• Organizational - working across companies and their respective functions, people, policies, and processes.
• Geographical - working across disparate locations and cultures around the world.
• Software - working across different information systems.
• Technology infrastructure - working across different networks and security models.
• Scientific - working across different research designs and models.

We often look to standards to help us work across these boundaries. For example, by using data standards such as CDISC ODM, data can be shared across organizational and software boundaries. Within our organizations, we often select standard applications to be used for certain functions in an attempt to overcome organizational boundaries between people and business processes.

But each of these approaches has limits; for example, selecting a data standard does not help you overcome technology infrastructure barriers. Though the selection of a specific standard to address a particular barrier is important, the real challenge is creating an architecture that provides a connected fabric of standards addressing the harder problems that single standards cannot solve:

• Information aggregation. Bringing information from different sources, contexts and formats into a new business context is difficult. The work is often manual, involving technical interventions and data manipulations for increasingly larger volumes of information.
• Process alignment. Having a business process execute reliably with different people in different companies is also difficult. Challenges include clarity in the process definition, consistency in the implementation, and visibility into the process status.
• Information interpretation. Knowing the context of data coming from disparate systems and environments is difficult as well. We cannot easily discover the assumptions, conditions, and potential meanings behind information that did not originate from within our own processes.

Architecture provides a framework for tackling these challenges, and a recent example of this type of architecture was presented during the annual conference of the Healthcare Information and Management Systems Society. The conference featured an interoperability showcase with participants from major pharmaceutical companies, healthcare groups, and information technology providers (including SAS). By reaching agreement on an architecture consisting of a variety of accepted standards, the participants were able to demonstrate how electronic patient data can be collected into electronic medical records systems while also being used for clinical research. Because the focus of the effort was around architecture, the showcase was able to demonstrate how to overcome the barriers described above:

• Organizational. Data collected in physician offices can be sent to pharmaceutical firms, contract research organizations and other constituents.
• Geographical. Organizations from around the world can participate.
• Software. The solution can function regardless of which electronic medical record system or electronic data capture systems different organizations use.
• Technology infrastructure. The data can flow across common networks such as the Internet.
• Scientific. Both the physicians as well as the researchers can share a common interpretation of the research model and patient results.

It also addresses the three business challenges above:

• Information aggregation. Data can be used in multiple business contexts - typical patient care as well as medical research.
• Process alignment. The process of collecting data for a patient's medical record can be linked to the process of executing a clinical research protocol.
• Information interpretation. Both the healthcare provider and research sponsor can share a common understanding of the context of the data - when it was collected and under what conditions.

Of course, it will be some time before we see electronic medical records systems widely used for populating pharmaceutical research data repositories. But the point is that the opportunity for innovation is created by exploring the traditional boundaries and understanding what role information technology can play in crossing those boundaries.

A company's use of architecture as an enabler need not be as grandiose as crossing the chasm between healthcare and life sciences. What are the boundaries that you see each day that inhibit information aggregation, process alignment and information interpretation? How can you innovate across those boundaries, and can technology help? If so, is the solution really an application, or do you need an architecture?

Bio: Jason Burke is Americas Director of Life Sciences Strategy and Solutions at SAS.