Generated Narrative: StructureDefinition bcr-follow-up-form Name Flags Card. Type Description & Constraints <a href="StructureDefinition-bcr-follow-up-form-definitions.html#bcr-follow-up-form" title="Logical model of the cancer registration follow-up form. Submitted to BCR#xA;at each follow-up MOC or disease event after the initial registration.#xA;Captures the primary tumour reference, recurrence information, the planned#xA;treatment for the current problem, and the reason for the follow-up MOC.#xA;#xA;Source: Bijlage 55 (vervolg 3) of the RIZIV Verordening of 28 July 2003,#xA;amended 15 December 2025.">bcr-follow-up-form 0..* Base BCR Follow-Up Form — Bijlage 55 vervolg 3 (Logical Model) #xD; patientName 1..1 string Patient name #xD; birthDate 1..1 date Date of birth #xD; nationalOrInsuranceNumber 1..1 string INSZ / Ziekenfondsnummer #xD; sex 1..1 code Sex Binding: BCR Sex at Birth (required) #xD; primaryTumourLocation 1..1 code Primary tumour localisation Binding: BCR ICD-O-3 Topography (extensible) #xD; primaryTumourHistology 1..1 code Primary tumour histology Binding: BCR ICD-O-3 Morphology (extensible) #xD; primaryTumourIncidenceDate 0..1 date Primary tumour incidence date #xD; diseaseFreeInterval 0..1 boolean Disease-free interval #xD; firstRecurrenceDate 0..1 date Date of first recurrence #xD; recurrenceType 0..* code Recurrence type Binding: BCR Recurrence Type (required) #xD; <a href="StructureDefinition-bcr-follow-up-form-definitions.html#bcr-follow-up-form.intendedTreatment" title="Intent-to-treat code(s), filled in chronologically. Codes:#xA;10 = surgery; 15 = bone marrow transplant;#xA;20 = external radiotherapy / brachytherapy;#xA;25 = concurrent chemoradiotherapy;#xA;30 = radio-isotopes;#xA;40 = chemotherapy; 50 = hormonal therapy; 60 = immunotherapy;#xA;70 = symptomatic; 80 = other treatment (specify in `intendedOtherTreatment`);#xA;90 = no therapy; 95 = treatment refusal.">intendedTreatment 0..* code Intended treatment Binding: BCR Intended Treatment Code (required) #xD; intendedOtherTreatment 0..1 string Other intended treatment #xD; <a href="StructureDefinition-bcr-follow-up-form-definitions.html#bcr-follow-up-form.followUpMocReason" title="Reason(s) for convening the follow-up MOC. Codes:#xA;RECURRENCE = treatment of a patient with a recurrence;#xA;PROGRESSION = treatment of a patient with progressive disease;#xA;GUIDELINE_DEVIATION = before oncological treatment deviating from accepted guidelines;#xA;REPEAT_RADIATION = before a repeat irradiation of the same target area within twelve months;#xA;CTG_DRUG = before chemotherapy with a drug flagged for MOC monitoring by the Commissie Tegemoetkoming Geneesmiddelen;#xA;OTHER = other (specify in `followUpMocOtherReason`).">followUpMocReason 0..* code Follow-up MOC reason Binding: BCR Follow-Up MOC Reason (required) #xD; followUpMocOtherReason 0..1 string Other follow-up MOC reason #xD; coordinator 0..1 BackboneElement Coordinating physician #xD; name 1..1 string Name #xD; rizivNumber 1..1 string RIZIV number #xD; institution 1..1 string Institution #xD; signatureDate 1..1 date Signature date #xD; Documentation for this format
BCR Follow-Up Form — Bijlage 55 vervolg 3 (Logical Model)
Logical model of the cancer registration follow-up form. Submitted to BCR at each follow-up MOC or disease event after the initial registration. Captures the primary tumour reference, recurrence information, the planned treatment for the current problem, and the reason for the follow-up MOC. Source: Bijlage 55 (vervolg 3) of the RIZIV Verordening of 28 July 2003, amended 15 December 2025.
Belgian national number (INSZ/NISS) or insurance fund number.
ICD-O-3 topography of the primary tumour.
ICD-O-3 morphology / behaviour of the primary tumour.
Date of incidence (DD-MM-YYYY). The form notes that *the year alone is sufficient if the full date is not traceable*.
Indicates whether a disease-free interval was present (Ja / Nee).
Date of first recurrence — recorded only when a disease-free interval was present.
Type(s) of recurrence (multiple allowed). Codes: LOCAL, REGIONAL, METASTATIC.
Intent-to-treat code(s), filled in chronologically. Codes: 10 = surgery; 15 = bone marrow transplant; 20 = external radiotherapy / brachytherapy; 25 = concurrent chemoradiotherapy; 30 = radio-isotopes; 40 = chemotherapy; 50 = hormonal therapy; 60 = immunotherapy; 70 = symptomatic; 80 = other treatment (specify in `intendedOtherTreatment`); 90 = no therapy; 95 = treatment refusal.
Free-text description of the treatment when code 80 is selected.
Reason(s) for convening the follow-up MOC. Codes: RECURRENCE = treatment of a patient with a recurrence; PROGRESSION = treatment of a patient with progressive disease; GUIDELINE_DEVIATION = before oncological treatment deviating from accepted guidelines; REPEAT_RADIATION = before a repeat irradiation of the same target area within twelve months; CTG_DRUG = before chemotherapy with a drug flagged for MOC monitoring by the Commissie Tegemoetkoming Geneesmiddelen; OTHER = other (specify in `followUpMocOtherReason`).
Free-text reason when `followUpMocReason` includes OTHER.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Extensions are always sliced by (at least) url
Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Must have either extensions or value[x], not both
exists(f:extension)!=exists(f:*[starts-with(local-name(.), "value")])
Extensions that cannot be ignored even if unrecognized
May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Modifier extensions allow for extensions that *cannot* be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the [definition of modifier extensions](http://hl7.org/fhir/R4/extensibility.html#modifierExtension).
Modifier extensions are expected to modify the meaning or interpretation of the element that contains them