Detailed Description of CIP-Intake YAML
This page explains the CIP-Intake YAML used by the MR-clinical-trial-CIP-Creator GPT to validate your inputs and generate a regulator-aligned Clinical Investigation Plan (CIP) skeleton for CH and/or EU submissions.
What the YAML is for
- Validation: The GPT checks required data, format, and consistency and returns a Gap Report when something is missing or conflicting.
- Generation: When valid, it creates a jurisdiction-aligned CIP skeleton (swissethics for CH, ISO 14155/MDR for EU) and then drafts sections using your Plans.
File rules & formatting
- Filename: any
.yamlor.yml. - Encoding: UTF-8. Dates as
YYYY-MM-DD. - Empty values (
"",null,[],{}) are treated as missing unless you setnot_applicable: trueon that subsection. - If multiple YAML documents are in one file, the GPT reads the first document with
meta.schema_version. - Indent with 2 spaces. No tabs.
Minimal valid example (for orientation)
meta:
schema_version: "1.0"
jurisdiction:
track: CH # or EU / CH+EU / Other
ch:
clinO_MD_category: C2
swissmedic_involved: true
basec_lead_ec: "KEK BE"
identification:
full_title: "Feasibility of MRSI X at 7T"
investigation_id: "MRSI7T-001"
cip_version: "1.0"
cip_date: "2025-10-02"
sponsor_setup:
sponsor_model: "Sponsor-Investigator"
sponsor:
name: "Inselspital Bern"
coordinating_investigator:
name: "Dr. A. Example"
medical_device:
name: "MRSI-X Software + Dual-Tuned Head Coil"
manufacturer:
name: "Lab ABC"
mdr_class: "IIa"
mdr_rule: "11"
categorisation:
rationale: "Investigational use beyond CE intended purpose (software affects diagnosis)."
synopsis:
primary_objective: "Assess feasibility and data quality of MRSI-X."
primary_endpoint: "Acquisition success rate per subject."
sample_size_total: 15
sample_size_rationale: "Feasibility sample; precision target ±10%."
population:
inclusion_criteria:
- "Adults 18–80"
exclusion_criteria:
- "MRI contraindications"
procedures:
visit_schedule:
- visit_id: "V1"
name: "Baseline & Imaging"
window: "Day 0"
procedures: ["Consent","Safety check","MR scan","Questionnaire"]
- visit_id: "V2"
name: "Follow-up"
window: "Day 14 ±3"
procedures: ["AE check"]
safety:
path: "C"
reporting:
to_sponsor_hours:
sae: 24
data_quality_privacy:
archiving_period_years: 10
ethics_and_regulatory:
patient_information_icf_plan: "Single IC at V1; lay summary provided."
insurance:
provider: "Swiss Research Insurance AG"
publication_and_dissemination:
plan: "Authorship per ICMJE; preprint & code repository after acceptance."
signatures:
sponsor:
name: "Inselspital Bern"
revision_history:
- version: "1.0"
date: "2025-10-02"
registration:
primary_registry: "BASEC-Human Research"
registry_id: "TBD-HumRes"
Full scaffold (copy & adapt)
Use this when starting from scratch. Delete rows you do not use and fill all placeholders. Add not_applicable: true only when a whole subsection truly does not apply.
meta:
schema_version: "1.0"
jurisdiction:
track: CH # CH | EU | CH+EU | Other
ch:
clinO_MD_category: C1 # A1/A2/C1/C2/C3
swissmedic_involved: false # must be true if safety.path == "C"
basec_lead_ec: ""
eu:
lead_member_state: ""
sponsor_srn: ""
manufacturer_srn: ""
eudamed_civ_id: "" # optional but recommended
other:
authority_name: "" # only if track == Other
identification:
full_title: ""
short_title: ""
investigation_id: ""
cip_version: ""
cip_date: "YYYY-MM-DD"
sponsor_setup:
sponsor_model: "" # e.g., Sponsor, Sponsor-Investigator
sponsor:
name: ""
address: ""
coordinating_investigator:
name: ""
affiliation: ""
statistician:
name: "" # required unless not_applicable:true
not_applicable: false
medical_device:
name: ""
description: ""
manufacturer:
name: ""
ce_marked: false
intended_purpose: ""
investigational_use_description: ""
mdr_class: "" # e.g., IIa
mdr_rule: "" # e.g., 11
radiation_exposure:
applicable: false
details: "" # required if applicable:true
categorisation:
rationale: "" # explain investigational/off-label basis
synopsis:
primary_objective: ""
secondary_objectives: []
primary_endpoint: ""
secondary_endpoints: []
sample_size_total: 0
sample_size_rationale: ""
population:
inclusion_criteria: []
exclusion_criteria: []
procedures:
visit_schedule: [] # one or more visits; see example below
safety:
path: "A" # "A" or "C"
reporting:
to_sponsor_hours:
sae: 24 # integer hours to notify sponsor
stopping_rules: ""
device_deficiencies: "Recorded and reported per plan."
data_quality_privacy:
monitoring_plan: ""
audits: "As needed."
inspector_access: "Permitted."
archiving_period_years: 10
data_privacy_plan: "Pseudonymization, secure transfer, controlled access."
ethics_and_regulatory:
patient_information_icf_plan: ""
lay_summary_plan: "To be published post-study."
insurance:
provider: ""
publication_and_dissemination:
plan: ""
registration:
primary_registry: ""
registry_id: ""
signatures:
sponsor:
name: ""
revision_history:
- version: ""
date: "YYYY-MM-DD"
Field-by-field guide — Core (all jurisdictions)
| Path | Type | What to enter | Role / meaning | Required? |
|---|---|---|---|---|
meta.schema_version |
string | "1.0" |
Enables the validator to apply the correct rule set. | Yes |
jurisdiction.track |
enum | CH | EU | CH+EU | Other |
Drives which skeleton and checks are applied. | Yes |
identification.full_title |
string | Exact CIP title. | Appears on title page, approvals, and registry. | Yes |
identification.investigation_id |
string | Protocol/CIP ID (e.g., MRSI7T-001). |
Primary identifier across documents. | Yes |
identification.cip_version |
string | Version label (e.g., 1.0). |
Change control and signatures. | Yes |
identification.cip_date |
date | YYYY-MM-DD |
Version date printed on all pages. | Yes |
sponsor_setup.sponsor_model |
string | “Sponsor” or “Sponsor-Investigator”. | Clarifies roles and responsibilities. | Yes |
sponsor_setup.sponsor.name |
string | Legal sponsor name. | Used in signatures, insurance, and regulatory forms. | Yes |
sponsor_setup.coordinating_investigator.name |
string | CI/PI name. | Operational lead identified in CIP. | Yes |
medical_device.name |
string | Device/system name (e.g., software + coil). | Defines the investigational product. | Yes |
medical_device.manufacturer.name |
string | Manufacturer entity. | Links to SRN (EU) and responsibilities. | Yes |
medical_device.mdr_class |
string | e.g., IIa. |
Determines oversight and documentation depth. | Yes |
medical_device.mdr_rule |
string | MDR rule (e.g., 11). |
Justifies the class. | Yes |
categorisation.rationale |
string | Why the use is investigational/off-label. | Makes the legal basis explicit. | Yes |
synopsis.primary_objective |
string | Single, measurable objective. | Aligns endpoints and sample size. | Yes |
synopsis.primary_endpoint |
string | One endpoint mapped to the objective. | Focus for analysis and feasibility. | Yes |
synopsis.sample_size_total |
integer ≥ 1 | Total participants planned. | Power/precision or feasibility framing. | Yes |
synopsis.sample_size_rationale |
string | Logic/assumptions for N. | Reviewer expects clear justification. | Yes |
population.inclusion_criteria |
list | Bullet list; each item as a YAML string. | Eligibility definition. | Yes |
population.exclusion_criteria |
list | Bullet list. | Safety/feasibility boundaries. | Yes |
procedures.visit_schedule |
list of objects | At least one visit with name/window/procedures. | Becomes the CIP schedule table and narrative. | Yes (≥1) |
safety.path |
enum | "A" or "C" |
Determines Swissmedic involvement and reporting. | Yes |
safety.reporting.to_sponsor_hours.sae |
integer | e.g., 24 |
Max time to notify sponsor for SAEs. | Yes |
data_quality_privacy.archiving_period_years |
integer | e.g., 10 |
Records retention commitment. | Yes |
ethics_and_regulatory.patient_information_icf_plan |
string | How/when IC is obtained; language; attachments. | Informs EC review and participant protection. | Yes |
insurance.provider |
string | Insurer or institutional coverage. | Mandatory for participant protection. | Yes |
publication_and_dissemination.plan |
string | Authorship, timeline, data/code sharing. | Transparency & dissemination expectations. | Yes |
signatures.sponsor.name |
string | Name to appear on signature page. | Confirms sponsor accountability. | Yes |
revision_history[0].version & date |
string & date | Initial entry for vX.Y and date. | Starts the change log. | Yes |
Field-by-field guide — CH specific
| Path | Type | What to enter | Role / meaning | Required if track=CH/CH+EU? |
|---|---|---|---|---|
jurisdiction.ch.clinO_MD_category |
enum | A1/A2/C1/C2/C3 |
Swiss ClinO-MD categorization. | Yes |
jurisdiction.ch.swissmedic_involved |
bool | true if safety.path = C |
Triggers CA involvement for Path C. | Yes (must be true for Path C) |
jurisdiction.ch.basec_lead_ec |
string | Name of lead EC (e.g., KEK BE). | Needed for BASEC submission. | Yes |
registration.primary_registry |
string | e.g., “BASEC-Human Research”. | Registry planning; warning if empty. | Recommended |
registration.registry_id |
string | e.g., “HumRes-placeholder”. | Can be placeholder before approval. | Recommended |
Field-by-field guide — EU specific
| Path | Type | What to enter | Role / meaning | Required if track=EU/CH+EU? |
|---|---|---|---|---|
jurisdiction.eu.lead_member_state |
string | One MS (e.g., “NL”). | Centralizes assessment under MDR Art. 78. | Yes |
jurisdiction.eu.sponsor_srn |
string | Sponsor SRN (e.g., CH-123456-S). |
Identity in EUDAMED. | Yes |
jurisdiction.eu.manufacturer_srn |
string | Manufacturer SRN. | Manufacturer identity. | Yes |
jurisdiction.eu.eudamed_civ_id |
string | Clinical investigation (CIV) ID if assigned. | Optional but recommended; warning if missing. | Recommended |
Conditional & cross-field logic the validator enforces
- If
safety.path="C"andjurisdiction.trackincludes CH →jurisdiction.ch.swissmedic_involvedmust be true. - If
medical_device.ce_marked=trueand use is beyond the intended purpose →categorisation.rationalemust explicitly state investigational/off-label basis. - If
statistician.not_applicableis not true →sponsor_setup.statistician.nameis required. - If
medical_device.radiation_exposure.applicable=true→…detailsis required. - Visit schedule: must contain ≥ 1 visit object; each should include a human-readable window and list of procedures.
Visit schedule — compact example
procedures:
visit_schedule:
- visit_id: "SCR"
name: "Screening"
window: "Day −14 to −1"
procedures: ["Consent","Eligibility","Safety checklist"]
- visit_id: "BL/IMG"
name: "Baseline + Imaging"
window: "Day 0"
procedures: ["Vitals","MR scan (no contrast)","Questionnaire"]
- visit_id: "FU"
name: "Follow-up"
window: "Day 14 ±3"
procedures: ["AE query","Device deficiency review"]
Typical validation errors & how to fix
- Missing schema version: Add
meta.schema_version: "1.0". - Unknown jurisdiction: Set
jurisdiction.trackto one ofCH,EU,CH+EU,Other. - Empty required fields: Replace
""/[]/nullwith real values. Do not mark single fields asnot_applicableunless the whole subsection is truly not applicable. - Sample size zero: Set
synopsis.sample_size_totalto ≥ 1 and justify in…rationale. - Path C without Swissmedic: Set
jurisdiction.ch.swissmedic_involved: true. - Radiation applicable but details missing: Fill
medical_device.radiation_exposure.details. - No visits defined: Add at least one item under
procedures.visit_schedule.
Before you upload — quick checklist
- Dates use
YYYY-MM-DD; indentation is consistent. meta.schema_versionis exactly"1.0".- Jurisdiction track selected; CH/EU extras completed.
- Device class & rule present; categorisation rationale clear.
- Objective, endpoint, sample size & rationale filled.
- Inclusion & exclusion lists populated.
- Visit schedule present (≥ 1 visit).
- Safety path set; SAE reporting hours set.
- Archiving period, ICF plan, insurance provider, publication plan present.
- Sponsor signature name present; first revision row completed.
FAQ
Can I leave optional fields blank?
Yes, but empty values like "" or [] are treated as missing and may produce warnings. Use not_applicable: true only for whole subsections that truly do not apply.
Do I need the Scientific/Research Plans to validate?
No. They are required only for drafting CIP sections. Validation and skeleton generation can run with the YAML alone.
What if my device is CE-marked but I am changing indications or workflow?
That is typically investigational use. State this clearly in categorisation.rationale and ensure your endpoints and risk mitigations match the change.
How detailed should the visit procedures be?
Enough to generate a usable schedule table and narrative (e.g., consent, safety checks, MR scan parameters at a high level, data capture forms, AE checks).