Meerdere mappings voor hetzelfde element
Description
Verduidelijking van Impact
Proposed solution (NL)
Verwijderen mapping NL-CM:11.1.7 op
Immunization.notein profiel zib-Vaccination.Verwijderen mapping NL-CM:14.3.6 op
Procedure.categoryenProcedure.category.codingin profiel zib-FreedomRestrictingMeasures.Verwijderen mapping NL-CM:20.6.4 op
RelatedPerson.telecomin profiel nl-core-relatedperson.
Proposed solution (EN)
Release notes (NL)
Double (incorrect) mappings from the dataset to profiles have been removed: NL-CM:11.1.7 to Immunization.note in profile zib-Vaccination; NL-CM:14.3.6 to Procedure.category and Procedure.category.coding in profile zib-FreedomRestrictingMeasures; NL-CM:20.6.4 to RelatedPerson.telecom in profile nl-core-relatedperson.
Release notes (EN)
Activity
Niek van Galen September 10, 2021 at 12:55 PMEdited
Former user akkoord.
Pieter Edelman September 9, 2021 at 2:36 PM
Former user, wil jij de review doen?
Pieter Edelman September 9, 2021 at 2:36 PM
Pull request: https://github.com/Nictiz/Nictiz-STU3-Zib2017/pull/218
Pieter Edelman July 27, 2021 at 7:20 AM
Hallo ,
Wat betreft de eerste vier: dit heeft ermee te maken dat FHIR op deze plekken een verplichte (required of extensible) waardelijst specificeert terwijl de zib een andere waardelijst vereist die soms niet een-op-een te mappen is. Om dit te ondervangen wordt gevraagd om met de code-specification extensie ook de oorspronkelijke zib-waarde mee te sturen. Dit wordt hier uitgelegd: https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Mapping_of_coded_concepts. Vandaar dat de mapping zowel op het root-element als op de extensie staat (NB: In FHIR R4 zijn de code- en Coding-datatypes meestal vervangen door _CodeableConcept_s en kan dit eleganter worden opgelost).
Wat zib-Vaccination betreft heb je gelijk, de mapping op
Immunization.notemoet weg.Wat zib-FreedomRestrictingMeasures betreft heb je ook gelijk, de mapping op
Procedure.categoryenProcedure.category.codingkunnen beide weg. NB: deze zib is de facto komen te vervallen ivm. nieuwe wetgeving en zal ik de praktijk niet meer gebruikt worden.Wat betreft nl-core-relatedperson heb je ook gelijk, dit moet een verwijzing zijn naar het rootconcept van zib ContactInformation.
Ik zal de laatste drie aanpassen nomineren voor de eerstvolgende patchrelease van september.
Eduard de Rijcke July 26, 2021 at 3:18 PM
Beste
Bedankt voor het doorgeven van de bevinding.
Wij gaan dit voor je uitzoeken.
Met vriendelijke groet,
Eduard de Rijcke
Details
Assignee
Pieter EdelmanPieter EdelmanReporter
Jorg MutterJorg MutterClassification
Patch (Z)Informatiestandaard onderdelen
FHIR-packageInformation standard
AlleFix versions
Priority
High
Details
Details
Assignee
Pieter EdelmanReporter
Jorg MutterClassification
Informatiestandaard onderdelen
Information standard
Fix versions
Priority
HighBetter Excel Exporter
Export Excel
Better Excel Exporter
Export Excel
Better Excel Exporter
De volgende elementen hebben exact dezelfde mappings op twee verschillende niveaus. Dit is niet consistent met de overige profielen. Kan er hier steeds één weg, of is er een reden voor om dit redundant door te voeren?
Een meer algemene vraag: als een element een geneste structuur oplevert (bijvoorbeeld een valueCodeableConcept), waar zou dan de mapping moeten zijn gedefinieerd? Zijn daar regels voor?
ZIB
Eerste element
Tweede element
zib-AllergyIntolerance
AllergyIntolerance.reaction.severity
AllergyIntolerance.reaction.severity.extension:SeverityCodelist.valueCodeableConcept:valueCodeableConcept
zib-Problem
Condition.clinicalStatus
Condition.clinicalStatus.extension:ProblemStatusCodelist.valueCodeableConcept:valueCodeableConcept
zib-Problem
Condition.verificationStatus
Condition.verificationStatus.extension:VerificatieStatusCodelijst
zib-Encounter
Encounter.class
Encounter.class.extension:ContactTypeCodelist.valueCodeableConcept:valueCodeableConcept
zib-Vaccination
Immunization.note
Immunization.note.text
zib-FreedomRestrictingMeasures
Procedure.category
Procedure.category.coding
De laatste mappings kunnen m.i. beide weg: element 14.3.6 is al gemapt op Procedure.code. Procedure.category heeft een vast patroon:
Hieraan gerelateerd: in "nl-core-relatedperson" staat de volgende mapping:
omdat deze mapping ook al voorkomt in het geneste profiel "nl-core-contactpoint", levert dit uiteindelijk ook een duplicaat mapping op. Gelet op de mappings van 2015 en 2016, vermoed ik dat deze naar NL-CM:20.6.1 ContactInformation zou moeten verwijzen?
Voor de volledigheid: Patient.name en RelatedPerson.name hebben beide een mapping op Payer.name, die ook op een lager niveau voorkomt. Hier vind ik hem wel te rechtvaardigen, omdat deze concepten ook een mapping hebben op Naamsgegevens en het niet logisch zou zijn dit alleen op het laagste niveau te mappen.