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.
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)
5.1.1 Medicatieproces (MP) Versie 9.0.7
| Van | Dataset transactie | Naar | Voorbeeldconversies (XSLT) op GitHub |
| MP-6.12 (opleveren verstrekkingenlijst) | beschikbaarstellen verstrekkingenvertaling | FHIR | Verstrekkingenvertaling op GitHub |
| FHIR | |||
| beschikbaarstellen medicatiegegevens | FHIR | ||
| FHIR | HL7v3 (CDA of organizer met CDA-statements) | MP-9.0.7 FHIR naar HL7v3 op GitHub | |
| CDA | sturen medicatievoorschrift | MP-6.12 HL7v3 messaging ('PORX') - Verzoek uitvoeren voorschrift | Voorschrift op GitHub (gebruikt in POC) |
| CDA | |||
| FHIR | beschikbaarstellen medicatieoverzicht |
5.1.2 Medicatieproces 9 (MP9) Versie 2.0.0
Alle velden in deze tabel zijn hyperlinks waar verdere informatie gevonden kan worden over dat item.
5.1.3 Medicatieproces (MP) Versie MP9 2.0 en versie 9.0.7
Dit gaat om conversies tussen de ada dataset formaten van de transacties en is onafhankelijk van technische formaten (zoals FHIR of HL7v3 CDA). De kolom 'Van' heeft hyperlinks waarin nadere toelichting staat over mapping issues.
| Van | Transactie | Naar | Voorbeeldconversies (XSLT) op GitHub |
| MP9 2.0.0 | beschikbaarstellen medicatiegegevens | MP 9.0.7 | MP9 2.0.0 naar MP-9.0.7 op GitHub |
| MP 9.0.7 | MP9 2.0.0 | MP-9.0.7 naar MP9 2.0.0 op GitHub | |
| MP9 2.0.0 | sturen medicatievoorschrift | MP 9.0.7 | MP9 2.0.0 naar MP-9.0.7 op GitHub |
| MP 9.0.7 | MP9 2.0.0 | MP-9.0.7 naar MP9 2.0.0 op GitHub |
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 AllergieIntolerantieVertaling | CIO 1.0 AllergyIntolerance612Conversion in FHIR |