CDISC CORE and Conformance Rules are a rule set with an open-source reference validation engine for the technical implementation of CDISC standards. Conformance Rules define specific conditions under which SDTM, SEND, or ADaM data meet a standard\u2019s requirements; CORE executes machine-readable rules against these data. The system makes validation rules transparent and repeatable, but it does not replace the subject-matter assessment of the study.<\/p>\n
A rule may, for example, require that a mandatory attribute is present, that a value is within an allowed codelist, or that variables are logically consistent across records. It therefore describes a verifiable criterion for implementing a CDISC standard. The result is a message tied to a specific rule and a specific data element\u2014not automatically a judgement on clinical plausibility or the medical relevance of a finding.<\/p>\n
Historically, many conformance rules were provided as tables. Different organisations could therefore implement the same textual requirement differently. CDISC Open Rules converts the rules into a more unambiguous, machine-readable form. The associated rule catalogue can represent CDISC requirements as well as regulatory business rules and organisation-specific extensions.<\/p>\n
For working with messages, the rule identifier, rule version, the standard version checked, and the affected record are indispensable. Only this information makes it possible to reproduce a finding reliably and determine whether the cause lies in raw data, mapping, metadata, or the validation configuration. A mere total number of error messages would not be sufficiently informative for correcting a submission.<\/p>\n
CORE stands for CDISC Open Rules Engine. CDISC provides the engine as an open-source reference implementation so that the published Open Rules can not only be read but also executed technically. The engine code is publicly available; using other validation software remains possible as long as it correctly interprets the applicable rules.<\/p>\n
The separation between rule and engine is essential. A rule specifies the condition; the engine is the tool that evaluates it. CDISC thereby combines governance, rule-based specification, and technical execution. Changes to a rule must therefore be checked against the relevant standard version, executability, and the expected message text before they enter a validated validation workflow.<\/p>\n
Not every scientifically sensible rule can be fully automated. Some conditions require context from the protocol, a medical assessment, or a comparison with external documentation. The rule catalogue must therefore make it clear whether a check can be executed fully, only partially, or not at all by machine. This classification prevents a non-checkable issue from being incorrectly treated as passed simply because the engine does not generate a message.<\/p>\n
CDISC CORE is neither a general quality management system nor a complete data cleaning process. It checks a defined set of machine-readable conformance conditions. A flawless CORE run does not confirm that consents are in place, sources are correct, a protocol is medically sound, or an analysis result has been scientifically substantiated convincingly.<\/p>\n
The neighbouring entry Data Integrity addresses the reliability of data across its lifecycle; CORE, by contrast, focuses on defined technical rules for specific data standards. A query typically triggers clarification with the study site. A CORE message, by contrast, may target mapping, a variable, a terminology assignment, or a Define-XML attribute in central data processing.<\/p>\n
The prioritisation of a rule message therefore depends on the requirement affected and its impact on data delivery\u2014not on the mere existence of a warning. Subject-matter owners must decide whether the finding should be corrected, explained as a justified exception, or fed back to refine the validation rule.<\/p>\n
For submission data, rule-based validation is worthwhile well before database lock. If interim SDTM and ADaM programming is tested against the intended rules, missing required values, inconsistent domain relationships, or invalid terminology become apparent earlier. This makes it possible to correct errors in the transformation logic before they propagate into analysis and submission artefacts.<\/p>\n
Full-service CROs such as Mediconomics support this by configuring relevant rule packages, evaluating CORE messages, feeding technical findings back to data management and biostatistics, and documenting justified exceptions. They can also integrate FDA business rules and project-specific checks into the SDTM, SEND, or ADaM delivery workflow.<\/p>\n
Is a CORE message always a submission error?<\/strong><\/p>\n No. The message indicates that a data element violates a specifically implemented rule or that a check has failed. Whether this results in a correction, a traceable exception, or further development of the rule depends on the context.<\/p>\n Can CORE also execute custom validation rules?<\/strong><\/p>\n In addition to CDISC Open Rules, the CORE approach includes regulatory and organisation-specific rules. However, custom rules require a defined specification, traceable versioning, and testing so that their validation results remain reliable.<\/p>\n Does CORE verify the correctness of clinical source data?<\/strong><\/p>\n No. CORE checks structured data against rules. Source data verification and the assessment of clinical events belong to other processes such as monitoring, medical review, and data management.<\/p>\n CDISC CORE and Conformance Rules are a rule set with an open-source reference validation engine for the technical implementation of CDISC standards. Conformance Rules define specific conditions under which SDTM, SEND, or ADaM data meet a standard\u2019s requirements; CORE executes machine-readable rules against these data. The system makes validation rules transparent and repeatable, but it […]<\/p>\n","protected":false},"author":10,"featured_media":0,"parent":0,"template":"","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"glossary-cat":[25],"class_list":["post-8065","glossary","type-glossary","status-publish","hentry","glossary-cat-datenmanagement-eclinical"],"acf":[],"related_terms":"","external_url":"","internal_reference_id":"","_links":{"self":[{"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/glossary\/8065","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/glossary"}],"about":[{"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/types\/glossary"}],"author":[{"embeddable":true,"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/users\/10"}],"version-history":[{"count":0,"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/glossary\/8065\/revisions"}],"wp:attachment":[{"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/media?parent=8065"}],"wp:term":[{"taxonomy":"glossary-cat","embeddable":true,"href":"https:\/\/mediconomics.com\/en\/wp-json\/wp\/v2\/glossary-cat?post=8065"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Regulatory References<\/h2>\n
\n