etellimuse spetsikatsioon

Transcription

1 etellimuse spetsikatsioon Vahur Vaiksaar 26. september a. Sisukord 1 Sissejuhatus 3 2 Mudel Süsteemid, organisatsioonid Tellimuse mudel Tellimus Tellimuse päis Leping Juhtum Tellitud analüüs Proovinõu Vastus Interpretatsioonivahemikud Analüüsikirjeldus Sisendparameeter Statiiv Olem Mikrobioloogia Ülesandepüstitus Telliv süsteem -> teenust osutav süsteem Uue tellimuse tekitamine Juurde tellimine Proovinõude lisamine Sisendparameetri lisamine Sisendparameetri tühistamine Tellitud analüüsi ümber sidumine Proovinõu andmete täiendamine Tellitud analüüsi tellimise katkestamine Märkuse lisamine Proovinõu vöötkoodi üle kleepimine Teenust osutav süsteem -> telliv süsteem Proovinõu registreerimine

2 3.2.2 Proovinõu lisamine Proovinõu hävitamine Proovinõu vöötkoodi üle kleepimine Tellimuse muut(u)mine Tellitud analüüside ümber sidumine Teenust osutav süsteem -> vastuseid kuulav süsteem Kinnitatud vastuste edastamine Kinnitatud vastuse muutmine Mittelõplike vastuste edastamine HL7 v3 kasutamine Üldist Süsteemid ja tellimused HL7s Tellimuse mudeli kitsendused Kasutatavad interaktsioonid Identikaatorid ja koodid II andmetüüp CD andmetüüp OIDide kasutamine Üldised põhimõtted identikaatorite ja koodide edastamisel Sõnumi identikaatorid Seadmete identikaatorid Isikute identikaatorid Asutuste identikaatorid Tellimuse päiste identikaatorid Tellitud analüüside identikaatorid Proovinõude identikaatorid Juhtumi identikaatorid Lepingute identitseerimine Analüüsikirjelduste kodeerimine Materjali tüüpide kodeerimine Proovinõu tüüpide kodeerimine Vastusekoodistike kodeerimine Tellimuse struktuuri esitamise põhimõtted Tellimuse objektide olekud Tellimuse päise olek Proovinõu olek Tellitud analüüsi olek Sisendparameetri olek Transpordikihi esitamine sõnumites Sõnumi päis Süsteemi kirjeldus Andmete esitamine sõnumis MCCI_IN000002UV Näide positiivsest kinnitussõnumist Näide negatiivsest kinnitussõnumist Tellimis- ja vastussõnumi esitamine

3 4.7.1 Näide tellimissõnumi kahest välimisest kihist Näide vastussõnumi kahest välimisest kihist Osaluse esitamine Märkuse esitamine Lepingu esitamine Materjali ja füüsilise proovinõu andmete esitamine Juhtumi andmete esitamine Patsiendi andmete esitamine Vastuse esitamine Andmete esitamine sõnumis POLB_IN Tellimuse päise esitamine Proovinõu esitamine Tellitud analüüsi esitamine Sisendparameetri esitamine Andmete esitamine sõnumis POLB_IN Tellimuse päise esitamine Proovinõu esitamine Tellitud analüüsi esitamine Interpretatsioonivahemiku esitamine Sissejuhatus See dokument kirjeldab viise, kuidas laboriteenust pakkuvate ja tellivate asutuste infosüsteemid vahetavad teiste omasugustega andmeid konkreetsete laboriteenuste osutamiste kohta (etellimus). Dokumendi sihtrühm on etellimust kasutavate infosüsteemide loomisega tegelevad isikud (analüütikud, arhitektid, programmeerijad). Dokumendi läbitöötanud inimesed peaksid olema teadlikud etellimuse protokolli kitsendustest võrreldes nt HL7 v3 sõnumitega ning peaksid suutma luua süsteeme, mis suudavad omavahel laboriteenuste kohta käivaid andmeid vahetada. 2 Mudel See peatükk kirjeldab üldisi mõisteid, millede abil andmevahetuse sisust ja tähendusest rääkida. ETellimust rakendavate süsteemide sisemine mudel võib siintoodust erineda (nt toetada vaid ühte proovinõud tellimuse kohta jms). 2.1 Süsteemid, organisatsioonid (Labori)teenuseid vajavad ning pakuvad organisatsioonid ja nende allüksused (edaspidi mõlemad kokku: asutused). Andmevahetuses esindavad asutusi süsteemid. Üks süsteem võib esindada mitut asutust, iga andmevahetusvõimelist asutust esindab vähemalt üks süsteem. 3

4 Süsteemile sõnumi saatmiseks kasutatakse mingit transpordimeetodit. Mõni süsteem võib vahendada teisi süsteeme, sellisel juhul saadetakse sõnum tegelikule sihtsüsteemile kasutades vahendava süsteemi transpordiparameetreid (kuidas ja milliseid täpselt on konkreetse süsteemi teostuse asjaolud ja pole etellimuse teema). See, kas ja millised asutusi esindavad süsteemid andmevahetuses osalevad, pannakse paika vastavate teenuseosutamise lepingutega. 2.2 Tellimuse mudel Tellimus Tellimus on etellimuse mõttes komplekt tellitud analüüsidest, proovinõudest materjaliga ja administratiivsest infost. Igal süsteemil on tellimuste osas oma arvepidamine, etellimuse abil vahetatakse andmeid ühist huvi pakkuvate tellimuste (või nende alamhulkade) kohta. Tellimuse administratiivne info on järgmine: üks patsient (minimaalselt mingi suvaline identikaator, mille järgi teenusepakkuja võib sisemiselt otsida sama patsiendi varasemaid vastuseid), üks tellija (telliv isik, nt arst), üks telliv asutus, üks maksja (maksev asutus), üks teenusepakkuja (teenust osutav asutus), leping ning juhtum Tellimuse päis ETellimuse spetsikatsioon toetab tellimuse mudelit, kus ühe tellimuse raames võib tellida analüüse rohkem kui ühest proovinõust (materjalist). Sellise lähenemise korral läheb vaja tellimust identitseerivat objekti, mis seoks administratiivse info, tellitud analüüsid ja proovinõud üheks terviklikuks tellimuseks. Nimetame seda grupeerivat objekti tellimuse päiseks Leping Leping seob telliva asutuse, teenusepakkuja, maksja ning tellijad (isikud, kes selle lepingu nimel tellida võivad). Tellimuse päisega seotud telliv asutus võib olla lepingus kirjas oleva alamüksus. Selle spetsikatsiooni kontekstis on leping abstraktne nähtus, millega pannakse paika kõik sellised asjad, mida tellija ja teenusepakkuja etellimise sõnumitega ei saa kokku leppida (arveldusaspektid, suhtluses kasutatavad koodistikud jm vajalik) Juhtum Juhtum (Encounter) on etellimuse kontekstis täiendav, telliva asutuse väljastatud identikaator, mis grupeerib tellimuse päiseid. Juhtumiga on tavaliselt seotud patsient (tavaliselt sama, kes tellimusegagi), raviarst ja raviasutus (vastavalt telliv isik ja telliv asutus), viimased kaks võivad aja jooksul muutuda. Teenust pakkuv asutus võib kasutada juhtumi-andmeid tellimuse päise atribuutide täitmiseks, kuid ei vaja seda millekski muuks. Samas peab teenust pakkuv 4

5 infosüsteem selle teadmise saadetavates sõnumites kaasa panema, kui see olemas on. See, mida telliv süsteem juhtumi all tegelikult mõtleb pole tegelikult teenusepakkuja asi erinevates raviorganisatsioonides võib juhtum olla külastus, haiguslugu või mingi muu grupeeriv asi. Milline täpselt pole teenusepakkumise kontekstis enamasti oluline. (Seega võib termini juhtum kasutamine olla mõne telliva süsteemi jaoks eksitav. ETellimuse mudeli mõttes on see siiski hea lühike ja teiste tähendusteta sõna). Kui teenusepakkumiseks on vajalik nt varasemate vastuste uurimine vms patsiendi ajaloo kasutamine, siis leitakse vajalikud andmed patsiendi ja mitte juhtumi järgi Tellitud analüüs Tellitud analüüs on identitseeritud seos tellimuse päise ja analüüsikirjelduse (teenusekirjeldus, analüüsi tüüp, teenuse tüüp) vahel. Tellitud analüüsiga võivad olla seotud (sama tellimuse päise) proovinõu (või mitu) ja/või vastus. Tellitud analüüsil on tellija (vt ) ning tellimise aeg. Erijuhul on tellijaks teenust osutav süsteem või selle kasutaja teenust pakkuv asutus võib tellimuse täitmise käigus lisada tellimusele täiendavaid analüüse. Tellitud analüüsil on prioriteet routine (tavaline) või stat (cito, eelisjärjekorras tegemist vajav). Tellitud analüüs võib olla komponendiks ühele või mitmele teisele (grupeerivale) tellitud analüüsile. Omavahel komponentseosega ühendatud tellitud analüüsid peavad olema seotud sama tellimuse päisega. Grupeerivad tellitud analüüsid võivad ka ise olla mõne teise grupi komponentideks. Grupeerivatel tellitud analüüsidel ei ole enamasti vastust, kuid leidub ka juhte, kus vastusega tellitud analüüs grupeerib teisi vastusega tellitud analüüse. Tellitud analüüs võib omada seoseid teistele (sama tellimuse päise) tellitud analüüsidele, millede vastustest selle analüüsi vastust on plaanis (formaalselt või mitteformaalselt) tuletada. Tõenäoliselt pole tellimise kontekstis arvutuslike seoste kommunikeerimine vajalik. Võimalik, et teenust osutav süsteem saab tellimuse vastuvõtmisel alati kõik vajalikud arvutuslikud seosed ise tekitada ja hiljem need vajadusel (koos vastustega) tellijale tagasi kommunikeerida. Seda küsimust tuleb vaadata seotult sisendparameetritega (vt ). Leiduvad tellitud analüüsid, mis võivad olla seotud rohkem kui ühe proovinõuga - nt on iga grupeeriv tellitud analüüs on seotud kõigi endas sisalduvate tellitud analüüsidega seotud proovinõudega. Tellitud analüüse, mis ei ole lõppolekusse jõudnud, võib ühe tellimuse päisega seotud proovinõude vahel ümber siduda Proovinõu Proovinõu on identitseeritav komplekt füüsilisest proovinõust ning selles sisalduvast materjalist. Proovinõuga on seotud tellitud analüüsid, mis mõõdeti konkreetselt sellest proovinõust ning need, mida kavatsetakse sellest veel mõõta. Proovinõu kohta võib teada olla materjali võtmise aeg ja võtja (vt ) ning 5

6 teenust pakkuvas süsteemis registreerimise aeg ning registreerija (vt ). Tütarproovinõu on selline proovinõu, mille tekitab teenust pakkuv asutus tehnoloogilistel põhjustel töö käigus. Tütarproovinõu ja emanõu on seotud sama tellimusega. Tütarproovinõu kohta on enamasti teada emanõu ning tütardamise aeg ning koht. Proovinõu võib paikneda kuni ühes statiivis. ETellimuse kontekstis on tütarproovinõud teenusepakkuja siseasi ja ei ole praktilist vajadust, et ülejäänud osapooled neist midagi teaks. Seetõttu vahetatakse etellimuse kontekstis andmeid ainult esmaste proovinõude (mille materjal on saadud vahetult patsiendilt) kohta. Sõnumivahetuses esitab teenust pakkuv süsteem tütarproovinõudest tehtud ja tellitud analüüsid seotult vastava(te) esmas(t)e proovinõu(de)ga. Proovinõu on seotud täpselt ühe tellimuse päisega ja seda teise tellimuse päise külge ümber või täiendavalt siduda ei saa. Ühe proovinõuga saab olla seotud ülimalt üks mingile konkreetsele analüüsikirjeldusele vastav tellitud analüüs, mis ei ole lõppolekus. Perspektiivis võiks etellimus toetada ühest proovinõust analüüside tellimist mitme sama patsiendiga seotud tellimuse raames. See kataks olukorra, kus teenusepakkujal on uue analüüsi tegemiseks proovimaterjal (nt arhiveeritult) olemas, aga mingil põhjusel ei ole vana tellimuse täiendamine võimalik. Sellega on paraku seotud hulk komplikatsioone, mis vajavad täiendavalt analüüsimist (nt patsiendi identiteedi või meditsiiniliste parameetrite muutumise käsitlemine). Teine potentsiaalselt kasulik funktsionaalsus oleks mitme identse administratiivse infoga tellimuse päise asendamine ühega. See võimaldaks kogemata või ettenägematusest tehtud kahte erinevat tellimust ühena käsitleda kui see peaks funktsionaalselt vajalik olema Vastus Vastus on komplekt mingit tüüpi väärtusest (või selle puudumisest), ühikust ning interpretatsioonidest (sh referentsvahemikest) ning umbkaudne kvalitatiivne interpretatsioonikood. Vastusel võib olla allikas (vt ) (süsteem või inimene, kes vastuse sai), kinnitaja (vt ), sisestaja (vt ) (kui sisestaja puudub, on selleks allikas ise). Vastusega on seotud vastuse saamise ja kinnitamise aeg. Vastus on alati seotud tellitud analüüsiga. Tellitud analüüsil, millel teenusekirjelduse järgi ei peagi vastust olema (grupeerivad analüüsid), on tühi vastus (ilma väärtuse, ühiku ja interpretatsioonideta), millel võib olla allikas ja kinnitaja (kes vastavalt väidavad ja kinnitavad, et teenus on osutatud). Vastus võib viidata ühele või mitmele teisele vastusele, millest see vastus (formaalselt või mitteformaalselt) tuletatud on. Omavahel tuletamisseosega ühendatud vastused peavad olema seotud sama tellimuse päisega. Vastus võib grupeerida teisi vastuseid. Vastus võib viidata tühistatud vastusele, mida see vastus asendab. 6

7 2.2.8 Interpretatsioonivahemikud Interpretatsioonivahemik on paar (vahemik) väärtustest või üksik väärtus (ülemine või alumine piir), kus väärtus(t)e andmetüüp on sama, mis vastusel, mille kohta interpretatsioonivahemik rakendub. Interpretatsioonivahemikul on kood, mis määrab kuidas seda tõlgendada, nt normaalsus, abnormaalsus jms. Referentsvahemikud on sellised interpretatsioonivahemikud, mis väljendavad vastuse normaalsust. Interpretatsioonivahemikuga võib olla seotud üks või mitu tingimust, mille tõttu see vahemik rakendus (nt patsiendi soo, vanuse vm parameetri väärtus on mingis konkreetses vahemikus või omab mingit konkreetset väärtust) Analüüsikirjeldus Analüüsikirjeldus (teenusekirjeldus, teenuse tüüp) on süsteemisisene teadmine mingit tüüpi teenuse osutamise asjaoludest. Sh, kas ja millist materjali vaja on, millised on komponentanalüüsid, arvutuslikud sõltuvused, inerpretatsioonid (sh referentsvahemikud), vastuse tüüp, ühik jne. Igal süsteemil on enamasti omad sisemised analüüsikirjeldused (ning koodid nende tähistamiseks). Andmevahetuses kasutavad süsteemid ühist/jagatud koodistikku, millest mõlemad osapooled aru saavad Sisendparameeter Sisendparameeter on selline tellitud analüüs, mille vastuse annab kaasa tellija (telliv süsteem). Seda kasutatakse juhul, kui mingite arvutuste tegemisel kasutatakse varem mõõdetud suurusi, nt ööpäevase uriini kogus mingite ainete eritamiskiiruse arvutamisel jms. Sisendparameetreid on olemuselt kahesuguseid. Patsiendipõhised ja proovinõu(materjali)põhised. Patsiendipõhine sisendparameeter on nt pikkus, proovinõupõhine nt asjaolu, kas proovimaterjal on võetud püsti või pikali asendis. On oluline ära märkida, et leidub sisendparameetreid, mille vastused kommunikeeritakse praktikas kuidagi eriliselt (või sootuks mitteilmutatult) võrreldes ülejäänud sisendparameetritega. Mõned näited: materjali võtmise aeg, patsiendi sugu ja vanus. Selline lähenemine ei ole regulaarne ning ei võimalda vajadusel väljendada arvutuslikke sõltuvusi. Samuti võib olla probleemiks selliste sisendparameetrite vastuste hilisem muutmine - see peaks läbima ilmutatult kinnitatud vastuste tühistamise protsessi. Mitteilmutatult kommunikeerimise näide: tellija süsteem saadab tellimuse, milles on patsiendi sünniaeg, teenusepakkuja süsteem arvutab patsiendi vanuse iga tellimuses leiduva proovinõu kohta, kus seda vaja on. ETellimuse raames on eelistatud (nii formaalsetes kui ka mitteformaalsetes) arvutuskäikudes kasutatavate sisendparameetrite kommunikeerimine tellitud analüüsi vastusena. Mida lugeda sisendparameetriks ja mida mitte, pole alati väga selgepiiriline. Kui teenusepakkuja esindaja tegeleb ise proovimaterjali võtmisega, siis võib ta sisendparameetrid otse teenusepakkuja süsteemi sisestada. 7

8 Statiiv Statiiv grupeerib (enamasti füüsiliselt) hulga proovinõusid. Statiivil on tüüp. Statiivil võib olla identikaator, proovinõul statiivis võib olla positsioon Olem Olem on isik, asutus või süsteem, kes või mis mõnes tegevuses osales. Olem võib tegutseda mõne konkreetse asutuse nimel. Tegevustes osalevate olemite ring on laiem kui juriidilised ja füüsilised isikud mõnes tegevuses (nt. analüüsi vastuse saamine, vahel ka kinnitamine) osalevad ainult andmevahetuse-võimelised süsteemid. Sisuliselt on olem hulk identikaatoreid, mis võivad määrata organisatsiooni ning selle allüksuse, mille nimel olem tegutseb, süsteemi, mille seest vastav teadmine tuli ning isiku, kes/mis tegutses. Milliste identikaatorite abil olemit identitseeritakse, on kommunikatsiooniparameeter Mikrobioloogia Mikrobioloogia tellimus ja vastus mahub kirjeldatud tellimuse mudeli sisse. Proovimaterjalist tellitakse mikrobioloogiline uuring - külvid ja/või mikroskoopia (labor võib mikroskoopia tööprotsessist sõltuvalt lisaks külvile ka omaalgatuslikult teha). Kuna preparaadi vastus selgub enamasti kiiremini kui külvi vastus ning kuna külvi vastus saadakse enamasti mitmes etapis, võib teenusepakkuja väljastada mikrobioloogia vastuse mitmes etapis. Tellitud mikroskoopiline uuring on grupeeriv kompleksanalüüs, mille komponentanalüüsideks on erinevad mikroskoopilised leiud. Konkreetse leiu komponentanalüüsiks võib olla leiu nähtav kogus. Tellitud külv on grupeeriv kompleksanalüüs, mille komponentideks on mikroobianalüüsid analüüsid, mille vastuseks on lõpuks täpsustatud mikroob või mõnda eriolukorda väljendav spetsiaalne kood. Esialgu viitab mikroobianalüüsi vastus täpsustamata mikroobigrupile, töö käigus vastus täpsustub. Külvile tekib töö käigus alati vähemalt üks komponent asjaolu, et külvi pealt midagi ei tuvastatud, väljendatakse spetsiaalse mikroobianalüüsi vastusena. Mikroobianalüüsil võivad olla komponentanalüüsideks mikroobi nähtav kogus ning 0..* tundlikkuse analüüsi. Tundlikkuse analüüsidel on lisaks vastusele ka interpretatsioon (tundlik, mõõdukas, resistentne). 3 Ülesandepüstitus See peatükk annab ülevaate etellimuse funktsionaalsest skoobist. Peatükk sisaldab loetelu etellimuse erinevate osapoolte vahelisest andmevahetusvajadusest. Peatükk keskendub küsimustele mida? ja miks? ning ei ürita vastata küsimusele kuidas?. Kõikide toodud punktide juures võib teate vastuvõtja vastavast tegevusest keelduda, kui muudatused on kuidagi vastuolus teate vastuvõtja süsteemi ärireeglitega. 8

9 3.1 Telliv süsteem -> teenust osutav süsteem Uue tellimuse tekitamine Telliv süsteem peab saama kirjeldada teenust osutavale süsteemile uue tellimuse: tellimusega seotud proovinõu(d), tellitud analüüsi(d), sisendparameetrid ja tellimuse administratiivinfo Juurde tellimine Telliv süsteem peab saama lisada olemasolevale tellimusele tellitud analüüse Proovinõude lisamine Telliv süsteem peab saama lisada olemasolevale tellimusele proovinõusid Sisendparameetri lisamine Telliv süsteem peab saama lisada olemasolevale tellimusele sisendparameetreid Sisendparameetri tühistamine Telliv süsteem peab saama sisendparameetri (vastuse) tühistatuks märkida (nt sest parameetri väärtus polnud korrektne) Tellitud analüüsi ümber sidumine Telliv süsteem peab saama tellitud analüüsi ümber siduda teise proovinõu külge Proovinõu andmete täiendamine Telliv süsteem peab saama täiendada proovinõu andmeid - registreerida materjali võtmise aja, märkida proovinõu hävitatuks Tellitud analüüsi tellimise katkestamine Telliv süsteem peab saama loobuda juba tellitud analüüsi tellimisest, teisisõnu peab saama tühistada vastava tellitud analüüsi tellitud olemise fakti (seda ei tohi segi ajada vastuse tühistamisega tellija ei saa teenusepakkuja tehtud tellitud analüüsi vastust tühistada) Märkuse lisamine Telliv süsteem peab saama lisada olemasoleva tellimuse erinevatele objektidele (tellimusele, tellimuse proovinõudele ja tellitud analüüsidele) märkuseid Proovinõu vöötkoodi üle kleepimine Telliv süsteem peab saama teatada füüsilise proovinõu vöötkoodi üle kleepimisest. 9

10 3.2 Teenust osutav süsteem -> telliv süsteem Proovinõu registreerimine Teenust osutav süsteem peab saama teatada füüsilise proovinõu kohalolu registreerimisest teenust osutavas süsteemis. Teine osapool (telliv süsteem) võib vastata tellimusega. Kui proovinõu vastuvõtmisel tuvastati probleem, siis peaks teenust osutava süsteemi kasutaja selle süsteemis vastavalt registreerima (proovinõu hävitatuks märkima, lisama vastava kommentaari jms). Kui tellimuses leidub tegemata tellitud analüüse, mida registreeritud proovinõust teha saab, võib teenust osutav süsteem need registreeritud proovinõuga siduda (vt 3.2.6). Normaaljuhul jõuab tellimust tekitav sõnum kohale enne proovinõud. Samas leidub olukordi, kus see vahel või alati on teistpidi. Selle probleemi lahendamine pole 1. prioriteet Proovinõu lisamine Teenust osutav süsteem peab saama teatada füüsilise proovinõu lisamisest tellimusele. Kui tellimuses leidub tegemata tellitud analüüse, mida lisatud proovinõust teha saab, võib teenust osutav süsteem need lisatud proovinõuga siduda (vt 3.2.6). Sõnumivahetuse kontekstis käsitleme ainult selliste proovinõude lisamisi, mille materjal on saadud vahetult patsiendilt. Teenusepakkuja sisemine tööprotsess võib ette näha ka tütarproovinõude moodustamist, aga neid sõnumivahetuses ei kajastata. Poovinõu lisamise kasutusjuht on vajalik peamiselt olukorras, kus teenusepakkuja ise tegeleb proovimaterjali kogumisega Proovinõu hävitamine Teenust osutav süsteem peab saama teatada füüsilise proovinõu hävitamisest (kasutuskõlbmatuks muut(u)misest). Kui hävitatud proovinõuga oli seotud tegemata tellitud analüüse, siis võib teenust osutav süsteem need sobivalt ümber siduda (vt 3.2.6) Proovinõu vöötkoodi üle kleepimine Teenust osutav süsteem peab saama teatada füüsilise proovinõu vöötkoodi üle kleepimisest Tellimuse muut(u)mine Teenust osutav süsteem peab saama teatada tellimusega seotud tellitud analüüside hulga muutumisest (analüüsi juurde tellimine, tellitud analüüsi tellimuse tühistamine). 10

11 3.2.6 Tellitud analüüside ümber sidumine Teenust osutav süsteem peab saama teatada tellitud analüüside ümber sidumisest teise proovinõu külge. 3.3 Teenust osutav süsteem -> vastuseid kuulav süsteem Kinnitatud vastuste edastamine Teenust osutav süsteem peab saama edastada tellimusega seotud tellitud analüüside olekud ning kinnitatud analüüside vastused (kui need olemas on) Kinnitatud vastuse muutmine Inimlike ja tehnoloogiliste vigade tõttu saab tekkida olukord, kus teenusepakkuja saadab tellijale kinnitatud vastuse, mille kohta hiljem selgub, et see oli vale. Vale võib olla kas vastus ise või ka tellitud-olemise fakt (analüüs lisati ekslikult, tegelikult tellija seda ei soovinud). Samuti võib vale olla tellija saadetud sisendparameeter. Asutus, kes vigased andmed saatis, peab saama edastada parandatud andmed või vigase suuruse tühistamise soovi. NB! Alati peab vigaste andmete edastamisega andmevahetuses kaasnema mõlema asutuse nimel tegutsevate inimeste omavaheline suhtlus, et minimeerida valeandmete kasutamise halbu tagajärgi! Ühendlaboris käib selle kohta juhend PKLÜL-12. Mujal tuleb arvatavasti omad kohalikud reeglid kehtestada. Eriline kinnitatud vastuse muutumise liik on patsiendi muutmine. Patsiendi muutumine tähendab, et isik, kelle kohta vastused käivad tuvastati valesti (tundmatu täpsustamine siia alla ei käi). Peab olema võimalik väljendada, et eelnevalt kehtinud patsiendiga juba seotud kinnitatud vastuseid ei tohi arvestada. Natuke vähem oluline on tellija muutumine sellisel juhul on käivad küll tulemused tellimuse päisega seotud patsiendi kohta, kuid tellija-info oli vale. Kui tellija vahetamine põhjustab ka vastuseid saava süsteemi muutumise, siis peab olema võimalik korraldada see, et eelnevalt sõnumi saanud süsteem saaks teada, et teenus arveldatakse mujal Mittelõplike vastuste edastamine Teenust osutav süsteem peab saama edastada tellimusega seotud mittelõplikud vastused. Teenusepakkuja võib aktiivses olekus vastuseid anda välja tellija tööprotsessi efektiivsemaks muutmiseks. Aktiivses olekus tellitud analüüsi vastused ei ole lõplikud ja võivad edaspidi muutuda. 11

12 4 HL7 v3 kasutamine 4.1 Üldist ETellimus kasutab esimeses versioonis HL7 v3 POLB domeeni sõnumeid, konkreetsemalt 2006 septembri-hääletuse versioonist (V ). Pärast seda versiooni on toimunud (toimumas) ümberkorraldused, mis puudutavad kasutatavate interaktsioonide hulka ja täpset sisu, kuid need ümberkorraldused pole veel lõppenud ning viidatud versioon on seni ainus, mis sisaldab kooskõlalist ja (peaaegu) piisavat komplekti sõnumeid. Kõigi eelduste kohaselt jääb andmevahetuse põhimõtteline mudel samaks, täpsustuvad sõnumitüübid (interaktsioonide identikaatorid) ning detailides võibolla ka andmekoosseis. HL7 kirjeldab muuhulgas nõudeid transpordile kõigi selliste nõuete arvestamine ning neile tehtavad täiendused on etellimuse kirjelduse skoobist väljas. ETellimus kirjeldab konkreetsete sõnumite kasutuse ja tähenduse peatükis 3 püstitatud probleemide lahendamiseks. ETellimust kasutavad organisatsioonid võivad transpordi osas leppida kokku kasutuse, mis erineb HL7 dokumentides kirjeldatust. ETellimuse sõnumid on versioneeritud. See dokument kirjeldab protokolli versioon Süsteemid ja tellimused HL7s HL7 mudelis omab ja haldab iga süsteem oma tellimust. Sõnumivahetuse eesmärk ei ole sünkroniseerida n identset koopiat tellimusest vaid pigem teatavad osapooled vastastikku oma tellimuse muutumisest, mis võib (aga ei pea) põhjustada ka teise osapoole tellimuse muutumise. Samuti tähendab see, et igal süsteemil ei pea olema teadmist kogu tellimusest kui näiteks osa tellimust tellitakse välisest laborist, siis piisab, kui välisele laborile saadetakse vaid toda huvitav osa tellimusest. HL7 mõttes on tellimusele kolm vaadet, sõltuvalt süsteemi rollist tellimise protsessis võib sama tellimust väljendada erinevate vaadete kaudu. Iga vaade deneerib HL7 sõnumitüübi, mille kitsendused/täpsustused konkreetse vaate edastamiseks mõeldud sõnumid on. Vaated on järgmised. Request - Telliva süsteemi nägemus sellest, mida ta saada tahab. Promise - Teenust pakkuva süsteemi nägemus sellest, mida ta teha kavatseb. Event - Teenust pakkuva süsteemi ülevaade tellimuse käigus tehtust (vastus). HL7 loetleb erinevad süsteemi rollid (application role), mida suhtluse osapooled (süsteemid) esitada võivad. Süsteemi roll määrab komplekti sõnumeid, mida süsteem peab töödelda suutma ning komplekti sõnumeid, mida ta saata võib. Süsteem võib esitada ühte või mitut rolli. ETellimuse kontekstis on olulised järgmised süsteemi rollid. 12

13 Order Placer - seda rolli esitav süsteem esitab tellimusi (Order Receiver'itele). Order placer haldab sisemiselt oma nägemust tellimustest (request'e). Order Placer vastutab tellimuste olekumuudatuste kommunikeerimise eest (Order Receiver 'itele). Order Receiver - seda rolli esitav süsteem kuulab (Order Placer'i poolt) saadetavaid tellimuste (request'ide) olekumuudatusi ja oskab neid vastu võtta. Süsteem võib, aga ei pea vastu võetud tellimusest enda nägemust salvestama. Order Fulller - seda rolli esitav (labori)süsteem võtab vastu tellimusi ja saadab välja vastuseid. Order Fulller haldab sisemiselt oma nägemust tellimustest (promise'itest) ja vastustest (event'idest) ning vastutab enda tellimuste ja vastustega seotud olekumuudatuste kommunikeerimise eest (vastavalt Promise Receiver 'itele ja Result Receiver 'itele). Promise Receiver - seda rolli esitav süsteem kuulab (Order Fulller'ite) poolt saadetavaid tellimuste (promise'ite) olekumuudatusi ja oskab neid vastu võtta. Seda rolli esitav süsteem võib, aga ei pea vastu võetud tellimusest enda nägemust salvestama. Result Receiver - seda rolli esitav süsteem oskab (Order Fulller'ite) poolt saadetavaid vastuste (event'ide) olekumuudatusi vastu võtta. Seda rolli esitav süsteem võib, aga ei pea vastu vastu võetud vastusest enda nägemust salvestama. Tavaliselt on tellival süsteemil rollid Order Placer, Promise Receiver, Result Receiver ning teenusepakkujal Order Receiver ja Order Fulller. Samas HL7 ega etellimuse spetsikatsioon ei dikteeri, kuidas need rollid konkreetses lahenduses erinevate süsteemide vahel jagunema peavad Tellimuse mudeli kitsendused ETellimuse spetsikatsioon kasutab kirjeldatud tellimuse mudeli lihtsustust, kus teenust osutav süsteem esitab kommunikatsioonis ainult ühte vaadet tellimusele, mis kajastab nii teenust osutava süsteemi nägemust tellimusest ( Promise) ja vastustest (Event). Sellest tulenevalt on etellimuse spetsikatsiooni kontekstis olulised rollid Order Placer, Order Receiver, Order Fulller ja Result Receiver Kasutatavad interaktsioonid HL7 POLB domeeni sõnumid (interaktsioonid) on jagatud kahte suuremasse gruppi selle põhjal, kas (sõnumit) vastuvõtval süsteemil on või ei ole kohustust vastata sõnumile rakenduse taseme sõnumiga. ETellimuse spetsikatsioon kasutab sõnumeid, kus vastuvõtval süsteem ei ole kohustust vastata rakenduse taseme sõnumiga. Nii tellimuse kui ka vastuse kommunikeerimiseks on valitud sõnumite grupis palju erinevaid sõnumeid. HL7 kirjeldab iga põhjustava sündmuse ( trigger 13

14 event) kohta eraldi sõnumi. Kõik tellimise sõnumid baseeruvad samal sõnumitüübil ja kõik vastussõnumid samal sõnumitüübil. Konkreetne sõnum on tuletatud vastavast sõnumitüübist ja sisaldab kitsendusi keskse acti ja selle alamactide olekute kohta. Olekukitsendused on esitatud loogilisel, mitte tehnilisel tasemel, XML-skeemad kitsendusi ei sisalda. Kuna erinevate sõnumite tüüp on sama, siis praktikas koostab sõnumeid saatev süsteem ükskõik millise põhjustava sündmuse korral sõnumi samal viisil ning sõnumit vastu võttev süsteem töötleb sõnumit sõltumata sõnumi saatmist põhjustanud sündmusest samal viisil (põhjustava sündmuse toimumise saab sõnumist välja lugeda). Seetõttu piirdub etellimuse spetsikatsioon ühe konkreetse sõnumi kasutamisega kõigi põhjustavate sündmuste korral ning ei sätesta olekukitsendusi acti ja selle alam-actide kohta. Olekukitsendusi valideerivad rakendused sõnumeid vastu võttes. Tellimuse ja selle edaspidiste muudatuste edastamiseks kasutab telliv süsteem sõnumit Order Fulllment Request w/o RR (POLB_IN211100) ning vastuse ja selle edaspidiste muudatuste edastamiseks kasutab teenust osutav süsteem sõnumit Result in Progress w/o RR (POLB_IN224100). Igale konkreetsele tellimis- ja vastussõnumile peab teine osapool vastama sõnumiga Accept Ack (MCCI_IN000002UV01 ), mis kinnitab sõnumi edukat töötlemist või teavitab sõnumi tagasi lükkamisest koos tekkinud vigadega. HL7 POLB domeen kirjeldab ka vastuste pärimisega seotud sõnumid, neid etellimuse spetsikatsioon ei kasuta. 4.2 Identikaatorid ja koodid etellimuse sõnumites on vaja kasutada mitmeid identikaatoreid ja koode. See peatükk esitab etellimuse üldised identikaatorite ja koodide kasutamise põhimõtted ning toob välja ja analüüsib konkreetseid koodide ja identikaatorite kasutuskohti sõnumites. Identikaatoreid esitatakse HL7 sõnumites II (Instance Identier ) andmetüübiga, koode CD (Concept Descriptor ) andmetüübiga II andmetüüp II on identikaator, mis identitseerib unikaalselt mingit asja või objekti. II andmetüüp esitatakse XML-elemendina, millel on etellimuse seisukohalt olulised atribuudid root ja extension. On kaks skeemi, kuidas II andmetüüpi kasutada. Atribuudi root väärtus identitseerib globaalselt unikaalselt mingi asja või objekti ning extension on määramata. Atribuudi root väärtus identitseerib globaalselt unikaalselt mingi asja või objekti nimeruumi (identikaatori tüübi, koodistiku) ning extension määrab selle asja või objekti identikaatori selles nimeruumis. Objekti või asja identitseerib globaalselt unikaalselt root ja extension väärtuste paar. ETellimuse kontekstis kasutatakse läbivalt viimasena toodud skeemi. Globaalselt unikaalne nimeruum esitatakse sobiva OIDina (vt 4.2.3). 14

15 4.2.2 CD andmetüüp CD on viide mingile mõistele, mis on mingis kodeerimissüsteemis kirjeldatud. CD andmetüüp esitatakse XML-elemendina, millel on etellimuse seisukohalt olulised atribuudid code, codesystem, codesystemname ja displayname ning 0..* alamelementi translation, mis võimaldavad esitada mõistet alternatiivsetes koodistikes. Alamelementidel translation võivad olla samuti ülaltoodud neli atribuuti. code - Kood kodeerimissüsteemis codesystem. codesystem - Globaalselt unikaalse kodeerimissüsteemi nimi, esitatakse etellimuse kontekstis sobiva OIDina (vt 4.2.3). codesystemname - Mittekohustuslik atribuut kodeerimissüsteemi inimloetava nime esitamiseks. displayname - Mittekohustuslik atribuut koodi inimloetava nime esitamiseks OIDide kasutamine OID (Object Identier ) on identikaator objekti globaalseks identitseerimiseks (vt Identikaatorite haldamine põhineb puustruktuuril: leidub globaalne OIDide puu, kus igale tipule on omistatud mingi arv ning konkreetse tipu OID saadakse juurtipust kuni selle tipuni arve sümboliga '.' ühendades. OIDide puust jagatakse konkreetsetele asutustele välja alamharusid. Iga asutus, kellel on mingi alamharu, saab sellest harust anda välja erinevatele objektidele globaalselt unikaalseid identikaatoreid või delegeerida mingi alamharu haldamine omakorda mõnele teisele asutusele. HL7 organisatsioonil on oma OIDide haru, millest HL7 on standardi arendamiseks OIDe välja antud. Eesti kontekstis on E-tervise Sihtasutus kirjeldanud mitmeid OIDe. ETellimuse raames vaatame iga konkreetset kohta eraldi kas ja mis tingimustel saab kasutada olemasolevaid OIDe ja millal peavad omavahel suhtlevad osapooled enda OIDiharust spetsiaalselt OIDe eraldama Üldised põhimõtted identikaatorite ja koodide edastamisel Sõnumit saatev süsteem peab konkreetse identitseeritava või kodeeritava objekti kohta sõnumis kaasa panema kõik identikaatorid/koodi alternatiivsed esitused, millest vastuvõttev süsteem võib kokkuleppeliselt huvitatud olla. Sõnumit saatev süsteem võib sõnumisse lisada ka selliseid identikaatoreid ja koodide alternatiivseid esitusi, millest vastuvõttev süsteem midagi ei tea. Vastuvõttev süsteem võib talle tundmatuid sõnumis esinevaid koode ja identikaatoried ignoreerida. 15

16 4.2.5 Sõnumi identikaatorid Andmevahetuses on sõnumid identitseeritud. Igal sõnumil on parajasti üks identikaator, mille annab välja sõnumit koostav süsteem. Iga etellimuse raames sõnumeid vahetav süsteem peab seega omama unikaalset OIDi enda poolt väljastatavate sõnumite identikaatorite nimeruumi jaoks. Kindlasti on oluline garanteerida ka see, et sama tarkvara toote-, test- ja arendussüsteemidel oleks erinevad OIDid. Liidestuvad osapooled peavad kasutatavad OIDid omavahel kokku leppima Seadmete identikaatorid Iga etellimuse kontekstis vahetatava sõnumi päises tuleb identitseerida sihtsüsteemi ja sõnumit saatvat süsteemi. Vastussõnumis võivad meditsiiniseadmed või (allhankijana) teise organisatsiooni teenust osutavad süsteemid esineda teostaja ja kinnitaja osalustes. Lihtsamal juhul pole meditsiinitoimingute süsteem-tüüpi osalusi vaja tellijale eksponeerida tellijat huvitab peamiselt vastus ja selle meditsiiniline tõlgendus. Kui see siiski vajalikuks osutub, peavad osapooled vastavate süsteemide kodeerimises kokku leppima. Ka siin on oluline garanteerida, et sama tarkvara toote-, test- ja arendussüsteemid oleks eristatud Isikute identikaatorid Tellimis- ja vastussõnumis on vaja kommunikeerida patsiendi isiku ja erinevates tegevustes (analüüsi teostaja, kinnitaja, materjali koguja, proovinõu laboris registreerija, märkuse autor, märkuse sisestaja, tellimuse tellija, tellitud analüüsi tellija) osalevate mõlema suhtluse osapoole töötajate isikute identikaatoreid. E-tervise sihtasutus on välja andnud kaks siinkohal olulist OIDi. EV isikukood EV tervishoiutöötaja kood Patsientide identitseerimisel saab kasutada neist esimest, ülejäänud osaluste juures mõlemat. Need kaks ei pruugi ära katta kõiki vajadusi ning suhtlevad osapooled võivad kokku leppida ka muude identikaatoritüüpide kasutuses. Näiteks omavahel suhtlevad süsteemid, mis paiknevad organisatsiooniliselt lähestikku ning kasutavad ühist isikute registrit, võivad kasutada selle registri sisemisi identikaatoreid. Samuti näiteks võivad tellivad süsteemid kasutada kokkuleppeliselt ühekordseid identikaatoreid patsientide isikute osas, kelle identiteeti nad teenust osutavale süsteemile näidata ei soovi Asutuste identikaatorid Tellimis- ja vastussõnumis on vaja kommunikeerida erinevates tegevustes (analüüsi teostaja, kinnitaja, materjali koguja, proovinõu laboris registreerija, märkuse autor, märkuse sisestaja, tellimuse tellija, tellitud analüüsi tellija) osalevate isikute ja seadmete poolt esindatavaid asutusi. E-tervise sihtasutus on välja andnud siinkohal olulise OIDi. 16

17 Asutuse äriregistrikood Täiendavalt saavad suhtlevad osapooled kasutada teistest nimeruumidest identi- kaatoreid, mille osas peab igal konkreetsel juhul eraldi kokku leppima. Näiteks teatud juhtudel on teenust osutavale süsteemile oluline teada tellija asutuse sisestruktuuri (nt osakonna täpsusega) Tellimuse päiste identikaatorid Tellival ja teenust osutaval süsteemil on enda nägemus tellimustest ning seega enda sisemine tellimuse päiste üle arvepidamine. Seega peab igal suhtluses osaleval süsteemil olema OID enda sisemise tellimuse päisete nimeruumi globaalseks identitseerimiseks. Oluline on jällegi märkida, et see nimeruum peab sama tarkvara toodang-, test- ja arenduskeskkondades olema erinev. Suhtluse osapooled peavad vastavad OIDid kokku leppima Tellitud analüüside identikaatorid Tellitud analüüside korral rakendub tellimuse päistega analoogne arutluskäik suhtluse osapooled peavad vastavad OIDid kokku leppima. etellimuse raames on eelistatud skeem, kus sisendparameetrite ja tellitud analüüside nimeruum on sama, kuid kaks osapoolt võivad ka teisiti kokku leppida Proovinõude identikaatorid Proovinõud identitseerib sellele kleebitud vöötkood. Vöötkoodid on kõik ühest nimeruumist (ja seetõttu peavad omavahel suhtlevad osapooled vöötkoodide kasutusskeemi ja väljaandmist koordineerima). Kuna kõigi vöötkoodide nimeruum on sama, siis esitatakse vöötkood paarina, kus root=barcode ja extension väärtuseks on konkreetne vöötkood. Võibolla tuleks vöötkoodide nimeruumile ikkagi korrektne OID välja anda? Juhtumi identikaatorid Juhtumi identikaatorite nimeruumi OIDide osas lepivad osapooled vajadusel kokku Lepingute identitseerimine Lepingute identikaatorite nimeruumi OIDide osas lepivad osapooled vajadusel kokku. 17

18 Analüüsikirjelduste kodeerimine Analüüsikirjeldusi on vaja nii tellimis- kui ka vastussõnumis kodeerida tellitud analüüsi juures, tellimissõnumis sisendparameetrite juures. Samuti on vaja analüüsikirjeldusi kodeerida tellitud analüüsi vastuste interpretatsiooni rakenduvuse tingimustes. ETellimus kasutab ELMÜ LOINC projekti tulemit. Tulem on koodistik (edaspidi ELMÜ koodistik), mis on saadud üldisest LOINC koodistikust Eesti kontekstis relevantse alamosa eraldamise teel. ETellimuse raames on eelistatud skeem, kus kaks suhtlevat osapoolt kasutavad analüüsikirjelduse kohta sõnumis alati vähemalt ELMÜ koodistiku koodi kui selline leidub. Täiendavalt võib sõnumis esitada ka analüüsikirjelduse alternatiivseid esitusi teistes kodeeringutes. Praktikas ei kata ELMÜ koodistik kõiki Eesti kontekstis kasutatavaid analüüsikirjeldusi. Tellimisprotsessis pakuvad teenuseosutajad sageli klientidele välja teenuseosutaja-spetsiilisi tellimispaneele (grupeerivaid kompleksanalüüse). Kuna tellimispaneele saab koostada väga mitmel moel, need on erinevate teenusepakkujate korral erinevad ning LOINC organisatsioonil on tellimispaneelide kodeerimine alles algusjärgus, siis peavad konkreetsed suhtlevad osapooled leppima täiendavalt kokku kasutatava tellimispaneelide koodistiku, millest mõlemad osapooled aru saavad. ELMÜ LOINC koodistiku jaoks annab OIDi välja E-Tervise Sihtasutus. Kui vastav OID on välja antud, siis tuleb see siia dokumenti kirja panna Materjali tüüpide kodeerimine Materjali tüüpe on vaja kodeerida nii tellimis- kui ka vastussõnumis. ETellimus kasutab ELMÜ LOINC projekti kõrvaltulemit materjalide tüüpide koodistikku. Vastava OIDi annab välja E-Tervise Sihtasutus. Kui vastav OID on välja antud, tuleb see siia dokumenti kirja panna Proovinõu tüüpide kodeerimine Proovinõu tüüpe on vaja kodeerida nii tellimis- kui ka vastussõnumis. ETellimus kasutab ELMÜ LOINC projekti kõrvaltulemit proovinõu tüüpide koodistikku. Vastava OIDi annab välja E-Tervise Sihtasutus. Kui vastav OID on välja antud, tuleb see siia dokumenti kirja panna Vastusekoodistike kodeerimine Mikroobide kodeerimiseks on ETellimuse raames eelistatud Snomedi koodistiku kasutamine (OID ). Paljude kodeeritud vastustega analüüside korral on praktikas kasutusel koodistik [POS, NEG] või [POS, NEG, MÄÄRAMATU]. Nende kahe koodistiku jaoks annab E-Tervise Sihtasutus välja OIDid ning ELMÜ LOINCi projekti analüüsikoodistikus on vastavate analüüside juures viide kasutatavale koodistikule. 18

19 Kui vastavad OIDid on välja antud, tuleb need siia dokumenti kirja panna. Ülejäänud vastusekoodistike osas peavad suhtluse osapooled omavahel vajadusel kokku leppima. Kui vastuseid kuulaval süsteemil ei ole vaja kodeeritud vastuseid masintöödelda, võib ta neid tekstiliselt käsitleda. 4.3 Tellimuse struktuuri esitamise põhimõtted See peatükk loetleb üldised põhimõtted, millest tuleb lähtuda tellimise- ja vastussõnumites tellimuse andmete esitamisel. Juhul kui tellimuse päis edastatakse, esitatakse proovinõud vahetult tellimuse päise komponentideks olevate objektidena. Kui tellimuse päist ei edastata, saab saata vaid ühe proovinõu ning see peab olema sõnumi juurmine objekt. Proovinõud võib ilma tellimuse päiseta edastada ainult siis, kui tellimuse päises sisalduv teadmine on teise ospoole jaoks üheselt ja mitteilmutatult tuvastatav. Sellise sõnumi lubatavus on kommunikatsiooniparameeter. Esialgu on vist mõtet eelistada skeemi, kus tühi (ilma identikaatorite, patsiendiviidete jms andmeteta) tellimuse päis on alati olemas, ilma tellimuse päiseta sõnumitel oleks otstarve juhul, kui mõni laboriseade ise HL7 v3 sõnumeid koostaks (aga ka sellisel juhul saab rakendada tõlkimist). Tellitud analüüs, mis ei ole ühtegi teise tellitud analüüsi komponent (grupeeriva kompleksanalüüsi komponent) ega viidatav mõne teise analüüsi poolt arvutusliku sõltuvusena, esitatakse tellimuse päise vahetu komponendina. Tellitud analüüs võib olla mõne teise tellitud analüüsi komponent kahes erinevas tähenduses: gupeeriva kompleksanalüüsi komponent ja arvutuslik komponent. Kui tellitud analüüs on mõne teise tellitud analüüsi komponent (ükskõik kummas ülaltoodud tähenduses), siis esitatakse tellitud analüüs vastava vanem-analüüsi komponendina. Kui tellitud analüüs on mitme teise tellitud analüüsi komponent, siis esitatakse tellitud analüüs kõikides vajalikes kohtades. Korduste esitamine on valitud HL7 versioonis probleem ja vajab täpsustamist (tühi tellitud analüüs, mille identikaatorid on samad ja mille kood mingi spetsiaalne?). Esialgu väljendame kordusi ilmutatult kopeerimistena (st. tellitud analüüs ja selle alluvad esinevadki mitu korda). Tellitud analüüsi seotust proovinõu(de)ga väljendatakse tellitud analüüsi vastava atribuudi kaudu (välja arvatud sisendparameetrite kommunikeerimine tellimissõnumis). 19

20 Tellitud analüüs saab olla sõnumi juurelemendiks vaid siis, kui tellimuse päises sisalduv teadmine on teise poole jaoks üheselt ja mitteilmutatult tuvastatav. Ka sellise sõnumi lubatavus on kommunikatsiooniparameeter. Kõik muudatused, mida edastatakse peavad olema ilmutatult välja toodud. Ainus viis teatada mingi objekti või seose muutumisest on saata sõnum, kus selle uus olek väljendatud on, kui mingit alamhulka tellimusest ei edastatud, siis ei peaks vastavad osad tellimusest sõnumi töötlemisel muutuma. Samas võivad ühesed seosed muutuda juhul, kui sõnumis on eelmist seost asendav seos. Kui kahe objekti vahel on seos ning mõlemad objektid on sõnumis esitatud, siis peab olema sõnumis esitatud ka nendevaheline seos. (kui varem on selline seos olnud, siis tähendab seose puudumine uues sõnumis, et vastav seos on katkestatud). HL7 võimaldab sõnumiga edastada ka tellimuse alamhulga oleku (nt konkreetne tellitud analüüs või analüüsigrupp, mingi proovinõuga seotud analüüsid, jne). Kooskõlalisuse kontrollimise huvides on etellimuse raames eelistatud kogu tellimuse päise (tellimuse päise ja kõigi sellega seotud proovinõude ning tellitud analüüside) saatmine ühes sõnumis. 4.4 Tellimuse objektide olekud Tellimuse päise olek 'active' - Tellimuse päis on saatva süsteemi nägemuses aktiivne, st sellega on seotud tegemata tellitud analüüse. 'completed' - Tellimuse päis ei sisalda saatva süsteemi nägemuses tegemata tellitud analüüse. Kuna etellimus kasutab mudelit, kus tellimuse päisega võib olla seotud rohkem kui üks proovinõu, siis võib tellimuse päise olek kahe ülaltoodud oleku vahel muutuda. Teenusepakkujal võivad olla ärireeglid, mis loevad tellimuse teatud juhtudel lõpetatuks ja ei luba enam tellimuse raames täiendavalt juurde tellida, kuid võib esineda ka vastupidist käitumist lõppolekus tellimusele saab juurde tellida ja tellimuse päise oleku uuesti aktiivseks muuta Proovinõu olek 'active' - Proovinõu on kasutuskõlblik. 'completed' - Proovinõu on hävitatud. 20

21 4.4.3 Tellitud analüüsi olek 'active' - Tellitud. Tellitud analüüs on selles olekus kuni hetkeni, kuni see satub mõnda kolmest lõppolekust (kinnitatud, katkestatud, tühistatud). Tellitud olekus analüüs võib olla teostuse ootel, teostamisel, või omada esialgset, kinnitamata vastust. 'completed' - Kinnitatud. Tellitud analüüs on tehtud ja teenusepakkuja poolt kinnitatud. 'aborted' - Katkestatud. Tellitud analüüsi tellitud olemise fakt on katkestatud. 'nullied' - Eelnevalt kinnitatud olekus tellitud analüüsi vastus on tühistatud Sisendparameetri olek 'completed' - Kinnitatud. Sisendparameeteri väärtus on tellijapoolselt kinnitatud. 'nullied' - Eelnevalt kinnitatud olekus sisendparameetri vastus on tühistatud. 4.5 Transpordikihi esitamine sõnumites See peatükk annab ülevaate etellimise transpordikihi andmete esitusest Sõnumi päis Kõikide etellimuse spetsikatsioonis kasutatavate sõnumite transpordikihi osa esitatakse järgmiselt. Sõnumi juurmine element on kasutatava interaktsiooni nimega (tellimissõnumi korral POLB_IN211100, vastussõnumi korral POLB_IN224100, kinnitussõnumi korral MCCI_IN000002UV01 ). Sõnumi juurmisel elemendil on atribuut ITSVersion="XML_1.0". Sõnumi juurmisel elemendil on atribuut xmlns:xsi =" Sõnumi juurmisel elemendil on atribuut xmlns="urn:hl7-org:v3" Sõnumi juurmisel elemendil on atribuut xsi:schemalocation ="urn:hl7- org:v3 <skeema_asukoht>". ETellimise seisukohalt oluliste XMLskeemade asukohad peavad suhtluse osapooled kokku leppima. Sõnumi juurmisel elemendil on järgmised kohustuslikud alamelemendid. id - sõnumi identikaator. 21

22 creationtime - sõnumi loomise aeg. interactionid - sõnumi interaktsioon. Atribuut root on kseeritult , extension on sõnumi interaktsioon (tellimissõnumi korral POLB_IN211100, vastussõnumi korral POLB_IN224100, kinnitussõnumi korral MCCI_IN000002UV01 ). processingcode - määrab, kas tegu on toodang-, test- või arenduskeskkonnaga. Atribuudi code võimalikud väärtused: P - toodangukeskkond, T - testkeskkond, D - arenduskeskkond. processingmodecode - määrab sõnumi töötlemise re iimi. Atribuudi code väärtus etellimuse kontekstis kseeritult T. acceptackcode - määrab kas (sõnumi) vastuvõtmist kinnitava sõnumi (accept-ack i) saatmine on vajalik või mitte. Atribuudi code väärtus on tellimise ja vastussõnumi korral kseeritult AL, kinnitussõnumi korral NE (sest kinnitussõnumile ei ole vaja kinnitussõnumit saata). receiver - sõnumi sihtsüsteemi andmed. Sihtsüsteemil on kohustuslik atribuut typecode=rcv. Sihtsüsteemil on kohustuslik sihtsüsteemi kirjeldav alamelement (vt 4.5.2). sender - sõnumi saatja süsteemi andmed. Saatja süsteemil on kohustuslik atribuut typecode=snd. Saatja süsteemil on kohustuslik saatja süsteemi kirjeldav alamelement (vt 4.5.2) Süsteemi kirjeldus Süsteemi kirjeldus esitatakse elemendiga device. Süsteemil on kohustuslikud atribuudid classcode=dev ja determinercode=instance. Süsteemil on minimaalselt üks identikaator, alamelement id. 4.6 Andmete esitamine sõnumis MCCI_IN000002UV01 Kinnitussõnum koosneb ainult transpordikihist (vt 4.5), millel on kinnituse kohta alamelement acknowledgement. Elemendil acknowledgement on järgmised alamelemendid. typecode atribuudiga code, mis indikeerib esialgse sõnumi töötlemise edukust/ebaedukust. AA - esialgse sõnumi töötlemine oli edukas. AE - esialgse sõnumi töötlemisel tekkis viga, vea detailid sisalduvad selles kinnitussõnumis. AR - esialgse sõnumi töötlemine ebaõnnestus põhjustel, mis pole seotud esialgse sõnumi formaadi või sisuga. 22