PN in de CMET E Person NL gebruik van het datatype versie 3

Return to InM actie punten

• meeting: TC-InM
• Author: Adri Burggraaff
• Status: Final - subject for discussion in TC

Inleiding

Email vraag 16-02-2010 van Yvonne Pijnacker Hordijk: Ik heb een vraag over het gebruik van het datatype PN in de CMET E_Person NL.

Name heeft hier een cardinaliteit van [0..1]. Nu wil ik van een kind een roepnaam, voorletters, gevoerde achternaam, maar ook de officiële voornamen en geslachtsnaam doorgeven.Dus eigenlijk meerdere Person Names met verschillende use. Dit kan nu niet.
Wanneer je het echter in één Person Name zet, gelden de volgorde regels van de person name parts zoals beschreven in de IH basiscomponenten. Dit levert in het geval van het kind een rare weergave op.
Stel het kind heeft als officiële voornaam: Johanna Dewina Theodora

Roepnaam: Dewi
Initialen: D. Th.
Gevoerde achternaam : Bakker
Officiële achternaam: Heijnen

Wat is nou de juiste en beste manier om dit door te geven?

Voorstel

Er zijn twee problemen:

1. Doorgeven van initialen én voornamen
2. Het feit dat er maar één naam in het huidige Nederlandse model kan worden gevoerd.

Er zijn dus ook twee voorstellen: 1. Initialen zijn een afgeleid gegeven van de voornamen. Deze hoef je dus niet separaat te communiceren. Namen die beginnen met Th worden ook altijd afgekort tot Th en niet T. Officiële namen krijgen use code OR en roepnamen krijgen use code L volgens IH Basiscomponenten v2.2:

<name use="OR">
   <given>Johanna</given>
   <given>Dewina</given>
   <given>Theodora</given>
   <family qualifier="BR">Heijnen</family>
</name>
<name use="L">
   <given>Dewi</given>
   <family>Bakker</family>
</name>

2. Uitbreiding van de CMET E_PersonNL zodat er meer namen zijn toegestaan. Als JGZ zijn eigen CMET erop nahoudt, dan die uitbreiden. In beide gevallen moet het artefact een nieuwe identificatie krijgen, omdat de wijziging niet backward compatible is

Discussie

16-02 MvdZ: Kan iemand uitleggen waarom Person NL maar 1 name toelaat? De HL7 universal versie laat [0..*] toe. Wat mij ook logisch lijkt. Want dan kan je verschillende namen tegelijk doorgeven. E.g. Legal of License. En voor presentatie kies je er dan 1 tje. Ik snap dat dit je probleem niet oplost. Ik zit hier ook mee.

17-02 Tom: Ik kan wel een beetje historisch perspectief geven, want de [0..1] was wel degelijk een bewuste keuze. Natuurlijk zijn er situaties denkbaar waarin een verzender verschillende naamvarianten wil doorgeven (officiële voornamen vs. roepnaam is wel het klassieke voorbeeld), maar de vraag is of we altijd kunnen verwachten dat een ontvanger die ook apart kan opslaan. Aangezien V3 (nog) geen aparte conformance claims voor zenders en ontvangers geldt, zou dat nl. wel de consequentie zijn. Maar ik ken maar weinig systemen die meerdere namen per patiënt kunnen opslaan.

Volgens mij is nu de praktijk dat de situatie met officiële voornamen en roepnaam toch wordt opgelost door beide in één naamelement op te nemen. Inderdaad staat dat op gespannen voet met het principe van sequentiële weergave.
Ik zou er best voor zijn om de cardinaliteit te verhogen, maar dan moeten wewel de kanttekening maken dat een ontvanger allen namen moet kunnen ‘verwerken’, maar minimaal één naam (naar keuze) moet kunnen opslaan.
We zouden dit kunnen aanpassen in de v2.3 versie van de gids.

PS1 Dit is niet forwards compatible (een nieuw bericht kan worden aangewezen door een oud systeem).
PS2 In het voorbeeld van Yvonne zouden de voorletters J.D.Th. moeten zijn(ook de J moet er bij staan). Met officiële voornamen en voorletters ontstaat overigens sowieso een lastige situatie, want daar is hoe dan ook sprake van redundantie. Ze horen namelijk allebei bij de officiële naam en toch wil je ze niet allebei opnemen in de weergave.

Irma: Dit is nu precies de reden waarom ik er niet voor ben de internationale specs te veel in te perken. Ontvangende systemen houden nu slechts rekening met 1 naam, omdat er op dat moment nog geen systeem mee deed dat meerdere namen ondersteunde. Nu krijg je dus problemen met ondersteuning van verschillende versies van de gids. Hoe moet dat worden gemanaged?

Tom: Wel eens met je uitgangspunt, maar deze tekst staat er toch echt al een jaar of 4 en is door twee ballots heengekomen. Bij Nictiz (AORTA) wordt dat gemanaged door een versiekenmerk in de berichten op te nemen, waardoor de ontvanger weet tegen welke spec’s een bericht gebouwd is (en dus of hij kan/moet verwachten dat er meer dan één naam is).

Alexander: Maar hier gaat het om een CMET die een nieuwe versie zou krijgen waardoor (nieuwe versies van) interacties de keuze krijgen welke versie van de CMET ze koppelen. Zo werkt het internationaal althans. Zo lang de oude versie van de CMET nog gewoon geldig blijft, weet ik ook niet of je in IH BC 2.x dan niet beide varianten zou moeten beschrijven.
Nu we bij Nictiz langzaam werk maken van versiebeheer zou ik het jammer vinden als IH BC met zijn artefacten daarin achter zou blijven. Bij Nictiz moest ik sowieso nog een voorstel daarvoor opstellen. Ik stel me voor dat ditzelfde voorstel ook bij Stg. HL7 gelezen, becommentarieerd en gedragen kan worden, zodat er niet twee snelheden ontstaan.

18-02 Tom: Prima, dat zou een legitieme aanpak zijn. Ik stel voor dat de naam van de CMET dan de huidige naam met achtervoegsel 02 wordt. Vanaf nu gaan we dan die laatste twee posities gebruiken om verschillende versies te onderscheiden. Wat de documentatie betreft zou ik niet een volledig aparte beschrijving van de 02 variant maken, maar duidelijk in de tekst aangeven op plaatsen waar er verschillen tussen beide versies zijn. Alexander, kun jij t.z.t. zorgen dat de richtlijnen voor versiebeheer van Nictiz op de agenda van de TSC komen, want dit lijkt me een werkgroep overstijgend onderwerp.

Maar…nu we hier toch over bezig zijn… Yvonne, volgens mij gebruiken jullie feitelijk een andere CMET toch, speciaal voor JGZ? Of is dat alleen de R_Patient en is de E_Person wel gewoon de NL variant? Misschien is dit een mooie gelegenheid om alle extra features die jullie in het JGZ project hebben ontdekt in een update van de algemene NL variant te gieten. Zijn er meer punten voor E_Person?

André: Ja, er zijn nog meer punten voor E_Person die vanuit het e-Perinatologieproject naar voren zijn gekomen. Kai heeft deze gisteren al met Alexander besproken. Dat kan dan meteen worden meegenomen. Verder heb ik een document geschreven waarin de ‘meerling’ aspecten staan beschreven. Dit nadert een finaal stadium, alleen moet daarbij nog gekeken worden welke internationale coderingen bij de betreffende concepten passen. Het lijkt mij goed dat dat dan ook een plaats krijgt bij E_Person NL.

Voorlopig besluit in TC InM

In de Hl7NL TC InM is op 9 maart je vraag besproken. De TC InM verwijst de vraag na overleg door naar de TC-AM. De TC-AM gaat deze vraag behandelen in hun eerstvolgende out of cycle meeting woensdag 7 april as. T.z.t. komt het dan ook weer terug in de TC-InM.
15 maart 2010