HUS – Potilastietoa miljardeilla
Normaalisti poliittisissa blogauksissani en merkittävissä
määrin korosta omaa osaamistani. Nyt on kuitenkin pakko tehdä poikkeus, sillä käsittelyssä
on HUS:n potilastietojärjestelmä ja Apotti-hanke. Kyseessä on jo aiemminkin
esiin nostamani kokonaisuudessaan hieman alle kahden miljardin euron
massiivinen hankekokonaisuus. HUS:n osuus tästä on 350–450 miljoonaa euroa.
Teen työkseni tietojärjestelmiä päällikkötasolla. Olen ollut
vetämässä ja osallisena useiden miljoonien eurojen hankkeissa. Silti HUS:n miljardiluokan
hanke ylittää selvästi oman kokemukseni ja tämän takia olenkin halunnut käyttää
riittävästi aikaa perehtyäkseni asiaan kunnolla ennen kuin sanon mitään
pitävää.
Potilastietojärjestelmä on massiivinen kokonaisuus.
Vaikeustasoltaan potilastietojärjestelmän rakentaminen on samaa luokkaa kuin globaali
logistiikan toiminnanohjausjärjestelmän rakentaminen Nokialle korvaten 200
vanhaa järjestelmää ilman tuotantokatkoksia.
Puheet ilmaisista ja helpoista ratkaisuista, joissa
kaikenratkaiseva hopealuoti tulee taivaalta, on syytä unohtaa saman tien. Populistisesta
käsienheiluttelusta ei ole kenellekään mitään hyötyä. Tämä ei ole ACTA, joka
kaadetaan suuren kansanjoukon hurratessa (ja hyvä, että kaatuikin).
Hankkeen käynnistämisestä päättää käytännössä Helsingin
terveyslautakunta. Materiaali päätöksiä varten on täällä.
Omat huomioni materiaalin perusteella on kuvattu
seuraavissa. Päätöksentekijöiden työtä helpottaakseni olen korostanut tekstissä
kappaleet, joihin ehdotan muutoksia.
== Halvin ei saa voittaa! ==
Esityslistan
perusteella HUS on valitsemassa hankkeelle yhden toimittajan, joka karsitaan
normaalissa neuvottelukilpailutusmenettelyssä valittavista toimittajista.
Lisäksi hankkeen esityslistassa ehdotetaan toimittajan valinnan kriteeriksi ”kokonaistaloudellista
edullisuutta”.
Tässä ollaan menossa pahasti metsään.
Kokonaistaloudellinen edullisuus on byrokraattista
kapulakieltä ja tarkoittaa suomeksi sitä, että halvin voittaa. Periaatteessa
näin ei ole, mutta käytännössä en ole kertaakaan nähnyt julkista tietojärjestelmää,
jossa ”kokonaistaloudellisesti edullisin” olisi esimerkiksi laadukkain.
Kun muistaa hankkeen koko pääkaupunkiseutua ja suomalaista
yhteiskuntaa vavisuttavan vaikutuksen, ensisijaisena valintakriteerinä ei pidä käyttää
edullisuutta. Hankkeen ensisijaisena
valintakriteerinä täytyy käyttää tulevan tietojärjestelmän vaikutusta
terveydenhoidon toimintojen tehostumiseen. Vain näin voidaan varmistaa,
että IT-investoinnista on oikeaa hyötyä.
Ehdottamaani valintakriteeriä voi perustellusti kritisoida
siitä, että toimintojen tehostumista järjestelmän avulla on vaikea mitata.
Mittari ei ole silti mahdoton. ROI-ajattelu toimintojen tehostumisesta on
arkipäivää kaikissa teollisuuden IT-investoinneissa.
Toinen hankinnassa
oleva ongelmallinen kohta on ajatus
vain yhden toimittajan valinnasta. Tällä liikkeellä HUS pelaa käytännössä
Suomen terveydenhoitoalan markkinat vain yhdelle toimittajalle, jolla on jatkossa
täysin ylivoimainen markkina-asema muihin toimittajiin nähden. Kaikki
arvannevat mitä hinnoille ja joustavuudelle tapahtuu tässä tilanteessa.
Hankinnassa pitää
edellyttää useita toimittajia ja ratkaisua, jonka Suomessa pystyy toimittamaan
joko osittain tai kokonaan vähintään kolme varteenotettavaa toimittajaa. Absoluuttinen
toimittajariippuvuus (vendor-lock-in) täytyy pystyä välttämään.
Hankinnallisesti asia voidaan järjestää esimerkiksi siten,
että valittavan toimittajan on
muodostettava yhteenliittymä vähintään kahden muun IT-alan toimittajan kanssa
siten, että yhdelläkään osapuolella ei ole yli 40 % osuutta toimitettavasta
kokonaisuudesta. Yhdellä toimittajalla on kuitenkin oltava kokonaisvastuu toimituksesta.
== Ongelmallinen hankintarengas ==
Toinen merkittävä ongelma hankkeessa on kunnallinen
itsehallinto. Hankkeessa esitetään, että hankkeessa mukana olevat kaupungit
(Helsinki, Espoo, Vantaa, Kauniainen, Kerava ja Kirkkonummi) muodostavat
hankintarenkaan.
Rengas sinällään on järkevä ajatus, mutta sitä ollaan
vesittämässä. Määritysten mukaan nimittäin ”hankintarenkaan kukin jäsen toimii
omana hankintayksikkönä”.
Suomeksi sanottuna tämä tarkoittaa sitä, että yksittäiset
kaupungit päättävät itsenäisesti mitä ne hankkivat käyttöönsä ja milloin.
Rakenne suorastaan kerjää ongelmia. Seurauksena tulee takuuvarmasti olemaan
useiden järjestelmien tilkkutäkki, jossa projektit etenevät eri tahtia ja jopa
toisistaan eroten. Lopputuloksena on tehoton nykytila, jossa kunnat toimivat
erikseen.
Tässä vaiheessa hanketta virhe on helppo korjata. Asia on korjattava tehokkaimmin siten, että
hankintarenkaan jäsenet sitoutuvat delegoimaan päätös- ja hankintavallan itse
renkaalle. Näin hankkeesta saadaan tehokas järjestelmien ja palveluiden
ostaja.
Pidän itse erittäin ongelmallisena sitä, että kokonaishankkeen
organisaatiossa ohjausryhmällä ei ole riittävästi päätäntävaltaa hankkeesta.
Merkittävä osa päätösvallasta on jakautunut kymmenien henkilöiden Kehittämis-
ja neuvotteluryhmille.
Hankkeella on oltava
yksi yhteinen ylin päättävä taho, jonka päätäntävallalle kaikki muut
organisaatiot ovat alisteisia. Luontevin tapa organisoida asia on määritellä
ohjausryhmä ylimmäksi päättäväksi tahoksi. Kehittämisryhmä, neuvotteluryhmä,
asiantuntijaryhmät ja hanketoimisto olkoot ohjausryhmän valmisteluelimiä.
Ohjausryhmän on myös erittäin perusteltua kokoontua joka
kuukausi.
Hankeorganisaatiossa on myös kauneusvirhe hankesuunnitelman kappaleessa
6.2. Kappaleessa määritellään, että valittu tietojärjestelmätoimittaja istuu
koko hankkeen ohjausryhmässä samaan aikaan kuin myös itse toteutusprojekteissa.
Näin ei pidä toimia. Muuten on suuri vaara, että toimittaja
käyttää koko hankkeen ohjausryhmän jäsenyydestä saamaansa asemaa hyödyksi ja
ohittaa yksittäisten projektien ohjausryhmän.
IT-toimittajia ei
pidä päästää jäseneksi koko hankkeen ohjausryhmään.
== Perustelumuistio ==
Ilokseni hankkeen perustelumuistiossa
on otettu huomioon monia tärkeitä tavoitteita. Näistä tärkein koskee avoimia
rajapintoja. Muistiossa todetaan näistä seuraavaa:
– mahdollistaa avoimet
rajapinnat, joiden kautta kokonaisratkaisuun voidaan liittää tulevaisuuden
tarpeita palvelevia lisätoiminnallisuuksia tai vaihtaa yksittäisiä ratkaisun
osia. (s. 2).
Tässä kannattaa olla kuitenkin tarkkana. IT-kielessä
nimittäin jonkun asian ”mahdollistaminen” tarkoittaa ikävän usein samaa kuin
että ei tehdä, mutta on mahdollista tehdä isolla rahalla jälkeenpäin. Hyödyt
jäävät saamatta.
Kappale kuuluu paremmin seuraavasti:
– Hanke toteuttaa rakennettavaan tietojärjestelmään
avoimet rajapinnat. Niiden avulla kokonaisratkaisuun voidaan liittää
tulevaisuuden tarpeita palvelevia lisätoiminnallisuuksia ja näitä laajennuksia
pystyy tekemään myös muu kuin alkuperäisen järjestelmän toimittaja. Toteutettavien
rajapintojen kautta on myös mahdollista vaihtaa potilastietoa avoimesti
dokumentoituja sanomavälitysrajapintoja pitkin muiden julkisen ja yksityisen
sektorin potilastietojärjestelmien kanssa.
== Hankesuunnitelma ==
Suunnitellun potilastietojärjestelmän hankesuunnitelma
on 56-sivuinen dokumentti, joka asiasta päättävien on erittäin tärkeää tuntea.
Dokumentin on perustanut Heikki Onnela,
joka on toiminut Sirius-kartoitushankkeessa Accenturen alihankkijana. Toinen
merkittävä kirjoittaja on Mikko Rotonen,
HUS:n tietohallinnon IT-kehitysjohtaja. Sisältöä on tuottanut myös Helsingin terveysasemien
johtaja Antti Iivanainen.
Hankesuunnitelmassa luvataan (s. 7), että rakennettavan
tietojärjestelmän takaisinmaksuaika on 6-8 vuotta. Väite on rohkea ja jos se
pitää paikkansa, hanke on kokonaisuudessaan kannatettava.
Mutta mihin takaisinmaksuaika on hävinnyt hankkeen
kokonaistavoitteista? Takaisinmaksuaika (ROI)
on liitettävä osaksi hankkeen tavoitelistaa. Ei kuitenkaan liian tiukkana.
Takaisinmaksuaikana näin suuressa kokonaisuudessa 10 vuotta on riittävä. Asia
voidaan myös pisteyttää laatukriteereissä toimittajaa tai toimittajia
valittaessa. (Kappale 2.2.3 s. 14).
Hankesuunnitelmassa esitellään myös tavoitteiden mukaisten
järjestelmän tarjoamia hyötyjä. (Kappale 2.2.4 ja myös Liite 2 s. 41).
Sisältönsä puolesta kappale on ok, mutta lähestymistapa on väärä. Hankkeessa täytyy edellyttää luvattujen
hyötyjen toteutuminen. Ne eivät saa jäädä mahdollisten esimerkkien
asteelle.
Aikaisemmat kommenttini IT-alan slangin ”mahdollistamisesta”
pätevät myös tähän kappaleeseen. Hyötyjä ei siis pidä ”mahdollistaa”, vaan edellyttää. Malliesimerkkinä tästä on yhteinen
käyttäjätuki. Sen toteuttaminen osana hanketta on paitsi täysin mahdollista,
myös taloudellisesti erittäin perusteltua. Ei ole mitään syytä miksi tämä
jätettäisiin puolitiehen.
Hankkeessa tulee todennäköisesti vastaan useita
vanhanaikaisia työnkulkuja, jotka eroavat eri kaupungeissa toisistaan. Jos
hankittava tietojärjestelmä räätälöidään vastaamaan kunkin kaupungin
työnkulkua, lopputuloksena on hajanaista sotkua. On erittäin suositeltavaa,
että hankkeen aikana tutkitaan missä osallistujakaupungissa on paras työnkulku
ja tietojärjestelmä toteutetaan tämän mukaisesti. Muut osapuolet mukauttavat
toimintatapansa tämän vakioidun toimintatavan mukaiseksi.
Hankesuunnitelmassa
kohdassa 2.2.2 (s.13) aloittavan virkkeen on tulee kuulua seuraavasti:
Hankkeen päätyttyä
kunnilla ja kuntayhtymillä on yhtenäiset sosiaali- ja terveyspalveluiden
toimintamallit ja toimintaprosessit…
Sama tulee ottaa huomioon myös kappaleessa 2.9 (Hankkeen
onnistumisen kriteerit). Ensimmäisen ja toisen ranskalaisen viivan tulee kuulua
seuraavasti:
- Osapuolet
sitoutuvat yhtenäistämään toimintamallinsa ja toimintaprosessinsa. - Uusien toimintamallien
ja toimintaprosessien käyttöönotto toteutetaan viimeistään osana tietojärjestelmän
käyttöönottoa.
Tähän liittyen kappale 3.1.8 (Toimintamallien määrittely)
tulee kirjoittaa kokonaan uudestaan.
== Muita tärkeitä vaatimuksia ==
- Järjestelmän rajapintojen on oltava avoimia ja niihin on pystyttävä liittymään
sekä muista sairaanhoitopiireistä, että myös yksityisilta palveluntuottajilta. - Järjestelmän täytyy olla teknisesti
nykyaikainen. - Hankkeessa on suosittava ketteriä
kehitysmenetelmiä ja niiden tulee olla aina mahdollisia yksittäisissä
toteutusprojekteissa. - Hankkeen ohjausryhmän on erittäin aiheellista
palkata avukseen konsulttitalo, joka auttaa hankkeen valvomisessa ja toimii
neuvonantajana. Luonnollisestikaan nämä konsultit eivät saa toimittaa
ensimmäistäkään osaa itse tulevasta tietojärjestelmästä. Mikäli tämä valitaan
toimintatavaksi, hankesuunnitelmassa esitetty kaksi miljoonaa euroa PMO:n
toimintaan on alakanttiin. On
suositeltavaa lisätä hanketoimiston resursseja. Tässä tapauksessa
huolellisesti hallittu on lähes puoliksi tehty. - Koska hanke on erittäin suuri, on perusteltua,
että hankkeen ja sen aliprojektien sekä työryhmien ohjausryhmien muistiot julkaistaan
välittömästi avoimessa Internetissä, eikä niitä jätetä vain extranet-julkaisun
varaan. - Hankkeen auditoijilla täytyy olla oikeus
tarkistaa myös valitun IT-toimittajan tai -toimittajien työn
sopimuksenmukaisuus.
Tarkennuksena tähän vielä, että varteenotettavia IT-toimittajia Suomessa on noin kymmenkunta kappaletta. Varteenotettava tarkoittaa esimerkiksi usean miljoonan euron liikevaihtoa, vähintään 200 hengen henkilökuntaa ja niin edelleen.
Yhteenliittymät IT-hankinnoissa ovat varsin tavanomaisia. Ja silloin ei tietenkään pidä sallia yhden konsernin eri osastojen muodostavan eri osuuksia.
Tässä tapauksessa voitaisiin jakaa kakku esimerkiksi siten, että infran toimittaa A, järjestelmän rakennusprojektin ja pienkehityksen B ja sovelluksen elinkaaren ylläpidon C.
Ilmoita asiaton viesti
http://marjattahalkilahtiblogituusisuomifi.puheenv…
Toivottavasti Helsingin seudun hanke saa niin paljon kylmää kyytiä, että ne, jotka suunnitelman ovat alulle panneet, tajuavat itsekin missä mennään ja ennenkaikkea sen mitä ihan oikeasti tarttis tehdä.
http://www.uusisuomi.fi/kotimaa/53388-kansalaiset-…
http://www.uusisuomi.fi/kotimaa/53381-helsingissa-…
Ilmoita asiaton viesti
Olet aivan oikeassa siinä, että potilastietojärjestelmän pitäisi olla yhtenäinen koko maalle. Tämän aikaansaanti on kuitenkin vielä dekadiluokkaa vaikeampaa.
Jos tämä Stadin seudun hanke onnistuu, muu maa voi hyvin seurata perässä.
Ilmoita asiaton viesti
Hyvä kirjoitus Ossi Halkilahti, mutta ikävä kyllä taitaa olla käytännössä turha. Miten kepujohtoiset kunnat saadaan omaksumaan jotain pääkaupunkiseutujuttua? Ei mitenkään, koska silloinhan ne menettäisivät kunnallista itsemääräämisoikeuttaan.
Koko jutusta tulee sekasotku, kuten niin usein Suomessa on käynyt esim. kaikkien kansalaisten henkilökortti. Edustajiamme viedään kuin pässiä narussa kohti ”maailman parasta ja uudenaikaisinta järjestelmää”. Tämä tietää ainakin kahden-kolmen vuoden viivästymää aikataulussa ja yli 30 %:n ylitystä kustannuksissa. Lisäksi järjestelmät tulevat toimimaan niin huonosti, että hallintohenkilökuntaa on lisättävä. Rahaa ei riitä kaikkeen, joten hoitavia käsiä vähennetään.
Ilmoita asiaton viesti
Helsingin seudulla itse asiassa kuntaliitos etenee tämän tietojärjestelmäprojektin myötä. Ehkäpä myös maakunnissa?
Järjestelmä kannattaa alusta alkaen rakentaa sellaiseksi, että siihen voidaan kytkeytyä muista maakunnista. Ja ainakin suurista kaupungeista (Tampere, Oulu, Turku jne.).
Ilmoita asiaton viesti
No ei tuohon projektiin nyt kannata mitään ”open sourcea” kopsata. Tuo on valtava projekti, joka vaatii kunnollisen määrittelyn ennen kuin voidaan edes kilpailuttaa mitään.
Tämä vaatisi tekijöitä myös omassa organisaatiossa. Mutta onko heitä? Vai onko kaikki IT-työntekijät jo potkittu pois tuosta tilaajaorganisaatiosta??
Jos on, niin se on tosi paha juttu! Määrittelyprosessissa pitää olla sekä tietojärjestelmä-ihmisiä, että myös sellaisia käyttäjän edustajia, jotka pystyvät kartoittamaan tilannetta yhdessä IT-osaajien kanssa.
Kunnollinen määrittelyvaihe on kaiken perusta ja siitä tulee laatia myös kunnon dokumentit, joiden perusteella toteutus ja testaaminen hoidetaan. Ellei tällaista määrittelydokumentointia ole, ei voida myöskään aloittaa toteutusvaihetta.
Pahoin pelkään, ettei tuosta järjestelmästä tule kovinkaan onnistunutta. Kunnollinen osaaminen taitaa puuttua. Ei tässä muu auta kuin odotella vaan sitä päivää, kun uusi sovellus otetaan käyttöön. Voi kestää kotvanen tuohon päivään.
EV
Ilmoita asiaton viesti
Juuri näin. Open source on vain sivulauseen alaviite. Tässä puhutaan isosta ja erittäin monimutkaisesta järjestelmästä. Voi siihen open source -komponentteja ympätä mukaan, mutta se on vain detalji.
Ilmoita asiaton viesti
Hyvää pohdintaa. Tässä toki pari asiaa, jotka ovat minua askarruttaneet.
”Kokonaistaloudellisesti edullisin” oli mielestäni hieman heppoisasti määritelty. Kärjistäen voisi todeta, että hanke A kilpailutetaan ja saadaan kaksi hyvää tarjousta, lopuissa on niin paljon lähtökohtaisesti pielessä. Ensimmäinen tarjous tulee kotimaasta hintalappuna olkoon vaikkapa miljoona euroa. Toinen tulee Kiinasta, mutta hintalappu onkin vain 600 kiloeuroa. Oletetaan lisäksi, ettei suuria muita eroja tarjouksissa liiemmin ole. Kumpi on kokonaistaloudellisesti edullisempi, kun toisessa hankkeessa suomalaiset pakertavat, maksavat tuloveroja, firma yhteisöveroa ja sitten syntyy jokin palvelu, joka nostaa elämänlaatua – ja tapauksesta riippuen voi tuoda vielä ALV:n muodossa kassavirtaa valtiolle?
Mainintasi investoinnin järkevyydestä toki pitää paikkaansa, mainitaan sekin, ettei minua lueta tahallaan väärin. 🙂
Halkilahden peräänkuuluttama valtakunnallinen järjestelmä on pohtimisen arvoinen. Lähdit itsekin riskienhallinnan kautta (hyvä niin!) pohtimaan, josko kuntarenkaan sisällä aloitetaan ns. sooloilemaan. Huomaamatta kuitenkin jäi se, että renkaan ulkopuolella olevat alueet voi tarvita niinikään kommunikointia renkaan sisäpuolen kanssa. ”Koekaniinin” koon arviointi on varmasti aina vaikeaa. Joku pitää sitä liian massiivisena ja siksi riskialttiina, kun vaakalaudalla on niin paljon ihmisiä. Toisten mielestä taas ei tipottain pitäisi tehdä yhtään mitään.
Mutta mikä tässä HUS:n toimessa sitten maksaa niin jumalattomasti? Moni vertaa Viron tapaukseen: sen nopeuteen (hanke vuodessa) ja edullisuuteen. Laskutoimitukset vilisevät monella saitilla, jotta kuinka monta koodaajaa tällä loppusummalla palkattaisiin vaikka 20 vuodeksi eräänlaisella oletuspalkalla. Tätähän tässä haetaan takaa: onko se ”kokonaistaloudellisesti edullista”?
Ajattelen rahaa niin, että se määrää (allokoi) sen, miten resurssit (energia, ruoka yms.) jaetaan. Jos tässä allokoidaan parille sisäpiiripampulle muutama sata miljoonaa niin ne tuskin käyttävät kaiken sen leivän ostamiseen, jolloin ”kokonaistaloudellisesti” hyöty jää laihemmaksi kuin silloin, kun resurssit allokoidaan tasaisemmin useammalle tekijälle.
Ilmoita asiaton viesti
Suomeen Accenturen suunnittelema Epic-järjestelmä perustuu MUMPS-ohjelmointikieleen. Kyseisestä sikotaudista voi lukea lisää WTF-sivustolta: http://thedailywtf.com/Comments/A_Case_of_the_MUMP… — Jos haluaa objektiivisemman kuvan siitä minkä roskan päälle Suomen järjestelmää ollaan nyt 1,8 miljardilla rakentamassa lukekaa Wikipediasta lisää, se ei juuri tuosta WTF linjasta eroa. Jos ei tuohon jaksa perehtyä niin suosittelisitko itse ohjelmointikieltä jossa 5+10*3=45? Tuo vain pieni esimerkki MUMPSin ”featureista”, noita MUMPS koodiesimerkkejä ei voi lukea nauramatta.
Ilmoita asiaton viesti
”Sairaalan työ tietokoneohjelmien kehittäjänä lääketieteelliseen käyttöön 1960-luvulla johti MUMPS ohjelmointikielen syntyyn”. (Wikipedia).
Kiitos Jani Kajala. Oikeastaan enismmäinen kunnon asiantuntijalausunto. (Toki Ossi Mäntylahden ohella) Lyhyt ja toimiva, enkä voi olla havaitsematta pientä ironiaa tekstisi sisällä:) Eli alusta on kehitetty 1960 luvulla. Onko se miten paljon kehittynyt noista ajoista? ´
En väitä olevani asiantuntija. ATK-laitteiden kanssa kyllä touhunnut. Käsittääkseni hankittava paketti on yksinkertaisuudessaan tietokanta juttu, jota päivitetään potilaskohtaisesti jakoon. Voi olla, että olen väärässä, mutta ei tuo tietokannan hallitseminen niin ylivertainen homma ole. Tarvittavan ohjelmiston voisi rakentaa suhteellisen helposti aina koodauksesta, kielestä asti.
Uhkakuvana koko maan kattavassa tietokantajutussa, jossa on esim. sosiaalitoimi mukana, näin ymmärsin, lienevät tietoturvaan ja tuhansien käyttäjien pääsyn sormeilemaan tietoja. Pari tahatonta virhelyöntiä ja fyysinen henkilö, voi muuttua aivan joksikin muuksi.
Toinen ongelma lienee nykyisten tietokantojen syöttö mahdollisimman nopeasti erilaisista ohjelmistoista uuteen. Onko niin, että juuri MUMPS ohjelmointikielen kielen akilleen kantapää on ymmärtää, kommunikoida toisenlaisiin alustoihin perustuvien tietokanta ohjelmien kanssa?
Kuten kerroin en asioista juuri mitään tiedä. Kysyn vain?
Ilmoita asiaton viesti
Ohjelmointikieli on vuodelta 1967 ja siihen perustuva Epicin alusta on tehty myöhemmin (80-luvulla?), mutta ongelma joka tapauksessa johonkin tuollaiseen muinaisjäänteeseen perustuvassa systeemissä on se että ensinnäkään et löydä helposti ohjelmoijia jotka ko. kieltä osaavat. Ylläpidettävyys ja vendor-lock-innin välttäminen on toiveunia. Toisekseen ohjelmointikielet ovat kehittyneet tuon jälkeen selvästi ja noita MUMPS-esimerkkejä ei voi tosiaan lukea irvistelemättä — niistä on luettavuus ja selkeys kaukana. Lähdekoodin luettavuus ja selkeys pitäisi olla ykkösprioriteetteja kun jotain noin tärkeää järjestelmää kehitetään. Kun lähdekoodi näyttää tuollaiselta kryptiseltä moskalta kuin MUMPSin koodi näyttää, niin koko järjestelmästä ei tule ikinä toimivaa.
Tietokannan hallitseminen ei pitäisi tosiaan olla kovin ylivoimaista varsinkin kun ottaa huomioon että Suomessa on vain noin 5 miljoonaa potentiaalista asiakasta jonka tiedot pitää tuohon systeemiin saada. Vaikka vanhoja järjestelmiä olisi käytössä n.200, niin silti ”puoli miljoonaa per järjestelmä” pelkästään tietojen siirtoon pitäisi olla enemmän kuin varsin avokätinen budjetti. Ja jos kerran siirtoon menee silloin 100M, ja Virosta saadaan järjelmältä 10 miljoonalla, niin eikö 110M euroa pitäisi riittää vallan mainiosti? Jäisi hyvin rahaa vielä koulutukseenkin ja silti projekti pysyisi 300 miljoonassa. Nuo Accenture-luvut ei kestä pyörittelyä millään tasolla.
Ilmoita asiaton viesti
Olen samaa mieltä MUMPS:n vanhanaikaisuudesta ja huvittavuudesta, vaikka käytettävän ohjelmointikieln perusteella järjestelmän laadusta argumentointi on todellista nörttipornoa. Osittain tämän takia esitänkin, että yksi järjestelmän kriteereistä on yksinkertaisesti se, että hankittava järjestelmä on tekniikaltaan nykyaikainen.
Ilmoita asiaton viesti
Olet oikeassa että ohjelmointikieleen vetoaminen on aika nörtteilyä, mutta on tuossa silti monia seurauksia, mm. MUMPSia osaavien ohjelmoijien löytämisen vaikeus, ylläpidon vaikeus, toteutuksen vaikeus ja vendor lock-in, jotka pitäisi kelvata argumenteiksi maallikoillekin.
Ilmoita asiaton viesti
Eli nyt tarjottava systeemi, mumpsin päivitys ei ole hyvä alusta. Vaan toimivaan systeemiin vaaditaan nykyaikaisempi vaihtoehto. Esim. paljon puhuttuun avoimeen lähdekoodiin perustuva ohjelmisto, jolloin kaikki munat tulevaisuudessa eivät ole samassa korissa.
Saa nähdä miten käy?
Ilmoita asiaton viesti
Ei ole nörttipornoa alkuunkaan. Pikemminkin jonkun MUMPSin suositteleminen on tyylipuhdasta pölhöpopulismia, jolla Accenture on onnistunut höplöttämään täkäläisiä päättäjiä. Kukapa ei voisi olla luottamatta järjestelmään, jonka nimi on Massachusetts General Hospital Utility Multi-Programming System? Nomen est omen, mumps sattuu tarkoittamaan myös sikotautia.
Kukaan nykyaikaisia ohjelmointikieliä opiskellut nykynuori ei yksinkertaisesti *halua* työskennellä jonkin niin kammottavan ja muinaisen, aivot nyrjäyttävän ohjelmointikielen kanssa, jos parempia töitä löytyy muualtakin. Niinpä MUMPS-koodin ylläpito pitää ulkoistaa niille muutamalle MUMPS-osaajalle, joita maailmasta enää löytyy, ja he voivat kiskoa työstään tähtitieteellisiä summia.
Yhteiskunnalle olisi ilman muuta paljon järkevämpää, että Suomen työttömille olisi töitä. Kansallisesta järjestelmästä pitää ilman muuta mobilisoida kansallinen, yhteistä hyvinvointia parantava projekti. Siinä teille poliitikoille ihan oikeita töitä! Suunnittelu, ohjelmointi, testaus ja tietojen syöttö järjestelmään voisi työllistää valtavan lauman työttömiä ja projektin hyödyt voisivat siten ulottua aina nuorten työllistymiseen ja syrjäytymisen ehkäisemiseen asti.
Toivon sydämestäni, että järkevät poliitikot onnistuvat torppaamaan tämän mielettömyyden.
Ilmoita asiaton viesti
//****
Ihmettelen, mitä ihme superihmisiä Suomessa ollaan kun ei jokin valmis maailmassa oleva systeemi kävisi tännekin. Ei tarvitsisi kehittäää kaikkea biteistä asti.
//****
Näytti se cache ja MUMPS olevan yhden Intersystems firman takana ja jossain luki patentoitu. Sillä on tehty historiallisista syistä juttuja.
Se elää omaa elämäänsä. Ohjelmoijat ja konsultit kehuvat rypevänsä rahassa.
Siitä jää puuttumaan avoimuus ja tietojenkäsittelyn evoluutio.
Ihmettelen, että joku edes ajattelee rakentaa systeemeitä ilman SQL:ää.
Siihenkin voi työntää noita java scriptejä ja vaikka kaikki potilastiedot.
Kaikki kehitysympäristöt käyttävät sitä. Saahan SQL:n konvertoitua 101 % varmuudella sitten seruaavan tietokantastandardiin 50 v kuluttua , mikä ei ainakaan ole historiallinen mums/cache. Kaikki muut kehitysympäristöt ja systeemit nojaavat SQL kantoihin. (lukkunottamatta leivänpaahdinta, johon saa SQLiten:n)
Hurjimmilta kuulosti nuo määrittelemättömät muuttujat ja niiden globaalius tai näkyminen ohjelman ulkopuolelle ja ettei ole varattuja sanoja. Joutuu ajattelemaan ohjelmointia 1970-luvun tyyliin. Joskus tein Fortranilla jotain ja se oli vaaraksi mielenterveydelle jo.
Nykyään ohjelmat maalataan ja tehdään nopea prototyyppi. 1960-2000 aikana ilmeisesti MUMPSin vahvuus oli saada proto äkkiä.
Ainakin Windows C# kielessä voi tehdä juuri noita hakuja helposti, koska kieleen on upotettu mahdollisuus hakea tieto ja sortata se muistissa. Puhutaan Linqstä ja Entity Frameforkistä, jotka on valovuoden edellä. Voidaan tehdä tekstihakuja ja saa ne heti näyttöön taulukoksi jne. Tuommoisen potilaskortiston saa kasaan päivässä. Tietysti koko HUS systeemi on jotain muuta.
Jos vertaa jotain C++ tason kieltä, jos M on sellainen on, vähän kuin vertaisi mopoa ja ferraria kun vertaa C# + Windows liittymää. Toisessa kirjoittaa viikkoja spagettia ja toisessa maalailee ikkunoita ja tekee muutamalle riville sen logiikan.
Postgressissa ja Oraclessa SQL:ssä pyörii maailman isoimpia tietokantoja ja pelaukset ja muut kehittyneet tekniikat on valmiita.
//****
Ilmoita asiaton viesti
Minä haluan tarkempaa erittelyä, koska myös moottoritie, jota hintaluokkaa tämä hanke edustaa, on tiukan arkkitehtuurin mukainen hanke. Moottoritiessä liittymät maksavat, mutta ne suunnitellaan ja kokonaisurakka voidaan kilpailuttaa osa kerrallaan.
Siis mikä on arkkitehtuuuri ja sen osa kustannuksista, mitä maksavat tietovarastot tietoturvineen ja edelleen käyttäjä- ja muutoshallinta?
Arkkitehtuuriin kuuluu rajapintojen suunnittelu, mitkä ovat vähimmäisvaatimukset liittyville järjestelmille.
Eli rätingit esiin.
Ja alkeellisinkin tietojärjestelmien tai tietoturvastandardien kanssa ollut ihminen tuntee erottelun testauksen ja tuotannon välillä. Järjestelmää ei oteta käyttöön mikäli siinä on dokumentoimattomia toiminnallisuuksia eli virheitä.
Ilmoita asiaton viesti
Kiitos! Erittäin pätevältä vaikuttava analyysi tärkeästä aiheesta. Pelkona on, että julkisyhteisöistä tulee tässäkin lypsylehmiä yhdelle suurelle toimijalle. Sellaisesta on tässä maassa kokemusta.
Hyvää referenssiä voitaneen saada Virosta (en siis väitä, että heidän potilastieojärjestelmänsä luominen olisi ihan sama juttu kuin Suomessa, mutta silti pistää miettimään, että hinta on alle 1 % Suomen vastaavasta). Kyllä julkinenkin valta saa kohtuuhintaan, kun vain halua ja tiukkuutta löytyy.
http://www.laakarilehti.fi/uutinen.html?opcode=sho…
Karkealla matematiikalla 1,8 miljardia on noin 18000 hyvin palkatun it-ammattilaisen henkilötyövuotta.
Ilmoita asiaton viesti
Tämä 1,8 miljardia euroa on koko valtakunnan tasolla oleva summa. HUS:n osalta puhutaan sentään ”vain” 350-450 miljoonan euron investoinnista. Ja tässäkin on muuten kyse __kymmenen vuoden kokonaiskuluista__. Nykyisellään tietojärjestelmien pyörittämiseen menee 49 miljoonaa euroa vuodessa. Yhteensä siis tällä kaudella 490 miljoonaa euroa.
HUS:lla on yli 200 vanhaa erillistä sirpaleista järjestelmää. Niiden ylläpitoon ja purkalla pystyssä pitämiseen menee ihan oikeasti rahaa.
Silti kallista lystiä. Ja tämän takia hankinta on valmisteltava hyvin.
Ilmoita asiaton viesti
Tuossa yläpuolella ollaan lähdössä hyvän matkaa p edellä puuhun ellei peräti puu edellä p:een. Lähdetään ratkomaan teknisiä ja ohjelmiston hankintaprosessin loppupään yksityiskohtia ennenkuin kukaan missään tietää mitä järjestelmältä odotetaan ja mitä sillä tulisi hoitaa.
Järjestelmä ja etenkin sen tekninen toteutus pitäisi olla aina ja joka paikassa vihonviimeisenä ratkaistava asia. Ensisijaista olisi, miten toiminta järjestetään: mitkä ovat toiminnan tavoitteet ja millaisilla toimintaprosesseilla ne saavutetaan ja mitä tietoja siinä yhteydessä tarvitaan. Sitten kun sellaiset on saatu ratkaistua, tulee ratkaista mitä osia ja miten ratkaistaan tietoteknisillä ratkaisuilla. Sen jälkeen voidaan katsoa millaisia tietojärjestelmiä tarvitaan ja vasta lopuksi katsoa mistä sellaiset järjestelmät hankitaan ja millä laitteistoilla ja tietoliikenneyhteyksillä niitä ajetaan. Vasta sen jälkeen alkaa koodaaminen siltä osin kuin se on tarpeellista.
Terveyden ja sairaanhoitoalalla on toki asioita pähkitty ja toimintoja jo hoidettu vuosikymmeniä ICT:aa hyödyntäen. Löytyy myös toimialalle kehitettyjä konsepteja ja toimintamalleja sekä valmiita ohjelmistokikkareita. Ongelma on kuitenkin, että ICT:llä on aiemmin haettu, ja toki löydetty, tehostamista muuttamalla vanhoja paperilla toimivia prosesseja sähköisiksi ja osittain automaattisiksi. Se tie on nyt kuitenkin kuljettu loppuun myös terveyden ja sairaanhoidon alalla. Meillä on joukko keskenään ei-yhteentoimivia järjestelmä palasia joilla hoidetaan yksittäisiä ja pieniä osakokonaisuuksia. Pohdiskelemalla mumps- tai humps-tason ratkaisua ei päästä tästä sotkusta eteenpäin.
Suurin virhe joka nyt voitaisi tehdä, olisi lähteä konvertoimaan olemassaolevien päällekkäisten ja rinnakkaisten järjestelmien toiminnallisuuksia taas kerran uudelle teknologialle ja uusiin ohjelmistoihin. Niin saadaan vanhastaan megalomaanisiksi kasvaneista järjestelmistä jälleen kertaluokaa monimutkaisempia (lue: kalliinpia).
Nyt pitäisikin lähteä katsomaan koko sairaan- ja terveydenhoidon prosesseja avoimesti ilman paperimaailman rajoitteita ja ihmisen elinkaaren näkökulmasta – ja todella koko valtakunnan tasolla. Silloin pitäisi olla valtaa ja voimaa sekä järkeä katsoa olemassa olevia hoito- ja hallintoprosesseja niille asetettujen ja asetettavien toiminnallisten tavoitteiden, tässä tapauksessa ihmisen terveyden edistäminen, näkökulmasta. Silloin niin organisaatiot kuin tietojärjestelmätkin ovat myöhemmin ratkaistaistavia yksityiskohtia. Niiden aika tulee kun tiedämme mitä haluamme ja miten haluamme sen halutun toimivan.
Ilmoita asiaton viesti
Olen aivan samaa mieltä siitä, että tässä yhteydessä on myös uudistettava prosesseja.
Ilmoita asiaton viesti
Olkoon kuinka megalomaaninen järjestelmähanke tahansa niin sen kustannukset ja vaikeustaso todennäköisesti on silti selvästi kertaluokkaa pienempi kuin yritys muuttaa sairaan- ja terveydenhoidon prosesseja ja käytäntöjä.
Silloin jos vastassa ovat ihmiset joita ei kiinnosta paitsi tittelit ja arvovalta niin soppa on valmis. Yritä siinä sitten muutosta. Vaikeusaste kasvaa potenssiin ja hanke paisuu eli juuri päinvastoin kuin pitäisi.
Pitäisi hakea nopeita voittoja ja selkeitä konkreettisia mitattavia hyötyjä hankkeen aikana. Ettei jäädä vain odottamaan sitä suurta isoa valmista joka ei koskaan valmistu.
Sekin vielä että puhutaanko sovelluskehityksestä vai järjestelmäkehityksestä? Aika iso ero. Myös elinkaaren hallinnan näkövinkkelistä.
Kai nyt ainakin tietoturva/tietosuoja on huomiotu riittävästi?
Ilmoita asiaton viesti
Silloin kun vastassa on vain titteleistään ja asemastaan kiinnostuneet niin minkäänlainen uudistus ei onnistu, ei edes pienimmän kikkareen konversio.
Prosesseihin puuttuminen on ainoa keino poistaa monimutkaisuutta. Se kun on syntynyt nykyisiin prosesseihin ja menettelyihin vuosikymmenten aikaisena ja laajasti hallintokulttuuri mukaan ottaen jo vuosisatojen aikaisena evoluutiona. Tunnistan toki myös, että niihin puuttuminen on vaikeaa, työlästä ja katkeruutta aiheuttavaa. Vaikeuksia ei kuitenkaan vältetä vaikenemalla ja unohtamalla ne ja yrittämällä hoitaa homma pyörittelemällä teknisiä yksityiskohtia. Sillä vain varmistetaan, että VTV:llä on jatkossakin asiaa vuosikymmeniksi venyvistä projekteista.
Ilmoita asiaton viesti
Myyryläinen. Prosessit ovat avainasemassa kuten kerroit. Liittyvät haasteet vaan on syytä tiedostaa ja huomioida.
Prosessit olkoon ne kuinka vanhakantaisia ja puutteellisia tahansa ovat nekin ainoastaan työkaluja. Siitäkin huolimatta että joku voi löytää niille myös itseisarvon.
Prosessien tehtävä on pitää paketti jollakin tavalla kasassa. Prosessien perimmäinen tehtävä on mahdollistaa itse tehtävän suorittaminen – yksinkertaistettuna sairaanhoito.
Tarkoittaa kääntäen että aina kun tietojärjestelmiä TAI prosesseja halutaan muuttaa on muutokset tehtävä varsinaista tehtävää (sairaanhoitoa) vaarantamatta. Jos on vaara että suorittavan portaan ajankäyttö ja fokus alkaa siirtyä potilaiden hoitamisesta enemmän tietojärjestelmien ja prosessien kehittämiseen aletaan olla pahasti väärillä raiteilla. Ja kuka muu niitä prosesseja kehittäisi kun ne jotka jo nykyiset prosessit tuntevat. Ainakin joutuvat osallistumaan.
Mitä itse järjestelmään tulee niin väittäisin että potilastietojärjestelmän ehkä tärkein ominaisuus (potilastietojen eheyden jälkeen) on järjestelmän helppokäyttöisyys tavallisen työtään tekevän lääkärin/hoitajan/whatever näkökulmasta katsottuna. Sekin tukee prosesseja.
Ja asian toinen puoli. Kyseessä on järjestelmä jonka sisältämien tietojen varassa on potilaiden terveys ja henki. Tämä tuntuu joskus unohtuvan kun rahasta keskustellaan.
Ilmoita asiaton viesti
Kirjoittanemme Korhosen kanssa ihan samasta asiasta mutta eri sanoin.
Minustakin prosessit ovat ”vain työkalu” eli tapa järjestää työn tekemistä järkevästi eteneväksi ja asetettuun tavoitteeseen pyrkivästi. Silloin toiminnan tavoitteet ja niistä johdedut vaatimukset ovat avainasemassa. Sen jälkeen kun tiedetään mitä töitä pitää ja halutaan tehdä tavoitteiden saavuttamiseksi, voidaan vääntää prosessit palvelemaan sitä tarkoitusta. Ja vasta sen jälkeen kannattaa alkaa miettiä loogisella tasolla minkähänlaisia haasteita tietojärjestelmillä kannattaa ratkaista. Kun se tiedetään, voidaan alkaa katsoa tietoTEKNIIKKAA. Siinäkään ei ihan ensimmäisen kysymys ole mumps- tai humps-tason kysymykset ohjelmointikielistä, jotka todellakin ovat kuten Mäntylahti toteaa, nörttipornoa.
Ohjelmoimisen osaamisenkin kannalta olisi hyvä muistaa, että kielen syntaktinen osaaminen on pikkujuttu jos osaa ohjelmoimisen perustekniikat. Jos osaa perusasiat niin erilaisten kielten oppiminen on pikku juttu.
Erityisen oleellista olisi tunnistaa tietojärjestelmäkokonaisuuksien kerroksellisuus. Ytimenä olevien tietojen hallinta ja niihin liittyvät perusproposessit ovat eri asia kuin toimintaprosessit ja niiden tarvitsemat tietojärjestelmäpalveluista koostuvat liiketoimintapalvelut. Päälimmäinen kerros on sitten erilaiset käyttöliittymät erilaisissa kanavissa. Noihin erilaisiin kerroksiin pitää kohdistaa niille ominaiset vaatimukset ja elinkaariodotukset. Ytimiä tehdään vuosikymmeniksi, prosesseja vuosiksi ja käyttöliittymiä pahimmillaan vain kuukausiksi. Ja kaikkien noiden tekemistä ja ylläpitoa pitää hallita päämääränä se, mihin niitä aiotaan käyttää eikä se, millä teknisellä vemputtimella olisi kiva kenenkin puuhastella.
Ilmoita asiaton viesti
Hei,
Monilta osin varsin hyvä teksti, mutta hankintalaki asettaa monille ehdotuksillesi juridiset rajat. Esim. hankintalain 62 § toteaa yksiselitteisesti, että tarjouksista on hyväksyttävä se, joka on hankintayksikön kannalta kokonaistaloudellisesti edullisin hankinnan kohteeseen liittyvien vertailuperusteiden mukaan, tai se, joka on hinnaltaan halvin. Kokonaistaloudellisuuden vertailuperusteita sitten on listattu hankintailmoituksen luonnokseen.
HUS ja kunnat ovat erillisiä hankintayksiköitä. Siksi hankintarengas on juridisesti ainoa tapa hankkia yhteinen järjestelmä. Yhteisen järjestelmän tarve taas on kiistaton. Hankkeeseen on yritetty valjastaa organisaatioiden parhaat asiantuntijat ja ulkopuolista apua.
Terv. Lasse Lehtonen, hallintoylilääkäri HUS / hankintalainsäädännön vastuuopettaja / Ty, oik.tdk
Ilmoita asiaton viesti
Hei Lasse
Kiitos hyvästä kommentistasi. Hankintalaki tuntuu ylipäätään olevan erittäin vaikea kompastuskivi julkisen sektorin järjestelmien ja palveluiden hankinnalle.
Olisiko mahdollista muokata kriteereihin mukaan tämä toimintojen tehostamiseen vaikuttavuus? Kyllähän sillä on selkeä liittymä *kokonaistalouden* edullisuuteen. Operatiiviset toimintamenot kun ovat monin verroin merkittävimpiä kuin pelkät järjestelmän rakennus- ja ylläpitokustannukset.
Ilmoita asiaton viesti
”joka on hankintayksikön kannalta kokonaistaloudellisesti edullisin hankinnan kohteeseen liittyvien vertailuperusteiden mukaan, tai se, joka on hinnaltaan halvin.”
Eipä tuo miltään lailta tunnu sen varsinaisessa merkityksessä. Päinvastoin kyseisen tekstin voi ymmärtää ihan miten vain. Yksiselitteinen se ei ainakaan ole. Sellaista virkamieshallinnon kapulakieltä. Ihan vain aiheen ulkopuoleleta. Onko ko. prosessi edennyt jo niin pitkälle, että muut toimittajat tai ohjelmistot on pois suljettu?
Ilmoita asiaton viesti
Tällaisessa hankkeessa unohtuu helposti tulevaisuus. Jos hanke onnistuu, niin se ja siitä edelleenkehittynyt tietokokonaisuus muodostaa Suomen terveydenhoidon pohjan vielä kymmenien vuosien kuluttua.
Tästä syystä järjestelmä pitää pystyä palastelemaan osakokonaisuuksiin, joita voidaan sitten edellenkehittää tai vaihtaa toisenlaisiksi vuosien saatossa ilman, että koko pohjaa pitää vaihtaa. Tässä mielessä yhden toimittajan kokonaisuus on aika vaarallinen.
Tietysti on mahdollista sekin, että hankittavalle järjestelmälle suunnitellaan jo nyt selkeä elinkaari, jona aikana sitten kehitetään uudempiin arkkitehtuureihin ja hoitotapoihin perustuva seuraava ja ihan uusi generaatio.
Hankaluutena nykyisessä hankkeessa on, että nyt ollaan Suomessa ensimmäistä kertaa laajamittaisesti yhdistämässä kaikkia asioita saman katon alle ja kokemuksesta ja tutkimuksesta syntyviä hoitologistiikan tulevia asioita ei vielä edes välttämättä tiedetä. Fiksaa siinä sitten tämänhetkiset liiketoimintaprosessit ja osta sen perusteella halvin. Haastetta kerrassaan.
Ilmoita asiaton viesti
Hyvä kirjoitus, joka osoittaa, että tiedät mistä kirjoitat.
Miksi Helsingin terveyslautakunta yksin päättää aloittamisesta, jos siihen on useampi kaupunki ja kunta osallistumassa? Vai onko tässä, jo ajateltu, että tulevaisuudessa mukana olevat kuuluvat Helsinkiin?
Kannattaisin yhteistyötä tuollaisenkin päätöksen tekemisessä ja jokaisessa kunnassa pystyttäisiin itsenäisesti päättämään osallistumisesta, mikä toki jokaiselle kunnalle olisi suositeltavaa.
Yhden toimittajan valinta ei välttämättä ja ei toivottavasti myöskään toteudu, jos seuraavaa on uskominen
”Mikäli neuvotteluissa havaitaan, että esitetyt ratkaisumallit tai
toteutusvaihtoehdot eivät ole tarkoituksenmukaisia tai
toteutuskelpoisia, hankintayksikkö voi ryhtyä neuvottelemaan uudesta
ratkaisumallista tai toteutusvaihtoehdosta kaikkien
neuvottelumenettelyyn valittujen ehdokkaiden kanssa.”
Ehdottamasi periaatteet toimitsijoiden valitsemisesta ovat kannatettavia.
Hankintarenkaan ongelmallisuudesta en saanut aivan noin huonoa kuvaa kuin tekstissäsi oli, koska eikö jokainen mukana oleva kunta sitoudu kokonaisratkaisuun, ei erillisiin osiin, tarjottavista palveluista. ”Hankintasopimus syntyy vasta, kun osapuolet ovat allekirjoittaneet sopimuksen.”
Muutoin edelleen kannatettavia ajatuksia millaisella organisaatiolla hanketta viedään eteenpäin.
Perustelumuistion osalta oli hyviä ehdotuksia ja kannanottoja.
Itse korostaisin lopussa olevaan yhteenvedossa olevaan kohtaan ” Hankittava järjestelmä ei ratkaise kaikkia sosiaalihuollon, perusterveydenhuollon ja erikoissairaanhoidon tietojärjestelmätarpeita.”,
laaja-alaista määrittelyn tarpeellisuutta, johon monelta osaamisalueelta osallistuttaisiin, jotta mahdollisemman pieni osa tarpeista jäisi toteutumatta. Todennäköisesti näin tehdäänkin.
Hankesuunnitelman osalta toteamuksesi ” Hankkeessa täytyy edellyttää luvattujen hyötyjen toteutuminen”, todeta kohtaan I-tyypin diabeetikkona
”Itse- ja omahoidon toteuttaminen on helpompaa, mikä johtaa ennaltaehkäisyn tehostumiseen,
sairauksien aikaisempaan toteamiseen ja parempiin hoitotasoihin.
o Miten hyödyt toteutuvat järjestelmän avulla
. potilas pystyy kommunikoimaan sähköisesti lääkärin/muun ammattihenkilön kanssa
. potilas saa omahoito-ohjeita portaalistaan
. potilas voi tallettaa omia tuloksiaan portaaliin ja saa niistä palautetta”
, että omien tietojen tallentamista potilastietojärjestelmiin olen toivonut pidemmän aikaa, mutta se taitaa mennä aika kauas tulevaisuuteen, johtuen siitä, että diabeetikot keräävät kyllä tietoa itsestään verensokerimittareilla. Jokaisella kunnalla on vain erilaiset jaettavat ja niitäkin voi olla hyvin erilaisia. Kaikilla ei välttämättä ole välinettä minne tiedot tallentaa, kaikki eivät edes osaisi sitä tehdä. Tieto varmasti saadaan siirrettyä, mutta se tieto voi olla hyvin erilaista mittareista johtuen.
Millä lailla tietojen yhteneväisyys samankaltaisten tietojen siirrossa taataan.
Lisäksi itse toivoisin, jopa näihin mittareihin enemmän ominaisuuksia, joilla voidaan lisätä muutakin tietoa kuin pelkkä mittauksen arvo. En halua kuitenkaan itselleni puhelinta, joka sen tekisi, niin älykästä puhelinta en tarvitse, vaan laitteen, joka tekee omat tehtävänsä.
Pahoittelen, etten pystynyt lyhyemmin kommentoimaan.
Ilmoita asiaton viesti
Voin olla väärässä mutta hienoinen toimialatuntemuksen puute näyttäisi vaivaavan. Käytännön vaikutukset hankkeiden läpiviennille eivät ehkä täysin selvillä. Päällikkötasolla tietysti ei niin tarvitsekaan olla selvillä pääasia että hankkeen päättävä johto ymmärtää ja huomioi. Päällikkötasolla ymmärrys kasvaa sitten hankkeen myötä.
Perustason käsitteiden hallinta ei käynyt aivan selväksi myöskään. Vrt. elinkaaren ylläpito – vai hallinta.
”Järjestelmän rajapintojen on oltava avoimia” tyyppiset vaatimukset luovat kuvaa järjestelmäkehityksen periaatteiden ymmärtämisestä mutta eivät sinänsä kerro oikeastaan vielä mitään. Kuten Heli yllä totesi ”rajapintojen suunnittelu, mitkä ovat vähimmäisvaatimukset liittyville järjestelmille.”
Mutta joo onhan tuossa asiaakin.
Mutta ne pienet nyanssit ja ”en merkittävissä määrin korosta omaa osaamistani” tyyppiset lausahdukset aiheuttaa kyllä sen että rivien välitkin pitää lukea tavallista huolellisemmin.
Ilmoita asiaton viesti
Ossi kirjoittaa: ”Halvin ei saa voittaa!… ensisijaisena valintakriteerinä ei pidä käyttää edullisuutta”.
Tämä on se kinkkinen juttu, jossa mennään pieleen hankinnoissa. Kun itse asiassa on niin, että jos halutaan laatua, HINNAN pitää olla ensisijainen valintakriteeri! Niin nurinkuriselta kuin se kuullostaakin.
Laatu valintakriteereissä nimittäin ei takaa laatua. Sen sijaan laatua saadaan siten, että se laatu laitetaan pakollisten vaatimusten joukkoon. Olen kirjoittanut (esim. Hesarin vieraskynä 1.7.12 http://www.hs.fi/digilehti/01072012/paakirjoitukse…), omassa blogissani http://hankikaytettavyytta.blogspot.fi/ ja keskustellut asiasta useissa alan LinkedIn-keskusteluryhmissä. Ja mielestäni ollut asiassa varsin vahvoilla.
Eli hankinnan pitäisi mennä siten, että hankkija määrittää pakolliseksi sen laadun, mitä haluaa (esimerkiksi toiminnan tehostumisen). Ja sitten valinta tehdään pakollisiin vaatimuksiin sitoutuneiden toimittajien kesken, pääkriteerinä hinta.
Haaste on tietenkin määrittää mittarit (ja tavoitetasot) noille pakollisille laatuvaatimuksille. Ja tässä olen samaa mieltä Ossin kanssa, että sellaisten määrittäminen on mahdollista vaikkakin haastavaa.
Ilmoita asiaton viesti
Olen ihan samaa mieltä, että kulloiseltakin toimitukselta vaadittavat kaikki oleelliset asiat, m.l. laatu, on oltava vaatimuksina.
Samoin olen samaa mieltä, että vaatimusmäärittely on vaikeaa. Se on jo sitä mentaalisella tasolla. Kuulinpa kerrankin eräältä moniaita hankintoja asiallisesti päättäneeltä, että ehdottomia vaatimuksia ei pidä asettaa koska se rajoittaa valinnanvapautta.
Vaikeinta tuntuu olevan osata päättää asioista niin, että niihin todella sitoudutaan; että, tiedetään mitä oikeasti tarvitaan jotta haluttu toiminta tehostuu halutulla tavalla. Helpompaa on puuhastella niitä ja näitä antaen asioiden valua hoidettavaksi toteutusprojektien loppua kohden, eli ratkaistavaksi mahdollisimman kalliilla ja mahdollisimman hankalilla tavoilla.
Eli oikeasti pitäisi panostaa ihan eri tavalla halutun tavoitetilan ja sitä kuvaavien vaatimusten ja periaatteiden tunnistamiseen ja lukkoonlyömiseen. Se on halpaa kun välineet ovat taulukoita, tekstiä ja kuvia sekä niiden ympärillä rajattu määrä ihmisiä. Mitä myöhemmäksi asioiden ratkaisemista lykätään, sitä kalliimmaksi se tulee kun väkeä kerääntyy lisää ja muutosten heijastusvaikutukset laajenevat.
Toki toisessa päässä on vaarana, että asioita vain vatvotaan. Tarvitaan myös kykyä tehdä päätöksiä ja tehdä niitä oikealla tasolla niin, että pöydällä on relevantteja asioita eikä pyöritä mumps- ja humps-tasolla. Sellaisille teknisille yksityiskohdeille on omat vaiheensa ja ne ratkeavat jos niiden ratkaisemista varten on (liike-)toimintavaatimuksista johdetut periaatteet. Tärkeää on pystyä pitämään kulloinkin käsiteltävänä olevat asiat osana kokonaisuutta ja käsitellä kerralla keskenään vertailukelpoisia asioita järjellä käsitettävinä palasina.
Ilmoita asiaton viesti
Jos järjestelmä toteutetaan käyttäen moderneja tekniikoita ja avoimia rajapintoja, voidaan järjestelmän toteutuksen osia, mm. integroinnit erilaisiin järjestelmiin, kilpailuttaa erikseen vaikka pienemmillä ohjelmistotaloilla, joilla kyllä löytyy jo nyt osaamista näistä teknologioista.
Ei tarvitse olla rakettitieteen tohtori tajutakseen, että talonrakentajan ei tarvitse tehdä ikkunankarmeja itse, jos vaan pystyy toimittamaan mitat alihankkijalle. Aivan samasta asiasta on kyse ohjelmistohankinnoissa. Korvataan vaan ”mitat” sanalla rajapintakuvaus (jota mitat myös ovat) ja ”ikkunankarmit” sanalla integraatiosovellus.
Käyttäen avoimia yleisesti käytössä olevia tekniikoita varmistetaan se, että kuka tahansa voi osallistua tämän järjestelmän kehitykseen, mikä laskee hintaa huomattavasti.
Suunniteltu malli ei mahdollista tällaista toteutustapaa, sillä ehdotettu talo on rakennettu tuntemattomasta 60-luvun teollisuusjätteestä 80-luvun tekniikoilla, eikä kukaan halua edes mennä sen lähelle.
Ilmoita asiaton viesti
Feikkikommentointia:
http://www.laitos.fi/tervetuloa-suomeen-astroturff…
joku on tooodella epätoivoinen (ja tyhmä)
Ilmoita asiaton viesti