Jari Porrasmaa, Marko Suhonen & Hannu Virkanen

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

2. Aiheet • Johdantoa • Alueellisia tietokäsittelymalleja Suomessa • SerAPIn taustaselvityksiä • Metatietojen läpikäynti

3. 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.?)

4. 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ä

5. 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

6. 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

7. Alueellisia tiedonkäsittelymalleja Suomessa

8. ATJ:n käyttö (HUS, PSHP, SatSHP) potilaskertomus selain (ATJ) muut sovellukset aluetietojärjestelmä viitehakemisto pyydetyt dokumentit viitteet perusjärjestelmä 1 perusjärjestelmä n alkuperäiset dokumentit . . .

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

10. "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

11. 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)

12. 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

13. 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...

14. yhdistelmäratkaisu 4. kattavat tiedot 1. onko potilastietoa? kysely 3. voi kysyä muilta 2. tietää oman alueen tiedot

15. 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...

16. Jo tehty SerAPI työ...

17. 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)

18. 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

19. IHE XDS aktorit ja transaktio lootat on aktoreita viiva + nimi = transaktio

20. 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

21. 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

22. potilaskertomus varasto/arkisto Sovelluksien roolit hyödyntäjä – potilaskertomus, erityissovellus, tms. potilaskertomus Esim. effica, pegasos, miranda, (tai taloushallinnontietojärjestelmä) HUOM! monia muita mahdollisia aktorien ryhmittelyjä

23. Pakollisuus

24. Tekniikka Kysely payload: XML message (ebRS) rajattu SQL Vastaus: ebRIM mukainen XML dokumentti siirto: SOAP + MIME HTTP, SMTP ebMS, ebRIM, ebRS, HL7 CDA, HL7 V2 (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?)

25. SQL:n rajaukset (ebRS 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>.

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

27. 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.)

28. 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/

29. Prototyyppitoteutukseen valitut viestit

30. 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

31. Käyttötapaus 1 • viitteet lähetetään rekisteriin (viitetietokantaan)

32. Käyttötapaus 2 • Kysely viitekantaan, joka reitittää eteenpäin • Vastauksena viitteet ja lisätietoja

33. Käyttötapaus 3 • Kysellään pelkät viitteet, tarkoituksena valita ennakkoon tiedot/sovellukset joihin varsinainen kysely kohdistuu

34. Käyttötapaus 4 • viitteiden tilaus, halutaan tietyn tyyppiset viitteet, aina kun näitä syntyy niin ne lähetään tilaajalle

35. UK - Spine, NHS/NPfIT

36. 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

37. 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)

38. UK - Spine, NHS/NPfIT

39. Kanada – Health Infoway • Health Information Access Layer (HIAL) • Common Services • viestienvaihto • Communication Bus • verkkoprotokolla • reititys • toimitus

40. HIAL

41. 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

42. HIALin ulkoiset palvelut • Tiedon sijaintipalvelut • Tietovaraston sijainti • hallintoalueen ID-tunnus • tietovaraston tyyppi • Potilastiedon sijainti • Potilaan ID-tunnus • tietotyyppi • aikaväli

43. 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

44. 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

45. RLAS rajapinnat • 6Detailed Functional Model for each Interface • 6.1RecordLocate • 6.2RecordRetrieve • 6.3RecordCreate • 6.4RecordUpdate • 6.5RecordNullify

46. 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ä

47. 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)

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

49. Metatiedot

50. 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