The theme of this presentation is how GSK is combining data modelling with master data management, an Enterprise Service Bus, Business Data Stewardship and Enterprise Architecture to build a simplified environment for the management of clinical studies and related data.
Intro slide to GSK.Turnover of £28.4bn in 2009R&D spend of £4.1bn
Intent of this slide is to give some context of what R&D do and where clinical studies fit. Might redraw to make this simpler.
This slide gives a more detailed breakdown of where clinical studies fit and gives a hint of why pharma R&D is complex. Clinical Studies are created to test 3 main parameters – is the product safe within humans, is it effective (i.e. does it cure or alleviate the medical condition that it was intended for) and does it provide value. All pharmaceutical products will go through a number of clinical studies before the product can be launched on the market. This is an ongoing process and we continually run clinical studies on our products to support ongoing licensing of the product. GSK currently runs clinical studies across more than 140 countries. This is a complex activity involving multiple organisations who recruit patients and run the clinical studies on behalf of GSK. There’s also a significant amount of complexity in collecting and reporting on the study results themselves.However the clinical study process sits within an overall Pharmaceutical Enterprise with a diverse and complex set of processes. To a large extent business solutions supporting these different parts of the business have grown up independently because of their highly specialised nature. Each area also has multiple IT solutions, each supporting some part of what is a very complex scientific business.For example Project Planning – plans the development of new products, including budgeting and planning studies. These are very large scale projects that run over many years. Deliver Physical Product – embedded within here is a supply chain that is used first to deliver materials for internal testing, but then out to healthcare organisations conducting clinical studies. An added complexity is the fact that the products are blinded – for example we may ship both Placebo’s and active products that appear identical. Manage Safety of the Product – a large part of clinical studies is to establish that the product is safe for human use. There is continual monitoring of the safety of the product, including the use of Manage Regulatory Activities – there are many regulatory activities related to the conduct and disclosure of clinical studies. These can be very demanding and compliance is critical to the ongoing operation of the company. Chemistry - there are also links back to earlier discovery operations (not shown here). For example the identification of products used within GSK clinical studies is derived from early chemistry activities which are focused on the identification of a molecule. Key point is that this is a complex business.Again may re-draw to make this simpler.
The complexity can be seen within the application landscape. GSK R&D has around 3,000 business applications. Whilst we’re working hard to reduce this, it does represent the diverse and complex nature of a pharmaceutical organisation. The figures here aren’t untypical for any pharmaceutical organisation and represents the diversity and scientific complexity of pharmaceutical operations. Over the years we’ve acquired lots of specialised applications focused on specific business needs – these are highly optimised for the specific scientific function, but don’t integrate well to support the overall operation of the enterprise.The diagram on the left illustrates the complex point to point world in which we currently operate (and remember there are 3,000 of these applications). In reality though there are many examples of where we have no direct interfaces between systems and it’s common to see that some elements of reference or master data are manually re-entered from one system into another. This is something our IT organisation is tackling on a strategic level as part of our Re-Wire R&D programme. We are implementing an infrastructure that supports the implementation of a full SOA environment across the organisation and are putting a lot of training focus both on the technology and the definition of business services. Some of the technologies supporting this are an Enterprise Service Bus (IBM) supporting reliable messaging and web services a Master Data Management solution (Siperian). We are also investing in a claims based security environment. Put all these together and we will have a environment that should support plug and play type integration. We’ve even put together an integration center of excellence to support delivery, so technically all of the pieces would appear to be there.Those of you with an interest in data governance will know that this isn’t sufficient in of its self of course. If we are going to achieve data consistency and information availability we are also going to have to invest a lot of time and effort in understanding and governing the data.
So why is this particularly relevant to GSK’s clinical information environment?GSK is currently making a major investment into it’s clinical information environment with an aim to double productivity by 2015. You can see some of the issues noted on the previous slide are very prevalent here. We have a complex environment that makes it difficult to find and re-use information across systems.The implementation is rationalising, simplifying and in many cases replacing the current IT solutions we have in place to support clinical information.The solutions are all being progressed as part of GSK R&D’s re-wire strategy – so the use of services, ESB, MDM etc will all be part of the mix.
What about master data management? This is very much part of our strategy for Re-Wire and moves us to a situation where we have one version of the truth on the ESB. Diagram shows the status of the major subject areas of interest within R&D at present. Within this model we’re using the following definitions… Data Custodian – we have agreement at a senior level for a specific organisation to manage the data on behalf of the rest of the organisation. This is critical to ensure that the relevant data stewardship roles are in place. Data Stewards – we have individuals assigned to the management of the data. This can include a variety of roles. Master Source identified – we can agree on a single source for the master data. Note that there are a lot of instances where we have only partial data. Can be a variety of reasons, including not all of the data entities we’d consider in scope are available or that the master data only represents a subset of the full organisations master data for this entity. Data Quality Plan defined – means that we have a formally defined document that describes how the master data will be sourced and managed. The document also defines expected quality characteristics for the data. As you can see there’s plenty more to do. A look down the subject area’s shows that there are a number of things that are unique to our industry – Clinical Study, Compound which represents a molecule, and Medical Condition which represents a disease or indication for example. You can also see some things that are familiar within other industries. Products for example, we also have our own version of customer data – GSK makes payments to health care professionals to conduct clinical studies on its behalf; there is increasing legislation requiring us to report these payments, particularly in the US. As you can see we’re not in a position where we have true global master data in place. The last 2 items span the entire GSK organisation – spanning multiple solutions including global SAP and several local Siebel implementations.
Not surprisingly good old data modelling is a key component of our solutions. Perhaps no surprise there – but this is starting from an environment where there was virtually no data modelling within our IT organisation. Any data modelling that was completed was seen as supporting the physical design of the database only. The presence of multiple vendor solutions within our environment made this all the more difficult, with the frequent assumption that we didn’t need a data model because the vendor was supplying one. I wont go into detail here – but main points… We are building a full logical data model for this area, using ER/Studio as our data modelling environment. The model is heavily influenced from external industry standard models such as BRIDG. We are constructing CRUD matrices that allow us to map the data to systems and business process and to identify master sources. We are building definitions into the models as a data dictionary and have automated the Last but not least we plan to use the models to automatically generate the message definitions that flow between systems.
What’s different about our approach to data modelling; compared to traditional approaches. Firstly we are attempting to approach the modelling within the context of an overall R&D and Enterprise data models – the aim being to ensure that we really do understand the common data that needs to be shared and flow across the organisation. We already have an R&D level conceptual data model, that describes all of the data entities of relevance to R&D. We are now seeking to embed the use of these models into our logical data modelling efforts. This will allow us to link common concepts into the our data models. We are also planning further automation for ER/Studio, so that we can automate the import of common entity definitions from a master data model. For example any data model that references clinical study would be able to import a master definition.So why is this such an issue for our organisation. Think about the highly specialised nature of the pharma R&D organisation and fragmented solutions we have in place currently. We really are seeking to integrate across a set of organisations who each have their own perspective and terminology relating to master data. Take one concept that is used right across pharmaceutical R&D – compound. Everyone thinks they know what they mean by this, but when you span the organisation you find that there are all sorts of slightly different interpretations and meanings. Also many different terms are used to describe the same thing – Active Ingredient, API, Investigational New Drug could all mean the same thing. I recently found more than 30 terms that could be used to describe this same entity. What we’re seeing are specialised functions that are representing the role of the data entity, rather than a common definition. As we’re generally dealing with scientific communities all with PhD’s and their own specialised terminology, it’s very hard to introduce generic terminology like party or material. A second area that we’re giving a lot of focus to is the generation of XML schema for messaging directly from the models. We don’t have this fully worked out yet – but it is our aim to be able to step straight from the logical data model to a defined XML message schema. By linking from a enterprise through to a physical level we anticipate much higher consistency for interfaces and hopefully higher quality of information moving across the organisation.
As part of our strategy we’ve defined a set of information principles that are being used direct our approach to Information Architecture and associated governance. You’ll note that there’s a strong emphasis on the use and re-use of data models. Each of these has an assigned set of actions. For example “Key data models should be communicated throughout the organisation” tells us that we need to set up a communication programme to ensure that the role of the R&D level model is understood and where appropriate is used within the definition of Information Architectures.
The diagram shows some of the steps we are taking to link business and IT data governance. A core part is the fact that we have data models – each linked to an R&D level model - as a key component of the environment. The models are managed within an ER/Studio repository. We also see the MDM – managing both master data and reference data, like lists of values, as a key component of our strategy. Shown on the diagram are a set of activities that we are planning or implementing to enable our vision. These are colour coded – items in green show that these are already underway, items in yellow are planned or progressing in a limited part of the organisation. Items in grey are under discussion, but not yet addressed or possibly even agreed to. The items in the top right hand side show that we still have a lot of challenges in bringing together a common view of data governance across the organisation.A few things to point out. We are currently training all of our Business Analysts and Tech Leads in the use of ER/Studio. Around 80 people have now been trained within R&D. As we develop the R&D models and Information Blueprints more fully we’ll also conduct focused communication and training on the use of these models. We are also beginning to plug the use of the data models into our IT Project Governance processes – over time it will become an expectation that IT projects demonstrate that they understand where their data fits and that they are aligned with any existing domain wide Information Blueprints. We of course do this using data models. Further activities are being planned, including linking into the software development process. I’ll say a little bit about this on the next slide.On the business side things are more patchy, but this represents the diversity of our business. We have some strong pockets of success and we are seeking to broaden this across the organisation. Once again we are looking to make full use of the data models to establish common definitions, ownership and responsible data stewards. One other gap (not shown) is the implementation of a data quality toolset which supports business data profiling. We do have a data quality service in house, but as yet we’ve not been able to fully explore business data profiling. I personally have a belief that data profiling tools will be a key enabler to business data stewardship.
Key point here is to make the message appropriate to the audience in question.
Clinical Information Governance ..... .... Keeping the Data Healthy<br />How GlaxoSmithKline are combining the disciplines of<br />Data Modelling<br />Master Data Management<br />Enterprise Service Bus<br />Data Stewardship<br />Enterprise Architecture and IT Governance<br />... to simplify the management of clinical study information<br />
About IPL<br />IPL Clients<br />Trusted, independent consulting & solutions house<br /><ul><li>30 year track record
GSK Business Process - Description<br />- Processes that create value by transforming ideas or raw materials into revenue generating assets and products. Business Processes are the core of the Enterprise<br />B GSK Business Process<br />- Processes that identify molecular targets and validate their association with relevant disease processes and find potentially therapeutic compounds with acceptable developability characteristics. <br />B1 Develop Targets & Leads<br />- Processes that refine the synthesis and delivery of a therapeutic compound and demonstrate safety, efficacy, and manufacturability within regulatory limits and economic feasibility. <br />B2 Develop Drugs and Products<br />- Positions new products for distribution in relevant world markets and secures legal authority to market and sell these products for appropriate levels of reimbursement. External participants of these processes are regulatory authorities, and government or private payers. Internal customers are country sales and marketing groups and global manufacturing.<br />B3 Launch New Product<br />- Direct generation of revenue by marketing and selling products that GSK has manufactured. Customers of this process are consumers, managed care organisations, hospitals, and 3rd party payers.<br />B4 Develop Markets and Manage Customers<br />- Scale-up and transfer of production specifications and technologies to deliver the capability and capacity to manufacture sufficient quantities of new product to meet market demands. Direct customers of this process are the manufacturing sites that will produce the new products.<br />B5 Supply New Product<br />- Supply Chain processes that generate revenue directly by manufacturing and distributing the products that GSK sells. Customers of this process include wholesale distributors and other organisations that supply and use GSK products.<br />B6 Manufacture and Distribute Products<br />
B2: Develop Drugs and Products - Description<br />- Processes that refine the synthesis and delivery of a therapeutic compound and demonstrate safety, efficacy, and manufacturability within regulatory limits and economic feasibility. <br />B2 Develop Drugs and Products<br />- Optimise trade-offs among Risk, Value, Resources and Timing in order to drive decisions relating to Prioritisation of high value assets, Project progression, and management of the progression of opportunities from candidate selection through to launch<br />B2.1 Manage Project Portfolio<br />- Develop all necessary aspects of the large-scale manufacturing process of an active pharmaceutical ingredient.<br />B2.2 Refine Synthetic Route<br />- Develop all necessary aspects of the formulation of a drug product.<br />B2.3 Develop Formulation<br />- Develop all aspects of the manufacture of sufficient quantities of drug products for pre-cliical and clinical evaluation.<br />B2.4 Deliver Physical Product<br />- Pre-clinical and early clinical studies are performed on each candidate selected for progression to FTIM and PoC studies. These studies help to determine that the product profile is achievable and that there is therapeutic potential<br />B2.5 Perform Preclinical Evaluation<br />- Prove the clinical value, efficacy and safety of the product<br />B2.6 Test Human Safety & Efficacy<br />- Monitor the safety of the drug and provide further data to support the market. Evaluate the possibilities for new indications, formulations and presentations. <br />B2.7 Manage Product Lifecycle<br />- Define, communicate and manage regulatory strategy. Compile, review, submit, and maintain regulatory documentation. Influence regulatory policy by interfacing with external bodies.<br />B2.8 NPD6 Manage regulatory activities<br />
Simplifying Clinical Information Environment:<br />Objective: Transform the way we collect, report, archive and retrieve clinical trials data<br />More Effective Use of People’s Time<br />Difficulty finding <br />& accessing <br />Information<br />Lack of Information <br />Re-use<br />More Efficient Clinical Trials<br />Multiple, <br />Complex interfaces<br />Difficulty Integrating Information<br />Enhance Patient Safety & Risk Management<br />Double Productivity by 2015<br />
Clinical<br />Data <br />Steward<br />Business Unit<br />Stewards<br />Asset Stewards<br />CDS Governance + Support<br />Study Stewards<br />Team Members<br />Current Clinical Data Stewardship Framework<br />Levels of accountabilities have been established.<br />Undertaken by existing roles.<br />Based on existing SOPs and guidance wherever possible.<br />Implementation driven within Business Unit by Business Unit Steward.<br />Communities of practice established.<br />Everyone who generates, transforms, uses, stores, archives and/or discards data or documents pertaining to GSK clinical trials is a Steward of clinical data and must understand their responsibilities and act accordingly. <br />Similar frameworks in progression elsewhere within R&D<br />
R&D Master Data Management Roadmap<br />Draft<br />Chart represents cross-organisational mastering of data – does not reflect on quality of information in individual solutions<br />
SCIE Information Blueprint has been crucial to understanding the Information landscape<br />Governance process<br />Data Dictionary<br />Application vs. Data Matrix<br />Data structures – <br />Logical Data Model<br />Application<br />Information Flow<br />
Building a common understanding using layered information models<br />Implementation focus<br />Communication focus<br />(Low)<br />(High)<br />(High)<br />(Low)<br />
Information Principles <br />Data and data models are a critical business asset in GSK and will be managed as a shared asset.<br />All data will be subject to data ownership and governance principles.<br />A strong preference for the reuse and elaboration of existing data models should be exercised.<br />Key data models should be communicated throughout the organisation.<br />The GSK Data Model Repository will be the Source of Record for data models.<br />Integrate Data Modelling with Application Life Cycle.<br />Link models from Enterprise through to Physical.<br />
Data Models linking IT and Business Data Governance<br />IT Focus<br />Business Focus<br />BA Training<br />Data Modelling (complete)<br />Info Blueprints (planned)<br />Business Training<br />Use of Info Blueprints (planned)<br />IT Project Governance<br />Embed use of data models into architecture reviews<br />Data Governance<br />Cross-org teams actively engaged in data management <br />Development Process<br />Automation to embed models into the development process<br />Data Stewardship<br />All data with clear accountability for definitions and data quality<br />Master Data Roadmap<br />Shared master and reference data, built into IT Project Portfolio<br />Data Quality Plans<br />Defined for all shared master and reference data<br />
Different focus of IT & business<br />3NF<br />DBAs, Data Architects and Executives are different creatures:<br /><ul><li>DBA
“Let me tell you about my data model!” </li></li></ul><li>Models for many purposes<br />Key to ensure that models are leveraged across the organisation & not simply pigeon holed for “new” DBMS developments ....<br />Communication with the business<br />Extended metamodel to cover governance<br />Evaluation / configuration / gap analysis of packages<br />Data lineage<br />XML messages (essential for R&D rewire)<br />.... and more<br />
Important in an SoA World. <br />Definition of data & consequently calls to / results from services is vital.<br />Straight through processing can exacerbate the issue<br />what does the data mean?<br />which definition of X (e.g. “cost of goods”)?<br />need to utilise the logical model and ERP models definitions<br />Models & SOA<br />
XML messages are at the core<br />Data Warehouse<br />Claims Management<br />RedBrick<br />DB2<br />Unix Adapter<br />OS/390 Adapter<br />MessageQueues<br />MessageQueues<br />Message Broker<br />MessageQueues<br />MessageQueues<br />Windows Adapter<br />Unix Adapter<br />SQLServer<br />Oracle<br />Billing<br />Document Management<br />
Fundamentals: SOA<br />Message Based Interaction<br /><ul><li>All interaction between components is through messages
Generally XML messages</li></ul>Message: Book details<br />Book ISBN code<br />Amazon URL<br />Book name<br />Category<br />Publication date<br />Publisher<br />Book<br />Recommended price<br />Book Authorship<br />
XML messages need models!<br />DBMS B<br />DBMS A<br />Enterprise Service Bus<br />System A<br />System B<br />XML message<br />
XML message fundamentals<br /><ul><li>XML is hierarchical
ER models represent real world data</li></li></ul><li>XML implementation of ER model<br /><ul><li>An XML schema generated from this model must choose one “parent”
We could choose BOOK as the root, in which case WRITER would become a child of BOOK AUTHORSHIP
We could choose WRITER as the root, in which case BOOK would become a child of BOOK AUTHORSHIP</li></li></ul><li>XML implementation of ER model<br />Book<br />Book ISBN code<br />Amazon URL<br />Book Authorship<br />Writer<br />Writer id<br />Book name<br />Agreement id<br />Writer name<br />Category<br />Writer<br />Specialism<br />Publication date<br />Book ISBN code<br />Book<br />Affiliation<br />Publisher<br />Writer id<br />Recommended price<br />Royalty %<br />Draft delivery date<br />Book Authorship<br />Constraints<br />Profile delivery date<br />Constraints<br />Constraints<br />
Establish a Corporate Repository<br />Share models across the Enterprise<br />Enterprise<br />Conceptual<br />Industry Standard<br />Project<br />Move from data “mine”ing to data “ours”ing<br />Extend the data architecture to incorporate Data Governance<br />Training and mentoring<br />Bake data considerations into the SDLC<br />Data models are NOT just for new developments<br />
Establish a Community of Interest<br />Purpose <br />Share best practices inside company<br />Exchange ideas across projects<br />Represent company on vendor user forum<br />Charter <br />ALL internal data management users<br />Invited consultants & contractors<br />Subjects <br />Standards & guidelines<br />Training & education<br />“Best practices”<br />Part of OUR job IS Marketing!<br />
Beware this is not “fire & forget”<br />Current position<br />Avoid the abyss via investment in “sustain” activities<br />Data Governance Visibility<br />Typical Gartner “hype cycle”<br />TechnologyTrigger<br />Peak of inflated expectations<br />Trough of disillusionment<br />Slope of enlightenment<br />Plateau of productivity<br />Maturity @ your company<br />
Conclusion<br />Understand roles and motivations and work within the organization<br />Federated governance model<br />Avoid silo mentality<br />Communicate<br />Obtain buy in by starting small & document success <br />Make it easy to get hold of<br />Market, market, market!<br />Follow up with a robust architecture<br />Common repository <br />Models appropriate for the audience<br />Defined stewardship<br />Unique definitions<br />“Repurpose” data for various audiences: via the web, Excel, DDL, XML, etc. It’s the data that’s important, not the format.<br />
Data Governance 2.0<br />Conclusion<br />Data Governance and Modeling need to get out of the “old school”<br />Use new technologies to reach users<br />Approach users in their language<br />Don’t forget the fundamentals<br />
Chris Bradley<br />Business Consulting Director<br />Chris.Bradley@ipl.com<br />+44 7501 224230<br />Intelligent Business<br />My blog: Information Management, Life & Petrol<br />http://infomanagementlifeandpetrol.blogspot.com<br />Colin Wood<br />Enterprise Information Architect<br />Colin.email@example.com<br />+44 1438 766671<br />36<br />