Implementatiehandleiding HL7v3 basiscomponenten v2.2 Part1

Implementatiehandleiding
HL7v3 Basiscomponenten

Stichting HL7 Nederland

W. Barentszstraat 1
3902 DE Veenendaal


Telefoon : +31 (0)318 - 548869
Fax : +31 (0)318 - 548090

E-mail : info@hl7.nl

Deze publicatie is mede tot stand gekomen
met ondersteuning van NICTIZ.

Versie	: 2.2
Datum	: 1 december 2009

  Naar boven

Inleiding

 

Doel en doelgroep

De HL7 versie 3 [HL7v3] standaard beschrijft onder andere een reeks artefacten (componenten en structuren) die in vele berichten toegepast worden. CMET's en datatypes worden in elk HL7v3 bericht toegepast. De diverse HL7 versie 3 implementatiehandleidingen bevatten tot nu toe elk een beschrijving van de daarin gebruikte datatypen en CMET's. Om herhaling te voorkomen maar ook om reden van consistentie werd in mei 2005 besloten om dit onderwerp in een aparte implementatiehandleiding onder te brengen.

Dit document heeft als doel de meestgebruikte datatypes en CMET's nader te verklaren en te specificeren voor toepassing in de Nederlandse zorgsector. Dit document dient gezamenlijk met de HL7 versie 3 standaarddocumentatie te worden gelezen. Dit document is opgesteld onder verantwoordelijkheid van de Technische Stuur Commissie van HL7 Nederland. Dit document is vooral bedoeld voor softwareontwikkelaars van zorgapplicaties en zorginfrastructurele applicaties, die op grond de HL7 versie 3 communicatiestandaard en op grond van dit document hun berichtschema's en berichten willen definiëren. Deze gids is mede ontwikkeld om gebruikt te worden voor de implementatie van HL7v3 berichten binnen de landelijke basisinfrastructuur AORTA.

 

Versie, status en wijzigingshistorie

Dit is versie 2.2 van het document "Implementatiehandleiding HL7v3 Basiscomponenten". Deze versie van dit document is normatief voor alle documenten die normatief naar deze versie van dit document verwijzen. Deze versie van dit document is niet van toepassing op documenten die naar eerdere versies van dit document verwijzen.

De status van deze versie is "Definitief". Er wordt ten sterkste aanbevolen om indien mogelijk altijd gebruik te maken van de laatste, definitieve versie van dit document.

 

Achtergrond

Dit document bevat een aantal Nederlandse aanwijzingen bij het toepassen van HL7 versie 3. Dit document dient als toevoeging op (en niet als vervanging van) de internationale HL7 versie 3 materialen. In geval van tegenstrijdigheden tussen de internationale standaard en dit document geldt hetgeen bepaald is in deze richtlijn.

Dit document legt een aantal beperkingen op aan de vrijheden zoals deze in de internationale standaard bestaan; het is een "conformance profile". Partijen die versie 3 implementeren op basis van de internationale HL7 versie 3 standaard voldoen daarmee dus niet aan het "HL7 Nederland conformance profile". Zorgaanbieders en leveranciers die gegevens willen uitwisselen via de nationale infrastructuur moeten voldoen aan de "HL7 Nederland conformance profile".

Indien niet specifiek anders vermeld zijn in Nederland de vocabulaires (code tabellen) van toepassing zoals deze in de internationale standaard beschreven zijn. Indien u in de Nederlandse situatie gebruikt wenst te maken van een HL7v3 datatype of CMET dat in strijd is met de Nederlandse richtlijnen, en dat niet in strijd is met de internationale HL7 versie 3 standaard, dan kunt u een voorbeeld gebruiksscenario (de use case) aanmelden bij HL7 Nederland met een verzoek tot aanpassing van dit document.

 

Reikwijdte

Dit document biedt een fundament voor alle toepassingen van HL7 versie 3 binnen Nederland, met name binnen de nationale basisinfrastructuur AORTA. Het overstijgt een specifieke toepassing of project, maar dient te worden gezien als achtergrondinformatie, met een bindend karakter, bij elke andere HL7 versie 3 implementatiehandleiding.

Daar waar sprake is van overlap (en mogelijk daaruit voortkomende inconsistentie) tussen dit document en enige andere HL7 versie 3 implementatiehandleiding, dient dit document als leidend te worden gezien. Zodra een dergelijke inconsistentie bekend wordt, zal ernaar worden gestreefd zo snel mogelijk te komen tot harmonisatie.

 

Structuur

Dit document bestaat uit een beschrijving van de belangrijkste datatypes en CMET's, waarbij uitsluitend die onderdelen worden beschreven die in de Nederlandse situatie van toepassing zijn. Indien er specifieke aanwijzingen zijn hoe iets (wellicht in afwijking van de internationale standaard) in Nederland geïmplementeerd moet worden dan is dit in de tekst aangegeven.

HL7-artefacten worden in dit document aangeduid door hun officiële identificatie volgens de HL7 versie 3 ballot. De meeste van deze artefacten zijn conform ballot #7 van maart 2004, maar gaandeweg zijn ook onderdelen uit nieuwere ballots toegevoegd. In een later stadium zal waarschijnlijk integraal harmonisatie plaatsvinden met een actuele release.

Enkele van de in deze implementatiegids beschreven HL7-artefacten bestaan (nog) niet in de internationale HL7-standaard. Deze artefacten worden in dit document in detail beschreven, omdat zij niet in het HL7-materiaal gedocumenteerd zijn. Als voorbereiding op een eventueel latere opname in de wereldwijde standaard zijn de namen van deze HL7-artefacten in het Engels gesteld. Aan nieuwe artefacten is een identificatie toegekend volgens de HL7v3 naam- en identificatieconventie. De (voorlopig) Nederland-specifieke artefacten zijn voorzien van een "NL" code. Alle nieuwe artefacten zullen ter beoordeling worden voorgelegd aan de internationale HL7-organisatie ter opneming in de internationale standaard. Als zij eenmaal zijn opgenomen komt de "NL" code te vervallen.

 

Samenhang met andere documenten

Diverse NICTIZ documenten bevatten beschrijvingen voor datatypes en CMET's. Dit document is een nadere, niet contextafhankelijke, uitwerking van de in de NICTIZ documentatie opgenomen aanbevelingen. Dit document is tevens aan de nieuwe inzichten aangepast.

Reeds gepubliceerde implementatiehandleidingen blijven gerelateerd aan de CMET's en datatypen, die in de implementatiehandleidingen opgenomen waren. Toekomstige publicaties zullen wel verwijzen naar een versie van de implementatiehandleiding voor CMET's en datatypen.

 

Revisies

De volgende wijzigingen zijn doorgevoerd sinds versie 2.0 van 31 mei 2007:

• Verwijderd: paragraaf 5.3 Afgeleide root-OID's omdat dit de indruk zou wekken dat OID's ontleed moeten worden bij ontvangst
• Gewijzigd: hoofdstuk 7 volgorde CMET's zodat ze logischer op elkaar volgen
• Nieuw: paragraaf 7.8 R_AssignedEntity ("verantwoordelijke")
• Verwijderd: hoofdstuk 8 Appendix: UZI-pasgegevens, omdat deze AORTA-specifiek is
• Toegevoegd: paragraaf 2.2 [NIWrappers]
• Gewijzigd: paragraaf 3.5 notitie bij BSN verwijderd, omdat BSN nu definitief is
• Gewijzigd: paragraaf 3.5 notitie bij UZOVI toegevoegd
• Gewijzigd: paragraaf 4.3 01.004 Apotheekhoudende huisarts
• Gewijzigd: paragraaf 4.3 RoleCodeNL aangevuld
• Verwijderd: paragraaf 4.3 DrugEntity
• Gewijzigd: paragraaf 6.2.2 opmerking bij apostrof
• Toegevoegd: paragraaf 6.3.1 opmerking over verschil tussen modelattributen en XML-attributen
• Gewijzigd: paragraaf 6.4 tekst bij Conformance aangescherpt
• Gewijzigd: paragraaf 6.6 toelichting instantiatieprincipe verbeterd
• Gewijzigd: paragraaf 6.9 typen text/rtf, application/pdf en application/dicom toegevoegd
• Gewijzigd: paragraaf 6.9 attribuut encoding moest representation zijn
• Gewijzigd: paragraaf 6.10 attribuut encoding moest representation zijn
• Gewijzigd: paragraaf 6.12 eerste deel van datatypebeschrijving herschreven en aangevuld met overzicht van attributen voor CD en afgeleiden
• Gewijzigd: paragraaf 6.19 verplichting en gebruik van het value attribuut nader toegelicht
• Gewijzigd: paragraaf 6.20 verwijzingen naar incorrecte ISO-3166 OID "2.16.1" vervangen door de juiste "1.0.3166.1.2.2" voor landen
• Gewijzigd: paragraaf 6.20 verwijzing naar OID voor gemeenten toegevoegd
• Gewijzigd: paragraaf 6.20 verbeterde toelichting bij additionalLocator
• Gewijzigd: paragraaf 6.21 richtlijn op zoveel mogelijk opdelen in naamdelen expliciet gemaakt
• Gewijzigd: paragraaf 6.21 verbod op lege naamdelen expliciet gemaakt
• Gewijzigd: paragraaf 6.21 toelichting bij qualifier "BR" in relatie tot name part family aangepast zodat deze niet meer afhangt van geboorte
• Gewijzigd: paragraaf 6.32 toegevoegd "een ondergrens <low> en een breedte <width>"
• Gewijzigd: paragraaf 6.33 sterk verbeterde tekst op alle elementen, twee informatieonderdelen toegevoegd, tekst boven voorbeelden aangescherpt en voorbeeld 6) en 7) toegevoegd
• Gewijzigd: paragraaf 6.35 sterk verbeterde tekst op alle elementen en tekst boven voorbeelden aangescherpt
• Gewijzigd: paragraaf 7.3.2 toelichting voor lokale situaties toegevoegd
• Gewijzigd: paragraaf 7.3.2 richtlijn voor Confidentiality toegevoegd
• Gewijzigd: paragraaf 7.3.2 richtlijn voor VeryImportantPersonCode toegevoegd
• Gewijzigd: paragraaf 7.3.3 relatie tot [universal] toegelicht
• Gewijzigd: paragraaf 7.5.2 code attribuut wordt nu wel gebruikt
• Gewijzigd: paragraaf 7.4.2 model geheel vervangen door vernieuwde en uigebreide versie
• Gewijzigd: paragraaf 7.4.3 extra toelichting op namen
• Gewijzigd: paragraaf 7.4.3 gewijzigde toelichting op multipleBirthInd
• Gewijzigd: paragraaf 7.4.3 gewijzigde toelichting op MaritalStatus code S
• Gewijzigd: paragraaf 7.9.3 R-MIM van Identified-Confirmable variant vervangen door bedoelde Universal variant
• Gewijzigd: vele kleinere tekstuele verbeteringen van de consistentie en/of leesbaarheid

  Naar boven

Uitgangspunten

 

Normatieve referenties

De onderstaande documenten zijn beschouwd als leidend voor dit document:

Referentie	Document(en)	Bron
[HL7v3]	HL7 Version 3 Ballot 11, September 2005 Normative Edition 2005	http://www.hl7.org
[XMLSC]	World Wide Web Consortium. XML-Schema.	http://www.w3.org/TR/xmlschema-0/ http://www.w3.org/TR/xmlschema-1/ http://www.w3.org/TR/xmlschema-2/
[XML]	World Wide Web Consortium. Extensible Markup Language, 1.0, 2nd Edition.	http://www.w3.org/TR/REC-xml

 

Informatieve referenties

De onderstaande documenten hebben gediend als bron voor dit document:

Referentie	Document(en)	Bron
[NIInfraDom]	NICTIZ Implementatiehandleiding generieke berichten	http://www.nictiz.nl
[NIWebSvPrf]	NICTIZ Implementatiehandleiding berichttransport	http://www.nictiz.nl
[NIWrappers]	NICTIZ Implementatiehandleiding berichtwrappers	http://www.nictiz.nl
[Verklarende woordenlijst]	NICTIZ Verklarende woordenlijst	http://www.nictiz.nl

 

Afkortingen

Alle afkortingen die relevant zijn voor het voorliggende document zijn opgenomen in [Verklarende woordenlijst].

 

Begrippen

Algemene begrippen die relevant zijn voor het voorliggende document zijn opgenomen in [Verklarende woordenlijst].

Overal in dit document waar de voornaamwoorden "hij", "hem" of "zijn" staan, wordt "hij of zij" resp. "hem of haar" resp. "zijn of haar" bedoeld.

  Naar boven

Identificatiemechanismen

 

Inleiding

Standaardiseren van gegevensuitwisseling betekent enerzijds het afspreken van een berichtstructuur (grammatica), maar het betekent ook dat dezelfde aanduiding voor objecten en concepten gehanteerd moet worden. Het heeft immers weinig zin om precies af te spreken hoe (qua formaat en betekenis) een patiënt wordt aangeduid, als de identificatie van die patiënt vervolgens niet wordt begrepen door de ontvangende partij.

Binnen een instelling is het meestal wel duidelijk welke 'stamtabel' bedoeld wordt voor identificatie en codering. Als een opname binnen een ziekenhuis wordt uitgewisseld, dan weten alle ontvangers dat de opnamenummers degene zijn die zijn uitgegeven door het ZIS. Als een arts wordt geïdentificeerd, dan zal bekend zijn of dit gebeurd met lokale nummers óf eventueel met landelijke VEKTIS nummers. Van laboratoriumbepalingen zal bijv. bekend zijn dat de onderzoeken worden aangeduid met lokaal gedefinieerde codes.

Dit geldt zeer waarschijnlijk niet in een transmuraal geïntegreerd zorgnetwerk, waar zender en ontvanger elkaars context niet per definitie 'kennen'. In zo'n setting kunnen er namelijk geen aannames meer gedaan worden over de aard van de gebruikte identificatie over codering. Die moet dus expliciet worden doorgegeven. Een tweetal voorbeelden:

Regionale gegevensuitwisseling ziekenhuizen:

• Er worden kruistabellen bijgehouden van de nummers van een patiënt bij verschillende ziekenhuizen (MPI functie).
• Patiëntnummer 3268774 wordt (bijv. bij onderlinge dienstverlening) verzonden van ziekenhuis A naar B.
• Bedoelt ziekenhuis A nu een eigen nummer of heeft het een nummer van ziekenhuis B gebruikt?

Landelijke aanvraag van labonderzoeken:

• Een ziekenhuis stuurt een aanvraag voor onderzoek 'B345' naar een landelijk opererend laboratorium.
• Bedoelt de aanvrager nu een eigen code, een code uit de specifieke tabel van het laboratorium of een algemene code?

Het eerste voorbeeld zal na invoering van het BSN niet (meer) spelen, omdat patiënten dan landelijk uniek identificeerbaar zijn. Maar hetzelfde probleem speelt ook bij de identificatie van bijvoorbeeld medicatieverstrekkingen of andere brongegevens in het (landelijk) EPD. Het blijft dus nodig om identifiers en codes uniek aan te duiden.

Er is overigens vaak verwarring over het onderscheid tussen de termen identifier (ID) en code. De kreten worden soms door elkaar gebruikt, terwijl hun betekenis fundamenteel verschilt:

• Een ID (identifier) duidt een specifiek object aan: een bepaalde patiënt, een ziekenhuis, een arts, een labaanvraag, een röntgenfoto, een medicatieverstrekking. Kortom, iets of iemand waarvan er maar één is en waar je als het ware een volgnummer aan kunt hangen.
• Een code duidt een generiek concept aan: een soort patiënt, een type zorginstelling, een artstype, een soort labonderzoek, een medicatietype. Hier gaat het niet om één 'object', maar om een categorie objecten die bepaalde kenmerken met elkaar gemeen hebben.

Merk op dat als men het dus heeft over 'de artscode' van Dr. Jansen, dit feitelijk onjuist is. Het gaat dan immers om de identificatie van Dr. Jansen als 'object' (oftewel individu) en 'het artsnummer' zou dan ook de juiste benaming zijn.

 

Object Identifiers (OID's)

Object IDentifiers (OID's) is een concept dat wordt gebruikt door ISO (de wereldwijde standaardisatieorganisatie) om te komen tot unieke identificatie van een systeem waarbinnen zelf weer identifiers of codes worden uitgedeeld en beheerd.

Het achterliggende idee daarbij is dat elke identificatie en elke code onderdeel is van een systeem waarbinnen deze gedefinieerd is, een identificatie- resp. coderingssysteem, bijv.:

• Patiëntnummers van ziekenhuis ABC
• Zorgverleneridentificatie o.b.v. AGB-Z
• Laboratoriumbepalingen volgens LOINC

In alle drie deze voorbeelden is sprake van een identifier (eerste twee gevallen) resp. een code (laatste situatie) en van een systeem waarbinnen deze worden uitgedeeld en beheerd. In het eerste geval is het een ziekenhuis dat de nummers uitdeelt (of liever: een softwaresysteem dat door het ziekenhuis wordt gebruikt). In het tweede geval gaat het om een landelijke zorgverlenertabel (beheerd door VEKTIS) en in het derde geval zelfs om een internationaal beheerd systeem voor het coderen van laboratoriumbepalingen.

De truc is nu om dat identificatie/coderingssysteem zelf een unieke identificatie te geven: deze identificatie is de OID van het identificatie- of coderingssysteem. Als de OID van het systeem wereldwijd uniek is en de identificatie of code is uniek binnen dat systeem, dan is de combinatie van die twee dus een unieke aanduiding voor de identificatie/code.

De achterliggende systematiek zorgt ervoor dat het identificatie- of coderingssysteem een OID heeft die gegarandeerd wereldwijd en eeuwig uniek is. Met andere woorden: een OID is niet alleen uniek, maar ook persistent. Er zal nergens ooit dezelfde OID worden toegewezen aan een andere identificatie- of coderingssysteem. Dit wordt later toegelicht.

Een aardige analogie is die met nummertjesautomaten, waarin bonnetjes zitten die uniek zijn voor de betreffende automaat. Als ik nu een bonnetje trek uit twee verschillende automaten, dan zou het nummer daarop best gelijk kunnen zijn. Maar stel nu dat de automaat zelf een sticker met daarop een OID bevat. De OID is dan dus een unieke identificatie van de nummertjesautomaat zelf. De combinatie van de OID van de automaat met het nummer op het bonnetje is nu gegarandeerd wereldwijd en eeuwig uniek.

In het geval van de identificatie van personen, organisaties of andere stoffelijke zaken wordt gebruik gemaakt van bestaande (HL7-externe) identificatiesysteem (zoals bijvoorbeeld Nederlands Rijbewijsnummer, SOFI-nummer, Ziekenhuisnummer binnen het St. Josef Ziekenhuis, UZI nummer van de zorgverlener). Ieder identificatiesysteem (Engels: identification scheme) wordt op zijn beurt uniek geïdentificeerd door een bepaalde OID.

In het geval van vocabulaires/terminologieën heeft een bepaalde organisatie (zoals de WHO, HL7 zelf, Z-Index, Prismant, SNOMED) één of meer vocabulaires (coderingssystemen/"tabellen") ontwikkeld. Iedere tabel wordt eenduidig geïdentificeerd door een bepaalde OID.

Voorbeeld: 2.16.840.1.113883.2.4.6.12 is de OID voor het identificatiesysteem van Nederlandse rijbewijzen. Het Rijbewijsnummer van Jan Janssen is 93632988. Dan wordt de persoon Jan Jansen eenduidig geïdentificeerd door de combinatie van a) de OID van het identificatiesysteem (2.16.840.1.113883.2.4.6.12) en b) de extensie daarvan (Engels: extension), een nummer binnen het identificatiesysteem (hier 93632988).

In een HL7 versie 3 bericht ziet dit er als volgt uit:

<id root="2.16.840.1.113883.2.4.6.12" extension="93632988" assigningAuthorityName="Rijksdienst voor het wegverkeer"/>

Voorbeeld: 2.16.840.1.113883.5.1 is de OID voor het HL7-codesysteem AdministrativeGender. Binnen die tabel staat de waarde "M" voor 'Mannelijk'. Dan wordt het concept 'Mannelijk' eenduidig geklassificeerd door de combinatie van a) de OID van het codesysteem (2.16.840.1.113883.5.1) en b) een code binnen dat systeem (hier "M").

In een HL7 versie 3 bericht ziet dit er als volgt uit:

<cd code="M" codeSystem="2.16.840.1.113883.5.1" codeSystemName="AdministrativeGender" displayName="Male"/>

 

Uitgiftemechanisme OID's

De opbouw van OID's is gebaseerd op het principe van gedelegeerde verantwoordelijkheid, d.w.z. dat de instantie die een OID beheert kan bepalen dat een andere organisatie zelf weer OID's mag uitdelen onder de OID die hen is toegewezen.

Alle OID's worden uitgedeeld volgens een boomstructuur, met knopen (nodes) en takken, zodat een hiërarchie ontstaat. Het allereerste niveau is ooit bepaald door ISO, dat daaronder nodes heeft toegewezen aan allerlei (categorieën van) organisaties.

Nodes horen bij een 'assigning authority' die een identificatie- of coderingssysteem beheert (bijv. HL7 zelf, VEKTIS of een specifieke zorginstelling). Deze assigning authority kent sub-OID's (oftewel nieuwe takken) toe onder de 'eigen' root node.

Bij elke nieuwe tak wordt een assigning authority geacht te controleren of er al een OID bestaat voor hetzelfde identificatie- of coderingssysteem. Op die manier wordt zoveel mogelijk voorkomen dat voor hetzelfde systeem (dezelfde 'nummertjesautomaat') meer dan één OID gebruikt wordt. Dit aspect is echter niet 100% waterdicht, omdat er geen centrale registratie bestaat. Het gevolg daarvan is dat het zou kunnen dat er meerdere OID's voor één identificatie- of coderingssysteem bestaan. Het blijft echter zo dat een OID altijd een unieke aanduiding voor één specifiek systeem is (en dus als basis kan dienen voor identifiers of codes die binnen dat systeem worden uitgedeeld en beheerd).

Een OID is altijd een unieke aanduiding voor één specifiek identificatie- of coderingssysteem. Een OID kan nadat zij is toegewezen nooit meer aan iets anders worden toegewezen. Een OID blijft ook geldig en bruikbaar als de assigning authority niet meer bestaat. Het gaat er immers om dat de OID persistent is, dus ook als een andere assigning authority het beheer overneemt, moet de OID voor alles onveranderd blijven.

Teneinde het gebruik van OID's in HL7-berichtimplementaties te vergemakkelijken hebben de internationale HL7-organisatie en HL7 Nederland elk een OID root bij ISO verkregen. Binnen deze OID roots kan HL7 op verzoek OID's uitdelen.

Figuur 15: OID boomstructuur

Een OID bestaat uit een keten van nodes. De nodes zijn getallen met punten ertussen: n1.n2.n3.n4. Er is in principe geen beperking aan de lengte die een OID kan hebben (hoewel in de praktijk vaak een maximum van 100 posities wordt aangehouden).

Een OID node mag geen voorloopnullen bevatten, hoewel een node wel gewoon uit het getal 0 mag bestaan. Dus 1.01.2567 is geen geldige OID, maar 1.1.2567.0 is dat wel.

Een OID is slechts bedoeld om de uniciteit te borgen en de structuur van de OID heeft geen betekenis. OID's mogen dus niet opgedeeld worden, bijv. om te bepalen welke assigning authorities betrokken zijn bij het ontstaan van de keten van nodes.

Elke tak onder een root in de boomstructuur correspondeert met een domein waarbinnen een assigning authority de uitgave van OID's beheert. Indien een OID binnen deze tak wordt uitgegeven aan een andere organisatie, dan vormt die OID de OID root van de daaraan gerelateerde organisatie (die weer een assigning authority kan zijn).

Voor meer informatie over OID's, zie de site www.oid-info.com, waar veel OID's terug te vinden zijn (op basis van actieve registratie of dooor koppelingen met andere registers).

 

Identificatiemethode

Binnen HL7-berichten is een identificatie systeem noodzakelijk waar het gaat om personen, systemen, instellingen en andere stoffelijke zaken. Daarbij wordt gebruik gemaakt van bestaande (HL7-externe) identificatiesystemen (zoals bijvoorbeeld 'Nederlands rijbewijsnummer', SOFI-nummer, Ziekenhuisnummer binnen het St. Josef Ziekenhuis, UZI nummer van de zorgverlener) die op zijn beurt uniek geïdentificeerd wordt door een bepaalde OID.

Hieronder volgt per gegevenscategorie een tekstuele toelichting van de te gebruiken identificatiemethoden, alfabetisch gesorteerd op gegevenscategorie. Na deze lijst volgt een tabel met alle aangehaalde OID's.

Berichten: Een HL7 versie 3 bericht. Berichten dienen te worden voorzien van een uniek nummer door de zendende softwareapplicatie.

Indien 2.16.840.1.113883.2.4.6.6.945 de OID van de zendende applicatie is (Zie softwareapplicatie in deze lijst), dan mag deze applicatie binnen de OID-tak 2.16.840.1.113883.2.4.6.6.945 zelf unieke nummers uitdelen. Als YYYY een oplopend nummer per bericht is, en de applicatie de OID tak '1' gebruikt om berichten verzonden door de applicatie te identificeren, dan vormt 2.16.840.1.113883.2.4.6.6.945.1 met extensie YYYY een unieke identificatie van het bericht.

Voorbeeld: De applicatie met OID 2.16.840.1.113883.2.4.6.6.940 staat op het punt een nieuw bericht te verzenden. Het te verzenden bericht krijgt het unieke nummer 8700333 (dit nummer mag slechts één keer worden gebruikt gedurende de levensduur van de zendende applicatie).
De applicatie kan binnen haar eigen OID-tak zelf unieke nummers uitdelen. Als 8700333 het te verzenden bericht aangeeft, en de organisatie er voor heeft gekozen OID tak 1 te gebruiken om berichten te identificeren, dan vormt 2.16.840.1.113883.2.4.6.6.940.1 met extensie 8700333 een unieke identificatie van het bericht.

<id root="2.16.840.1.113883.2.4.6.6.940.1" extension="8700333" assigningAuthorityName="ApplicatieNaam"/>

 Softwareapplicatie: Met een softwareapplicatie wordt een applicatie bedoeld, die als 'fysieke' zender of ontvanger van berichten optreedt, eventueel namens functionele applicatiemodules binnen de softwareapplicatie. Hieronder vallen de diverse XIS-systemen. Zie tevens Appendix D "Adresseren van dossiers en postbussen" in het document Specificatie van de basisinfrastructuur in de zorg, versie 2.4 voor een beschrijving van het identificeren en adresseren van applicaties.

Softwareapplicaties worden door middel van een door de verantwoordelijke organisatie uit te geven OID geïdentificeerd. Dit is mogelijk door of een OID af te leiden uit de OID van de organisatie die de applicatie beheert, of door het aanvragen van een aparte OID bij HL7 Nederland voor de applicaties binnen de eigen instelling. De identificatie heeft in principe geen enkele relatie met het UZI nummer van het systeemcertificaat van een GBZ; een relatie kan alleen aan de hand van een koppeltabel gelegd worden.
Indien de applicatie een GBZ is (of een deel daarvan) dan wordt op moment van aansluiting van de GBZ een identificerende OID door de LSP uitgegeven en in de ZIM vastgelegd.

Voorbeeld: indien de OID 1.2.3.4.26 met extensie 22 een softwareapplicatie identificeert (zie hierboven voor een definitie van softwareapplicatie), dan mag deze softwareapplicatie binnen de OID 1.2.3.4.26.22 zelf unieke nummers uitdelen. Als YYYY een oplopend nummer per softwaremodule binnen de softwareapplicatie is, en de OID-tak 56 wordt gebruikt ter identificatie van modules in de softwareapplicatie, dan vormt 1.2.3.4.26.22.56 met extensie YYYY een unieke identificatie van de softwaremodule.

File:Info.png

FAQ: Gegeven dat elke softwareapplicatie een Systeempas met een certificaat voorzien van een uniek UZI nummer verkrijgt voor authenticatiedoeleinden, kan dat UZI nummer niet hergebruikt worden als unieke identificatie van de softwareapplicatie ? Nee, systeemcertificaten dienen periodiek (elke drie jaar) te worden vernieuwd en verkrijgen dan een nieuw UZI nummer. Om deze reden wordt de identificatie van softwareapplicaties door middel van het UZI nummer van de Systeempas afgeraden.

File:Info.png

FAQ: De identificerende OID van een applicatie kan vrijelijk worden gedefinieerd. Een uitzondering wordt gevormd door een GBZ en applicaties binnen een GBZ die voor communicatiedoeleinden bekend zijn bij de verwijsindex. Deze verkrijgen, na aanmelding en registratie bij de LSP, een identificerende OID die verplicht is in alle communicatie met de landelijke infrastructuur. De root van de door de LSP uitgegeven identificaties is 2.16.840.1.113883.2.4.6.6.

Noot: Bovenstaande identificatiemethode voor applicaties is alleen van toepassing in de context van aansluiting op het Landelijk Schakelpunt in de infrastructuur van NICTIZ.

Patiënt/cliënt: Persoon die zorgservices afneemt van zorgverleners of zorgverlenende instellingen. Patiënten worden landelijk uniek geïdentificeerd door middel van het Burger Service Nummer (BSN).

De OID van het BSN identificatie systeem is: 2.16.840.1.113883.2.4.6.3. Naast de BSN-identificatie (die indien deze bekend is in ieder geval verzonden moet worden) kan gebruik worden gemaakt van het identificatienummer zoals bekend binnen een zorgregio of de instelling zelf.

Voorbeeld: Een patiënt heeft BSN 700434 en de locale (instellingsinterne) identificatie 830760. Er van uitgaande dat het HL7-bericht een identificerend data-element bevat wat herhalend voor mag komen, kan dit er in het bericht als onderstaand voorbeeld uitzien. Indien de OID 2.16.840.1.113883.2.4.6.1.100702 de identificatie van de organisatie is, dan mag een applicatie binnen haar OID-tak zelf unieke nummers uitdelen. Als 830760 een organisatie-intern patiëntnummer is, en de organisatie er voor heeft gekozen OID tak 12 te gebruiken om patiënten te identificeren, dan vormt 2.16.840.1.113883.2.4.6.1.100702.12 met extensie 830760 een unieke identificatie van de patiënt.

<id root="2.16.840.1.113883.2.4.6.3" extension="000700434" assigningAuthorityName="Ministerie van BiZa"/>

<id root="2.16.840.1.113883.2.4.6.1.100702.12" extension="830760" assigningAuthorityName="Ons Ziekenhuis"/>

Zorgverlenende Organisaties: Organisaties (of organisatiedelen) die op enigerlei manier bij het zorgproces of daaraan verwante processen betrokken zijn. Deze organisaties dienen binnen AORTA landelijk uniek geïdentificeerd te worden door middel van:

1. het CIBG UZI-registerabonneenummer (URA). Dit nummer is aanwezig op de UZI pas, het gebruik ervan binnen AORTA is feitelijk verplicht.
2. indien de organisatie geen (CIBG) URA bezit: de (Vektis) AGB-Z code.

Indien van een organisatie meerdere identificaties worden verstuurd dient tenminste of de (CIBG) URA of de (Vektis) AGB-Z code aanwezig te zijn.

Het begrip organisatie is in Nederland tevens van toepassing op zorgverleners die als zelfstandig ondernemer werkzaam zijn (ongeacht of zij bij de Kamer van Koophandel ingeschreven zijn). Voorbeeld: "Huisartspraktijk Dr. T. de Vries" wordt beschouwd als een organisatie, ongeacht of dit in de fomeel-juridische zin een organisatie is.

De Vektis AGB-Z zorginstelling identificatie OID is: 2.16.840.1.113883.2.4.6.1
Het UZI-registerabonneenummer (URA) Zorginstelling identificatie OID is: 2.16.528.1.1007.3.3. Naast het primaire identificatiesysteem kunnen tevens alternatieve identificaties gebruikt worden. De Prismant (SIG) Zorginstelling identificatie OID is: 2.16.840.1.113883.2.4.6.2

Zorgverleners: Personen die op enigerlei manier bij het zorgproces of daaraan verwante processen betrokken zijn. Deze personen worden landelijk uniek geïdentificeerd in het UZI-register.

De OID ten bate van identificatie van personen door middel van een UZI is: 2.16.528.1.1007.3.1. Naast de UZI-identificatie (die indien zij bekend is in ieder geval verzonden moet worden) kan gebruik worden gemaakt van andere regionale identificatiesystemen. Veelal wordt het Vektis AGB-Z nummer van de zorgverlener gehanteerd. De Vektis AGB-Z Zorgverlener identificatie OID is: 2.16.840.1.113883.2.4.6.1

Voorbeeld: Een zorgverlener heeft UZI 100434, Vektis AGB-Z nummer 2032988, en een locale (organisatie interne) code "WEE". Er van uitgaande dat het HL7-bericht een identificerend data-element bevat wat herhalend voor mag komen kan dit er in het bericht als onderstaand voorbeeld uitzien. Indien 100330 het Vektis AGB-Z nummer van de organisatie is, dan mag deze organisatie binnen de OID 2.16.840.1.113883.2.4.6.1.100330 zelf unieke nummers uitdelen. Als 160 een organisatie-interne zorgverlenercode is, en de organisatie heeft besloten OID tak 6 te gebruiken om zorgverleners binnen de organisatie te identificeren, dan vormt 2.16.840.1.113883.2.4.6.1.100330.6 met extensie WEE een unieke identificatie van deze zorgverlener.

<id root="2.16.528.1.1007.3.1" extension="000100434" assigningAuthorityName="UZI Register"/>

<id root="2.16.840.1.113883.2.4.6.1" extension="2032988" assigningAuthorityName="Vektis"/>

<id root="2.16.840.1.113883.2.4.6.1.100330.6" extension="WEE" assigningAuthorityName="Ons Ziekenhuis"/>

 

Identificatiesystemen OID Referentietabel

De volgende tabel bevat een overzicht met de in Nederland gebruikte OID's voor gangbare identificatiesystemen. De getoonde tabel is niet volledig. Zie de website www.hl7.nl van HL7 Nederland voor een up-to-date en compleet overzicht van de uitgegeven OID's.

OID	Identificatiesysteem	Omschrijving
2.16.840.1.113883.2.4.6.1	VEKTIS AGB-Z	Dient ter identificatie van zorgverleners en zorgverlenende organisaties
2.16.840.1.113883.2.4.6.2	Prismant/SIG code	Dient ter identificatie van zorgverlenende organisaties
2.16.528.1.1007.3.1	Zorgverlener UZI	Dient ter identificatie van zorgverleners (natuurlijke personen) in de Nederlandse zorgsector. Het UZI nummer wordt uitgegeven na opname in het ZorgaanbiederRegister (ZR). Formaat: 9N, met voorloopnullen indien korter dan 9 cijfers.
2.16.528.1.1007.3.2	Systeem UZI	Dient ter identificatie van systemen (applicatiesoftware) in de Nederlandse zorgsector. Formaat: 9N, met voorloopnullen indien korter dan 9 cijfers.
2.16.840.1.113883.2.4.6.3	BSN(1)	Landelijk Nederlands Burger Service Nummer, dient ter identificatie van patiënten of zorgcliënten. Formaat: 9N, met voorloopnullen indien korter dan 9 cijfers.
2.16.840.1.113883.2.4.6.4	UZOVI(2)	Unieke identificatie van een zorgverzekeraar. (1)
2.16. 528.1.1007.3.3	UZI-Registerabonneenummer (URA)	Dient ter identificatie van zorgorganisaties in de Nederlandse zorgsector. Het betreft zorgorganisaties (inclusief zelfstandigen) die tenminste één UZI pas bezitten. Formaat: 8N, met voorloopnullen indien korter dan 8 cijfers.
2.16.528.1.1007.5.1	BIG-ID	BIG-Register (ID van in BIG Register opgenomen entiteiten)
2.16.840.1.113883.2.4.6.6	Applicaties binnen de nationale infrastructuur	Identificeert applicaties aangesloten op de landelijke infrastructuur, waaronder de ZIM en alle GBZ applicaties.

Noot:
1. Deze OID duidde voor 15 September 2005 de Vektis ZV-tabel aan, en na die datum de UZOVI tabel. De identificatienummers in beide tabellen zijn gelijkluidend.

• Identificatie van ministeries

Deze tabel bevat door HL7 Nederland uitgegeven identificaties voor Nederlandse Ministeriële Departementen (Ministeries). Deze identificaties worden gebruikt als organisatie identifiers. Het ministerie-identificatiesysteem zelf heeft de OID 2.16.840.1.113883.2.4.6.5. Deze tabel wordt nog nader aangevuld.

Extensie	Omschrijving
1	BZK – Ministerie van Binnenlandse Zaken
2	VWS – Ministerie van VWS

  Naar boven

Vocabulaire voor berichtspecificaties

 

Inleiding

Eenheid van taal c.q. standaardisatie van taal is een belangrijk terrein waarop zowel nationaal als internationaal veel werk dient te worden verzet. Binnen het brede begrip "eenheid van taal" is met name de standaardisatie van zorg- en behandelinhoudelijke taal en coderingen een der belangrijkste voorwaarden voor o.a. elektronische zorgdossiers en het uitwisselen van eenduidige zorg- en behandelinformatie tussen zorgprofessionals. Zowel internationaal als nationaal (Nictiz, NEN) is het belang onderkend om aandacht te besteden aan de relatie tussen taalstandaarden en HL7. De wetenschappelijke verenigingen spelen hierin een cruciale rol. Aangezien de HL7-standaard zich strikt genomen primair richt op het bieden van berichtenstructuren waarin informatie op een gestandaardiseerde wijze kan worden afgebeeld, behoren "taalstandaarden" zeker inhoudelijk niet tot het werkgebied van HL7.

Taalstandaarden vormen vanuit de HL7-standaard "externe content", vergelijkbaar met diverse andere externe coderingen en classificaties die inhoudelijk door derden worden ontwikkeld en beheerd. Met betrekking tot "standaardisatie van taal" houdt HL7 zich niet bezig met de inhoudelijke standaardisatie van taal, maar met het afbeelden en weergeven daarvan in de HL7-structuur.

Dit document bevat beschrijvingen van de vocabulaire domeinen toegevoegd (of gewijzigd) voor gebruik in de Nederlandse situatie. Indien een vocabulaire in dit document niet genoemd wordt, zijn er geen specifieke Nederlandse richtlijnen van toepassing en wordt verwezen naar de vocabulaires zoals opgenomen in de internationale HL7-standaard.

 

Vocabulaires in HL7v3

Aan alle HL7-modelattributen van een gecodeerd datatype is een "Vocabulary Domain" gekoppeld. Een vocabulaire domein (Vocabulary Domain) wordt beschreven door middel van een tabel met waarden, of een referentie naar een HL7-externe terminologie.

In de HL7 versie 3 materialen wordt soms in de R-MIMs (<= MyVocabularyDomain), maar in ieder geval in de HMDs per modelattribuut de van toepassing zijnde vocabulaire aangehaald, bijvoorbeeld "MyVocabularyDomain" (CWE). Hierbij geeft CWE (Coded With Exceptions) aan dat er naast waarden uit het vocabulairedomein ook andere waarden mogen worden gebruikt (zoals waarden uit Nederland-specifieke tabellen). Indien CNE (Coded, No Exceptions) is aangegeven, dient de gebruikte waarde uit het vocabulaire domein te worden gekozen, en zijn er geen uitzonderingen mogelijk.

• Structuur van een Vocabulairy Domain table

MyVocabularyDomain
This table contains values related to … etc.

Level	Type, Domain name and/or Mnemonic code (2)	Base OID / Externe terminologienaam (1)	Mnemonic (2)	Definition/ description

Noten:

1. De externe terminologienaam wordt ter informatie gegeven indien de code afkomstig is uit een bestaande HL7-externe terminologie.
2. In het geval van een verwijzing naar een externe terminologie kunnen deze velden leeg zijn. In dat geval verwijst de tabel naar alle mogelijke waarden in de externe terminologie.

 

HL7 Vocabulary Domain Values

Indien de waarden binnen een vocabulaire geen aanpassingen/inperkingen behoeven in de Nederlandse situatie wordt volstaan met een verwijzing naar de vocabulaire documentatie binnen de HL7-materialen (wel wordt de OID van de desbetreffende vocabulaire gedocumenteerd).

HL7 Nederland streeft ernaar zo min mogelijk vocabulaires voor Nederland te definiëren. Indien mogelijk wordt gebruik gemaakt van in de internationale standaard opgenomen vocabulaire tabellen en (indien dat niet mogelijk is) van tabellen gedefinieerd door Nederlandse standaardisatie organisaties.

• RoleCodeNL - zorgverlenertype (natuurlijke personen)

Dit codesysteem bevat waarden die het roltype bepaalt van een zorgverlener of andere medewerker in de gezondheidszorg. De onderstaande tabel is een invulling van het HL7v3 vocabulaire domein "RoleCode" en wel specifiek het concept "AssignedRoleType". Deze tabel is specifiek voor Nederland en niet onderhevig aan harmonisatie met HL7.

Dit codesysteem heeft de OID 2.16.840.1.113883.2.4.15.111.

Lvl	Type, Domain name and/or Mnemonic code	Mnemonic	Definition/ description
1	A: AssignedRoleType		Een roltype wordt gebruikt om een entiteit verder aan te duiden, die een rol speelt met AssignedEntity als modelattribuut RoleClass.
2	S: Arts	01.000	Arts
3	L: (01.002)	01.002	Internist-Allergoloog
3	L: (01.003)	01.003	Anesthesioloog
3	L: (01.004)	01.004	Apotheekhoudende huisarts
3	L: (01.008)	01.008	Arts arbeid gezond. / bedrijfsarts
3	L: (01.010)	01.010	Cardioloog
3	L: (01.011)	01.011	Cardiothoracaal chirurg
3	L: (01.012)	01.012	Dermatoloog
3	L: (01.013)	01.013	Gastro-enteroloog
3	L: (01.014)	01.014	Chirurg
3	L: (01.015)	01.015	Huisarts
3	L: (01.016)	01.016	Internist
3	L: (01.018)	01.018	Keel- neus- en oorarts
3	L: (01.019)	01.019	Kinderarts
3	L: (01.020)	01.020	Arts klinische chemie
3	L: (01.021)	01.021	Klinisch geneticus
3	L: (01.022)	01.022	Klinisch geriater
3	L: (01.023)	01.023	Longarts
3	L: (01.024)	01.024	Arts-microbioloog
3	L: (01.025)	01.025	Neurochirurg
3	L: (01.026)	01.026	Neuroloog
3	L: (01.030)	01.030	Nucleair geneeskundige
3	L: (01.031)	01.031	Oogarts
3	L: (01.032)	01.032	Orthopedisch chirurg
3	L: (01.033)	01.033	Patholoog
3	L: (01.034)	01.034	Plastisch chirurg
3	L: (01.035)	01.035	Psychiater
3	L: (01.039)	01.039	Radioloog
3	L: (01.040)	01.040	Radiotherapeut
3	L: (01.041)	01.041	Reumatoloog
3	L: (01.042)	01.042	Revalidatiearts
3	L: (01.045)	01.045	Uroloog
3	L: (01.046)	01.046	Gynaecoloog
3	L: (01.047)	01.047	Verpleeghuisarts
3	L: (01.048)	01.048	Arts arbeid gezond. / verzekeringsarts
3	L: (01.050)	01.050	Zenuwarts
3	L: (01.055)	01.055	Arts maatschappij en gezondheid
3	L: (01.056)	01.056	Arts verstandelijk gehandicapten
2	S: (02.000)	02.000	Tandarts
3	L: (02.053)	02.053	Orthodontist
3	L: (02.054)	02.054	Kaakchirurg
2	S: (03.000)	03.000	Verloskundige
2	S: (04.000)	04.000	Fysiotherapeut
2	S: (16.000)	16.000	Psychotherapeut
2	S: (17.000)	17.000	Apotheker
3	L: (17.060)	17.060	Ziekenhuisapotheker
2	S: (25.000)	25.000	GZ-psycholoog
3	L: (25.061)	25.061	Klinisch psycholoog
2	S: (30.000)	30.000	Verpleegkundige
2	S: (83.000)	83.000	Apothekersassistent
2	S: (85.000)	85.000	Tandprotheticus
2	S: (86.000)	86.000	Verzorgenden in de individuele gezondheidszorg (VIG-ers)
2	S: (87.000)	87.000	Optometrist
2	S: (88.000)	88.000	Huidtherapeut
2	S: (89.000)	89.000	Diëtist
2	S: (90.000)	90.000	Ergotherapeut
2	S: (91.000)	91.000	Logopedist
2	S: (92.000)	92.000	Mondhygiënist
2	S: (93.000)	93.000	Oefentherapeut Mensendieck
2	S: (94.000)	94.000	Oefentherapeut Cesar
2	S: (95.000)	95.000	Orthoptist
2	S: (96.000)	96.000	Podotherapeut
2	S: (97.000)	97.000	Radiodiagnistisch laborant
2	S: (98.000)	98.000	Radiotherapeutisch laborant

Toelichting:

• Deze codes zijn gebaseerd op de Certification Practice Statement (CPS) van het UZI-register, die weer verwijst naar de tabellen voor "Beroepstitels, opleidingstitels en specialismen". Deze sluiten aan op artikel 3 en artikel 34 uit de wet BIG.
• De waarde "00.000" (geen beroepstitel) komt als waarde op de UZI-pas voor, maar wordt binnen HL7 versie 3 niet gebruikt.
• De in het verleden voor testdoeleinden gebruikte codes 833 (Apotheker) en 638 (Huisarts) dienen te worden vervangen door resp. de codes 17.000 en 01.015.

 

• RoleCodeNL - zorgaanbiedertype (organisaties)

Dit codesysteem bevat waarden die het roltype bepaalt van een organisatie die als zorgaanbieder optreedt. De onderstaande tabel is een invulling van het HL7v3 vocabulaire domein "RoleCode" en wel specifiek het concept "AssignedRoleType". Deze tabel is specifiek voor Nederland en niet onderhevig aan harmonisatie met HL7.

Dit codesysteem heeft de OID 2.16.840.1.113883.2.4.15.1060.

Lvl	Type, Domain name and/or Mnemonic code	Mnemonic	Definition/ description
1	A: AssignedRoleType		Een roltype wordt gebruikt om een entiteit verder aan te duiden, die een rol speelt met AssignedEntity als modelattribuut RoleClass.
2	L: (V4)	V4	Ziekenhuis
2	S: (X3)	X3	Verplegings- of verzorgingsinstelling
3	L: (R5)	R5	Verpleeghuis
3	L: (M1)	M1	Verzorgingstehuis
2	A: Apotheekinstelling
3	L: (J8)	J8	Openbare apotheek
3	L: (K9)	K9	Zelfstandig opererende ziekenhuisapotheek
2	A: Huisartsinstelling
3	S: (Z3)	Z3	Huisartspraktijk (zelfstandig of groepspraktijk)
4	L: (K3)	K3	Apotheekhoudende huisartspraktijk
3	L: (N6)	N6	Huisartsenpost (t.b.v. dienstwaarneming)

Toelichting:

• Deze codes zijn binnen NICTIZ zelf bedacht en hebben geen relatie met het CIBG. Het codesysteem is voorlopig beperkt tot de codes die nodig zijn voor de pilots EMD en WDH, maar wordt later uitgebreid met andere zorgaanbiedertypen.
• Deze codes komen niet voor op de UZI-pas, waar wel het URA nummer van de zorginstelling van de pashouder wordt aangeduid, maar niet het type organisatie.

 

Vocabulaires OID-Referentietabel

De volgende tabel bevat een overzicht met de in Nederland gebruikte OID's voor de identificatie van vocabulaires (code tabellen), met in ieder geval de OID's van een groot aantal Nederland-specifieke vocabulaires. De onderstaande tabel is niet volledig. Zie de website www.hl7.nl van HL7 Nederland voor een up-to-date en compleet overzicht van de uitgegeven OID's.

OID	Identificatiesysteem	Omschrijving
2.16.840.1.113883.2.4.4.1	G-Standaard GPK	Medicatie. Generieke productcode (GPK,GPC). Werkzame stof (inclusief sterkte), farmaceutische vorm (doseervorm) en de toedieningsweg. Voorbeeld: Diazepam 5 mg/st, tablet, oraal. (1)
2.16.840.1.113883.2.4.4.2	Medicatiedosering WCIA Tabel 25	Medicatiedosering (precoordinated), bestaande uit een reeks 'aanelkaargeplakte' Tabel 25 codes.
2.16.840.1.113883.2.4.4.3	Tijdseenheden - WCIA Tabel 25	Toedieningstijdseenheden (numcode)
2.16.840.1.113883.2.4.4.4	Eenheden gebruiksadvies - WCIA Tabel 25	Eenheden (numcode)
2.16.840.1.113883.2.4.4.5	Tekstcategorieen - WCIA Tabel 25
2.16.840.1.113883.2.4.4.6	Aanvullende teksten - WCIA Tabel 25	Aanvullende teksten bij medicatiedosering (numcode)
2.16.840.1.113883.2.4.4.7	G-Standaard HPK	Medicatie. Handelsproductcode (HPK, TPC). Als GPK, verbijzonderd met (onder andere) fabrikantnummer.<pbr/>Voorbeeld: Valium 5mg tablet, Stesolid 5mg tablet als verschijningsvormen van Diazepam. (Zie noot 1)
2.16.840.1.113883.2.4.4.8	G-Standaard Artikel Code	Medicatie: Artikel Kode, Artikelnummer. Als HPK, verbijzonderd naar verpakking. Voorbeeld: Valium 5 mg tablet, 2 strip à 10 tablet, 1 verpakking à 50 EAV. (Zie noot 1)
2.16.840.1.113883.6.1	LOINC	Observation identifier, identificeert een bepaald type (laboratorium)test.
1.0.3166.1.2.2	ISO 3166-1 editie 2, 2-character codes	2-karakter country codes volgens ISO 3166-1 editie 2
2.16.840.1.113883.2.4.4.15	Nederlandse Postcodes	Lengte 6, zonder spatie
Nederlandse uitbreidingen op versie 3 vocabulaires:
2.16.840.1.113883.2.4.15.111	HL7-NL Role Code	Zorgverlener rol typen: Identificeert de diverse rollen die een zorgverlener binnen een organisatie vervult
2.16.840.1.113883.2.4.15.4	HL7-NL Act Code (Gegevenssoort)	Gegevenssoorten, een hiërarchische value set gebruikt door de verwijsindex.

Noot:

1. In de G-Standaard kan men eigen artikelnummers gebruiken (codes 90.000.000 en hoger). Deze codes zijn leverancier- of locatiespecifiek. Bij deze codes dient gebruik gemaakt te worden van een andere OID dan de G-Standaard OID's. De G-Standaard OID's mogen dus niet gebruikt worden in combinatie met eigen codes.

  Naar boven

OID gerelateerde implementatieaspecten

 

Inleiding

NICTIZ heeft gekozen voor HL7 versie 3 en gebruikt daarom OID's als onderdeel van identificaties en coderingen die voorkomen in diverse onderdelen van de HL7-berichten.

Voorbeelden van identificaties die binnen een HL7-bericht in AORTA voorkomen:

• In de transmission wrapper:
  • Berichten (message ID, identificatie van interacties tussen applicaties)
  • Applicaties (device ID, als zender en ontvanger van de interactie)
    In de transmission wrapper gaat het altijd om de adressering van de interactie.
• In de control act wrapper:
  • Zorginstellingen (altijd geïdentificeerd o.b.v. een URA nummer)
  • Zorgverleners (altijd geïdentificeerd o.b.v. een UZI nummer)
  • Zorgmedewerkers (ook geïdentificeerd o.b.v. een UZI nummer)
  • Zorgsystemen (geïdentificeerd o.b.v. een UZI services certificaat)
    In de control act wrapper gaat het altijd om een auteur of verantwoordelijke.
• In de payload:
  • Patiënten (altijd o.b.v. het BSN binnen de landelijke infrastructuur)
  • Zorggegevens (medicatieverstrekkingen, laboratoriumuitslagen, etc.)
  • Daarnaast worden ook in de payload zorgverleners/zorginstellingen aangeduid.

Voor al deze identificaties geldt dat ze uniek en persistent moeten zijn. Dit betekent onder andere dat ze ook bestand moeten zijn tegen migraties en fusies van informatiesystemen.

Het is onmogelijk om vanuit HL7 Nederland, of welke instantie dan ook, centraal bij te houden welke OID's gebruikt worden voor lokaal gegenereerde zorggegevens. Elke applicatie die een uniek nummer bepaalt per ingevoerde order of uitgevoerde activiteit zal daarvoor een eigen unieke en persistente OID moeten hanteren, om te zorgen dat bijv. elke medicatieverstrekking te onderscheiden is van elke andere medicatieverstrekking.

Wat daarom nodig is, is een compromis met de volgende kenmerken:

• Forceer OID roots per applicatie, per zorginstelling of per softwareleverancier.
• Geef richtlijnen voor het uitdelen van nodes onder deze roots.
• Laat het beheer hiervan over aan de assigning authority (behorend bij de root).

De volgende ID's kunnen in principe als root dienen in de zorg:

• De applicatie, o.b.v. de door het LSP uitgedeelde applicatie ID
  (dit zou handig zijn, maar er is dan geen vanzelfsprekende assigning authority).
• De zorginstelling, o.b.v. het UZI Register Abonnee (URA) nummer
  (probleem is dat nog niet zeker is of URA 1-op-1 bij zorginstelling zal horen).
• Het Goed Beheerd Zorgsysteem', o.b.v. de daaraan uitgedeelde GBZ ID
  (probleem is dat de juridische definitie van een GBZ nog niet 100% zeker is).
• De IT-leverancier, o.b.v. een nog te bepalen identificatie van de organisatie
  (het lijkt niet zo handig om leverancier AA te maken, bijv. i.v.m. conversie).

Implementatierichtlijnen zijn nodig om duidelijk te maken welke OID structuur gebruikt moet worden in HL7 versie 3 berichten binnen AORTA. Hierover is een beslissing genomen binnen NICTIZ, met deze richtlijn als uitkomst:

Ten behoeve van de wereldwijde uniciteit en persistentie van gegevensidentificatie wordt de zorgaanbieder geadviseerd haar URA (UZI Register Abonneenummer) te gebruiken als basis voor de OID root van alle binnen de zorginstelling gegenereerde gegevens. Zorgaanbieders die reeds een bestaande OID hanteren, mogen deze wel blijven gebruiken.

Complicatie hierbij is dat er nu reeds pilot- en andere implementaties zijn, terwijl er nog nauwelijks UZI passen (en dus ook geen bijbehorende URA nummers) zijn uitgedeeld. Oplossing is om in de tussenliggende periode hetzelfde principe te gebruiken o.b.v. Vektis AGB-Z nummers. Dit betekent dat een ziekenhuis met AGB-Z nummer 06004212 de volgende OID root moet gebruiken: 2.16.840.1.113883.2.4.6.1.6004212. Als later een URA voor dit ziekenhuis beschikbaar komt, dan moet toch de node o.b.v. het AGB-Z nummer in gebruik blijven (de regel o.b.v. URA is alleen bedoeld voor nieuwe OID's).

Merk op dat, ondanks deze richtlijn, het LSP of een daarop aangesloten applicatie nooit iets mag afleiden (o.b.v. verwerking van de nodes) uit de opbouw van een ontvangen OID.

 

Gevolgen van OID's voor GBZ applicaties

De volledige ID (dus extensie én OID root) moet altijd reproduceerbaar zijn

• bij opslaan opgevraagde gegevens moet volledige identifier worden bewaard
• bij opnieuw opvragen van gegevens moet dezelfde identifier worden opgeleverd

De volgende praktijksituaties moeten ondersteund worden:

• Gegevens wijzigen van bron
  • Er vindt een migratie plaats van gegevens tussen softwareleveranciers, zorgverleners of locaties
  • De ID (OID root en extensie) blijft gehandhaafd; er mag dus niet meer omgenummerd worden
  • Gegeven wordt afgemeld voor oude bron en aangemeld als onderdeel van nieuwe bron
• Externe gegevens worden opgenomen in eigen dossier
  • De ID (OID root en extensie) blijft gehandhaafd; er mag dus geen eigen nummer meer toegekend worden.
  • Het feit dat het gegeven extern is moet ook bewaard blijven
    (dit is immers niet afleidbaar uit de structuur van de OID)
  • Extern gegeven mag namelijk niet opnieuw als brongegeven worden aangemeld bij LSP
  • Mag echter wel worden opgeleverd als onderdeel van bredere context (bijv. het huisartsdossier)
• Het fuseren of splitsen van:
  • Zorginstellingen
  • Softwareleveranciers
  • Informatiesystemen

Momenteel wordt in implementaties vaak nog getruukt met vaste waarden voor OID's, maar juist gebruik vergt aanpassingen in minimaal de volgende applicatieaspecten:

• databases (opslag root OID's)
• configuratie (definitie lokale roots)
• implementatie (uitvoering conversies)

  Naar boven

Datatypes

Naar hoofdstuk datatypes

  Naar boven

CMET's

Naar hoofdstuk CMET's