This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "XPN subveld 11 Name assembly order"

From HL7Wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
*meeting: TC-InM
 
*meeting: TC-InM
 
*Author: Adri Burggraaff.
 
*Author: Adri Burggraaff.
*Status: '''Draft, editing by author'''
+
*Status: '''FINAL - for discussion in TC'''
  
 
==Inleiding==
 
==Inleiding==
Line 47: Line 47:
 
01-12-2010 12:47 RS: Ik denk dat een solide mapping van de GBA naamdelen naar het v2 datatype zo snel mogelijk in de gidsen moet worden opgenomen. En ik bedoel dan zelfs een expliciete tabel met een mapping, beide kanten op indien
 
01-12-2010 12:47 RS: Ik denk dat een solide mapping van de GBA naamdelen naar het v2 datatype zo snel mogelijk in de gidsen moet worden opgenomen. En ik bedoel dan zelfs een expliciete tabel met een mapping, beide kanten op indien
 
mogelijk.<br>
 
mogelijk.<br>
Gegeven de BSN verificatieplicht moet men feitelijk in staat zijn deze mapping uit te voeren. Wat mij betreft nog deze cyclus meenemen, in H2 en H3.<br>\
+
Gegeven de BSN verificatieplicht moet men feitelijk in staat zijn deze mapping uit te voeren. Wat mij betreft nog deze cyclus meenemen, in H2 en H3.<br>
 
<br>
 
<br>
 
01-12-2010 14:02 IJ: Ik denk niet dat dit van belang is voor de BSN verificatieplicht. Het SBV-Z bevat geen partnernamen, alleen eigen namen, dus daarvoor is het toch niet relevant?<br>
 
01-12-2010 14:02 IJ: Ik denk niet dat dit van belang is voor de BSN verificatieplicht. Het SBV-Z bevat geen partnernamen, alleen eigen namen, dus daarvoor is het toch niet relevant?<br>
 
Maar het is natuurlijk een hoop geknoei als de afzender de naamonderdelen gescheiden heeft, ze conform de voorkeur tot een samengestelde naam samenvoegt en de ontvanger dan maar weer moet uitvogelen hoe die voorkeur eruit zag. Dus ik zou het ook fijn vinden als we dit konden meenemen in de 2010 update.<br>
 
Maar het is natuurlijk een hoop geknoei als de afzender de naamonderdelen gescheiden heeft, ze conform de voorkeur tot een samengestelde naam samenvoegt en de ontvanger dan maar weer moet uitvogelen hoe die voorkeur eruit zag. Dus ik zou het ook fijn vinden als we dit konden meenemen in de 2010 update.<br>
 +
<br>
 +
01-12-2010 15:07 RS: Het SBV-Z biedt die mogelijkheid inderdaad (nog) niet, maar allen die 'een wettelijke grondslag hebben om zorggegevens te verzamelen' (bijv.RIVM, zorgloketten, WMO) hebben een andere link naar de GBA, en die krijgen wel de partnernaam.<br>
 +
<br>
 +
14-12-2010 09:59 IJ: Ik heb in H3 de volgende (concept) tekst opgenomen:<br>
 +
name assembly order: hiermee kan worden aangegeven in welke volgorde de persoon de eventuele combinatie van eigen naam en naam partner wenst te gebruiken. Basis voor de waarden is de NEN tabel, voorafgegaan door NL om aan te geven dat het een Nederland-specifieke waarde betreft.<br>
 +
Code          Omschrijving<br>
 +
NL0            onbekend<br>
 +
NL1            eigen naam<br>
 +
NL2            naam partner<br>
 +
NL3            naam partner gevolgd door eigen naam<br>
 +
NL4            eigen naam gevolgd door naam partner<br>
 +
<br>
 +
'''24-03-2011''', Willem van Wijngaarden:
 +
Ik heb inmiddels antwoord vanuit NEN. Het komt erop neer dat de tabel uit het oorspronkelijke voorstel (op de Wiki http://wiki.hl7.org/index.php?title=XPN_subveld_11_Name_assembly_order) overeenkomstig is met NEN1888:2002. Het gaat om deze waarden:<br>
 +
<br>
 +
0              onbekend<br>
 +
1              eigen naam<br>
 +
2              naam partner<br>
 +
3              naam partner gevolgd door eigen naam<br>
 +
4              eigen naam gevolgd door naam partner<br>
 +
<br>
 +
<br>
 +
Vektis heeft daarentegen diverse codetabellen op basis van NEN1888:2002 gedefinieerd. Tom heeft daar een voorbeeld van aangehaald waarbij de waarde ‘9’ i.p.v. de waarde ‘0’ voor onbekend werd gebruikt. Ik heb ook een Vektis-voorbeeld aangehaald waarbij aan de NEN1888:2002 lijst een code ‘5’ voor pseudoniem is toegevoegd die het meest uitgebreid en compleet lijkt (namelijk COD829, zie http://ei.vektis.nl/WespCodelijstenDetail.aspx?Co_Ge_Code=COD829&Co_Or_Code=NEN1):<br>
 +
<br>
 +
0              onbekend<br>
 +
1              eigen naam<br>
 +
2              naam partner<br>
 +
3              naam partner gevolgd door eigen naam<br>
 +
4              eigen naam gevolgd door naam partner<br>
 +
5              pseudoniem<br>
 +
<br>
 +
NEN geeft aan dat zij niet verantwoordelijk zijn voor de codetabellen van Vektis en dat deze niet in samenwerking/samenspraak met hun tot stand zijn gekomen. Ook geeft NEN aan dat instanties hun norm kunnen gebruiken, maar daar eigen codes aan kunnen toevoegen zoals blijkbaar door Vektis is gedaan.<br>
 +
<br>
 +
Ik denk dat wij als Stichting HL7 Nederland zullen moeten kiezen of we de zuivere NEN1888:2002 aanhouden (waarvan ik bevestigd heb gekregen dat er sinds 2002 tot nu toe nog geen update van heeft plaats gevonden door NEN) of dat we de iets uitgebreidere Vektis COD829 aanhouden die 1 aanvulling t.o.v. NEN1888:2002 bevat. Het zou mijn voorkeur hebben om de zuivere NEN1888:2002 aan te houden, omdat het er volgens mij omgaat dat een zender de mogelijkheid heeft om de wijze waarop de naam is samengesteld te kunnen aangeven in XPN subveld 11 name assembly order. Een pseudoniem kan ook worden aangegeven met XPN subveld 7 name type code ‘N’ (nickname).<br>
 +
<br>
 +
Grtn, Willem.<br>
 
<br>
 
<br>

Latest revision as of 20:48, 18 April 2011

Return to InM V2 voorstellen

  • meeting: TC-InM
  • Author: Adri Burggraaff.
  • Status: FINAL - for discussion in TC

Inleiding

Dit voorstel is t.b.v. HL7 NL TC-InM en gaat over het datatype XPN en moet leiden tot een besluit dat gaat gelden voor alle TC's. De TC-AM is bezig om de openstaande zaken uit de themamiddag te verwerken in een update 2010 voor onze hoofdstukken. Een van de punten op onze lijst is om de naamopbouw op een slimmere manier door te geven dan door de elementen uit de samengestelde naam te ontleden en te vergelijken met hoe ze in de losse onderdelen staan. In het datatype XPN zit een element Name assembly order, dat er goed voor geschikt is. Helaas voldoen de waarden in de tabel niet aan wat in Nederland gewenst is.

Voorstel


TC-AM: Ons voorstel zou zijn om de NEN of de GBA codes hiervoor te gebruiken voorafgegaan door NL, om duidelijk aan te geven dat het Nederland specifieke codes betreft (zie onderstaande waarden). Dit is een wijziging die we strikt genomen niet zelfstandig kunnen doorvoeren omdat het ook H2 consequenties heeft, vandaar dat ik graag van de TC-IM wil horen wat men ervan vindt. Is dit een haalbare wijziging om mee te nemen voor dit jaar of moet het een jaar wachten? Er is een lid dat wacht op het antwoord, dus als het nog zou lukken zou dat mooi zijn.

Willem van Wijngaarden:ik zou nog een tabel sturen voor XPN subveld 11 ‘Name assembly order’. Na enige zoekwerk heb ik die gevonden (op de site van http://www.justid.nl/ in het Gegevenswoordenboek Vreemdelingenketen dat blijkbaar gebruik maakt van dezelfde tabel).

Tabel: Aanduiding naamgebruik
Beschrijving: De aanduiding van de vaststelling van de wijze van het gebruik van persoonlijke gegevens zoals deze door een persoon bij aanschrijving wordt gewenst.
Herkomst: NEN 1888:2002
Bron: NEN & GBA
Toelichting: Voor uitwisseling heeft het gebruik van betekenisloze codes de voorkeur. Voor dit element betekent dit het gebruik van de NEN-codering. Voor de uitwisseling met de GBA moet echter de GBA-codering worden gebruikt. Deze codering is in de gebruikte tabel opgenomen.

Aanduiding naamgebruik


Code NEN Code GBA Omschrijving
0 - onbekend
1 E eigen naam
2 P naam echtgenoot of geregistreerd partner
3 V naam echtgenoot of geregistreerd partner gevolgd door eigen naam
4 N eigen naam gevolgd door naam echtgenoot of geregistreerd partner


Aangezien het een NEN-codering is neem ik aan dat dit een volledige set aan waarden is en dat we die zonder meer kunnen gebruiken binnen HL7. Ik kan in elk geval geen andere waarden bedenken dan de 5 items die hier boven worden genoemd.

Discussie

01-12-2010 12:47 RS: Ik denk dat een solide mapping van de GBA naamdelen naar het v2 datatype zo snel mogelijk in de gidsen moet worden opgenomen. En ik bedoel dan zelfs een expliciete tabel met een mapping, beide kanten op indien mogelijk.
Gegeven de BSN verificatieplicht moet men feitelijk in staat zijn deze mapping uit te voeren. Wat mij betreft nog deze cyclus meenemen, in H2 en H3.

01-12-2010 14:02 IJ: Ik denk niet dat dit van belang is voor de BSN verificatieplicht. Het SBV-Z bevat geen partnernamen, alleen eigen namen, dus daarvoor is het toch niet relevant?
Maar het is natuurlijk een hoop geknoei als de afzender de naamonderdelen gescheiden heeft, ze conform de voorkeur tot een samengestelde naam samenvoegt en de ontvanger dan maar weer moet uitvogelen hoe die voorkeur eruit zag. Dus ik zou het ook fijn vinden als we dit konden meenemen in de 2010 update.

01-12-2010 15:07 RS: Het SBV-Z biedt die mogelijkheid inderdaad (nog) niet, maar allen die 'een wettelijke grondslag hebben om zorggegevens te verzamelen' (bijv.RIVM, zorgloketten, WMO) hebben een andere link naar de GBA, en die krijgen wel de partnernaam.

14-12-2010 09:59 IJ: Ik heb in H3 de volgende (concept) tekst opgenomen:
name assembly order: hiermee kan worden aangegeven in welke volgorde de persoon de eventuele combinatie van eigen naam en naam partner wenst te gebruiken. Basis voor de waarden is de NEN tabel, voorafgegaan door NL om aan te geven dat het een Nederland-specifieke waarde betreft.
Code Omschrijving
NL0 onbekend
NL1 eigen naam
NL2 naam partner
NL3 naam partner gevolgd door eigen naam
NL4 eigen naam gevolgd door naam partner

24-03-2011, Willem van Wijngaarden: Ik heb inmiddels antwoord vanuit NEN. Het komt erop neer dat de tabel uit het oorspronkelijke voorstel (op de Wiki http://wiki.hl7.org/index.php?title=XPN_subveld_11_Name_assembly_order) overeenkomstig is met NEN1888:2002. Het gaat om deze waarden:

0 onbekend
1 eigen naam
2 naam partner
3 naam partner gevolgd door eigen naam
4 eigen naam gevolgd door naam partner


Vektis heeft daarentegen diverse codetabellen op basis van NEN1888:2002 gedefinieerd. Tom heeft daar een voorbeeld van aangehaald waarbij de waarde ‘9’ i.p.v. de waarde ‘0’ voor onbekend werd gebruikt. Ik heb ook een Vektis-voorbeeld aangehaald waarbij aan de NEN1888:2002 lijst een code ‘5’ voor pseudoniem is toegevoegd die het meest uitgebreid en compleet lijkt (namelijk COD829, zie http://ei.vektis.nl/WespCodelijstenDetail.aspx?Co_Ge_Code=COD829&Co_Or_Code=NEN1):

0 onbekend
1 eigen naam
2 naam partner
3 naam partner gevolgd door eigen naam
4 eigen naam gevolgd door naam partner
5 pseudoniem

NEN geeft aan dat zij niet verantwoordelijk zijn voor de codetabellen van Vektis en dat deze niet in samenwerking/samenspraak met hun tot stand zijn gekomen. Ook geeft NEN aan dat instanties hun norm kunnen gebruiken, maar daar eigen codes aan kunnen toevoegen zoals blijkbaar door Vektis is gedaan.

Ik denk dat wij als Stichting HL7 Nederland zullen moeten kiezen of we de zuivere NEN1888:2002 aanhouden (waarvan ik bevestigd heb gekregen dat er sinds 2002 tot nu toe nog geen update van heeft plaats gevonden door NEN) of dat we de iets uitgebreidere Vektis COD829 aanhouden die 1 aanvulling t.o.v. NEN1888:2002 bevat. Het zou mijn voorkeur hebben om de zuivere NEN1888:2002 aan te houden, omdat het er volgens mij omgaat dat een zender de mogelijkheid heeft om de wijze waarop de naam is samengesteld te kunnen aangeven in XPN subveld 11 name assembly order. Een pseudoniem kan ook worden aangegeven met XPN subveld 7 name type code ‘N’ (nickname).

Grtn, Willem.