KANTA HL7 RAJAPINTAMÄÄRITTELYT: ERILLISJÄRJESTELMIEN LIITTÄMINEN KANTA-PALVELUUN ERILLISJÄRJESTELMIEN KANTAPALVELUTAPAHTUMARAJAPINNAT TYÖRYHMÄ 5.5.2010 Timo Kaskinen, Timo Siira, Jarkko Närvänen SOLEA PALVELUTAPAHTUMA – PROSESSITAPAHTUMA KESKUSTELU SOLEA prosessitapahtuma palvelutapahtuma määritykset • erillisjärjestelmien KanTa-palvelutapahtumarajapinnat työryhmän kokous 7.4.: • ”Palvelutapahtumaan saattaa kuulua useita hoitojaksoja (esim. kaksi vuodeosastojaksoa). Yhteen palvelutapahtumaan voi siis kuulua useita prosessitapahtumia. Keskusteltiin palvelutapahtuman ja prosessitapahtuman suhteesta. Prosessitapahtuma on KanTamäärittelyissä käyttöönotettu yleistermi, joka kattaa potilashallinnollisia, tilastointiin ja raportointiin liittyviä ja tuotteistukseen ja laskutukseen liittyviä käsitteitä. Prosessitapahtuma on eräänlainen yleistermi kaikilla hoidollista kontaktia (sisään-ulos sairaalasta) pienemmille tapahtumille, joita ei ole haluttu ottaa KanTa-määrittelyissä käsiteltäviksi. ” 3 Solea prosessitapahtuma keskusteluun • Viedään seuraavaan Solea-kokoukseen käsittelyyn että ovatko prosessitapahtuman määritelmät ja tietomalli kansallisesti kiinnitettävissä. Mikäli prosessitapahtuma on keskeinen hoitoa yksilöivä tapahtuma, ja integrointiratkaisut edellyttävät käyttöä, niin se on virallistettava kansallisella tasolla. Toimittajakohtaiset liittymät ovat todennäköisesti erilaisia. Prosessitapahtuma tulee ottaa rajapintoihin mukaan rajatusti koskien potilashallintoa eli vuodeosastohoitojakson tai käynnin tasolla. Tällä tasolla prosessitapahtuma voi olla merkityksellinen merkintöjen kohdistamisessa palvelutapahtumalle. Varmistettava myös PTH:n näkemys asiaan, nyt Solea-työ ollut pääosin ESH-vetoista. 4 v.0.86 dokumentista Prosessitapahtuma • Kopioitu tähän ja seuraaville kalvoille SOLEA palvetapahtumien hallinta dokumentista v 0.86 liittyvät asiat • Toteutettavissa eri tavoin, alustava ehdotus palvelutapahtumien hallinnan kannalta olennaisiksi tiedoiksi (liite 2): – Yksilöivä tunnus – Toimintayksikkö tai ammattihenkilö (kuka) • yksityinen / julkinen / työterveys • toimintayksikön rooli organisaation toiminnassa – – – – – toimintayksikön rooli potilaan palvelutapahtumassa alkamisaika päättymisaika onko laitos- vai avohoitoa hoitoprosessin tunniste 5 V.086 prosessitapahtuma määritelmä • Prosessitapahtuma, Hoitoprosessin tapahtuma • Terveydenhuollon palvelujen antajan toteuttama potilashoidon prosessin tapahtuma - synonyymejä termille prosessitapahtuma ovat hoitoprosessin tapahtuma, potilashallinnon tapahtuma, tilastotapahtuma ja osin myös palvelu. (Laskentatoimessa prosessitapahtumia kutsutaan nimellä suorite tai välisuorite) (Alk09). Prosessitapahtuma voi olla esimerkiksi yhden vuodeosaston hoitojakso, vastaanottokäynti, näytteenotto tai kuvanottokäynti (Alk09). Prosessitapahtumat ovat tyypillisesti palvelutapahtumaa pienempiä yksiköitä, joita voidaan yhdistellä ja ryhmitellä eri tavoin mm. laskutusta, tilastointia tai johtamista varten. Ks. myös hoitotapahtuma. 6 v.0.86 Hoitotapahtuma • • • Hoitoa antavan sosiaali- tai terveydenhuollon ammattihenkilön ja asiakkaan välinen yksittäinen vuorovaikutustilanne. Tietojärjestelmien kannalta: Hoitotoimintaa tukevassa tietojärjestelmässä hoitotapahtuma on sellainen yksittäinen vuorovaikutustilanne, joka dokumentoidaan ja joka on sovittu kirjattavaksi tietojärjestelmään. Hoitotapahtuma kohdistetaan jollekin asiakkaalle, ja hoitotapahtuman yksilöinnissä, tyypittelyssä ja luokittelussa voidaan käyttää nimike- tai tuotetunnuksia. Hoitotapahtuman nimikeja tuotekuvauksista useat ovat suoritelaskennan peruselementtejä. Hoitotapahtuma voidaan kirjata tietojärjestelmään eri elinkaaren vaiheissa: suunnitteluvaiheessa (hoitotapahtuma aiotaan toteuttaa tulevaisuudessa), tilausvaiheessa, varausvaiheessa tai vasta kun se on toteutunut tai toteutumassa. Henkilötietolain kannalta: Hoitotapahtuma on pienin yksittäinen vuorovaikutustilanne, josta kertyy rekisteröitävää tietoa asiakkaan hoidosta muodostuvaan henkilörekisteriin. Tiedon käsittelyä ohjaavat menettelyt on sisällytetty tietojärjestelmään siten, että henkilötietojen käsittely täyttää lainsäädännön vaatimukset. Tietojen käsittely ja siirto toteutetaan ensisijaisesti asiakkaan luvalla. (Stakes02) 7 v.0.86 käsitemalli 8 ERILLISJÄRJESTELMIEN KANTAPALVELUTAPAHTUMARAJAPINNAT TYÖN ESITTELY Lähestymistapa / johdanto Palvelutapahtuman tietojen osalta ydin- ja erillisjärjestelmän välillä on useita tapoja toteuttaa tietojenvaihto. Tarve on yhdistää potilaan hoitoon liittyvät merkinnät loogisiksi kokonaisuuksiksi (palvelutapahtuma) ja saada tiedot arkistoitua KanTaan hyödynnettäväksi. Lähestymistapoja: 1.Mikäli erillisjärjestelmässä tehdään merkintöjä (kokonaisia asiakirjoja tai asiakirjan osia), jotka eivät siirry ydinjärjestelmään ja jotka pitäisi saada KanTaan, niin palvelutapahtuman tiedot on saatava välitettyä järjestelmien välillä. Muuten tarvitsee jälkeenpäin selvittää/liittää mihin palvelutapahtumaan tietyt merkinnät kuuluvat. 2.ydinjärjestelmä huolehtii ydin- ja erillisjärjestelmän tietojen kohdentamisen korreloimalla pyynnöt ja vastaukset erillisenä palveluna. Tämä voidaan mahdollisesti myös toteuttaa ydin- ja erillisjärjestelmästä irrallisena palveluna. 3.Jos esimerkiksi laboratoriotulokset siirtyvät ydinjärjestelmään ja siellä on jo tällä hetkellä olemassa tapa, miten pyyntö sekä vastaus kohdistetaan palvelutapahtumaan, niin palvelutapahtumatunnuksen siirtoa ei tarvitse erikseen pohtia ollenkaan. 10 Työn tavoite ja kohderyhmä Tavoite • Määritellä ja koostaa yhteen tiedot, miten ja millä tavalla potilaan hoidon palvelutapahtuman tunnustiedot voidaan välittää ydinjärjestelmän ja erillisjärjestelmien välillä. • Määrittely sisältää integraatiovaihtoehtojen kuvaukset ja sanomamäärittelyt siirrettävien tietojen osalta. Määrittelyn kohderyhmänä ovat ydin- ja erillisjärjestelmätoimittajat sekä organisaatioiden eri tasojen arkkitehtuurityöstä vastuulliset tahot. 11 Rajaukset ja oletukset • Määrittely ei ratkaise kaikkea asiakirjan arkistoinnissa tarvittavien tietojen siirtoa järjestelmien välillä. Tässä työssä on rajauduttu ensisijaisesti palvelutapahtuman tunnuksen välittämiseen. Muita tarvittavia tietoja on kuvattu CDA R2 Header dokumentissa [2] sekä SOLEA-hankkeen tulosdokumentissa [3]. 12 Määrittelyn Sisällys 1. JOHDANTO 4 1.1 TYÖN TAUSTA JA LÄHESTYMISTAPA,1.2 MÄÄRITTELYN TAVOITE JA KOHDERYHMÄ, 1.3 RAJAUKSET JA OLETUKSET, 1.4 VIITATUT MÄÄRITTELYT 5 2. PALVELUTAPAHTUMAN JA PROSESSITAPAHTUMAN TIETOMALLI, SIIRRETTÄVIEN TIETOJEN KUVAUS 3. INTEGRAATIOTAVAT PALVELUTAPAHTUMATUNNUKSEN VÄLITTÄMISEKSI 6 3.1 HL7 CONTEXT MANAGEMENT SPECIFICATION (CCOW) JA MINIMIKONTEKSTINHALLINTA 6 3.2 SANOMAT POTILAAN HOIDON VASTUUN SIIRTYESSÄ JÄRJESTELMÄLTÄ TOISELLE 7 3.3 KYSELYSANOMAT 8 3.4 INTEGRAATIOTAPOJEN SOVELTUVUUDEN VERTAILU ERI KÄYTTÖTARPEISIIN 10 4. HL7 CONTEXT MANAGEMENT SPECIFICATION (CCOW) JA MINIMIKONTEKSTINHALLINTA 11 4.1 HL7 CONTEXT MANAGEMENT SPECIFICATION (CCOW) 11 4.2 MINIMIKONTEKSTINHALLINTA 16 4.3 PALVELUTAPAHTUMATUNNUKSEN VÄLITTÄMINEN KONTEKSTINHALLINNALLA 18 4.3.1 Kontekstinhallinta ja tiedon välitys 18 4.3.2 Minimikontekstinhallinta ja palvelutapahtuma 19 5. SANOMAT POTILAAN HOIDON VASTUUN SIIRTYESSÄ JÄRJESTELMÄLTÄ TOISELLE 19 5.1 AJANVARAUS 19 5.2 LÄHETE 20 5.3 PYYNTÖ 20 5.4 OSASTONSIIRTO 20 6. KYSELYSANOMAT 20 13 HL7 Context Management Specification (CCOW) • CCOW:n toiminnallisuutta kuvaa allaoleva esimerkki: – Käyttäjä valitsee potilaan, jostakin työpöydällä auki olevasta sovelluksesta – Sovellus ilmoittaa context managerille kontekstin muutoksesta ja asettaa kontekstin tiedot vastaamaan valittua potilasta – context manager ilmoittaa agenteille kontekstin muutoksesta ja agentit ilmoittavat context managerille mahdollisia lisätietoja (esim. potilaan tunnistetietoja) – context manager ilmoittaa sovelluksille kontekstin muutoksesta – sovellukset ilmoittavat voivatko ne ottaa käyttöön uuden kontekstin – Jos yksi tai useampi sovelluksista ei voi ottaa uutta kontekstia, niin käyttäjältä kysytään haluaako hän jatkaa vai keskeyttää kontekstin vaihdon – context manager ilmoittaa sovelluksille, että ne voivat ottaa uuden kontekstin käyttöön tai että toimenpide on keskeytetty – Jokainen sovellus ottaa uuden kontekstin käyttöön 14 CCOW subjektit Subjekti Kuvaus User Identity Subject Sovelluksen käyttäjän tiedot Patient Identity Subject Potilaan tiedot Encounter Identity Subject Observation Request Identity Subject Potilaan ja hoitohenkilökunnan välisen vuorovaikutuksen tiedot (käynnit, puhelut jne.) Tutkimuspyyntöjen tiedot DICOM Study Identity Subjects DICOM komponenttien tiedot View Subject Sovelluksen näytön, näkymän tai esitystavan tiedot Kirjautuneen käyttäjän sertifikaatin tiedot Certificate Annotation Subject Authenticate-User Action Subject Custom Subjects Sovellus voi pyytää käyttäjän tunnistautumistiedot Toteuttajan räätälöimät tiedot 15 Encounter Identity Subject Potilaan ja hoitohenkilökunnan välisen vuorovaikutuksen tietojen (käynnit, puhelut jne.) välittämiseen käytetään subjektia: Encounter Identity Subject. Encounter Subject Identifier Item Name Enconter.Id.VisitNumber. Suffix Encounter.Id.AlternateVisitId. Suffix Encounter.Id.AccountNumber . Suffix Meaning Visit Number, per PV1-19 Alternate Visit Id, per PV1-50 Account Number, per PID-18 Data Type ST ST ST Semantic Constraints Case Sensitive on Values HL7 Table 0203 No Identifier Type = VN HL7 Table 0203 No Identifier Type = VN HL7 Table 0203 No Identifier Type = AN 16 Minimikontekstinhallinta • • • • Minimikontekstinhallinnan määrittelyn pohjana on käytetty CCOW-standardissa kuvattua ratkaisua työpöytäintegraation toteuttamiseen. Minimikontekstinhallinnan määrittelyn tavoitteena oli hahmottaa minimiratkaisu, jolla CCOW-tyyppinen toiminnallisuus oli saavutettavissa. CCOW-standardista pyrittiin löytämään vain kaikkein olennaisimmat ja hyödyllisimmät osat, joilla työpöytäintegraation perustoiminnallisuus voitiin toteuttaa. Toiminnallisuus on käyttäjälähtöistä eli käytössä ei ole CCOW:n tapaan automaattista (Context managerin ohjaamaa) kontekstin vaihtamista. Sen avulla on mahdollista toteuttaa kertakirjautuminen sovelluksiin ja yhteiseen kontekstiin siirtyminen (kontekstin synkronointi). Potilaskontekstin muutosten tapahtumaketju on seuraavanlainen (oletuksena, että sovellus on jo liittynyt kontekstinhallintaan): – – – – Käyttäjä valitsee potilaan käyttäen jotain integraatioon kytkettyä sovellusta. Sovellus asettaa (SetItemValues) kontekstia identifioivan tunnisteen (potilastunniste) kontekstiin. Käyttäjä vaihtaa toiseen sovellukseen ja klikkaa esim. "Hae viimeisin potilas"-painiketta, jolloin sovellus hakee kontekstista viimeisimmäksi käsitellyn potilaan. Sovellus sopeuttaa sisäisen tilansa ja näyttää tiedot potilaskontekstin mukaisesti (näyttää sen potilaan tiedot, jonka potilastunnuksen sai kontekstinhallinnasta). 17 Kontekstinhallinta ja tiedon välitys • yhteinen konteksti koostuu joukosta tietoja, joita voidaan käsitellä sovellusten sisäisestä toteutuksesta riippumatta samalla tavalla. Tärkeimmät tiedot liittyvät käyttäjään ja potilaaseen, joiden avulla saadaan toteutettua kertakirjautuminen (käyttäjä) ja seurata saman potilaan tietoja koordinoidusti eri ohjelmissa (potilas). • Kontekstinhallintaa ei ole tarkoitettu sovellusten välisen tiedonsiirron muodoksi, eikä sillä ole tarkoitus korvata sovellusten välistä tiedonsiirtoa. • Konteksti muodostuu tietokokonaisuuksista, subjekteista. Siitä on ilmaistava vähintään yksi id-tieto (esim. henkilötunnus). Jokaiseen subjektiin liittyy joukko tietoja, jotka täsmentävät subjektia. Muut tiedot ovat riippuvaisia id-tiedosta. Jos subjektin id-tieto vaihtuu, niin kontekstista tyhjennetään kaikki muut tiedot. Subjektien välille voidaan määritellä riippuvuuksia. Esim. Encounter-subjekti on riippuvainen Patient-subjektista. 18 Kontekstinhallinta ja tiedon välitys • Kontekstinhallinta on ”yksiulotteista” eli kutakin subjektia on yksi kerrallaan. Kontekstiin ei ole tarkoitus viedä listoja, joissa olisi lukuisia Patient- tai Encounter-subjekteja. Kun sovelluksessa valitaan potilas (Patient) ja potilaaseen liittyvä käynti tai hoitojakso (Encounter), niin kontekstiin siirretään yksi potilas ja yksi käynti. Standardin tarkoituksena ei ole se, että kontekstiin siirretään yksi potilas ja kaikki hänen käyntinsä. Tarkoituksena ei myöskään ole se, että jos palvelutapahtuma lisätään omaksi subjektikseen, niin kontekstinhallinnan kautta välitettäisiin potilas, palvelutapahtuma ja kaikki siihen liittyvät käynnit. 19 Palvelutapahtuma minimikontekstinhallinnassa • subjektikoodistossa ei tällä hetkellä ole määriteltynä palvelutapahtumaa. Subjektikoodistossa on määriteltynä Encounter.Id.VisitNumber (Käynnin tai hoitojakson tunniste) ja Encounter.Id.AlternateVisitId (Toissijainen käynnin/hoitojakson tunniste). • Jos lähtökohtaisena tietona on potilaan prosessitapahtuma, niin palvelutapahtuman tunnistetta varten voidaan käyttää tietoa Encounter.Id.AlternateVisitId (Toissijainen käynnin/hoitojakson tunniste) tai sille voidaan luoda uusi custom-subjekti. Näistä suosittelemme ensimmäistä. • Tällöin prosessitapahtumaa kontekstissa käsiteltäessä olisi aina tiedossa palvelutapahtuma, johon prosessitapahtuma kuuluu. Kontekstin perusteella toisinpäin ei toimi eli ei tiedetä, kuuluuko palvelutapahtumaan muitakin prosessitapahtumia. • Samoin jossain vaiheessa SOLEA:ssa keskutellut valintalistoja (potilaan voimassa olevat palvelutapahtumat) ei pysty minimikontekstinhallinnalla toteuttamaan. Näitä varten pitää toteuttaa kyselypohjainen rajapinta, jos on tarve. 20 CCOW ja mini.. tiedonsiirtotarkoituksiin CCOW:n standardissa (HL7 Context Management “CCOW” Standard: Technology- and Subject-Independent Component Architecture, Version 1.5, May 2004) on maininta CCOW:n käytöstä tiedonsiirrossa: Luku 2.2 ASSUMPTIONS/ASSERTIONS (4. kohta): Context management is not a form of data interchange nor is it a substitute for data interchange. However, the common context might contain data that can also be obtained by an application through data interchange mechanisms such as those based upon HL7 (e.g., a patient’s name or date of birth in addition to a patient identifier). When such data is provided, it is only as a means to simplify or optimize the sharing of common context. 21 CCOW ja mini.. tiedonsiirtotarkoituksiin Toisaalta luku 2.3 CMA DESIGN CENTER ei niin yksiselitteisesti kuvaa tuota asiaa, koska suunnittelun kohteena ovat järjestelmät, joiden on tarkoitus vaihtaa tietoja keskenään. The CMA specification is primarily aimed at enabling interoperability in the form of application control by the end user. Applications that interoperate in this manner appear to the user as visually integrated. Further, the design foThis is because the user can see ways in which the applications interoperate. This is in contrast to traditional healthcare standards, which have been primarily aimed at enabling interoperability in the form of data interchange between applications.cus for the CMA specification is applications that have a means for interchanging clinical data. The overall role of the CMA specification is illustrated in figure 4. ”Itse tulkitsen standardia niin, että tiedonsiirto tapahtuu taustalla muilla tavoin (sanomat) ja kontekstinhallinta on tarkoitettu vain helpottamaan sovellusten sujuvampaa yhteiskäyttöä.” 22 Kysyksiä minimikontekstinhallinnan toteuttaneille ja hyödyntäville • Millaisia käyttötapauksia/käyttötarpeita olette toteuttaneet minimikontekstinhallinnan avulla? • Onko encounter-subjektit käytössä toteutuksessanne? • Mitä custom subjekteja teillä on käytössä? • Hyödynnättekö minimikontekstinhallintaa myös tiedonsiirtomielessä? Esimerkiksi tallentuuko erillisjärjelmään kontekstin kautta jotain tietoa, mitä se ei muuten saa sanomaintegraation kautta (tai jotain muuta kautta)? 23 SANOMAT POTILAAN HOIDON VASTUUN SIIRTYESSÄ JÄRJESTELMÄLTÄ TOISELLE • HL7 versio 2.x. sanomaperheen osalta yleisratkaisu palvelutapahtuma- ja palvelukokonaisuustunnuksen välittämisessä on HL7 teknisen komitean kokouksessa 25.11.2008 käsittelyn mukaisesti: • ”TT kävi läpi tapaa, jolla HL7 v2.x-maailmassa voitaisiin siirtää palvelutapahtuma- ja palvelukokonaisuustunnukset ja ehdotti kenttää PV150, joka on yleensä mukana lähes joka sanomassa ja jossa voidaan ilmoittaa hoitoprosessiin liittyviä tunnisteita. Käydyssä keskustelussa todettiin, että on hyvä noudattaa jo olemassa olevia soveltamisohjeita, eikä ole tarvetta määritellä uutta kenttää. Koska kukaan ei vastustanut ehdotusta, hyväksyttiin palvelutapahtumatunnuksen välittäminen kentässä PV1-50 tunnisteen tyypillä PTAP. Kenttää ei laiteta pakolliseksi. ” • Tätä peruslinjausta on tarkennettu ja tarkasteltu seuraavassa: – – – – Ajanvaraus Lähete Pyyntö Osastonsiirto 24 Palvelutapahtumatietojen kysely? • rajapinnan tarjoava sovellusrooli / palvelu: tapahtumatietojen varasto • kyselyparametrit – – – – potilas aikarajaukset?, tulevat, käynnissä, tapahtuneet? prosessitapahtumat?, AC-numero tms. tunniste? minkä palvelutapahtumien tietoja palautetaan? • voimassa olevat? aktiiviset? kaikki joita varasto hallinnoi? – toteutustason mukaiset rajaukset (palvelunantajakohtainen, palvelunjärjestäjäkohtainen, alueellinen, valtakunnallinen)? • paluuarvot – palvelutapahtuman kaikki tiedot? – myös pelkät tunnisteet tarpeen? 25 25 Kyselysanomat • Potilashallinnon sanomat • Palvelutapahtuman tietojen kysely ydinjärjestelmän tarjoamasta rajapinnasta tai – Medical Records -dokumentissa on kuvattu yleisen esimerkin avulla keskeiset Medical Records -standardiin kuuluvat kyselyt/käyttötapaukset (s. 15). Käyttötapaukset ovat: – Paikallinen järjestelmä lähettää kansalliseen tietovarastoon dokumentin (interaktio RCMR_IN000002). – Tietovarasto rekisteröi dokumentin kuvailutiedot (metatiedot) erilliseen hakemistoon / rekisteriin (interaktio RCMR_IN000027). – Dokumenttien kyselyyn on kaksi interaktiota. • Ensimmäinen kysely palauttaa pelkät kuvailutiedot (RCMR_IN000029 ja RCMR_IN000030). • Toinen kysely palauttaa vastauksessa myös varsinaisen tietosisällön eli koko dokumentin (RCMR_IN000031 ja RCMR_IN000032). – Palvelutapahtumatiedon välittämisen osalta keskeinen on kuvailutiedot26 palauttava sanoma (RCMR_IN000029 ja RCMR_IN000030). Medical Records • Medical Records -sovellusalueeseen on määritelty erilaisia interaktioita, joista osa on mainittu olevan Suomeen ensi vaiheessa paikallistettavassa arkistototeutuksessa. Näistä palvelutapahtumatietojen välittämiseen soveltuvia vaikuttaisivat olevan seuraavat kysely-aihealueen interaktiot: – – Find Document Metadata Query(RCMR_IN100029FI01) Find Document Metadata Response(RCMR_IN100030FI01) • Interaktiot jotka hyödyntävät pelkkiä kuvailutietoja on sidottu viestityyppiin RCMR_MT100001FI01. Clinicaldocument.text elementin käyttö ei ole sallittua tässä viestityypissä. • Kyseiset viestityypit on alkuperäisessä standardissa tehty asiakirjan tai sen kuvailutietojen palautukseen. Kanta-arkiston yhteydessä näillä sanomilla kuitenkin palautetaan myös laissa 159/2007 määritellyt hakutiedot. Palvelutapahtuman tiedot ovat sinänsä normaaleja asiakirjan kuvailutietoja, joten standardin viestityyppi täsmää hyvin hakutietoihin. Suurin poikkeama tulee pakollisten tietojen suhteen, sillä palvelutapahtuman tietojen palautuksen yhteydessä ei voida palauttaa kaikkia tietoja jotka asiakirjan tai sen kuvailutietojen yhteydessä on pakollisia. 27 Tietosisältö Kentän nimi Tietotyyppi Arkistosanoman MR-sanomien soveltamisoppaan ohjeistus (selite) ClinicalDocument Description: This RMIM is used to derive Medical Records specifications. Hakutieto (palvelutapahtumia palautettaessa, ei palvelukokonaisuuksissa). Kentällä ilmaistaan mihin rekisteriin potilasasiakirja kuuluu (julkinen terveydenhuolto, yksityinen terveydenhuolto, jne). Käytettävä koodisto: KanTa-palvelut - Potilasasiakirjan potilasrekisteritunnus OID: 1.2.246.537.5.40150.2008 Medical Records HMD ClinicalDocument code .. 1..1 CE 0..* SET<DocumentationOf> 0..1 Component1 1..1 EncompassingEncounter [clip…] documentationOf Stakesin palveluluokituksen mukainen palvelu. Rakenteessa voidaan esittää myös yksityiskohtaisempia palvelutapahtumassa toteutuneita kliinisiä palveluita. [clip…] componentOf [clip…] encompassingEncounter Hakutieto. Palvelutapahtuman tiedot. Palvelutapahtumasta vastaava toimipiste (toimipaikka) ja palvelutapahtuman aika, Tieto palvelunantajasta vuodeosaston, poliklinikan tai toimenpideyksikön tarkkuudella; osastohoitojakso tai avohoitokäyntitieto ja niiden alkamis- ja päättymispäivä; Esimerkiksi: käynti tk pvm; osastohoitojaksossa esim. kiros/sisos, ajanjakso (voidaan tarvita myös kellonaika, jos päivämäärätarkkuus ei riitä) 28 Tietosisältö Kentän nimi Tietotyyppi Arkistosanoman MR-sanomien soveltamisoppaan ohjeistus (selite) 0..* SET<II> Hakutieto. Palvelutapahtuman yksilöivä tunniste. (ei palauteta palvelukokonaisuuden hakutietona) 1..1 IVL<TS> Hakutieto. Palvelutapahtuman alkamis- ja päättymispäivä –(voi sisältää päivän lisäksi myös tarkemman ajankohdan, yleensä päivän tarkkuudella). Jos loppupäivä puuttuu on palvelutapahtuma vielä käynnissä. 0..1 Location 0..* SET<II> Hakutieto. Palvelutapahtuman tuottavan palvelujen antajan yksilöintitunnus 0..1 EN Hakutieto. Palvelutapahtuman tuottavan palvelujen antajan nimitieto. CV Hakutieto. Varsinaista palvelutapahtuma luokituksesta yksinkertaistettu koodiarvo, joka kuvaa lain hakutiedon ”osastohoito ja avokäyntitieto”. Koodisto: eArkisto Palvelutapahtuman laji (hakutietoja varten). OID: [clip…] id [clip…] effectiveTime [clip… location [clip…] id [clip…] name [clip…] hl7fi:localHeader [clip…] encompassingEncounterC 0..1 ode 29 Tietosisältö Kentän nimi Tietotyyppi encompassingEncoun 0..1 terMasterCode BL secondaryEncompassi 0..* ngEncounterId II Arkistosanoman MR-sanomien soveltamisoppaan ohjeistus (selite) Ilmaisee onko asiakirja ns. ensisijainen asiakirja, jossa on mukana palvelutapahtuman tiedot täydellisenä (ja josta hakutiedot on poimittu). Toissijainen palvelutapahtumatunnus "Kuuluu myös": Mikäli asiakirja kuluu myös toiselle rekisterinpitäjälle, niin tämä voi liittää siihen myös oman palvelutapahtumatunnuksensa Tämän kentän käyttöä tullaan täsmentämään myöhemmin. [clip…] KantaMetadata 0..* Kanta arkiston muut metatiedot ilmoitetaan tässä rakenteessa. Tähän tulee tiettyjä documentum järjestelmän kuvailutietoja kuten asiakirjan koko. Käytettävät arvot voi katsoa Kelan ohjeista tai testiviesteistä. [clip…] validConsentId 0..* II Hakutieto. Kentässä palautetaan voimassa olevat suostumukset, jotka liittyvät kyselyviestissä annettuun toteutettavaan palvelutapahtumaan tai palvelukokonaisuuteen, jossa kyseltäviä tietoja aiotaan hyödyntää (Arkisto palauttaa kyseiselle palvelujen antajalle voimassa olevat suostumusasiakirjojen yksilöintitunnukset, Eli potilastietojärjestelmä voi hyödyntää aiempia suostumuksia vaikka sillä ei olisi 30 niistä kirjanpitoa.) Integraatiotapojen vertailua Minimikontekstinhallinta (ja CCOW) Hoidon vastuun siirron sanomat Kyselysanomat / Käyttökohde Työpöytäintegraatio, missä käytetään minimikontekstinhallinnan avulla useita sovelluksia (mm. erillisjärjestelmät). Käyttötapauksia Kertakirjautuminen ja yhteisen kontekstin hyödyntäminen KV-tunnettavuus CCOW laajasti käytössä, vaatisi minimikontekstinhallinnan täydentämistä ja toimintalogiikan muuttamista yhteensopivuuden saavuttamiseksi Siirrettäessä potilaan Potilaan perustietojen siirto hoidon jatkamisen kannalta järjestelmästä toiseen tarpeelliset tiedot kyselysanomien pohjalta järjestelmästä toiseen Potilashallinnon kyselysanomat Palvelutapahtuman tietojen kysely ajanvaraus Erillisjärjestelmä kysyy lähete potilaan tietoja pyyntö ydinjärjestelmältä osastonsiirto Erillisjärjestelmä kysyy palvelutapahtuman tietoja ydinjärjestelmän tarjoaman rajapinnan kautta. Erillisjärjestelmä kysyy palvelutapahtuman tietoja KanTa palvelun tarjoaman rajapinnan kautta?! Kv-standardit pohjalla, Rajapinnat toteutettu HL7 jotka on lokalisoitu ja v3 sanomina, mutta itse käyttöönotettu laajasti. käyttötapaus ja käyttötarve Ilman lokalisointia kvon paikallinen ratkaisu tuotteita ei pysty ottamaan käyttöön. 31 Integraatiotapojen vertailua Minimikontekstinhallinta (ja CCOW) Hoidon vastuun siirron sanomat Kyselysanomat / Hyödyntämispotentiaali Tarkoitettu yhteisen kontekstin synkronointiin, ei uusien tietojen välittämiseen sovellusten välillä. Käyttö ei ole kovin laajaa? Laaja kattavuus Suomen integraatiokentässä. Potilashallinnon sanomat ovat laajasti käytössä. KanTa palvelutapahtumarajapintoj en osalta toteutukset käynnissä, ei vielä tuotannossa. Käyttöönotettavuus PT-tunnus lisäys tuettuihin subjekteihin on pieni työ, vaikeampi toteuttaa toiminnallinen tuki tuettujen käyttötapausten osalta järjestelmiin. Muut huomiot Minimikontekstinhallinta edellyttää käyttäjältä aktiivisia toimia integraatio ovat osin perustuneet osapuolten välisiin sopimuksiin pointto-point integraatioissa, joten yleisratkaisun toteutuksessa voi tulla lisätarkennusten tarpeita tapauskohtaisesti. Sanomien vastaanotto ei edellytä käyttäjän toimenpiteitä. Järjestelmän sisällä ne ohjautuvat käyttäjän käsittelyyn, mutta tällöin mukana olisi tarvittavat tiedot ja niitä ei tarvitsisi kyselysanomien pohjalta täydentää. 32