Vastus pöördumisele

Teie 18.10.2023 nr 1.1-12/20893-1 Meie 25.10.2023 nr 1-4/96-1 MihkelMiidla [email protected] Sotsiaalministeerium [email protected] Mary-Liis Moorbach [email protected] Hea koostööpartner, Meil on siiralt kahju, et info Innovaatik OÜ-s toimunud meeskonnavahetuse komplikatsioonidest ei jõudnud õigeaegselt meieni ja seetõttu on meie poolt lepingulisele kontaktisikule väljastatud vajalike arenduste tegemiseks oluline info jäänud tegelikult Teieni jõudmata. Edastame info uuesti ning kinnitame omalt poolt, et oleme valmis arenduste tegemiseks vajalikku testplaani kokku leppima niipea, kui olete selleks valmis. Teie poolt esitatud konkreetsetele küsimustele vastame järgnevalt: a. Millised on Pildipanga poolsed tehnilised detailid HL7 sõnumivahetuse teenuse sisseviimiseks? Detailid on kirjeldatud dokumendis „Pildipank HL7 message requirements v1.11 - 2023.05.31.pdf“, mille edastame Teile. b. Kuidas on korraldatud HL7 sõnumivahetuse arenduste testimine? Pildipank ja Pildipanga partner loovad krüpteeritud andmeedastus lahenduse testsüsteemide vahel. Pildipanga partner esitab testimise kava koos teststsenaariumitega. Pildipank vaatab kava üle ja korrigeerib vajadusel. Vastavalt kokkulepitud kavale alustab Pildipanga partner testsõnumite saatmist ning saab iga saadetud sõnumi kohta kas positiivse vastuse või negatiivse vastuse koos veakirjeldusega. Kui kõik sõnumid on saanud positiivsed vastused, siis viiakse läbi täistestimine koos HL7 sõnumite ja kujutistega. c. Millised on HL7 sõnumivahetuse keskkonnad? Kuidas saab testida? Pildipanga HL7 sõnumivahetuse keskkond on ligipääsetav VPN kanalite kaudu. Pildipanga partneril on võimalus saata testkeskkonda sõnumeid ja saada igale sõnumile vastuseks kas positiivne (ACK) või negatiive teavitus (NACK). Testida saab vastavalt kokkulepitud testplaanile. d. Eeltooduga seonduvalt palun täpsustada, mis on testkeskkonnas: i. Pildipanga serveri IP HL7 sõnumite saatmiseks? IP-d lepitakse kokku pärast testimisplaani koostamist. IP ei ole kättesaadav avalikust Internetist ning juurdepääsu saamiseks on vaja luua krüpteeritud andmeedastuse keskkond. ii. MSH-4 (Sending Facility) väärtus? Peab olema konfigureeritav ja lepitakse kokku testimise plaani kooskõlastamisel. iii. MSH-5 (Receiving Application) väärtus? vt Integratsiooni dokumenti „Pildipank HL7 message requirements v1.11 -2023.05.31.pdf“. iv. MSH-6 (Receiving Facility) väärtus? vt integratsiooni dokumenti „Pildipank HL7 message requirements v1.11 -2023.05.31.pdf“. v. patsiendi andmed (isikukood, eesnimi, perekonnanimi) sõnumite edastamiseks? Pildipank ei määratle, milliseid testandmeid kasutab Partneri testsüsteem, kui andmed vastavad HL7 liidestamise dokumendis „“Pildipank HL7 message requirements v1.11 - 2023.05.31.pdf“ esitatud nõuetele. Konkreetsed edastatavad testandmed lepitakse kokku testimisplaanis. vi. tervishoiutöötaja andmed (THT kood, eesnimi, perekonnanimi) sõnumite edastamiseks? Pildipank ei määratle, milliseid testandmeid kasutab Partneri testsüsteem, kui andmed vastavad HL7 liidestamise dokumendis „Pildipank HL7 message requirements v1.11 - 2023.05.31.pdf“ esitatud nõuetele. Konkreetsed edastatavad testandmed lepitakse kokku testimisplaanis. vii. OBR-34.5 (Code of location where study is/will be conducted, acquisition room) väärtus? Pildipank ei määratle, milliseid testandmeid kasutab Partneri testsüsteem, kui andmed vastavad HL7 liidestamise dokumendis „Pildipank HL7 message requirements v1.11 - 2023.05.31.pdf“ esitatud nõuetele. Konkreetsed edastatavad testandmed lepitakse kokku testimisplaanis. viii. OBR-43.1 (Code of the performing department) väärtus? Pildipank ei määratle, milliseid testandmeid kasutab Partneri testsüsteem, kui andmed vastavad HL7 liidestamise dokumendis „Pildipank HL7 message requirements v1.11 - 2023.05.31.pdf“ esitatud nõuetele. Konkreetsed edastatavad testandmed lepitakse kokku testimisplaanis. e. Kas MSH-4 (Sending Facility) väärtus (institution identifier) on raviasutuse põhine (nt Tallinna Hambapolikliinik) või infosüsteemi põhine (nt Hammas)? See väli määratleb sõnumeid saatva Infosüsteemi. Regionaalhaigla puhul on see näiteks „PER“, samas Läänemaa haigla puhul on see samuti PER kuna nende sõnumivahetust vahendab Regionaalhaigla infosüsteem. Pildipank ei oma infot, kuidas suhestuvad omavahel raviasutuste ja nende kasutatav infosüsteem andmevahetusprotsessis Pildipangaga. f. Millised on HL7 sõnumivahetuse täpsed protsessid? Täpsed protsessid on määratletud rahvusvaheliste standarditega ja Pildipanga liidestusdokumendiga „Pildipank HL7 message requirements v1.11 -2023.05.31.pdf“. i. Seal hulgas, palun seletada protsessi ning koostada näidissõnumid olukorraks, kus hambakliinik on uuringu käigus teinud DICOM formaadis pildi ja soovib seda Pildipanka edastada. Näidissõnumid on leitavad dokumendis „Pildipank HL7 message requirements v1.11 - 2023.05.31.pdf“. Vastavalt standardsele tööprotsessile kasutatakse ADT ja ORM HL7 sõnumeid enne kujutise tegemist, et varustada kujutist registreeriv seade elektroonse töödenimekirjaga vastavalt DICOM Modality Worklist protokollile. Kujutis edastatakse kujutist registreerivast seadmest DICOM Store protokolli abil PACS-i ning seejärel saadab infosüsteem HL7 ORU sõnumi, mis sisaldab kujutise interpretatsiooni. g. Millised on Pildipanga poolsed tehnilised detailid 3D piltide edastamise võimekuse sisseviimiseks? Pildipanga süsteemide poolt vastuvõetavate 3D DICOM objektide detailid on leitavad alljärgnevatest standarditest ja ühilduvusdeklaratsioonidest. Süsteemi nimi Funktsionaalsus Standard Piltide Kujutiste vastuvõtmine DICOM 3.0 arhiveerimise ja kujutist tekitavast https://www.dicomstandard.org kommunikatsioon seadmest (modaliteet) ja i süsteem (PAKS). kujutise Tootja DICOM standardiga ühildumise Toode: Agfa järeltöötlussüsteemist, deklaratsioon „Enterprise Imaging 8.2.x Enterprise seadmele tööde nimekirja – Doc. 001647“ Imaging 8.2 edastamine, järeltöötlussüsteemidele ja https://www.agfahealthcare.com/dico visualiseerimissüsteemidel m-conformance/ e kujutiste edastamine, kujutiste edastamine arhiivi ja kujutiste pärimine arhiivist Infosüsteemidest HL7 uuringutellimuste ja - https://www.hl7.org kirjelduste vastuvõtmine ning sidumine kujutistega Tootja HL7 standardiga ühildumise deklaratsioon „Enterprise Imaging 8.2.0 HL7 Conformance Statement – Doc. 001645“. https://www.agfahealthcare.com/hl7/  Pildipanga poolt tootes realiseeritud sõnumivahetuse kirjeldus „Pildipank HL7 message requirements v1.11 - 2023.05.31.pdf“ Ühtlasi selgitame, et andmevahetussüsteemi vahetuse aluseks on riigihanke nr 224671 „PAKS (piltide arhiveerimise- ja kommunikatsioonisüsteem) ostmine“ tulemused. Lugupidamisega Andrus Paats Juhatuse liige SA Eesti Tervishoiu Pildipank [email protected]  Pildipank HL7 message requirements Version Date Author Comments 1.0 06.10.2022 Willeke Staljanssens Initial version 1.1 29.12.2022 Tarmo Rasmann Added section about connection protocols 1.2 14.02.2023 Tarmo Rasmann Field ORC-21.3 changed to use ORC- 21.10 instead 1.3 16.03.2023 Tarmo Rasmann Added remark about using local time for timestamps 1.4 22.03.2023 Willeke Staljanssens Added support for report deletion and clarification in patient death indicator 1.5 05.04.2023 Willeke Staljanssens Added comment for persons without first or last name 1.6 11.04.2023 Willeke Staljanssens Corrected to use of ‘R’ to ‘M’ in the mandatory column + support for multiple reporting doctors 1.7 12.04.2023 Willeke Staljanssens OBR-4.2 should use short procedure name 1.8 21.04.2023 Willeke Staljanssens Corrected the OBX-5 format for scanned requests 1.9 10.05.2023 Willeke Staljanssens Corrected the OBX-5 format for scanned requests 1.10 23.05.2023 Willeke Staljanssens For report deletion, the report author can be emtpied 1.11 31.05.2023 Willeke Staljanssens Corrected example messages HL7 connection and low level protocol HL7 messages are sent over a TCP/IP connection. Pildipank messaging platform acts as server, customer application acts as client. Specific destination IP address and port will be provided by Pildipank on a case-by-case basis. HL7 connections can be optionally secured by TLS. If TLS is used, Pildipank will provide the necessary CA certificates to be included in the trust store of customer application. All HL7 messages on the TCP/IP connection need to be delimited by HL7 Minimum Lower Layer Protocol (MLLP) start and stop bytes.  Start byte – Vertical Tab, HEX value 0x0B 1 / 11   Stop bytes – File Separator followed by Carriage Return, HEX values 0x1C 0x0D Multiple messages can be sent on the same TCP/IP connection. Keeping idle connections open in the long term is not preferred. Timeout of 60 seconds is recommended for the acknowledgment message. Average processing and reply time should not exceed 1-2 seconds. HL7 acknowledgment messages will be returned on the same connection as the original message was sent. Message encoding should be UTF-8. Message types and events The table below describes which events/actions should trigger what kind of message. Event Message New patient arrives in the ADT A28 or hospital and is registered in the ADT A08 HIS Patient details (name, sex, ADT A08 birthdate) are updated in the HIS Patient dies ADT A08 Patient is merged to another First ADT A08/ADT A28 of the target patient, so that target patient in the HIS. patient is known with correct details. Then, ADT A40 to merge Patient gets new ID. source patient to target. Order/study is created One ORM O01 message per study in the order, with ORC-1 = Study is added to an order NW (and the scheduled date in ORC-27.4) and ORC-5 = SC or empty Order is changed ORM O01 with ORC-1 = XO and possibly changed procedure in OBR-4 Study is validated ORM O01 with ORC-1 = XO and possibly changed procedure in OBR-4 and an OBX-segment with VALIDATED = YES Patient arrives in the One ORM O01 message with ORC-1 = SC and an OBX-segment department/at the acquisition PATIENT_ARRIVED=YES. locations Study is started in the RIS ORM O01 with ORC-1 = SC and ORC-5 = IP Study is completed in the RIS ORM O01 with ORC-1 = SC and ORC-5 = CM Study is cancelled in the ORM O01 with ORC-1 = SC and ORC-5 = CA RIS/Study is deleted in the RIS Study is discontinued in the RIS ORM O01 with ORC-1 = SC and ORC-5 = DC Study is restored in the RIS (set ORM O01 with ORC-1 = SC and ORC-5 = SC back to first status) Preliminary report is created ORU R01 with OBX-11 = P Final report is created ORU R01 with OBX-11 = F Report is cancelled/deleted ORU R01 with OBX-11 = D In the next sections, the message structure and segments for each of these message types will be discussed. Remarks: 2 / 11  - Each incoming message will be checked by a message validator. If the message does not meet the requirements listed in this document, the message will be rejected and a (N)ACK AE reply will be sent. - Fields not mentioned in this document cannot contain any data or they will fail the validation mentioned above. - The words study and procedure are used interchangeably in this document. - All timestamps in messages should be presented in local time. Message structures Segments in [] are optional, segments in {} can be repeated. - ADT A08: MSH – EVN – PID - ADT A28: MSH – EVN – PID - ADT A40: MSH – EVN – PID – MRG - ORM O01: MSH – PID – ORC – OBR – [{OBX}] – [ZDS] o 1 message per study required, several studies can be grouped within one order using the ORC/OBR-3 field. Example: to create 1 order with 3 studies, 3 messages are needed with the same ORC/OBR-3 field. - ORU R01: MSH – PID – {ORC – OBR} – {OBX} o 1 report that covers multiple studies can be sent in 1 message. Example a: 1 order with 3 studies, one report for all studies created: 1 message is needed in with the ORC-OBR segments are repeated for each of the studies and the OBX segment contains the combined report for these studies. Example b: 1 order with 3 studies, one report for each of the studies separately: 3 messages are required: 1 for each study containing the specific report for that study. Example c: 1 order with 3 studies, one report for 2 of the studies, one report for the third study created: 2 messages are required. 1 containing 2 studies and the combined report, and 1 for the third study with its own report. Institution identifier definition Will be issued by Pildipank to each institution. For example: North-Estonia Medical Centre: PER; Tartu University Clinics: TYK Message segments MSH Field Mand./Opt. Max. Description Remark/Example* field length MSH-1 M 1 Field separator symbol | MSH-2 M 4 Encoding characters ^~\& MSH-3 O 180 Sending Application e.g. ESTER 3 / 11  MSH-4 M 180 Sending Facility Institution identifier MSH-5 M 180 Receiving Application EI MSH-6 M 180 Receiving Facility PILDIPANK MSH-7 M 14 Date and time of the message e.g. 20220830105700 in YYYYMMDDHH24MiSS MSH-9.1 M 3 Message type Patient update/merge: ADT Study creation/update: ORM Report: ORU MSH-9.2 M 3 Message event Patient update: A08 Patient merge: A40 Procedure/study creation/update: O01 Report: R01 MSH-10 M 20 Message ID A unique value to identify each message, e.g. TYK123 MSH-12 M 3 HL7 version 2.3, 2.3.1, 2.4 or 2.5 * listed in bold are mandatory values EVN Field Mand./Opt. Max. Description Remark/Example* field length EVN-2 M 14 Record date(time) in YYYYMMDD[HH24Mi[SS]] PID Field Mand./Opt. Max. Description Remark/Example* field length PID- M 64 Patient ID National number, international number 3.1** or temporary code PID- M 3 Patient ID issuer - EST in case of national number (in 3.4** this case, the PID-3.1 field will be checked if it is a correct Estonian PID format) - 3-letter ISO country code in case of international number - Institution identifier in case of temporary ID PID-5.1° ADT: M Patient Last Name ORM: M ORU: M 64 PID-5.2° ADT: M Patient First Name ORM: M ORU: M PID-7 ADT: M 8 Patient Date of Birth in e.g. 19901127 ORM: M YYYYMMDD ORU: M 4 / 11  PID-8 ADT: M 1 Administrative Sex - M = male ORM: M - F = female ORU: M - O = unknown PID-29°° ADT: M 14 Patient Decease Date(time) in Mandatory if PID-30 = Y ORM: O YYYYMMDD[HH24Mi[SS]] ORU: O PID-30°° ADT: M 1 Patient Death Indicator - N = patient alive ORM: O - Y = patient deceased, time of death ORU: O should be indicated in PID-29 - When left empty in ORM and ORU: it is assumed that the patient is alive. * listed in bold are mandatory values ° Patient first name and last name are mandatory fields. However, if one of these fields or both are missing, the message is still accepted and the missing value(s) is/are replaced with ‘Unknown’. This should ONLY be used in case the patient officially has only 1 name. ** PID-3 can be repeated, e.g.: PID-3.1a^^^PID-3.4a~PID-3.1b^^^PID-3.4b~PID-3.1c^^^PID-3.4c °° If patient is marked as deceased incorrectly, an ADT A08 message is expected with PID-29=”” (two double quotes) and PID-30=N to correct. - Patient ID Issuer: For known patients 3-letter ISO 3166-1 country code (EST for people whom Estonian state issued ID code). For Unknown persons the medical institution will issue the ID and the ID Issuer Code will be institution identifier MRG Field Mand./Opt. Max. Description Remark/Example* field length MRG- M 64 Source Patient ID This patient will be merged to the 1.1** patient in the PID-field. The patient in the PID-field has the data (name, DOB, …) that will be kept. If the patient in MRG-1 does not exist, the identifier will just be created and added to the patient in the PID segment. MRG- M 3 Source Patient ID issuer See PID-3.4 1.4** ** MRG-1.4 can be repeated, but all identifiers should point to the same patient ORC Field Mand./Opt. Max. Description Remark/Example* field length 5 / 11  ORC-1 M 2 Order control - NW = new order - XO = update order - SC = change order status ORC-2** M 16 Order placer number Internal order ID of the subscriber ORC- M 16 Accession number on ORDER Unique ID to identify the order, this 3.1** level number will be used to group different studies in the same order together. ORC-3.2 M 3 Issuer of the ORDER Institution identifier Accession number ORC-5 O 2 Study status - Empty = no status update - SC = created/ordered/scheduled - IP = started - CM = completed - CA = cancelled - DC = discontinued Remark: Patient arrival managed by OBX segment Remark: ORU message will NOT update the Order status ORC-7.6 M 1 Study priority - S = STAT/CITO - R = Routine ORC- M 16 ID code of the ordering Healthcare worker’s code*** 12.1 doctor ORC- M Last name of the ordering 12.2 doctor 64 ORC- M First name of the ordering 12.3 doctor ORC- O 16 Code of the ordering Institution identifier + department 17.1 department code ORC- O 64 Name of the ordering 17.2 department ORC- O 64 Name of the ordering 21.1 hospital ORC- M 16 Code of the ordering Institution identifier 21.10 hospital * listed in bold are mandatory values ** ORC-2 and OBR-2 should contain the same value. ORC-3 and OBR-3 should contain the same value. Optionally, ORC-2 = ORC-3 = OBR-2 = OBR-3. *** Healthcare worker’s code are available: https://medre.tehik.ee/search/employees OBR Field Mand./Opt. Max. Description Remark/Example field length OBR-2** M 16 Order placer number Internal order ID of the subscriber OBR- M 16 Accession number on ORDER Unique ID to identify the order, this 3.1** level number will be used to group 6 / 11  different studies in the same order together. OBR-3.2 M 3 Issuer of the ORDER Institution identifier Accession number OBR-4.1 M 16 Procedure code For Radiology studies, the standard codes should be used. OBR-4.2 O 64 Procedure description Please use the short name of the procedure description. OBR-6 M 14 Order creation time in format YYYYMMDD[HH24Mi[SS]] OBR-13 O 2000 Important clinical On order level, same for all information, study procedures/studies in the order. commentary, medical alerts Newlines should be sent as \.br\ OBR-18 M 16 Accession number on STUDY Unique ID to identify the study, level according to the standard (http://pub.e- tervis.ee/manuals/Digipildi%20s%C3% BCsteemis%20kasutatav%20uuringu% 20registreerimise%20struktuur/2/Acc essionNumber_juhend.pdf ). OBR-19 M 16 Accession number on STUDY Should equal OBR-18 level OBR-20 M 16 Accession number on STUDY Should equal OBR-18 level OBR-22 ORM: not 14 Date and time the report was When report just created: OBR-22 = allowed last modified in OBX-14 (report creation time) ORU: M YYYYMMDDHH24MiSS OBR-27.4 M 14 Date and time the procedure Important for correct and complete is/was scheduled in DMWL YYYYMMDDHH24MiSS OBR-31.2 O 2000 Reason the study was On study level, can be different for all ordered studies in an order. Newlines should be sent as \.br\ OBR- ORM: not 16 ID code of the reporting Healthcare worker’s code 32.1.1° allowed doctor ORU: M OBR- ORM: not Last name of the reporting 32.1.2° allowed doctor ORU: M 64 OBR- ORM: not First name of the reporting 32.1.3° allowed doctor ORU: M OBR- ORM: not 16 ID code of the reviewing Healthcare worker’s code 33.1.1 allowed doctor ORU: O OBR- ORM: not Last name of the reviewing 33.1.2° allowed doctor ORU: O 64 OBR- ORM: not First name of the reviewing 33.1.3° allowed doctor 7 / 11  ORU: O OBR-34.5 M 16 Code of location where study Important for correct and complete is/will be conducted, DMWL acquisition room OBR-43.1 M 16 Code of the performing Institution identifier + department department code OBR-43.2 O 64 Name of the performing department ** ORC-2 and OBR-2 should contain the same value. ORC-3 and OBR-3 should contain the same value. Optionally, ORC-2 = ORC-3 = OBR-2 = OBR-3. ° remark the subsubfields used here. Use OBR-32 and OBR-33 as: CODE&Last_name&First_name. Only the use of OBR-32 is mandatory for reports. For a preliminary report: OBR-32 = author OBR-33 (can be repeated using ~) = reviewer(s) For a final report: OBR-32 = validator OBR-33 (can be repeated using ~) = 1st value -> author, 2nd/3rd... value -> reviewer For a deleted report, OBR-32 should be “” to clear the report author. OBX Report – only in ORU message Field Mand./Opt. Max. Description Remark/Example* field length OBX-2 M 2 Value type FT OBX- M 3 Constant value GDT 3.1.1** OBX-5 M No Report body - Newlines should be sent as \.br\ limit - Content of OBX-5 will be ignored if OBX-11 = D OBX-11° M 1 Report status P = preliminary F = final D = delete report OBX-14 M 14 Date and time the report was created in YYYYMMDDHH24MiSS * listed in bold are mandatory values ** so OBX-3 = ‘&GDT’ (without quotes) ° If OBX-11 = D is sent, Pildipank will delete the report completely and keep no record of the deleted report nor its metadata. 8 / 11 Attachments/Extra info – only in ORM message Field Mand./Opt. Max. Description Remark/Example* field length OBX-2 M 2 Value type TX (except when OBX-3 = SCANNED_REQUEST, then ED should be used) OBX-3 M 20 Attachment code OBX-5 M No Attachment value See table below limit * listed in bold are mandatory values OBX-3 Mand./Opt. OBX-5 value Remark PATIENT_ARRIVED O - YES Indicates whether the patient - NO is arrived or not. Can be used to filter the DMWL based on arrival status. PATIENT_TYPE M - Ambulatory Indicates the current patient - Stationary type. - Emergency PAT_HEIGHT O Patient height in cm Decimal separator = . PAT_WEIGHT O Patient weight in kg Decimal separator = . SCANNED_REQUEST O Scanned Request/order OBX-2 = ED in this case! Base64 encoded Scanned document and digital orders should be transformed image/PDF and then to Base64 encoded string. OBX-5 for PDF = ^TEXT^PDF^BASE64^Base-64 string OBX-5 for image = ^IM^JPEG^BASE64^Base-64 string (replace JPEG with the image format) STUDYCOMMENT O Study comments For example validation comments – “don’t use contrast agent during study” TECHN O Name of technician. TECHNOLOGISTSCOMMENT O Comments entered by the For example – “patient was technologists in the RIS. uncooperative” PRODUCT O Contains the used products VALIDATED O - YES Indicated whether the study is - NO validated or not yet. * listed in bold are mandatory values 9 / 11 ZDS To be used if RIS sends in study UID to be used by modality. This segment is optional, but if present, then ZDS-1 below is mandatory. Field Mand./Opt. Max. Description Remark/Example* field length ZDS-1 M 64 Study UID Should only contain numbers and . Message examples ADT A08 MSH|^~\&|EHL|TYK|EI|PILDIPANK|20220829091330||ADT^A08|82||2.4 EVN||20220829091330 PID|||123456789^^^BEL||KENNISON^COLLIN||19881026|M||||||||||||||||||||||N ADT A40 MSH|^~\&|EHL|TYK|EI|PILDIPANK|20220829091331||ADT^A40|83||2.4 EVN||20220829091331 PID|||123456789^^^BEL||KENNISON^COLLIN||19881026|M||||||||||||||||||||||N MRG|987654321^^^BEL ORM O01 MSH|^~\&|EHL|TYK|EI|PILDIPANK|20220829091331||ORM^O01|84||2.4 PID|||123456789^^^BEL||KENNISON^COLLIN||19881026|M||||||||||||||||||||||N ORC|NW|RIS22081600705|RIS22081600705^TYK||SC||^^^^^R|||||ORD_PHYS_CODE^ORD_PHYS_LAST_NAME^ORD_PH YS_FIRST_NAME |||||TYKDEPT1^Ordering department goes here||||Ordering facility goes here^^^^^^^^^TYK OBR||RIS22081600705|RIS22081600705^TYK|MRT026^MRT LÜLISAMBA NIMMEOSAST (DISK)||20220816131427|||||||here would go clinical info |||||HPERMR2220816028|HPERMR2220816028|HPERMR2220816028|||||||^^^20220816150000||||^Lülisambakanali kitsenemine e spinaalstenoos (Added by WS: purpose of the study)|||^^^^MR2_GE3|||||||||TYKDEPT2^Performing department OBX||TX|PATIENT_ARRIVED||YES OBX||TX|PATIENT_TYPE||Ambulatory 2nd study in same order: MSH|^~\&|EHL|TYK|EI|PILDIPANK|20220829091331||ORM^O01|84||2.4 PID|||123456789^^^BEL||KENNISON^COLLIN||19881026|M||||||||||||||||||||||N ORC|NW|RIS22081600705|RIS22081600705^TYK||SC||^^^^^R||||| ORD_PHYS_CODE^ORD_PHYS_LAST_NAME^ORD_PHYS_FIRST_NAME ||||| TYKDEPT1^Ordering department goes here||||Ordering facility goes here^^^^^^^^^TYK OBR||RIS22081600705|RIS22081600705^TYK|RG514^NIMMELÜLIDEST LAT SEISTES (STANDARD)||20220816131427||||||| here would go clinical info|||||HPERRG4220816118|HPERRG4220816118|HPERRG4220816118|||||||^^^20220816000000||||^Lülisambakan ali kitsenemine e spinaalstenoos (Added by WS: purpose of the study 2)|||^^^^MM_RG4|||||||||TYKDEPT2^Performing department OBX||TX|PATIENT_ARRIVED||NO OBX||TX|PATIENT_TYPE||Ambulatory ZDS|1.2.3.4 Completion of first study: MSH|^~\&|EHL|TYK|EI|PILDIPANK|20220829091331||ORM^O01|84||2.4 PID|||123456789^^^BEL||KENNISON^COLLIN||19881026|M||||||||||||||||||||||N ORC|SC|RIS22081600705|RIS22081600705^TYK||CM||^^^^^R|||||ORD_PHYS_CODE^ORD_PHYS_LAST_NAME^ORD_PH YS_FIRST_NAME ||||| TYKDEPT1^Ordering department goes here||||Ordering facility goes here^^^^^^^^^TYK 10 / 11 OBR||RIS22081600705|RIS22081600705^TYK|MRT026^MRT LÜLISAMBA NIMMEOSAST (DISK)||20220816131427|||||||here would go clinical info |||||HPERMR2220816028|HPERMR2220816028|HPERMR2220816028|||||||^^^20220816150000||||^Lülisambakanali kitsenemine e spinaalstenoos (Added by WS: purpose of the study)|||^^^^MR2_GE3|||||||||TYKDEPT2^Performing department OBX||TX|PATIENT_ARRIVED||YES OBX||TX|PATIENT_TYPE||Ambulatory ORU R01 MSH|^~\&|EHL|TYK|EI|PILDIPANK|20220829091331||ORU^R01|84||2.4 PID|||123456789^^^BEL||KENNISON^COLLIN||19881026|M||||||||||||||||||||||N ORC|SC|RIS22081600705|RIS22081600705^TYK||CM||^^^^^R|||||ORD_PHYS_CODE^ORD_PHYS_LAST_NAME^ORD_PH YS_FIRST_NAME |||||TYKDEPT1^Ordering department goes here||||Ordering facility goes here^^^^^^^^^TYK OBR||RIS22081600705|RIS22081600705^TYK|MRT026^MRT LÜLISAMBA NIMMEOSAST (DISK)||20220816131427|||||||here would go clinical info |||||HPERMR2220816028|HPERMR2220816028|HPERMR2220816028||20220830162500|||||^^^20220816150000|||| ^Lülisambakanali kitsenemine e spinaalstenoos (Added by WS: purpose of the study)|READING_DOCTOR_CODE&READING_DOCTOR_LAST_NAME&READING_DOCTOR_FIRST_NAME||^^^^MR2_GE3||| ||||||TYKDEPT2^Performing department ORC|NW|RIS22081600705|RIS22081600705^TYK||SC||^^^^^R||||| ORD_PHYS_CODE^ORD_PHYS_LAST_NAME^ORD_PHYS_FIRST_NAME |||||TYKDEPT1^Ordering department goes here||||Ordering facility goes here^^^^^^^^^TYK OBR||RIS22081600705|RIS22081600705^TYK|RG514^NIMMELÜLIDEST LAT SEISTES (STANDARD)||20220816131427||||||| here would go clinical info|||||HPERRG4220816118|HPERRG4220816118|HPERRG4220816118||20220830162500|||||^^^20220816000000|| ||^Lülisambakanali kitsenemine e spinaalstenoos (Added by WS: purpose of the study 2)| READING_DOCTOR_CODE&READING_DOCTOR_LAST_NAME&READING_DOCTOR_FIRST_NAME ||^^^^MM_RG4|||||||||TYKDEPT2^Performing department OBX||FT|&GDT||REPORT_BODY||||||F|||20220830162500 Acking On all inbound message, an ACK message will be sent according to the following format: Field Value MSH-1 | MSH-2 ^~\& MSH-3 Value that was originally sent in MSH-5 MSH-4 Value that was originally sent in MSH-5 MSH-5 Value that was originally sent in MSH-3 MSH-6 Value that was originally sent in MSH-4 MSH-7 Date and time of the message in YYYYMMDDHH24MiSS MSH-9 ACK or ACK^R01^ACK MSH-10 Unique Message ID MSH-12 HL7 version that was sent in MSA-1 - AA: message accepted - AE: message rejected MSA-2 Message ID of the original message MSA-3 Error message in case of message rejected ERR-1.4 Other location for error message 11 / 11 Saatja: Andrus Paats - Pildipank <[email protected]> Saadetud: 25.10.2023 21:34 Adressaat: Mary-Liis Moorbach <[email protected]>; <[email protected]>; <"SM Info">; <[email protected]> Teema: Re: Vastuskiri Manused: image001.jpg; image002.jpg; image003.jpg; image004.jpg; image005.jpg; image006.jpg; image007.jpg; PP vastus teabenõudele 25.10.2023.asice Tere Käesolevaga edastame Pildipanga vastuse teabenõudele Lugupidamisega Andrus Paats juhatuse liige SA Eesti Tervishoiu Pildipank From: Mary-Liis Moorbach <[email protected]> Sent: 18 October 2023 16:31 To: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Vastuskiri Teie 10.10.2023 Meie 18.10.2023 nr 1.1-12/20893-1 Lugupeetud Mihkel Miidla Edastame Teile kirja. Lisatud manusena. Lugupidamisega MARY-LIIS MOORBACH Assistent Õigus- ja teabehalduse osakond T: 6033638 E: [email protected] Lastekodu 48,Tallinn E-kiri ja selle manused võivad sisaldada konfidentsiaalseid andmeid ning seda võivad kasutada vaid kirja saajad. Palun ärge edastage ega avaldage kirjas olevat teavet teistele inimestele ilma saatja loata. Juhul kui olete saanud e-kirja eksituse tõttu, teavitage palun kohe saatjat ning kustutage kiri. This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal.