INTERLIS. Versie 1.10

INTERLIS Versie 1.10

Datum laatste wijziging: 02/09/2010

INTERLIS v1.10

Licentie Op dit werk is een Creative Commons Licentie van toepassing, terug te vinden op: http://creativecommons.org/licenses/by/2.0/be/deed.nl. HET WERK (ZOALS HIERONDER OMSCHREVEN) WORDT TER BESCHIKKING GESTELD OVEREENKOMSTIG DE BEPALINGEN VAN DEZE CREATIVE COMMONS PUBLIC LICENSE (HIERNA “CCPL” OF “LICENTIE”). HET WERK WORDT BESCHERMD DOOR HET AUTEURSRECHT, EN/OF, INDIEN RELEVANT, DOOR DE NABURIGE RECHTEN, OF HET SUI GENERIS DATABANKENRECHT EN/OF ELK KRACHTENS DE GELDENDE WETGEVING VAN TOEPASSING ZIJNDE RECHT. ELK GEBRUIK VAN HET WERK DAT NIET UITDRUKKELIJK DOOR DEZE LICENTIE TOEGESTAAN WORDT, IS VERBODEN. ELK GEBRUIK VAN HET WERK, OP EEN MANIER DIE ONDER EEN IN DEZE LICENTIE BEHANDELD RECHT VALT, BRENGT DE AANVAARDING VAN DEZE LICENTIE MET ZICH MEE. DOOR DEZE LICENTIE KENT DE LICENTIEGEVER U DE HIERNA OMSCHREVEN RECHTEN TOE INDIEN U DE VOLGENDE BEPALINGEN EN VOORWAARDEN AANVAARDT: 1. Definities a. Met “Collectief Werk” wordt een werk bedoeld waarin het Werk, in zijn geheel en in ongewijzigde vorm, samen met een aantal andere bijdragen, die elk een afzonderlijk en zelfstandig Werk vormen, tot een collectief geheel is samengevoegd. Collectieve Werken zijn onder andere geregeld een uitgave van een tijdschrift, bloemlezingen of encyclopedieën. Een Werk dat een Collectief Werk is, zal, krachtens deze Licentie, niet beschouwd worden als een Afgeleid Werk (zoals hieronder omschreven). b. Met "Afgeleid Werk" wordt een werk bedoeld dat gebaseerd is op het Werk of op het Werk en andere reeds bestaande werken, zoals een vertaling, een muziekarrangement, een toneel-, literaire of cinematografische bewerking, een geluidsopname, een kunstreproductie, een ingekorte versie, een samenvatting of elke andere vorm waarin het Werk gewijzigd, omgezet of bewerkt kan worden, met uitzondering van de Collectieve Werken, die niet als Afgeleide Werken zullen beschouwd worden in de zin van deze Licentie. Om onduidelijkheid te vermijden zal, indien het Werk een muziekwerk of een fonogram is, de synchronisatie van het Werk met een bewegend beeld (“synching”) als een Afgeleid Werk in de zin van deze Licentie beschouwd worden. c. Met "Licentiegever" wordt de natuurlijke persoon of rechtspersoon bedoeld die de rechten op het Werk toekent volgens de bepalingen van deze Licentie. d. Met "Oorspronkelijke Auteur” wordt de natuurlijke persoon bedoeld die het Werk gemaakt heeft of, indien het gaat om een voorwerp dat door een naburig recht beschermd wordt, de oorspronkelijke titularis van het naburig recht.

ii

INTERLIS v1.10

e. Met "Werk” wordt het Werk van letterkunde of kunst bedoeld dat beschermd wordt door het auteursrecht en dat het voorwerp is van deze licentie. Voor de toepassing van deze Licentie omvat het “Werk” ook voorwerpen die beschermd worden door een naburig recht, zoals een uitvoering, een fonogram, een eerste vastlegging van film of radio-uitzending, alsook de databanken die beschermd worden door een sui generisrecht, voor zover deze het voorwerp vormen van deze licentie. Indien nodig, zullen de bepalingen van deze Licentie op zo een manier geïnterpreteerd worden dat ze op dergelijke beschermde voorwerpen toegepast kunnen worden. f.

Met "U" wordt de natuurlijke persoon of rechtspersoon bedoeld die het Werk gebruikt op een wijze die geregeld wordt door de rechten waarop deze Licentie betrekking heeft en die de bepalingen van deze Licentie met betrekking tot het Werk niet eerder geschonden heeft of die de uitdrukkelijke toestemming van de Licentiegever gekregen heeft om rechten krachtens deze Licentie uit te oefenen ondanks een eerdere schending van deze.

2. Uitzonderingen en beperkingen op de exclusieve rechten Niets in deze Licentie heeft de bedoeling de toepassing van de uitzonderingen op de exclusieve rechten van de rechthebbenden, de uitputting van deze rechten of andere beperkingen op deze rechten krachtens het auteursrecht, de naburige rechten, het sui generis databankenrecht of elk ander van toepasselijk recht te verminderen, te begrenzen of te beperken. 3. Omvang van de toegekende Licentie In overeenstemming met de bepalingen en voorwaarden van deze Licentie, verleent de Licentiegever U een licentie die wereldwijd, gratis, niet-exclusief en onbeperkt in tijd (voor de volledige duur van de bescherming van het Werk door het auteursrecht, de naburige rechten, het sui generis recht op de databanken) is om de volgende rechten met betrekking tot het Werk uit te oefenen: a. het reproduceren, op welke wijze en in welke vorm dan ook, van het Werk, het opnemen van het Werk in één of meer Collectieve Werken en het reproduceren van het Werk zoals het opgenomen is in de genoemde Collectieve Werken; b. het maken en reproduceren van Afgeleide Werken; c. het verhuren, uitlenen en verspreiden van exemplaren van het Werk, het meedelen aan het publiek en het ter beschikking stellen van het publiek. Hetzelfde geldt voor het Werk wanneer het opgenomen is in een Collectief Werk; d. het verhuren, uitlenen en verspreiden van exemplaren van Afgeleide Werken, ze meedelen aan het publiek en ze ter beschikking stellen van het publiek; e. indien het Werk een databank is, het opvragen en hergebruiken van substantiële delen van de databank. f.

Deze Licentie wijzigt geenszinsnde regeling van de billijke vergoedingen, die eventueel van kracht is in België of in andere landen, ter compensatie van de wettelijke erkenning van gedwongen licenties en heeft geen invloed op de inning van deze vergoedingen.

iii

INTERLIS v1.10

De hierboven vermelde rechten mogen uitgeoefend worden op alle bekende en onbekende dragers, media en formaten, met uitzondering van onbekende exploitatievormen. U heeft eveneens het recht om die wijzigingen aan het Werk aan te brengen die technisch noodzakelijk zijn voor de uitoefening van de hoger genoemde rechten op andere dragers, media en formaten. Oorspronkelijke Auteur ziet af van de uitoefening van zijn/haar morele rechten met betrekking tot de wijzigingen die technisch noodzakelijk zijn. De Licentiegever behoudt zich alle rechten voor die niet uitdrukkelijk overgedragen zijn in deze Licentie. 4. Beperkingen De in artikel 3 toegekende licentie wordt uitdrukkelijk op de volgende manier beperkt: a. U mag het Werk enkel in overeenstemming met de bepalingen van deze Licentie, uitlenen, verspreiden, ter beschikking stellen van het publiek of meedelen aan het publiek op voorwaarde dat U een kopie van deze Licentie of de Uniform Resource Identifier van deze Licentie toevoegt aan elke kopie van het Werk dat U uitleent, verspreidt, ter beschikking stelt van het publiek of meedeelt aan het publiek. U mag geen voorwaarden op het gebruik van het Werk aanbieden of opleggen die de bepalingen van deze Licentie of de uitoefening van de toegekende rechten wijzigen of beperken. U mag het werk niet in onderlicentie geven. U moet alle aanduidingen die verwijzen naar deze Licentie en naar de garantieclausule en de uitsluiting van aansprakelijkheid intact houden. U mag het Werk niet uitlenen, verspreiden, ter beschikking stellen van het publiek of meedelen aan het publiek indien daarbij een technische maatregel gebruikt wordt die de toegang tot of het gebruik van het Werk op een met de bepalingen van deze Licentie strijdige wijze controleert. Het voorgaande geldt voor het Werk dat opgenomen is in een Collectief Werk maar dat houdt niet in dat het Collectief Werk zelf, afgezien van het Werk, onderworpen wordt aan de bepalingen van deze Licentie. Indien U een Collectief Werk maakt, dan moet U, op aanvraag van om het even welke Licentiegever en in de mate van het mogelijke, elke verwijzing naar de Licentiegever of de Oorspronkelijke Auteur uit het Collectief Werk verwijderen. Indien U een Afgeleid Werk maakt, dan moet U, op aanvraag van om het even welke Licentiegever en in de mate van het mogelijke, elke verwijzing naar de Licentiegever of de Oorspronkelijke Auteur uit het Afgeleide Werk verwijderen. b. Indien U het Werk, Afgeleide Werken of Collectieve Werken uitleent, verspreidt, ter beschikking stelt aan het publiek of meedeelt aan het publiek, dan moet U alle informatie betreffende het beheer van rechten met betrekking tot het Werk intact houden en, op een wijze die redelijk is in verhouding tot het gebruikte medium of middel, verwijzen naar de Oorspronkelijke Auteur, door het verstrekken van de naam van de Oorspronkelijke Auteur (of het pseudoniem indien van toepassing) indien deze wordt vermeld; de titel van het Werk indien deze wordt vermeld; in de mate dit redelijkerwijze mogelijk is en indien deze beschikbaar is, de Uniform Resource Identifier, dat de Licentiegever aanduidt als verbonden met het Werk, tenzij die URI niet verwijst naar de informatie betreffende het beheer van rechten met betrekking tot het Werk of naar de van toepassing zijnde licenties op het Werk;

iv

INTERLIS v1.10

en in het geval van een Afgeleid Werk, door het aanduiden van het gebruik van het Werk in het Afgeleid Werk en door het identificeren van de elementen (bijvoorbeeld, door de aanduiding “Franse vertaling van het Oorspronkelijk Werk door de Auteur” “Franse vertaling van het Werk door de Oorspronkelijke Auteur” of “scenario gebaseerd op het Oorspronkelijk Werk door de Oorspronkelijke Auteur”). De verwijzing naar de Oorspronkelijke Auteur moet gebeuren op een redelijke manier. In het geval van een Afgeleid Werk of een Collectief Werk, moeten deze verwijzingen echter minstens weergegeven worden op dezelfde plaats en op dezelfde wijze als andere vergelijkbare auteursvermeldingen. 5. Garantieclausule en uitsluiting van aansprakelijkheid TENZIJ ER TUSSEN DE PARTIJEN SCHRIFTELIJK ANDERS OVEREENGEKOMEN IS, BIEDT DE LICENTIEGEVER HET WERK AAN ZOALS HET IS EN DOET DE LICENTIEGEVER GEEN VERKLARINGEN OVER HET WERK OF VERPLICHT HIJ ZICH TOT GEEN ENKELE GARANTIE, ONGEACHT OF DEZE UITDRUKKELIJK OF STILZWIJGEND, KRACHTENS DE WET OF OP EEN ANDERE GRONDSLAG RUST, HIERIN BEGREPEN, MAAR NIET BEPERKT TOT DE GARANTIE TEGEN UITWINNING, DE COMMERCIALISEERBAARHEID VAN HET WERK, DE FUNCTIONELE CONFORMITEIT, DE AFWEZIGHEID VAN INBREUK OP RECHTEN VAN DERDEN, DE AFWEZIGHEID VAN VERBORGEN OF ANDERE GEBREKEN, DE NAUWKEURIGHEID VAN HET WERK OF DE AFWEZIGHEID VAN FOUTEN EN GEBREKEN MET BETREKKING TOT DE INFORMATIE, ONGEACHT OF DEZE AL DAN NIET OPSPOORBAAR ZIJN. INDIEN DE OP DEZE LICENTIE VAN TOEPASSELIJKE WETGEVING EEN DERGELIJKE UITSLUITING VAN VERANTWOORDELIJKHEID VERBIEDT OF REGLEMENTEERT, DAN IS DEZE UITSLUITING VAN AANSPRAKELIJKHEID EN GARANTIE SLECHTS IN DE MATE TOEGELATEN DOOR DE WET VAN TOEPASSING. 6. Beperking van aansprakelijkheid VOOR ZOVER DE VAN TOEPASSELIJKE WETGEVING DIT TOELAAT, ZAL DE LICENTIEGEVER IN GEEN ENKEL GEVAL AANSPRAKELIJK GEACHT WORDEN VOOR WELKE RECHTSTREEKSE OF ONRECHTSTREEKSE, MATERIËLE OF MORELE SCHADE DAN OOK, DIE VOORTVLOEIT UIT DEZE LICENTIE OF UIT HET GEBRUIK VAN HET WERK, ONGEACHT OF DE LICENTIEGEVER INGELICHT WERD OVER DE MOGELIJKHEID VAN DERGELIJKE SCHADE. 7. Beëindiging a. Elke inbreuk op de bepalingen van deze Licentie waarvoor U verantwoordelijk bent, leidt tot de ontbinding van rechtswege van deze Licentie en het einde van de rechten die er uit voortvloeien. Niettemin behouden de licenties op Afgeleide Werken of Collectieve Werken, die door U krachtens deze Licentie verleend werden aan natuurlijke personen of rechtspersonen, hun werking ten opzichte van deze natuurlijke personen of rechtspersonen, voor zover deze personen de bepalingen van deze licenties niet schenden. De artikels 1, 2, 5, 6, 7 en 8, blijven van kracht ongeacht de beëindiging van deze Licentie.

v

INTERLIS v1.10

b. Indien de hierboven vermelde bepalingen en voorwaarden in acht genomen worden, is deze licentie onbeperkt in tijd (voor de duur van de bescherming van het Werk door het auteursrecht, de naburige rechten en het sui generis databankenrecht). Desalniettemin behoudt de Licentiegever zich op elk ogenblik het recht voor om het Werk onder een andere licentie of onder andere voorwaarden te exploiteren of om elke verspreiding van het Werk stop te zetten, zonder dat het gebruik maken van deze mogelijkheid deze Licentie (of elke andere licentie die, krachtens de bepalingen van deze Licentie, verleend werd of verleend moest worden) ongedaan kan maken, en deze Licentie zal onverminderd van kracht blijven tenzij de beëindiging intreedt wegens de hoger aangegeven redenen. 8. Diversen a. Telkens U het Werk of een Collectief Werk uitleent, verspreidt, meedeelt of ter beschikking stelt van het publiek, verleent de Licentiegever aan de ontvanger een licentie die van toepassing is op het Werk en die dezelfde bepalingen en voorwaarden bevat als deze Licentie. b. Telkens U het Afgeleid Werk uitleent, verspreidt, meedeelt of ter beschikking stelt van het publiek, verleent de Licentiegever aan de ontvanger een licentie die van toepassing is op het oorspronkelijke Werk en die dezelfde bepalingen en voorwaarden bevat als deze Licentie c. Indien een bepaling uit deze Licentie, krachtens het van toepassing zijnde recht, nietig of niet afdwingbaar is, dan zal dit geen invloed hebben op de geldigheid en de afdwingbaarheid van de andere bepalingen. In dit geval zal, zonder dat enige tussenkomst van de partijen hiervoor nodig is, een dergelijke bepaling op een zodanige wijze geïnterpreteerd worden dat haar geldigheid en afdwingbaarheid gevrijwaard blijven. d. Geen enkele afstand ten opzichte van de bepalingen en voorwaarden van deze Licentie wordt vermoed zonder een schriftelijke overeenkomst die ondertekend is door de partij die afstand doet. Geen enkele inbreuk op deze Licentie wordt door de andere partij aanvaard zonder schriftelijke overeenkomst, ondertekend door deze partij. e. Deze Licentie is het enige contract tussen de partijen met betrekking tot het Werk, dat het voorwerp is van deze Licentie. Er bestaat geen enkele overeenkomst of document van welke aard dan ook, die betrekking heeft op het Werk, bovenop wat hier bepaald is. De Licentiegever is gebonden door geen enkele bijkomende verplichting die voortvloeit uit enige communicatie afkomstig van U, ongeacht de vorm. Deze Licentie kan niet gewijzigd worden zonder de schriftelijke overeenkomst van beide partijen.

vi

INTERLIS v1.10

Document historiek v1.0 v1.1

02/10/2008 15/10/2008

v1.2

27/01/2009

v1.3

14/05/2009

v1.4

16/06/2009

Initiële versie Sectie Toevoeging van een optioneel NTE segment aan 3.6.6 het OUL^R22^OUL_R22 bericht 3.6.6.6 3.6.6.7 Uitbreiding van de erkende codeersystemen voor 1.11 resultaat- en aanvraagtesten 3.4.12 3.4.14 Uitbreiding van de erkende eenhedenstelsels 3.4.14 voor resultaten Verdere specificatie aanvraagformulier 1.7 Verdere specificatie staaletiket

1.8

LIS specifieke codeersystemen voor resultaat- en 1.11 aanvraagtesten 3.4.12 3.4.14 LIS specifieke eenhedenstelsels voor resultaten Wijzigen van bestaande voorschriften v1.5

04/09/2009

v1.6 v1.7 v1.8 v1.9 v1.10

05/11/2009 17/02/2010 18/06/2010 26/08/2010 02/09/2010

3.4.14

3.6.2 3.6.2.1 Uitbreiding PID segment voor niet opsplitsbare 3.4.7 patiëntnamen SPM-18 veld kan ook leeg zijn 3.6.6.1 HL7 berichten niet gerestricteerd tot versie “2.5” 3.4.5 Extra informatie voor specimen 3.6.6.2 Specificatie voor OBX-8 Abnormal Flags 3.4.14 Verzending van bijlagen 3.2 3.2.1 3.2.2 3.4.14

vii

INTERLIS v1.10

Inhoudstafel 1.

INTERLIS CONCEPTEN ............................................................................................................ 1

1.1

INTERLIS ............................................................................................................................................. 1

1.2

LIS ....................................................................................................................................................... 1

1.3

Activiteitencentrum ........................................................................................................................... 2

1.4

Voorschrift ......................................................................................................................................... 2

1.5

Contract.............................................................................................................................................. 3

1.6

Staal ................................................................................................................................................... 4

1.7

Aanvraagformulier ............................................................................................................................. 4

1.8

Staaletiket .......................................................................................................................................... 4

1.9

Openstaande en afgesloten aanvragen .............................................................................................. 5

1.10

Verwacht tijdstip en maximale duur ................................................................................................... 5

1.11

Coderen van testen ............................................................................................................................ 6

1.12

Identificeren van patiënten ................................................................................................................ 7

1.13

Identificeren van artsen ..................................................................................................................... 8

1.14

Ziekenhuisverblijf ............................................................................................................................... 9

1.15

Verzekeringsgegevens ...................................................................................................................... 10

2.

INTERLIS BARCODES ........................................................................................................... 11

2.1

Standaarden ..................................................................................................................................... 11

2.2

Staaletiket ........................................................................................................................................ 11

2.3

Aanvraagformulier ........................................................................................................................... 11

2.4

Code-128 .......................................................................................................................................... 12

2.5

CLSI-AUTO7-A ................................................................................................................................... 12

2.6

ISBT-128 ........................................................................................................................................... 13

3.

INTERLIS PROTOCOL ........................................................................................................... 15

3.1

Introductie ....................................................................................................................................... 15

3.2 Het gebruik van de E-postiljon .......................................................................................................... 15 3.2.1 HL7 berichten ......................................................................................................................................16 3.2.2 Bijlagen ................................................................................................................................................16 3.3

De HL7 bericht structuur................................................................................................................... 17

3.4 Segmenten ....................................................................................................................................... 18 3.4.1 Het BHS segment .................................................................................................................................18 3.4.2 Het BTS segment .................................................................................................................................19 3.4.3 Het ERR segment .................................................................................................................................19 3.4.4 Het MSA segment ................................................................................................................................19

viii

INTERLIS v1.10

3.4.5 3.4.6 3.4.7 3.4.8 3.4.9 3.4.10 3.4.11 3.4.12 3.4.13 3.4.14 3.5

Het MSH segment ...............................................................................................................................20 Het NTE segment .................................................................................................................................20 Het PID segment ..................................................................................................................................20 Het PV1 segment .................................................................................................................................22 Het ORC segment ................................................................................................................................23 Het BLG segment ............................................................................................................................24 Het IN1 segment .............................................................................................................................24 Het OBR segment ............................................................................................................................24 Het SPM segment............................................................................................................................25 Het OBX segment ............................................................................................................................26

Het batch protocol............................................................................................................................ 29

3.6 Events en berichten .......................................................................................................................... 30 3.6.1 Generiek antwoord bericht .................................................................................................................30 3.6.2 Creatie van een nieuw voorschrift ......................................................................................................30 3.6.2.1 Wijzigen van bestaande voorschriften .......................................................................................32 3.6.2.2 Bijkomende restricties voor een aanvraag binnen de RIZIV regels ............................................33 3.6.3 Bevestiging van creatie van een nieuw voorschrift .............................................................................33 3.6.4 Annulatie door de klant .......................................................................................................................33 3.6.5 Bevestiging van annulatie door de klant. ............................................................................................34 3.6.6 Melding van recepties, resultaten, annulaties en aanverwanten .......................................................34 3.6.6.1 SPM segmenten ..........................................................................................................................35 3.6.6.2 OBX segmenten (for Specimen)..................................................................................................35 3.6.6.3 OBR segmenten ..........................................................................................................................36 3.6.6.4 OBX segmenten (for Order) ........................................................................................................36 3.6.6.5 Stalen niet gereceptioneerd .......................................................................................................36 3.6.6.6 Stalen gereceptioneerd ..............................................................................................................37 3.6.6.7 Stalen geannuleerd bij ontvangst ...............................................................................................37 3.6.6.8 Het verwachte tijdstip van rapporteren .....................................................................................38 3.6.6.9 Annuleren van individuele testen ...............................................................................................38 3.6.6.10 Resultaten ...................................................................................................................................39 3.6.6.11 Bijaanvragen ...............................................................................................................................39 3.6.6.12 Wissen van resultaten en (bij)aanvragen ...................................................................................40 3.6.7 Voorbeelden ........................................................................................................................................40 3.6.7.1 OML^O33^OML_O33 .................................................................................................................40 3.6.7.2 ORL^O34^ORL_O34 ....................................................................................................................40 3.6.7.3 OML^O21^OML_O21 .................................................................................................................41 3.6.7.4 ORL^O22^ORL_O22 ....................................................................................................................41 3.6.7.5 OUL^R22^OUL_R22 ....................................................................................................................41 3.6.7.6 ACK^R22^ACK .............................................................................................................................42

ix

INTERLIS v1.10

1. INTERLIS concepten 1.1 INTERLIS INTERLIS is de naam van een systeem voor de elektronische uitwisseling van aanvragen, resultaten en andere gerelateerde informatie tussen twee labo informatica systemen. Het systeem heeft niet als doel de communicatie tussen voorschrijvers en labo‟s mogelijk te maken. Enkel de relatie tussen twee labo‟s – de klant vs. de onderaannemer – wordt beoogd. Het systeem houdt rekening met de Belgische realiteit die voornamelijk vertaald wordt onder de vorm van RIZIV richtlijnen. Het systeem gebruikt een communicatieprotocol dat gebaseerd is op de HL7 standaard. De details van dit protocol worden uiteengezet in de derde sectie van dit document.

1.2 LIS Een LIS of Labo Informatica Systeem is de generieke aanduiding voor elke agent die INTERLIS berichten kan versturen en ontvangen. Dit concept is dus niet de aanduiding van een (versie van) een software systeem voor labo automatisering, maar wel van een welbepaald informatica centrum dat gebruik maakt van een dergelijk systeem. Een LIS-ID is een mnemonische afkorting bestaande uit 5 hoofdletters (A-Z) die aan een LIS toegekend is. Er wordt verondersteld dat deze ID een unieke identificatie van een LIS is. De eerste twee hoofdletters van een LIS-ID vormen de twee-letterige ISO 3166-1alpha-2 landcode. Samen met de drie daaropvolgende karakters betekent dit dat het mogelijk is om per land 26 * 26 * 26 = 17576 verschillende productie INTERLIS agenten te benoemen. De LIS-ID‟s beginnend met “ZZ” worden gereserveerd voor test doeleinden. Opmerking: het enige doel van deze regels voor de vorm van een LIS-ID is het vereenvoudigen van de analyse van een barcode waar een dergelijke ID deel van uit maakt, zie verder. Het LIS-address is een e-mail adres dat gebruikt moet worden om INTERLIS berichten naar een zeker LIS te versturen.

1

INTERLIS v1.10

De LIS-public-key is de cryptografische sleutel waarmee berichten die bij verzending door een zeker LIS versleuteld werden, bij ontvangst weer ontcijferd kunnen worden. Twee LIS systemen die met elkaar willen communiceren, moeten elk het LIS-ID, het LIS-address en de LIS-public-key van hun tegenpartij kennen. Hoe deze kennis tot stand komt, en hoe ervoor gezorgd wordt dat binnen de context van elk LIS de ID van hun tegenpartijen uniek zijn, moet gebeuren m.b.v. mechanismen die geen onderwerp uitmaken van deze specificatie.

1.3 Activiteitencentrum Een activiteitencentrum of kortweg AC is een administratieve entiteit die binnen het INTERLIS netwerk afgelijnd wordt. Elk AC hoort tot één enkel labo. Eén enkel labo kan meerdere AC’s omvatten die elk over eigen administratieve gegevens beschikken (postadres, verantwoordelijke, …). In vele gevallen zal een AC een volledig labo aanduiden. Elk AC maakt gebruik van een welbepaald LIS. Het is mogelijk dat meerdere AC’s van eenzelfde LIS gebruik maken. Binnen het INTERLIS systeem kan een AC twee rollen vervullen: klant of onderaannemer. De klant geeft opdracht aan de onderaannemer om een zeker voorschrift uit te voeren. Deze rollen zijn niet vast maar kunnen in principe per voorschrift toebedeeld worden. Bij extensie kunnen we ook aan een LIS de rol van klant of onderaannemer toekennen. Een AC-ID is een mnemonische afkorting die aan een AC toegekend wordt. Er wordt verondersteld dat deze ID een unieke identificatie van een AC is, binnen de context van het LIS waartoe de AC hoort. Er worden geen regels geformuleerd voor de vorm van een AC-ID. Elk LIS mag hierover vrij beslissen. Twee AC‟s die met elkaar willen communiceren, moeten elk de AC-ID van hun tegenpartij kennen. Hoe deze kennis tot stand komt, en hoe ervoor gezorgd wordt dat binnen de context van elk LIS de ID‟s van alle AC’s uniek zijn, moet gebeuren m.b.v. mechanismen die geen onderwerp uitmaken van deze specificatie.

1.4 Voorschrift Een voorschrift in de INTERLIS context is een opdracht die een klant geeft aan een onderaannemer. Deze opdracht omvat een beschrijving van één of meerdere stalen, en een omschrijving van de testen die op deze stalen moeten uitgevoerd worden. Een voorschrift-ID is een alfanumerische ID die het klant LIS toekent aan een voorschrift. Deze ID moet uniek zijn binnen de context van het klant LIS. De

2

INTERLIS v1.10

betekenis van deze ID moet ook invariant zijn in de tijd (m.a.w. deze ID mag later nooit gebruikt worden voor het aanduiden van een ander voorschrift). Een globaal unieke aanduiding van een voorschrift bestaat uit de ID van het klant LIS, gevolgd door de ID van dat voorschrift. Daar er strikte regels bestaan voor de vorm van een LIS-ID, kunnen de twee onderdelen van deze concatenatie makkelijk herkend worden. Het INTERLIS concept van een voorschrift is niet noodzakelijk via een 1-op-1 relatie te mappen op een gelijkaardig concept binnen het klant en/of onderaannemer LIS. Het is bv. perfect mogelijk dat een INTERLIS voorschrift slechts een deel van de testaanvragen bevat die binnen het klant voorschrift gevraagd zijn (de overige testen werden reeds door een klant Labo uitgevoerd). Het is bv. ook mogelijk dat één enkel INTERLIS voorschrift binnen het onderaannemer LIS als meerdere voorschriften voorgesteld wordt. Het is de taak van elk LIS om deze mapping tussen de eigen LIS voorschriften en de INTERLIS voorschriften in goede banen te leiden.

1.5 Contract Een klant AC dat een voorschrift uitbesteedt aan een onderaannemer AC, doet dit steeds binnen de context van een contract. Een contract is een gedocumenteerde afspraak tussen een klant AC en een onderaannemer AC. Een contract-ID is een alfanumerische ID die een contract aanduidt. Deze ID moet uniek zijn binnen de context van het onderaannemer LIS. Een contract kan handelen over alle mogelijke modaliteiten m.b.t. het uitvoeren van voorschriften (prijzen, de wijze van facturering, extra kwaliteitscontroles, bijkomende rapportering, …). Deze aspecten van een contract vallen grotendeels buiten het domein van de INTERLIS specificatie. Het enige aspect dat wel in deze specificatie geformaliseerd wordt, is het feit dat de uitvoering van een voorschrift binnen dit contract al dan niet moet voldoen aan de RIZIV voorschriften. Een RIZIV contract is een contract dat naast een aantal mogelijke extra regels, ook alle RIZIV regels omvat. De wijze waarop een contract tussen twee AC’s tot stand moet komen, wordt niet beschreven door deze specificatie. We gaan er wel van uit dat na het afsluiten van een contract de twee betrokken LIS systemen de kennis verkrijgen over de potentieel te gebruiken contract-ID, en ook of het al dan niet een RIZIV contract betreft. Indien het klant AC bij het versturen van een voorschrift geen expliciet contract-ID opgeeft, dan wordt impliciet aangenomen dat het standaard RIZIV contract gehanteerd moet worden, met alle regels die het RIZIV hiervoor heeft opgesteld, en zonder enige bijkomende modaliteit.

3

INTERLIS v1.10

1.6 Staal Een staal (specimen, monster) is een hoeveelheid materiaal dat bewaard wordt in een container en waarop testen kunnen uitgevoerd worden. Het klant AC is verantwoordelijk voor het maken van de stalen. Een staal-ID is een alfanumerische ID die een staal aanduidt. Deze ID moet uniek zijn binnen de context van het klant LIS. De betekenis van deze ID moet ook invariant zijn in de tijd (m.a.w. deze ID mag later nooit gebruikt worden voor het aanduiden van een ander staal). Een globaal unieke aanduiding van een staal bestaat uit de ID van het klant LIS, gevolgd door de ID van dat staal. Daar er strikte regels bestaan voor de vorm van een LIS-ID, kunnen de twee onderdelen van deze concatenatie makkelijk herkend worden.

1.7 Aanvraagformulier Een aanvraagformulier is een fysisch document dat een voorschrift beschrijft. Een aanvraagformulier wordt door het klant LIS geproduceerd en wordt samen met de stalen waarop de testen uitgevoerd moeten worden, naar het onderaannemer AC verstuurd. Er wordt vereist dat op het aanvraagformulier een barcode aanwezig is – alsook de leesbare karakter voorstelling ervan – die zowel de ID van het klant LIS als de ID van het beschreven voorschrift bevat. De vereisten waaraan deze barcode moet voldoen, worden beschreven in de sectie over INTERLIS barcodes. De overige informatie die in dit document opgenomen wordt, en de layout waarin deze informatie moet geschikt worden, valt buiten het domein van deze specificatie.

1.8 Staaletiket Een staaletiket is een zelfklever die aangebracht wordt op de container die een staal bevat. Op het staaletiket moet minimaal de volgende informatie aanwezig zijn: Een barcode die zowel de ID van het klant LIS als de ID van het betrokken staal bevat. De vereisten waaraan deze barcode moet voldoen, worden beschreven in de sectie over INTERLIS barcodes. De leesbare karakter voorstelling van deze barcode. De naam en voornaam van de patiënt. Het geslacht van de patiënt (M of V). De geboortedatum van de patiënt (DD-MM-JJ). De staalsoort. Het afnametijdstip van het staal (DD-MM-JJ UU:MM).

4

INTERLIS v1.10

De layout waarin deze informatie moet geschikt worden, valt buiten het domein van deze specificatie.

1.9 Openstaande en afgesloten aanvragen Een onderaannemer AC heeft een openstaande aanvraag voor een welbepaalde test op een welbepaald staal wanneer een klant AC een voorschrift met een aanvraag voor die test op dat staal heeft verstuurd naar deze onderaannemer. Een onderaannemer kan zelf beslissen om bijkomende testen aan te vragen. Dit resulteert eveneens in openstaande aanvragen. Een openstaande aanvraag wordt afgesloten door een van de volgende gebeurtenissen: Het staal komt niet op tijd toe bij de onderaannemer Het staal wordt in zijn geheel geweigerd De aanvraag wordt geannuleerd Een resultaat wordt gerapporteerd voor deze aanvraag Een afgesloten aanvraag kan weer geopend worden wanneer de annulatie of het resultaat gewist worden. Opmerkingen: de openstaande en afgesloten toestand wordt per aanvraag behandeld, niet per staal.

1.10 Verwacht tijdstip en maximale duur Het is de bedoeling dat alle openstaande aanvragen uiteindelijk door de onderaannemer afgesloten worden. Deze heeft hiervoor natuurlijk een zekere hoeveelheid tijd nodig. Exact hoeveel tijd is moeilijk te voorspellen, maar dikwijls is het mogelijk een betrouwbare schatting te geven. De onderaannemer kan na receptie van een staal aan zijn klant melden wat voor elk van de gevraagde testen het verwachte tijdstip van rapporteren is. Er wordt aan de onderaannemer AC’s gevraagd deze mogelijkheid enkel te gebruiken indien er een betrouwbare voorspelling kan gemaakt worden. Het verwacht tijdstip definieert een “zachte” bovengrens voor de periode dat een klant moet wachten op zijn resultaten. Daarnaast heeft een klant als ultiem vangnet een “harde” bovengrens nodig. Deze wordt gerealiseerd onder de vorm van de maximale duur tot rapporteren. Deze duur wordt gerekend vanaf het tijdstip waarop het betrokken staal in het onderaannemer AC gereceptioneerd wordt. Dit maximum is steeds geldig, de onderaannemer moet en kan hierover geen bericht aan de klant sturen.

5

INTERLIS v1.10

De maximale duur tot rapporteren is functie van de uit te voeren test. Elke onderaannemer moet aan zijn klanten kenbaar maken wat de waarde van deze parameter is voor elke test die hij aanbiedt. De manier waarop dit gebeurt, valt buiten het domein van deze specificatie. Wanneer een onderaannemer voor een bepaalde test een verwacht tijdstip van rapporteren meldt aan zijn klant, en dit tijdstip ligt verder dan wat de maximale duur van rapporteren definieert, dan moet deze maximale duur impliciet verlengd worden. Natuurlijk enkel voor de betrokken aanvraag.

1.11 Coderen van testen Voor de discussie van deze sectie is het nuttig om een onderscheid te maken tussen een test op het niveau van een resultaat, en een test op het niveau van een aanvraag. Voor het eerste concept poneren we de term resultaat test, voor het tweede concept de term aanvraag test. Elk resultaat dat gerapporteerd wordt, moet vergezeld gaan van een code die een resultaat test aanduidt. Voor het INTERLIS systeem wordt hiervoor hoofdzakelijk het LOINC codeersystemen gehanteerd. Daarnaast mag elk LIS ook een eigen codeersysteem hanteren, doch alleen maar in het geval dat er geen expliciete LOINC code beschikbaar is voor een LIS specifieke test. Een dergelijke test wordt in dit geval geïdentificeerd door een door het LIS vrij toegekende code. Het LIS specifieke codeersysteem wordt geïdentificeerd op basis van het betrokken LIS-ID (zie ook §3.4.12 en §3.4.14). Er is steeds een eenduidige 1-op-1 mapping van een resultaat test naar de betrokken test code volgens het gebruikte codeersysteem. Bij het aanvragen van testen moet er ook een codeersysteem gehanteerd worden waarmee de aanvraag testen kunnen aangeduid worden. Voor dit domein bestaat er echter geen algemeen aanvaarde internationale standaard. We hebben dan ook besloten om ook hier de LOINC of LIS specifieke codes te hanteren. Nu hebben we een probleem indien er geen eenvoudige 1-op-1 mapping bestaat tussen een aanvraag test en een resultaat test. Dikwijls worden er voor één enkele aanvraag test resultaten gerapporteerd voor meerdere resultaat testen, en soms kan een resultaat voor eenzelfde resultaat test gerapporteerd worden in het kader van verschillende aanvraag testen. Om dit probleem op te lossen, definiëren we het concept van de karakteristieke aanvraag set voor een aanvraag test. Dit is een subset van de test codes (behorende tot de erkende codeersystemen) waarvoor het onderaannemer AC resultaten kan rapporteren in het kader van deze aanvraag test. Deze subset moet bovendien zodanig gekozen worden dat die combinatie bij geen enkele andere aanvraag test kan voorkomen. Een AC dat als onderaannemer wenst op te treden, moet aan zijn klanten meedelen welke de karakteristieke aanvraag set is voor elke aanvraag test die hij aanbiedt.

6

INTERLIS v1.10

Een klant AC dat op een welbepaald staal een zekere aanvraag test wenst te laten uitvoeren, moet in zijn elektronische aanvraag al de codes uit de karakteristieke aanvraag set vermelden bij de beschrijving van dat staal. Merk op dat in de gevallen waar er wel een 1-op-1 mapping bestaat tussen aanvraag test en resultaat test, de karakteristieke aanvraag set uit één enkele code bestaat. Een AC dat als onderaannemer wenst op te treden, moet eveneens aan zijn klanten meedelen wat de potentieel meer uitgebreide maximale aanvraag set is voor deze aanvraag testen die hij aanbiedt. Deze set moet alle codes bevatten waarvoor er in het kader van deze test een resultaat kan geantwoord worden. Een klant AC dat potentieel wenst deze aanvraag test bij deze onderaannemer te laten uitvoeren, moet al deze codes bij de resultaat rapportering accepteren. Een verdere complicatie treedt op indien voor het uitvoeren van één enkele aanvraag test, testen op meerdere stalen moeten uitgevoerd worden. In dat geval moet de onderaannemer voor deze aanvraag test beschrijven wat voor soort stalen er verwacht worden, en voor elk van deze stalen welke codes er moeten aangevraagd worden. In plaats van een eenvoudige karakteristiek set hebben we in dit geval een karakteristiek patroon van staal beschrijvingen met geassocieerde codes. Een AC dat als onderaannemer wenst op te treden, moet aan zijn klanten deze karakteristieke patronen meedelen. Een klant AC dat een aanvraag test wenst te laten uitvoeren, moet zorgen dat elk staal dat in het karakteristiek patroon van deze test beschreven wordt aan de onderaannemer geleverd wordt, en op deze stalen moeten al de codes vermeld worden die volgens het patroon vereist zijn. Om problemen te vermijden zullen we als laatste generalisatie van dit mechanisme toelaten dat voor één bepaalde aanvraag test meer dan één karakteristiek patroon gedefinieerd wordt. Het onderaannemer AC verplicht zich ertoe alle patronen die het publiceert te erkennen, een klant AC kan willekeurig één van de gepubliceerde patronen kiezen. De manier waarop een onderaannemer deze patronen moet publiceren, valt buiten het domein van deze specificatie.

1.12 Identificeren van patiënten Een voorschrift in het kader van een RIZIV contract moet een eenduidige identificatie van de betrokken patiënt vermelden. Deze sectie concretiseert de regels die binnen het INTERLIS systeem gelden voor patiëntidentificatie. Patiënten worden geïdentificeerd d.m.v. een patient-ID. Dit is een alfanumerische ID die door patient-ID-authority toegekend is. Dit laatste is een organisatie die volledig zelfstandig unieke patiënt identificaties toekent.

7

INTERLIS v1.10

Op haar beurt wordt aan een patiënt-ID-authority eveneens een identificatie toegekend. Dit noemen we de patient-ID-authority-ID. Een volledige identificatie van een patiënt bestaat bijgevolg uit de combinatie van een patient-ID en een patient-ID-authority-ID. Elk LIS kan optreden als patient-ID-authority. In data geval is de patient-ID-authorityID gelijk aan de LIS-ID. Voorts kan het INTERLIS een aantal betrouwbare derde partijen erkennen als patient-ID-authority. Voor het ogenblik is dit enkel het RIZIV die INSZ nummers toekent aan patiënten. Het patient-ID-authority-ID voor het RIZIV is dan ook “INSZ”. Voor het INTERLIS worden twee notaties voor INSZ nummers gestandaardiseerd: een code van 11 posities enkel bestaande uit cijfers een code van 13 posities van het formaat “xxxxxx xxx xx” (dus inclusief de spaties) Een LIS kan vrij kiezen welk van deze notaties het wenst te hanteren. Een voorschrift moet minstens één patient-ID bevatten. Er mogen ook meerdere dergelijke ID‟s voorkomen. Het wordt ten zeerste aangeraden dat het INSZ nummer als een van de patiënt identificaties vermeld wordt. Naast de patiënt identificaties wordt er ook vereist dat de naam, de voornaam, de geboortedatum en het geslacht van de patiënt vermeld worden. Indien het onderaannemer LIS inconsistenties ontdekt binnen een lijst van ontvangen identificaties (bv. een ID toegekend door een klant LIS is vroeger reeds in combinatie met een ander INSZ nummer gebruikt), of indien de vermelde patiënt eigenschappen niet overeenstemmen met een van de identificaties (bv. de vermelde naam komt niet overeen de naam die bij de laatste SIS-kaart lezing voor het vermelde INSZ gevonden werd), dan moet het onderaannemer AC corrigerende acties ondernemen. Het onderaannemer AC kan in het geval van extreme identificatieproblemen ook beslissen het voorschrift te weigeren. Deze sectie is niet van toepassing voor voorschriften die onder een niet RIZIV contract vallen: zelfs indien er totaal geen verwijzing naar een patiënt voorkomt in een dergelijk voorschrift, moet het toch geaccepteerd en uitgevoerd worden. De voorschrift-ID op zich is voldoende om bij rapportering eenduidig naar te verwijzen.

1.13 Identificeren van artsen Een voorschrift in het kader van een RIZIV contract moet de identificatie van de originele voorschrijver bevatten, en eveneens die van de klinisch bioloog die binnen

8

INTERLIS v1.10

het klant AC verantwoordelijk is voor het uitbesteden van de testen vermeld in het voorschrift aan het onderaannemer AC Artsen worden geïdentificeerd d.m.v. een arts-ID. Dit is een alfanumerische ID die door een arts-ID-authority wordt toegekend. Dit laatste is een organisatie die volledig zelfstandig unieke arts identificaties toekent. Op haar beurt wordt aan een arts-ID-authority eveneens een identificatie toegekend. Dit noemen we de arts-ID-authority-ID. Een volledige identificatie van een arts bestaat bijgevolg uit de combinatie van een arts-ID en een arts-ID-authority-ID. Voorlopig gebruikt het INTERLIS slechts één arts-ID-authority: het RIZIV. Als ID voor deze authority wordt “RIZIV” gebruikt. De arts ID‟s die door deze authority toegekend worden, zijn de zorgverlener RIZIVnummers. Voor het INTERLIS worden twee notaties voor zorgverlener RIZIV-nummers gestandaardiseerd: een code van 11 posities enkel bestaande uit cijfers een code van 14 posities van het formaat “x-xxxxx-xx-xxx” (dus inclusief de „-„ tekens) Een LIS kan vrij kiezen welk van deze notaties het wenst te hanteren. Daarnaast wordt gevraagd ook de naam en voornaam van de arts te vermelden bij zijn RIZIV-nummer. Indien het onderaannemer LIS inconsistenties ontdekt tussen een gegeven RIZIVnummer en de erbij behorende naam of voornaam, dan moet het onderaannemer AC corrigerende acties ondernemen. Voor voorschriften die onder een niet RIZIV contract vallen, is het identificeren van een originele voorschrijver en/of van een uitbestedend klinisch bioloog niet noodzakelijk (maar wel toegelaten).

1.14 Ziekenhuisverblijf Een voorschrift in het kader van een RIZIV contract kan geassocieerd worden met een ziekenhuisverblijf. Deze informatie is volgens de Belgische wetgeving nodig om op een correcte wijze te kunnen tariferen en factureren. Wanneer een voorschrift met een ziekenhuisverblijf gekoppeld wordt, dan moet het betrokken ziekenhuis eenduidig geïdentificeerd worden. Hiervoor wordt binnen het INTERLIS systeem het RIZIV erkenningnummer van de instelling gebruikt.

9

INTERLIS v1.10

Voor het INTERLIS worden twee notaties voor RIZIV erkenningsnummers gestandaardiseerd: een code van 11 posities enkel bestaande uit cijfers een code van 14 posities van het formaat “x-xxxxx-xx-xxx” (dus inclusief de „-„ tekens) Een LIS kan vrij kiezen welk van deze notaties het wenst te hanteren. Voor voorschriften die onder een niet RIZIV contract vallen, is de kennis van een mogelijk ziekenhuisverblijf niet relevant.

1.15 Verzekeringsgegevens Wanneer een onderaannemer AC een voorschrift uitgevoerd heeft, is het vanzelfsprekend dat het daarvoor financieel vergoed wordt. Het zal daarom een factuur sturen naar ofwel het klant AC, ofwel het ziekenhuis dat in het voorschrift vermeld wordt als verblijfplaats van de patiënt. Hieruit volgt dat de onderaannemer nooit rechtstreeks contact moet opnemen met het verzekeringsorganisme dat tussenkomt voor het betalen van deze factuur. Dit is de taak van het klant AC of het betrokken ziekenhuis. Nochtans wordt er gevraagd de verzekeringsgegevens bij het voorschrift te vermelden, indien dit van toepassing is en voor zover dit mogelijk is. Dit om toe te laten het administratief dossier van de betroken patiënt bij het onderaannemer AC zo volledig mogelijk te maken. We voorzien geen machinale verwerking van deze gegevens, daarom wordt er ook niet getracht om de exacte vorm en inhoud ervan formeel te specificeren.

10

INTERLIS v1.10

2. INTERLIS barcodes 2.1 Standaarden Voor de fysische codering wordt de Code-128 standaard gebruikt. De modaliteiten die hierbij van toepassing zijn, worden in sectie 2.4 besproken. De vooropgestelde structuur van de gegevens die als een INTERLIS barcode uitgedrukt worden, wordt gestandaardiseerd in secties 2.2 en 2.3. Mogelijke modificaties op deze structuren worden vermeld in daarop volgende secties. Er zijn twee soorten gegevens die als barcode voorgesteld moeten worden: de staalID’s voor gebruikt op een etiket, en de voorschrift-ID’s voor gebruik op een aanvraagformulier. De structuren die we definiëren bevatten naast de eigenlijke ID‟s ook een aanduiding van de soort, zodanig dat een staal-ID barcode nooit als een voorschrift-ID barcode kan geïnterpreteerd worden of omgekeerd. We voorzien eveneens het gebruik van barcodes volgens de CLSI-AUTO7-A norm. De mapping van CLSI-AUTO7-A naar INTERLIS concepten wordt in sectie 2.5 beschreven. Ook voorzien we het gebruik van barcodes volgens de ISBT-128 norm. De mapping van ISBT-128 naar INTERLIS concepten wordt in sectie 2.6 beschreven. Indien er andere barcode standaarden zijn die zoals CLSI-AUTO7-A en ISBT-128 een zeker toepassingsgebied hebben dat met het INTERLIS systeem zou kunnen overlappen, dan kan het gebruik hiervan later op gelijkaardige wijze aan deze specificatie toegevoegd worden.

2.2 Staaletiket Een staaletiket moet een barcode bevatten bestaande uit de concatenatie van een LIS-ID en een staal-ID. Er worden geen prefix tekens gedefinieerd, zodanig dat de barcode breedte minimaal is. Een dergelijke code kan herkend worden aan het feit dat ze start met de 5 hoofdletters van de LIS-ID. Geen enkele andere INTERLIS barcode voldoet aan deze test.

2.3 Aanvraagformulier Een aanvraagformulier moet een barcode bevatten bestaande uit de concatenatie van een uitroepteken, een LIS-ID en een voorschrift-ID.

11

INTERLIS v1.10

Een dergelijke code kan herkend worden aan het feit dat ze start met een uitroepteken, gevolgd door de 5 hoofdletters van de LIS-ID. Geen enkele andere INTERLIS barcode voldoet aan deze test.

2.4 Code-128 De Code-128 symbologie is een ANSI standaard (www.ansi.org). Voor een korte en overzichtelijke beschrijving van de standaard wordt verwezen naar www.barcodeman.com. Ook verwijzen we naar de CLSI-AUTO2-A2 standaard te bekomen op www.clsi.org. Voor het definiëren van de vereisten m.b.t. de fysische dimensies van een barcode, wordt het begrip x-dimensie gebruikt. Dit is de maat van het smalste element dat potentieel in een barcode kan voorkomen. Alle grotere elementen hebben een maat die een geheel veelvoud is van de x-dimensie. Voor het INTERLIS moet de x-dimensie minimaal 0.191 mm zijn. Het gebruik van kleinere x-dimensies wordt niet aangeraden voor open systemen, t.t.z. systemen waarbij de producent en gebruiker van de barcodes niet onder eenzelfde bestuur vallen. De hoogte van een barcode moet groter zijn dan 15% van de symbool lengte en moet ook groter zijn dan 10 mm. De eigenlijke barcode moet voorafgegaan en gevolgd worden door een zogenaamde quiet zone. Deze moet breder zijn dan 10 x-dimensies en ook breder dan 6.35 mm. Deze quiet zones moeten volledig leeg zijn. Elke Code-128 barcode bevat een welgedefinieerde checksum. Het is bijgevolg zinloos om voor onze toepassing een extra foutdetectie mechanisme te definiëren. Het Code-128 systeem definieert 3 verschillende code sets genaamd A, B en C. Het gebruik van elk van deze code sets wordt toegelaten voor de INTERLIS toepassingen. Er wordt wel aangeraden de gebruikte code sets zo efficiënt mogelijk te kiezen zodanig dat de resulterende barcode zo smal mogelijk is.

2.5 CLSI-AUTO7-A De CLSI-AUTO7-A standaard is opgesteld door het CLSI (www.clsi.org), vroeger NCCLS genoemd. De CLSI-AUTO7-A standaard gebruikt de Code-128 symbologie. Deze standaard definieert een barcode structuur om een staal te identificeren. Deze structuur heeft de volgende opbouw (tussen haakjes staat het aantal te gebruiken karakters): <Site Code (9)><Sequence ID (7)>

12

INTERLIS v1.10

De Data ID is gelijk aan een uitroepteken gevolgd door een dubbel punt om aan te duiden dat deze barcode een staal identificatie bevat. De Land Code is de twee-letterige ISO 3166-1-alpha-2 landcode. Dit komt dus overeen met de eerste twee karakters van het LIS-ID. De Site Code is een identificatie die door een erkende instelling wordt toegekend aan een organisatie die in het INTERLIS kader overeenkomt met een LIS. Deze code mapt dus op het INTERLIS concept van LIS-ID. Merk op dat een Site Code conceptueel wel overeenkomt met een LIS-ID, maar zeker niet gelijk is aan een dergelijke ID. Er is dus een zekere vertaling nodig. Hoe deze vertaling moet tot stand komen, wordt niet door dit document gedefinieerd. De Sequence ID bevat het eigenlijke staal-ID van het INTERLIS specimen en is dus in deze standaard hoogstens 7 karakters lang. Het Aliquot ID is optioneel om een aliquot aan te duiden. Dit wordt door ons niet gebruikt in de INTERLIS context. Een staaletiket volgens deze standaard kan herkend worden aan het feit dat ze start met een uitroepteken gevolgd door een dubbel punt. Geen enkele andere INTERLIS barcode voldoet aan deze test. Aangezien een gebruiker van de CLSI-AUTO7-A standaard bij het maken van een staaletiket barcode reeds beschikt over een Site Code, voorzien we ook dat deze standaard gebruikt mag worden voor een aanvraagformulier. In dat geval vereisen we dat de barcode begint met twee uitroeptekens. Het Sequence ID bevat dan het eigenlijke voorschrift-ID. Een aanvraagformulier volgens deze standaard kan herkend worden aan het feit dat ze start met twee uitroeptekens. Geen enkele andere INTERLIS barcode voldoet aan deze test.

2.6 ISBT-128 De ISBT-128 standaard is opgesteld door de ICCBBA (www.iccbba.com) voor gebruik door de International Society for Blood Transfusion (www.isbt-web.org) Deze standaard beschrijft regels voor het identificeren van producten afgeleid van menselijk bloed, weefsel en organen. De ISBT-128 standaard gebruikt de Code-128 symbologie. De ISBT-128 standaard definieert een hele reeks verschillende data structuren. De enige die voor de INTERLIS toepassing van belang is, is de Donation Identification Number. Deze data structuur mapt op ons staal concept. Een ISBT-128 Donation Identification Number barcode heeft volgende structuur: =αppppyynnnnnnff.

13

INTERLIS v1.10

Deze code start dus steeds met een gelijkheidsteken. De rest van deze structuur wordt voor onze doelstellingen vereenvoudigd tot slechts 2 velden. Het eerste omvat posities 2 tot en met 6 (αpppp), het tweede omvat de rest van de barcode (yynnnnnnff). Het eerste veld bevat de ISBT-128 Facility Identification Number. Dit is een nummer dat door de ICCBBA toegekend wordt aan een instelling die donatie identificatie nummers toekent. Dit nummer mapt dus op het INTERLIS concept van LIS-ID. Merk op dat een Facility Identification Number conceptueel wel overeenkomt met een LIS-ID, maar zeker niet gelijk is aan een dergelijke ID. Er is dus een zekere vertaling nodig. Hoe deze vertaling moet tot stand komen, wordt niet door dit document gedefinieerd. Het tweede veld bevat een donatie nummer. Dit veld mapt dus op het INTERLIS concept van staal-ID. Een ISBT-128 Donation Identification Number barcode kan herkend worden aan het feit dat ze start met een gelijkheidsteken. Geen enkele andere INTERLIS barcode voldoet aan deze test.

14

INTERLIS v1.10

3. INTERLIS protocol 3.1 Introductie Het INTERLIS protocol is een communicatieprotocol voor de uitwisseling van aanvragen, resultaten en andere gerelateerde informatie tussen twee labo‟s. Dit protocol is gebaseerd op de HL7 standaard. Het is geen extensie van deze standaard, maar een zuivere specialisatie. Dit hoofdstuk bevat de volledige specificatie van de onderdelen van de HL7 standaard die we voor het INTERLIS protocol gebruiken. Deze versie van het INTERLIS protocol is gebaseerd op HL7 versie 2.5. Verwijzingen vanuit deze tekst naar dit standaard document hebben de vorm: (HL7 x.y.z) De HL7 standaard is een application level protocol. Om een communicatie kanaal volledig te definiëren, moeten we ook de lagere niveau protocols beschrijven. Voor het INTERLIS systeem wordt hiervoor gebruik gemaakt van het E-postiljon mechanisme.

3.2 Het gebruik van de E-postiljon Als transportmedium maakt INTERLIS gebruik van het E-postiljon systeem ontwikkeld door de systeemgroep van UZ Leuven. Dit systeem voorziet in een betrouwbare, chronologische en veilige uitwisseling van bestanden, gebruik makend van de standaard S/MIME e-mail mechanismen. Het configureren van het E-postiljon systeem gebeurt volgens de procedures die in de E-postiljon handleiding beschreven staan. Hierbij wordt o.a. gebruik gemaakt van het LIS-address en de LIS-public-key van alle LIS systemen waarmee communicatie mogelijk moet zijn. De inhoud van elke uitgewisselde verzending is een sequentie van HL7 berichten, mogelijks vergezeld van één of meerdere aparte bijlagen. De subparagrafen van deze sectie beschrijven de verzending van elk van deze twee categorieën. Indien er fouten gedetecteerd worden op niveau van deze bestandsuitwisseling – bv. een HL7 batch bestand (zie verder) met een foutieve naam wordt ontvangen, een HL7 batch bestand wordt ontvangen waarvan de inhoud niet als een geldige HL7 batch herkend wordt, of één of meerdere bijlagen waarnaar verwezen wordt in een HL7 batch ontbreekt – dan moet dit gemeld worden aan afzender. Dit moet gebeuren m.b.v. mechanismen die geen onderwerp uitmaken van deze specificatie (bv. e-mail).

15

INTERLIS v1.10

3.2.1 HL7 berichten Alle HL7 berichten in één sequentie moeten voldoen aan de regels beschreven in deze specificatie. De sequentie zelf wordt opgesteld volgens de principes van het “HL7 Batch protocol” (HL7 2.10.3). De concrete toepassing van dit batch mechanisme wordt in sectie 3.5 van deze specificatie beschreven. Elk LIS mag autonoom beslissen hoeveel berichten tezamen in één bestand opgenomen worden. Er mag bv. niet verwacht worden dat de ontvangstbevestigingen voor een reeks berichten die als één bestand verzonden werden, ook als één bestand zullen verzonden worden. Het afzender LIS kent aan een te verzenden bestand een naam toe die voldoet aan het volgende patroon: XXXXX-YYYYMMDD-HHMM-NNNN.HL7 Hierbij is: XXXXX YYYYMMDD HHMM NNNN HL7

de LIS-ID van het afzender LIS de datum waarop dit bestand door afzender LIS gegenereerd werd het tijdstip waarop dit bestand door afzender LIS gegenereerd werd een sequentieel volgnummer dat door afzender LIS toegekend werd de verplichte extensie “HL7” die aanduidt de inhoud een HL7 bericht is

het het het dat

Het ontvanger LIS controleert of de LIS-ID component van de namen van de ontvangen bestanden wel degelijk de ID is die hoort bij het e-mail adres van de afzender. Voor het toekennen van het volgnummer, mag het afzender LIS om het even welk algoritme hanteren. Deze component dient enkel voor het uniek maken van namen van bestanden die (ongeveer) op hetzelfde ogenblik gegenereerd werden. Het E-postiljon systeem garandeert dat bestanden in alfabetische volgorde zullen afgeleverd worden. Het voorgeschreven patroon voor de bestandsnamen leidt ertoe dat deze ordening ook congruent is met de chronologie van de generatie van de bestanden. Om deze chronologie end-to-end te garanderen, is het natuurlijk aan de ontvanger om deze bestanden ook in alfabetische volgorde te verwerken.

3.2.2 Bijlagen Naast HL7 berichten voorziet het INTERLIS systeem ook de mogelijkheid voor de uitwisseling van bijlagen, bestanden waarnaar verwezen wordt in een HL7 bericht. Deze extra bestanden dienen ook via het E-postiljon systeem verstuurd te worden.

16

INTERLIS v1.10

Om een gelijktijdige verzending (en verwerking door de ontvanger) te garanderen van een HL7 batch tezamen met al zijn bijhorende bijlagen, moeten zowel het batch bestand als de extra bestanden in één gemeenschappelijke folder voorkomen. Bovendien vereisen we dat de naam van deze folder overeenkomt met de naam van zijn (ene) HL7 batch bestand. Zodoende blijft ook de chronologische verwerking van alle HL7 batch bestanden (die niet in een folder zijn opgenomen) en folders (bestaande uit één HL7 batch bestand en alle bijlagen die horen bij een van de HL7 berichten uit de batch) verzekerd. Hieronder staat een voorbeeld van een mogelijke E-postiljon OUTBOX structuur: OUTBOX ZZZZZ-20100830-1015-0000 Bijlage1.pdf Bijlage2.jpg ZZZZZ-20100830-1015-0000.HL7 ZZZZZ-20100830-1017-0000.HL7

Geldige bestandstypes voor afbeeldingen zijn: “JP(E)G”, “Bitmap (BMP)”, “GIF”, “TIFF” en “PNG”. Geldige bestandstypes voor tekstuele rapporten zijn: “Tekst zonder opmaak (TXT)”, “Rich Text Format (RTF)”, “XML”, “Adobe PDF”, “Microsoft Word 972003-document (DOC)”, “Microsoft Word-document (DOCX)”, “Microsoft Excel 972003-werkmap (XLS)” of “Microsoft Excel-werkmap (XLSX)”.

3.3 De HL7 bericht structuur Deze sectie heeft betrekking op hoofdstuk “Control” (HL7 2). We laten het gebruik toe van alle mogelijkheden die in dit hoofdstuk beschreven worden, buiten diegene die hieronder expliciet als niet gebruikt opgesomd worden. De mechanismen beschreven in “Response using enhanced acknowledgement” (HL7 2.9.3) worden niet gebruikt. Dit houdt dus in dat we de “original processing rules” van paragraaf (HL7 2.9.2) gebruiken. De “enhanced acknowledgement rules” geven voor onze toepassing geen voordeel, daar we geen real-time data uitwisseling doen. Dus kunnen we net zo goed wachten op een application level acknowledgement voordat we een ontvangstbevestiging terugsturen. Merk op dat het E-postiljon mechanisme ook een low-level acknowledge fase inhoudt. Er wordt geen gebruik gemaakt van het “Sequence number protocol” (HL7 2.10.1) Er wordt geen gebruik gemaakt van “Continuation messages and segments” (HL7 2.10.2) Er wordt geen gebruik gemaakt van de mechanismen beschreven in “Modes for updating via repeating segments” (HL7 2.10.4).

17

INTERLIS v1.10

Er wordt geen gebruik gemaakt van “Local extension”s (HL7 2.11) Er wordt geen gebruik gemaakt van de mechanismen beschreven in “Conformance using message profiles” (HL7 2.12).

3.4 Segmenten Segmenten die in dit hoofdstuk niet expliciet vermeld worden, worden voor onze toepassing niet gebruikt. Per segment zal besproken worden welke velden – buiten de standaard vereiste velden – door onze toepassing gebruikt worden. Let wel: we houden het algemeen geldende HL-7 principe aan dat segmenten en velden die voorkomen in een bericht op een plaats waar dat volgens de standaard mag maar die door een toepassing niet gebruikt worden, eenvoudig genegeerd moeten worden.

3.4.1 Het BHS segment Deze sectie heeft betrekking op hoofdstuk “BHS – batch header segment” (HL7 2.15.2). Dit segment duidt het begin van een batch van berichten aan. Het is het eerste segment van een communicatiebestand. Het gebruik van het BHS-3 Batch Sending Application veld is verplicht. Dit veld moet de ID van het afzender LIS bevatten. Indien de waarde die in veld BHS-3 voorkomt niet gelijk is aan de LIS-ID die in de naam van het communicatiebestand voorkomt, dan moet de ontvanger deze batch in zijn geheel verwerpen. Het gebruik van het BHS-4 Batch Sending Facility veld is verplicht. Dit veld moet de AC-ID van het afzender AC bevatten. Het gebruik van het BHS-5 Batch Receiving Application veld is verplicht. Dit veld moet de LIS-ID van het bestemmeling LIS bevatten. Indien aan het ontvanger LIS niet de ID toegekend is die in veld BHS-5 voorkomt, dan moet het ontvanger LIS de batch in zijn geheel verwerpen. Het gebruik van het BHS-6 Batch Receiving Facility veld is verplicht. Dit veld moet de AC-ID van het bestemmeling AC bevatten.

18

INTERLIS v1.10

Indien het ontvanger LIS de waarde van veld BHS-6 niet herkent als de AC-ID van een AC die met dit LIS verbonden is, dan moet het ontvanger LIS de batch in zijn geheel verwerpen. Het gebruik van het BHS-11 Batch Control Id veld is verplicht. Het afzender LIS kent aan elke verzonden batch een uniek identifier toe, volgens een methode die het zelf mag bepalen.

3.4.2 Het BTS segment Deze sectie heeft betrekking op hoofdstuk “BTS – batch trailer segment” (HL7 2.15.3). Dit segment duidt het einde van een batch van berichten aan. Het is het laatste segment van een communicatiebestand. Het gebruik van veld BTS-1 Batch Message Count is verplicht. Indien de inhoud van dit veld niet overeenstemt met het aantal berichten dat in de batch gevonden werd, dan moet de ontvanger deze batch in zijn geheel verwerpen.

3.4.3 Het ERR segment Deze sectie heeft betrekking op hoofdstuk “ERR – error segment” (HL7 2.15.5). Enkel de volgende velden worden gebruikt voor onze toepassing: ERR-2 Error Location ERR-3 HL7 Error Code ERR-4 Severity ERR-5 Application Error Code ERR-6 Application Error Parameter Voor veld ERR-3 HL7 Error Code wordt de waarde 0 niet ondersteund. Voor veld ERR-4 Severity wordt enkel de waarde “E” ondersteund. Voor veld ERR-5 Application Error Code wordt gebruik gemaakt van de waarden die in de desbetreffende secties van deze specificatie gedefinieerd worden. De betekenis van de waarde van veld ERR-6 Application Error Parameter is functie van de waarde van veld ERR-5 en wordt ook in de desbetreffende secties uiteengezet.

3.4.4 Het MSA segment Deze sectie heeft betrekking op hoofdstuk “MSA – message acknowledgement segment” (HL7 2.15.8).

19

INTERLIS v1.10

Voor veld MSA-1 Acknowledgement Code zijn enkel de waarden “AA” en “AR” geldig (we werken niet met de “enhanced acknowledgement rules”).

3.4.5 Het MSH segment Deze sectie heeft betrekking op hoofdstuk “MSH – message header segment” (HL7 2.15.9). Indien veld MSH-3 Sending Application een waarde heeft, dan moet deze gelijk zijn aan de waarde van veld BHS-3 van de batch waarin dit bericht voorkomt. Mutatis mutandis voor velden MSH-4, MSH-5 en MSH-6. Indien veld MSH-11 Processing ID niet de waarde “P” (production) heeft, dan wordt het vereiste gedrag bij het ontvangen van een bericht niet bepaald door deze specificatie. De betekenis van de waarden “D” (debugging) en “T” (training) kan onderwerp uitmaken van een aparte overeenkomst tussen twee communicerende partijen. Veld MSH-12 Version code moet een waarde groter dan of gelijk aan “2.5” bevatten, zolang als er maar voldaan is aan de minimale vereisten van het INTERLIS protocol (dat gebaseerd is op HL7 versie 2.5). We herinneren eraan dat men bij de verwerking van HL7 berichten steeds rekening dient te houden met de sectie “Rules for the recipient” (HL7 2.6.2). In deze sectie wordt enerzijds gespecificeerd om onbekende segmenten, velden en (sub)componenten te negeren. Anderzijds dienen verwachte, maar niet inbegrepen segmenten, velden en (sub)componenten behandeld te worden als niet aanwezig. Indien veld MSH-13 Sequence Number een waarde heeft, dan moet dit de null waarde zijn (want het “sequence number protocol” wordt door onze toepassing niet gebruikt). Indien veld MSH-18 Character Set code een waarde heeft, dan moet dit “ASCII” of “8859/1” zijn.

3.4.6 Het NTE segment Deze sectie heeft betrekking op hoofdstuk “NTE – notes and comments segment” (HL7 2.15.10). Enkel veld NTE-3 Comment wordt gebruikt door onze toepassing.

3.4.7 Het PID segment Deze sectie heeft betrekking op hoofdstuk “PID – Patiënt Identification Segment” (HL7 3.4.2). Het PID segment beschrijft een patiënt.

20

INTERLIS v1.10

Veld PID-3 Patiënt Identifier List bevat een niet-lege lijst van patiënt identificaties. Voor onze toepassing worden enkel de volgende componenten van een identificatie gebruikt: ^^^ M.a.w. de Check Digit en Check Digit Scheme componenten worden niet gebruikt, net als alle componenten die volgen op de Assigning Authority. De ID Number (ST) component bevat een patient-ID. Van de Assigning Authority (HD) component wordt enkel de Namespace ID (IS) subcomponent gebruikt. Deze bevat de patiënt-ID-authority-ID Veld PID-5 Patiënt Name bevat een lijst van namen van de patiënt. Voor onze toepassing wordt max. 1 element uit deze lijst gebruikt, en van dit element worden enkel de volgende componenten gebruikt: ^^^^^^ Voor de Family Name component wordt enkel de Surname subcomponent gebruikt. Voor de Name Type Code component worden enkel de waarden “L” en “D” gebruikt. Wanneer de waarde “D” (Display Name) is gebruikt, wordt verondersteld dat de volledige naam van de patiënt enkel in de Surname subcomponent van de Family Name component vermeld is. De inhoud van component Given Name is dan irrelevant. Deze mogelijkheid kan gebruikt worden, wanneer de patiënt naam niet kan opgesplitst worden in een voor- en familienaam. Het wordt echter steeds aangeraden de patiënt naam wel op te splitsen en enkel de waarde “D” te gebruiken indien het niet anders kan. In het geval de waarde “L” (Legal Name) is gebruikt moet de patiënt naam opgesplitst worden in de twee componenten Family Name en Given Name. Wanneer de Name Type Code component niet is ingevuld, wordt de waarde “L” verondersteld. Veld PID-7 Date/Time of Birth bevat de geboortedatum van de patiënt. Veld PID-8 Administrative Sex bevat een aanduiding van het geslacht van de patiënt. Enkel de waarden “F” en “M” zijn toegelaten. Veld PID-11 Patient address bevat een lijst van adressen van de patiënt. Voor onze toepassing wordt max. 1 element uit deze lijst gebruikt, en van dit element worden enkel de volgende componenten gebruikt: <Street Address (SAD)>^ ^^^^ De Street Address (SAD) subcomponent is op haar beurt ook gestructureerd, en wel als volgt:

21

INTERLIS v1.10

<Street or Mailing Address (ST)&<Street Name (ST)>& Er wordt dus de mogelijkheid geboden om straat en nummer als twee aparte entiteiten te vermelden. Er wordt aangeraden van deze mogelijkheid gebruik te maken. Indien het Street Name (ST) element een waarde heeft, zal de mogelijke waarde van het Street or Mailing Address (ST) element genegeerd worden. De waarde van het Dwelling Number (ST) element wordt enkel beschouwd indien het Street Name (ST) element een waarde heeft.

3.4.8 Het PV1 segment Deze sectie heeft betrekking op hoofdstuk “PV1 – Patient Visit Segment” (HL7 3.4.3) Dit segment wordt gebruikt om, voor een voorschrift in het kader van een RIZIV contract, aan te geven dat het gevraagde onderzoek verbonden is met een welbepaald ziekenhuisverblijf, en welke de kenmerken zijn van dit ziekenhuisverblijf. Dit segment wordt herkend als een codering van een ziekenhuisverblijf, indien aan alle volgende voorwaarden voldaan is: Veld PV1-2 Patiënt Class bevat de waarde “E” (emergency), “I” (inpatient) of “B” (obstetrics). Veld PV1-3 Assigned Patiënt Location bevat een verwijzing naar een ziekenhuis. Voor onze toepassing worden enkel de volgende componenten van dit veld gebruikt: ^^^^^^^ De Namespace ID (IS) subcomponent van de Facility (HD) component bevat het RIZIV erkenningnummer van het ziekenhuis, in een van de notaties die voor het INTERLIS gestandaardiseerd zijn. De Person Location Type (IS) subcomponent bevat de waarde “C” (clinic). De Namespace ID (IS) subcomponent van de Assigning Authority for Location (HD) component bevat de waarde “RIZIV”. Indien het aanvraagbericht geen PV1 segment bevat, of indien het PV1 segment niet aan al de hierboven opgesomde voorwaarden voldoet, dan moet dit geïnterpreteerd worden als een voorschrift dat niet verbonden is met een ziekenhuisverblijf. Het vermelden van een PV1 segment dat niet aan de hierboven opgesomde voorwaarden voldoet, is zinloos maar niet verboden.

22

INTERLIS v1.10

Voor een voorschrift dat niet onder een RIZIV contract valt, is het gebruik van dit segment zinloos maar niet verboden.

3.4.9 Het ORC segment Deze sectie heeft betrekking op hoofdstuk “ORC – Common Order Segment” (HL7 4.5.1) Het ORC segment beschrijft een voorschrift. Veld ORC-1 Order Control geeft aan welke actie moet ondernomen worden m.b.t. het beschreven voorschrift. Voor onze toepassing worden enkel de waarden “NW” (new order), “CA” (cancel order) en “OK” gebruikt. Veld ORC-2 Placer Order Number is steeds vereist. Het bevat het voorschrift-ID van het te creëren of te annuleren voorschrift. Enkel de component <Entity Identifier (ST)> wordt voor onze toepassing gebruikt. Veld ORC-12 Ordering Provider bevat de identiteit van de voorschrijver van dit voorschrift. Voor onze toepassing worden enkel de volgende componenten van dit veld gebruikt: ^^^^^^^^ Dit wil zeggen dat de componenten Second and Further Given Names or Initials Thereof (ST), Suffix (e.g., JR or III) (ST), Prefix (e.g., DR) (ST), DEPRECATEDDegree (e.g., MD) (IS), Source Table (IS) en alle componenten die volgen op de Assigning Authority (HD) component, niet gebruikt worden. De ID Number component bevat de arts-ID. Voor de Family Name component wordt enkel de Surname subcomponent gebruikt. Van de Assigning Authority (HD) component wordt enkel de Namespace ID (IS) subcomponent gebruikt. Deze bevat de arts-ID-authority-ID Volgens de HL7 specificatie mag veld ORC-12 Ordering Provider een lijst bevatten. Voor onze toepassing wordt enkel het eerste element van deze lijst beschouwd. Veld ORC-19 Action By bevat de identiteit van de klinisch bioloog die binnen het klant AC verantwoordelijk is voor het doorgeven van dit voorschrift aan de onderaannemer. De structuur van dit veld is volledig analoog aan veld ORC-12 Ordering Provider. Beide velden, ORC-12 Ordering Provider en ORC-19 Action By, zijn steeds vereist bij het aanvragen van een nieuw voorschrift.

23

INTERLIS v1.10

3.4.10

Het BLG segment

Deze sectie heeft betrekking op hoofdstuk “BLG – Billing Segment” (HL7 4.5.2) Dit segment duidt het contract aan waarbinnen een voorschrift dient uitgevoerd te worden. Indien veld BLG-2 Charge Type een waarde heeft, moet dit de waarde “CO” (Contract) zijn. Veld BLG-3 Account ID is vereist. Het bevat een verwijzing naar een contract. Voor onze toepassing worden enkel de volgende componenten van dit veld gebruikt: ^<^^ De ID Number component bevat de contract-ID van het contract. De Assigning Authority (HD) component bevat de AC-ID van het onderaannemer AC.

3.4.11

Het IN1 segment

Deze sectie heeft betrekking op hoofdstuk “IN1 – Insurance Segment” (HL7 6.5.6) Dit segment bevat de verzekeringsgegevens die van toepassing zijn voor een voorschrift. Buiten de algemeen geldende regels van de HL7 standaard, worden er voor het INTERLIS systeem geen bijkomende vereisten gesteld.

3.4.12

Het OBR segment

Deze sectie heeft betrekking op hoofdstuk “OBR – Observation Request Segment” (HL7 4.5.3) Het OBR segment beschrijft de aanvraag van een individuele test. Het gebruik van veld OBR-1 Set ID is verplicht. Veld OBR-2 Placer Order Number bevat als waarde het voorschrift-ID van het voorschrift waartoe de aanvraag hoort. Enkel de component <Entity Identifier (ST)> wordt voor onze toepassing gebruikt. De waarde van veld OBR-4 Universal Service Identifier duidt de aangevraagde test aan, onder de vorm van een LOINC of LIS specifieke code. Voor onze toepassing worden enkel de volgende componenten van dit veld gebruikt: ^^ De Identifier component bevat de eigenlijke test code. De Text component bevat een leesbare omschrijving van deze code. De Name of coding system component bevat de waarde “LN” (voor het LOINC systeem) of – in navolging van de HL7 standaard – de concatenatie van de tekststring “99” en de LIS-ID (voor een LIS specifieke code).

24

INTERLIS v1.10

Veld OBR-11 Specimen Action Code is verplicht. Dit veld mag enkel een waarde bevatten uit onderstaande tabel (dit is een subset van HL7 Table 0065): G Generated order, reflex order O Specimen obtained by service other than lab P Pending specimen; Order sent prior to delivery Veld OBR-36 Scheduled Date/Time wordt gebruikt door het onderaannemer Labo om aan de klant het verwachte tijdstip van rapporteren te melden.

3.4.13

Het SPM segment

Deze sectie heeft betrekking op hoofdstuk “SPM – Specimen Segment” (HL7 7.4.3) Het SPM segment beschrijft een staal. Veld SPM-2 Specimen ID is vereist. Het bevat de staal-ID van het beschreven staal. Enkel de subcomponent <Entity Identifier (ST)> van de component van dit veld wordt voor deze toepassing gebruikt. Veld SPM-4 Specimen Type is vereist. Enkel de component van dit veld wordt door deze toepassing gebruikt. Het wordt aanbevolen veld SPM-6 Specimen Additives te gebruiken indien dit van toepassing is voor het beschreven staal. Enkel de component van dit veld wordt door deze toepassing gebruikt. Veld SPM-14 Specimen Description kan een bijkomende beschrijving van het staal bevatten. Het wordt niet voorzien dat de waarden van velden SPM-4, SPM-6 en SPM-14 automatisch moeten verwerkt worden, vandaar dat het voldoende geacht wordt om enkel de componenten te hanteren. Deze gegevens worden enkel geregistreerd om indien nodig geïnterpreteerd te worden door een persoon die het correcte fysische staal bij een gegeven staal-ID moet zoeken. Veld SPM-17 Specimen Collection Date/Time bevat het tijdstip waarop de bemonstering bij de patiënt werd uitgevoerd. Het is vereist indien dit segment hoort tot een voorschrift dat onder de RIZIV richtlijnen valt. Dit veld laat toe een tijdvenster i.p.v. een tijdstip te specificeren. Indien er een tijdvenster opgegeven wordt, moet enkel rekening gehouden worden met het startpunt van dit venster. De waarde van veld SPM-17 wordt gebruikt voor het bepalen van de ouderdom van de betrokken patiënt, indien dit belang heeft bv. voor het selecteren van de juiste referentiewaarden.

25

INTERLIS v1.10

Veld SPM-18 Specimen Received Date/Time bevat het tijdstip waarop het staal in het onderaannemer AC gereceptioneerd werd. Veld SPM-21 Specimen Reject Reason bevat een aanduiding van de reden waarom een staal met alle testen die erop gevraagd zijn, geweigerd werd. Voor onze toepassing wordt de structuur van dit veld als volgt vereenvoudigd: ^ Er kan gebruik gemaakt worden van een subset van de standaard codes voor dit veld, of van een vrije tekst. Indien gebruik gemaakt wordt van een gecodeerde waarde, moet component Identifier een waarde hebben uit de onderstaande tabel, en moet component Name of coding system de waarde “HL70490”. EX QS RB RC RH RI RN RR

Expired Quantity not sufficient Broken container Clotting Hemolysis Identification problem Contamination Improper storage

De code “EX” wordt voor onze toepassing geïnterpreteerd als “het staal is niet binnen redelijke termijn toegekomen in het onderaannemer AC”. De definitie van de redelijke termijn valt buiten het domein van deze specificatie. De code “QS” wordt voor onze toepassing geïnterpreteerd als “de container bevat niet genoeg materiaal”, met als speciaal geval “de container is leeg”. De code “RI” wordt voor onze toepassing geïnterpreteerd als “de informatie op het etiket wijkt af van de elektronische informatie in het voorschrift”. Het is ook toegelaten een vrije tekst als reden van weigering op te geven. In dat geval hebben componenten Identifier en Name of coding system geen waarde, en is component Text verplicht.

3.4.14

Het OBX segment

Deze sectie heeft betrekking op hoofdstuk “OBX – Observation/Result Segment” (HL7 7.4.2) Het OBX segment wordt gebruikt voor het rapporteren van een enkelvoudig resultaat. Veld OBX-1 Set ID – OBX is verplicht.

26

INTERLIS v1.10

Veld OBX-2 Value Type bevat een aanduiding van het type van het resultaat. Enkel de waarden “CE” (coded entry), “FT” (formatted text), “NM” (numeric), “RP” (reference pointer), “SN” (structured numeric) en “ST” (string data) zijn toegelaten. Veld OBX-3 Observation Identifier bevat de LOINC of LIS specifieke code van de test waarvoor dit resultaat geldt. De structuur van dit veld wordt voor onze toepassing als volgt vereenvoudigd: ^^ Hierbij is component Identifier de eigenlijke code, component Text is een leesbare omschrijving van deze code. De Name of coding system component bevat de waarde “LN” (voor het LOINC systeem) of – in navolging van de HL7 standaard – de concatenatie van de tekststring “99” en de LIS-ID (voor een LIS specifieke code). Veld OBX-4 Observation Sub ID wordt gebruikt om structuur aan te brengen in een reeks van verschillende resultaten die allen horen tot eenzelfde testcode. Deze resultaten horen gerapporteerd te worden volgens de oplopende waarde van deze sub ID. Veld OBX-5 Observation Value is een vereist veld, behalve wanneer veld OBX-11 de waarde “I”, “D” of “X” heeft. In het geval van een reëel getal zal veld OBX-2 steeds de waarde “SN” (structured numeric) hebben. Het veld OBX-5 is dan in het algemeen van het formaat: ^^<Separator/Suffix (ST)>^ In het geval dat de component Separator/Suffix gelijk is aan “.”, zal het bedoelde resultaat overeenkomen met het product van de reële waarden in de componenten Num1 en Num2, meer bepaald: Num1 maal Num2. In het geval dat de component Separator/Suffix gelijk is aan “:”, zal het bedoelde resultaat overeenkomen met het quotiënt van de reële waarden in de componenten Num1 en Num2, meer bepaald: Num1 gedeeld door Num2. Het aldus bekomen resultaat staat in de eenheden zoals vermeld in veld OBX-6. Voor de comparator component zijn de volgende vergelijkingsoperatoren geldig: ">", "<", ">=", "<=" of "=". Enkel de Num1 component is vereist voor INTERLIS. Wanneer de andere componenten niet voorkomen, worden de volgende standaard waarden verondersteld: Component Comparator Separator/Suffix Num2

Standaard waarde = . 1

Zo wordt bv met |^100| een resultaat bedoeld dat gelijk is aan 100. In het geval van een reference pointer, dient veld OBX-5 een bestandsnaam (met extensie) te specifiëren die verwijst naar een extern bestand waarin het eigenlijke

27

INTERLIS v1.10

resultaat wordt beschreven. Dit extern bestand dient tegelijkertijd met het eigenlijke HL7 bericht via het E-postiljon systeem verstuurd te worden, zoals beschreven in §3.2.2. Veld OBX-6 Units bevat de eenheid waarin de waarde van OBX-5 uitgedrukt is (indien dit relevant is). De structuur van dit veld wordt voor onze toepassing als volgt vereenvoudigd: ^^ De Identifier component bevat een voorstelling van de eenheid volgens het gebruikte codeersysteem, aangeduid door de derde component Name of Coding System. Het INTERLIS systeem erkent twee types codeersystemen: het standaard ISO+ systeem (HL7 7.4.2.6, 7.18.3) met een ID gelijk aan “ISO+” en een LIS specifiek codeersysteem waarin bijzondere LIS specifieke eenheden worden gedefinieerd die niet volgens het ISO+ systeem kunnen gecodeerd worden. In navolging van de HL7 standaard stellen we de ID van een dergelijk lokaal systeem gelijk aan de concatenatie van de tekststring “99” en de LIS-ID. Bij eenheden volgens een LIS specifiek systeem is de Text component verplicht. Deze bevat een nadere omschrijving van de gebruikte eenheid. Wanneer bij het doorsturen van een resultaat de betrokken eenheid, die gebruikt wordt voor de interne rapportering binnen een LIS, omgezet wordt naar de ISO+ syntax, is het aanbevolen om dezelfde “vorm en betekenis” te behouden voor de omgezette eenheid: stel bv dat een resultaat intern wordt uitgedrukt als “5 milliliter”. Dan staan hieronder twee van de mogelijke (weliswaar correcte) manieren om dit resultaat door te sturen in ISO+ eenheden, waarvan de eerste meer verkieslijk is (ervan uitgaande dat een milliliter overeenkomt met de meest gangbare manier waarop een dergelijk resultaat intern in het betrokken LIS wordt behandeld, nl. zonder “belastende” schaalfaktor t.o.v. een basis eenheid): |=^5|mL^^ISO+| |=^5^.^0.001|L^^ISO+| Veld OBX-7 References Range bevat de referentiewaarden. Deze waarden zijn bepaald in functie van het geslacht en de leeftijd van de betrokken patiënt. Indien het voor een test niet mogelijk is om uitgaande van deze eigenschappen unieke referentiewaarden te bepalen, dan zal dit veld geen waarde hebben. Een omschrijving van alle toepasbare waarden zal dan volgen in een of meerdere NTE segmenten waarvan de eerste herhaling van het NTE-3 Comment veld gelijk is aan “Referentie”. Wanneer er een omschrijving van de referentiewaarden beschikbaar is, zal deze steeds vermeld staan in de tweede herhaling van het NTE-3 Comment veld. De eigenlijke referentiewaarden volgen in de laatste herhaling van dit veld in het formaat “min-max” (of één getal voorafgegaan door een vergelijkingsoperator in het geval er geen range is). Wanneer er unieke referentiewaarden gevonden zijn, zullen deze steeds in het OBX-7 veld vermeld staan, maar zonder een bijkomende omschrijving.

28

INTERLIS v1.10

Net als voor het OBX-5 veld moeten de referentiewaarden nog vermenigvuldigd worden met dezelfde factor als de waarden van het resultaat om de eigenlijke referentiewaarden te bekomen. Deze factor wordt echter niet herhaald omwille van de eenvoud van de notatie, aangezien deze dezelfde is als het OBX-5 veld. Indien de patiënt of één van zijn eigenschappen niet gekend zijn door het onderaannemer AC, dan zal veld OBX-7 steeds geen waarde hebben. In dit geval zullen er ook geen NTE segmenten volgen met een omschrijving van de toepasbare waarden. Mogelijke waarden voor veld OBX-8 Abnormal Flags zijn: Waarde N L H NULL

Betekenis Het resultaat valt binnen normale waarden Het resultaat is lager dan normaal Het resultaat is hoger dan normaal Het is onmogelijk of irrelevant om de (ab)normaliteit van het resultaat vast te stellen. Dat kan bijvoorbeeld het geval zijn wanneer er geen referentiewaarden voor het resultaat van toepassing zijn of wanneer er meerdere referentiewaarden mogelijks van toepassing zijn maar niet allen leiden tot een gelijke waarde voor dit veld.

Veld OBX-11 Observation Result Status mag enkel de waarde “I” (initieel, nl. geen resultaat of annulatie), “C” (correctie), “D” (wissen), “F” (finaal) of “X” (annulatie) bevatten. Veld OBX-17 Observation Method bevat een aanduiding van de methode waarmee het resultaat bepaald werd. Deze aanduiding wordt gecodeerd volgens een schema dat door het onderaannemer AC autonoom bepaald wordt. De structuur van dit veld wordt voor onze toepassing als volgt vereenvoudigd: ^^ Hierbij is component Identifier de eigenlijke methode code die door het onderaannemer AC toegekend werd aan de gebruikte methode, component Text is een leesbare omschrijving van deze code (bv. een datum waarop de methode in voege is getreden), en component Name of coding system heeft als prefix de ID van het onderaannemer AC.

3.5 Het batch protocol Deze sectie heeft betrekking op hoofdstuk “HL7 Batch protocol” (HL7 2.10.3). Zoals in sectie 3.2 reeds beschreven werd, groeperen we meerdere berichten tot één batch in een communicatiebestand. Het algemeen HL7 batch mechanisme is te generiek voor onze toepassing. We beperken het dan ook tot volgende structuur: BHS [ { MSH … } ] BTS

29

INTERLIS v1.10

Merk op dat het gebruik van een BHS segment verplicht is. Het duidt eenduidig het begin van een batch aan. Ook het gebruik van het BTS segment is verplicht. Het biedt een zekere bescherming tegen het onverhoeds afbreken van een communicatiebestand. Merk ook op dat de FHS en FTS segmenten niet gebruikt worden. Merk ook op dat het gebruik van meer communicatiebestand niet ondersteund wordt.

dan

één

batch

binnen

één

Indien een ontvanger LIS een batch in zijn geheel verwerpt, dus zonder naar de individuele berichten te kijken die erin voorkomen, dan moet dit aan het afzender LIS gemeld worden. De manier waarop een dergelijke probleemmelding verstuurd moet worden, valt buiten het domein van deze specificatie. Een ontvanger LIS moet de berichten die in een batch verpakt zijn, in volgorde behandelen.

3.6 Events en berichten Events en berichten die niet expliciet beschreven worden in deze specificatie, worden door onze toepassing niet gebruikt.

3.6.1 Generiek antwoord bericht Deze sectie heeft betrekking op hoofdstuk “ACK – general acknowledgement” (HL7 2.14.1) Elk bericht dat een afzender LIS naar een bestemmeling LIS verstuurt, wordt door dit bestemmeling LIS beantwoord d.m.v. een ACK bericht, tenzij er een meer specifiek antwoord bericht gedefinieerd is. De structuur van dit bericht wordt voor deze toepassing als volgt vereenvoudigd: MSH MSA [ { ERR } ]

Message header

Indien het MSA-1 Acknowledgement Code veld van het MSA segment de waarde “AA” bevat, dan mogen er geen ERR segmenten volgen. Indien het MSA-1 Acknowledgement Code veld van het MSA segment de waarde “AR” bevat, dan moet er minstens één ERR segment volgen.

3.6.2 Creatie van een nieuw voorschrift Deze sectie heeft betrekking op hoofdstuk “OML – Laboratory order for multiple orders related to a single specimen (event O33)” (HL7 4.4.8)

30

INTERLIS v1.10

Wanneer een klant AC een of meer voorschriften wenst te laten uitvoeren, dan zendt het een OML bericht, event O33, naar de gewenste onderaannemer. De structuur van het OML^O33^OML_O33 bericht wordt voor deze toepassing als volgt vereenvoudigd: MSH [ NTE ] [ PID [ PV1 ] [ { IN1 } ] ] { SPM [ { OBX } ] { ORC OBR [ BLG ] } }

Message Header Notes and Comments (for Header) Patient Identification Patient Visit Insurance --- Specimen begin Specimen Observations related to specimen --- Order begin Common Order Observation Request Billing segment --- Order end --- Specimen end

Het NTE segment wordt gebruikt voor het meedelen van ongestructureerde klinische informatie bij de voorschriften. Alle herhalingen van de Comment component worden in rekening gebracht. Het wordt niet voorzien dat de inhoud van dit segment automatisch verwerkt wordt door het onderaannemer LIS. Deze gegevens worden enkel geregistreerd om indien nodig geïnterpreteerd te worden door een persoon die de voorschriften verwerkt. Het PID segment duidt de patiënt aan waarvoor deze nieuwe voorschriften gelden. Het PV1 segment wordt gebruikt om aan te geven of en waar de patiënt gehospitaliseerd is. De SPM segmenten identificeren de stalen waarop de voorschriften uitgevoerd moeten worden. Twee verschillende SPM segmenten van een bericht mogen hetzelfde staal-ID vermelden. Dit is enkel nuttig indien slechts één van deze twee gevolgd wordt door een BLG segment, of indien beiden door BLG segmenten gevolgd worden die echter verschillende contracten aanduiden. Enkel bij de eerste vermelding van een welbepaalde staal-ID moeten de overige velden van het SPM segment waarden hebben. Indien een volgend SPM segment ook nog een waarde voor een bepaald veld bevat, dan moet deze waarde gelijk zijn aan de waarde die het eerste segment voor dat veld bevat.

31

INTERLIS v1.10

De OBX segmenten worden gebruikt voor het melden van resultaten die door het klant AC reeds op één van deze stalen bepaald zijn. Er mogen geen twee of meer OBX segmenten bestaan voor eenzelfde combinatie van staal-ID, testcode (volgens hetzelfde codeersysteem) en OBX-4 Observation Sub ID. De ORC segmenten definiëren één of meerdere nieuwe voorschriften. Veld ORC-1 Order Control moet voor dit bericht steeds de waarde “NW” bevatten. De ORC segmenten mogen verschillende voorschrift-ID’s vermelden: men kan met één bericht verschillende voorschriften aanmaken. Het is echter wel vereist dat in eenzelfde bericht de voorschrijver dezelfde is voor elk ORC segment en ook dat de klinisch bioloog dezelfde is voor elk ORC segment. Bovendien moet ook de naam en de voornaam van beide vermeld worden in het kader van een RIZIV contract. Enkel bij de eerste vermelding van een welbepaalde voorschrift-ID moeten de overige velden van het ORC segment waarden hebben. Indien een volgend ORC segment ook nog een waarde voor een bepaald veld bevat, dan moet deze waarde gelijk zijn aan de waarde die het eerste segment voor dat veld bevat. De OBR segmenten duiden de uit te voeren testen aan. Veld OBR-11 Specimen Action Code moet voor dit bericht steeds de waarde “P” bevatten. Er mogen geen twee of meer OBR segmenten bestaan voor eenzelfde combinatie van staal-ID en testcode (volgens hetzelfde codeersysteem). De BLG segmenten worden gebruikt voor het aanduiden van het contract waaronder de aanvraag valt.

3.6.2.1

Wijzigen van bestaande voorschriften

Wanneer minstens één SPM en/of ORC segment een staal-ID, respectievelijk voorschrift-ID vermeldt dat reeds gebruikt werd in een vorig bericht van deze klant aan deze onderaannemer, wordt ervan uitgegaan dat het huidig bericht het betrokken vorig bericht volledig vervangt. Met andere woorden, het betrokken vorig bericht mag vanaf dan volledig genegeerd worden door beide partijen. Het is echter niet toegestaan in eenzelfde bericht staal-ID’s en/of voorschrift-ID’s te vermelden die reeds vermeld werden in meer dan één vorig verzonden bericht. Voorschriften en stalen mogen niet over meerdere berichten verspreid worden. Ook heeft de onderaannemer het recht een vervanging van een vorig bericht te weigeren, wanneer reeds één of meerdere stalen gereceptioneerd zijn die vermeld werden in dat vorig bericht. Bijvoorbeeld omdat de betrokken stalen reeds na een bepaalde houdbaarheidstermijn werden vernietigd door de onderaanemer.

32

INTERLIS v1.10

3.6.2.2

Bijkomende restricties voor een aanvraag binnen de RIZIV regels

Indien er geen BLG segment aanwezig is of indien minstens één BLG segment verwijst naar een RIZIV Contract, dan moet er ook voldaan zijn aan de hierna volgende vereisten. Het PID segment is vereist. Veld PID-3 Patiënt Identifier List bevat minstens één identificatie. Veld PID-7 Date/Time of Birth is vereist. Veld PID-8 Administrative Sex is vereist. Veld ORC-12 Ordering Provider van het eerste ORC segment is vereist Veld ORC-19 Action By van het eerste ORC segment is vereist

3.6.3 Bevestiging van creatie van een nieuw voorschrift Deze sectie heeft betrekking op hoofdstuk “ORL – Laboratory order response message to a multiple order related to single specimen OML – (event O34)” (HL7 4.4.9). Wanneer een onderaannemer een OML^O33^OML_O33 bericht ontvangt, moet hij dit aan de afzender laten weten onder de vorm van een ORL^O34^ORL_O34 bericht. Er wordt dus geen gebruik gemaakt van het generiek ACK bericht. De structuur van dit bericht wordt voor deze toepassing als volgt vereenvoudigd: MSH MSA [ { ERR } ]

Message header

Dit is dus volledig analoog aan het generiek ACK bericht.

3.6.4 Annulatie door de klant Deze sectie heeft betrekking op hoofdstuk “OML – laboratory order message – (event O21)” (HL7 4.4.6) Wanneer het klant AC een eerder verzonden voorschrift wenst te annuleren, dan stuurt het een OML bericht, event 21, naar het onderaannemer AC. De structuur van het OML^O21^OML_O21 bericht wordt voor deze toepassing als volgt vereenvoudigd: MSH ORC

Message header Common Order

33

INTERLIS v1.10

Veld ORC-1 Order Control bevat voor dit bericht de waarde “CA”. Veld ORC-2 Placer Order Number bevat het voorschrift-ID van een te annuleren voorschrift. De overige velden van het ORC segment worden niet gebruikt. Zolang het onderaannemer AC nog geen enkel van de stalen horend tot het te annuleren voorschrift ontvangen heeft, is het verplicht deze vraag tot annulatie te aanvaarden. Een onderaannemer AC mag de vraag tot annulatie ook aanvaarden wanneer er reeds een staal geannuleerd is. De condities waaronder dit mogelijk is, mogen vrij door elk AC bepaald worden. Wanneer de vraag tot annulatie door een onderaannemer AC geaccepteerd werd, dan mag er geen enkel resultaat m.b.t. dit voorschrift naar het klant AC gestuurd worden. Er mag ook geen enkele aanrekening gebeuren, aan geen enkele direct of indirect betrokken partij. Opmerking: een voorschrift kan door een klant AC enkel in zijn geheel geannuleerd worden.

3.6.5 Bevestiging van annulatie door de klant. Deze sectie heeft betrekking op hoofdstuk “ORL – general laboratory order response message to any OML – (event O22)” (hoofdstuk HL7 4.4.7). Wanneer een onderaannemer een OML^O21^OML_O21 bericht ontvangt, moet hij dit aan de afzender laten weten onder de vorm van een ORL^O22^ORL_O22 bericht. Er wordt dus geen gebruik gemaakt van het generiek ACK bericht. De structuur van dit bericht wordt voor deze toepassing als volgt vereenvoudigd: MSH MSA [ { ERR } ]

Message header

Dit is dus volledig analoog aan het generiek ACK bericht.

3.6.6 Melding van recepties, resultaten, annulaties en aanverwanten Deze sectie heeft betrekking op hoofdstuk “OUL – Unsolicited Specimen Oriented Observation Message – (Event R22)” (HL7 7.3.7). Een onderaannemer AC stuurt een OUL bericht, event 22, wanneer een van volgende gebeurtenissen optreedt: Een staal komt niet binnen de redelijke termijn toe, of Een staal wordt gereceptioneerd, of

34

INTERLIS v1.10

Een staal wordt bij receptie afgekeurd, of De aanvraag voor een test wordt geannuleerd, of Een resultaat wordt gefinaliseerd, of Een eerder gefinaliseerd resultaat wordt gewist of gecorrigeerd, of Er wordt beslist een bijkomende test uit te voeren op een staal (in functie van eerder bekomen resultaten) De structuur van het OUL^R22^OUL_R22 bericht wordt voor deze toepassing als volgt vereenvoudigd: MSH [NTE] { SPM [ { OBX } ] [{ OBR [{ OBX [ { NTE } ] }] }] }

3.6.6.1

Message header Notes and Comments -- Specimen begin Specimen information Observation Result (for Specimen) -- Order begin Observation order -- Result begin Observation result (for Order) Notes and comments -- Result end -- Order end -- Specimen end

SPM segmenten

De SPM segmenten duiden de stalen aan waarover informatie gemeld wordt. Veld SPM-18 Specimen Received Date/Time bevat het tijdstip waarop het staal binnen het onderaannemer AC als gereceptioneerd geregistreerd werd. Voor stalen die nog niet geregistreerd zijn, zal dit veld leeg zijn. Deze situatie ontstaat bijvoorbeeld wanneer een eerder OML^O33^OML_O33 bericht meerdere stalen beschrijft, maar waarvan in het onderaanemer AC slechts enkele daarvan zijn toegekomen en geregistreerd. Voor geregistreerde stalen heeft dit veld binnen dit bericht steeds een waarde, behalve wanneer veld SPM-21 de waarde “EX” (Expired) heeft. Indien veld SPM-21 Specimen Reject Reason een waarde heeft, dan moet dit door het klant AC geïnterpreteerd worden als een annulatie van alle testen die op dat staal aangevraagd waren. In dat geval mag het SPM segment niet gevolgd worden door OBR segmenten.

3.6.6.2

OBX segmenten (for Specimen)

Via deze OBX segmenten kan extra informatie gerapporteerd worden horende bij een specimen. De betekenis van de gerapporteerde informatie hangt af van de LOINC code in het OBX segment. We reserveren de volgende LOINC code voor het rapporteren van

35

INTERLIS v1.10

staal commentaar, die gebruikt kan worden als extra informatie voor het betrokken klant LIS: 8251-1 "Service comment 01" Op termijn kunnen meerdere LOINC codes gereserveerd worden voor het rapporteren van andere soorten specimen gerelateerde informatie.

3.6.6.3

OBR segmenten

De OBR segmenten geven de toestand weer van de testen die op de stalen gevraagd zijn. Veld OBR-11 Specimen Action Code mag voor dit bericht enkel de waarde “G”, “O” of “P” bevatten. Een OBR segment met waarde “G” voor veld OBR-11 kan door een onderaannemer AC verstuurd worden om aan zijn klant aan te geven dat een bijkomende test zal uitgevoerd worden, maar dat er nog geen resultaat is voor deze test. Een OBR segment met een waarde voor veld OBR-36 Scheduled Date/Time kan door een onderaannemer AC verstuurd worden om aan zijn klant te melden wanneer het resultaat van de aangeduide test verwacht mag worden. Een OBR segment dat niet gevolgd wordt door minstens één OBX segment is enkel toegelaten indien veld OBR-11 Specimen Action Code de waarde “G” heeft, of indien veld OBR-36 Scheduled Date/Time een waarde heeft.

3.6.6.4

OBX segmenten (for Order)

Deze OBX segmenten bevatten de resultaten, annulaties en bijaanvragen. Indien veld OBX-11 Observation Result Status de waarde “X” heeft, dan duidt dit segment op een annulatie van een test. In dat geval mag dit OBX segment gevolgd worden door maximaal één NTE segment dat de reden van de annulatie beschrijft. Indien veld OBX-11 Observation Result Status een waarde verschillend van “X” heeft, dan duidt dit segment op een resultaat van een test. Mogelijke NTE segmenten die volgen dienen geïnterpreteerd te worden als niet gestructureerde commentaren bij een resultaat.

3.6.6.5

Stalen niet gereceptioneerd

Elk onderaannemer AC spreekt met zijn klanten een zekere redelijke termijn af waarbinnen stalen moeten toekomen in het AC. Deze termijn begint te lopen van het moment waarop het elektronisch voorschrift ontvangen wordt (dus zeker niet vanaf de waarde van veld SPM-17 Specimen Collection Date/Time, want dat tijdstip kan veel vroeger zijn).

36

INTERLIS v1.10

Zodra deze termijn verstreken is, mag het onderaannemer LIS een niet ontvangen bericht sturen naar de klant. Dit gebeurt onder de vorm van een bericht met een SPM segment dat naar dit staal verwijst en dat de waarde “EX” heeft voor veld SPM21 Specimen Reject Reason De onderaannemer beslist autonoom op exact welk tijdstip dit gebeurt.. Zolang deze termijn niet verstreken is, is het aan het onderaannemer LIS verboden om stalen met code “EX” te annuleren. Een “niet-ontvangen-bericht” kan overruled worden door het versturen van een volgend bericht met een SPM segment dat verwijst naar hetzelfde staal en dat geen of een andere waarde bevat voor veld SPM-21. Wanneer er een “niet-ontvangen-bericht” verstuurd is, mag het onderaannemer LIS geen berichten meer sturen met OBX segmenten die betrekking hebben op hetzelfde staal. Er mag ook geen enkele aanrekening gebeuren, aan geen enkele direct of indirect betrokken partij.

3.6.6.6

Stalen gereceptioneerd

Zodra een staal gereceptioneerd is, moet het onderaannemer LIS binnen een redelijke termijn een receptie bericht versturen. Dit gebeurt onder de vorm van een bericht met een SPM segment dat naar dit staal verwijst en waarvoor veld SPM-18 Specimen Received Date/Time een waarde heeft. Deze specificatie doet geen uitspraak over de duur van deze redelijke termijn. Een onderaannemer AC kan hierover met elke klant afzonderlijk afspraken maken. Het NTE segment volgend op het MSH segment kan optioneel gebruikt worden om commentaar in verband met de staalreceptie te vermelden. De structuur, betekenis en vereistheid van deze commentaar is LIS-specifiek en valt buiten het domein van deze specificatie. Zolang een staal nog niet gereceptioneerd is, mag een onderaannemer LIS geen receptie bericht sturen voor dat staal. Een receptie bericht kan overruled worden door het versturen van een volgend bericht met een SPM segment dat verwijst naar hetzelfde staal en dat geen of een andere waarde bevat voor veld SPM-18. Zolang er geen receptie gemeld is van een staal, mag een onderaannemer LIS geen berichten sturen met OBX segmenten die betrekking hebben op dit staal.

3.6.6.7

Stalen geannuleerd bij ontvangst

Wanneer bij receptie geoordeeld wordt dat een staal niet geschikt is om de gevraagde testen op uit te voeren, en deze beoordeling wordt in het onderaannemer LIS geregistreerd, moet dit LIS binnen een redelijke termijn een staal annulatie

37

INTERLIS v1.10

bericht versturen. Dit gebeurt onder de vorm van een bericht met een SPM segment dat naar dit staal verwijst en waarvoor veld SPM-21 Specimen Reject Reason een waarde heeft verschillend van “EX”. Een staal annulatie bericht mag volgen op een gewoon receptie bericht. Een dergelijke sequentie wordt verwerkt als een gewone overrule van het receptie bericht. Een staal annulatie bericht mag echter ook verstuurd worden zonder dat er een receptie bericht aan voorafging. In dat geval moeten zowel veld SPM-18 als veld SPM-21 ingevuld zijn. Net als bij de staalreceptie kan het NTE segment volgend op het MSH segment optioneel gebruikt worden om commentaar in verband met de staalreceptie en/of staalannulatie te vermelden. Een staal annulatie bericht kan overruled worden door het versturen van een volgend bericht met een SPM segment dat verwijst naar hetzelfde staal en dat geen of een andere waarde bevat voor veld SPM-18 en/of SPM-21. Een staal annulatie bericht mag niet meer verstuurd worden wanneer er reeds berichten verstuurd werden met OBX segmenten die betrekking hebben op dat staal. Wanneer er een annulatie gemeld is van een staal, mag het onderaannemer LIS geen berichten meer sturen met OBX segmenten (for Order) die betrekking hebben op dit staal. Er mag ook geen enkele aanrekening gebeuren, aan geen enkele direct of indirect betrokken partij.

3.6.6.8

Het verwachte tijdstip van rapporteren

Voor een gereceptioneerd staal mag een onderaannemer LIS melden wat het verwachte tijdstip van rapporteren is voor elke individuele te rapporteren test. Dit gebeurt onder de vorm van een bericht met één of meerdere OBR segmenten die naar de te rapporteren testen verwijzen en waarvan veld OBR-36 Scheduled Date/Time een waarde heeft. Het is niet toegelaten een verwacht tijdstip van rapporteren te melden voor een aanvraag die reeds geannuleerd werd of waarvoor er reeds een resultaat gemeld werd.

3.6.6.9

Annuleren van individuele testen

Wanneer het onderaannemer AC beslist om een gevraagde test niet uit te voeren, dan moet deze informatie binnen een redelijke termijn aan de klant gerapporteerd worden. Dit gebeurt onder de vorm van een bericht met een OBX segment (for Order) waarvan veld OBX-11 Observation Result Status de waarde “X” heeft. Dit segment moet gevolgd worden door een NTE segment dat een omschrijving van de reden van de annulatie bevat en waarvan de eerste herhaling van het NTE-3 Comment veld gelijk is aan "Annulatie reden".

38

INTERLIS v1.10

Hierna is de betrokken aanvraag afgesloten. Een test annulatie bericht kan overruled worden door het versturen van een volgend bericht met een OBX segment (for Order) dat verwijst naar dezelfde test en dat een andere waarde heeft voor veld OBX-11 of dat gevolgd wordt door een NTE segment met een andere omschrijving van de reden van de annulatie. Voor een geannuleerde test mag er geen enkele aanrekening gebeuren, aan geen enkele direct of indirect betrokken partij.

3.6.6.10

Resultaten

Wanneer een onderaannemer AC een resultaat voor een gevraagde test gefinaliseerd heeft, dan moet deze informatie binnen een redelijke termijn aan de klant gerapporteerd worden. Dit gebeurt onder de vorm van een bericht met een OBX segment (for Order) waarvan veld OBX-11 Observation Result Status de waarde “F” of “C” heeft. Indien het een openstaande aanvraag betreft, of indien de aanvraag nog niet bestond, moet veld OBX-11 de waarde “F” hebben, anders de waarde “C”. Wanneer een LIS voor de eerste keer een resultaat ontvangt met de waarde “C”, moet dit geïnterpreteerd worden als een resultaat met waarde “F”. Dit mag in elk geval niet leiden tot een fout in de verwerking. Hierna is de betrokken aanvraag afgesloten. Een resultaat bericht kan overruled worden door het versturen van een volgend bericht met een OBX segment (for Order) dat verwijst naar dezelfde test en dat de waarde “C”, “D” of “X” heeft voor veld OBX-11.

3.6.6.11

Bijaanvragen

Wanneer het onderaannemer AC beslist om een bijkomende test uit te voeren, dan kan deze informatie aan de klant gerapporteerd worden. Dit gebeurt onder de vorm van een bericht met een OBR segment waarvan veld OBR-11 Specimen Action Code de waarde “G” bevat. Het melden van een bijaanvraag is niet verplicht. Een onderaannemer AC mag een resultaat rapporteren voor een test die niet door de klant gevraagd is, en die ook niet als bijgevraagd gemeld werd. Het melden van een bijaanvraag wordt wel aangeraden, vooral indien het resultaat van de bijgevraagde test niet onmiddellijk beschikbaar zal zijn. In een dergelijk geval is het eveneens aangeraden om aan veld OBR-36 Scheduled Date/Time een zinvolle waarde te geven. Een bijaanvraag bericht kan niet overruled worden. Een bijaanvraag bericht kan wel geannuleerd worden, en natuurlijk kunnen er resultaten voor gerapporteerd worden.

39

INTERLIS v1.10

3.6.6.12

Wissen van resultaten en (bij)aanvragen

Een onderaannemer AC kan aan de klant melden dat een eerder gerapporteerd resultaat of annulatie moet gewist worden. Dit gebeurt onder de vorm van een bericht met een OBX segment (for Order) waarvan veld OBX-11 Observation Result Status de waarde “D” heeft. Na het wissen van een resultaat of annulatie, is de betrokken aanvraag weer open.

3.6.7 Voorbeelden 3.6.7.1

OML^O33^OML_O33

Voorbeeld van een compleet OML^O33^OML_O33 bericht met een aanvraag voor meerdere voorschriften op verschillende stalen. Dit bericht is opgenomen in een batch. BHS|^~\&|ZZZ|TEST|AAA|LAG|||||BATCH-ID-0001 MSH|^~\&|ZZZ|TEST|AAA|LAG|20071206151300||OML^O33^OML_O33|MESSAGE-ID0001|P|2.5 NTE|1||Dit is een testvoorbeeld~Geen klinische info beschikbaar PID|||123456 789 10^^^INSZ~PATIENT-ID0001^^^ZZZ||Testpatiënt^Klantlabo||19690601|M|||Teststraat 123A^Extra testlijn^Leuven^^3000^België PV1||I|^^^7-10322-09-000^^C^^^^^RIZIV IN1|1|Plan-b^Dit is plan B|COMPANY1^^^CID~COMPANY2^^^CID SPM|1|SPECIMEN-ID-0001||^bloed||^Geen additieven||||||||plasma|||200712011509 OBX|1|ST|12468-5^Aminozuren protocol (plasma)^LN|1|Test resultaat|^^ISO+|||||X OBX|2|SN|721-1^Hemoglobine (plasma)^LN|1|=^5.5^.^10.0|m3.g^^ISO+|<=10||||F ORC|NW|VOORSCHRIFT-ID-0001||||||||||9-88888-77666^Rednose^Rudolf^^^^^^RIZIV|||||||12345678911^Gaskar^Mada^^^^^^RIZIV OBR|1|VOORSCHRIFT-ID-0001||99949-9^ACTH 4u - ACTH dagprofiel^LN|||||||P ORC|NW|VOORSCHRIFT-ID-0002||||||||||9-88888-77666^Rednose^Rudolf^^^^^^RIZIV|||||||12345678911^Gaskar^Mada^^^^^^RIZIV OBR|2|VOORSCHRIFT-ID-0002||5970-9^Plasminogeen^LN|||||||P SPM|2|SPECIMEN-ID-0002||^urinedebiet||||||||||steriele buis - staal uit 24u urinecollectie|||200712011509 ORC|NW|VOORSCHRIFT-ID-0003||||||||||9-88888-77666^Rednose^Rudolf^^^^^^RIZIV|||||||12345678911^Gaskar^Mada^^^^^^RIZIV OBR|3|VOORSCHRIFT-ID-0003||24447-5^Magnesium (urinedebiet) berekend^LN|||||||P BTS|1

3.6.7.2

ORL^O34^ORL_O34

Voorbeeld van een positieve ontvangstbevestiging van het bericht onder 3.6.7.1. Dit bericht is opgenomen in een batch.

40

INTERLIS v1.10

BHS|^~\&|AAA|LAG|ZZZ|TEST|||||BATCH-ID-0003 MSH|^~\&|AAA|LAG|ZZZ|TEST|20071211111100||ORL^O34^ORL_O34|MESSAGE-ID0003|P|2.5 MSA|AA|MESSAGE-ID-0001 BTS|1

3.6.7.3

OML^O21^OML_O21

Voorbeeld van een OML^O21^OML_O21 bericht met het verzoek een volledig voorschrift te annuleren. Dit bericht is opgenomen in een batch. BHS|^~\&|ZZZ|TEST|AAA|LAG|||||BATCH-ID-0002 MSH|^~\&|ZZZ|TEST|AAA|LAG|20071211084900||OML^O21^OML_O21|MESSAGE-ID0002|P|2.5 ORC|CA|VOORSCHRIFT-ID-0003 BTS|1

3.6.7.4

ORL^O22^ORL_O22

Voorbeeld van een negatieve ontvangstbevestiging van het bericht onder 3.6.7.3 met een error segment. Dit bericht is opgenomen in een batch. BHS|^~\&|AAA|LAG|ZZZ|TEST|||||BATCH-ID-0004 MSH|^~\&|AAA|LAG|ZZZ|TEST|20071211120700||ORL^O22^ORL_O22|MESSAGE-ID0004|P|2.5 MSA|AR|MESSAGE-ID-0002 ERR||ORC^^2|207|E|^Het voorschrift met ID VOORSCHRIFT-ID-0003 kan niet geannuleerd worden aangezien hiervoor reeds één of meerdere stalen ontvangen zijn BTS|1

3.6.7.5

OUL^R22^OUL_R22

Voorbeeld 1: Voorbeeld van een HL7 bericht na de receptie van de specimen van een bepaald LIS om het verwacht tijdstip van rapporteren te melden voor alle aanvragen op alle ontvangen specimen binnen een bepaald INTERLIS order. Het eerste specimen werd geannuleerd met QS (Quantity not sufficient). Dit bericht is opgenomen in een batch. BHS|^~\&|AAA|LAG|ZZZ|TEST|||||BATCH-ID-0005 MSH|^~\&|AAA|LAG|ZZZ|TEST|20071211125500||OUL^R22^OUL_R22|MESSAGE-ID0005|P|2.5 SPM|1|SPECIMEN-ID-0001||^Plasma||^Geen||||||||Plasma (heparine) / zonder gel|||20071001000000|20071005000000|||QS^^HL70490 SPM|2|SPECIMEN-ID-0002||^Urine||^Geen||||||||Steriele buis|||20071001000000|20071005000000 OBR|1|VOORSCHRIFT-ID-0001||2350-7^Glucose (urinestaal)^LN|||||||O|||||||||||||||||||||||||20071011000000 BTS|1

Voorbeeld 2: Voorbeeld van een HL7 bericht binnen dezelfde context als het eerste voorbeeld, maar nu met rapportering van een enkelvoudig resultaat voor de aanvraag op het tweede specimen. Dit bericht is opgenomen in een batch.

41

INTERLIS v1.10

BHS|^~\&|AAA|LAG|ZZZ|TEST|||||BATCH-ID-0005 MSH|^~\&|AAA|LAG|ZZZ|TEST|20071211125500||OUL^R22^OUL_R22|MESSAGE-ID0005|P|2.5 SPM|1|SPECIMEN-ID-0001||^Plasma||^Geen||||||||Plasma (heparine) / zonder gel|||20071001000000|20071005000000|||QS^^HL70490 SPM|2|SPECIMEN-ID-0002||^Urine||^Geen||||||||Steriele buis|||20071001000000|20071005000000 OBR|1|VOORSCHRIFT-ID-0001||2350-7^Glucose (urinestaal)^LN|||||||O OBX|1|SN|2350-7^Glucose (urinestaal)^LN|1|=^0.1^.^1000.0|m3.g^^ISO+|<=0.2||||F BTS|1

Voorbeeld 3: Voorbeeld van een HL7 bericht met rapportering van de resultaten voor alle aanvragen op twee verschillende specimen. De eerste aanvraag op het eerste specimen is geannuleerd. Dit bericht is opgenomen in een batch. BHS|^~\&|AAA|LAG|ZZZ|TEST|||||BATCH-ID-0005 MSH|^~\&|AAA|LAG|ZZZ|TEST|20071211125500||OUL^R22^OUL_R22|MESSAGE-ID0005|P|2.5 SPM|1|SPECIMEN-ID-0001||^Plasma||^Geen||||||||Plasma (heparine) / zonder gel|||20071001000000|20071005000000 OBR|1|VOORSCHRIFT-ID-0001||12468-5^Aminozuren protocol (plasma)^LN|||||||O OBX|1|ST|12468-5^Aminozuren protocol (plasma)^LN|1||^^ISO+|||||X OBR|2|VOORSCHRIFT-ID-0002||721-1^Hemoglobine (plasma)^LN|||||||O OBX|2|SN|721-1^Hemoglobine (plasma)^LN|1|=^5.5^.^10.0|m3.g^^ISO+|<=10||||F SPM|2|SPECIMEN-ID-0002||^Urine||^Geen||||||||Steriele buis|||20071001000000|20071005000000 OBR|3|VOORSCHRIFT-ID-0003||2350-7^Glucose (urinestaal)^LN|||||||O OBX|3|SN|2350-7^Glucose (urinestaal)^LN|1|=^0.1^.^1000.0|m3.g^^ISO+|<=0.2||||F BTS|1

3.6.7.6

ACK^R22^ACK

Voorbeeld van een positieve ontvangstbevestiging van een bericht onder 6.7.5. Dit bericht is opgenomen in een batch. BHS|^~\&|ZZZ|TEST|AAA|LAG|||||BATCH-ID-0006 MSH|^~\&|ZZZ|TEST|AAA|LAG|20071211131700||ACK^R22^ACK|MESSAGE-ID0006|P|2.5 MSA|AA|MESSAGE-ID-0005 BTS|1

42