II datatype: maximumlengte vaststellen voor II.extension
Return to InM V3 voorstellen
- meeting: TC-InM
- Author: Alexander Henket
- Status: Closed
Inleiding
Er is nooit formeel een maximumlengte gesteld aan de lengte van een Instance Identifier (II) extension. Wel zijn er informeel allerlei maximums in diverse (registratie)systemen.
Use Case
Vanuit diverse leveranciers is bij Nictiz aangegeven dat bij het bouwen van applicaties een bepaalde ruimte moet worden gereserveerd in de database. Doordat er geen maximum, of andere richtlijn is, wordt per leverancier een arbitrair maximum gesteld. Dit kan tot compatibiliteitsproblemen leiden.
Voorstel
Er zijn twee voorstellen ten behoeve van IH Basicomponentengids versie >= 2.3:
- Het stellen van een maximulengte aan de Instance Identifier (II) extension
- Het vaststellen van de maximumlengte van 64 tekens
Argumentatie
De use case is voor Nictiz voldoende reden om te zoeken naar breder draagvlak. De vraag is ook voorgelegd op de internationale lijsten en diverse antwoorden kwamen daarop terug:
- Canada: 200 tekens voor zowel root als extension (bron: Lloyd McKenzie)
- Peter Scholz: ziet geen reden voor het stellen van een maximum
- UUID is 64 tekens
- GUID kan als 40 tekens hex worden weergegeven
- Binnen een ruime set testberichten zoals nu uitgewisseld binnen de AORTA was het maximum 46 tekens (bron: Alexander Henket)
Het laatste punt biedt in elk geval de garantie dat het niet tot implementatieproblemen leidt in bestaande implementaties.
Discussie
- Ik ben tegen het stellen van een maximum (hoe groot of klein ook) voor extensies. Als er al, om implementatieredenen, tot een maximum zou worden besloten, dan zou dat maxumum ruim moeten zijn. 64 lijkt me te kort. Rene spronk 14:51, 17 November 2009 (UTC)
- Ik zie ook geen reden om een maximum vast te stellen, te meer omdat er in HL7 formeel geen minimum of maximum lengte bestaat.De lengtes die worden aangegeven zijn alleen maar bedoelt als voorgestelde lengte. Als we een advies afgeven zou ik kiezen voor 128 als max. lengte. Adri burggraaff 23:32 uur, 2010 januari 03 (UTC)
- Dit is lastig stemmen, want er bestaat niet zoiets als een OID.extension... Wordt daarmee bedoeld de extension van het data type II? Of wordt ermee bedoeld zowel de root (OID) als de extension van het data type II? Het lijkt me goed als de Wiki nog even wordt aangepast. Op zich goed initiatief, maar ik moet nog wel opmerken dat parallel hieraan een discussie tussen Nictiz en XIS leveranciers loopt, over hetzelfde onderwerp, waarin ook nog niet duidelijk is wat de overeenstemming gaat worden (als het al lukt om die te bereiken). Tom de Jong 00:14, 4 januari 2010.
- I.t.t. de tekst in de e-mail betreft het niet (alleen) v3, maar gewoon OID's in het algemeen. Verder bestaat er geen OID extension, maar alleen OID's. Een v3 II heeft een root en een extension en als we hier dus alleen de extension van een II datatype van V3 bedoelen, dan ben ik er op tegen om hiervoor een maximum lengte af te dwingen. Dit om een veelvoud van redenen, die ik nu niet alle expliciet zal noemen, maar alleen dat we dit niet zelf in de hand hebben. Als paspoortnummers straks 33 char lang zijn en we hebben een maximum lengte van 32 als norm, gaan we dan geen paspoortnummers meer communiceren??? Ook als het gaat om de maximum lengte van een OID, stem ik stellig en om een veelvoud van redenen tegen. André Achterberg, 10:59 uur, 2010 januari 08 (UTC)
- Laten we het pragmatisch houden en iets afspreken van een maximum. Als blijkt dat het toch te kort is kunnen we het nog altijd uitbreiden (uitbreiden is altijd makkelijker dan krimpen). Wat dan het maximum moet zijn is niet zo heel belangrijk maar gaat aub niet filosoferen over de meest uitzonderlijke gevallen in theorie. Jan Dannenberg, 8 januari, 2010 16:12
Stemming
Resultaat stemming: 1 voor, 4 tegen, 1 onthouding (1-4-1).
Het voorstel is afgewezen
