Difference between revisions of "XPN subveld 11 Name assembly order"
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> | <br> |
Revision as of 21:19, 13 December 2010
Return to InM V2 voorstellen
- meeting: TC-InM
- Author: Adri Burggraaff.
- Status: Draft, editing by author
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.
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.