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.