Mappingarchitectuur

{{#customtitle:Mapping - architectuur}}

1 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. Mapping is een optie als de bronsystemen niet (op de gewenste termijn) zelf de informatie in de juiste vorm aan kunnen bieden, maar wel een stabiel alternatief formaat ondersteunen. 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.

2 Strategie

Bij het mappen is het - zeker wanneer je begint - 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). Een zib is echter een context-onafhankelijke definitie. Uitwisseling van informatie vindt altijd plaats ín een context. In datasets en transacties van een informatiestandaard wordt context toegevoegd aan de zib-definitie. Wanneer deze context extra informatie(-elementen) bevat, mogen deze niet verloren gaan bij mappings. Praktisch gezien wordt een mapping daarom altijd gekoppeld aan een transactie. Omdat dezelfde zibs toegepast worden in verschillende transacties is herbruikbaarheid van mappings nog steeds mogelijk. De strategie voor mappings is dan ook om deze altijd van/naar een generiek functioneel formaat (dat zich mede baseert op zibs) te laten lopen.

In figuurvorm:

Formaat X		transactie met zibs		Formaat Y
Input	↗ → ↘	Patient Zorgaanbieder ...	↗ → ↘	Output

3 Aandachtspunten

Bij iedere mapping komen een aantal aspecten altijd terug

• Bedenk goed of mappen de beste oplossing is.
• 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 Persoonlijke Gezondheid 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. Het MedMij-afsprakenstelsel beschrijft de wijze waarop deze PGO-id samenhangt met het BSN via tokens die ontstaan in het proces voor identificatie en authenticatie
• 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 dan weer vaak in HL7 benodigde identificatiemogelijkheden.

4 Input- en outputformaten

Persoonlijke Gezondheid Omgevingen (PGO's) werken met standaarden uit de MedMij standaardencatalogus. Deze zijn in principe altijd gebaseerd op HL7 FHIR profielen die zijn afgeleid van de Zorginformatiebouwstenen (zibs). De standaarden voor de PGO's zijn dus vanaf het begin ontworpen op compatibiliteit met de zibs. De wijze waarop een willekeurig FHIR-profiel samenhangt met een of meerdere zibs, is te zien op de Mapping-tab in Simplifier waar de profielen te vinden zijn. Hierbij een voorbeeld met links voor het profiel voor Patient in FHIR dat mapt op 6 zibs (Patient, BurgerlijkeStaat, Contactpersoon, Zorgverlener, Nationaliteit, Betaler) met voor de zib Patient de detailmapping in beeld.

HL7 FHIR Profiel Patient naast zib Patiënt

In het domein van de zorgaanbieders zijn veelal (nog) andere standaarden in gebruik. Deze zijn soms ook vanaf zibs ontworpen, maar niet altijd. Voor een groeiende lijst van deze standaarden maakt en onderhoudt Nictiz alsnog een mapping op de zibs. Deze mappings helpen implementerende partijen van mappings, maar dienen ook als basis voor impactanalyses op die standaarden. Bij volgende, grotere versies van zo'n standaard kan dan beter worden ingeschat hoe meer richting zibs bewogen kan worden. De mappings zijn op deze website te vinden in de Gedefinieerde mappings.

5 Mappings en transacties

Deze sectie toont verschillende mappings voor transacties uit de betreffende informatiestandaard. Door te klikken op de hyperlinks in de 'Van' of de 'Naar' kolom vindt u meer gedetailleerde informatie over die specifieke mapping.

5.1 Medicatieproces (MP)

Van	Dataset transactie	Naar	Example XSLT's on GitHub
MP-6.12 opleveren verstrekkingenlijst	MP-9 beschikbaarstellen verstrekkingenvertaling	MP-9 beschikbaarstellen verstrekkingenvertaling in FHIR	Verstrekkingenvertaling op GitHub
	MP-9 beschikbaarstellen medicatiegegevens	MP-9 beschikbaarstellen medicatiegegevens in FHIR
		MP-9 beschikbaarstellen medicatiegegevens in HL7v3 (CDA of organizer met CDA-statements)
MP-9 sturen medicatievoorschrift in CDA	MP-9 sturen medicatievoorschrift	MP-6.12 Verzoek uitvoeren voorschrift in HL7v3 messaging ('PORX')	Voorschrift op GitHub (gebruikt in POC)
		MP-9 sturen medicatievoorschrift in CDA

5.2 Geboortezorg (GZ)

Van	Dataset transactie	Naar
nvt	Kernset aanleverbericht 2.2	Kernset 2.2 in HL7v3 CareProvision
nvt	Kernset Geboortezorg 2.3	Kernset Geboortezorg 2.3 in HL7v3 CareProvision

5.3 Contraindicaties en overgevoeligheden (CIO)

Van	Dataset transactie	Naar	Example XSLT's on GitHub
MP ICA 6.12 beschikbaarstellen potentiële contraindicaties	CIO 1.0 beschikbaarstellen ICAvertaling