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.

TomiS commented 11 years ago

Potilastiedot ovat pohjimmiltaan dokumentteja, joihin liitetään toisia dokumentteja, joten ehdottomasti suuntaisin katseeni NoSQL-puolelle. Siellä ainakin MongoDB on hyväksi havaittu ja toimiva valinta. Mitä plattoihin tulee, niin PHP-skenen edustajana äänestän tietty Symfony 2 -frameworkia.

itmo commented 11 years ago

Valitsisin alustaksi linux+J2EE tyylin paketin, apachen, jonkun sopivan edustakakun, jbossin,postgres kannaksi, dokumenttivarastoksi joku nosql-mallinen esim. cassandra. Sitten tarvitaan jonkunlainen audit-frameworkki ja pääsynhallintaframeworkki. Etummaiseksi kerrokseksi voisi harkita vaadinta.

Sinällään ensimmäinen ongelma on kaikkien liityntäjärjestelmien ja siirrettävän datan listaaminen, rajapintojen listaaminen ja toisaalta softan käyttäjäpuolen vaatimusten speksaaminen.

Alustavalinta on lähinnä pikkupolitiikkaa. PHP on sikäli kuraa että sillä ei voi tehdä ylläpidettävää softaa, ja tämän kokosessa projektissa ei voida olettaa että jokanen koodari tekee siistiä jälkeä.

Tosta dokumenttimaisuudesta en ole ihan samaa mieltä. ei niitä dokumentteja voi käsitellä täysin läpinäkymättöminä, niistä pitää pystyä hakemaan järkevästi tietoa, jotta voidaan näyttää relevantteja dokumentteja ja kaivaa tietoa.Kuitenkin suurin osa nykyisestä datasta terveydenhuollossa tuotetaan ihan tietokoneella, joten formaatit lienevät jotenkin muokattavissa kohti teksti+kuva muotoisia formaatteja. esim pdf. Näistä taas haku onnistuu kunhan dokumentti ei ole pelkkä kuva.

TomiS commented 11 years ago

@itmo Ensinnäkään en nyt tartu tuohon PHP-trolliin, koska se oli niin ysäriä että oksat pois. Kukin puffaa tietty sitä plattaa jonka tuntee, ja totta on, että se platta on loppupelissä aika epäoleellista. Kunhan se on lisenssiltään avoin, laajasti tuettu ja riittävän stabiili.

Mutta siihen vielä puuttuisin, että dokumentti-storagen käyttö ei millään tapaa estä kannan rakentamista strukturoiduksi ja jopa indeksoiduksi tarvittavilta osin. Ainakin Mongossa molemmat ovat mahdollisia ja jopa järkevä tapa toimia. Toki jos mieluummin askartelee kahden eri kannan kanssa ja ratkoo siitä syntyviä haasteita, niin voihan niinkin toki tehdä :)

tparvi commented 11 years ago

@TomiS Olen käsittänyt että MongoDB ei tue transaktioita. Siinä on kyllä jonkinlainen "atomic operation" tuki mutta hyvin kevyt sellainen. Transaktioiden lisäksi pitää olla 100% takuu siitä että kun data talletetaan se myös menee fyysisesti levylle tai homma epäonnistuu. Aika noloa jos lääkäri kirjoittaa e-reseptin ja vasta apteekissa huomataan että "oho ei sitä löydykään koska tietojen tallennus levylle tapahtuu viiveellä".

Muuten olen myös NoSQL:n kannalla ja esim. RavenDB tukee transaktioita (ACID). Lisäksi siinä on HTTP rajapinta joka syö JSONia joten sen käytön pitäisi onnistua melkein mistä tahansa. Jopa PHP:stä :) Niin ja tietysti lähdekoodi löytyy githubista vaikka kyseessä onkin maksullinen tuote.

itmo commented 11 years ago

Se ei ollut edes trolli, vaan ihan rehellinen mielipide. PHP on ideana kiva mutta toteutus on paska. "About 30% of all vulnerabilities listed on the National Vulnerability Database are linked to PHP."

Tossa on vaan luonnostaan kahdenlaista dataa, binääriblobeja malliin röntgenkuva ja hyvin kantamaista, rakenteista tietoa tyyliin varsinaiset potilastiedot ja ajanvaraus. Käyttäisin ensimmäisenkaltaisiin hajautettua dokumenttivarastoa ja jälkimmäiseen varsinaista SQL kantaa.

itmo commented 11 years ago

Ja olennainen jako tossa on että erottaisin perustoiminnallisuuden (tietovarasto, oikeuden ja pääsynhallinta, auditointi) , peruspalveluista (ajanvaraus,potilastietojen pyörittely, hakuominaisuudet,lääkeristivaikutukset) ja sovellustasosta (Käyttöliittymät erilaisilla työpisteillä, ajanvarauskäyttöliittymät, yms. ) Sopivalla jaottelulla suurin osa noista voitaisiin kilpailuttaa erikseen avoimia rajapintoja vastaan.

Symbiatch commented 11 years ago

Lisäänpä sitten pikaisesti omia ajatuksiani asiasta.

Itsekään en kyllä PHP:n päälle lähtisi vääntämään, juurikin tehokkuuden ja jatkuvien turvaongelmien vuoksi. Java tai .NET olisivat hyviä ehdokkaita, jälkimmäinen on oma valintani ollut pitkään monista syistä. Noissa myöskin se positiivinen puoli, että ovat käännettäviä ja vahvasti tyypitettyjä. Noistakin voi olla montaa mieltä, mutta kyllä kunnollinen käännösaikainen virhe/varoituslista on kiva asia ja tyypitysten tarkistus samalla myös.

Röntgenkuvia ja muita ei edes kannata tähän lähteä sotkemaan, sillä niiden varastointiin on jo PACSit, eikä mielestäni kannata lähteä omaa sellaista suunnittelemaan tai rakentamaankaan. Ja niihin rajapinnat ovat avoimet jo, joten homma toimii oikeasti hyvin DICOMilla.

Mietittävänä myös se, että onko olemassa keskustietovarasto, josta haetaan dataa tietyssä formaatissa vai jutellaanko aina rajapintojen kautta. Molemmissa hyvät ja huonot puolet. Fyysinen säilytys sitten tarpeen mukaan. PostgreSQL saisi äänen minulta myöskin, koska on vakaa ja kehittäjät pitävät tärkeänä "released when it's done"-ideologiaa, eikä joidenkin suosimaa "laitetaan tämä nyt ulos ja katsotaan miten käy"-tyyliä. Toki paremmin tukea todennäköisesti saisi sitten vaikkapa MS SQL Serverille, Oraclelle (johon en kyllä henk.koht. haluaisi koskea) tai muulle vastaavalle. Ja niihin löytyy suoraan paketista kunnolla testatut klusteroinnit ja muut tarpeelliset.

Itse jos järjestelmää tarjoaisin, lähtisin varmaankin .NET/PostgreSQL/IIS-yhdistelmästä, tai SQL Server. Lisenssit eivät päätä huimaa tällaisessa ja kehitys on nopeaa ja tehokasta sekä on vakaa alusta ihan muutostenkin suhteen. Apache on kanssa minulle kategoriassa "kiva idea, toteutus ei niin hyvä" (vaikka moisia ylläpidänkin).

Sinänsä järjestelmästä voisi tulla entistä parempi, jos todellakin eri osia tekisivät eri tahot. Ja pidettäisi nämä tahot sopivasti oikeasti erillään, eikä koodarit käy yhdessä kaljalla puhumassa asiasta. Tällöin rajapintojen pitää oikeasti toteuttaa halutut asiat, koska ne ovat ainoat joiden mukaan toimitaan.

Toki tällaisten pohdintojen jälkeen vain aina pitää kysyä: onko mitään mahdollisuutta kenelläkään oikeasti päästä kilpailutukseen mukaan, että voisi oikeasti toteuttaa järjestelmän?

d2s commented 11 years ago

HTTPD-palvelimista vielä se, että itse näkisin FreeBSD+nginx -pohjaisen frontendin ainoana järkevänä ratkaisuna, vaikka sovelluspuolella olisikin käytössä vaikka Windows-palvelimia. Ongelmana suorassa Windows-palvelimien liittämisessä verkkoon on edelleenkin käyttöjärjestelmän verkkotason tietoturvan puutteet joita tuskin tullaan lähitulevaisuudessa korjaamaan (ja tämä ei ole pelkkää mutu-arviota). Hyödyntämällä hyvin konffattuja välipalvelimia voidaan saada huomattavasti suurempi suorituskyky pienemmällä laitteistokuormituksella ja samalla voidaan Unix-pohjaisen välikoneen tasolla blokata moni potentiaalinen tietoturva-aukko.

Järjestelmien rakenteessa on tietty järkevä eristää systeemit pienempiin lohkoihin niin että eri palikat voivat tarvittaessa olla yhteydessä keskenään (jos on tarve), mutta niin ettei kerralla menetetä koko järjestelmää jos joku pääsisi murtautumaan tiettyyn osa-alueeseen (mitä ei tietenkään saisi tapahtua, mutta mikään ihmisten tekemä koodi ei ole täydellistä vaikka todella hyvään laatuun voikin päästä hyvällä testauksella).

ztane commented 11 years ago

Kylläpäs täällä kaikenlaista pusketaan. Te mietitte vain ja ainoastaan nyt Viron/Tanskan tyylistä potilaan portaalia kaikesta päätellen, vaikka kyseessä on kuitenkin huomattavasti isompi järjestelmä.

Lähdetään ensinnäkin siitä että nykyisellään softa ei voi toimia pelkästään web-sivuna, koska sitä on tuettava myös kannettavissa laitteissa. Potilastiedoista pitää jäädä myös audit-tiedot. Systeemin pitää toimia hajautettuna koska potilaiden hoitamista ei voi keskeyttää vaikka tietoliikenneyhteydet olisivat poikki. Jos katsotte edes vaikkapa Electronic Health Record -wikipedia-sivua, niin siitähän jo itse kuvasta näkee että on hyvä hyvä että tiedon tallentaja voi mm. piirtää mikä rajoittaa myös osaltaan teknologiaa - miettikää miten etäpääte toimisi edes tablet koneessa.

Millä kielillä tätä ei luultavasti tehdä on PHP, jolla on ongelmia modulaarisen koodin kirjoittamisessa (toisaalta eipä MUMPSkaan ole kummoisempi). MongoDB puolestaan on omien kokemuksieni mukaan täysin epästabiili ja kelvoton mihinkään mission-critical-järjestelmään. Siinä missä backend on hyvä aina toteuttaa vanhan ja todennetun teknologian päälle, toki erinäisissä käyttöliittymissä voidaan hyödyntää mitä moninaisimpia teknologioita.

Symbiatch commented 11 years ago

Ei tietenkään minään pelkkänä webbisivuna, kyllä tuohon tarvitaan ihan "oikeat" sovelluksetkin käyttöön ja varsinkin palvelinpäässä tarvitaan hieman rankempaa palvelua. Että en minä ainakaan mieti vain potilaan portaalia. Ja palvelun hajauttaminen juuri yhteysongelmien takia ei ole mikään triviaali asia. Jos joku oikeasti ajattelee vääntävänsä yksittäisellä kanta- ja sovelluspalvelimella (tai yksittäisellä klusterilla yhdessä konehuoneessa) tuon edes HUSin sisällä toimivaksi niin... :)

Ja olen aivan samaa mieltä backend/frontend-rajauksestasi. Rajapintojen päälle voidaan rakentaa mitä vain millä vain, mutta alustan itsensä pitää olla vakaa eikä millään hipster-favorite-of-the-day -alustalla viritelty.

jsalonen commented 11 years ago

Täysin samoilla linjoilla edellisten kirjoittajien kanssa. Prototyyppejä voi rakentaa keveästi millä vaan, mutta jos keskustellaan tämän tason tietojärjestelmien kehityksestä niin tuotantoteknologioiden täytyy olla todella koeteltuja ja vakaita.

Mielestäni spesifien alustavalintojen sijaan olisi syytä keskustella tarkemmin niistä vaatimuksista, mitä potilastietojärjestelmille käytännössä kohdistuu. Eli tässä yhteydessä: mitkä ovat järjestelmän tarkat suorituskyky, tietoturva, saavutettavuus ym. vaatimukset? On mielestäni ihan hullua keskustella vaikkapa siitä, mikä tietokanta valintaan, ennenkuin on mitään käsitystä siitä, mitä vaatimukset tiedon varastoinnille ovat.

d2s commented 11 years ago

@ztane Totta sanomasi. Ongelma kuitenkin on että järjestelmästä on väkisin tulossa jatkossa tiettyjä osia julkiseen käyttöön koska yhteiskunnan vaatimus datan saatavuudelle myös itse potilaalle kasvaa jatkuvasti. Rajoituksia ja ongelmia tietysti on asiassa, mutta hyvä varautua siihenkin.

Web-pohjaisella käyttöliittymällä oleva softa sairaalan sisällä ei kuitenkaan ole todellakaan mikään pois suljettu vaihtoehto. Kyllä, softien pitää toimia vaikka yhteydet olisivat poikki. Siihen löytyy kuitenkin mahdollisia ratkaisuja, riippuen ihan siitä että missä määrin tietoja pitää kuljettaa mukana ja kuinka kauan kannettava päätelaite on irti sairaalan keskusjärjestelmistä. Mahdollisuus on myös paketoida osa sovelluksista tablet-laitteille tai käyttää samoja (dokumentoituja…) yhteysrajapintoja natiivisovelluksen teossa.

Pääasia on että taustajärjestelmän päälle voidaan kehittää erilaisia client-sovelluksia ilman että taustajärjestelmää pitäisi jatkuvasti muutella.

itmo commented 11 years ago

Käytännössä jonkunlainen keskitetty backend tietovarasto tarvitaan. Toinen vaihtoehto on lähestyä jonkunlaista p2p systeemiä (ei fiisiibeliä) tai rakentaa monimutkainen synkronointimekanismi (ei fiisiibeliä). Käytännössä homma on hoiduttava jotenkin niin että lisäyksiä tietoihin voidaan tehdä yhteyksien ollessa poikki, ajanvarauksesta on käytössä jonkinlainen paikallinen kopio, kuten myös järjestelmistä kuten lääkkeiden ristivaikutukset. Sen sijaan tossa muodostuu sitten ongelmaksi potilasdatan paikallinen tallentaminen turvallisesti ja niin että audit-kanta pysyy jotenkin viisaasti synkissä.

@d2s frisbi+nginx tuli itelläkin mieleen frontendiin kuormaa tasaamaan ja reverse cacheksi.

@symbiatch jos pitäisi IISsin ja apachen välillä valita niin ei ole vaikeaa valita niistä käytetympää, laadukkaampaa ja vähempireikäistä ;) Muitakaan varsinaisia vaihtoehtoja ei taida olla. Apache toimii erittäin hyvin sovelluspalvelimien edessä ohjaamassa ja uudelleenkirjoittamassa liikennettä.

itmo commented 11 years ago

ts. yhteyksien katketessa menetetään aina jotain toiminnallisuutta,todennäköisimmin pääsy suurimpaan osaan potilasdatasta. Koska kaiken potilasdatan kahdentaminen joka pisteeseen on mahdotonta/itsemurha, toinen vaihtoehto on että mahdollistetaan toiminta offline-tilassa mahdollisimman hyvin ja taataan yhteyksien katkeamattomuus varatiellä. Nykyseltään about joka paikkaan on saatavissa kustannustehokkaasti esim. lankalinja ja langaton yhteys, jotka voidaan liimata vpn-ratkasulla läpinäkyvästi kahdennetuksi yhteydeksi. Toinen ongelma on sitten keskitetty tietovarasto joka on SPOF mutta siitä ei pääse yli eikä ympäri, se on vaan kahdennettava/monistettava sisäisesti ja tehtävä siitä erittäin vikasietoinen, esim käyttämällä offsite kantareplikointia ja hajautettuja varastoja kuten cassandra.

itmo commented 11 years ago

@ztane imo disainin pitäisi olla sellainen että keskitetty varasto ottaa kantaa lähinnä tunnettuihin dokumenttimuotoihin. Päätesoftat voidaan sitten kilpailuttaa tarpeen mukaan erikseen, kunhan tottelevat annettua audit/kirjautumis/turvakäytäntöä. Avoimet rajapinnat joka suuntaan. Tämmösessä projektissa on hullua lähteä tekemään etukäteen jokaiselel käyttäjäryhmälle täydellistä pääteratkasua, niitä voidaan helpommin rakentaa jälkikäteen inkrementaalisesti ja samalla hyödyntää opittua.

itmo commented 11 years ago

Näen c#/windows stackin käyttämisen backend puolella ongelmaksi siksi että se on suhteellisen suljettu ja monopolistinen ympäristö. Javalla on etuna se fakta että se on avoin toteutukseltaan, lisenssiltään ja speksiltään.

d2s commented 11 years ago

@itmo Totta tuo Windows-backendin ongelmallisuus. Suuria haasteita tuottaa järjestelmän pidempiaikainen tukeminen kun vanhentuneeseen järjestelmään ei voida itse tehdä/tilata korjauksia jos havaitaan toimintaa häiritseviä bugeja esim. itse käyttöjärjestelmässä. Client-puolella Windows-softat eivät toki ole missään määrin poissuljettuja vaan yksi vaihtoehto muiden mukana.

Jokaisessa järjestelmässä on tietty omat ongelmansa enkä sano että mikään avoimen lähdekoodin systemi olisi lähtökohtaisesti vähemmän ongelmallinen. Pitää löytää sopiva yhdistelmä jolle on riittävän helppo kehittää vakaita ja toimivia järjestelmiä, kuormantasauksella ja vikasietoisuudella varustettuna. Lisäksi järjestelmät pitää testata niin koodin tasolla, käyttöliittymän toimivuuden osalta, tietoturvatasolla (oikeasti osaavien ammattilaisten avustuksella) sekä tietty tekemällä järjestelmän kriittisyyttä vastaavat rasitustestit (joissa selviää miten hyvin koodi/tietokanta/rauta kestää todellista rasitusta).

Javassa on omat oikeat ongelmansa suorituskyvyn osalta. Useampi todella suuria Java-pohjaisia sovelluksia pyörittäviä laiteympäristöjä ylläpitävä on kertonut että on ikävää kun joutuvat Java-softaa edelleen pyörittämään. Toisaalta, eipä tuo kait eroa monista keskuskoneista paljoakaan, paitsi softan siirrettävyydessä.

Symbiatch commented 11 years ago

@itmo No, jos tuolle linjalle lähdetään, niin katsopa huviksesi reikien määrä IIS7:stä lähtien ja Apachesta samalla aikavälillä. Saatat yllättyä aika reippaasti. Aina ei kannata miettiä vain tilannetta vuosikymmen sitten. Ja Apacheen ei tullut edes perchild-modulia, jota aikoinaan yritettiin, joten sillä onkin tosi ihanaa yrittää ajaa vaikkapa eri tunnuksilla eri sivustoja. Tässä tilanteessa merkityksetöntä toki, mutta silti muuten reaalimaailmassa ikävämpi juttu.

Ja minusta tärkein asia ei ole miettiä käytetyn alustan toteutuksen avoimuutta vaan sitä, millä järjestelmät saadaan toteutettua tehokkaasti ja järkevästi. Ja joka tulee olemaan käytettävissä vuosikausia sekä on rajapinnoiltaan stabiili. Ja monestiko törmätään käyttöjärjestelmässä ongelmiin tällaisissa järjestelmissä? Olisi kiva saada jotain tutkimustietoa vaikkapa eikä FUDia...

itmo commented 11 years ago

@symbiatch niin ja apache ei ole stabiili? sillä nyt kuitenkin pyöritetään vissiin 80% webistä suhteellisen onnistuneesti? Olisi todella kiva joo saada jotain faktaa eikä vaan tota FUDia. Kyllä mä ymmärrän että sun duunit riippuu siitä että microsoft menestyy. Ja käytännössä tommosta perchildia en ole nähnyt koskaan tarvittavan. Apache yleensä saa minimipermissiot jokatapauksessa.

ja noista perchild-tyylin moduleista.. niitä on ainakin 4 olemassa vaihtelevin featurein. sikäli kun sitä tarvitsee.

itmo commented 11 years ago

@jsalonen tjooh ja sitten tossa partitiointitilanteessa pitäis jotenkin olla "omien" potilaiden data käytettävissä, tuntemattomien potilaiden data lisättävissä ja audit/kirjautumis/pääsynhallinnan pitäis toimia.

Symbiatch commented 11 years ago

@jsalonen Nuo ovat mielestäni ensiarvoisen tärkeitä vaatimuksia, jotta järjestelmä voitaisi tehdä

@itmo Ad hominem ei ole ikinä fiksua, varsinkaan kun et tunne henkilöä pätkääkään, osoittaa vaan missä loppuu tietotaito. Jätän asian osaltani siis tähän.

d2s commented 11 years ago

@jsalonen Todennäköisesti aluekohtaisille replikoinneille olisi tarvetta niin että järjestelmä kykenisi palautumaan useiden yhteyksien katkeamisesta. Kysymys toisaalta on että miten hyvin tietojen päällekkäisyyksistä pystytään palautumaan mesh-verkon tyylisessä hajautetussa ratkaisussa jos samoihin tietoihin tulee eri paikoista päällekkäisiä kirjoituksia. Historiatiedon ja sen tallentajan tiedot on tärkeä tallentaa jotta pystyisi paremmin tekemään vakaata ja auditointikelpoista systeemiä.

itmo commented 11 years ago

@symbiatch ei se ollut ad hominem, se oli viittaus sun tarpeeseen myydä loputtomalla FUD-listalla kaupallista tuotetta jolla ei ole käytännössä minkäänlaista etua teknisessä mielessä.

itmo commented 11 years ago

@d2s tjoo. tommonen hajautetun noodiston muutosten synkronointi yhteyksien palatessa ei ole mitenkään triviaali juttu. Käytännössä jos haluttais "hieno" systeemi niin jokasen potilaan data makais sen kotilaitoksen koneella ja replika alueellisessa keskuksessa tjsp. Mutta taitaa mennä tommonen vähän overengineeringiks. Imo tekisin ennemmin siistin fallbackin alemman toiminnallisuuden tilaan jossa saatavilla on vaan kyky lisätä uutta ja lukea cachettunutta dataa. ja sitten se varatie niin että piuha ei katkea.

mikaelkundert commented 11 years ago

Peukut @d2s ja @itmo, mun mielestä backendin tulisi olla avoin softa... Lisäisin sen jopa @jsalonen listan jatkeeksi

itmo commented 11 years ago

@mikaelkundert sanoisin jopa avoin,avoin,avoin. ts avoimelle alustalle avoimella speksillä avointa softaa. Mitään syytä sulkea palaakaan siitä kaikkein kriittisimmästä komponentista ei oikeastaan ole.

mikaelkundert commented 11 years ago

Jep. Siteeraan repon etusivu tekstiä "Tämä repository on luotu muistuttamaan siitä, että avoin työskentely yhteisen asian puolesta olisi paras ratkaisu."

jsalonen commented 11 years ago

Kiitos palautteista! Täydensin vaatimuslistani raakiletta :)

@d2s Oon samaa mieltä, että todennäköisesti tosiaan pitäisi pystyä optimoimaan se, että järjestelmällä voisi keskeytyksettä tehdä kirjauksia verkon eri osissa -> järjestelmä pystyy käsittelemään rinnakkaiset muutokset järkevästi.

@itmo @mikaelkundert ehdottomasti samaa mieltä avoimien teknologioiden ja rajapintojen avoimuudesta. Lisään listan jatkeeksi.

jsalonen commented 11 years ago

Onko kellään muuten mitään hajua minkälaisi tietoturvavaatimuksia tällaisilla järjestelmillä konkreettisesti on?

Tällaisilla vaatimuksilla saadaan helposti vedettyä 90-100% teknologiavaihtoehdoista alas toiletista.

d2s commented 11 years ago

@jsalonen Hiukkasen on pintapuolista käsitystä tietoturvavaatimuksista mutta en todennäköisesti ole oikea ihminen arvioimaan sitä vaatimustasoa mitä tällaiselle järjestelmälle pitäisi asettaa.

Palvelinpuolen ja verkkoprotokollien osalta suosittelisin https://en.wikipedia.org/wiki/Fuzz_testing tyylistä testaustapaa jollaiseen löytyy asiantuntemusta ja Suomessa kehitettyjä työkaluja esim. Codenomicon http://www.codenomicon.com -nimiseltä firmalta. Edellämainitun firman syntysijoja on ilmeisesti ainakin osittain Oulun yliopiston tietoturvatutkimuksen tutkimukset. Kyseiset testausmenetelmät eivät kuitenkaan yksin takaa turvallisuutta, ne vain lisäävät potentiaalia löytää olemassaolevista/kehitettävistä järjestelmistä/protokollista/sovelluksista potentiaalisia aukkoja.

Hieman sanastoa tietoturvapuolen käsitteistä: https://www.ee.oulu.fi/research/ouspg/Glossary

mikaelkundert commented 11 years ago

Se mitä tulee sähköiseen palveluihin, niin siihen itse näkisin hyväksi vaihtoehdoksi käyttää PHP:n päälle rakennettua julkaisujärestelmää Drupalia, jonka kehitteillä oleva versio (8) tullaa käyttämään @TomiS mainitsemaa Symfonya. Drupalin avoin yhteisö on hyvin tehokas ja siinä mielessä erittäin luotettava, että sitä projektia tullaan kehittämään ja tukemaan pitkään.

Siitä saa paljon hyötyä irti kun siihen avoimesti saatavilla moduuleilla voidaan käyttää tehokkaasti WWW-sivujen muiden toiminnalisuuksien toteuttamiseen myös.

Siihen voidaan koodata installaatio profiileita, jotka muodostuvat valmiiksi konfiguroiduista Drupal moduuleista mikä tarkoittaisi sitä, että siitä voidaan muodostaa avoin tuotemainen asennettava paketti.

jsalonen commented 11 years ago

@d2s kiitos vinkeistä! Tietoturvapuoli ei tässä määrin ole omaakaan alaa. Onko muilla lisätietoja aiheesta?

ztane commented 11 years ago

Suomenkielisiä järjestelmään liitettäviä vaatimuksia voi vähän arvioida esim

d2s commented 11 years ago

@jsalonen Tiedän muutamia tietoturvapuolen testausta työkseen tekeviä mutta en ole varma haluaisiko yksikään heistä kommentoida tuota puolta julkisesti…

ztane commented 11 years ago

@mikaelkundert: tämä PHP/Drupal/Tiesmikä-keskustelu on jo käyty yllä. @d2s: kovin alhaisen tason katsanto tietoturva-asioihin, tosiasiassa siihen liittyy paljon muutakin, esmes jopa legitiimien käyttäjien hallinta, audit trailit, tiedon integriteetti - miltäs tuntus jos potilastiedot yhtäkkiä häviäis bittiavaruuteen. "Muistakkos oliko sulla X siinä röntgen-kuvassa joka otettiin susta otettiin viime vuonna"

d2s commented 11 years ago

@ztane Totta, käsitykseni ovat rajallisia koska en ole tehnyt työkseni laajamittaisia riskianalyysejä suuriin järjestelmiin. ;) Kiitos tarkennuksesta ja hyvistä linkeistä vaatimusmäärittelyihin.

Keväällä tuli osallistua tietohallinnon perusteita käsitelleeseen kurssiin, mutta en ole tosiaan senkään puolen ammattilainen vaikka paljon knoppitietoa onkin eri asioista löytyykin. Tietoturvaa on muuten tullut vuosien varrella opeteltua mutta varmasti muilta löytyy parempi kokonaiskäsitys todella monista asioista.

jsalonen commented 11 years ago

Hyviä linkkejä @ztane! Tuolta sais varmasti perattua lisää vaatimuksia.

Erityisen havainnollinen on mielestäni raportin R41-2008 ("Menetelmä sosiaali- ja terveydenhuollon tietojärjestelmien sertifiointivaatimusten tuottamiselle") kuvio 6 (s. 29), josta irtoaa ainakin seuraavaa pohdintaa:

Dokumenttien kautta poimittuja lisävaatimuksia:

Aiheeseen liittyviä standardeja lisäksi:

mikaelkundert commented 11 years ago

@ztane käsittääkseni yllä käyty keskustelu viittasi potilastietoihin. Olen samaa mieltä siinä, että mitään PHP+MySQL viritystä ei tehdä mihinkään tietojärjestelmän osan pohjaksi.

Itse tarkoitin sähköisen palvelun asioinnin alustaa, joka toimisi täysin näiden järjestelmien API-rajapintojen varassa.

d2s commented 11 years ago

@mikaelkundert "Kuluttajapuolen" asiointialusta on hyvin pieni osa kokonaisuutta, mutta on omat hyvät puolensa jotka tukisivat Drupalia yhtenä vaihtoehdoista web-käyttöliittymälle. Se ei kuitenkaan ole järjestelmien kokonaisuuden kannalta kuin yksi yksityiskohta.

mikaelkundert commented 11 years ago

@d2s kyllä, tähän yksityiskohtaan pystyn itse antaa oman inputtini mielelläni :)

ztane commented 11 years ago

Tässäpä taas lisää tavaraa joka sattui silmään - kaikkea sitä löytyykin http://www.openehr.org/home.html

ztane commented 11 years ago

https://github.com/suomi/potilastietojarjestelma/issues/5 Tuolta siis löytyy tuo WorldVista / VistA -systeemit, niitä vain testaamaan :-)

kakoni commented 11 years ago

@jsalonen Noista standardeista vielä että mukaan tarvitaan vielä

d2s commented 11 years ago

Kiitos muuten oikeasti kaikille näistä mittavista linkeistä ja esimerkeistä. Laittaa itsensä aika nöyrälle paikalle kun huomaa miten paljon asioita pitäisi ottaa huomioon jos lähtee yhtä henkilökohtaisen terveydenhuollon projektia kehittelemään eteenpäin… (sellaisesta on jotain alustavia suunnitelmia itsellä ja olen käynyt keskusteluja käyttäjänäkökulman vaatimuksista eri ihmisten kanssa). Aikalailla unrelated tähän kansalliseen projektiin nähden, mutta alkoi just huimaamaan nuo kansainväliset minimivaatimukset. :S

ztane commented 11 years ago

@kakoni noi taitaa koskea kaikki vain lääketieteellisten laitteiden firmistä, ei siis EMR/EHR:ää.

d2s commented 11 years ago

@ztane Toisaalta, täytyy ottaa huomioon että myös monet lääkintäpuolen laitteet ovat yhteydessä erilaisiin sairaalan tietojärjestelmiin ja niiden keskustietokantoihin syöttämän datan määrä tulee varmasti lisääntymään tulevaisuudessa. Datamäärät tulevat siis kasvamaan entistä nopeammalla tahdilla välineiden kehittyessä.

ztane commented 11 years ago

@d2s ei vaikuta, noi standardit koskee siis laitteita jotka voi suoraan tappaa potilaan :D

d2s commented 11 years ago

@ztane Voi kuule, voi se virheellinen datakin aiheuttaa saman jos esim. veriryhmä-kenttään tulee väärä kirjain näkyville… Vaikka kyseiset standardit eivät suoraan koskisikaan, voi niistä oikeasti ottaa esimerkkiä varmasti monissa asioissa.

ztane commented 11 years ago

http://www.computerworld.com/s/article/9137376/Open_source_software_may_unify_the_medical_records_realm tuossa hyvä artikkeli josta pääsee argumentoimaan.

kakoni commented 11 years ago

@d2s @ztane Lääkelaitteella (myönnän, nimi viittaa hardikseen) voidaan tarkoittaa myös puhdasta softaa. EUssa on voimassa lääkelaitedirektiivi (http://en.wikipedia.org/wiki/Medical_Devices_Directive) joka määrittelee lainsäädännön/asettaa vaatimuksia tuolle medikaalisoftalle. Helpoiten nuo vaatimukset täyttää jos käyttää noita ylhäällä mainittuja standardeja.

Tässä vielä lisää luettavaa http://www.emergogroup.com/resources/articles/software-as-medical-device