Mappingarchitectuur: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(→‎Geboortezorg (GZ))
(→‎Mappings per informatiestandaard)
 
(26 tussenliggende versies door 5 gebruikers niet weergegeven)
Regel 1: Regel 1:
−
{{IssueBox|Deze pagina is nog in bewerking}}
+
__NUMBEREDHEADINGS__
 +
{{DISPLAYTITLE:Mapping - architectuur}}
 
[[Bestand:Nictiz_logo_PO_rechts_rgb.png |link=https://www.nictiz.nl/|rechts|Naar nictiz.nl]]
 
[[Bestand:Nictiz_logo_PO_rechts_rgb.png |link=https://www.nictiz.nl/|rechts|Naar nictiz.nl]]
−
 
+
<section begin=Introductie />
 
==Introductie==
 
==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:
 
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:
Regel 11: Regel 12:
  
 
De meeste van de [[:Categorie:Mappings|geleverde mappings]] zitten op niveau ''notional'' met diverse ''definitional'' onderdelen indien mogelijk.
 
De meeste van de [[:Categorie:Mappings|geleverde mappings]] zitten op niveau ''notional'' met diverse ''definitional'' onderdelen indien mogelijk.
 +
<section end=Introductie />
  
 +
<section begin=Strategie />
 
==Strategie==
 
==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 [http://zibs.nl Zorginformatiebouwsteen] (zib).
 
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 [http://zibs.nl Zorginformatiebouwsteen] (zib).
Regel 28: Regel 31:
 
| Output
 
| Output
 
|}
 
|}
 +
<section end=Strategie />
  
 +
<section begin=Aandachtspunten />
 
==Aandachtspunten==
 
==Aandachtspunten==
 
Bij iedere mapping komen een aantal aspecten altijd terug
 
Bij iedere mapping komen een aantal aspecten altijd terug
Regel 44: Regel 49:
 
* 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 [https://www.medmij.nl/afsprakenstelsel/ MedMij-afsprakenstelsel] beschrijft de wijze waarop deze PGO-id samenhangt met het BSN via ''tokens'' die ontstaan in het proces voor identificatie en authenticatie
 
* 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 [https://www.medmij.nl/afsprakenstelsel/ 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.
 
* 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.
 +
<section end=Aandachtspunten />
  
 +
<section begin=Inputenoutputformaten />
 
==Input- en outputformaten==
 
==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. [[Bestand:FHIR-ZIB-side-by-side.png|miniatuur|HL7 FHIR Profiel Patient naast zib Patiënt]]
 
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. [[Bestand:FHIR-ZIB-side-by-side.png|miniatuur|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 [[:Categorie:Mappings|Gedefinieerde mappings]].
 
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 [[:Categorie:Mappings|Gedefinieerde mappings]].
 +
<section end=Inputenoutputformaten />
 +
 +
 +
==Mappings per informatiestandaard==
  
−
==Mappings en transacties==
 
−
Dze 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.
 
 
===Medicatieproces (MP)===
 
===Medicatieproces (MP)===
−
{| class="wikitable sortable"
+
[[mp:Mappingarchitectuur| Link naar mappings voor Medicatieproces]]
−
| style="background-color: #1F497D;; color: white; font-weight: bold; text-align:center; width:275px;"  | Van || style="background-color: #1F497D;; width:275px; color: white; font-weight: bold; text-align:center;" | Dataset transactie  || style="background-color: #1F497D;; color: white; font-weight: bold; text-align:center;width:600px;" | Naar
 
−
|-
 
−
|rowspan="2"| [[Mappings/MP612Dispense_2_MP9MedicationInformation|MP-6.12 opleveren verstrekkingenlijst]]  
 
−
|rowspan="2"| MP-9 beschikbaarstellen medicatiegegevens || [[Mappings/MP9MedicationInformation_2_MP9-FHIR|MP-9 beschikbaarstellen medicatiegegevens in FHIR]]
 
−
|-
 
−
| [[Mappings/MP9MedicationInformation_2_MP9-CDA|MP-9 beschikbaarstellen medicatiegegevens in HL7v3 (CDA of organizer met CDA-statements)]]
 
−
|-
 
−
|rowspan="2"| [[Mappings/MP9-CDA_2_MP9Prescription|MP-9 sturen medicatievoorschrift in CDA]]
 
−
|rowspan="2"| MP-9 sturen medicatievoorschrift || MP-6.12 Verzoek uitvoeren voorschrift in HL7v3 messaging ('PORX')
 
−
|-
 
−
|| [[Mappings/MP9Prescription_2_MP9-CDA|MP-9 sturen medicatievoorschrift in CDA]]
 
−
|}
 
  
 
===Geboortezorg (GZ) ===
 
===Geboortezorg (GZ) ===
−
{| class="wikitable sortable"  
+
[[Gebz:Mappingarchitectuur| Link naar mappings voor Geboortezorg]]
−
| style="background-color: #1F497D;; color: white; font-weight: bold; text-align:center;width:275px;" | Van || style="background-color: #1F497D;; width:275px; color: white; font-weight: bold; text-align:center;" | Dataset transactie  || style="background-color: #1F497D;; color: white; font-weight: bold; text-align:center;width:500px;" | Naar
+
 
−
|-
+
===Contraindicaties en overgevoeligheden (CIO)===
−
|| nvt || Kernset aanleverbericht 2.2 || [[Mappings/GZ22Kernset_2_GZ22-HL7v3|Kernset 2.2 in HL7v3 CareProvision]]
+
[[mp:IcaMappingarchitectuur| Link naar mappings voor Contraindicaties en overgevoeligheden]]
−
|-
+
 
−
|| nvt || Kernset Geboortezorg 2.3 || Kernset Geboortezorg 2.3 in HL7v3 CareProvision
+
<br>
 +
 
 +
= Documenthistorie =
 +
{| class="wikitable"
 +
|-style="background-color: #1F497D;; color: white; text-align:left;"  
 +
| Datum||Omschrijving
 +
|-style="vertical-align:top; background-color: #E3E3E3;;"
 +
|style="background-color: white;"| 2023-03-07
 +
|style="background-color: white;"| Paragraaf 5: Verplaatsing mapping tabellen naar eigen wiki namespaces van de betreffende informatiestandaard.
 
|}
 
|}
 +
<br><br>
 +
[[Categorie:Mappings]]

Huidige versie van 9 mrt 2023 om 10:44


Naar nictiz.nl

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 per informatiestandaard

5.1 Medicatieproces (MP)

Link naar mappings voor Medicatieproces

5.2 Geboortezorg (GZ)

Link naar mappings voor Geboortezorg

5.3 Contraindicaties en overgevoeligheden (CIO)

Link naar mappings voor Contraindicaties en overgevoeligheden


6 Documenthistorie

Datum Omschrijving
2023-03-07 Paragraaf 5: Verplaatsing mapping tabellen naar eigen wiki namespaces van de betreffende informatiestandaard.



Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=Mappingarchitectuur&oldid=161530"