Jari Porrasmaa Marko Suhonen Hannu Virkanen yhteistyss avointa

Jari Porrasmaa, Marko Suhonen & Hannu Virkanen yhteistyössä avointa hankkeen kanssa

Aiheet • • Johdantoa Alueellisia tietokäsittelymalleja Suomessa Ser. APIn 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 • HL 7 -OMG HSSP projekti • Kansallinen terveyshanke ja arkisto – tukee kansallisen hankkeen tavoitteita • HL 7 TC kokouksessa keskusteltu että Ser. API 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 Ser. APIssa? • IHE XDS selvitys • Katsaus eri maiden ja standardointijärjestöjen määrityksiin potilaskertomusvarastoista ja kyselyistä • Osallistuminen HL 7 -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, Sat. SHP) potilaskertomus selain (ATJ) aluetietojärjestelmä viitehakemisto pyydetyt dokumentit viitteet perusjärjestelmä 1 muut sovellukset . . . perusjärjestelmä n alkuperäiset dokumentit

Effica-Pegasos suorakysely Kainuussa alueellinen (tuotteen sisällä) potilaskertomus Pegasos potilaskertomus Effica alueellinen (tuotteen sisällä) muut sovellukset kysytään mitä toinen tietää potilaasta vastauksena CDA viitteitä (laajennettu) viitteen perusteella haetaan dokumentti voidaan näyttää halutulla tavalla potilaskertomuksen sisällä selaimessa tms. tietosuoja poikkeavaa erityislain perusteella

"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äratkaisu 1. onko potilastietoa? 4. kattavat tiedot kysely 3. voi kysyä muilta 2. tietää oman alueen 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 Ser. API työ. . .

Selvitykset • IHE XDS • "Kyselyrajapinnat kansallisissa arkkitehtuureissa ja dokumenttienjakoteknologioissa" – Kanada Infoway – HL 7 NLM projekti, EHR osio (USA) – UK NHS, Spine ja sen viestit – Hollanti (HL 7 Act reference viestit) – + muita dokumentissa • Tilannekatsaus HL 7 -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

Register Provide Document & Register Set, edellisen documenttransaktion set: Query registry Retrieve document Toimitetaan liipaisemana dokumentit käynnistynyt, ja niihin metatietojen liittyvät pyydetään rekisteristä halutut metatiedot Toiminnallisuus Yksi metatiedoista on URI, avulla metatiedot tietovarastoon rekisteröinti (XDSjonka submission suodatettuna halutuilla kriteereillä dokumentin voi pyytää dokumenttivarastosta dokumenttirekisteriin/hakemistoon request)

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 potilaskertomus Esim. effica, pegasos, miranda, (tai taloushallinnontietojärjestelmä) hyödyntäjä – potilaskertomus, erityissovellus, tms. HUOM! monia muita mahdollisia aktorien ryhmittelyjä

Pakollisuus

Tekniikka siirto: SOAP + MIME HTTP, SMTP Kysely payload: XML message (eb. RS) rajattu SQL Vastaus: eb. RIM mukainen XML dokumentti eb. MS, eb. RIM, eb. RS, HL 7 CDA, HL 7 V 2 (etc. . ) HTTP, SMTP, MIME Registry ja repository ei välttämättä 1: 1, joustava malli. . . (retrieve toisaalta hankala jos repository eri paikassa kuin registry? )

SQL: n rajaukset (eb. RS appendix D) D. 1 SQL Query Syntax Specification This 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"? > <Adhoc. Query. Request> <Response. Option return. Type=”Object. Ref” return. Composed. Objects=”true”/> <SQLQuery> SELECT * FROM Extrinsic. Object e WHERE e. id=’urn: uuid: fbeacdb 7 -5421 -4474 -9267 -985007 cd 8855’ </SQLQuery> </Adhoc. Query. Request>

Yhteenveto XDS? • Palikat (komponentit), niiden toiminnallisuus ja yhteistoiminnallisuus on mietitty hyvin • Registry, Repository ja Document Source aktoreiden toteuttaminen vaatii eb. XML osaamista / tuotetukea • Hyödyntää valmiita standardeja (osaan voi jo löytyä osaamista jne. )

HL 7 NLM EHR projekti • HL 7 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. hl 7. org/nlmcontract/

Prototyyppitoteutukseen valitut viestit

Hollannin "viitetietokanta" • Hollanti / HL 7 NL ZIM spesifikaatio – Healthcare information broker – Pohjautuu V 3 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/NPf. IT

UK - Spine, NHS/NPf. IT • TMS: Transaction and Messaging Spine – viestien reititin – HL 7 v 3 • PDS: Personal Demographics Services – kansallinen tietovarasto – PDS-kyselyt • • • väestötieteelliset tiedot NHS-numerot linkitykset

UK - Spine, NHS/NPf. IT • 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/NPf. IT

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

HL 7 -OMG Healthcare Services Specification projekti • Yhteistyö OMG + HL 7 • Tuotokset – palveluiden tuottaminen HL 7: ssa – lista tärkeistä palveluista – 3 -4 palvelun määrittelyt • Tuotettavat palvelurajapinnat käyttöön 2006 • Palvelurajapintojen määrittelymenetelmä ja integraatio HL 7 development frameworkkiin • Yhdenmukainen HL 7 palvelurajapinnan formaatti • Record locator and access service

HL 7 -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 HL 7 eri domainien DMIM, RMIM, tietotyypit jne. • Korkeamman tason rajapinta? (esim. Kanada) • Rajapinnat käy läpi HL 7 ja OMG prosessin

RLAS rajapinnat • 6 Detailed Functional Model for each Interface • 6. 1 Record. Locate • 6. 2 Record. Retrieve • 6. 3 Record. Create • 6. 4 Record. Update • 6. 5 Record. Nullify

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 • HL 7 yleisimmin käytetty ratkaisu tiedonsiirtoon – löytyy valmiiksi määriteltyjä ja hyödynnettyjä (? ) viestejä

Muuta yhteenvetoa • IHE XDS: arkiston kokonaisratkaisu? • HL 7: 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 • HL 7 CDA R 2 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? • Open. CDA projektissa / HL 7 TC ehdotettu Ku. Y: lle kyselyrajapintaa – tosin resurssia vähän saatavilla Open. CDA puolella – pohjustamisen jatkaminen Ser. API työnä? – osapuolten tarpeet ja painotukset?