Verduidelijking nodig (issue-id 2.16.840.1.113883.2.4.3.11.60.100.6.34) |
Laatst toegekend aan 'Alexander Henket' |
Issue | Mapping van huisletters | |
---|---|---|
Id | jgz-issue-34 | |
Type | Verduidelijking nodig | |
Status | ![]() |
|
Prioriteit | normaal | |
Object(en) | Template Adres kind jgz-template-10222 (2012‑08‑01) | |
Template Adres ouder/verzorger jgz-template-10223 (2012‑08‑01) | ||
![]() |
![]() |
|
Auteur | Alexander Henket | |
Omschrijving | Uitgevoerd | |
![]() |
![]() |
|
Auteur | Alexander Henket | |
Omschrijving | Volgens het logisch ontwerp GBA versie 3.7 is huisletter inderdaad 1 alfabetisch teken
met waardenbereik a-z A-Z. Echter: huisnummertoevoeging is 1-4 tekens alfanumeriek.
Ik ken geen voorbeeld van een adres zonder huisletter maar wel met een huisnummertoevoeging
van 1 letter, maar dat theoretische geval zou dan tot verkeerde interpretatie leiden. Verder vind ik het een prima voorstel wat ik als zodanig kan overnemen in de specificatie zonder verdere vertraging. |
|
![]() |
![]() |
|
Auteur | Kyndylan Nienhuis | |
Omschrijving | ![]() Het is duidelijk dat de realisatie van een extra adreselement lang gaat duren. Om binnen de JGZ toch de adreselementen apart door te kunnen geven heb ik het volgende voorstel.
Export
Import
Onder de aanname dat huisletters altijd uit één karakter bestaan en huisnummertoevoegingen altijd uit meer dan één, is dit een eenduidige mapping. |
|
![]() |
![]() |
|
Auteur | Alexander Henket | |
Omschrijving | Er is 1 veld dat altijd ambigu blijft en dat is hl7:houseNumber: systemen die geen
gescheiden huisnummergegevens hebben zullen alles daar in plaatsen, terwijl systemen
die wel alles gescheiden leveren, dit veld + de overige elementen zullen gebruiken.
Voor een ontvanger is hl7:houseNumber dus een lastig veld, maar daar zal mee geleefd
moeten worden: afgezien van de JGZ is er geen enkele zorginstelling die zo ver gaat
in de scheiding van huisnummerdelen en dus zal naarmate het aantal communicatiepartners
toeneemt ook de 'vervuiling' toenemen. Het enige twistpunt is volgens mij de scheiding van huisletter en huisnummertoevoeging. Hiervoor was in de oorspronkelijke mapping op HL7 ook geen scheiding voorzien overigens. De oplossing is niet eenvoudig: er zijn geen HL7-adreselementen die specifiek voor deze scheiding zijn bedoeld - buildingNumberSuffix is wat er oorspronkelijk (BDS 3.1) ook voor beide velden was bedacht. Er zijn nog wel meer adreselementen die we ervoor zouden kunnen aanwijzen, maar dat kan alleen als we de basisspecificatie voor de gehele Nederlandse zorg daarop aanpassen zodat iedereen op dezelfde wijze werkt/kan werken. Een JGZ-specifieke afspraak is hier onmogelijk. Nogmaals: de rest van de zorginstelling in Nederland werken via de SBV-Z met de GBA-gegevens. Deze kent 2 toegangsmethoden: SBVZ-XML en HL7v3. In de HL7-implementatie bestaat de scheiding tussen huisletter en huisnummertoevoeging daar ook niet. Ook die implementatie zou dan moeten worden bijgewerkt met de nieuwe specificatie. Ik wil dat allemaal in gang zetten, maar het zal lang duren en ik wil toch graag zeker weten of het sop de kool waard is. We bereiken er namelijk alleen de scheiding tussen huisletter en huisnummertoevoeging mee: <houseNumber>11</houseNumber> <buildingNumberSuffix>A BIS</buildingNumberSuffix> <additionalLocator>to</additionalLocator> versus <houseNumber>11</houseNumber> <buildingNumberSuffix>A</buildingNumberSuffix> <????>BIS</????> <additionalLocator>to</additionalLocator> maar ook altijd de mogelijkheid op: <houseNumber>11 A BIS</houseNumber> <additionalLocator>to</additionalLocator> of <houseNumber>11 A BIS to</houseNumber>afhankelijk van de communicatiepartners en de ouderdom/herkomst van de gegevens in het bronsysteem. |
|
![]() |
![]() |
|
Auteur | Kyndylan Nienhuis | |
Omschrijving | ![]() In de vergadering van 27-08 is het issue verder verduidelijkt. Hieronder verslag. Er moet een mapping naar het HL7-bericht bedacht worden voor het geval dat alle adres-elementen gescheiden zijn (een aparte huisnummer, huisletter, huisnummertoevoeging en aanduiding bij huisnummer). Het is belangrijk dat de mapping omgedraaid kan worden: uit een HL7-bericht moeten eenduidig de aparte elementen gehaald kunnen worden. De huidige voorstellen gaan bij dit laatste punt mis: als de huisletter en de huisnummertoevoeging samen in een buildingNumberSuffix moeten, dan is het tijdens het importeren niet meer duidelijk welk deel van de buildingNumberSuffix bij de huisletter hoort en welk deel bij de huisnummertoevoeging. Het alternatieve voorstel is om de huisnummertoevoeging en de aanduiding bij huisnummer in aparte additionalLocators te stoppen (er kunnen dus twee additionalLocators voorkomen), maar dan is het bij het importeren niet meer duidelijk of een additionalLocator bij een huisnummertoevoeging hoort of bij een aanduiding bij huisnummer. Voor dit issue speelt het geen rol of een verzendend systeem de gegevens gescheiden
kan doorgeven of niet. Wat er met niet-gescheiden elementen gaat gebeuren (bijvoorbeeld
of er huisletters in een BDS-huisnummer mogen staan of niet), is namelijk een afspraak
die over de BDS gaat. |
|
![]() |
Toegekend aan Alexander Henket (id#2) op 2013‑08‑26 17:39:12 | |
Auteur | toegekend door Claartje Hülsmann (id#11) | |
Omschrijving | Zie melding hieronder. |
|
![]() |
![]() |
|
Auteur | Claartje Hülsmann | |
Omschrijving | In de Basiscomponentengids HL7 versie 2.2 wordt nog niet gesproken over een additionalLocator,
in de 2.3 versie wel. Hierin geldt het volgende: het huisnummer (14 indien 14a doorgegeven
moet worden) komt in houseNumber, in buildingNumberSuffix komt de a van 14a, en in
additionalLocator komt een huisnummertoevoeging zoals bijvoorbeeld t.o - tegenover. In het voorbeeld bij R_PatientNL-JGZ komt deze additionalLocator ook voor, daar staat: <addr> <streetName>Stubtekst</streetName> <houseNumber>Stubtekst</houseNumber> <buildingNumberSuffix>Stubtekst</buildingNumberSuffix> <additionalLocator>to</additionalLocator> <postalCode>Stubtekst</postalCode> <county>Stubtekst</county> <city>Stubtekst</city> <country>Stubtekst</country> <desc>Stubtekst</desc> </addr> (Zie http://decor.nictiz.nl/jeugdgezondheidszorg/jgz-html-20130711T155558/tmp-2.16.840.1.113883.2.4.6.10.100.131-2012-08-01T000000.html ) Op dit moment bevat houseNumber in de JGZ specificaties echter alleen de mogelijkheid om of 14 of a mee te geven in houseNumber (jgz-bds-element12 of 13), en houseNumber mag 0 of 1 keer voorkomen. Bij jgz-bds-element13 staat overigens een voorbeeld genoemd met een nummer en een letter samen. (In de tekst), zie http://decor.nictiz.nl/jeugdgezondheidszorg/jgz-html-20130711T155558/tmp-2.16.840.1.113883.2.4.6.10.100.131-2012-08-01T000000.html In de HL7 specificaties van de basiscomponenten staat voor buildingNumberSuffix gespecificeerd: "a" van bijvoorbeeld 14a (dus een huisletter). In de JGZ specificaties staat voor buildingNumberSuffix gespecificeerd: "bis" (dit is een huisnummertoevoeging). Ik stel voor: houseNumber kan bevatten: "huisnummer" of "huisnummer en huisletter" of "huisnummer en huisletter en huisnummertoevoeging" of "huisnummer en huisletter en huisnummertoevoeging en aanduiding bij huisnummer" (alle andere varianten dan de eerste alleen als het echt niet anders kan) buildingNumberSuffix kan bevatten: "huisletter" additionalLocator kan bevatten: "huisnummertoevoeging" of "aanduiding bij huisnummer" of "huisnummertoevoeging en aanduiding bij huisnummer" In dit voorstel kan houseNumber dus nog steeds maar een keer voorkomen, de samengestelde vormen zijn in de typering houseNumber als één typering opgenomen. additionalLocator kan eventueel 2 keer voorkomen, als een huisnummertoevoeging en een aanduiding bij huisnummer separaat meegegeven moeten worden (dit heeft de voorkeur). Hierbij ken ik dit issue toe aan Alexander om zijn mening en toelichting op de huidige specificaties te geven. |
|
![]() |
![]() |
|
Auteur | Claartje Hülsmann | |
Omschrijving | Hierbij de beschrijving in de eerdere e-mail uitwisseling waar Kyndylan naar refereert
(citaat Alexander): De specificatie op huisletter bestond al in de vorm van het element "buildingNumberSuffix". Indien het bronsysteem deze gescheiden heeft dan kan deze ook gescheiden worden doorgegeven. Als het bronsysteem deze niet heeft echter, dan blijft de mogelijkheid bestaan deze samen met het huisnummer door te geven in het element houseNumber.
Dat was altijd al de intentie van de specificatie, maar stond er zodanig dat ik er zelf ook overeen keek. Ik heb daarom de omschrijving bij houseNumber als volgt aangepast:
Het element houseNumber moet het het huisnummer bevatten. Het huisnummer kan niet-numerieke gedeelten bevatten die het adres mede identificeren, bijv. "23a", maar alleen als de bron deze niet gescheiden kan aanbieden. Huisletter dienen indien mogelijk in het element buildingNumberSuffix te worden doorgegeven. Gegevens zoals "to" (woonboten) of "3 hoog achter" maken geen deel uit van dit attribuut. Dit type gegevens is elders in het Adres datatype opgenomen.
Uiteraard betekent e.e.a. dat zodra huisnummer en huisletter eenmaal aan elkaar vast zitten, dat scheiding ervan niet meer (zo makkelijk) lukt. |
|
![]() |
![]() |
|
Auteur | Kyndylan Nienhuis | |
Omschrijving |
Bevinding:
Volgens de handleiding mappen zowel element 13 huisletter als 14 huisnummertoevoeging naar het HL7-element buildingNumberSuffix. In dit element is slechts plaats voor één waarde. Hoe moeten de elementen gecombineerd worden, zodat ze tijdens het importeren weer eenduidig uit elkaar kunnen worden gehaald? Voorstel:Een mogelijke oplossing is als volgt. We kiezen een karakter dat niet kan voorkomen in een huisletter of huisnummertoevoeging, en plakken de twee elementen in een vaste volgorde aan elkaar met dat karakter er tussen. Bij het importeren kan de waarde gesplitst worden aan de hand van het karakter, en omdat de volgorde vaststaat kunnen beide helften als huisletter en huisnummertoevoeging geïmporteerd worden. Nadere toelichting:In een eerdere e-mailuitwisseling is besloten dat de huisletter niet meer in een houseNumber
komt, maar in een buildingNumberSuffix. Dit lost het probleem van de ambiguïteit echter
niet op. |