Avoin kutsujärjestelmä ikäihmisille ja palvelukeskuksiin

Tämä kirjoitus oli julkaistu aikaisemmin markosu.net blogissani elokuussa 2014. Idea on vieläkin ajankohtainen, sillä kutsujärjestelmät ovat sidottuja palvelun toimittajiin eikä standardoituja rajapintoja ole tiedonsiirtoon.

Olin ehtinyt työskennellä Likioma-projektissa muutaman kuukauden, kun erään keskustelun jälkeen havahduin siihen, että kaikki kutsujärjestelmiin ts. avunpyyntöjärjestelmiin liittyvät toiminnot ”nauttivat” vendor lock in -tilanteesta. Kyseessä on siis tilanne, jossa tuotteen tai palvelun vaihtaminen on hankalaa tai vaihdon kustannukset kohtuuttoman suuria sekä nykyisen järjestelmän kehittäminen on riippuvainen nykyisestä palveluntarjoajasta. Käytännössä esimerkiksi palvelukodin laajentuessa joudutaan ostamaan saman valmistajan tuotteita lisää tai vaihtamaan kaikki uusiin. Tähän minulla olisi kustannustehokas ratkaisu, joten kannattaa lukea lisää alempaa.

Viiden minuutin video avoimuudesta ja siihen liittyvistä hyödyistä:

https://www.youtube.com/watch?v=3cZGQHgrH80#t=76

Idea

Miltä kuulostaa avoin kutsujärjestelmä, jossa kaikki siihen liittyvä on niin avointa kuin pystyy? Monelle varmaan tulee mieleen: ”Mikäs se sellainen avoin kutsujärjestelmä on? En minä ainakaan halua kertoa tietojani avoimesti maailmalle.” Tässä yhteydessä avoimuudella tarkoitetaan kehittämistä avoimesti niin, että kuka vaan voi osallistua kehittämiseen eikä kenelläkään ole yksinoikeutta kehitystyön tulokseen. Tarkoitus on perustaa samanlaista toimintaa kuin RuuviTracker-projektilla, jossa tarkoituksena on rakentaa avoimuuteen perustuva paikannusjärjestelmä.

Alla karkeasti kuvattuna yksi toteutusvaihtoehto:

Avoimiin tekniikoihin perustuva kutsujärjestelmä olisi suunniteltu ensisijaisesti kotona asuville ikäihmisille. Teknisesti järjestelmä voisi koostua räätälöidyllä ohjelmistolla varustetusta älypuhelimesta, joka toimii tukiasemana kutsunapille. Tukiasema sijoitetaan asunnon keskeiselle paikalle niin, että yhteydet toimivat. Kutsunappi kulkee asukkaan mukana esim. ranteessa, kaulassa ja välittää tarvittaessa hälytyksen tukiaseman kautta päivystykseen.

Kutsujärjestelmän käyttö hätätilanteessa:

  1. Käyttäjä painaa nappia
  2. Tukiasema välittää hälytyksen eteenpäin
  3. Puheyhteys päivystykseen napin kautta tai asuntoon asennetun puheyksikön  tms. kautta.
Piirros, jossa rannekellosta lähtee hälytys puhelimeen ja siitä eteenpäin karttanäkymään valvomoon
Kutsujärjestelmän toimintaperiaate

Laitteisto

Tukiasema: Älypuhelin tai mini-pc (esim. Raspberry Pi)

Tukiasemana hyödynnetään valmista kuluttajatuotetta, koska erillisen laitteiston kehittäminen tuo lisää hallittavaa projektiin. Mahdollista tulevaisuudessa, riippuen kiinnostuksesta.

Vaatimukset:

  • Ilmoitukset parametroitavissa monipuolisesti esimerkiksi ilmoittaa virran loppumisesta sähköpostilla tai tekstiviestillä,..
  • ilmoittaa verkkoyhteyden ongelmista, parametroitavissa monipuolisesti

Kutsunapin rauta (hardware):

Käytetään valmiita komponentteja (avoimia jos saatavilla) ja tehdään mahdollisimman yksinkertaiseksi ladonta piirilevylle. Rauta koostuu pääosiltaan tiedonsiirtopiiristä ja virtalähteestä (akku/paristo) sekä painokytkimestä, joka vastaanottaa painalluksen.

Kutsunapin ulkokuori:

Kutsunapin rauta (hardware) määrittää kokoluokan millainen kutsunappi on mitoiltaan.

Ensimmäisessä vaiheessa kutsunapille on tarkoitus luoda 3D-tulostuksen avulla erilaisia koteloita. Kotelot voivat olla rannekelloja, kaulakoruja tai ihan millaisia vaan kunhan komponentit sopivat yhteen. 3D-tulostusmallit jaetaan avoimella lisenssillä (CC BY 4.0) ja ovat saatavilla vapaasti esimerkiksi Thingiverse sivustolta.

Jotta kotelo olisi tiivis niin painokytkimen kohdalle pitää kehittää joustavasta materiaalista suoja, joka liimataan koteloon tiiviisti kiinni. Myös suojaan liittyvät tiedot ovat vapaasti saatavilla.

Tiedonsiirto:

Tiedonsiirrossa pyritään hyödyntämään avoimia standardoituja rajapintoja ja tiedonsiirtotekniikoita. Tärkein ominaisuus tiedonsiirrossa napin ja tukiaseman välillä on, että siirto ei kuluta paljoa virtaa. Alla mahdollisia tiedonsiirtotekniikoita:

  • matkapuhelinverkko
  • Bluetooth
  • radiotaajuus: 868.95 MHz
  • tai muu tekniikka

Tulevaisuuden kilpailutukset avoimella kutsujärjestelmällä?

Olen aina ollut sitä mieltä, että kilpailutuksessa laatu pitää olla tärkein kriteeri eli sillä pitää olla suurin painoarvo pisteissä. Tuntuu kuitenkin, että tällä hetkellä kilpailutukseen vaikuttaa eniten tuotteen ominaisuudet tai palvelun sisältö. Joskus jopa käy niin, että tuotteen ominaisuudet ratkaisevat jo voiton tarjousvaiheessa (Ilta-Sanomat, 3.1.2008: Tamperelaista kilpailutusta: Vain yhden yhtiön tuotteet kelpaavat).

Miten avoin kutsujärjestelmä voisi muuttaa kilpailutusta? Tässä visioni.

Alla kuva kutsujärjestelmiin liittyvästä perinteisestä kilpailutuksesta, johon osallistuu tällä kertaa vain kaksi palveluntarjoajaa.

Kuva, jossa kaksi palveluntarjoajaa. Palveluntarjoajan 1 tuote+laatu häviää palveluntarjoaja2:n.

He tarjoavat edustamaansa tuotetta ratkaisemaan tuotteelle asetettuja vaatimuksia ja laadun osalta lupaavat sitä mitä kilpailuttaja haluaa. Kilpailuttaja sitten valitsee parhaimman näistä tarjouksessa määriteltyjen kriteerien perusteella.

Kilpailutuksen ratkaisi palveluntarjoaja2:n tuotteessa ollut ominaisuus, jota ei löytynyt muilta osallistuneilta. Palveluntarjoaja2:n laatulupauksissa oli enemmän puutteita, mutta tuotteen ominaisuuksilla oli suurempi painoarvo tässä kilpailutuksessa.

Avoin kutsujärjestelmä tuotteena kilpailutuksessa

Kaikki toimijat samalla viivalla, kun kaikilla sama tuote. Ainoastaan laadulla pystyy kilpailemaan ja mukaan kilpailutukseen voi osallistua kuka vain ilman omaa tuotetta. Tällaista sen kilpailun pitää olla. Alla kuva kilpailutuksesta, jossa kaikilla sama tuote eli vain laatu ratkaisee.

Kuva, jossa vain kaikkien palveluntarjoajien laatu merkitsee.

 

Tiedätkö mitä lähistölläsi tapahtuu? Tapahtumatiedot avoimeksi dataksi -ideasta apua.

Nykyisessä työssäni Likioma-projektissa järjestetään tapahtumia ja niitä markkinoidaan erilaisissa medioissa. On kuitenkin todella turhauttavaa syöttää samoja tietoja vähintään kolmelle eri sivustolle kuten harmala-tapahtumat.fi sivulle, Tampereen terveystutka -palveluun, Aamulehden menoinfo -palveluun. Lisäksi tapahtumista pitää luoda tulostettava lista niille henkilöille, jotka eivät käytä sähköisiä medioita eivätkä tilaa lehtiä.
Myös mahdollisten virheiden korjaus on työlästä, kun ensin pitää muistella missä kaikkialla väärä tieto on ja sen jälkeen koittaa korjata väärä tieto. Jossain tapauksissa korjausprosessi on täysin erillinen kuin tapahtumatietojen syöttöprosessi ja vaatii esimerkiksi sähköpostin käyttöä.
Kaikki nämä toimenpiteet vaativat paljon resursseja.

Mikä ihmeen “tapahtumatiedot avoimeksi dataksi” -idea?

Ideana on, että tapahtumatiedot hallittaisiin kootusti yhdessä palvelussa esim. kunnalla nettipalvelu ja tiedot jaetaan hyvin määriteltynä avoimen rajapinnan kautta. Valitettavasti tällä hetkellä netissä ei ole tarjolla palvelua, johon esim. kolmannen sektorin toimija voisi syöttää tapahtumatietoja ja saada ne rajapinnan kautta myös omille sivuille näkyviin. Päätepysäkkejä (palveluita ilman rajapintoja) on kyllä tarjolla mihin tapahtumia voi syöttää.

Vielä kun tuon palvelun (backend) toteuttaisi avoimen lähdekoodin ratkaisuna niin kaikki Suomen kunnat (317kpl) voisivat hyödyntää samaa järjestelmää. Koska järjestelmä hyödyntää yhteisesti määriteltyä tietomallia ja tarjoaa tiedot avoimen rajapinnan kautta niin kunnille riittäisi pelkästään käyttöliittymän (frontend) muokkaukset kunnan ulkoasuun sopivaksi.

Koostin muita hyötyjä alla näkyvään kalvosettiin:

Tämän kappaleen alapuolella näkyvä kuva yrittää kuvata sitä, että tällä hetkellä tapahtuman markkinointi on kuin kaivaisi pikkulusikalla kuoppaa, kun lasin takana olisi 200 000€ hintainen lapio, jolla homma sujuisi resursseja säästäen. Lapio siis olisi se kaivattu markkinointia helpottava työkalu eli tässä tapauksessa tapahtumatiedot avoimeksi dataksi -idea, jonka hintalappu tosiaan olisi 200 000 euroa. Hinta on hieman yläkanttiin (kysytty parilta yritykseltä ns. heittotarjouksia).
Ei paha hinta ratkaisusta, joka palvelisi vähintään viittä miljoonaa Suomen kansalaista.

 

Tikku-ukko kaivaa kuoppaa pienellä lusikalla vaikka lasin takana on kunnon lapio
Tällä hetkellä (2015) tapahtuman syöttäminen usealle sivustolle on kuin pikkulusikalla kaivaisi ns. markkinointikuoppaa, kun taas tapahtumatiedot avoimena datana olisi kuin lapio tähän työhön.

Otakantaa -palvelussa gallup ja kysely

Oikeusministeriön otakantaa.fi palveluun on luotu ”Tapahtumatiedot avoimeksi dataksi – tehokas ratkaisu tapahtumien markkinointiin” -hanke, vaikkei kyseessä ole varsinainen hanke vaan ideaan liittyvän keskustelun mahdollistaminen. 

Yhtenä ideana otakantaa.fi palvelun hyödyntämisessä oli, että sitä käyttäen voisin kokeilla listata ideaa kannattavia toimijoita samalla tavalla kuin [Uusi Lastensairaala 2017 tukijat](http://uusilastensairaala2017.fi/tukijat) sivulla. Valitettavasti otakantaa.fi palvelu ei taivu tarpeeseen ja minulla ei ole resursseja toteuttaa kannattajalistausta samalla tavalla kuin uuden lastensairaalan kohdalla, joten täytyy tyytyä gallupista ja kyselystä saatuihin tuloksiin, joiden perusteella jokin toimija toivottavasti aloittaa ratkaisun toteuttamisen niin, että se palvelee myös kolmatta sektoria.

Ideaa on lobattu jo syksystä 2013 lähtien

Alla kalvosetti, missä kerrotaan mitä on tullut tehtyä Likiomassa ja miten ideaa on lobattu.

Kerätäkseni asiasta kiinnostuneet ihmiset keskustelemaan ideasta perustin myös “Tapahtumatiedot avoimeksi dataksi” Facebook-ryhmän.
Tottakai keskusteluun pitää olla tarjolla myös ns. neutraali keskustelufoorumi sellaisille henkilöille ketkä eivät halua hyväksyä yrityksien käyttöehtoja. Ajattelin, että otakantaa palvelussa hanke olisi sellainen.

Perustin myös määrittelyjen yhteisölliseen tuottamiseen ja koodin jakamiseen Github-palveluun organisaation ja repon: Tapahtumatiedot avoimeksi dataksi repo

Muokattu 4.6.2016: Korjattu linkkejä otakantaa palveluun ja muutoksia tekstiin.