search

suomi / potilastietojarjestelma

55 stars 7 forks source link

Mitkä olisivat parhaat alustat järjestelmän kehitykseen? #1

Open d2s opened 11 years ago

d2s commented 11 years ago

Käyttöliittymän alustava vaatimusmäärittely olisi todennäköisesti näppärää toteuttaa ketterillä menetelmillä ja nopeasti muokattavilla web-pohjaisilla tekniikoilla. Tähän threadiin voisi koota ideoita siitä että millä välineillä loppukäyttäjien näkemää palvelua voisi tehokkaimmin alkaa luomaan.

Myös backend-puolen vaihtoehdoista olisi hyvä kuulla. Tarvetta on todennäköisesti valtavalle määrälle datan tallennusta joten perinteisten relaatiotietokantojen lisäksi voisi harkita sekä NoSQL https://en.wikipedia.org/wiki/NoSQL että Graph database https://en.wikipedia.org/wiki/Graph_database tyyppisiä välineitä tietojen varastointiin.

Koska olemassaolevia tietovarantoja pitää siirtää tai muuten yhdistää uusiin järjestelmiin, tarvitaan erilaisia siirtotyökaluja tietomassojen käyttöönottoon. Esimerkit olisivat kultaakin arvokkaampia.

Plussapisteitä esimerkeistä eri projekteista joissa on hyödynnetty avointa lähdekoodia osana terveydenhuollon työkaluja.

jhul commented 11 years ago

@d2s @ztane @kakoni Kyllä. Lääkinnälliseksi laitteeksi lasketaan kaikki sellaiset järjestelmät sekä niiden osat, jotka vaikuttavat potilaan hoitoon.

Mikäli olette tässä millään muotoa nyt tosissanne, niin unohtakaa toistaiseksi kaikki spesifiset tekniikat. Ei niillä ole mitään merkitystä asian suhteen tässä vaiheessa. Näkisin, että tällä projektilla on aivan oikeaa arvoa mikäli se pystyy tarjoamaan ensisijaisesti jonkinlaisen speksin potilastietojärjestelmän kehittämisen vaatiman projektin mittaluokasta ja laajuudesta. Tekninen toteutus on oma luku sinänsä.

Haluaisin myös vinkata, että dokumentit tuohon HUSin toteuttamaan järjestelmäkartoitukseen ovat julkisia, jos joku muukin on kiinnostunut erilaisista ominaisuuksista joita olemassaolevat potilastietojärjestelmät pyrkivät toteuttamaan. :)

raphendyr commented 11 years ago

Olittekin keränny hemmetin hyviä ideoita ja oikeestaan kaiken olellisen mitä mä ajattelin.

Nää olis lähinnä arkkitehtuurillisia huomioita. Vois yrittää abstractoida objektien välitys, taltiointi, offline/cache tila yms. omaksi lohkoksi, jolloin jatkossa on helpompi tuoda lisää ominaisuuksia valmiin pohjan päälle. En tiedä, mutta Cephfs projektista voi olla hyviä lähtöideoita, vaikka se onkin filesysteemi.

Lisäksi käyttöliittymistä voisi tehdä melkein oman osion/projektin. Käyttöliittymää on varmaan nopein ensiksi kehittää web pohjaisena, mutta lopullisessa se ei tule tukemaan verkkokatkoja.

Haluaisin myös löytää tavan, jolla akulliset laitteet (Tabletit) voisivat vaihtaa tietoa suoraan keskenään. Esimerkiksi tilanteessa että sairaalan oma wlan/verkko on jostain kumman syystä rikki. Olisi kätevää että röntken kuvat saisi röntken laitteesta tablettiin. Myös NFC ja RFID tekniikoiden hyödyntämistä voisi siellä osin miettiä. Tästä kannattanee varmaan tehdä taas oma kokonaisuus / lohko. Täten tätä voi myös soveltaa esimerkiksi tehdasautomaatioon, poliiseihin, kelaan yms kaikeen.

Mielestäni voisi myös valmiiden tietokantojen lisäksi tutkia itstekemistä. En tiedä tukeeko mikään valmis tiedon hajauttamista niin että osa objekteista on toisaalla (tosin aina kahdennettuna). Ks. cephfs. Oletettavasti on myös tarpeita joissa tulee louhia tietoa koko potilaskannasta.

Lisäksi kaikki potilastiedon salaus luo ongelmallisuutta keskitettyyn kantaan.

Viimeisenä huomiona tietoturva niin sähköinen kuin fyysinen. Olisi hyvä ettei kaikki potilastiedoista olisi ikinä yhdessä paikkaa. Jos ko. lokaatioon joku pääsee murtautumaan on hänellä helposti pääsy koko potilas kantaan. Tähän voisi olla ilona jokaisen objektin kryptaus niin ettei samalla avaimella saa kaikkia auki. Täten potilas pystyis jo teknisesti periaatteessa estämään väärien lääkärien pääsyn hänen tietoihinsa.

Pahoittelen hyvin hajonaista ajatuksen juoksua, toivottavasti fiksummat saavat tästä jotain irti.

raphendyr commented 11 years ago

Yks käyttötilanne, joka on hyvä huomioida. (Huomaa tabletti ei ole lääke vaan esim iPad/Galaxy Tab)

Ambulanssissa potilaasta kirjataan tietoja ylös. Nämä tiedot pitää sitten sairaalassa välittää (nykyisin kaiketi paperilla) vastaanottohenkilökunnalle. Tähän olisi it-ratkaisu taas kerran tabletit. Potilaan tiedot tulisi kulkeutua potilaan mukana, mutta niin että tiedo kulkeutuu laitteesta toiseen, jotta ambulanssisa ei tarvitse olla äärettömästi tabletteja. Potilaan henkilötietoja ei välttämättä tiedetä ambulanssissa joten anonyymit potilaat tulee olla mahdollisia, ja tietojen yhdistäminen rekisterissä olevaan potilaaseen jälkeenpäin.

Kyseinen datan siirtymiseen voisi toimia rfid/nfc/wlan tyyppiset ratkaisut ja hätätilassa myös 3g. Toki ambulanssissa tablettiin voitaisiin hakea potilaan lääketiedot cloudista 3g:n yli, jos potilaan henkilötiedot tiedetään.

Tää voi olla liian yksityiskohtasta, mutta mielestäni tämäkin on oleellinen käyttökohteen tuoma vaikutus kokonaisratkasuun.

Voisin myös kuvitella oikean ratkaisun rakentuvan cloud tyyppisestä ratkaisusta, joka käyttää paljon hyväkseen hajauttamista. Eli voidaan tehdä keskitettyjä hakuja, mutta cloudin ei pidä olla toiminnan vaatimus. Ei aikoinaankaan potilastietoja saanut haettua verkon yli :D

tparvi commented 11 years ago

Mielenkiintoista luettavaa. Muutama oma huomio

Avoimuus

Avoimet standardeihin perustuvat rajapinnat (esim. HTTP + JSON sopii moneen) ovat ehdoton vaatimus. Sen sijaan en laskisi niin suurta painoarvoa esim. käyttöjärjestelmän tai jonkun frameworkin (.NET, Java) 100% avoimuudelle. Ei siellä projektissa kukaan ole korjaamassa frameworkin bugeja eikä vuosien päästä kukaan totea Olipa hyvä kun meillä on tämä miljoona riviä avointa koodia frameworkista X niin tämän asian korjaus hoitui helposti.

Itse käsitän avoimuuden projektin edun kannalta siten että kukaan yksittäinen toimija ei pysty luodamaan suljetuilla rajapinnoilla ja omilla proprietary tuotteillaan järjestelmää/järjestelmän osaa joka lukitsee asiakkaan ikuisiksi ajoiksi tuohon toimittajaan.

Mitä tulee MS-puolen avoimuuteen niin .NET on ihan standardoitua kamaa. Siihenhän perustuu se että Monon avulla voidaan tehdä .NET -koodia usealle alustalle. Lisäksi iso osa itse .NET:n sorsista on saatavilla ja moni isompi palikka löytyy ihan oikeana avoimena koodina täältä githubista. Esimerkkinä vaikka Azure ja ASP.NET MVC.

Huvittavaa on myös se että juuri monon kautta .NET on se jolla samaa C# koodia voi käyttää webissä, palvelinpäässä, desktopissa (windows, linux, mac), puhelimissa (iOS, android, windows phone) ja tableteissa (iPad, tulevat windows tabletit).

Teknologia

Koska järjestelmä koostuu hyvin monesta palasta tuskin voidaan sanoa että 100% kaikki pitää tehdä teknologialla X. Avointen rajapintojen (ja avoimen koodin) etuhan on siinä että jos neljätoista järjestelmää kolmesta sadasta on huonoja niin ne voidaan korvata jonkun toisen firman tekemillä tuotteilla.

Jos olisin asiakas niin rajoittaisin teknologiat kuitenkin sellaisiin jotka ovat kypsiä ja joille suomesta löytyy paljon osaajia ja voidaan katsoa että sama trendi jatkuu. Muuten asiakkaana ollaan samassa tilanteessa jossa lukitaan itsemme kouralliseen toimittajia koska teknologia-alusta on sellainen että kovin moni firma ei sitä hallitse. Tässä mielessä esim. PHP (vaikka siitä ei itse henkilökohtaisesti pitäisikään) olisi ihan validi ratkaisu. Palvelinpäässä vaihtoehdot ovat sitten .NET/Java. Joku voi varmasti tehdä C++:lla, pythonilla, haskelilla tai vaikka millä mutta edelleen niitä firmoja on hyvin vähän. .NET/Java-puolella osaajia riittää, tuottavuus, integroinnin helppous muihin järjestelmiin on hyvä jne.

Tiedon tallennus

Paljon on keskusteltu tiedon replikoinnista, synkkauksesta, mahdollisista konflikteista jne. Ihan lonkalta voisin heittää niinkin hullun heiton että teknisessä mielessä potilastietoja harvemmin muutetaan. Kaikki muutokset ovat yleensä lisäyksiä. Jos lääkitystä/annostelua muutetaan niin teknisesti kyseessä on lisäys potilaan historia tms. tietoihin. Tai jos otetaan uusi verinäyte niin ei se korvaa aiempia tietoja. Tuo yksinkertaistaa kaikenlaista replikointia yms. aika paljon koska konfliktien määrä on hyvin rajallinen.

Tiedon saatavuus

Tiedon saatavuuden varmistaminen (esim. verkkokatko) kannattaa miettiä siten että keskitytään siihen käyttötapaukseen. Riippuen käyttötapauksesta vaatimukset voivat olla ihan erillaiset. Esimerkiksi vaikka ajanvaraus. Jos verkkoyhteys on poikki ulkomaailmaan niin sen ei pitäisi estää ajanvarauksen toimintaa paikallisessa laitoksessa. Näissä tullaan yleensä siihen että kuinka todennäköinen tapahtuma on kyseessä / mitä siihen varautuminen maksaa.

jrutila commented 11 years ago

Pakko osallistua keskusteluun, on sen verran kuumottavaa. Ajatuksiani seuraavassa liittyen nimenomaan potilasdataan.

NoSQL vs SQL

Mielenkiintoisen potilastietojärjestelmästä tekee se, että potilaan dataa ei juuri koskaan tarvitse linkata kenenkään muun potilaan dataan. Eli aina kun järjestelmä "avataan", tutkitaan yhden henkilön tietoja. Tällöin jonkinlainen dokumenttitietokanta kuulostaa järkevältä, jossa potilasdata on avain-arvo -muodossa.

Tietojen synkronoinnista

Potilas on yleensä vain yhdessä paikassa tietyllä ajanhetkellä. Potilasdataan tehtävät muutokset ovat yksittäisiä muutoksia (lääkemääräys, todettu sairaus tms.). Jokainen tällainen muutos voisi olla oma atominen aikaleimattu tapahtumansa. Näistä tapahtumista voitaisiin aina kasata potilaan tämähetkiset tiedot. Samalla syntyy audit trail (kirjoituksen suhteen).

Näitä tapahtumia voitaisiin sitten synkronoida ja lähetellä jokaiselle järjestelmän palvelimelle, jossa niistä muodostettaisiin lokaalit kopiot potilastiedoista.

Tietojen salaus

Tapahtumat (eli atomiset muutokset dataan) voisi olla salattu jollain "yleisavaimella", jonka eri palvelimet tietäisivät. Eli data liikkuisi palvelimelta toiselle ja avattaisiin avaimella. Henkilökohtainen pääsy (eli kuka saa lukea ja mitä) taas tarkastettaisiin kirjautumalla lokaalille palvelimelle. Jos potilastietoja hakisi "ulos" lokaalilta palvelimelta, salattaisiin ne käyttäjän henkilökohtaisella avaimella, jolloin tieto olisi esim. lääkärin tabletissa, mutta kuitenkin salattuna ja vain lääkärin käytössä.

pepez commented 11 years ago

Koska kukaan ei vielä maininnut, niin Hadoon & HBase voisi olla hyvä varastointiin. Replikoitu data ja versiointi valmiina.

jrutila commented 11 years ago

@pepez Eikös Hadoop ole Big Datan varastointiin? Missä potilastietojärjestelmissä on Big Dataa?

pepez commented 11 years ago

Big Datan yhteydeydessä se on useasti mainittu, mutta muitakin käyttökohteita sille löytyy. HBase on siis Hadoopin päälle rakennettu tietokanta. Potilastietojärjestelmässä tärkeää dataa on paljon, joten Hadoop&HBasen skaalautuvuus ja varmuus tulevat avuksi.

kakoni commented 11 years ago

Quorassa oli aikoinaan mainiota keskustelua noista EMR/EHR järjestelmän vaatimuksista (http://www.quora.com/Jae-Won-Joh/Posts/How-to-build-a-good-EMR-part-1). Listaampa ne tähän

1) Build for the web 2) Build for iPad 3) Design for a 5-year-old 4) Design for a single small screen 5) Dream big 6) Leave things open-ended 7) Multiple uses

Mitä tarvitaan onnistuneeseen tiimin(tietoteknisen henkilöstön lisäksi siis); http://www.quora.com/Jae-Won-Joh/Posts/How-to-build-a-good-EMR-part-2 1) Designer 2) Marketing person 3) M.D

Järjestelmän workflowt http://www.quora.com/Jae-Won-Joh/Posts/How-to-build-a-good-EMR-part-3

1) Learning about each patient 2) Data collection/interpretation 3) Writing notes 4) Orders

Security http://www.quora.com/Jae-Won-Joh/Posts/How-to-build-a-good-EMR-part-4

Toimintoja/UI-elementtejä http://www.quora.com/Jae-Won-Joh/Posts/How-to-build-a-good-EMR-part-5

ghost commented 11 years ago

Arkkitehtuurin haarukointiin lienee olisi tarpeen hahmotella vähän niitä käyttäjämääriä ja käyttötilanteita - vai löytyikö ne jo jostakin linkista? @jhul mainitsi että HUSin vertailu on julkinen, joko joku sen linkkasi vai pitääkö sen saamiseen nähdä enemmänkin vaivaa?

Jotensakin tietomassa vaatinee oikeasti sitä että katselee jotain massojen hallinnan esimerkkejä - eliniässä tehtyjen lääkärikäyntien ja huomioiden tallenteleminen ja jakaminen mahdollisesti soveltuvin osin sekä julkisen että yksityisen sektorin kesken ohjaa varmasti tälläisen tekemistä. Ja menisin melkein olettamaan, että jotain linkkejä potilaiden välilläkin on, niin ei aina kyseltäisi joka kaavakkeessa erikseen sitä äidin ja sisarusten sydän- ja sokeritautiprofiilia.

Myös varmasti vaikuttaa moneenkin juttuun on tarve toimia paikallisesti (kaikki terveyskeskukset ei kerralla nurin) ja silti saada tietoja käyttöön keskitetysti. Ja olisi kiva jos voisi tunnistaa mikä palanen pitäisi ensin saada korvattua - vaatinee kuitenkin hieman enempi sitä sovellusalueymmärrystä sairaanhoitosekmentiltä. Ja noita sairaanhoidon erikoisaloja tuppaa kuulemaan aina kun johonkin vähänkin tähän viittaavaan järjestelmään koskee. Onhan se eri asia laittaa muistiin tietoja lastensuojelussa vs. terveyskeskuksessa, ja pohjalla kuitenkin on tilanne jossa näillä jo on jossain määrin jaettua järjestelmää.

jsalonen commented 11 years ago

@ztane Huomasin vasta nyt, miten erinomainen tuo linkittämäsi dokumentti "Opas sähköisen potilaskertomuksen rakenteesta versio 2.00" itse asiassa on. Se kuvaa jo nyt todella kattavasti aihepiiriin liittyviä vaatimuksia sekä standardeja. Esimerkiksi tietoturvan osalta selkeitä vaatimuksia on kuvattu luvussa 8 (s. 36):

ztane commented 11 years ago

Huomauttaisin että Epic ei siis ole pelkästään sähköinen potilaskertomus, se on myös käytännössä kokonainen sairaalan toiminnanohjausjärjestelmä.

Mazku commented 11 years ago

Javan osalta EJB-teknologia (Enterprise JavaBeans) mahdollistaisi hyvän hajauttamistuen ja helpon transaktiokontrollin back end -tasolle. Useampia avoimia sovelluspalvelinvaihtoehtoja myös löytyy, joilla EJB-sovelluksia voidaan pyörittää. Olettaisin että tämä järjestelmä tulisi kasvamaan niin suureksi, että hajauttaminen on välttämätöntä ja EJB:n käytön viemä suorituskykymenetys tulee vastaan teknologialla kuin teknologialla.

MikkoPaltamaa commented 11 years ago

Kuten @ztane edellä sanoi, niin kyseessä on toiminnanohjausjärjestelmä. Eri sairaaloilla ja eri osastoilla on hyvinkin erilaiset prosessit. Ei pelkästään huvikseen, vaan han jo siksikin, että eri sairauksia hoidetaan eri tavalla. Tämän takia ei kannata yrittää pakottaa kaikille yhtä prosessia tai toteuttaa kaikkia mahdollisia prosesseja. Sen sijaan prosessien pitäisi olla määriteltävissä hyvinkin joustavasti tapauskohtaisesti. Siinä on aika kiinnostava suunnitteluhaaste.

Minusta tämä johtaa arkkitehtuurissa ja teknologiavalinnoissa siihen, että eri tyyliset asiat täytyy pystyä hajauttamaan eri osajärjestelmiin, jotka toimivat sulavasti yhdessä. Pelkkä hajautus ei luullakseni riitä, koska osajärjestelmät eivät ole samanlaisia, eikä niillä kaikilla kannata olla tietoa koko prosessista. Luultavasti tämä pitäisi toteuttaa yhden "hubijärjestelmän" kautta, jolla on päävastuu määritellyistä prosesseista ja eri järjestelmien yhteistoiminnasta. Tämä hubi voisi vastata myös siitä, että eri osajärjestelmät saavat sen kautta tarvitsemansa tiedot yhteisellä rajapinnalla, mikä helpottaisi integrointeja huomattavasti.

Jos olen oikeassa, niin homma pitäisi aloittaa tämän "hubin" määrittelemisellä arkkitehtuurimielessä ja tarkentaa siitä tärkeimpiin osajärjestelmiin ja rajapintoihin.

Alustan miettiminen on minusta pelkkä mielipidekysymys ennen kuin tiedämme itse järjestelmän rakenteesta enemmän. Parhaimmillaan eri osajärjestelmien alustalla ei ole kokonaisuuden kannalta mitään väliä, vaan ne keskustelevat avoimien rajapintojen kautta. Eli kuka vaan voisi toteuttaa minkä vaan osajärjestelmän sellaisella alustalla, jonka hallitsee hyvin.

d2s commented 11 years ago

Samaa mieltä rajapintakeskeisyydestä. Allaoleva tekniikka on oltava vaihdettavissa uudempaan ilman tarvetta rikkoa yhteensopivuutta muiden kokonaisuuteen liitettyjen palasten kanssa. Kokonaisuus on enemmän kuin osiensa summa, joten olisi tärkeää että asiaa olisi mietitty sairaanhoidon kokonaisuuden kannalta niin pienen potilaan, erilaisten lääkärien ja hoitotyötä tekevien kuin myös järjestelmiä ylläpitävien kannalta.

Pääasia että homma toimii kokonaisuutena ilman että vääränlaiset rajoitteet tuottaisivat ongelmia jokapäiväiselle työlle.

keskival commented 11 years ago

Wheeet! Peli seis! Täällä tuntuu olevan nyt menossa joku outo bordelli, jossa määritellään jotain yksinkertaisia web sovelluksia. Tällaisestahan tässä projektissa ei ole alkuunkaan kyse. Tietokannat on jo olemassa, suurelta osin, eikä näihin tietentahtoen haluta koskea. Luonteeltaan tämä on pääasiassa integraatioprojekti.

Tottakai käyttöliittymät ja muut aspektit tulevat osina mukaan tietyissä osaprojekteissa, mutta näiden määrittely on tarjousten tekijöiden vastuulla. Jos open source yhteisö haluaa osallistua jonkun osajärjestelmän toteuttamiseen mukaan, on tämä hyvä jollain tavalla mahdollistaa. Itse näkisin, että tässä asiassa voitaisiin tehdä ensimmäisiä askeleita tähän suuntaan nimen omaan sillä tavalla, että ohjelmistotalojen pitää toteuttaa projekti läpinäkyvästi, julkisissa ja avoimissa repositoryissä siten, että open source yhteisö voi osallistua bugien ja laatuongelmien löytämiseen ja korjaukseen.

En usko, että se on millään tasolla realistista, että open sourcena, ilmaiseksi, tehtäisiin joku tämän kokoluokan ratkaisu, etenkin kun open source communityn engagementista ei ole vielä edes alustavaa kokemusta valtion projekteissa. PHP, NoSQL, whatever, keskustelu on siis täysin epärelevanttia. Tärkeämpää on keskustella siitä miten nämä tarjouspyynnöt täytyy muotoilla, ja mitä niissä pitää ottaa huomioon.

Open source voidaan, ja pitää ottaa aspektina mukaan tähän, mutta toteutusalustojen valinta on tarjoajien vastuulla.

raphendyr commented 11 years ago

Tässä vaiheessa kaikki ovat kaiketi ymmärtäneet ettei ongelma ole triviaali. Itselleni on ainakin tullut kuva että ainakin kahden laisia järjestelmiä on.

  1. Hakukanta. Esim. kanta jossa on tyypilliset ja haettavat tiedot on (veri ryhmä, sukulaiset, merkittävät sairaudet, merkittävät lääkitykset) mm. ambulanssi henkilökunnan käyttöön ja vastaanotoille. Tähän voi soveltaa cloudia hyvin.
  2. Dokumentti järjestelmä. Esim. potilaskertomukset, jotka ovat salaisia (jopa toisille lääkäreille, jos lupaa ei ole annettu). Tähän voi soveltaa hajauttamista ja kryptaamista.

Lisäksi on paljon muita joista en osaa sanoa mitään, kuten sairaalan toiminnanohjausjärjestelmä, laskutus, ajan varaus, tilojen varaus (tosin taitavat kuulua siihen toiminnanohjaukseen). Kaikki nämä eri toimenkuvat olisi hyvä kirjata repoon, jossa niitä voidaan sitten laajentaa. Nämä ovat hyviä pohjia moduloinnille. Lisäksi yhteneviä pohjaratkaisuja voidaan täten etsiä.

Esimerkiksi voi olla fiksua suunnitella geneerinen hakukanta, joka voi olla kaikkialta saatavilla (esimerkki 1.) tai vain yhden sairaalan (varausjärjestelmä) ja sitten rakentaa sen päälle itse osajärjestelmä/moduuli.

Mielestäni on hyvä alkaa rakentamaan hyvää kokonaiskuvaa siitä millainen tämän järjestelmän tulisi olla. Yksityiskohdat eivät ole vielä niin oleellisia, mutta niillä pääsee hyvin ideoinnissa vauhtiin (ks. tämä issue).

Tämän kokonaiskuvan pohjalta voimme ensiksi rakentaa halutun integraatio projektin, jos se tosiaan on se mitä halutaan. Jos integraatio tarkoittaa, että kaikki käyttävät samaa ohjelmaikkunaa, niin ei hyvä. Oletan että nykyisin hallinto ei esimerkiksi voi käyttää hyväksi ajanvaraus järjestelmää ja tämä on tarkoitus korvata. Voimme siis alkaa toteuttaa saadusta kokonaisratkaisusta integraatio osan ja sitten myöhemmin vaihtaa tietokanta ja tiedostojen tallennus ja välitys ratkaisuja.

Tälläisillä osatoteutuksilla saataisiin nyt heti (1 vuosi) se oleellinen asia korjattua eli ohjelmistojen toimiminen yhteen ja sitten muutamassa vuodessa päästään tehostamaan sairaalan toimintaa ennennäkemättömän hyvällä sairaalajärjestelmällä.

jsalonen commented 11 years ago

@keskival puhuu asiaa. Tietokantojen, web ui:n ynnä muun ideointi on hauskaa pyörittelyä ja hyvä tapa purkaa ensi-intoa aiheesta. Asian oikean edistämisen kannalta nyt olisi hyvä aika kuitenkin siirtyä pohtimaan kokonaisuutta ja sitä minkälaisilla projektikokonaisuuksilla päästäisiin ideoinnista todellisiin toteutusehdotuksiin.

keskival commented 11 years ago

Itsehän tykkään cloud-ratkaisuista vaikka miten paljon, mutta nyt en pysty voimakkaitten sidonnaisuuksieni takia kirjoittamaan mitään virallista aiheesta.

keskival commented 11 years ago

Siitä saisi liikaa Accenture-tyylisiä otsikoita keltaiseen lehdistöön taas.

ztane commented 11 years ago

Mun mielestä tässä pelissä on nyt vaarallista se että aletaan tosiaan rupelihattuileen näitä php-räpellyksiä ja tekemään EPIC/Accenture-integraation vastustamista naurunalaiseksi. Toisaalta tällaiset "maltilliset EPIC/Accenture-vastustajat" jotka sanovat että "on 10 suomalaista yritystä jolta voidaan tilata tällainen järjestelmä", ovat yhtä vaarallisia järkevän ratkaisun kannalta.

vsalomaki commented 11 years ago

Tässä issuessa on ollut hieman off-topicciakin mukana, mutta lisätään nyt vielä pari sanaa;

Datan synkronointi ja partitioinnista.

Kuten edellä mainittiin, niin järjestelmän täytyy pystyä toimimaan myös jollain tasolla verkkoyhteyksien katkettua. Järjestelmässä on mielestäni tarpeetonta ajatella sellaista tapausta, että kuka tahansa potilas voi olla millä tahansa vastaanotolla juuri kun verkkoyhteydet on poikki. Tapaus on mahdollinen, mutta niin harvinainen, että siinä pitäisi varautua käyttämään jonkinlaista puhelin-fallback:ia. Valtaosa potilastapauksista kuitenkin tapahtuu henkilön oman sairaanhoitopiirin sisällä ja todennäköisesti ns. omalääkärin vastaanotolla. Tällöin tietokantatasoja voisi lähteä ajattelemaan hieman samalla tavalla kuin miten sairaanhoito on nyt jaettu hallinnollisesti:

  1. Valtakunnallinen tietokanta. Sisältää kaikkien kansalaisten tiedot sekä binääritiedostot (rtg-kuvat yms)
  2. Sairaanhoitopiirin tietokanta. Sisältää kaikkien kansalaisten tiedot, mutta binääritiedostot vain ko. sairaanhoitopiirin kansalaisista.
  3. Terveyskeskuksen/sairaalan/hoitopisteen oma tietokanta. Sisältää omien tai kaikkien potilaiden tiedot, mutta binääritiedostot vain ko. hoitopisteestä

Ajatuksena sellainen, että tiedonhaku lähtisi aina alimmalta (paikalliselta) tietokantatasolta ja ylemmiltä tietokantatasoilta saataisiin sitten lisäinformaatiota. Toimenpiteiden kirjaukset ja tiedostojen tallennus tapahtuisi aina paikalliselle tietokantatasolle, josta palvelin sitten synkronoisi tiedot ylemmälle tasolle heti yhteyden palauduttua.

Pahimmassa tapauksessa lääkäri saa siis yhteyden vain paikalliseen tietokantaan ja sen tietoihin. Lääkärille pitäisi pystyä tässä kohtaa indikoimaan, että jotain dataa on myös olemassa ylemmillä tietokantatasoilla, joihin ei nyt pääse käsiksi. Potilaskohtaamisen kirjaukset lääkäri voi sitten kirjata paikalliseen tietokantaan, josta ne lisätään sairaanhoitopiirin kantaan yhteyden palautuessa. Ja sairaanhoitopiirin kannasta valtakunnalliseen kantaan.

Findo-zz commented 11 years ago

Ohjelman vois tehdä Qt:llä / C++.

Plussia: -Kaikille kolmelle alustalle ilman suuria koodin muokkauksia (Pc, Linux, Mac) -UI:n tekemisen helppous -Hyvä documentaatio -Hyvä tekninen tuki

Miinuksia: -Ei tukea mobiililaitteille (Android, iOS, WP), tulee joskus?

@vsalomaki Laitetaan vain riittävän iso teksti, kun yhteyttä ei saada valtakunnalliseen tietokantaa. Lääkärin käyttämä tietokone pitäisi vielä tarkistaa saadaanko yhteyttä lähimpään tietokantaan (terveyskeskuskesn tietokanta), jos ei niin tallennetaan muokatut potilastiedot päätteelle odottamaan synkkausta. Jonkinnäköinen potilashistoria tarvittaisiin myös, jossa näkyisi kaikki potilaalle tehdyt muutokset graafisessa muodossa.

Tietoturvasta vielä sen verran, että pitäisikö kaikille lääkäreille antaa mahdollisuus päästä käsiksi kaikkien potilaiden tietoihin?

ronchaine commented 11 years ago

Kun miettii mitä kieltä kannattaa käyttää tällaisen järjestelmän toteuttamiseen, kannattaa ottaa huomioon että esim. Javan Runtime on kolmannen osapuolen softaa jonka haavoittuvuuksia ei itse voida mennä korjailemaan. Esim. http://www.cert.fi/tietoturvanyt/2012/08/ttn201208281337.html En näe oikein mahdollisena että ajetaan näinkin kriittisessä paikassa softaa, johon voi joutua odottelemaan päivitystä kolmannelta osapuolelta.

C++ (ja Qt, siinä määrin kuin se on oleellista) on siinä mielessä hyvä ehdotus, että sille pitäisi löytyä vapaana liikkuvia osaajia Suomestakin, kiitos Nokian.

Oma näkemykseni olisi että vaikka en liiemmin kielestä pidä, tämmöiset stabiilit softat pitäisi kirjoittaa C:llä, jos se on suinkin käytännössä mahdollista.

raphendyr commented 11 years ago

Vain ne lääkärit joille on potilaas antanut luvan saavat nähdä potilaskertomuksia ja sitäkin pitää pystyä rajaamaan mitä kaikkea historiasta. Myöskään ylläpitäjät eivät saa nähdä potilastietoja.

Kaksi ideaa:

Qt ei pitäisi pystyä tulemaan androidiin taika ios käyttiksiin. Sinäänsä tyhmää.

Ps. Koitan muistaa korjata kirjoitusvirheet kun olen tietokoneella.

vsalomaki commented 11 years ago

@findo

Kahdennuksesta

Pelkkä varoitus yhteysongelmasta ei riitä, vaan pitäisi pystyä jollain tasolla ilmaisemaan, että mitä informaatiota muualla on. Itse ajattelen, että valtakunnallinen ja sairaanhoitopiirien tietokannat olisi parempi pitää vain tiedon yhdistäjänä sekä backuppina. Valtakunnallinen tietokanta ja sairaanhoitopiirien tietokannat toimisivat myös toistensa backuppina. Jos sairaanhoitopiirin tietokantaan ei saada yhteyttä, niin sitten koitetaan valtakunnallista tietokantaa ja toisinpäin. Tällä tavalla yksittäisen serverikeskuksen putoaminen ei saisi koko järjestelmää polvilleen.

Tai sitten jokaisessa sairaanhoitopiirissä olisi oma kopionsa valtakunnallisesta tietokannasta, jolloin vaikkapa laaja sähkökatko Helsingissä ei vaikuttaisi esim. Oulussa juuri mitään. (Olettaen worst-case-skenaarion, että UPS:t yms eivät toimi)

Joka tapauksessa, tekstidata vie aika vähän tilaa, joten lääkemääräykset yms sairaskertomukset voisi kyllä monistaa moneen paikkaan, mutta binääritietoa ei kannataisi kopioida joka paikkaan. Varsinkin, kun binääritietoa tulisi julmettu määrä. En tiedä, paljonko vaikkapa ns. viipalekuvauksesta tulee dataa, mutta voisin veikata, että paljon. Ja tuota datamäärää ei kannata kopioida jokaiseen niemeen ja notkoon, vaan data pitäisi säilyttää mahdollisimman lähellä potilasta.

Minun mielestäni ei ole hyvä idea tallentaa mitään mihinkään päätteelle, koska silloin potilasturvallisuus on vaarassa. Hyvin yleinen tapaus on, että sama potilas käy esim. terveyskeskuksessa usean eri hoitajan/lääkärin vastaanotolla, jolloin voisi syntyä vaaratilanne, että esim. lääkemääräyksen muutos jääkin lääkärin koneelle odottamaan synkkausta. Tällaisessa tapauksessa järjestelmän pitäisi ohjata/pakottaa paperin tulostamiseen tms. Kyseessä pitäisi olla kuitenkin niin harvinainen tilanne, että paikalle lähtee IT-kaverit sitten vaikka lentäen.

Tietoturvasta

Kaikki lääkärit eivät ole oikeutettuja näkemään kaikkia tietoja. En tiedä tarkempia rajauksia, mutta varmaan jonkinlaisten käyttäjäryhmien luonti ja hallinnointi olisi kätevin tapa hoitaa se. Huom, tässäkin kohtaa hoitavalle lääkärille pitäisi ilmoittaa lisäinformaation olemassaolosta, oli hänellä sitten oikeus katsoa niitä tai ei.

Toinen haaste on fyysinen tietoturva; isoihin serverikeskuksiin voidaan laittaa vaikka mitä puolustusjärjestelyjä, mutta esim. terveyskeskuksissa se ei ole mahdollista. Sellainenkin poikkeuksellinen tilanne voisi tulla, että kylän X terveyskeskukseen murtaudutaan sillä tarkoituksella, että päästään paikalliseen palvelimeen käsiksi ja mahdollisesti sen avulla valtakunnalliseen tietokantaan. Tällainen pitäisi estää ensinnäkin sillä, että terveyskeskuksen palvelimelle ei voi ladata kaikkien tietoja. Toinen puolustuslinja olisi paikallinen UPS, jonka avulla paikalliset tiedot pystyttäisiin tarvittaessa jopa tuhoamaan. Eli jos serveriräkkiin käydään fyysisesti käsiksi (porataan vaikkapa reikiä), niin tietojen tuhoaminen alkaa. Jos serveriin halutaan saada pääsy asianmukaisesti, niin se pitäisi hoitaa jonkinlaisen valtakunnallisen keskuksen kautta, joka lähettää serverille signaalin avausoikeudesta.

Selvää on, että järjestelmän sysadminit pitäisi valita huolella. Jos/kun jollain on näpeissään "dump * ", niin on syytä olla huolissaan.

Ohjelmointikielestä

Itse olisin myös C++:n kannalla, mutta minun mielestäni keskeistä olisi tehdä rajapinnoista sellaiset, että niitä voi käyttää lähes millä kielellä tahansa. Tarkoituksena siis se,että kaikilta eri sairaanhoidon toiminta-alueilta voitaisiin tallentaa tietoja kantaan sekä tietysti hakea tietoja. Se, että miten tieto esitetään vaikkapa kirurgille tai terveyskeskuslääkärille poikkeavat toisistaan ja tässä pitäisi pyrkiä siihen, että käyttöliittymä voidaan muokata mahdollisimman tarkasti tarpeita vastaavaksi. Käsittääkseni eri sairaaloissa voi olla hieman erilaisia toimintamalleja, jolloin alihankkijan pitäisi pystyä toteuttamaan haluttu käyttöliittymä vastaamaan tarpeita.

Eli rajapintojen ja tietokantojen rakenteen pitäisi olla mahdollisimman geneerinen, jotta voitaisiin taltioida hyvinkin erilaisista lähteistä tulevaa dataa. Ja jotta dataa voitaisiin myöskin hyödyntää erilaisilla tavoilla. Datalla ei tee mitään, jos sitä ei voi hyödyntää!

vsalomaki commented 11 years ago

Tuntemattomista potilaista

Vastaan voi helposti tulla tilanne, jossa potilaan henkilöllisyyttä ei tiedetä. Parhaassa tapauksessa voitaisiin tehdä hakuja tietokantaan jollain tuntomerkeillä, mutta joka tapauksessa tuntemattoman potilaan tiedot pitäisi kyetä kirjaamaan tabletilla tai vastaavalla. Jos henkilöllisyyttä ei tiedetä, niin potilaalle annettaisiin esim. nelikirjaiminen numero, jolloin ambulanssimiehistö voisi kirjata toimenpiteensä ja havaintonsa tuon numeron taakse. Kyseinen numero olisi sairaanhoitopiirikohtainen ja oletuksena on, että sairaanhoitopiirin alueella ei ole yhtäaikaisesti yli 9999 tuntematonta potilasta.

Huom, pitäisi myös varautua tilanteeseen, jossa potilas antaa vääriä tietoja tai tajuttomalla potilaalla on mukanaan eri henkilön paperit. Tällaista tilannetta varten täytyisi olla toimiva mekanismi. Jos jokaisella kirjauslaittella on oma ID-numeronsa, niin tiedot pitäisi pystyä siirtämään toiselle henkilölle. Ajatellaan vaikka tilannetta, jossa ambulanssihenkilöstö löytää tajuttomalta väärät paperit ja kirjaa toimenpiteensä tuon henkilön henkilötunnuksen taakse. Kun sairaalassa havaitaan, että kyseessä on eri henkilö, niin pitäisi pystyä siirtämään vaivatta ambulanssihenkilöstön kirjaukset oikean sotu:n taakse. Tässä voisi olla apuna jonkinlainen järjestelmän 24/7 helpdesk.

keskival commented 11 years ago

C++/C/whatever keskustelut eivät kuulu tänne. Ne aiheuttavat pelkästään hallaa tämän projektin uskottavuudelle.

Findo-zz commented 11 years ago

@vsalomaki

Toit todella hyvä pointteja esille tietoturvasta ja tästä viisastuneena sain uusia ideoita; jos kyseisen terveyskeskuksen serverit ovat alhaalla ohjelma voisi seuraavana yrittää yhdistää sairaanhoitopiirin tietokantaan jne.

Jos terveyskeskuksen palvelimille yritetään fyysisesti hyökätä esim. paikalliselle poliisille voisi lähteä viestiä, jolloin paikalla saataisiin teoriassa aika nopeasti väkeä. Tässä ongelmana olisi tietysti vahinkohälytykset, mutta nämä saatettaisiin saada mataliksi, jos huoltoväelle tehtäisiin riittävän selväksi miten toimia.

Tietojen rajaus olisi mielestäni kohtalaisen helppo; lääkärit näkevät kaikki potilaan tietojen kohdat kuten nimi, lääkitykset yms. mutta itse tekstit on sumennettu/yliviivattu.

Tuntemattomista potilaista

Ohjelmassa voisi myös aika samanlainen palvelu kuin täällä oleva Pull Requests palvelu eli lääkäri voisi lähettää tietyistä asioista mieleisensä oikaisun, johon voisi liittää vaikka syyn miksi pitäisi muuttaa tietoja. Tästä jäisi merkintä kummankin potilaan tietoihin, että jos myöhemmin havaitaan virhe asia olisi helposti palautettavissa. Nämä merkinnät eivät tietenkään näkyisi lääkäreille, vain tukihenkilöille jotka käsittelisivät muutos pyynnöt.

d2s commented 11 years ago

@vsalomaki Yksi mahdollisista vaihtoehdoista tiedon salattuun säilytykseen massiivisessa mittakaavassa on Apache Accumulo™ jonka taustoja voi hieman lukea. Teknisesti tuo on ilmeisesti aika uniikki siinä mielessä että se mahdollistaa esim. tietokannan ylläpidon ilman että edes pääylläpitäjä näkisi kannan sisällöstä itse tietoja. Ongelmana tuossa toisaalta on projektin suhteellisen vähäiset julkiset käyttäjät, mutta niitä on varmasti luvassa jatkossa enemmän. Sisäisessä käytössä Accumulo on ollut jo useampia vuosia maailman tunnetuimmassa tiedustelupalvelussa…

Kehityksen takana olevan yrityksen sivusto kertoo tietokannan turvamallista: "Acorn's cell-level security and flexible data model ensure that Protected Health Information (PHI) is only revealed to authorized users."

@keskival Samaa mieltä käyttöliittymäpuolen teknisestä toteutuksesta. Se kun ei ole kuin pintaa allaoleviin järjestelmiin ja tulee varmasti uudistumaan vuosien varrella tekniikoiden muuttuessa ja kehittyessä.

vsalomaki commented 11 years ago

Vastaan lyhyesti kännykällä. Kuten sanottua, en tiedä tarkalleen mitä tietoja kukin lääkäri saa katsoa lupiensa sisällä. Voisin veikata, että esim. Lääkemääräyksiä ei ole tarkoitus salata miltään lääkäriltä.

@d2s En tunne tuota Apachen järjestelmää, mutta selvää on, että jollain täytyy olla rajoittamaton pääsy tietokantaan. Vai voidaanko Accumulo todeta 100% toimivaksi? Mites sitten 10 vuoden päästä, kun uusia käyttöjärjestelmiä hankitaan? Hankitaanko accumulo2, paljonko maksaa accumulo-spesialisti, jolla on pääsy kaikkeen dataan"

bleadof commented 11 years ago

Hei, tyypit. Jotta tätä päätöstä voisi lähteä tekemään, niin tulisi ensin kartoittaa tämänhetkinen tilanne ja ymmärtää mitä ollaan tekemässä. Sen jälkeenhän tälläisiä voi edes miettiä.

vsalomaki commented 11 years ago

@bleadof

Helmetti, itse valvoisin mielelläni tällaista projektia kuin koira lampaita, mutta eiköhän tämäkin projekti lopulta ajaudu jonkin suojatyöpaikkalaisen vastuulle ja sitä kautta aivan pers**lleen.

Numero 1 kaikilla: KILPAILUKYKY! Jos sitä ei ole, niin ei ole pian mitään muutakaan!

d2s commented 11 years ago

@vsalomaki @bleadof Muutama päivä sitten keskustelin yhden tutun kanssa joka työkseen kehittää nykyisiä terveydenhuollon järjestelmiä eräässä suuressa korporaatiossa. Hän totesi ongelmaksi sen että perinteinen työtapa järjestelmien käyttämisestä tiedon kirjaamiseen/lukemiseen on muuttunut (tietomäärien kasvaessa valtavalla vauhdilla). Sellaiset järjestelmät jotka vielä 90-luvulla toimivat kohtalaisesti ovat muuttuneet käyttökelvottomiksi tietomäärän kasvettua. Iso ongelma on myös siinä että kun järjestelmiin kertyy päällekkäisiä tietoja, kaikkea ei voida nähdä eikä ymmärtää. Haastetta lisää vielä entisestään ihmisten kiire työtehtävissä. Joissakin asioissa (kuten leikkaussalien järjestelmissä) pientenkin detaljien näkyminen näytöllä voi olla elämän ja kuoleman kysymys. Käyttöliittymäpuolen selkeys on siis tärkeä asia, mutta se on kuitenkin vain aivan pintaa allaoleville ongelmille.

Suurempi ongelma on siinä että tietojärjestelmiin kertyvää dataa ei ymmärretä. Tarvitaan äärimmäisen kipeästi ihmisiä joilla olisi kokemusta tietojen louhinnasta ja analytiikasta jotta kasvaviin tietomassoihin voitaisiin saada jotain järkevää käsitystä aikaan. Saman potilaan tietoja voi olla jo monessa eri terveydenhuollon järjestelmässä ja yksittäinen lääkäri/hoitaja ei voi mitenkään saada kokonaiskuvaa asioista.

Joillakin tutuillani on kertynyt jo alle 40-vuotiaana paksun kansion verran sairauksien hoitoon liittyviä dokumentteja (iso osa potilaskertomuksia ja erilaisia mittaustuloksia yms.). Harvalla lääkärillä on aikaa tai jaksamista alkaa kahlata tuollaista tietomassaa läpi edes yhden potilaan osalta, puhumattakaan että jotenkin muodostuisi (oikea…) käsitys siitä miten samantyyppisiä sairauksia voitaisiin hoitaa mahdollisimman hyvin. Tarvitaan järkeviä keinoja erilaisten hoitotietojen analysointiin että esim. erilaisten päällekkäisten lääkitysten tai ristiriitaisten mittaustulosten riski vältettäisiin. Tuomalla näkyville erilaisia pidemmän ajan visualisointeja terveystiedoista voitaisiin auttaa jatkuvasti kovemmalla työtaakalla olevia terveydenhuollon ammattilaisia saamaan asioita enemmän aikaan.

Tärkeintä on kuitenkin se että asiaa katsotaan sekä potilaan, hoitohenkilökunnan kuin myös teknisen ylläpidon kannalta. Kokonaisuuden pitäisi olla sellainen että oikeat ihmiset pääsevät oikeisiin tietoihin käsiksi, tietoja voidaan visualisoida laajemmassakin mittakaavassa, mutta kuitenkin niin että yksityisyyden suoja säilyy.

Lääketieteen etiikasta voisi varmasti olla keskustelua joka vaikuttaa myös järjestelmän toteuttamiseen. Minkälaista on tulevaisuuden lääketiede analytiikan lisääntyssä ja mitkä ovat suurimmat ongelmat nykyisissä työtavoissa. Se on kuitenkin keskustelu joka kuuluu toiseen threadiin… :)

antagomir commented 11 years ago

Mainitun aiheen tutkimus on kansainvälisesti erittäin vilkasta tällä hetkellä, review-papereita aiheesta löytyy helposti hakukoneilla, ks. esim. "personalized medicine" ja "electronic health records".

pe3 commented 11 years ago

Hoippa!

Oon tehnyt taustatutkimusta ja funtsaillut tätä projektia. Musta vaikuttaisi nyt siltä, että toimintaa kannattaisi ruveta käynnistelemään uudestaan.

Oon saanut selville, että Virolaisten potilastietojärjestelmän kertaluokkaa halvempi hinta perustuu kansallisen tason IT-infran hyödyntämiseen ja erityisesti X-road nimiseen kansalliseen palveluväylään (eestiksi X-tee). Löysin jatkotutkimuksia varten open source java-kirjaston palveluiden ja tietokantojen luomiseksi siihen https://code.google.com/p/j-road/ Kansallisesta palveluväylästä oon käyny keskustelua FB:ssä https://www.facebook.com/groups/407836109267293/permalink/463956956988541/

Epäonnistuessaankin avoin potilastietojärjestelmä olisi hyvä keissi kehitteillä olevan julkisrahoitteisen Forge-hankkeen suuntaamiseksi kehittäjäyhteisöä hyödyttävään suuntaan. Hankkeessa kannattaisi mielestäni lähteä kokeilemaan kehittäjäyhteisölle avointa Viron mallin kaltaista kansallista palveluväylää, jossa voidaan siirtää luottamuksellista tietoa julkisen sektorin, yksityisen sektorin ja vapaiden kehittäjien palveluiden välillä. Tässä linkki hyvään FB-keskusteluun Forgesta https://www.facebook.com/groups/fi.okfn/permalink/10151369380115628/

Avoimella potilastietojärjestelmähankkeella olisi sen verran yhteiskunnallista merkittävyyttä puolellaan, että keissillä saisi varmaan neuvottelut hyvin käyntiin ja suunnattua Forgea konkreettiin hyödylliseen tekemiseen. Parhaimmillaan hankkeeseen osallistumalla pääsisi kokeilemaan jotakin todella mielenkiintoista ja koko nykyisen julkisen sektorin IT-järjestelmät haastavaan. Se voisi siis olla oppimisharjoituksena kiinnostava, vaikei rahaa tässä vaiheessa projektiin ole penniäkään.

Ihan ekaksi pitäisi siistiä tää repo ja tehdä projektille GitHub Pages -sivut. Ensimmäinen tekninen tavoite olisi pystyttää Viron kaltainen väylä ja toteuttaa siihen arkkitehtuurin mukainen simppeli HelloPotilas.

Onko muita kiinnostuneita kuin minä? Yksin en selviä, sillä en tajua tämän mittakaavan järjestelmistä mitään.

pe3 commented 11 years ago

Niin unohtui muuten mainita, että olin puhujana Suomen Telelääketieteen ja e-Health seuran (STeHS) ja Sosiaali- ja terveydenhuollon tietojenkäsittely-yhdistyksen (STTY) seminaarissa 27.11.2012. Päivän otsikko oli: Mikä on sähköisten potilastietojärjestelmien valintatilanne tänään? Puhuin open data pohjaisesti avoimen kehitysmallin puolesta. Ja pointti tän projektin kannalta oli, että tutustuin siellä ihmisiin jotka voisivat tuoda tähän projektiin terveydenhoitopuolen osaamista.

keskival commented 11 years ago

Erittäin hyvää työtä! Tämä on hyvää esitietoa arkkitehtuurityöhön ja toimii lähtökohtana tämän infrastruktuurin proof-of-conceptiin.

Minulla on paljon kokemusta tämänkaltaisista enterprise-integraatioprojekteista. Valitettavasti en pysty panostamaan tähän rupeamaan kovin montaa tuntia. Kuitenkin aluksi projektissa pitäisi kerätä user storyt, joiden pohjalta voidaan tehdä vaatimusmäärittely, use caset, prosessikuvaukset, UI-flowt ja product backlog. Kun product backlog on sitten luotu, voivat developerit ottaa siitä itselleen taskeja toteutettavaksi.

Huomioon otettavia asioita:

d2s commented 11 years ago

@pe3 Periaatteessa kiinnostusta, ainakin alkuvaiheen luonnostelun suhteen.

Palveluväylästä tms. ei ole kokemusta, joten en osaa siinä auttaa.

Se mitä tässä vaiheessa voisi/kannattaisi olisi esim. ottaa Etherpad avuksi ja työstää yhdessä listaa asioista joita pitäisi ottaa kokonaisuudessa huomioon. Tuon paloitellun ja järjestellyn listan voisi sitten ottaa ja siirtää tehtävälistaksi vaikka tänne GitHubin puolelle.

Lähtökohtaisesti tuollaisessa pienestä mittakaavasta lähtevässä projektissa olisi järkeä, vähintäänkin harjoituksen näkökulmasta. Ymmärrän hyvin, että terveydenhuollon järjestelmissä on oikeasti aivan valtava määrä yksityiskohtia ja asioita joita pitäisi ottaa huomioon. Jos lähdettäisiin liikkeelle ihan siitä että minkälainen käyttäjäkokemus järjestelmässä olisi käyttäjän kannalta (sekä lääkärin, sairaanhoitajan, muun henkilökunnan että potilaan näkökulmista). Sitä myötä voi löytyä myös niitä asioita joita pitäisi ottaa huomioon niin tallennettavan datan, backendin toimivuuden kuin myös käytettävyyden ja käyttöliittymien selkeyden kannalta.

Pelkkä käyttöliittymä ei toki ratkaise ongelmaa, enkä niin oletakaan. Sellaisen työstäminen on kuitenkin hyvä asia siitä näkökulmasta, että saa jotain näkyvää prototyyppiä aikaan, jota voi käyttää apuna keskustelun ja mielenkiinnon luomiseen projektia kohtaan. Backend-kehitys vaatii kuitenkin aivan omat osaajansa ja on hyvä olla samanaikaisesti yhteistyötä, sekä käyttäjille suoraan näkyvien, että taustalla olevien järjestelmien kehittäjien välille.

Ymmärrän hyvin myös sen, että potilastietojärjestelmät ovat laajoja kokonaisuuksia, ja eri käyttötarkoituksia varten on erilaisia työtapoja ja työnkulkuja.

@keskival edellä sanoi hyväksi lähtokohdaksi User Storyjen keräämisen. Se onkin tärkeä lähtökohta oikeastaan suurinpaan osaan alkuvaiheen asioista. Joku voisi esim. etsiä projektiin avuksi vaikka jotain terveydenhuollon puolen oppilaitoksia sekä jo pidempään työtä tehneitä ja heidän avullaan etsiä näkökulmia (sekä perinteisistä työnteon tavoista, että myös siitä, mitä uusille opiskelijoille opetetaan työtapoihin liittyen). Terveydenhuollon tietojärjestemien käyttö tulee varmasti muuttumaan tulevaisuudessa eri suuntaan nykytilanteesta, koska jatkuvasti lisääntyvät vaatimukset sekä datan että käyttäjäkokemuksen kannalta asettavat uusia haasteita asioiden tekotapoihin.

Datan määrä tulee jatkossa moninkertaistumaan, ennen näkemättömällä vauhdilla. Erilaiset mittalaitteet ja työtavat tuottavat entistä enemmän dataa josta tulee samalla yksi osa ongelmaa. Tiedon analysointi muuttuu tärkeämmäksi, ja pelkkä yksityiskohtien listaaminen ei riitä enää. Mitä asioita pitääkään ottaa huomioon, sitä en vielä tiedä. :)

keskival commented 11 years ago

Huomatkaa, että user storyihin voi lisätä meta-tason itemeitäkin tässä vaiheessa:

keskival commented 11 years ago

Tämä keskustelu on kuitenkin väärässä threadissa; täältä tätä kukaan ei löydä. Jos joku jaksaa summarisoida tämän projektin ensiaskeleet keskustelun uuteen threadiin tai löytää tälle keskustelulle paremman paikan, niin go for it.

keskival commented 11 years ago

Ja wiki-sivulle pitäisi kerätä näitä user storyjä, linkkejä, ohjeita ja huomioon otettavia asioita.

raphendyr commented 11 years ago

Kaikki on varmaan huomannu, että tää on aika iso palikka. Minun mielestä kannattaisi koittaa tehdä suurimmat arkkitehtuurilliset jaot, joiden pohjalta alkaisi rakentamaan omia projekteja, jotka sitten ovat läheisessä yhteistyössä.

Esimerkiksi jotain tämän suuntaista:

Tai jotain aivan muuta.

Tämä auttaisi ihmisiä keskittymään heitä kiinnostaviin aiheisiin. Yllä huomaa osan haluaa ajaa tätä käyttäjälähtöisesti (eli kolme viimeistä projekti jakoa) ja toiset taas tiedon tallennuksen ja liikuttamisen näkökulmasta.

Kun projektit saa liikkeelle voi käyttölittymä porukka kertoa millaista dataa heidän tulee tallettaa ja välittää ja toisilla on jo ideoita kuinka erityyppisiä datoja voidaan välittää.

Tuota välityskerrosta ja data storagea voinee käyttää myös muissa suomen it jutuissa.

Hukkinen commented 11 years ago

Tajuttoman potilaan tietojen siirtämisestä oikeaan paikkaan @vsalomaki voisi auttaa copy-paste -tyylinen tietojen kopioiminen/siirtäminen.

Pointti olisi siinä, että kopiointi tehtäisiinkin jossain määrämuotoisuuden säilyttävässä markup-muodossa. Ts. kun leikepöydälle kopioi jonkin tiedon käyttöliittymästä, sinne ei kopioidu pelkkää tekstiä, vaan sellainen datamuoto, jonka voi peistata jonnekin toiseen kenttään samassa järjestelmässä. Käli-toteutus on kysymys erikseen (tehdäänkö esim. eri data-ikkunat/kuvakkeet tekstin silmällä lukemiselle ja kopioimiselle vai ei).

Tämä toisi paljon joustavuutta järjestelmän tietojen käsittelyyn. Sitä en osaa sanoa, onko tällainen ratkaisu kuinka tarpeellinen suhteessa niihin käyttäjien ongelmiin, joita se ratkaisee. Täytyykö samoja tietoja siirtää ja kopioida paljon?

Hukkinen commented 11 years ago

Kokonaiskuvan muodostamisesta potilaan tiedoista johdosta pohdin seuraavaa.

Miten esittää tieto siten, että kokonaiskuvan muodostaminen on helppoa?

Annotointi, metadata, tägääminen, avainsanoittaminen?

Tietoja ei kai voida olettaa annotoitavan siten, että tällä perusteella ao. potilaan tietoihin pääsisi näin kätevästi käsiksi? Vai voidaanko? Voidaanko ottaa käyttöön avainsanalistoja tms, jotka helpottavat tiedon löytämistä?

Toisaalta esimerkiksi lääkemääräykset vaikuttavat sellaisenaan sen verran täsmällilsiltä tiedoilta, että niitä on helppo listata.

Tiedon louhinta: Miten "algoritmisesta mustasta laatikosta" saa käyttäjille luotettavan?

Miten tiedon louhinta käytännössä toimisi? Mitä tietoja se syö ja mitä tulostaa? Voiko tällainen "algoritminen musta laatikko" (hoitohenkilökunnan näkökulmasta) antaa läpinäkyvästi, ymmärrettävästi ja luotettavasti tietojaa?

Tämän takia ongelma onkin muotoiltava uudelleen: Miten tämä tiedonlouhinta-algoritmi olisi käyttjälle esitettävä, jotta se tuntuisi ymmärrettävältä, hallittavalta ja luotettavalta=

Hakukone?

Mitä jos potilastiedot olisivat sisäisen hakukoneen indeksoimia? Helpottaisiko tämä kokonaiskuvan muodostamisessa? Internetin käyttö- ja - lukutaitoa tässä ainakin voisi hyödyntää.

Hakukone voisi olla tiedollisesti melko läpinäkyvä ja käyttäjilleen ymmärrettävä tapa. Etu on siinä, että hakukone periaatteessa esittää tiedon hakijalleen samassa muodossa kuin missä se on luotu – ainakin jos puhutaan dokumenteista.

Tietojen määrämuotoisuudesta: Miten kysyä ja tallettaa eri tarpeita tukevaa tietoa? – Leipätekstiä, lomakkeita, tekstiä vai numeroita?

Leipätekstiä on helppo tuottaa mutta lomakkeet tarjoavat määrämuotoista dataa. Missä määrin voidaan olettaa, että tietoa tuottava henkilökunta lähtee lomakkeiden täyttöön?

Kuinka detaljoitua ja koneluettavaa dataa lomakkeisiin syötetään? Tekstiä, sanoja, lukuja, monivalintoja vai markup-notaatiota?

Millainen tiedonsyöttö- ja/tai tallenuustapa...

Pohdintaa

Erilaisia tarpeita on ainakin seuraavasti.

Tuntuisi, että epikriisiä kirjoittavalle lääkärille olisi pidemmän päälle helppoa, jos lukuarvot ja niiden yksiköt (mittaustulokset, lääkkeet) voisi annotoida tekstin sekaan jollain markup-kielellä. Myös linkityksiä pitäisi tukea; tämä olisi näppärintä toteuttaa selaimen tasolla.

Toisaalta laitteet tuottavat numerotietoa ja se voidaan syöttää järjestemlään koneellisesti – jos laite saadaan kytketyksi potilastietojärjestelmään (kustannustehokkaasti). Tällainen datamäärä kyllä lie tarpeen vain varsin lokaalisti.

Ehkäpä myös hoitaja käy seuraamassa toistuvasti potilasta ja tekee siitä joitain yksinkertaisia (numeropohjaisia?) muistiinpanoja.

Mitkä huomiot edellä esitetystä ovat käytännössä oleellisia ja mitä pitäisi vielä huomioida?