Accelerating Drug Development with AI-Powered Clinical Trial Transformation

novartis · Healthcare · 2025 · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.2 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Clinical development

Novartis needed a compliant data and AI platform to reduce clinical-trial development cycle time and support protocol generation and decision systems.

Constraints:

Architecture

Novartis and AWS built a regulated clinical-data platform before layering AI use cases on top. Domain data sources are ingested into a modular AWS/Databricks data mesh; analytical data products move through raw, reusable, and consumer-specific layers; operational relational workloads use Amazon RDS; an enterprise catalog, metadata registration, access workflow, data quality, traceability, governance, and central observability make the platform GXP-ready. AI/ML playgrounds such as SageMaker and Bedrock then consume approved, qualified data for protocol generation, safety analytics, and decision-system use cases.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  domain-data-sources[Domain data sources] --> ingestion-modules[Ingestion modules]
  ingestion-modules --> analytical-data-products[Analytical data products]
  analytical-data-products --> databricks-on-aws[Databricks on AWS]
  databricks-on-aws --> ci-cd-pipelines[CI/CD pipelines]
  ci-cd-pipelines --> domain-aws-accounts[Domain AWS accounts]
  analytical-data-products --> data-product-registry[Data product registry]
  data-product-registry --> enterprise-data-catalog[Enterprise data catalog]
  enterprise-data-catalog --> approved-access-workflow[Approved access workflow]
  approved-access-workflow --> ai-ml-playgrounds[AI ML playgrounds]
  ai-ml-playgrounds --> protocol-generation[Protocol generation]
  amazon-rds[Amazon RDS] --> operational-sql-clients[Operational SQL clients]
  enterprise-data-catalog --> governance-and-access-management[Governance and access management]
  governance-and-access-management --> central-observability-platform[Central observability platform]
  central-observability-platform --> dashboards[Dashboards]
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
Domain data sources Clinical, safety, imaging, audit, and regulatory source systems from different Novartis domains. Ingestion modules
Ingestion modules Modular ingestion components that bring domain data into the platform. Domain data sources, Analytical data products
Analytical data products Raw, reusable, and consumer-specific data products for analytical use cases. Ingestion modules, Data product registry, Databricks on AWS
Databricks on AWS Processing layer for analytical data products and data pipelines. Analytical data products, CI/CD pipelines
CI/CD pipelines Infrastructure-as-code deployment path for domain data products across environments. Databricks on AWS, Domain AWS accounts
Domain AWS accounts Dev, QA, test, and production accounts owned by each data domain. CI/CD pipelines
Data product registry Directory of data products with business metadata for discovery and use requests. Analytical data products, Enterprise data catalog
Enterprise data catalog Search and request surface for practitioners to find and request approved data. Data product registry, Approved access workflow
Approved access workflow Data-owner approval or rejection process before consumers use a data product. Enterprise data catalog, AI ML playgrounds
AI ML playgrounds SageMaker, Bedrock, and related AI environments that consume approved clinical data. Approved access workflow, Protocol generation
Protocol generation AI use case that drafts compliant clinical protocols from governed data. AI ML playgrounds
Amazon RDS Operational relational store for transactional/SQL workloads. Operational SQL clients
Operational SQL clients Business-user path for direct JDBC SQL access to relational data. Amazon RDS
Governance and access management Traceability, quality, access, and compliance controls across the platform. Enterprise data catalog, Central observability platform
Central observability platform Central AWS account for logs, audit traces, financial data, quality signals, and dashboards. Governance and access management, Dashboards
Dashboards Visibility layer for cost, quality, access, security, latency, and operational accountability. Central observability platform

Data flow

Domain systems feed data into modular ingestion and processing pipelines. Data products are registered with business metadata, stored and processed in AWS/Databricks or RDS, exposed through an enterprise catalog, approved by data owners, consumed by BI or AI/ML environments such as SageMaker and Bedrock, and traced through a central observability account for logs, audit traces, quality, cost, and dashboards.

3 supporting quotes
“the vision was to have a mesh type subscription so that any data sources, any data that is provided here, any use case that needs it should be able to search for it”transcript, implied
“The consumption happens via this approved workflow. All the while you're maintaining the management and governance on the whole process”transcript, stated
“All the while you're maintaining the management and governance on the whole process and all of the data is flowing into, sorry, all of the logs and trace data is flowing into the observability platform, so that you can create all kinds of dashboards that you need with it.”transcript, stated

Why this architecture

Novartis chose a foundational data-platform rebuild because legacy, domain-specific systems were fragmented, non-interoperable, and not scalable enough for cross-domain clinical AI. The team framed this as fortifying the core before adding AI, with modular components, open standards, governance, and observability to satisfy GXP and future use cases.

“fortify the core and all of this while maintaining the reliability, the integrity, the security, the sanctity of the data underlying.”transcript, stated
“However, these domains at the time were purposefully built for their own domains and specializations but not necessarily built for interoperability with each other.”transcript, stated

Scale

Alternatives considered (roads not taken)

Plug AI devices into the legacy data house

Rejected because: The platform needed re-architected wiring, interoperability, and modernized foundations before AI could scale safely.

“You may need to re-architect the wiring. You may need to at least modernize it. You may need to make sure that your sockets are correctly placed, so that it can support all of your devices.”transcript, stated

Choose tools only by feature fit

Rejected because: Novartis had to account for culture, licenses, cost restrictions, and worker skills in a regulated operating model.

“you also keep the organizational culture in mind. Are you a builder versus a buy company? Do you have any existing enterprise licenses?”transcript, stated

Keep logs and audit traces in each source system

Rejected because: Central observability avoided fragmented dashboard connections and gave users accountability over quality, access, security, speed, and cost.

“In theory it is possible to keep all the logs, and audit traces, and financial information where they are. But then the processing side of it, when you create a dashboard, they're going to have multiple connections. So for us in our case, it made more sense to do it this way.”transcript, implied

Lock into proprietary or narrow platform capabilities

Rejected because: Open standards were needed for GXP interoperability across sources, therapeutic areas, and multiple platforms.

“need to be open and communicated to each other, so that we don't lock ourselves into a particular capability and then have to work around that capability. The third is observability. We saw that about that earlier as well. The reason it's important because it drives”transcript, stated

Patterns

data-quality-loop (data-platform)

The platform reduced data fragmentation and used data traceability as a foundation for clinical AI use cases.

“The first is how can we reduce complexity? So we eliminated data fragmentation, we eliminated the fact that”transcript, stated

privacy-preserving-processing (governance)

The platform had to satisfy regulated GXP controls and traceability.

“the compliance standards that they use in this case was GXP. GXP stands for Good X Practice. X could refer to any”transcript, stated

Tradeoffs

Choose platform tools based on organizational fit, not only technical fit.

Chose A tool-selection process that considered culture, licenses, cost restrictions, and worker skills over Picking technically capable tools from a feature checklist alone.

Rationale: The implementation had to survive inside Novartis' operating model and compliance environment.

“you would do a pros and cons list, if you will, of all the technology or tools that are fit for purpose and you would already know what this tool can and cannot do”transcript, stated
“However, what's important is that you also keep the organizational culture in mind. Are you a builder versus a buy company? Do you have any existing enterprise licenses?”transcript, stated

Where to centralize observability.

Chose a central observability platform over leaving logs, audit traces, and financial information distributed at source.

Rationale: The team preferred central dashboards and accountability over many dashboard connections back to individual systems.

“So for us in our case, it made more sense to do it this way.”transcript, stated

How to avoid future lock-in in a regulated data mesh.

Chose open standards and interoperable tools over platform-specific capabilities that required workarounds.

Rationale: The GXP environment needed tools and AWS services that could communicate across sources, therapeutic areas, and platforms.

“the interoperability required between the tools is very much was an important need and ask.”transcript, stated

Gotchas (what bit them)

Legacy clinical systems turned the AI platform into an organizational change problem as well as a technical migration.

Root cause: Existing systems brought low efficiency, operational risk, vendor lock-in, and governance mindset changes.

Resolution: The program treated platform modernization, governance, and data-product operating model changes as part of the same transformation.

“we realized that there are some challenges that we're going have to navigate through with the Novartis. Some of them you might find familiar.”transcript, stated
“This means it didn't only bring in the technical challenges such as, you know, low efficiency, potential exposure to risks, potential vendor logins, et cetera.”transcript, stated

Domain-specific clinical data products could not support the digital twin vision until interoperability was designed in.

Root cause: The data domains were optimized for their own specialties, not for cross-domain operational simulation.

Resolution: The team moved toward interoperable data products, traceability, governance, and observability across the platform.

“However, these domains at the time were purposefully built for their own domains and specializations but not necessarily built for interoperability with each other.”transcript, stated

Evaluation

Novartis reported query-speed, cost, and manual-work reduction metrics from the platform.

Metrics: query speed · storage cost · manual hours saved · protocol acceleration

“The outcomes that approval just spoke about, right? 71.8% query speed increase, 60% cost optimization,”transcript, stated

Outcomes

The summary also reports protocol-generation acceleration.

“The protocol generation use case achieved 83-87% acceleration in producing compliant protocols, demonstrating significant progress toward their goal of bringing life-saving medicines to patients faster.”summary, stated