Pinnacle 21 vs Nurocor vs TCS ADD: Repository Comparison

A clinical metadata repository (CMDR) can mean either a controlled library of study-design objects or a discovery index for research documents. The distinction matters before comparing Pinnacle 21, Nurocor, and TCS ADD. ECRIN's public Clinical Research Metadata Repository helps researchers find study-linked documents and data; the three commercial products address sponsor standards and study construction. (^[1]) (^[2]) (^[3]) (^[4]) This report compares how those products govern objects from intake and approval through reuse, electronic data capture (EDC) specifications, tabulation and analysis metadata. It does not compare EDC systems or public document search.

As of October 2026, Certara markets Pinnacle 21 CMDR within Pinnacle 21 Enterprise and markets CRF Creator as an additional module. Certara announced that module in February 2026 after its Formedix acquisition; buyers should confirm what their proposed license includes. (^[5]) (^[6]) Nurocor presents its Digital Asset Repository as the foundation of a broader Clinical Platform, with a standards hierarchy, change workflow, EDC build specifications and Define-XML exports. (^[7]) TCS markets the TCS ADD Metadata Repository with a Clinical Standards Registry, study-build automation, mappings and configurable governance. Its current page calls Unified Study Definitions Model (USDM) alignment a roadmap item.

Published performance evidence is narrower than the feature claims. In a 2023 single-study Eli Lilly proof of concept, a customized TCS ADD route and a custom repository route reached the same automation level using Lilly's own metadata model and macros. The study reported 96% of Study Data Tabulation Model (SDTM) variables and 81% of Analysis Data Model (ADaM) variables generated without variable-specific code; it was not an out-of-box comparison of these three vendors. (^[8]) (^[9]) (^[10]) A TCS case describes 95% SDTM generation automation across more than 70 domains for one US pharmaceutical customer, but provides no public matched comparison. (^[11]) Prices, exact supported standards releases and full connector lists require a current proposal and demonstrated configuration.

A commercial CMDR is justified when a standards group can name the objects it will control, the approvals it will enforce and the downstream outputs it will measure. Use the CDISC object crosswalk, the migration sample and the reuse worksheet below to test that proposition. Require a study build from a supplied legacy library, then measure approved reuse, approved-with-change, deviations, time to approved specification and output reconciliation. CDISC's own versioned standards and the FDA Data Standards Catalog provide a more stable test baseline than a vendor feature count. (^[12]) The preferred product is the one that passes those tests for the sponsor's governance model and actual EDC and submission workflow.

The query “Pinnacle 21 vs Nurocor vs TCS ADD” asks about a specialized layer between enterprise standards and individual studies. A repository in this sense stores governed definitions of domains, forms, fields, controlled terms, value-level metadata, mapping rules and templates. The objects need identities, owners, versions, approval states and dependency links. A study then selects approved versions and records where it makes a justified change. Nurocor explicitly describes a hierarchy from global through therapeutic area and indication to study; Certara describes an approved standards library; TCS describes a registry for standards and templates.

The same abbreviation can mislead a searcher. ECRIN's public repository lets scientific users search study-linked documents and data without registration. A sponsor CMDR must make proposed objects reviewable and their release state actionable in study build. (^[13]) This report therefore asks whether a vendor can show an approved object becoming a study-specific item, an EDC artifact, a mapping and a submission metadata output, with its lineage intact.

The standards baseline is public. CDISC defines Clinical Data Acquisition Standards Harmonization (CDASH) for collection, SDTM for tabulation, ADaM for analysis, Operational Data Model (ODM) for exchange and Define-XML for dataset metadata. The US National Cancer Institute (NCI) publishes dated CDISC terminology archives, so “supports CDISC” is too broad a procurement answer without the release and terminology package. (^[14]) The FDA catalog lists which data standards are supported or required for submission; its technical conformance guide had a June 2026 issue as of this report. (^[15]) (^[16])

IntuitionLabs is an adjacent implementation and data advisory firm, not a CMDR option. Its first-party material describes technology roadmapping and Veeva ecosystem services, including its X-Pages partnership. (^[17]) (^[18]) That perspective informs the proof-of-concept questions here, especially how a repository exchanges approved specifications with the systems already in use. A Veeva relationship does not imply that any compared repository has a productized Veeva connector.

Capabilities

Pinnacle 21 CMDR is Certara's current name for the controlled library. Its product page describes governance workflows, reuse of approved standards and impact views for proposed changes. (^[19]) That is the repository claim. Adjacent functions require a packaging check: Certara describes CMDR and CRF Creator as additions to a Pinnacle 21 Enterprise foundation, and its 2026 announcement places CRF Creator in that Enterprise suite. Formedix was acquired in 2023; past descriptions of Formedix ryze should not automatically be read as current CMDR entitlements. (^[20])

Certara says CRF Creator manages forms, edit checks, visit schedules and controlled terminology, with review and approval before EDC build. It says an approved design can generate an EDC study file. Its demo page names Rave, Veeva and OpenClinica as targets. (^[21]) (^[22]) (^[23]) (^[24]) Separately, its SDTM specification tool says it can reuse a validated study or standard mapping specification, and its Define.xml product page claims output for SDTM, SEND and ADaM. The buying test is whether the quoted package connects those modules to one approved object and preserves version identity across outputs.

Adoption

Certara's Biogen case study describes a deployment spanning more than 100 global studies built in Medidata Rave. This is a named customer account published by the supplier, useful for implementation questions but not a neutral performance experiment. (^[25]) A separate anonymous Certara case reports approximately ten months from initial workshop to repository go-live and an 85% reduction in study setup time. Its public description does not provide a matched control group or denominator, so the figures should be treated as case-specific claims. (^[26]) (^[27])

Strengths and Limitations

• Governance fit: Ask the vendor to show the reviewer, approver, effective date, superseded version and study exception for one object; the public page establishes workflow and impact-analysis claims.
• Output fit: Confirm whether CRF Creator, mapping management and Define.xml are included in the proposal, and show the same field across each generated artifact.
• Connector fit: Named EDC targets are useful starting points, but a buyer still needs the exact target version, import direction and edit-check behavior in a live demonstration.
• Commercial fit: Request a module-by-module license, implementation services, validation package and change-control responsibilities. The current public positioning says functionality is added according to requirements.

Capabilities

Nurocor Digital Asset Repository, also presented as Nurocor MDR, is the standards foundation of the Nurocor Clinical Platform. Nurocor says its Vision application and repository support definition, review, approval and provisioning of industry and customer standards. (^[28]) Its object hierarchy can branch from global standards through therapeutic area and indication to individual studies, and its page describes concurrent versions and an ISO 11179-based configurable metamodel. (^[29]) (^[30]) The metamodel may matter for sponsors that need to represent internal operational attributes alongside CDISC objects.

Nurocor places study design around that library. Its schedule-of-activities application says it generates EDC and electronic patient-reported outcome (ePRO) build specifications and can trigger a standards change request. (^[31]) The platform home page says the MDR can export case report form (CRF) and Define-XML artifacts, while direct EDC integration depends on the receiving EDC's capabilities. (^[32]) That wording supports an output demonstration but does not establish a productized connector for every EDC. Nurocor also describes reusable protocol elements and exports of Trial Elements and Trial Arms datasets from Study Designer. (^[33]) (^[34])

Adoption

The reviewed public materials describe components and workflow rather than a measured deployment denominator, license price or comparable build-time benchmark. A buyer can still test the platform against its own use case: import one global definition, derive a therapeutic-area variant, build a study item, then compare the version and change record visible in the platform dashboard. Nurocor says that dashboard distinguishes studies, documents and change requests. (^[35]) Its authoring page describes permissions down to a document section, which makes access design a relevant pilot question for distributed teams. (^[36])

Strengths and Limitations

• Hierarchy fit: Demonstrate inheritance when a global field changes while an approved study retains an earlier version. Nurocor explicitly describes multiple production versions.
• Controlled reuse: Test whether a protocol element reused in several documents propagates an approved change without silently replacing a study exception.
• Study outputs: Inspect the actual eCRF specification, EDC build specification and Define-XML export, including source version identifiers.
• Integration boundary: Obtain a named EDC, supported version, direction, error handling and ownership statement for any proposed direct connection. Nurocor qualifies that possibility by EDC capability.

Capabilities

TCS ADD Metadata Repository is a named platform within the broader TCS ADD suite, separate from the Clinical Data Repository. Its Clinical Standards Registry is described as storing source-collection templates, SDTM and ADaM metadata, analysis results dataset standards and company references. The product page claims visual lineage for element-level dependencies, configurable governance workflows, role-based access and automated ingestion of new standards versions. (^[37]) (^[38]) TCS also describes bidirectional EDC integration for study design and comparison of repository versus EDC metadata. (^[39])

For downstream work, TCS says the platform creates SDTM and ADaM study setups and transformation mappings. It advertises configurable application programming interfaces (APIs) and a study metadata snapshot. Those statements justify an end-to-end pilot, but they do not identify a named productized EDC connector or a precise CDISC release matrix on the current page. The page characterizes USDM-aligned design as a roadmap. A TCS brochure describes an audit trail and says the platform can be implemented standalone or above an existing platform, which affects both architecture and service scope. (^[40]) (^[41])

Adoption

A 2023 paper authored by Eli Lilly practitioners reports a customized TCS ADD repository selected after a proof of concept with a custom repository path. The paper says both routes attained the same variable automation rate using Lilly's internally designed metadata model and generic macros. Lilly also chose not to integrate the repository directly with EDC in that project. (^[10]) (^[42]) This is valuable evidence for designing a sponsor-specific pilot; it does not establish that current TCS ADD automatically produces the same results in a new environment.

TCS separately reports a US pharmaceutical use case with 95% SDTM generation automation across more than 70 domains and 8,100 business hours saved in its first year. These are vendor-reported project results, with public methods and denominators insufficient for a cross-vendor ranking. (^[11]) (^[43])

Strengths and Limitations

• Breadth: Test the advertised line from source collection through SDTM and ADaM mapping on one supplied study.
• Governance: Require an example of role-specific review, approval, audit event and impact of a newly ingested standards release.
• Deployment: Clarify what is delivered as product configuration, what requires standards advisory services, and what infrastructure the proposed deployment needs.
• Roadmap: Treat USDM alignment as an evaluation question until a released version and export can be demonstrated.

A useful CMDR object model begins with a stable identifier and a separately versioned definition. A definition should identify its origin, owner, approved meaning, data type, permissible values, effective period and relationships to upstream collection and downstream datasets. The National Library of Medicine describes a common data element as a precisely defined question paired with allowable responses; its CDE repository supplies human- and machine-readable definitions. (^[44]) (^[45]) ISO/IEC 11179 formalizes administration, identification, naming and definition of registered items. (^[46]) The editorial test is whether a tool preserves these relationships when it reuses an object, rather than copying ungoverned text.

The CDISC crosswalk below is a test specification, not a claim that every vendor implements every release. CDISC Library offers structured domain and terminology metadata; NCI maintains dated terminology versions. CDISC controlled terminology had a September 25, 2026 update, illustrating why a repository must record the exact package used by each study. (^[47]) (^[14]) (^[12])

Table 1 maps controlled objects to an observable import, governance or export test.

Object layer	Open reference	Proof to request
Question, form, field and visit	CDASH collection concepts and ODM exchange ([48]) ([49])	Import an approved form; show field identity, visits, terms and a versioned study override.
Domain and variable	SDTM with CDISC Library domain metadata ([48]) ([47])	Trace an EDC field into a specified tabulation variable and approved mapping.
Analysis variable and result	ADaM traceability to SDTM ([50])	Show analysis derivation, approver and upstream dependencies.
Codelist and value-level metadata	NCI terminology archive and CDISC Biomedical Concepts ([14]) ([51])	Pin a dated codelist and show what a later release changes.
Exchange and submission metadata	ODM version 2.0 and Define-XML version 2.1 ([52]) ([53])	Export, validate and round-trip the actual files; record both schema and terminology versions.
Study definition	USDM reference model ([54])	Demonstrate an actual conformant export or label it as roadmap.

This crosswalk exposes two common procurement traps. ODM 2.0 has backward-compatibility changes, so “ODM support” needs a version and round-trip test. Define-XML 2.1 can identify the standards and terminology versions referenced by a document, so an export should expose those values rather than only a file name. Dataset-JSON may reference a Define-XML document, but that relationship is another exchange test, not a substitute for complete dataset metadata. (^[55])

An open baseline can reduce dependence on vendor presentations. CDISC Library provides standards metadata in JSON, XML, ODM, CSV and Excel, and publishes machine-readable difference reports. (^[56]) The open-source OpenStudyBuilder describes a reusable standards library, while a TransCelerate study-definition repository reference implementation supplies another inspection point. (^[57]) (^[58]) Neither example proves feature parity with a commercial CMDR; they let a team test object identity, version-difference handling and export requirements before procurement.

The primary comparison is the governed lifecycle, not a count of checkmarks. The table records publicly documented claims as of October 2026 and the demonstration needed to convert a claim into procurement evidence. An absent detail means public documentation reviewed here did not settle the question. It is not a zero or a product score.

Table 2 compares the three products using the same workflow questions.

Decision point	Pinnacle 21 CMDR	Nurocor Digital Asset Repository	TCS ADD Metadata Repository
Library and inheritance	Approved standards library; demonstrate study version binding ([59])	Global to indication to study hierarchy; demonstrate inheritance	Registry of standards and templates; demonstrate object lineage ([60])
Review and change	CMDR workflow and change impact; CRF Creator review in separately scoped module ([19])	Definition, review, approval and platform change request ([31])	Configurable workflows and version ingestion ([38])
Study build	CRF Creator promises EDC study file; confirm licensed module and target release	Schedule application promises EDC and ePRO specifications ([61])	Vendor describes bidirectional EDC design integration
Downstream metadata	Separate mapping and Define.xml functions; demonstrate linkage	CRF and Define-XML exports; inspect actual output ([62])	SDTM/ADaM mappings claimed; request explicit Define-XML demonstration
Exchange and connector question	Demo names Rave, Veeva, OpenClinica; verify exact capability	Direct connection depends on receiving EDC ([32])	Configurable API claim; request a named connector and error handling

The products emphasize different workflows. Pinnacle 21 offers a visible sequence of Enterprise modules, so licensing and metadata continuity across those modules are decisive. Nurocor emphasizes a hierarchical standards and study-definition platform, so inheritance and version coexistence are decisive. TCS emphasizes an end-to-end registry and mapping flow, so a complete worked transformation and governance audit are decisive. The table deliberately leaves pricing and connector coverage out of a score because current public pages do not establish comparable terms.

A request for proposal should therefore use one supplied case, not three unrelated demos:

• Provide the inputs: One protocol schedule, one legacy form, a company codelist, a CDISC package and a known study deviation.
• Register objects: Import, deduplicate and assign stable identifiers to forms, fields, codelists and mappings.
• Govern changes: Route a proposed global amendment through named roles, approval and effective dating.
• Reuse for a study: Create a new study from approved versions, preserving a justified local exception.
• Build collection: Produce annotated CRF and EDC specifications, then compare generated metadata with the built EDC study.
• Build datasets: Show SDTM and ADaM specification lineage, Define-XML where proposed, and a validation report.
• Upgrade standards: Ingest a new controlled terminology release and show the impact without silently changing the approved study.
• Export and exit: Deliver machine-readable metadata and an audit history that another team can inspect.

The output should be judged on observed behavior, including manual edits after export. CDISC's public artifacts and the FDA catalog provide release identifiers for this script, while the receiving EDC and statistical programming environment determine whether a proposed connector genuinely works. (^[15]) (^[56])

There is no public, independent matched benchmark in the reviewed evidence that runs Pinnacle 21, Nurocor and TCS ADD on the same library, standards release, EDC target and approval policy. The closest detailed process account is Lilly's 2023 single-study proof of concept, not a three-product test. It selected three ADaM datasets, 11 SDTM domains and 17 raw datasets within a three-month project window. (^[63]) The practitioner paper measured variable automation by the share generated by generic macros without variable-specific custom code. (^[64])

The reported 96% SDTM and 81% ADaM figures came from Lilly's combined metadata model, repository paths and macros. The paper says the two repository approaches achieved the same level of automation and that Lilly did not connect its MDR directly to EDC. (^[8]) (^[9]) (^[10]) (^[42]) Its Define-XML output belongs to the wider study automation process, not a verified out-of-box TCS feature. This case supports a practical benchmark design: hold the study, macros, standards and EDC constant, and isolate repository setup time and downstream rework.

Supplier cases answer narrower questions. Certara's Biogen account documents multi-study use and a move from ADaMIG 1.1 to 1.3; it is useful when asking how version migration is managed. (^[25]) (^[65]) TCS's reported automation and hours-saved example may inform a request for underlying denominators and the boundary of custom work. (^[11]) (^[43]) Neither makes a direct ranking possible. Nurocor's public platform descriptions focus on functions rather than a comparable timed outcome.

A sound pilot records the number of candidate objects, objects accepted without change, accepted with approved change, new objects, rejected duplicates, unresolved dependencies and exception approvals. It also timestamps intake, first review, rework, final approval, EDC import and specification reconciliation. A vendor can then show whether its gains come from reuse, simpler approvals, generated output or work shifted to professional services. The benchmark should include human review time and failed round trips rather than measuring only initial file generation.

The central measurement problem is the reuse denominator. Counting how many objects reside in a library does not show whether they were reusable for a new study. A peer-reviewed repository prototype reported 466,569 unique definitions and 1,836 reused items and item groups in its study-editor integration; those are different units and cannot be divided into a sponsor study-build reuse rate. (^[66]) (^[67]) Another German survey found 252 of 301 respondents interested in CRF reuse, but interest is not measured time saved and its 22.1% response rate limits generalization. (^[68]) (^[69])

Define eligible objects before the pilot: each study requirement that could map to an approved library object counts once at the chosen granularity. Then report exact reuse = approved objects used unchanged / eligible requirements and controlled reuse = (unchanged + approved-with-change) / eligible requirements. Report deviations separately; a changed field is not exact reuse. The same form can contain both reused and new fields, so the object unit must be declared. An earlier public CRF editor explicitly tested reuse at form, item-group and data-element levels, illustrating why granularity changes the measured rate. (^[70])

Table 3 is a hypothetical example, with units and arithmetic shown so a buyer can reproduce it for a real migration. These are analyst-defined sample counts, not outcomes attributed to any vendor.

Worksheet item, hypothetical	Count and unit	Calculation or decision
Legacy source inventory	1,000 object records	Count forms, fields, codelists and mappings separately before merge.
Duplicate records	180 records	Link to surviving identities; do not count as reusable approved objects.
Obsolete versions	120 records	Retain provenance, exclude from the active candidate set.
Unresolved dependencies	40 records	Quarantine until referenced codelists or mappings are resolved.
Approval exceptions	20 records	Route through owner review before release.
Pilot study eligible requirements	200 field requirements	Denominator fixed before vendor demonstrations.
Used unchanged	90 fields	Exact reuse: 90 / 200 = 45%.
Approved with change	50 fields	Controlled reuse: (90 + 50) / 200 = 70%.
New or unresolved	60 fields	Reconcile to denominator: 90 + 50 + 60 = 200.

The migration inventory and the pilot denominator serve different purposes. After deduplication and obsolete-version retirement, 700 records remain in the hypothetical source inventory before dependencies and exceptions are resolved; that number is not a study reuse rate. On the pilot study, a 70% controlled reuse result would still require inspection of the 50 changed fields and 60 new or unresolved fields to judge quality. The measure can improve while approval time worsens, so report median time from intake to approved study specification, its distribution and the number of review cycles beside reuse. These are proposed evaluation measures, not published cross-vendor results.

For a cost case, keep license, migration services, standards maintenance, connector validation and per-study manual work in separate columns. A repository earns its cost when the observed reduction in avoidable review and rebuild effort exceeds the full operating and change-control cost under the sponsor's study volume. Commercial terms are quote-specific in the reviewed material; a prospective buyer should obtain a current price, module boundary, implementation statement of work and support schedule from each provider. Also cost an internal CDISC Library baseline. A public NCI metadata service, for example, shows that versioned forms can be exported in XML and an EDC loader format, providing a concrete reference output for a pilot. (^[71]) (^[72])

The strongest procurement question is whether a repository can preserve semantic continuity when an approved definition is transformed into several artifacts. CDISC Biomedical Concepts add semantics and variable relationships that may support collection and Define-XML design. CDISC Library published 1,345 Biomedical Concepts and 1,326 SDTM Dataset Specializations as of April 6, 2026, numbers that show a moving reference corpus rather than a product's loaded inventory. (^[73]) Teams should ask how frequently a vendor imports those updates, how it compares versions and whether each existing study remains pinned to its approved baseline.

A migration should run in measured waves:

• Inventory: Export legacy libraries with source IDs, object types, versions, owners and approval evidence.
• Normalize: Separate actual duplicates from similar fields whose meanings differ; retain provenance.
• Map: Crosswalk each active field to CDASH, SDTM, controlled terminology and any analysis dependency.
• Resolve: Clear missing codelists, orphan mappings and approval exceptions with accountable owners.
• Load: Preserve source identity and version history where technically possible; record transformations.
• Pilot: Build a representative study and compare its approved specification with EDC and dataset outputs.
• Scale: Track exact reuse, controlled reuse, deviations, approval time and rework by release.
• Lineage acceptance: Trace one changed field through collection, tabulation and analysis.
• Round-trip acceptance: Reimport a generated specification and list every manual repair.
• Approval acceptance: Prove who approved the active version and when.
• Exit acceptance: Export complete objects, versions and dependencies in a usable format.

The open-standards baseline is useful even if the buyer chooses a commercial system. The CDISC Library API can supply machine-readable metadata, though access requires an API key; NCI says CDISC terminology is available without licensing restrictions. (^[74]) A repository should make that standards lineage observable, rather than obscure it behind a “compliant” label. The NCI caDSR example also demonstrates version management and EDC-oriented exports in a public metadata setting, useful as output checks even though it has a different purpose from sponsor CMDR procurement. (^[72]) (^[71])

IntuitionLabs' advisory and integration role fits this test framework: its own site describes technology roadmapping, implementation and data engineering, while its Veeva partnership concerns Vault CRM X-Pages rather than a CMDR product. (^[17]) (^[18]) That is a reason to keep selection evidence specific to the compared vendors and the buyer's clinical stack. USDM and other digital-study-definition work could increase pressure for portable objects, but a roadmap statement must be distinguished from an installed, versioned export. CDISC calls USDM a standard model for conformant study-definition technologies; TCS currently labels its alignment as a roadmap.

The answer to Pinnacle 21 vs Nurocor vs TCS ADD depends on where the sponsor needs control. Pinnacle 21 merits close examination when the desired path connects an approved library to CRF Creator, SDTM mapping and Define.xml functions, with the license and object lineage shown end to end. Nurocor merits close examination when a hierarchical standards model, study-definition workflow and version coexistence are central. TCS ADD merits close examination when the proposed scope includes source-to-analysis mappings and a demonstrable study-build flow. These are fit hypotheses grounded in current vendor descriptions, not comparative performance scores.

A commercial repository is justified by a measured operating result: approved objects reused at a declared granularity, fewer avoidable changes, a shorter and auditable approval path, and artifacts that reconcile with the receiving EDC and downstream standards. The current public record offers a useful Lilly process case and vendor-reported deployments, but no matched three-product benchmark or comparable public price schedule. (^[10]) (^[25]) The buyer therefore needs a controlled proof of concept with its own library and an itemized proposal.

The practical selection rule is to pin the relevant CDISC and terminology versions, provide identical source objects to every vendor, and record what each system actually imports, approves, versions, exports and reconciles. Keep roadmap claims, services and productized functionality distinct. That test creates a defensible answer even as standards and packaging change. (^[12]) (^[15])