Platform — private preview

Kyber Data Standards, in detail.

This page summarises what KDS covers and how it is built. Field-level definitions and crosswalk tables are not published here — they ship inside the versioned packs, available by request.

The Kyber emblem: a faceted crystal holding an orange DNA double helix
At a glance

Resources, fields, codelists.

KDS defines the records a clinical-trial organisation keeps as typed resources, bound to codelists where a controlled value is expected.

  1. Level 1 156

    Resources. The record types of clinical-trial operations — trackers, quality events, study data.

  2. Level 2 4,627

    Fields. Typed, named and owned by one resource each, so every term in KDS means one thing.

  3. Level 3 915

    Codelist files. Controlled vocabularies; 358 are pinned to an external terminology.

Crosswalk coverage

Fields pinned to each external standard, as a share of all 4,627 fields. Targets overlap.

  • Any external standard815 · 17.6%
  • FHIR R4751
  • CDISC SDTM132
  • CDISC Define-XML132

Bars share one scale: all 4,627 fields. We publish coverage as it stands, not as it will be.

Codelist terminology

Controlled values, not just field names, line up with external terminologies.

  • Pinned to an external terminology358 · 39.0%

915 codelist files in total. The remaining codelists use KDS-local values.

Coverage, honestly stated. 88 resources are not yet externally mapped. Extending crosswalk coverage across the standard is on the roadmap now.

As of 4 October 2026. Source: KDS campaign at commit 33dc3b6. Machine-readable figures and provenance (stats.json).

Interoperability

The crosswalk model.

KDS is the operational vocabulary. External standards are targets a field is pinned to — not replacements for it.

Source of truth KDS field Defined once, in its resource
  • FHIR R4Exchange
    751fields pinned
  • CDISC SDTMSubmission
    132fields pinned
  • CDISC Define-XMLSubmission
    132fields pinned
  • Pinned, not copied

    Each mapping pins a KDS field to a named target in a specific standard. The KDS definition stays the source of truth.

  • Many targets per field

    A field can map to FHIR R4 for exchange and to SDTM and Define-XML for submission — which is why the counts overlap.

  • Codelists too

    358 of the 915 codelist files are pinned to an external terminology, so coded values line up as well as field names.

Quality events

The tracker event taxonomy (v0.1 draft)

A hierarchical coding for quality and operational events, in the style of MedDRA's SOC and PT levels. Free text stays; a governed code is added, so events group, trend and surface recurrence.

  • L1

    Event Class ≈ MedDRA SOC

    The shared QEO backbone. Ten classes that every tracker family codes against.

    • L2

      Event Category

      Grouped areas within a class, defined per tracker family.

      • L3

        Event Term ≈ MedDRA PT

        The specific event. Stable, hierarchical, never reused after retirement.

The QEO backbone — ten L1 classes

Worded to mirror regulatory inspection-finding language.

  • DOCDocumentation & Records
  • TRNTraining & Competency
  • DATData Management & Integrity
  • PRCProtocol & Process Design
  • EQFFacilities, Equipment & Materials
  • VENVendor & Outsourcing
  • COMCommunication & Escalation
  • SYSComputerised Systems
  • SBJSubject Safety & Conduct
  • REGRegulatory Reporting

Seed families (v0.1)

Each tracker family adds its own L2 and L3 terms under the shared classes. The v0.1 seeds:

  • CAPA-Corrective & preventive actions
  • DEV-Deviations (non-protocol)
  • PD-Protocol deviations
  • AUD-Audit findings

All seed vocabularies are under quality review before ratification.

Illustrative example — synthetic data

What a tracker looks like

Four made-up entries in a CAPA- tracker. Free text stays as written; each entry carries an L1 class from the shared backbone, a status and a crosswalk state. The L2 and L3 terms, the full field list and the mappings are what ships in the packs, so they are held back here.

Entry What happened (free text) Coded as Status Crosswalk
CAPA-SYN-0141 Delegation log signed after the task had already been performed DOCL2 term held backL3 term held back Open Mapped
CAPA-SYN-0142 Storage temperature excursion not escalated within the agreed window EQFL2 term held backL3 term held back Action in progress Mapped
CAPA-SYN-0143 Study task started before the training record was filed TRNL2 term held backL3 term held back Effectiveness check Partial
CAPA-SYN-0144 Eligibility checklist printed from a superseded protocol version PRCL2 term held backL3 term held back Closed Not yet mapped
Synthetic entries for illustration: no real study, site or organisation. marks a term that exists in the taxonomy but is held back from the public site.

MedDRA stays for safety. The taxonomy covers quality and operational events only. Adverse events keep MedDRA — this is never a parallel safety dictionary.

Releases

kds-packs.

KDS ships as versioned customer packs. Each build carries a SHA-256 integrity manifest, so contents can be checked file by file.

Pack access is by request. Packs are not available for direct download during private preview. Request pack access.

Pack figures come from the 29 September 2026 builds — an earlier snapshot than the coverage figures above.

Packs listed in the kds-packs index
PackVersionBuilt FilesSize IntegrityAccess
KDS-v0.1-CUSTOMER-PACK0.129 Sep 2026 2,41918.2 MBSHA-256 manifest Request pack access
KDS-v0.1.0-CUSTOMER-PACK0.1.029 Sep 2026 2,41918.2 MBSHA-256 manifest Request pack access

What a pack contains

  • conformance/1,161 Conformance rules with positive and negative test fixtures
  • codelists/902 Codelist schemas and the controlled-terminology registry
  • crosswalks/216 CDISC and FHIR crosswalk documents
  • trackers/123 Tracker workbook templates
  • docs/ schema/ traceability/ registry/ + licence17 Start-here guide, playbook, release notes; database schema and validation engine; KDS-to-SOP traceability; registry and validation; licence terms