InM Actiepunt 46 Meer duiding bij user defined tables (Assigning Authority)

Return to InM actie punten

• Author: Alexander Henket
• Status: Final for review

Motietekst 1

Zorgaanbieders die een zelf een assigning authority vormen, zoals instellingen die zelf patiëntnummers uitdelen, wordt aangeraden hun mnemonic voor de Assigning Authority ten behoeve van User Defined Table 0363 te baseren op hun achtcijferige AGB-Z nummer, gevolgd door een koppelteken en een drieletterige mnemonic voor de betreffende master file. Voorbeeld voor AGB-Z nummer 01234567:

• 01234567-PAT = Patiëntnummers
• 01234567-ART = Artsnummers

Voorbeeld van gebruik: Intern patiëntnummer 1000001 van instellling met AGB-Z nummer 01234567

PID|1||1000001^^^01234567-PAT^PI

Dagpatiënt is opgenomen op afdeling A3, kamer 307, bed 02, lokatie W door arts Dr. A. Jansen met intern artsnummer 1234JANS

PV1|1|D|A3^307^02^W|R|||1234JANS^Jansen^A.^^^^Dr.^^01234567-ART

Motietekst 2

Het is ook mogelijk om OID's te gebruiken in HL7 versie 2. De tegenhanger van bovenstaand advies uit Motietekst 1 met gebruikmaking van OID's zou een AGB-Z gebaseerde OID zijn. De verwachting is momenteel dat de meeste systemen daar nog niet mee om kunnen gaan. Als de communicatiepartners in een bepaalde omgeving gebruik van OID's willen ondersteunen dan moet dit op de volgende wijze worden toegepast:

• 2.16.840.1.113883.2.4.6.1.1234567.1 = Patiëntnummers
• 2.16.840.1.113883.2.4.6.1.1234567.2 = Artsnummers

Voorbeelden van gebruik: Intern patiëntnummer 1000001 van instellling met AGB-Z nummer 01234567

PID|1||1000001^^^&2.16.840.1.113883.2.4.6.1.1234567.1&ISO^PI

Dagpatiënt is opgenomen op afdeling A3, kamer 307, bed 02, lokatie W door arts Dr. A. Jansen met intern artsnummer 1234JANS

PV1|1|D|A3^307^02^W|R|||1234JANS^Jansen^A.^^^^Dr.^^&2.16.840.1.113883.2.4.6.1.1234567.2&ISO

Aanpassingen in NL implementatiegids hoofdstuk 2

De algemene richtlijnen voor tabellen in HL7v2 zijn:

• User-Defined-tabel: A user-defined table is a set of values that are locally or site defined. This accom- modates certain fields, like PV1-3 - Assigned patient location, that will have values that vary from institu- tion to institution. Even though these tables are not defined in the Standard, they are given a user-defined table number to facilitate implementations. HL7 sometimes publishes suggested values that a site may use as a starter set (e.g., table 0001- Sex)...
  
  There are some user-defined tables that contain values that might be standardized across institutions but for which no applicable official standard exists. For these a set of suggested values may be listed in Appendix A. ... It is recommended that these values be used ... These values may, however, be redefined locally.
• HL7-tabel: An HL7 table is a set of values defined and published by HL7. They are a part of the HL7 Standard because they affect the interpretation of the messages that contain them. These values may not be redefined locally; however, the table itself may be extended to accommodate locally defined values.

(Bron: HL7v2.4 Internationaal hoofdstuk 2 paragraaf 2.7.6)

In gevallen waar instellingen/leveranciers zelf identificaties uitgeven, zoals interne artscodes en patiëntnummers, worden zij zelf een Assigning Authority. De tabel voor Assigning Authority is User-defined Table 0363. In HL7v2.4 is Assigning Authority echter ook altijd van datatype
2.9.21 ... HD - Hierarchic designator
The HD is designed to be used either as a local identifier (with only the <namespace ID> valued) or a publicly-assigned identifier, a UID (<universal ID> and <universal ID type> both valued). Syntactically, the HD is a group of two identifiers: a local identifier defined by the first component, and a universal identifier defined by the second and third components.

<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

• Namespace ID (IS) - User-defined Table 0300 - is used as the HL7 identifier for the user-defined table of values for this component.
• Universal ID (ST) The HD’s second component, <universal ID> (UID), is a string formatted according to the scheme defined by the third component, <universal ID type> (UID type).
• Universal ID type (ID) The third component governs the interpretation of the second component of the HD. If the third component is a known UID refer to HL7 Table 0301 - Universal ID type for valid values, then the second component is a universal ID of that type.

Instellingen/leveranciers die een OID hebben en daar identificaties onder uitreiken, zouden deze direct in HL7v2 kunnen gebruiken op de onderstaande wijze (voorbeeld op basis van UZI-registerabonneenummer:

^2.16.528.1.1007.3.3.12345678.1^ISO

Het datatype HD komt overigens zelfstandig voor, maar ook als onderdeel van: CK, CN, CX, ED, PL, PPN, RP, XCN, XON. In versie 2.4 heeft het geen maximumlengte. In versie 2.5 is het 227 tekens.

Zoals wij tot nu toe omgaan met een Assigning Authority uit tabel 0363, wordt deze toegepast op component Namespace ID in het datatype HD. Gegeven de geringe bekendheid/ondersteuning van de twee andere subvelden lijkt het onwaarschijnlijk dat deze zich lenen voor zoiets belangrijks als de Assigning Authority.

De kunst is dan een methode te vinden waar iedereen zelf mee aan de slag kan, binnen de beperkingen van de huidige systemen. Daarvoor zou alleen het veld Namespace ID gebruikt mogen. In aanmerking komen:

• AGB-Z code van de instelling, numeriek 8
  • Voorbeeld: 06020806-PAT voor patiëntnummers van Erasmus MC
• UZI-registerabonneenummer, numeriek 8
  • Voorbeeld: 00001111-PAT voor patiëntnummers van Huisartsenpraktijk Asklepios
• Mnemonic, wie deelt deze uit?, formaat ?
  • Ons OID-register heeft ook een mogelijkheid voor mnemonische code. Wellicht dat deze geschikt is.

Het is duidelijk dat hier een keuze gemaakt moet worden, aangezien AGB-Z en UZI niet uit elkaar te houden zijn. De tot nu toe breedst geaccepteerde oplossing is AGB-Z. Bij de overgang naar iets anders zou bij voorkeur voor een OID gebaseerd mechanisme moeten worden gekozen vanwege de aansluiting met versie 3.

Discussie/Amendementen Motie 1

14-04-11 Bas: Ik heb twijfel bij Motietekst 1. Hoewel het de richting goed is, is mijn twijfel of het AGB nummer van de instelling wel zo vast is als wij veronderstellen. Ziekenhuizen fuseren bijvoorbeeld.(geen stem?)

14-04-11 Alexander: Het fusieprobleem is ook van toepassing op OID's. zie verder de tekst bij motie 2

14-04-11 Tom: Inhoudelijk: datatype HD heeft zowel een lokale als een universele identifier. Waarom niet beide mogelijk maken (en/of), dan kan zowel AGB nr. als een OID.

15-04-11 Irma: Ik ga er niet van uit dat iedereen in staat is om OIDs te ondersteunen in de V2 wereld. Daarmee ben ik dus niet voor motie 2. We hebben op de V2 themamiddag vorig jaar afgesproken om de AGB code te gebruiken om ‘local’ nader aan te duiden, dus dat komt overeen met motie 1. Als ik het zo zie vraag ik me wel af hoe een ontvanger weet dat dit een AGB code is.
Adri B: geïnterpreteerd als voor motietekst 1

17-04-11 Adri: achtcijferige AGB-Z nummer, gevolgd door een koppelteken en een drieletterige mnemonic voor de betreffende master file. Voorbeeld voor AGB-Z nummer 01234567: 01234567-PAT = Patiëntnummers en 01234567-ART = Artsnummers. Ik zie mezelf en een zorginstelling dit niet op deze wijze gebruiken.

Discussie/Amendementen Motie 2

13-04-11 André A:OID’s o.b.v. AGB-codes wordt (ook door Nictiz) afgeraden. Het is dan ook niet goed om dit als voorbeeld te nemen. Graag dus voorbeeld met op URA gebaseerde OID.
Ander punt is dat instellingen soms naar andere patientnummerlijsten overgaan, bijvoorbeeld ten gevolge van fusies, soms door splitsingen etc. Ook zijn er Assigning authorities die meerdere lijsten naast elkaar hanteren. Met de AGB-code is er slechts één lijst identificeerbaar.
Het OID-register geeft mnemonics uit, die uniek zijn in de branch waar deze bestaan. Dat is dus geen globale uniciteit en kan daarom in principe niet worden gebruikt.
P.S. Mag ik om bovenstaande redenen ook tegen motietekst 1 stemmen? Adri B: geïnterpreteerd als tegen motietekst 1

14-04-2011 Bas: Het gebruik van OID's is een betere richting, want de zorginstelling bepaalt dan zelf welke OID gebruikt wordt. Ik vind niet dat HL7-NL hier zou moeten cq mogen adviseren dat een bepaalde OID gebruikt wordt.
We moeten de assigning authority die bedoeld is om nummerreeksen uniek te maken niet verwarren met de organisatorische entitieit ziekenhuis.
Ik denk dat we voor V3 overgaan naar OID's, en ik dat zou je in V2 kunnen toepassen, dat is dan wel toekmst vast (geen stem)

14-04-11 Alexander: Het fusieprobleem is ook van toepassing op OID's. Er is nog lang geen besef bij partijen dat OID's eeuwigheidswaarde hebben en dat bij fusies, of zelfs bij wijziging van leverancier, deze moeten worden meegenomen. De neiging is altijd om identificatie van anderen te vervangen door eigen identificatie. Nictiz weet daar alles van op AORTA.

Het idee achter een Assigning Authority is het verschaffen van context. Die context bepaalt en kent de zender, maar moet bij voorkeur ook voor ontvangers te snappen zijn. Bij het vinden van de juiste Assigning Authority-string komt er nu vaak een groot navelstaren omdat de meesten eigenlijk geen idee hebben van scope, nut en noodzaak. Voor ontvangers is het makkelijker als ze een idee hebben van wat er op ze af kan komen. Dat bespoedigt de gesprekken bij nieuwe koppelingen.

Dat is dus de reden om toch in een zekere duiding op te willen nemen in de IH. Natuurlijk kun je uiteindelijk alle strings gebruiken die je wilt, binnen de kaders van uniciteit natuurlijk, maar de tekst zou je richting kunnen geven voor hoe je er een "bedenkt".

Technisch gezien: in de keuze tussen OID's en iets anders heb ik liever OID's. Ik heb me alleen laten overhalen door een aantal mensen om OID's (nog) niet in versie 2 te introduceren. Als de tijd intussen rijp is voor OID's in v2 dan ga ik daar zeker in mee.

14-04-11 Tom: Inhoudelijk: datatype HD heeft zowel een lokale als een universele identifier. Waarom niet beide mogelijk maken (en/of), dan kan zowel AGB nr. als een OID.

15-04-11 Tom: OK, heb het nu bekeken en zie dat motietekst 2 dus juist betrekking heeft op het gebruik van OID’s, maar ik vrees dat ik nog steeds met vragen zit:
We stemmen nu alleen voor motietekst 2, betekent dit dat motietekst 1 al is aangenomen?
De voorgestelde aanpassing van hoofdstuk 2 lijkt strijdig met de motietekst. Wat is nu het concrete gevolg als motietekst 2 wordt aangenomen? Wordt dan hoofdstuk overeenkomstig aangepast? D.w.z.: is het dan (ook) mogelijk om assigning authority met OID aan te duiden?
Ik ben voor de strekking van de motie, maar tegen de verplichting om de OID op te bouwen o.b.v. het AGB-Z nummer. Dat is nl. volkomen strijdig met hetgeen Nictiz adviseert bij het toepassen van HL7v3, dus erg verwarrend. Zijn er amendementen op de motie mogelijk?

15-05-11 Alexander: Nictiz heeft bij mijn weten alle advies op URA laten vallen. Daarnaast weten we uit ervaring dat URA een ander doel heeft en daardoor tot problemen leidt in de praktijk. AGB heeft dat probleem minder. Amendementen zijn zoals altijd natuurlijk mogelijk.

15-04-11 Irma: Ik ga er niet van uit dat iedereen in staat is om OIDs te ondersteunen in de V2 wereld. Daarmee ben ik dus niet voor motie 2. We hebben op de V2 themamiddag vorig jaar afgesproken om de AGB code te gebruiken om ‘local’ nader aan te duiden, dus dat komt overeen met motie 1. Als ik het zo zie vraag ik me wel af hoe een ontvanger weet dat dit een AGB code is. Adri B: geïnterpreteerd als tegen motietekst 2

17-04-11 Adri:Ik zie het niet gebeuren dat zorginstellingen OID's gaan gebruiken in V2. Maar ik begrijp wel de intentie.