Toinen vaihtoehto, jota hyvinvointialueilla saatetaan harkita, on hoitopolkujen toteuttaminen SDK:n (Software Development Kit) muodossa osana laajempaa digialustaa. Tämä tarkoittaisi, että hoitopolun toiminnot eivät olisi itsenäisessä sovelluksessa, vaan ne olisi upotettu osaksi olemassa olevaa hyvinvointialueen digisovellusta SDK:n avulla.
Tämä malli tuo mukanaan monia samoja haasteita kuin täysin yhdistetty sovellusmalli, mutta siihen liittyy myös omia erityisongelmiaan:
- Riippuvuudet kasvavat entisestään
- SDK:n kehitys on kallista ja monimutkaista
- Digialustan kehittäjän vastuu kasvaa merkittävästi
- Kokonaiskustannukset voivat nousta liian suuriksi
Tässä blogissa käymme läpi, miksi SDK-pohjainen toteutus ei välttämättä ole paras ratkaisu hoitopolkujen tukemiseen.
Miten SDK-malli toimisi?
SDK-mallissa hoitopolun kehittäjä tuottaisi valmiin ohjelmistokehityspaketin, jonka hyvinvointialueen digialustan kehittäjä integroisi osaksi omaa sovellustaan. SDK sisältäisi esimerkiksi:
Tämä voisi teoriassa vähentää tarvetta rakentaa erillistä hoitopolkusovellusta ja antaa potilaalle yhden pääsyn kaikkiin digitaalisiin terveyspalveluihin. Mutta käytännössä tähän liittyy monia vaikeita haasteita.
1. Liian laaja ja raskas kokonaisuus
SDK-mallissa yhdistetään kaksi eri järjestelmää: hoitopolun hallinta ja yleinen digiasiointi. Tämä tuo mukanaan samoja ongelmia kuin täysin yhdistetty sovellus:
- Käyttökokemus voi kärsiä, koska hoitopolun logiikka ei ole erillinen, vaan se on upotettu toisen sovelluksen sisään.
- Notifikaatioiden hallinta on sekavaa, jos eri palvelut kilpailevat huomiosta yhdessä sovelluksessa.
- Käyttöpolut ovat erilaisia, ja ne voivat sekoittua: hoitopolut ovat aktiivisia, digialusta passiivinen.
SDK:n käyttö ei ratkaise näitä ongelmia, vaan tuo mukanaan uusia haasteita.
2. Riippuvuudet hidastavat kehitystä
Vaikka SDK-malli antaisi hoitopolun kehittäjille erillisen kehitysympäristön, se ei poista riippuvuuksia digialustan kehityksestä:
- Kaikki muutokset SDK:ssa vaativat yhteensopivuutta digialustan kanssa, ja kehitys hidastuu merkittävästi.
- Hyvinvointialueen digialustan kehittäjän on otettava SDK käyttöön ja päivitettävä sitä säännöllisesti, mikä voi tuoda lisäviivästyksiä. Tämä voi vaatia dedikoitua resursointia.
- Mahdolliset bugit ja ongelmat voivat olla vaikeita korjata, koska ne voivat johtua SDK:sta, digialustasta tai niiden yhteentoimivuudesta.
Esimerkiksi:
- Jos hoitopolkujen kehittäjä haluaa lisätä esimerkiksi uuden kyselytyypin tai raporttinäkymän, se ei onnistu itsenäisesti, vaan vaatii digialustan kehittäjän tukea.
- Jos digialustaan tehdään päivitys, se voi rikkoa SDK:n toiminnallisuuksia, mikä vaatii lisätestausta ja yhteensovitusta.
3. SDK:n kehitys ja ylläpito ovat kalliita
SDK:n toteuttaminen vaatii korkeatasoista kehitystä useille eri alustoille, jotta se voidaan integroida digialustan sovellukseen:
- iOS: Swift/Objective-C
- Android: Kotlin/Java
- Flutter tai React Native
Tämä tarkoittaa, että SDK:n kehittäjän täytyy ylläpitää ja kehittää useita eri versioita SDK:sta, mikä tekee ratkaisusta kalliin ja monimutkaisen:
- Lisäkustannuksia kehityksessä – tarvitaan erikoistuneita mobiilikehittäjiä
- Testaus ja yhteensovittaminen lisäävät kuluja – SDK:n täytyy toimia saumattomasti digialustan eri versioiden kanssa
- Versiohallinta ja jatkuvat päivitykset – jos digialusta muuttuu, SDK:n on pysyttävä mukana
Käytännössä tämä tarkoittaa, että kokonaiskustannukset nousevat nopeasti, koska sekä SDK:n kehittäjän että digialustan kehittäjän täytyy tehdä merkittävästi ylimääräistä työtä yhteensopivuuden varmistamiseksi.
4. Digialustan kehittäjälle tulee lisätyötä
SDK-mallin onnistuminen ei riipu vain SDK:n kehittäjästä, vaan myös siitä, kuinka hyvin digialustan kehittäjä pystyy sen integroimaan ja ylläpitämään. Tämä tuo lisähaasteita:
- Digialustan kehittäjällä täytyy olla osaamista SDK:n käytöstä ja sen päivittämisestä.
- SDK-integraatio vaatii lisäkehitystä ja mahdollisesti käyttöliittymän räätälöintiä, jotta se sopii hyvin yhteen muun sovelluksen kanssa.
- Mahdolliset yhteensopivuusongelmat voivat aiheuttaa merkittäviä viivästyksiä.
Tämä tarkoittaa, että hyvinvointialueen digialustan kehittäjän on sitouduttava pitkäjänteisesti SDK:n käyttöön ja päivityksiin, mikä ei välttämättä ole kustannustehokasta.
Yhteenveto: SDK-malli ei ole optimaalinen hoitopoluille
Vaikka SDK voisi teoriassa tarjota tavan integroida hoitopolut digialustaan, käytännön haasteet tekevät siitä epäkäytännöllisen ja kalliin vaihtoehdon.
- Liian laaja ja monimutkainen kokonaisuus → Käyttökokemus kärsii, ja notifikaatiot voivat hukkua
- Kehityksen riippuvuudet hidastavat molempia osapuolia → Hoitopolun kehittäjä ja digialustan kehittäjä joutuvat työskentelemään tiiviisti yhdessä, mikä tuo lisäkustannuksia ja viivästyksiä
- SDK:n kehitys ja ylläpito ovat kalliita → Tarvitaan useita eri alustoja tukevia versioita
- Digialustan kehittäjälle tulee merkittävästi lisätyötä → SDK:n integrointi ja päivitykset eivät tapahdu automaattisesti
Paras ratkaisu?
- Erillinen hoitopolkusovellus tarjoaa parhaan käyttökokemuksen ja mahdollistaa nopean kehityksen
- API-pohjainen integraatio digialustaan on järkevintä kun halutaan yhteentoimivuutta, API-ratkaisu on kevyempi ja paljon joustavampi kuin SDK
- Joustava modulaarisuus → Hoitopolut voivat kehittyä ilman, että ne ovat sidottuja digialustan muutoksiin, ja digialusta ilman sidosta hoitopolkuihin
SDK voi olla houkutteleva vaihtoehto teoriassa, mutta se ei poista yhdistetyn sovelluksen ongelmia – se vain siirtää ne uudelle tasolle ja tekee ratkaisusta entistä kalliimman ja monimutkaisemman. Siksi itsenäinen hoitopolkusovellus on edelleen paras ja kestävin vaihtoehto.