Jari Porrasmaa,

Marko Suhonen

&

Hannu Virkanen

yhteistyössä avointa

hankkeen kanssa

Aiheet

• Johdantoa

• Alueellisia tietokäsittelymalleja Suomessa

• SerAPIn taustaselvityksiä

• Metatietojen läpikäynti

Tavoitteet työpajalle

• Osallistujille muodostuu käsitys jo tehtyjen selvitysten sisällöstä

• Pystytään hahmottamaan mitä potilaskertomustietojen kyselyrajapinnalla voidaan saada aikaiseksi

• Pohjamateriaalin perusteella luonnostellaan mitä metatietoja kyselyissä pitäisi voida käyttää

• Osapuolten mielipiteet jatkotyöskentelystä (jatketaanko? miten suunnataan jne.?)

Mikä ja miksi kyselyitä?

• Rajapinta potilaskertomustiedon löytämiseen ja hakemiseen

• HL7-OMG HSSP projekti

• Kansallinen terveyshanke ja arkisto– tukee kansallisen hankkeen tavoitteita

• HL7 TC kokouksessa keskusteltu että SerAPI voisi selvitellä kyselyitä

Onko relevantti arkiston kannalta?• Ehkä? Riippuu mikä arkisto on ja miten se määritellään...

– onko arkisto vain pysyväissäilytyksen hoitava järjestelmä vai voidaanko sen päälle tehdä aktiivisesti tietoa käsitteleviä sovelluksia?

• Alueellinen tietojenkäsittely voi myös tarvita kyselymahdollisuutta

• Kehittyykö aluetietojärjestelmiin arkistointiominaisuudet vai korvaako arkisto ATJ:n? – Ei välttämättä väliä rajapinnan kannalta

• Kaikkien alueiden osalta alueellisen tietojenkäsittelyn toimintamallia ei ole vielä ratkaistu

Mitä on jo tehty SerAPIssa?

• IHE XDS selvitys

• Katsaus eri maiden ja standardointijärjestöjen määrityksiin potilaskertomusvarastoista ja kyselyistä

• Osallistuminen HL7-OMG HSSP projektin RLAS määrityksen työstämiseen

• Ylläolevat käydään läpi

Alueellisia tiedonkäsittelymalleja Suomessa

ATJ:n käyttö (HUS, PSHP, SatSHP)

potilaskertomus selain (ATJ)

aluetietojärjestelmä

perusjärjestelmä 1 perusjärjestelmä n. . .

muut sovellukset

alkuperäiset dokumentit

pyydetyt dokumentitviitteet

viitehakemisto

Effica-Pegasos suorakysely Kainuussa

potilaskertomusPegasos

potilaskertomusEffica

alueellinen(tuotteen sisällä)

alueellinen(tuotteen sisällä)

kysytään mitä toinen tietää potilaastavastauksena CDA viitteitä (laajennettu)viitteen perusteella haetaan dokumenttidokumentti voidaan näyttää halutulla tavalla

potilaskertomuksen sisälläselaimessa tms.

tietosuoja poikkeavaa erityislain perusteella

muut sovellukset

"yhden järjestelmän malli"

• Kaapo alueen ratkaisu– 1 järjestelmä jota kaikki alueen tk:t ja sairaalat

käyttävät– järjestelmä voidaan liittää HUS

aluetietojärjestelmään (osaksi miljoonapiirin tasoista ratkaisua)

• Länsi-pohjan alueellinen Pegasos

Muut

• Lähete-hoitopalaute liikenne toimii monissa paikoissa sähköisesti

• Kansallisen terveyshankkeen CDA-lähete sallii jatkossa monipuolisemmat ja rakenteiset tietosisällöt

• Alueellisia tautikohtaisia järjestelmiä

• (ja tietenkin aiemmin mainittu arkistoratkaisu)

Alueelliset mallit - yhteenveto

• 1 malli tukee kyselyitä• perinteisen ATJ malliin kyselyt voisivat tuoda lisäarvoa

– ei erillistä järjestelmää, suora integraatio olemassa oleviin järjestelmiin (ei erillistä käyttäjähallintaa jne.)

• erilaiset "topologiat"/arkkitehtuurit– kyselyssä suora yhteys kahden välillä, entä jos osapuolia on 3

tai 30 ?

– keskitetyssä ratkaisussa vähemmän yhteyksiä jos osapuolia on paljon

hajautettu vs. keskitetty?

• hajautetussa ratkaisussa enemmän yhteys- ja tietoturvamäärityksiä/toteutuksia, toisaalta ei ATJ

• riittääkö keskitetyn palvelun suorituskyky? (toisaalta poistaa kuormaa perusjärjestelmiltä)

• jne...

yhdistelmäratkaisu1. onko potilastietoa?

kysely

2. tietää oman alueen tiedot

3. voi kysyä muilta

4. kattavat tiedot

ATJ migraatio???

• ATJ voidaan kehittää arkiston suuntaan, kun siihen lisätään oma tietovarasto ja kyselyrajapinta– hakurajapinta dokumentille on olemassa– viitteiden syöttö on myös

• + muuta toiminnallisuutta mitä tarvitaan– arkistointiin liittyvä hallinta– tietosisältöjen tarkistaminen jne.– notariaatti allekirjoitukset– yms. mitä määrityksessä onkaan...

Jo tehty SerAPI työ...

Selvitykset• IHE XDS

• "Kyselyrajapinnat kansallisissa arkkitehtuureissa ja dokumenttienjakoteknologioissa"– Kanada Infoway– HL7 NLM projekti, EHR osio (USA)– UK NHS, Spine ja sen viestit– Hollanti (HL7 Act reference viestit)– + muita dokumentissa

• Tilannekatsaus HL7-OMG HSSP projektin Record Locator Serviceen (RLAS)

IHE XDS - yleistä

• IHE Cross enterprise document sharing (IHE XDS)

• IHE integraatioprofiilit– eivät ole standardeja– määrittelevät mitä standardeja tarvitaan ja mikä on

niiden täsmällinen käyttötapa eli profilointi (jumitus)

• Kuuluu IHEn IT infrastructure technical frameworkkiin

IHE XDS aktorit ja transaktio

lootat on aktoreita

viiva + nimi = transaktio

Toiminnallisuus

Provide & Register document set:Toimitetaan dokumentit ja niihin liittyvät

metatiedot tietovarastoon (XDS submission request)

Register Document Set, edellisen transaktion liipaisemana käynnistynyt, metatietojen

rekisteröinti dokumenttirekisteriin/hakemistoon

Query registrypyydetään rekisteristä halutut metatiedot

suodatettuna halutuilla kriteereillä

Retrieve documentYksi metatiedoista on URI, jonka avulla

dokumentin voi pyytää dokumenttivarastosta

IHE XDS käsitteet• XDS Document, tallennettava dokumentti• XDS Document Entry, metatiedot ja viittaus

dokumenttiin• XDS Folder, hakemistorakenne XDS document entryjen

ryhmittelyyn– esim. hoitojakso, erikoisala, henkilön koko potilaskertomus.

Yksi Document Entry voi kuulua useampaan XDS Folderiin.

• XDS Submission dokumenttivarasto Set, tallennettavat dokumentit, niiden metatiedot, hakemistorakenteet ja suhteet aiempiin dokumentteihin

• XDS Submission Request, submission setin rekisteröinti

Sovelluksien roolit

potilaskertomus varasto/arkisto

potilaskertomusEsim. effica, pegasos, miranda,(tai taloushallinnontietojärjestelmä)

hyödyntäjä – potilaskertomus,erityissovellus, tms.

HUOM! monia muita mahdollisia aktorien

ryhmittelyjä

Pakollisuus

Tekniikka

Kysely payload: XML message (ebRS) rajattu SQLVastaus: ebRIM mukainen XML dokumentti

HTTP, SMTP, MIME

ebMS, ebRIM, ebRS, HL7 CDA, HL7 V2 (etc..)

siirto: SOAP + MIME

HTTP, SMTP

Registry ja repository ei välttämättä 1:1, joustava malli...

(retrieve toisaalta hankala jos repository eri paikassa kuin registry?)

SQL:n rajaukset (ebRS appendix D)D.1 SQL Query Syntax SpecificationThis section specifies the rules that define the SQL Query syntax as a subset of SQL-92. The

terms enclosed in angle brackets are defined in [SQL] or in [SQL/PSM]. The SQL query syntaxconforms to the <query specification>, modulo the restrictions identified below:

1. A <select list> may contain at most one <select sublist>.2. In a <select list> must be is a single column whose data type is UUID, from the table in the

<from clause>.3. A <derived column> may not have an <as clause>.4. <table expression> does not contain the optional <group by clause> and <having

clause>clauses.5. A <table reference> can only consist of <table name> and <correlation name>.6. A <table reference> does not have the optional AS between <table name> and<correlation name>.7. There can only be one <table reference> in the <from clause>.8. Restricted use of sub-queries is allowed by the syntax as follows. The <in predicate> allows

for the right hand side of the <in predicate> to be limited to a restricted <query specification> as defined above.

9. A <search condition> within the <where clause> may not include a <query expression>.10. Simple joins are allowed only if they are based on indexed columns within the

relationalschema.11. The SQL query syntax allows for the use of <sql invoked routines> invocation from[SQL/PSM] as the RHS of the <in predicate>.

Kysely

<?xml version="1.0"?> <AdhocQueryRequest><ResponseOption returnType=”ObjectRef” returnComposedObjects=”true”/><SQLQuery>SELECT *FROM ExtrinsicObject eWHERE e.id=’urn:uuid:fbeacdb7-5421-4474-9267-985007cd8855’

</SQLQuery></AdhocQueryRequest>

Yhteenveto XDS?

• Palikat (komponentit), niiden toiminnallisuus ja yhteistoiminnallisuus on mietitty hyvin

• Registry, Repository ja Document Source aktoreiden toteuttaminen vaatii ebXML osaamista / tuotetukea

• Hyödyntää valmiita standardeja (osaan voi jo löytyä osaamista jne.)

HL7 NLM EHR projekti

• HL7 ja NLM yhteistyöprojekti– projekti keskittyy koodistoihin/sanastoihin ja

sähköiseen potilaskertomukseen– sähköisen potilaskertomuksen osalta tavoitteena

määritellä kyselyviestit tietosisältöjen vaihtoa varten (sisältö CDA dokumentteja)

• Projektin 1. vaihe on päättynyt, syventävä vaihe on käynnistymässä

• http://www.hl7.org/nlmcontract/

Prototyyppitoteutukseen valitut viestit

asiakas palvelin

QUMT_IN020010

Hakuehdot dokumenteille

QUMT_IN020020

Lista dokumenteista (metatietoa)

RCMR_IN000030T

Dokumenttihaku (tunniste)

RCMR_IN000031T

Dokumentti

Hollannin "viitetietokanta"

• Hollanti / HL7 NL ZIM spesifikaatio– Healthcare information broker– Pohjautuu V3 viestintään

• 4 käyttötapausta• Hollannin määrittely muistuttaa suomalaista

aluetietojärjestelmä ratkaisua viitteiden osalta– erona kyselyrajapinta

Käyttötapaus 1

• viitteet lähetetään rekisteriin (viitetietokantaan)

Käyttötapaus 2

• Kysely viitekantaan, joka reitittää eteenpäin

• Vastauksena viitteet ja lisätietoja

Käyttötapaus 3

• Kysellään pelkät viitteet, tarkoituksena valita ennakkoon tiedot/sovellukset joihin varsinainen kysely kohdistuu

Käyttötapaus 4

• viitteiden tilaus, halutaan tietyn tyyppiset viitteet, aina kun näitä syntyy niin ne lähetään tilaajalle

UK - Spine, NHS/NPfIT

UK - Spine, NHS/NPfIT• TMS: Transaction and Messaging Spine

– viestien reititin– HL7 v3

• PDS: Personal Demographics Services– kansallinen tietovarasto– PDS-kyselyt

• väestötieteelliset tiedot

• NHS-numerot

• linkitykset

UK - Spine, NHS/NPfIT• NCR: National Care Record

– Yhteenveto tiedoista– NCR hakee myös muista järjestelmistä

• PSIS-kyselyt• Event List Query - pyytää listan tapahtumista ("viitteet", pyynnössä

voidaan jo rajata, esim. lähetteet)

• Event Query - tieto pyydetään yhdestä määritellystä tapahtumasta, joka on vastaanotettu toisessa kyselyssä (palauttaa koko tietosisällön)

• CRE Query - tieto pyydetään käyttämällä yhtä tai useampaa Care Record Element -tyyppiä (suodattaa tietosisältöä otsikkotasolla, päivämäärät jne.)

• PSIS Clinical Statement Query (tietosisällön suodattaminen "ydintietojen" mukaan)

• PSIS DPA Subject Access Query (anna kaikki tiedot, vaatii erillisen vahvistuksen ja tietosuojavarmistukset)

UK - Spine, NHS/NPfIT

Kanada – Health Infoway

• Health Information Access Layer (HIAL)

– Common Services • viestienvaihto

– Communication Bus • verkkoprotokolla

• reititys

• toimitus

HIAL

Kanada

• Enterprise Master Person Index (EMPI) – potilasrekisteri

• tiedon tunnistaminen ja haut useista järjestelmistä

• Tietovarastot– säilyttävät ja tarjoavat pääsyn tietoon

• Rekisterit (potilas-, -palveluntarjoaja, -sijainti)

– vastaavat tiedonhakuun parametrien perusteella

HIALin ulkoiset palvelut

• Tiedon sijaintipalvelut – Tietovaraston sijainti

• hallintoalueen ID-tunnus

• tietovaraston tyyppi

– Potilastiedon sijainti• Potilaan ID-tunnus

• tietotyyppi

• aikaväli

HL7-OMG Healthcare Services Specification projekti

• Yhteistyö OMG + HL7• Tuotokset

– palveluiden tuottaminen HL7:ssa– lista tärkeistä palveluista– 3-4 palvelun määrittelyt

• Tuotettavat palvelurajapinnat käyttöön 2006• Palvelurajapintojen määrittelymenetelmä ja

integraatio HL7 development frameworkkiin• Yhdenmukainen HL7 palvelurajapinnan formaatti• Record locator and access service

HL7-OMG RLAS palvelun toiminnallisuus

• Dokumenttien päivitys, löytäminen ja hakeminen

• samankaltainen kuin viestiratkaisut, erona on pohjautuminen teollisuusstandardeihin työkaluihin (web services?)

• mikä on suhde viestintään? tätä kovasti mietitään?

• Palvelut - suhde HL7 eri domainien DMIM, RMIM, tietotyypit jne.

• Korkeamman tason rajapinta? (esim. Kanada)

• Rajapinnat käy läpi HL7 ja OMG prosessin

RLAS rajapinnat

• 6Detailed Functional Model for each Interface

• 6.1 RecordLocate

• 6.2 RecordRetrieve

• 6.3 RecordCreate

• 6.4 RecordUpdate

• 6.5 RecordNullify

Yhteenveto ulkomaisista toteutuksista / määrityksistä

• EHR tarvitsee tukipalveluita/infrastruktuuria– potilaiden tiedot ja niiden hallinta, tunnisteet– organisaatiot / lääkärit ja näiden hallinta– viestinvälityskeskus

• Kesken tuntuu olevan....• Riippumatta onko 1 tietovarasto (fyysinen/virtuaalinen) vai

hajautettu ratkaisumalli– tietojen sijainnin ja hakemisen päättelyyn on jonkin sortin rajapinta...

• Palvelupohjainen ajattelumalli on havaittavissa useimmissa arkkitehtuureissa

• HL7 yleisimmin käytetty ratkaisu tiedonsiirtoon– löytyy valmiiksi määriteltyjä ja hyödynnettyjä (?) viestejä

Muuta yhteenvetoa

• IHE XDS: arkiston kokonaisratkaisu?

• HL7: kyselypuoli kunnossa (moneen kertaan), syöttöpuolen pohdintaa ei tullut vastaan

• Kaikissa malleissa kyselyrajapinta - Suomeenkin tarvitaan

• Käykö joku ulkomaanmalli suoraan??– huomioitava Suomessa jo tehty työ ja kansalliset

tarpeet

• Kaikissa määriteltynä metatiedot (tai sitten ei)

Kysymys pohdittavaksi?

• Kyselyiden hierarkiataso, sisältö vai kuvailutiedot??– "tapahtuman tiedot" (metatietotaso)– karkean tason sisältöhaku (otsikkotaso)– yksityiskohtainen sisältöhaku

Metatiedot

Etenemispolku ja käynnissä oleva työ

• Kansallinen arkkitehtuuri?

• Viranomaismääritykset - lausunnot, seminaarit ja konsensuskokous.

• Arkistoinnin metatiedot

• Potilaskertomusarkiston aktiivihyödyntäminen– Potilasasiakirjan sisältö– Käyttötapaukset - STM:n rahoittamat hankkeet

Valmiit mallit

• IHE XDS

• HL7 CDA R2 FI header

• Hollanti (lopullinen metatietojoukko työnalla)

• Mitkä tiedot näistä ovat suomalaisten käyttötapausten kannalta oleellisimpia?

• Word dokumentti tietojenvertailusta

Jatkotyö

?

• Mitä selvitellään jatkossa vai selvitelläänkö yhtään mitään?

• OpenCDA projektissa / HL7 TC ehdotettu KuY:lle kyselyrajapintaa– tosin resurssia vähän saatavilla OpenCDA puolella– pohjustamisen jatkaminen SerAPI työnä?– osapuolten tarpeet ja painotukset?