optionality of response values was registered both in the description and via the `required: ` key.

Removed the `*OPTIONAL*` in the descriptions.

schemas/med_dossier/Contraindication.yaml

@@ -13,7 +13,7 @@ properties:
     example: 'RAYNAUD, FENOMEEN'
   when:
     description: |-
-      *OPTIONAL* If present, the date when this contraindication was registered.
+      If present, the date when this contraindication was registered.
     type: string
     format: date
     example: "2019-02-05"

schemas/med_dossier/Correspondence.yaml

@@ -31,7 +31,7 @@ properties:
     example: KNO
   episode:
     description: |-
-      *OPTIONAL* An ICPC code (formatted as e.g. `X99.12`) representing the problem or chronic illness that serves as context for this correspondence.
+      An ICPC code (formatted as e.g. `X99.12`) representing the problem or chronic illness that serves as context for this correspondence.
       
       Not all correspondence can be directly related to an ICPC code, and many source systems fundamentally do not allow linking correspondence to
       a given medical issue. Hence, this field is usually blank.

schemas/med_dossier/Episode.yaml

@@ -26,7 +26,7 @@ properties:
     example: 1900-01-01
   end:
     description: |-
-      *OPTIONAL* If the episode has been determined to no longer be relevant (for example, cured), the date when the episode was closed.
+      If the episode has been determined to no longer be relevant (for example, cured), the date when the episode was closed.
     type: string
     format: date
     example: "2022-12-31"
@@ -39,7 +39,7 @@ properties:
     example: "2022-10-20"
   description:
     description: |-
-      *OPTIONAL* Most HIS source systems default the 'description' of an episode to the standard description for the provided ICPC, but allow the
+      Most HIS source systems default the 'description' of an episode to the standard description for the provided ICPC, but allow the
       practitioner to change this description.
     type: string
     example: "Geboorte dochter"

schemas/med_dossier/Feat.yaml

@@ -23,7 +23,7 @@ properties:
     example: "2023-02-28"
   invoice:
     description: |-
-      *OPTIONAL* If this feat has been declared, the invoice id that declared it. Not all source systems track this, and generally
+      If this feat has been declared, the invoice id that declared it. Not all source systems track this, and generally
       invoices aren't instantly sent as feats are registered. Thus, if this field isn't provided, either the feat hasn't been invoiced yet,
       or the source system doesn't track invoicing, or the GP office doesn't use the source system for invoicing.
     type: string

schemas/med_dossier/Journal.yaml

@@ -6,7 +6,7 @@ required:
 properties:
   icpc:
     description: |-
-      *OPTIONAL* An ICPC1.1-NL code representing the nature of this journal note. Does not necessarily mean the patient suffers from the condition
+      An ICPC1.1-NL code representing the nature of this journal note. Does not necessarily mean the patient suffers from the condition
       this ICPC represents. For example, a patient that comes in asking questions about signs of Diabetes would have journal text with ICPC `"T90.02"`,
       even if tests show they clearly do not have Diabetes Mellitus.
       
@@ -16,7 +16,7 @@ properties:
     example: "A97.00"
   episode:
     description: |-
-      *OPTIONAL* An ICPC1.1-NL code representing the problem / chronic illness that this journal note has been filed under.
+      An ICPC1.1-NL code representing the problem / chronic illness that this journal note has been filed under.
       
       In our experience the difference between `icpc` and `episode` are not well demarkated and practitioners do not necessarily use these fields
       for their intended purpose. We suggest making no distinction between these 2 fields and accepting instead that this means journal text
@@ -84,7 +84,7 @@ properties:
     example: C
   code:
     description: |-
-      *OPTIONAL* If present, a short code representing a specific kind of action, such as a referral (`VER` - from dutch _Verwijzing_),
+      If present, a short code representing a specific kind of action, such as a referral (`VER` - from dutch _Verwijzing_),
       `H` for medication recipe refill (dutch: _Herhaalrecept_), `REC` for prescribing a recipe, `LAB` for processing laboratory results,
       or `BVO` for a nationally organized checkup such as for Cervical Cancer (from dutch: _Bevolkingsonderzoek_).
       

schemas/med_dossier/Measurement.yaml

@@ -28,7 +28,7 @@ properties:
     example: KREAOMK
   source_code:
     description: |-
-      *OPTIONAL* If the source system uses a different code to represent this measurement in its own system, it is listed here.
+      If the source system uses a different code to represent this measurement in its own system, it is listed here.
       
       If present, guaranteed to be different from `nhg_code`. For example, a HIS might use `ROKENHG` instead of NHG-standard `ROOKAQ` to
       represent registration of patient's smoking behaviour.
@@ -58,7 +58,7 @@ properties:
     example: 48
   comment:
     description: |-
-      *OPTIONAL* Some source systems allow adding a comment to any measurement; if one is present, it is provided here.
+      Some source systems allow adding a comment to any measurement; if one is present, it is provided here.
       
       Note that these can be quite lengthy, as sometimes a lab will add standard boilerplate text about how to interpret
       the result in these fields.

schemas/med_dossier/Medication.yaml

@@ -52,17 +52,17 @@ properties:
     example: "CUTISOFT NWK ST 10X10 48851"
   pharmacy:
     description: |-
-      *OPTIONAL* If automatically sent to a specific pharmacy, some source-system custom coding that indicates which pharmacy it was sent to.
+      If automatically sent to a specific pharmacy, some source-system custom coding that indicates which pharmacy it was sent to.
     type: string
     example: AN
   usageCode:
     description: |-
-      *OPTIONAL* A coded description of how to use this medication. Depends on source HIS software; sometimes even on the individual configuration of
+      A coded description of how to use this medication. Depends on source HIS software; sometimes even on the individual configuration of
       a practice's HIS or that practice's regional server; these values aren't normalized, and sometimes not available at all.
     type: string
     example: 1D1T
   usageText:
     description: |-
-      *OPTIONAL* Human-readable (dutch) description of how to use this medication. Depends on source HIS software and often not available at all.
+      Human-readable (dutch) description of how to use this medication. Depends on source HIS software and often not available at all.
     type: string
     example: Gebruik bekend