Mappingarchitectuur

Uit informatiestandaarden
Versie door Ahenket (overleg | bijdragen) op 6 jul 2017 om 16:51 (Nieuwe pagina aangemaakt met '{{IssueBox|Deze pagina is nog in bewerking}} ==Introductie== Mapping moet in het vervolg van deze pagina gelezen worden als het overzetten van informatie van de en...')
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Naar navigatie springen Naar zoeken springen

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.