Mappingarchitectuur

Introductie

Mapping moet in het vervolg van deze pagina gelezen worden als het overzetten van informatie van de ene (technische) in de andere (technische) vorm. De kunst van mappen is ervoor te zorgen dat er geen informatiewaarde verloren gaat en dat de mapping bij voorkeur twee kanten op werkt. Om een mapping twee kanten op te laten werken, ben je afhankelijk van de mogelijkheden en beperkingen van beide kanten. Mappings bestaan op diverse detailniveau's:

• skeletel of skeleton: de mappings geven het algemene beeld zonder alle details
• notional: de mappings identificeren de elementen die equivalent zijn in definitie en betekenis
• definitional: de mappings koppelen alle primitieve datatypen in beide specificaties
• executional: de mappings ondersteunen het hele waardedomein met een formele taal en er bestaat een engine die deze mapping kan uitvoeren

De meeste van de geleverde mappings zitten op niveau notional met diverse definitional onderdelen indien mogelijk.

Strategie

Bij het mappen is het verleidelijk om direct tussen berichtformaten te specificeren. Het aantal permutaties is dan schier eindeloos en herbruikbaarheid laag. In plaats daarvan is het beter om een min of meer stabiel normalisatiemedium te kiezen. Dit medium is in feite de informatie zelf, ofwel de functionele definitie daarvan: de Zorginformatiebouwsteen (ZIB). De strategie voor mappings is dan ook om deze altijd van/naar ZIB's te laten lopen.

Aandachtspunten

Bij iedere mapping komen een aantal aspecten altijd terug

• Mappings werken alleen goed als de input voldoende informatie heeft voor de output. Ontbrekende informatie kan soms worden toegevoegd, maar het is altijd opletten wanneer je dit doet. Als je bijvoorbeeld identificatie toevoegt, dan is belangrijk om te weten of deze identificatie iedere keer dat dezelfde informatie waarbij komt, ook dezelfde identificatie moet opleveren, of dat het voldoende is om in deze output unieke identificatie te genereren.
• Mappings van terminologie moet waar mogelijk worden vermeden, tenzij de mapping gegarandeerd zonder verlies van betekenis is en/of gevalideerd is door de 'juiste gremia', bijvoorbeeld koepelorganisaties of een standaardisatieorgaan zoals Nictiz
• Identificatie en codesystemen werken op basis van OID's in HL7v3, op basis van mnemonics in HL7v2 / Edifact en tenslotte op basis van URI's in HL7 FHIR. Hier zijn conversietabellen bij nodig. Voorbeeld:

Edifact	HL7v2	HL7v3	HL7 FHIR
BSN	NNNLD	2.16.840.1.113883.2.4.6.3	http://fhir.nl/fhir/NamingSystem/bsn

• Het burgerservicenummer dat hierboven staat, mag momenteel niet worden gebruikt in een Patiënt Gerelateerde Omgeving (PGO). Als iemand vanuit een PGO informatie opvraagt bij een zorgaanbieder, zal hij dat dus moeten doen met zijn identificatie zoals bekend in het PGO en de zorgaanbieder zal dan ook antwoord moeten geven op basis de identificatie van de persoon in het PGO. De wijze waarop deze PGO-id samenhangt met het BSN via tokens die ontstaan in het proces voor identificatie en authenticatie, wordt beschreven in het MedMij Afsprakenstelsel
• Sommige concepten vertalen zich moeilijk van standaard naar standaard. HL7v3 kent de NullFlavor waarmee op nagenoeg iedere plaats in de informatie kan worden geduid waarom informatie ontbreekt. HL7 FHIR kent hier wel een extensie voor maar ondersteunt dit niet direct. HL7v2 heeft dubbele aanhalingstekens ("") in velden om aan te duiden dat informatie expliciet moet worden gemist bij een ontvanger. Deze faciliteit kennen HL7v3 en HL7 FHIR niet. Edifact mist vaak in HL7 benodigde identificatiemogelijkheden.