Encounter.Id.AlternateVisitId

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