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 v P: 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.

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 v P: 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