hyväksymispäivä arvosana arvostelija Seminaari: HL7 versio 2 Markus Koski Helsinki 29.9.2014 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Tietojenkäsittelytieteen laitos Markus Koski Työn nimi Arbetets titel Title HL7 versio 2 Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year 29.9.2014 Tiivistelmä Referat Abstract Sivumäärä Sidoantal Number of pages 9 sivua Tämä on seminaarityö HL7 versio 2 -standardista ACM Computing Classification System (CCS): Avainsanat Nyckelord Keywords ehealth, HL7 Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information
ii Sisältö 1 Johdanto 1 2 Viestin syntaksi 2 2.1 Erottimet... 3 3 Yleisimmät segmentit 4 3.1 Otsikko (MSH, Message Header)...4 3.2 Potilaan tiedot (PID, Patient Identification Details)... 5 3.3 Käynti potilaan luona (Patient visit, PV1)... 5 3.4 Kokeen tiedot (Observation Request, OBR)...6 3.5 Kokeen tulokset (Observation Result, OBX)...6 3.6 Z-Segmentit...6 4 Tietotyypit 7 5 Yhteenveto 8 Lähteet 9
1 1 Johdanto Health Level International on kansainvälinen organisaatio, joka kehittää kansainvälisiä standardeja sähköisen terveydenhuollon tarpeisiin. Health Level 7 versio 2 eli lyhyesti HL7 V2 on yksi näistä standardeista. Nimen numero 7 viittaa OSI-mallin seitsemänteen kerrokseen, joka on sovelluskerros. Koska semanttista informaatiota käsitellään ainoastaan mallin seitsemännessä kerroksessa, tekijät ajattelivat sen sopivan Health Levelin nimeen [Ben10, s 79]. HL7 V2 on terveydenhuoltoalan IT-asiantuntijoiden keskuudessa yleisesti varsin tunnettu standardi ja onkin käytössä 35 eri maassa. Esimerkiksi Yhdysvalloissa yli 95% terveydenhuoltoalan instituutioista käyttää HL7 versio 2:sta. HL7 V2 on julkaistu vuonna 1987. Siitä on olemassa erilaisia aliversioita ja tällä hetkellä uusin versio on 2.8.1. HL7 V2 on suunniteltu siten, että se on aina yhteensopiva vanhempien versioiden kanssa [Ben10, s 91]. HL7 -standardin dokumentaatio on laajaa, sivuja on yli 2000. HL7 versio 2 määrittelee erilaisten formaattien avulla miten terveydenhuollon tietoa voidaan vaihtaa sähköisten järjestelmien välillä. Alunperin HL7 versio 1:n tarkoituksena oli välittää tietoa sisäänotoista (admission), kotiuttamisista (discharge) sekä siirroista (transfer) sairaaloiden välillä. HL7 V2:n myötä standardiin lisättiin myös vaihtomääräykset (exchanging orders) ja testitulosten raportit sekä hoidot. HL7 on alunperin suunniteltu sairaalan sisäiseen tiedonvälitykseen, mutta sen avulla on myös mahdollista välittää informaatiota sairaaloiden välillä.
2 2 Viestin syntaksi HL7 V2-viestit ovat ASCII-muodossa ja näin ollen periaattessa luettavaa sellaisenaan. Viestille on aina olemassa tyyppi. Viestin tyyppi voi olla esimerkiksi potilaan kotiutus tai hoito. Viestiin on määritelty myös toimenpiteitä vaativa tapahtuma (trigger event), joka tarkoittaa sellaista terveydenhuoltoon liittyvään toimenpidettä, johon liittyy tarve siirtää informaatiota. Viestit siis lähetetään vastineena tällaisiin tapahtumiin. Tapahtumat ovat aina sidoksissa viestin tyyppiin, ja viittaavaat siihen miten ja miksi viesti muodostui [Ben10, s. 93]. Viestin tyypille on määritelty kolmikirjaiminen tunniste. Eräs esimerkki tällaisesta tunnisteesta on ADT, joka tarkoittaa potilaan hallintaa (patient administration). Myös itse tapahtumalle on olemassa kolmikirjaiminen tunnus, esimerkiksi A02, joka tarkoittaa potilaan siirtoa (patient transfer). Jos edellämainitut yhdistetään, saadaan viesti jossa potilaan siirtotoimenpide on aiheuttanut tarpeen tehdä potilaalle jotakin. Tässä on esimerkki siitä, miltä HL7 version 2 viesti näyttää [INT08]: MSH ^~\& EPIC EPICADT SMS SMSADT 199912271408 CHARRIS ADT^A04 1817457 D 2.5 PID 0493575^^^2^ID 1 454721 DOE^JOHN^^^^ DOE^JOHN^^^^ 19480203 M B 254 MYSTREET AVE^^MYTOWN^OH^44123^USA (216)123-4567 M NON 400003403~1129086 NK1 ROE^MARIE^^^^ SPO (216)123-4567 EC PV1 O 168 ~219~C~PMA^^^^^^^^^ 277^ALLEN MYLASTNAME^BONNIE^^^^ 2688684 199912271408 002376853
3 Viestin syntaksin avulla määritellään viestin sisältö. Viesti koostuu segmenteistä, jotka ovat viestin karkeimman tason yksiköitä. Segmentti on käytännössä yksi rivi joka alkaa kolmikirjaimisella tunnuksella, kuten esimerkiksi OBX, ja loppuu ASCII-järjestelmän rivinvaihtomerkki <CR>. Jokaiselle segmenttityypille on olemassa määrittelytaulukko, joka määrittelee segmentin rakenteen. Segmentti koostuu kentistä, jotka puolestaan sisältävät komponentteja ja alikomponentteja. Kentät merkitään tunnisteen avulla siten, että segmentin tunnisteen perään lisätään numero, esimerkiksi segmentin OBX viidennen kentän tunniste olisi OBX-5. Jos kenttä sisältää alikomponentteja, lisätään perään alinumero, esimerkiksi OBX-5.1. Viestin rakenne määritellään HL7:n taulukossa (Abstract Message Syntax), jossa on listattu segmentit esiintymisjärjestyksessä. Segmentit voivat olla joko pakollisia tai optionaalisia, ja se on kerrottu taulukossa. Tämän lisäksi taulukossa on kerrottu mitkä segmentit voivat toistua [Kuva 1]. Kuva 1: Abstract Message Table [Ben10, s. 94]. Optionaaliset segmentit on ovat erottimien [] sisällä. Toistuvat segmentit ovat {} -merkkien sisällä. Segmentti voi olla sekä toistuva että optimaalinen eikä järjestyksellä ole väliä. Tällöin [{}] ja {[]} ovat molemmat kelvollisia. Nämä merkit eivät siis ole itse viestissä, vaan viestin abstraktion määrittelevässä taulukossa.
4 2.1 Erottimet HL7 V2 -viestin segmenttejä, kenttiä, komponentteja ja alikomponentteja kutsutaan elementeiksi. Elementtien rajat määritellään erottimien (delimeters) avulla [Ben10, s. 95]. Erottimia ovat seuraavat merkit: erottelee kentät toisistaan ^ erottelee komponentit toisistaan ~ on toistettavien elementtien erotin \ kenoviiva kuten ASCII-merkistössä & erottelee alikomponentit <CR> rivivaihto, erottaa segmentit toisistaan Kenttä, jossa on kaksi komponenttia, voidaan kirjoittaa muodossa [FIRST^SECOND]. Jos kentässä on tyhjiä kenttiä, esimerkiksi [FIRST^SECOND^^^^], tarpeettomat erottimet poistetaan lopusta. Näin viestin kokoa saadaan pienennettyä. Kenttä voi olla myös tyhjä, jolloin merkintä on. Se ei ole sama asia kuin NULL-kenttä, jolle on sovittu merkintä ''''. 3 Yleisimmät segmentit HL7 V2 -viestistandardiin on määritelty yli 120 erilaista segmenttiä [INT08]. Tämän lisäksi käyttäjät voivat määritellä omia segmenttejä. Seuraavissa kappaleissa on esitelty näistä yleisimpiä. 3.1 Otsikko (MSH, Message Header) Viestin ensimmäinen segmentti on otsikko ja sen aloittaa aina otsikkokenttä (message header). Sen lyhenne on MSH. Segmentin tunnuksen jälkeen tulee aina -erotinmerkki,
5 joka erottaa kentät toisistaan. Otsikkokenttää seuraa kenttä, jossa kerrotaan viestissä käytettävät erottimet. Yleisiä otsikkosegmentin kenttiä ovat esimerkiksi SenderID, jolla voidaan yksilöidä lähettäjä. Se koostuu kahdesta osasta, jotka on eroteltu komponentteihin. Toinen osa on yksilöivä koodi (identification code) ja toinen on koodin myöntävä taho. Esimerkki SenderID:stä: ^12345^Labs. SenderID määritelty käyttämään kenttää MSH-4. Muita yleisiä otsikkosegmentin kenttiä: DateTime on kentässä MSH-9 ja se kertoo viestin lähettämisajan, esimerkiksi 20140919120852 +0000 MessageType, joka kertoo viestin tyypin kentässä MSH-9 Lähettäjän järjestelmän määrittelemä yksilöivä MessageID, joka on viestin kentässä MSH-10 3.2 Potilaan tiedot (PID, Patient Identification Details) Potilaan tietoja varten on olemassa PID-segmentti. Yksilöinti tapahtuu kentässä PID-3, jossa määritellään potilastunniste (PatientID). Yksilöintiin käytetään useaa eri komponenttia PID-kentässä: sairaalan numeroa, sairaalatunnusta sekä potilastunnusta. Potilastunniste voisi olla 1234^^^VVH^PI jossa 1234 on sairaalanumero, VVH sairaalan tunnus ja PI potilasnumero. Muista kenttiä segmentissä ovat: PatientName, jossa määritellään henkilön nimi, esimerkiksi Rambo^John Syntymäaika DateOfBirth, esimerkiksi 19460706 Kenttä sukupuolta varten SexCode, arvoina M tai F
6 3.3 Käynti potilaan luona (Patient visit, PV1) Potilaan luona käynti sisältää tietoa potilaan sairaalakäynnistä, tärkeimpinä sijainnin (Patient Location) ja hoitavan lääkärin tai hoidosta vastaavan (General Practitioner) tiedot. Potilaan sijainti on kentässä PV-3 ja hoidosta vastaavan tiedot kentässä PV-1 [Ben10, s. 99]. 3.4 Kokeen tiedot (Observation Request, OBR) OBR-segmentti sisältää tarkentavaa tietoa liittyen johonkin kokeeseen tai siitä saatuun tulokseen. Koe voi olla laboratoriokoe, diagnostinen testi tai potilaan tarkkailuun perustuva koe. OBR-segmentissä voi antaa tarkentavia tietoja kokeeseen, esimerkiksi määritellä laboratorionäytteen tyypin (esim. virtsanäyte, verinäyte) ja mistä se on otettu (esim. käsivarsi). Näille on olemassa omat kentät. 3.5 Kokeen tulokset (Observation Result, OBX) Koetuloksia voidaan välittää OBX-segmentissä. Yksi OBX-segmentti sisältää yhden kokeen tiedot. Tulokset ovat muotoa attribuutti arvo. Mitattava attribuutti (Observation Identifier) on kentässä OBX-3 ja sen tulos kentässä OBX-5. OBX-3 ja OB-x5 sisältävät seuraavat komponentit: OBX-3.1 sisältää testin koodin OBX-3.2 taas kertoo kokeesta (ihmisen) luettavassa muodossa Koodi kentässä OBX-5.1 Näytettävä teksti kentässä OBX-5.2
7 3.6 Z-Segmentit Valmiiden segmenttien lisäksi HL7 V2 antaa mahdollisuuden määritellä myös omia segmenttejä, viestityyppejä ja tapahtumia. Tätä varten on olemassa Z-segmentit. Z- segmentit ovat laajasti käytössä ja tämän vuoksi HL7 V2 -viesteistä onkin olemassa paljon variaatioita. 4 Tietotyypit HL7 V2 -viestin tietotyyppejä käytetään elementtien sisällön rakentamiseen. Jokaiselle kentälle, komponentille ja alikomponentille on olemassa määritelty tietotyyppi. Tietotyyppi määrittelee tiedon esitystavan, sen mitä alikomponentteja se voi sisältää sekä mahdolliset sanaston rajoitteet. Yksinkertaisimmillaan (simple) tietotyypit voivat sisältää vain yhden arvon, kun taas monimutkaisemmat (complex) tietotyypit voivat sisältää esimerkiksi useita alikomponentteja, joissa voi jokaisessa olla oma tietotyyppi, ja lisäksi tämä tietotyyppi itsessään voi olla monimutkainen tietotyyppi. [Ben10, s.102]. Monimutkaiset tietotyypit voidaan jakaa kolmeen eri kategoriaan: koodit ja tunnisteet (codes and identifiers) nimet ja osoitteet muut kompleksiset tietotyypit Koodien ja tunnisteiden käyttö on tärkeää eri järjestelmien ja organisaatioiden välisessä yhteistyössä. Käytettävät tunnisteiden koodausmenetelmät ovat joko HL7:n tai jonkin muun tahon määrittelemiä. HL7:n määrittelemiä koodausmenetelmiä kutsutaan sisäisiksi (internal) ja muun tahon määrittelemiä taas ulkoisiksi (external) [Ben10, s 104]. Jos kaksi eri tahoa, joiden välillä siirretään informaatiota, käyttävät eri koodausmenetelmiä tunnisteiden generoimiseen, on olemassa vaara että molemmat tuottavat saman tunnisteen. HL7 on ratkaissut tämän sisällyttämällä viestiin sekä
8 koodausmenetelmän että sen tuottaman tunnisteen. Viestissä on varattu sekä koodausmenetelmälle että sen tuottamalle tunnisteelle omat kentät. On olemassa kaksi tapaa toteuttaa tämä [Ben10, s. 103]: 1. Haetaan koodi taulukosta, joka on nimetty tietotyypin määrittelyssä. Tämä on rajoittuneempi tapa ja sopii ainoastaan tietotyypeille ID (HL7:n määrittelemä taulukko) ja IS (käyttäjän määrittelemä taulukko). 2. Lähetään koodausmenetelmän tunniste sen tuottaman tunnisteen mukana. Tämä sopii yleisille tapauksille. HL7 V2 käyttää tietotyyppiä koodien ja tunnisteiden kanssa: CNE (Coded with No Exceptions) ja CWE (Coded With Exceptions). CNE on käytössä kun koodausmenetelmän käyttö on välttämätöntä. CWE on käytönnössä muuten samanlainen kuin CNE, mutta tunnistekomponentti ei ole siinä pakollinen. Esimerkkejä yksinkertaisista tietotyypistä: ST eli merkkijono joka sisältää merkkejä 0-200 kpl DT eli päivämäärä, kirjoitetaan muodossa YYYY[MM[DD]] Esimerkki monimutkaisesta tietotyypistä: SAD eli katuosoite 1234 Industrial Loop^^Calabasas^CA^91302^USA^B 5 Yhteenveto HL7 V2 on laajalti käytössä oleva sähköisen terveydenhuoltoalan standardi, jolla määritellään sähköisen viestinnän muoto. Periaatteet ovat yksinkertaiset, mutta toteutus on laaja standardista on olemassa paljon dokumentaatiota ja määritelmiä. Lisäksi Z- segmentit mahdollistavat käyttäjien omien segmenttien määrittelemisen, mikä lisää toteutusten variaatioiden määrä, mikä ei ole välttämättä ole aina hyvä asia.
9 Lähteet Ben10 INT08 Benson, Tim, Principles of Health Interoperability HL7 and SNOMED. Health Informatic Series, Springer-Verlag London Limited 2010. Interfaceware blog, HL7 segments. http://www.interfaceware.com/blog/hl7- segments. [13.5.2008]