This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

OID Vragen

From HL7Wiki
Jump to navigation Jump to search

(This is a Dutch language page - used by HL7 Netherlands)

Definitie: ID identificeert een object, middels een root-OID en een (mogelijk lege) extensie.

  • Wie bepaalt de applicatie-ids?
    • Indien het applicatie betreft die als onderdeel van een GBZ met de ZIM communiceren, dan bepaalt de LSP (bij registratie van een GBZ inclusief de daarin aanwezige applicaties) de applicatie-ids. Dit is geen technische, maar een organisatorische vastgelegde procedure.
  • Wie beheert applicatie-ids?
    • Zie voorgaand antwoord.
  • Hoe stabiel zijn de applicatie-ids?
    • Applicatie-ids blijven bestaan tot het moment dat de organisatie verantwoordelijk voor de GBZ waar deze applicatie een deel van uitmaakt de applicatie verplaatst/samenvoegd/laat vervallen. Dit kan alleen in overleg met de LSP, van aangemelde gegevens die opvraagbaar zijn bij een te vervallen applicatie-id dient een nieuwe id te worden opgegeven. Applicatie-ids opgenomen in de verwijsindex zijn om deze procedurele reden dus altijd geldig. Ten aanzien van initieel verstuurde berichten: het zorgaanbiederregister kan uitsluitsel bieden over de (primaire) applicatie-id van een zorgverlener.
    • Het moet onderdeel van de GBZ eisen zijn/worden dat dit aspect van applicatiebeheer gegarandeerd is. Een applicatie ID waaronder eenmaal is aangemeld moet in gebruik blijven, tenzij gebruik wordt gemaakt van de procedures voor ‘afmelden’ en eventueel opnieuw aanmelden (onder een nieuw applicatie ID). Open issue Karel(?): documenteren.
  • Wie stelt anderen op de hoogte als er een applicatie-ID wijzigt?
    • Een GBZ dient (zoals vermeld bij vraag 3) wijzigingen altijd met het LSP af te stemmen. De LSP heeft niet de verplichting deze wijziging aan andere GBZen mede te delen - het zorgaanbiederregister kan (vraaggebaseerd) uitsluitsel bieden over de (primaire) applicatie-id van een zorgverlener.
  • Gaat het om oids of om een oid met een extensie?
    • Dat wordt bepaald door de LSP bij uitgifte/registratie van de applicatie-ids. Gegegeven het feit dat een applicatie-id alleen in HL7 berichten wordt toegepast is het waarschijnlijk dat een (root-)oid met een niet-lege extensie wordt gebruikt.
    • Een OID-technische voetnoot: de OID 1.2.3 en de (root-oid) 1.2 met extensie 3 identificeren beide een en hetzelfde object. In een HL7 Instance Identifier wijst een OID naar een identificatieSYSTEEM en de extensie naar een object BINNEN het identificatiesysteem.
  • Wat is de relatie tussen oids van applicaties die tot één GBZ behoren (dezelfde oid, verschillende extenties?)
    • Dat wordt bepaald door de LSP bij uitgifte/registratie van de applicatie-ids. OIDs zijn (qua structuur, qua opgenomen nummerreeksen) betekenisloze nummers, dus men kan/mag uit de gelijkheid van root-oids geen conclusies trekken. Alle applicatie IDs hebben dezelfde root OID, namelijk die van ‘applicatie IDs binnen AORTA’ als identificatiesysteem.
  • Krijgen GBZ-en ook IDs als identificatie middel?
    • Rene: ik zie op het moment niet echt een noodzaak voor toepassing in de de v3 berichten. De LSP deelt intern IDs uit voor GBZen, maar deze worden nooit gecommuniceerd.
  • Welke eisen stelt HL7-NL aan IDs voor applicaties?
    • HL7 Nederland heeft geen eisen ten aanzien van applicatie-IDs, anders dan dat de applicatie-id een geldige waarde voor het gedefineerde datatype moet bezitten.
  • Ook de gegevens die uitgewisseld worden (dossiers, episodes, contacten, gegevenselementen) dienen voorzien te worden van unieke identificaties: (a) welke eisen gelden er voor deze IDs? (b) Moet er een relatie zijn met de root-OID van de applicatie-ID? (c) Hoe wordt landelijke uniciteit geborgd?
    • (a,c) De enige eis ten aanzien van deze IDs is dat ze uniek moeten zijn. Indien het zendende systeem (of de zendende organisatie) een zogenaamde root-OID bezit, dan dient de zender (of zendende organisatie) zeker te stellen dat 1 en dezelfde ID (root-OID met extensie) nooit voor meerdere objecten wordt gebruikt. Dit garandeert tevens landelijke uniciteit, omdat 2 organisaties of systemen nooit een en dezelfde root-OID kunnen bezitten.
    • (b) Nee, dat hoeft niet, maar het is wel een voor de hand liggende methode.
  • Welke eisen worden gesteld aan gegevens die overgenomen worden uit landelijk verkregen berichten: (a) moet de betreffende zorgverlener op het niveau van de betreffende gegevenssoort behouden blijven, of wordt de oid van de gegevens vastgelegd? (b) Als je de bron wordt voor die gegevens moet je die onder eigen id aanmelden, maar als je ze toevoegt aan het eigen dossier hoeft dat niet, maar wil je wel de bron kunnen achterhalen. Dergelijke gegevens worden dus niet atomair aangemeld (wellicht ook niet categoraal), maar wat doe je als een ander jouw bevraagt: (c) mag je de container dan wel onder eigen id meesturen met daarin patientstukken onder andermans id? (d) Moeten de oids van de gegevens wel jouw oids zijn maar alleen de id van de andere zorgverlener blijft intact?
    • (a)Gegevens die worden overgenomen van andere zorgverleners (en waarnaar al dan niet in rapportages -of in antwoorden op queries- wordt gerefereerd) worden geidentificeerd middels de oorspronkelijke ID. In rapportages en in antwoordberichten op queries kan en mag men refereren aan gegevens die door andere zorgvereleners zijn aangemaakt.
    • (b)Indien men de bron wordt van een gegeven (dat al een OID heeft uitgedeeld gekregen door een andere partij of systeem) dan wordt dit gegegeven met de bestaande ID aangemeld (er wordt dus geen "eigen" ID aan uitgedeeld, het gaat immers nog steeds over 1 en hetzelfde gegeven, de identiteit wijzigt niet). De identiteit (met name de root-OID) van een gegeven geeft dus *geen* uitsluitsel over de auteur van de gegevens, noch over de *lokatie* van de gegevens (vergelijk dit met een rijbewijsnummer: daaruit volgt niet in welke gemeente het is uitgegeven). Om te achterhalen wie de auteur is van een gegeven, en waar het opgeslagen ligt kan een query naar de Verwijsindex worden gestuurd, met daarin opgenomen de Patient.ID en de OID van de (in de verwijsindex opgenomen) Act. Zie paragraaf 2.2.3 van de Implementatiehandleiding HL7 v3 ZIM handleiding.
    • (b)Kern is dat zekergesteld moet worden dat een en dezelfde act maar door één enkele applicatie bij de VWI aangemeld kan zijn.
  • Onder welke omstandigheden moet een bronsysteem gegevens ‘van derden’ opleveren in een query response ?
    • Dit is afhankelijk van bussiness-rules. Bij het EMD hebben we expliciet gezegd dat een apotheek geen verstrekkingen moet rapporteren die het niet zelf gegenereerd heeft (maar heeft overgenomen in het profiel na dienstwaarneming door een andere apotheek). Het al-dan-niet opleveren van gegevens van derden hangt samen met de vraag of een bepaald gegeven al dan niet moet worden aangemeld bij de VWI.
    • Het gaat daarbij niet alleen om aangemelde acts. Stel je meldt een voorschrift aan, iemand queried het voorschrift, en in dat voorschrift staat dat men het middel voorschrijft mede op grond van observation "1.2.3 extensie 4". Die observatie kun je via de ZIM opvragen (indien de act.id aldaar door iemand aangemeld is) - onafhankelijk van de auteur van dat labgegeven, of waar dat labgegeven aanwezig is, of dat het labresultaat door een ander dan het lab aangemeld is. Of je dat gegeven mag opvragen is een workflow/autorisatie issue.