known-issues.yml

---
# The issues here are deliberate deviations from the guidelines, as flagged by the qa tooling.
# For each issue documented, a reason for deviating from the guidelines is given.

ext-AdvanceDirective.Disorder:
  zib deviations:
    Extension.value[x]:
      - cardinality: 0..1 instead of 0..*
        reason: FHIR restricts Extension.value to a max cardinality of 0..1. To use it more than once, the extension is added 0..* in the hosting element.

ext-LanguageProficiency.CommunicationDetails:
  zib deviations:
    Extension.value[x]:
      - cardinality: 0..1 instead of 0..*
        reason: FHIR restricts Extension.value to a max cardinality of 0..1. To use it more than once, the extension is added 0..* in the hosting element.

ext-Procedure.ProcedureMethod:
  zib deviations:
    Extension.value[x]:
      - cardinality: 0..1 instead of 0..*
        reason: FHIR restricts Extension.value to a max cardinality of 0..1. To use it more than once, the extension is added 0..* in the hosting element. 

ext-TreatmentDirective2.AdvanceDirective:
  zib deviations:
    Extension.value[x]:
      - cardinality: 0..1 instead of 0..*
        reason: FHIR restricts Extension.value to a max cardinality of 0..1. To use it more than once, the extension is added 0..* in the hosting element.

nl-core-HearingFunction.HearingAid.Product:
  ignored issues:
    Device:
      - message: The slice definition for Device.identifier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
      - message: The slice definition for Device.udiCarrier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.

nl-core-HelpFromOthers:
  ignored issues:
    CarePlan:
      - message: The slice definition for CarePlan.activity.detail.performer has a maximum of 1 but the slices add up to a maximum of 3. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.

nl-core-MedicalDevice.Product:
  ignored issues:
    Device:
      - message: The slice definition for Device.identifier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
      - message: The slice definition for Device.udiCarrier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.

nl-core-NursingIntervention:
  ignored issues:
    CarePlan:
      - message: The slice definition for CarePlan.activity.detail.performer has a maximum of 1 but the slices add up to a maximum of 3. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
        
nl-core-VisualFunction.VisualAid.Product:
  ignored issues:
    Device:
      - message: The slice definition for Device.identifier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
      - message: The slice definition for Device.udiCarrier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.

nl-core-Wound.Drain.Product:
  ignored issues:
    Device:
      - message: The slice definition for Device.identifier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
      - message: The slice definition for Device.udiCarrier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.

pattern-GstdSimpleQuantity:
  ignored issues:
    StructureDefinition:
      - message: "Constraint failed: sd-pg-08: 'The title of the StructureDefinition should conform to the profiling guidelines'"
        reason: The title is shown in the hosting profiles as the name of the datatype. "G-Standard SimpleQuantity" is more descriptive than the title according to the profiling guidelines ("pattern GstdSimpleQuantity").

pattern-GstdQuantity: 
  ignored issues:
    StructureDefinition:
      - message: "Constraint failed: sd-pg-08: 'The title of the StructureDefinition should conform to the profiling guidelines'"
        reason: The title is shown in the hosting profiles as the name of the datatype. "G-Standard Quantity" is more descriptive than the title according to the profiling guidelines ("pattern GstdQuantity").

pattern-NlCoreHealthProfessionalReference:
  ignored issues:
    StructureDefinition:
      - message: "Constraint failed: sd-pg-08: 'The title of the StructureDefinition should conform to the profiling guidelines'"
        reason: The title is shown in the hosting profiles as the name of the datatype. "zib HealthProfessional Reference" is more descriptive than the title according to the profiling guidelines ("pattern NlCoreHealthProfessionalReference").

pattern-VitalSigns:
  ignored issues:
    Observation.category:VSCat:
      - message: "Constraint failed: sd-pg-13: 'Slice names should be camelCased starting with a lowercase letter.'"
        reason: This slice name is adopted from the Vital Signs profile.

pattern-ZibHealthProfessionalReference:
  ignored issues:
    StructureDefinition:
      - message: "Constraint failed: sd-pg-08: 'The title of the StructureDefinition should conform to the profiling guidelines'"
        reason: The title is shown in the hosting profiles as the name of the datatype. "zib HealthProfessional Reference" is more descriptive than the title according to the profiling guidelines ("pattern ZibHealthProfessionalReference").

zib-AbilityToDrink.DrinkingLimitations:
  zib deviations:
      Observation.value[x]:valueCodeableConcept:
      - cardinality: 0..1 instead of 0..*
        reason: The value can only occur once, but this profile is referenced 0..* times via .hasMember, making the effective cardinality 0..* as required by the zib.

zib-AbilityToEat.EatingLimitations:
  zib deviations:
      Observation.value[x]:valueCodeableConcept:
      - cardinality: 0..1 instead of 0..*
        reason: The value can only occur once, but this profile is referenced 0..* times via .hasMember, making the effective cardinality 0..* as required by the zib.

zib-AbilityToUseToilet:
  zib deviations:
      Observation:
      - short: AbilityToUseToilet instead of ToiletUseAbility
        reason: The root of the zib is called "ToiletUseAbility" (which is incorrect), even though the zib itself is called "AbilityToUseToilet".

zib-AbilityToGroom:
  zib deviations:
    Observation:
      - short: AbilityToGroom instead of AbilityToGroome
        reason: The root of the zib is called "AbilityToGroome" (which is incorrect), even though the zib itself is called "AbilityToGroom".

zib-AddressInformation:
  zib deviations:
    Address.line.extension:houseNumberIndication.value[x]:
      - datatype: string instead of CD
        reason: The mapping of zib AddressInformation on the FHIR Address datatype is the result of compatibility with HL7v3, which is the format that a lot of healthcare data in the Netherlands is stored in. As a result of this, the zib concept HouseNumberIndication with CD datatype is mapped to a FHIR string datatype with a constraint added (the value can only be 'by' or 'to').
    Address.line.extension:*.value[x]:
      - cardinality: 1..1 instead of 0..1
        reason: The value of the extension is required, but the extension itself is optional, making the effective cardinality 0..1 as required by the zib.

zib-AdvanceDirective:
  zib deviations:
    Consent.provision.actor:representative.reference:
      - cardinality: 1..1 instead of 0..1
        reason: Consent.provision.actor:representative has cardinality 0..1, making the cardinality of Consent.provision.actor:representative.reference effectively 0..1 as required by the zib.

zib-AllergyIntolerance:
  zib deviations:
    AllergyIntolerance.reaction.manifestation:
      - cardinality: 1..* instead of 0..*
        reason: The FHIR profiles are expected to implement zib cardinalities as conceptual cardinalities, but FHIR requires the .manifestation element to be present. This aligns with the intention of the zib, as the Symptom concept is required for the container Reaction to make sense.
  ignored issues:
    AllergyIntolerance.reaction:
      - message: "Constraint failed: sd-pg-03: 'If mapping.map exists and the mapping is not implicit and the element is not the root element, definition should exist.'"
        reason: The mapping is to a zib container, which doesn't have a useful description if implemented in a profile.

zib-ApgarScore-*Minute:
  zib deviations:
    Observation.component:muscleToneScore.value[x]:
      - short: MuscleToneScore instead of MusleToneScore
        reason: The zib concept name "MusleToneScore" is an incorrect translation of the Dutch name into English.

zib-BloodPressure:
  ignored issues:
    Observation.component:*BP:
      - message: "Constraint failed: sd-pg-13: 'Slice names should be camelCased starting with a lowercase letter.'"
        reason: The slices "SystolicBP" and "DiastolicBP" start with an uppercase letter to align with the HL7 Vital Signs profile.

zib-BodyTemperature:
  ignored issues:
    Observation.code.coding:BodyTempCode:
      - message: "Constraint failed: sd-pg-13: 'Slice names should be camelCased starting with a lowercase letter.'"
        reason: The slice name "BodyTempCode" is chosen to align with the Vital Signs profile for BodyTemperature.
        
zib-Burnwound:
  zib deviations:
    Condition:
      - short: Burnwound instead of BurnWound
        reason: The root of the zib is called "BurnWound", even though the zib itself is called "Burnwound" (which is incorrect).
    Condition.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.
  ignored issues:
    Condition.bodySite.extension:laterality.value[x]:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is defined in the extension profile and therefore not defined in the differential.
      - message: "Constraint failed: sd-pg-03: 'If mapping.map exists and the mapping is not implicit and the element is not the root element, definition should exist.'"
        reason: The definition is defined in the extension profile and therefore not defined in the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias is defined in the extension profile and therefore not defined in the differential.
        
zib-CareTeam:
  zib deviations:
    CareTeam.name:
      - short: CareTeamName instead of CareTeamNaam
        reason: The zib concept name "CareTeamNaam" is an incorrect translation of the Dutch name into English.
    CareTeam.participant:healthcareProfessional.member:
      - cardinality: 1..1 instead of 0..1
        reason: The cardinality of each CareTeamMember option is defined by the cardinality of the slices on participant and thus the cardinality requirements of the zib are honored. Because .member is required to discriminate the slices, its cardinality is 1..1. 

zib-ContactInformation-TelephoneNumbers:
  zib deviations:
    ContactPoint.system:
      - cardinality: 1..1 instead of 0..1
        reason: Although TelecomType and NumberType are optional in the zib, ContactPoint.system is used to identify the TelephoneNumbers concept itself when this datatype is added to a profile. If only a telephone number is given without TelecomType and NumberType, this will fall in the default slice of the profile.

zib-ContactPerson:
  zib deviations:
    RelatedPerson.name*:
      - datatype: HumanName instead of a reference
        reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
    RelatedPerson.name:
      - cardinality: 0..* instead of 0..1
        reason: The name information according to zib NameInformation may be split up over multiple instances of RelatedPerson.name.
    RelatedPerson.address:
      - datatype: Address instead of a reference
        reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
    RelatedPerson.telecom:
      - datatype: ContactPoint instead of a reference
        reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource.
      - cardinality: 0..* instead of 0..1
        for: NL-CM:3.1.6 (ContactPerson.ContactInformation)
        reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib part ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
    RelatedPerson.telecom:*:
      - datatype: ContactPoint instead of a reference
        reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource.
  additional notes:
    RelatedPerson.telecom: Although there is a cardinality mismatch for the mapping of zib concept ContactPerson.ContactInformation on this element (as pointed out above), the cardinalities between zib and FHIR do match for the mapping of zib concept Payer.ContactInformation (NL-CM:1.1.12), as these are both 0..*.

zib-Encounter:
  zib deviations:
    Encounter.class:
      - cardinality: 1..1 instead of 0..1
        reason: Encounter.class is mandatory in FHIR. The cardinality matches the cardinality in the zib, however, it does not match with the conceptual cardinality concept. This should not be a major problem.
    Encounter.participant:healthProfessional.individual:
      - cardinality: 0..1 instead of 0..*
        reason: The cardinality mismatch between the zib (0..*) and FHIR (0..1) is explained by the parent participant element that may exist 0..* times, thereby this mapping is still honoring the cardinality requirements of the zib.
    Encounter.reasonReference:*:
      - cardinality: 0..* instead of 0..1 
        reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing ContactReason container in FHIR. This container may exist 0..* times, thereby this mapping is still honoring the cardinality requirements of the zib.
    Encounter.reasonReference.extension:commentContactReason.value[x]:
      - cardinality: 0..* instead of 0..1
        reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*, effective) is explained by the missing ContactReason container in FHIR. This container may exist 0..* times, thereby this mapping is still honoring the cardinality requirements of the zib.

zib-FLACCpainScale:
  zib deviations:
   Observation:
      - short: FLACCpainScale instead of FLACCpainScore
        reason: The root of the zib is called "FLACCpainScore" (which is incorrect), even though the zib itself is called "FLACCpainScale".

zib-FreedomRestrictingIntervention:
  zib deviations:
    Procedure:
      - short: FreedomRestrictingIntervention instead of FreedomrestrictingIntervention
        reason: The root of the zib is called "FreedomrestrictingIntervention" (which is incorrect), even though the zib itself is called "FreedomRestrictingIntervention".

zib-FunctionalOrMentalStatus:
  zib deviations:
    Observation.code:
      - cardinality: 1..1 instead of 0..1
        reason: The FHIR profiles are expected to implement zib cardinalities as conceptual cardinalities, but FHIR requires the Observation.code element to be present. This aligns with the intention of the zib, as the StatusName concept is required for zib FunctionalOrMentalStatus to make sense. 

zib-HealthcareProvider:
  zib deviations:
    Location.address:
      - datatype: Address instead of a reference
        reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
      - cardinality: 0..1 instead of 0..*
        reason: The cardinality mismatch between the zib (0..*) and FHIR (0..1) is explained by the restriction of FHIR to limit the Location.address to a physical address while the zib allows for other types of addresses (e.g. a postal address). Other types of addresses than a physical address are given in Organization.address which is referenced by Location.managingOrganization. More documentation can be found at https://github.com/Nictiz/Nictiz-R4-zib2020/issues/38.
    Location.telecom:
      - cardinality: 0..* instead of 0..1
        reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib part ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
    Location.telecom*:
      - datatype: ContactPoint instead of a reference
        reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource. Because the FHIR profile for ContactInformation consists of two parts the root concept of ContactInformation is mapped on .telecom.

zib-HealthProfessional-Practitioner:
  zib deviations:
    Practitioner.name*:
      - datatype: HumanName instead of a reference
        reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
    Practitioner.name:
      - cardinality: 0..* instead of 0..1
        reason: The name information according to zib NameInformation may be split up over multiple instances of Practitioner.name. 
    Practitioner.telecom:
      - cardinality: 0..* instead of 0..1
        reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib part ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
    Practitioner.telecom*:
      - datatype: ContactPoint instead of a reference
        reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource. Because the FHIR profile for ContactInformation consists of two parts the root concept of ContactInformation is mapped on .telecom.
    Practitioner.address:
      - datatype: Address instead of a reference
        reason: An address in FHIR is represented using the Address datatype, not as a separate resource.

zib-HealthProfessional-PractitionerRole:
  zib deviations:
    PractitionerRole.telecom:
      - cardinality: 0..* instead of 0..1
        reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib part ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
    PractitionerRole.telecom*:
      - datatype: ContactPoint instead of a reference
        reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource. Because the FHIR profile for ContactInformation consists of two parts the root concept of ContactInformation is mapped on .telecom.

zib-HearingFunction.HearingAid:
  zib deviations:
    DeviceUseStatement:
      - datatype: undefined
        reason: In FHIR, the reference to the MedicalDevice points in the other direction (so the MedicalDevice refers to HearingFunction). The MedicalDevice reference is however mapped on the root element that represents this zib rather than on DeviceUseStatement.reasonReference resulting in an unmatched datatype.
    DeviceUseStatement.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.
    DeviceUseStatement.timing[x]:timingPeriod.end:
      - short: EndDate instead of EindDatum
        reason: The zib concept name "EindDatum" has not been translated into English.

zib-HearingFunction.HearingAid.Product:
  ignored issues:
    Device:
      - message: The slice definition for Device.identifier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
      - message: The slice definition for Device.udiCarrier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
    Device.type:
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias for ProductType is already present in the base profile where this profile is derived from. It should not be added twice to silence this issue.
  zib deviations:
    Device.identifier:*ProductID:
      - datatype: Identifier instead of CD compatible datatype
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the mapping of the concept to FHIR will not match on a datatype level.
    Device.udiCarrier:*UdiCarrier.carrierHRF:
      - datatype: string instead of CD compatible datatype
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the mapping of the concept to FHIR will not match on a datatype level.

zib-HelpFromOthers:
  ignored issues:
    CarePlan:
      - message: The slice definition for CarePlan.activity.detail.performer has a maximum of 1 but the slices add up to a maximum of 3. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.

zib-LaboratoryTestResult:
  zib deviations:
    Observation.status:
      - cardinality: 1..1 instead of 0..1
        reason: Although the equivalent concept is optional in the zib, this element is required in FHIR.
    Observation.code:
      - cardinality: 1..1 instead of 0..1
        reason: This element is mapped to the concepts PanelOrBattery and TestCode at the same time. PanelOrBattery is marked as optional in the zib, but this is strictly not true; it must be absent if the zib instantiates a singular laboratory test, but is required if the zib instantiates a panel. Therefore, both mappings to this element are in fact required.
    Observation.value[x]:
      - datatype: Quantity instead of ANY
        reason: In FHIR there's no datatype ANY. All stated datatypes in the description can be accommodated using this element (Quantity and CodeableConcept are in fact both supported).
    Observation.referenceRange.*:
      - datatype: Quantity instead of ANY
        reason: The zib concepts ReferenceRangeUpperLimit and ReferenceRangeLowerLimit are defined as datatype ANY, but these concepts only have meaning when they apply to a Quantity. See https://bits.nictiz.nl/browse/ZIB-1703.

zib-LaboratoryTestResult.Specimen:
  zib deviations:
    Specimen.identifier:
      - cardinality: 0..* instead of 0..1
        reason: Although a single SpecimenId is allowed according to the zib, .identifier is often used for additional identifiers outside the scope of the zib. It's not possible to create a slice or pattern specifically for SpecimenId without further formal requirements by the zib.
    Specimen.subject:
      - datatype: Reference instead of string
        reason: The zib concept SpecimenSource is communicated using a string within the profile zib-LaboratoryTestResult.SpecimenSource, which is referenced here.
    Specimen.collection.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: Zib AnatomicalLocation is implemented as a datatype profile on CodeableConcept, so the datatype is not a Reference.
    Specimen.collection.collected[x]:collectedPeriod:
      - datatype: Period instead of a reference
        reason: Zib TimeInterval is directly mapped onto Specimen.collection.collectedPeriod and Specimen.collection.duration, as this matches the way these concepts are used in FHIR. 
    Specimen.collection.duration:
      - datatype: Duration instead of a reference
        reason: Zib TimeInterval is directly mapped onto Specimen.collection.collectedPeriod and Speciment.collection.duration, as this matches the way these concepts are used in FHIR.
    Specimen.container.extension:specimenNumberExtension.value[x]:
      - cardinality: 1..1 instead of 0..1
        reason: The value in the extension is 1..1, but the extension itself is 0..1, effectively matching the zib cardinality.

zib-LaboratoryTestResult.SpecimenSource:
  zib deviations:
    Device.deviceName.name:
      - cardinality: 1..1 instead of 0..1
        reason: The zib concept SpecimenSource is represented using a reference to this profile from zib-LaboratoryTestResult.Specimen, so this element represents just part of the mapping. Overall, the use of this concept is optional, but when this profile is used, Device.deviceName.name must be given.

zib-MedicalDevice:
  zib deviations:
    DeviceUseStatement.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.
    DeviceUseStatement.reasonReference:zibMedicalDeviceReference:
      - short: zib MedicalDevice reference
        reason: This is a special slice that represents situations where zib MedicalDevice is referenced from another zib through the reasonReference element. Because this reference is reversed in FHIR, this profile needs to contain the mappings for the references in _all_ these zibs. A common slice is defined with an indicative name rather than the name of all the targets. 
    DeviceUseStatement.timing[x]:timingPeriod.end:
      - short: EndDate instead of EindDatum
        reason: The zib concept name "EindDatum" has not been translated into English.

zib-MedicalDevice.Product:
  zib deviations:
    Device.identifier:*ProductID:
      - datatype: Identifier instead of CD compatible datatype
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the mapping of the concept to FHIR will not match on a datatype level.
    Device.udiCarrier:*UdiCarrier.carrierHRF:
      - datatype: string instead of CD compatible datatype
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the mapping of the concept to FHIR will not match on a datatype level.
  ignored issues:
    Device:
      - message: The slice definition for Device.identifier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
      - message: The slice definition for Device.udiCarrier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
    Device.udiCarrier:*.carrierHRF:
      - message: "Constraint failed: sd-pg-03: 'If mapping.map exists and the mapping is not implicit and the element is not the root element, definition should exist.'"
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the definition of the ProductID concept is not suited for all mapped elements.

zib-LegalSituation-LegalStatus:
  zib deviations:
    Condition.code:
      - cardinality: 1..1 instead of 0..1
        reason: The zib requires either a LegalStatus or a Representation to be present. This profile represents the former concept, so the LegalStatus (in Condition.code) is required.

zib-LegalSituation-Representation:
  zib deviations:
    Condition.code:
      - cardinality: 1..1 instead of 0..1
        reason: The zib requires either a LegalStatus or a Representation to be present. This profile represents the latter concept, so the Representation (in Condition.code) is required.

zib-MedicationContraIndication:
  zib deviations:
    Flag.code:
      - cardinality: 1..1 instead of 0..1
        reason: Flag.code is mandatory in FHIR. The cardinality matches the cardinality of the zib, but not the conceptual cardinality. This should not be a major problem, as a contraindication is useless without specifying what it pertains to.

zib-NameInformation:
  zib deviations:
    HumanName.prefix:
      - cardinality: 0..* instead of 0..1
        reason: Both prefix and suffix are mapped to the "titles" concept from the zib. There's a mismatch however in the way this information is represented in the zib and in FHIR. The mapping is documented in the profile.
    HumanName.suffix:
      - cardinality: 0..* instead of 0..1
        reason: Both prefix and suffix are mapped to the "titles" concept from the zib. There's a mismatch however in the way this information is represented in the zib and in FHIR. The mapping is documented in the profile.
    HumanName.given:
      - short: FirstName / Initial
        reason: The zib defines both the complete list of first names and of initials as a single string. In FHIR this is done fundamentally different, by using separate names. Hence, the short has been changed to the singular form.
      - alias: first name,middle name,Voornaam,Initiaal
        reason: The first two initials are provided by FHIR. For the singular form of the latter two, see the remark above.
      - cardinality: 0..* instead of 0..1
        reason: See the remark above.
    HumanName.family.extension:*.value[x]:
      - cardinality: 1..1 instead of 0..1
        reason: The value of the extension is required, but the extension itself is optional, making the effective cardinality 0..1 as required by the zib.

zib-NameInformation.GivenName:
  zib deviations:
    HumanName.given:
      - cardinality: 1..* instead of 0..1
        reason: The GivenName is optional according to the zib, but when this datatype profile is used, a name should be provided.

zib-NursingIntervention:
  zib deviations:
    CarePlan.activity.detail.scheduled[x]:scheduledTiming.repeat.frequency:
      - datatype: positiveInt instead of Quantity
        reason: The zib concepts Interval and Frequency are represented by a combination of .frequency, .period and .periodUnit, not by a single element of Quantity datatype.
    CarePlan.activity.detail.scheduled[x]:scheduledTiming.repeat.period:
      - datatype: decimal instead of Quantity
        reason: The zib concepts Interval and Frequency are represented by a combination of .frequency, .period and .periodUnit, not by a single element of Quantity datatype.
    CarePlan.activity.detail.scheduled[x]:scheduledTiming.repeat.periodUnit:
      - datatype: code instead of Quantity
        reason: The zib concepts Interval and Frequency are represented by a combination of .frequency, .period and .periodUnit, not by a single element of Quantity datatype.
    CarePlan.activity.detail.extension:medicalDevice.value[x]:
      - cardinality: 0..1 instead of 0..*
        reason: The value of the extension can only occur once, but the use of the extension itself is unlimited, making the effective cardinality 0..* as required by the zib.
  ignored issues:
    CarePlan:
      - message: The slice definition for CarePlan.activity.detail.performer has a maximum of 1 but the slices add up to a maximum of 3. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.

zib-Patient:
  zib deviations:
    Patient.extension:nationality.extension:code.value[x]:
      - cardinality: 1..1 instead of 0..1
        reason: Zib Nationality is implemented using the complex core extension patient-nationality. The value[x] element representing the concept Nationality has a 1..1 cardinality, but the "code" part of the extension itself is 0..1, making the cardinality effectively 0..1 as required by the zib.
    Patient.name*:
      - datatype: HumanName instead of a reference
        reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
    Patient.name:
      - cardinality: 0..* instead of 0..1
        reason: The name information according to zib NameInformation may be split up over multiple instances of Patient.name.
    Patient.telecom*:
      - datatype: ContactPoint instead of a reference
        reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource.
    Patient.telecom:
      - cardinality: 0..* instead of 0..1
        for: NL-CM:0.1.5 (Patient.ContactInformation)
        reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib part ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
    Patient.address:
      - datatype: Address instead of a reference
        reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
    Patient.deceased[x]:deceasedDateTime:
      - short: DateOfDeath instead of DateOfDeath / DeathIndicator
        reason: This element is mapped to two zib concepts, DateOfDeath and DeathIndicator. However, the latter is implicit -- although the zib recognizes both concepts, FHIR supports populating just one of them, thus DeathIndicator is assumed to be true when DateOfDeath is populated. For clarity reasons, the .deceasedDateTime slice has only DateOfDeath mapped to it.
      - datatype: dateTime instead of boolean
        reason: The boolean expected by DeathIndicator is only assumed; see the explanation above.
    Patient.contact:
      - datatype: BackboneElement instead of a reference
        reason: The zib ContactPerson _may_ be represented as Patient.contact. There is a different use case as well, where the ContactPerson is implemented using a RelatedPerson resource.
    Patient.contact.extension:contactPerson.value[x]:
      - datatype: Reference instead of the root concept of zib ContactPerson
        reason: This is an additional reference to a separate zib-ContactPerson (RelatedPerson) instance, next to the information in Patient.contact. Patient.contact and RelatedPerson can both be used to capture the information from zib-ContactPerson, but each are used within a different context. Information may therefore be duplicated; this is the recommended way.
    Patient.contact.name:
      - datatype: HumanName instead of a reference
        reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
    Patient.contact.telecom*:
      - datatype: ContactPoint instead of a reference
        reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource.
    Patient.contact.telecom:
      - cardinality: 0..* instead of 0..1
        reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib part ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
    Patient.contact.address:
      - datatype: Address instead of a reference
        reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
      - cardinality: 0..1 instead of 0..*
        reason: Patient.contact is a restricted representation of contact persons containing only information needed to contact a contact person. The full address information should be captured using an instance of the zib-ContactPerson profile on RelatedPerson, which can be linked using an extension. This is explained in the profile.  
    Patient.communication:
      - datatype: BackboneElement instead of a reference
        reason: The appropriate representation of zib LanguageProficiency in FHIR is Patient.communication, not a separate resource.
    Patient.communication.language:
      - cardinality: 1..1 instead of 0..1
        reason: The FHIR profiles are expected to implement zib cardinalities as conceptual cardinalities, but FHIR requires the .language element to be present. This aligns with the intention of the zib, as the Language concept is required for zib LanguageProficiency to make sense.
    Patient.communication.extension:languageControl:
      - datatype: Extension instead of CD compatible datatype
        reason: The mapping is placed on the extension and not on the value[x] because of the nature of this extension. The extension itself contains a valueCoding that gets the zibs value. This datatype matches the zib CD type.
      - cardinality: 0..* instead of 0..1
        reason: Because of the nature of this extension the cardinality has a mismatch. Three zib concepts are mapped to this extension. Therefore the extension cannot be 0..1, but should be able to repeat.
  additional notes: 
    Patient.telecom: Although there is a cardinality mismatch for the mapping of zib concept Patient.ContactInformation on this element (as pointed out above), the cardinalities between zib and FHIR do match for the mapping of zib concept Payer.ContactInformation (NL-CM:1.1.12), as these are both 0..*.

zib-PharmaceuticalProduct:
  zib deviations:
    Medication.ingredient:
      - datatype: BackboneElement instead of Container
        reason: The appropriate representation of Ingredient in FHIR is Medication.ingredient. The container can be properly mapped to this BackboneElement.
    Medication.ingredient.strength:
      - datatype: Ratio instead of Container
        reason: The .ingredient.strength acts as a container for the two child elements and can thus be correctly mapped to the zib Concentration container.

zib-Payer.InsuranceCompany:
  zib deviations:
    Coverage.payor:
      - cardinality: 1..1 instead of 0..1
        reason: The cardinality of the zib concept InsuranceCompany (0..1) mismatches FHIR (1..1). Between the zib concepts InsuranceCompany and PayerPerson, a minimum of 1 must be selected. If one uses the zib-Payer.InsuranceCompany profile, the choice has been made to apply the InsuranceCompany concept, therefore a cardinality of 1..1 can be used.

zib-Payer.PayerPerson:
  zib deviations:
    Coverage.extension:bankInformation:
      - datatype: Extension instead of Container
        reason: The (complex) extension acts as a container for three subextensions that each contain a zib subconcept.
    Coverage.payor:
      - cardinality: 1..1 instead of 0..1
        reason: The cardinality of the zib concept PayerPerson (0..1) mismatches FHIR (1..1). Between the zib concepts InsuranceCompany and PayerPerson, a minimum of 1 must be selected. If one uses the zib-Payer.PayerPerson profile, the choice has been made to apply the PayerPerson concept, therefore a cardinality of 1..1 can be used.

zib-Payer-Organization:
  zib deviations:
    Organization.telecom*:
      - datatype: ContactPoint instead of a reference
        reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource. Because the FHIR profile for ContactInformation consists of two parts, the root concept of the ContactInformation is mapped on .telecom.
    Organization.address:
      - datatype: Address instead of a reference
        reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
        
zib-PressureUlcer:
  zib deviations:
    Condition.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.

zib-Problem:
  zib deviations:
    Condition.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.

zib-Procedure-event:
  zib deviations:
    Procedure.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.

zib-Procedure-request:
  zib deviations:
    ServiceRequest.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.
    ServiceRequest.requester:
      - cardinality: 0..1 instead of 0..*
        reason: It seems that the zib may have an error in the cardinality for this concept and the cardinality should actually be 0..1 rather than 0..*. This issue is being tracked at https://bits.nictiz.nl/browse/ZIB-1488.

zib-Refraction:
  ignored issues:
    Observation.bodySite.extension:laterality.value[x]:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is defined in the extension profile and therefore not defined in the differential.
      - message: "Constraint failed: sd-pg-03: 'If mapping.map exists and the mapping is not implicit and the element is not the root element, definition should exist.'"
        reason: The definition is defined in the extension profile and therefore not defined in the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias is defined in the extension profile and therefore not defined in the differential.
  zib deviations:
    Observation.bodySite:
      - short: AnatomicalLocation
        reason: The zib has both a reference to AnatomicalLocation and a mapping on AnatomicalLocation::Laterality, while it seems only the latter is important. This leads to unexpected results. https://bits.nictiz.nl/browse/ZIB-1442.
      - datatype: CodeableConcept
        reason: The zib has both a reference to AnatomicalLocation and a mapping on AnatomicalLocation::Laterality, while it seems only the latter is important. This leads to unexpected results. https://bits.nictiz.nl/browse/ZIB-1442.
    Observation.component:cylindricalRefractionAxis.value[x]:
      - short: CylindricalRefractionAxis instead of CilindricRefractionAxis
        reason: The zib concept name "CilindricRefractionAxis" is an incorrect translation of the Dutch name into English.
    Observation.component:prismValue.value[x]:
      - short: PrismValue instead of PrismaValue
        reason: The zib concept name "PrismaValue" is an incorrect translation of the Dutch name into English.
    Observation.component:prismBase.value[x]:
      - short: PrismBase instead of PrismaBase
        reason: The zib concept name "PrismaBase" is an incorrect translation of the Dutch name into English.
    Observation.component:sphericalRefractionValue.value[x]:
      - short: SphericalRefractionValue instead of SfericRefractionValue
        reason: The zib concept name "SfericRefractionValue" is an incorrect translation of the Dutch name into English.
    Observation.component:sphericalEquivalent.value[x]:
      - short: SphericalEquivalent instead of SfericalEquivalent
        reason: The zib concept name "SfericalEquivalent" is an incorrect translation of the Dutch name into English.

zib-SNAQ65plusScore:
  ignored issues:
    StructureDefinition.mapping[0]:
      - message: "Constraint failed: sd-zpg-05: 'The URI for zib mappings should align with the mapping name'"
        reason: The discrepancy between uri and name in the mapping stems from the '+' character in the zib name, as this character is not allowed in the mapping name.

zib-SOAPReport:
  zib deviations:
    Composition.author:
      - cardinality: 1..1 instead of 0..1
        reason: This is a known difference with the zib. FHIR mandates an author for the Compositions. It seems like a requirement systems can honour.
    Composition.date:
      - cardinality: 1..1 instead of 0..1
        reason: This is a known difference with the zib. FHIR mandates a date for the Compositions. It seems like a requirement systems can honour.
    Composition.section:soapLine:
      - datatype: BackboneElement instead of Container
        reason: Zib container concept SOAPLine corresponds to a Composition.section, which is a BackboneElement. 
    Composition.section:soapLine.code:
      - cardinality: 1..1 instead of 0..1
        reason: The cardinality of both zib (SOAPLineHeader) and FHIR is 1..1, but because of conceptual cardinality 0..1 is expected.
  ignored issues:
    Composition.section:soapLine:
      - message: "Constraint failed: sd-pg-03: 'If mapping.map exists and the mapping is not implicit and the element is not the root element, definition should exist.'"
        reason: The mapping is to a zib container, which doesn't have a useful description if implemented in a profile.

zib-SOAPReport.SOAPLine:
  zib deviations:
    Observation.code:
      - cardinality: 1..1 instead of 0..1
        reason: The cardinality of both zib (SOAPLineHeader) and FHIR is 1..1, but because of conceptual cardinality 0..1 is expected. In case of absent data, the profiling guidelines provide guidance.

zib-SkinDisorder:
  zib deviations:
    Condition.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.

zib-Stoma:
  zib deviations:
    Condition.code:
      - cardinality: 1..1 instead of 0..1
        reason: The FHIR profiles are expected to implement zib cardinalities as conceptual cardinalities, but StomaType is essential to identify the Stoma. This aligns with the intention of the zib, as the StomaType concept is required for zib Stoma to make sense.
    Condition.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.

zib-TextResult:
  zib deviations:
    DiagnosticReport.status:
      - cardinality: 1..1 instead of 0..1
        reason: TextResultStatus (0..1) is mapped to the mandatory .status element which should not be a problem because implementers shall have to support .status one way or another. When TextResultStatus is absent, other codes may be used than from the zib. The _unknown_ code can be used as a fallback.
    DiagnosticReport.code:
      - cardinality: 1..1 instead of 0..1
        reason: The cardinality in both zib and FHIR is 1..1, but because of conceptual cardinality 0..1 is expected. In case of absent data, the profiling guidelines provide guidance.

zib-TextResult.VisualResult:
  zib deviations:
    Media.content:
      - cardinality: 1..1 instead of 0..*
        reason: The use of the Media resource referenced in zib-TextResult DiagnosticReport.media.link is optional (0..*), but if the Media resource is used, Media.content should be present (1..1).

zib-TreatmentDirective2:
  zib deviations:
    Consent.source[x]:sourceReference:
      - cardinality: 0..1 instead of 0..*
        reason: This element is the logical representation of the AdvanceDirective concept (NL-CM:2.2.8) specified in HCIM TreatmentDirective2, but FHIR restricts the cardinality to 0..1. For this reason, an extension is added that can be used to provide additional AdvanceDirective references.
    Consent.provision.actor:agreementParty:
      - datatype: BackboneElement instead of Container
        reason: The zib container AgreementParty can be mapped correctly to the actor's BackboneElement.
    Consent.provision.actor:agreementParty.reference:
      - cardinality: 1..1 instead of 0..1
        reason: The .reference element cannot be used without sibling .role to represent the concepts NL-CM:2.2.10, NL-CM:2.2.11 and NL-CM:2.2.12, so these two elements have to be used together. The container itself is optional.
  ignored issues:
    Consent.provision.actor:agreementParty:
      - message: "Constraint failed: sd-pg-03: 'If mapping.map exists and the mapping is not implicit and the element is not the root element, definition should exist.'"
        reason: The mapping is to a zib container, which doesn't have a useful description if implemented in a profile.

zib-Vaccination-event:
  zib deviations:
    Immunization.vaccineCode:
      - cardinality: 1..1 instead of 0..1
        reason: This is a known difference between the zib (0..*) and FHIR (1..1). The mandatory element in FHIR seems legit. If an immunization event has taken place the vaccine code should be known. Otherwise, the value of the whole Immunization resource will be strongly diminished.
    Immunization.performer:administrator.actor:
      - cardinality: 1..1 instead of 0..1
        reason: Immunization.performer:administrator has cardinality 0..1, making the cardinality of Immunization.performer:administrator.actor effectively 0..1 as required by the zib.

zib-Vaccination-request:
  zib deviations:
    ImmunizationRecommendation.recommendation.dateCriterion.value:
      - cardinality: 1..1 instead of 0..1
        reason: ImmunizationRecommendation.recommendation.dateCriterion has cardinality 0..1, making the cardinality of ImmunizationRecommendation.recommendation.dateCriterion.value effectively 0..1 as required by the zib.

zib-VisualFunction.VisualAid:
  zib deviations:
    DeviceUseStatement:
      - datatype: undefined
        reason: In FHIR, the reference to the MedicalDevice points in the other direction (so the MedicalDevice refers to VisualFunction). The MedicalDevice reference is however mapped on the root element that represents this zib rather than on DeviceUseStatement.reasonReference resulting in an unmatched datatype.
    DeviceUseStatement.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.
    DeviceUseStatement.timing[x]:timingPeriod.end:
      - short: EndDate instead of EindDatum
        reason: The zib concept name "EindDatum" has not been translated into English.

zib-VisualFunction.VisualAid.Product:
  ignored issues:
    Device:
      - message: The slice definition for Device.identifier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
      - message: The slice definition for Device.udiCarrier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
    Device.type:
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias for ProductType is already present in the base profile where this profile is derived from. It should not be added twice to silence this issue.
  zib deviations:
    Device.identifier:*ProductID:
      - datatype: Identifier instead of CD compatible datatype
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the mapping of the concept to FHIR will not match on a datatype level.
    Device.udiCarrier:*UdiCarrier.carrierHRF:
      - datatype: string instead of CD compatible datatype
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the mapping of the concept to FHIR will not match on a datatype level.
        
zib-Wound:
  zib deviations:  
    Condition.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.

zib-Wound.Drain:
  zib deviations:
    DeviceUseStatement.bodySite:
      - datatype: CodeableConcept instead of a reference
        reason: The referenced zib AnatomicalLocation is profiled on a datatype level and not a resource. Therefore it cannot be referenced, rather its concepts and constraints are added inline. This element conforms to the zib AnatomicalLocation.
    DeviceUseStatement.timing[x]:timingPeriod.end:
      - short: EndDate instead of EindDatum
        reason: The zib concept name "EindDatum" has not been translated into English.

zib-Wound.Drain.Product:
  ignored issues:
    Device:
      - message: The slice definition for Device.identifier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
      - message: The slice definition for Device.udiCarrier has a maximum of 1 but the slices add up to a maximum of 2. Check that this is what is intended
        reason: This is indeed what is intended, just one of these slices may be chosen.
    Device.type:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist"
        reason: The short for ProductType is already present in the base profile where this profile is derived from. It should not be added twice to silence this issue.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias for ProductType is already present in the base profile where this profile is derived from. It should not be added twice to silence this issue.
  zib deviations:
    Device.identifier:*ProductID:
      - datatype: Identifier instead of CD compatible datatype
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the mapping of the concept to FHIR will not match on a datatype level.
    Device.udiCarrier:*UdiCarrier.carrierHRF:
      - datatype: string instead of CD compatible datatype
        reason: The mapping of ProductID is not straightforward and relates to multiple elements in FHIR. In result, the mapping of the concept to FHIR will not match on a datatype level.

zib-wounds.WoundImage:
  zib deviations:
    DocumentReference.content.attachment:
      - alias: WondFoto instead of Wondfoto
        for: NL-CM:19.4.11 (Burnwound.WoundImage)
        reason: The zib concept name "Wondfoto" is incorrect and must be corrected to "WondFoto".
      - cardinality: 1..* instead of 0..*
        reason: The WoundImage concept itself has been mapped onto this separate DocumentReference resource. This resource may be instantiated 0..* times, but if it is used, its content is required.
        
unmapped zib concepts:
  - NL-CM:17.2.10: HealthcareProvider.LocationNumber
    reason: This zib concept is problematic to map cleanly to FHIR and it has been deemed too uncommon in practice to warrant an extension.
  - NL-CM:13.1.30: LaboratoryTestResult.InterpretationMethod
    reason: This zib concept is deemed unneeded and will be removed in the future. See https://bits.nictiz.nl/browse/ZIB-1292 for details.
  - NL-CM:13.1.34: LaboratoryTestResult.Requester::HealthProfessional
    reason: This concept is deemed unimplementable and will be removed in the future. See https://bits.nictiz.nl/browse/ZIB-1269 for details.

undefined zib concepts:
  - concept id: NL-CM:19.4.9
    name NL: BrandwondSoort
    name EN: BurnType
    datatype: CD
    cardinality: 0..1
    reason: The BurnType concept was added by an erratum.
    
---
# The following issues are not "real" deviations stemming from design choices, but rather problems that pop up due to
# shortcomings in tooling, the used terminology server, etc.
# These might occur in one or more profiles, or in none if they have been fixed in the meantime. 

issues should occur: false

"*":
  ignored issues:
    Consent.scope*:
      - message: Unknown Code 'adr' in the system 'http://terminology.hl7.org/CodeSystem/consentscope'
        reason: This concerns an error in the FHIR terminology server. The adr code has been removed for R5 and the terminology server was updated for it too soon. They will fix it according to zulip chat https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Consent.2Escope.3A.20diff.20in.20codes.20shown.20on.20FHIR.20vs.20Tx.20server.
      - message: None of the codings provided are in the value set 'Consent Scope Codes' (http://hl7.org/fhir/ValueSet/consent-scope), and a coding should come from this value set unless it has no suitable code
        reason: See above.
    ValueSet.compose.include[*].concept[*]:
      - message: Unable to validate code without using server
        reason: This warning doesn't provide any feedback on the correctness of the materials. In addition, there's little reason to fix this issue on the package level as it is unlikely that this ever results in problems in production (ValueSets are not typically validated in production).
    ValueSet.compose.include[*].concept[*].designation[*].language:
      - message: Unable to validate code without using server
        reason: This warning doesn't provide any feedback on the correctness of the materials. In addition, there's little reason to fix this issue on the package level as it is unlikely that this ever results in problems in production (ValueSets are not typically validated in production).
    CodeSystem.language:
      - message: Unable to validate code without using server
        reason: This warning doesn't provide any feedback on the correctness of the materials. In addition, there's little reason to fix this issue on the package level as it is unlikely that this ever results in problems in production (CodeSystems are not typically validated in production).
    CodeSystem.concept[*].designation[*].language:
      - message: Unable to validate code without using server
        reason: This warning doesn't provide any feedback on the correctness of the materials. In addition, there's little reason to fix this issue on the package level as it is unlikely that this ever results in problems in production (CodeSystems are not typically validated in production).

2.16.840.1.113883.2.4.3.11.60.40.2.5.1.3--20200901000000:
  ignored issues:
    ValueSet.compose.include[9].filter[0]:
      - message: The value for a filter based on property 'concept' must be a valid code from the system 'http://snomed.info/sct', and '31000147101' is not
        reason: This code represents the DHD Diagnosethesaurus, which the default terminology server is unable to check

2.16.840.1.113883.2.4.3.11.60.40.2.14.1.2--20200901000000:
  ignored issues:
    ValueSet.compose.include[0].filter[0]:
      - message: The value for a filter based on property 'concept' must be a valid code from the system 'http://snomed.info/sct', and '41000147108' is not
        reason: This code represents the DHD Verrichtingenthesaurus, which the default terminology server is unable to check

nl-core-*:
  ignored issues:
    "*":
      - message: No valid Display Names found for
        reason: This warning doesn't provide any feedback on the correctness of the materials, but only on the completeness of the terminology server used.
    "*.address*.country.extension[0].value*":
      - message: None of the codings provided are in the value set 'LandCodelijsten'
        reason: The current version of the Validator incorrectly raises an error on combined ValueSets.
    "*.code":
      - message: None of the codings provided are in the value set 'VerrichtingTypeCodelijsten'
        reason: The current version of the Validator incorrectly raises an error on combined ValueSets.
    "*.telecom[*].system.extension[*].value.ofType(CodeableConcept).coding[*]":
      - message: Wrong Display Name 'Mobile Phone' for http://terminology.hl7.org/CodeSystem/v3-AddressUse#MC
        reason: This core display value is redefined by the ValueSet, but this isn't properly recognized by the Validator
    Condition.code:
      - message: None of the codings provided are in the value set 'ProbleemNaamCodelijst'
        reason: This ValueSet contains two SNOMED refsets. The terminology servers are unable to determine if a code is part of this refset.
      - message: "Error from http://tx.fhir.org/r4: The Snomed Concept 31000147101 was not known"
        reason: This code represents the DHD Diagnosethesaurus, which the default terminology server is unable to check. This causes problems on some occasions (but not all).
    Condition.evidence[*].detail[*]:
      - message: This element does not match any known slice defined in the profile
        reason: The Validator is unable to resolve references on disk, so it is unable to match reference slices
    Observation.hasMember[*]:
      - message: This element does not match any known slice defined in the profile
        reason: The Validator is unable to resolve references on disk, so it is unable to match reference slices
    Procedure.code:
      - message: "Error from http://tx.fhir.org/r4: The Snomed Concept 41000147108 was not known"
        reason: This code represents the DHD Verrichtingenthesaurus, which the default terminology server is unable to check. This causes problems on some occasions (but not all).

nl-core-AllergyIntolerance*:
  ignored issues:
    AllergyIntolerance.code:
      - message: "None of the codings provided are in the value set 'VeroorzakendeStofCodelijsten'"
        reason: The terminology servers cannot handle the refset specified in the ValueSet.
    "AllergyIntolerance.reaction[*].substance":
      - message: None of the codings provided are in the value set 'SpecifiekeStofCodelijsten'
        reason: The terminology servers cannot handle the refset specified in the ValueSet.

nl-core-BloodPressure-*:
  ignored issues:
    Observation.component[*].value.*:
      - message: None of the codings provided are in the value set 'Vital Signs Units'
        reason: The Validator checks all Observations with a vital signs magic LOINC code against the HL7 Vital Signs base profile. Unfortunately, this profile restricts the allowed components to only the use cases identified by HL7, while the zib adds additional data. This has been identified as a bug in het HL7 Vital Signs profile, which will be fixed in the next version. See https://jira.hl7.org/browse/FHIR-43353 for more information.

nl-core-BodyHeight-*:
  ignored issues:
    Observation.value.ofType(Quantity).code:
      - message: The value provided ('cm') is not in the value set 'Body Length Units'
        reason: In absence of a terminology server, the Validator cannot check if 'cm' is a valid UCUM unit and raises an error.
    Observation.component[*].value.*:
      - message: None of the codings provided are in the value set 'Vital Signs Units'
        reason: The Validator checks all Observations with a vital signs magic LOINC code against the HL7 Vital Signs base profile. Unfortunately, this profile restricts the allowed components to only the use cases identified by HL7, while the zib adds additional data. This has been identified as a bug in het HL7 Vital Signs profile, which will be fixed in the next version. See https://jira.hl7.org/browse/FHIR-43353 for more information.

nl-core-BodyWeight-*:
  ignored issues:
    Observation.component[*].value.*:
      - message: None of the codings provided are in the value set 'Vital Signs Units'
        reason: The Validator checks all Observations with a vital signs magic LOINC code against the HL7 Vital Signs base profile. Unfortunately, this profile restricts the allowed components to only the use cases identified by HL7, while the zib adds additional data. This has been identified as a bug in het HL7 Vital Signs profile, which will be fixed in the next version. See https://jira.hl7.org/browse/FHIR-43353 for more information.

nl-core-BowelFunction-02-DeviceUseStatement-01:
  ignored issues:
    DeviceUseStatement.reasonReference[0]:
      - message: This element does not match any known slice defined in the profile http://nictiz.nl/fhir/StructureDefinition/nl-core-MedicalDevice
        reason: The Validator is unable to follow the reference on disk, and so is unable to analyze which profile the referenced resource matches.

nl-core-*Function.*Aid-*:
  ignored issues:
    DeviceUseStatement:
      - message: 'DeviceUseStatement.reasonReference:functionalOrMentalStatus: max allowed = 0, but found 1'
        reason: The Validator cannot actually inspect the referenced resources, and falsely assumes the reference is a reference to the offending profile.
      - message: 'DeviceUseStatement.reasonReference:bowelFunction: max allowed = 0, but found 1'
        reason: The Validator cannot actually inspect the referenced resources, and falsely assumes the reference is a reference to the offending profile.

nl-core-HearingFunction.HearingAid-*:
  ignored issues:
    DeviceUseStatement.reasonReference[*]:
      - message: 'Profile http://nictiz.nl/fhir/StructureDefinition/nl-core-HearingFunction.HearingAid, Element matches more than one slice'
        reason: The Validator cannot actually inspect the referenced resources, and falsely assumes the reference is a reference to the offending profile.

nl-core-VisualFunction.VisualAid-*:
  ignored issues:
    DeviceUseStatement.reasonReference[*]:
      - message: 'Profile http://nictiz.nl/fhir/StructureDefinition/nl-core-VisualFunction.VisualAid, Element matches more than one slice'
        reason: The Validator cannot actually inspect the referenced resources, and falsely assumes the reference is a reference to the offending profile.

nl-core-LaboratoryTestResult-*:
  ignored issues:
    Observation.code:
      - message: None of the codings provided are in the value set 'TestCode-en-Onderzoek-Codelijsten'
        reason: The current version of the Validator incorrectly raises an error on combined ValueSets.

nl-core-PainScore-01:
  ignored issues:
    Observation.method:
      - message: None of the codings provided are in the value set 'PijnMeetmethodeCodelijst'
        reason: The terminology servers used don't know this code system and wrongly conclude that this is an invalid code.

nl-core-Patient-01:
  ignored issues:
    Patient.communication[0].language:
      - message: None of the codings provided are in the value set 'CommunicatieTaalCodelijst'
        reason: The terminology servers used don't know this code system and wrongly conclude that this is an invalid code.

nl-core-PharmaceuticalProduct-01:
  ignored issues:
    Medication.code:
      - message: None of the codings provided are in the value set 'ProductCodeCodelijsten'
        reason: The terminology servers used don't know this code system and wrongly conclude that this is an invalid code.
      - message: Code System URI 'urn:oid:2.16.840.1.113883.2.4.4.1' is unknown so the code cannot be validated
        reason: The terminology servers used don't know this code system.

nl-core-PharmaceuticalProduct-02:
  ignored issues:
    Medication.code:
      - message: None of the codings provided are in the value set 'ProductCodeCodelijsten'
        reason: The terminology servers used don't know this code system and wrongly conclude that this is an invalid code.
      - message: Code System URI 'urn:oid:2.16.840.1.113883.2.4.4.1' is unknown so the code cannot be validated
        reason: The terminology servers used don't know this code system.

nl-core-PulseRate-*:
  ignored issues:
    Observation.code:
      - message: "HeartRateCode: magic LOINC code 8867-4 required, but not found"
        reason: The Validator regards a heart rate measured by palpation as a special case of a heart rate and requires the heart rate code to be present in addition, whereas the zib regards a "pulse rate" as something fundamentally different than a heart rate. This issue is tracked in https://nictiz.atlassian.net/browse/ZIB-2216. Until it has been resolved, this error message is silenced.

zib-*Function.*Aid.Product:
  ignored issues:
    Device.type:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is the same as that of the base profile, so it is absent from the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The short description is the same as that of the base profile, so it is absent from the differential.

zib-Alert:
  ignored issues:
    Flag:
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias "Alert" is already defined in the base profile, so it doesn't need to be defined again in the differential.

zib-CareTeam:
  ignored issues:
    CareTeam.participant:*.member:
      - message: "Constraint failed: sd-zpg-03: 'References to other resource profiles should be added next to the HL7 base references, unless they are added on a slice"
        reason: The restriction is set on a slice, but this cannot be automatically checked.

zib-ContactPerson:
  ignored issues:
    RelatedPerson.address:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is defined on the datatype profile and not repeated in the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias is defined on the datatype profile and not repeated in the differential.

zib-Encounter:
  ignored issues:
    Encounter.participant:healthProfessional.individual:
      - message: "Constraint failed: sd-zpg-03: 'References to other resource profiles should be added next to the HL7 base references, unless they are added on a slice."
        reason: The restriction is set on a slice, but this cannot be automatically checked.

zib-HealthcareProvider:
  ignored issues:
    Location.address:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The required short description is given by the datatype profile, so it is absent from the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The required alias is given by the datatype profile, so it is absent from the differential.

zib-HealthProfessional-Practitioner:
  ignored issues:
    Practitioner.address:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is defined on the datatype profile and not repeated in the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias is defined on the datatype profile and not repeated in the differential.

zib-Patient:
  ignored issues:
    Patient.address:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is defined on the datatype profile and not repeated in the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias is defined on the datatype profile and not repeated in the differential.
    Patient.contact.name:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is defined on the datatype profile and not repeated in the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias is defined on the datatype profile and not repeated in the differential.
    Patient.contact.address:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is defined on the datatype profile and not repeated in the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias is defined on the datatype profile and not repeated in the differential.
        
zib-Payer.InsuranceCompany:
  ignored issues:
    Coverage.payor:
      - message: "Constraint failed: sd-pg-03: 'If mapping.map exists and the mapping is not implicit and the element is not the root element, definition should exist.'"
        reason: The definition of the zib concept InsuranceCompany, which is the root of a container, does not contain a meaningful definition. 

zib-Payer-Organization:
  ignored issues:
    Organization.address:
      - message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
        reason: The short description is defined on the datatype profile and not repeated in the differential.
      - message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
        reason: The alias is defined on the datatype profile and not repeated in the differential.