”Diagnostics as a Service” -mallissa digitaaliset terveystuotteet tarjoavat laboratoriotestauspalveluita

Useimmat terveysalan tuotetta kehittävät tiimit saavat valmiin ja toimivan sovelluksen valmiiksi muutamassa kuukaudessa. Sitten mukaan tulevat laboratoriotestit, ja aikataulu venyy huomaamatta kahdella vuosineljänneksellä. Ei siksi, että koodi olisi vaikeaa, vaan siksi, että laboratoriointegraatio ei ole koskaan vain yksi integraatio. Siihen kuuluu tilausten reititys, tilauslomakkeet, testipakkausten toimittaminen, kuriirien toimitusajat, viivakoodien täsmäytys, tulosten jäsentäminen, yksikkömuunnokset, viitearvot, potilaalle näkyvä näkymä kaikesta tästä sekä taustalla oleva sääntöjenmukaisuuspaketti, jonka lakimiehen on allekirjoitettava ennen kuin yksikään näyte pääsee liikkeelle.

”Diagnostics as a Service” on ratkaisu, joka poistaa tämän työn, samalla tavalla kuin maksupalveluntarjoajat poistivat hankkivan pankin, maksuportaalin ja maksupäätelaitteen toimittajan tavallisesta kassaprosessista. Tässä artikkelissa käsitellään, mitä malli sisältää, miltä integraatio käytännössä näyttää, miten se eroaa sisäisestä ratkaisusta sekä mitä kysymyksiä palveluntarjoajalta kannattaa esittää ennen kuin sitoudut heidän kanssaan toteutussuunnitelmaan.

Mitä ”Diagnostics as a Service” tarkoittaa tuotekehitystiimille?

Diagnostics as a Service (DaaS) tarkoittaa laboratoriotestien tilaamista sovellusrajapinnan (API) kautta ja jäsenneltyjen tulosten vastaanottamista, kun taas yksi palveluntarjoaja huolehtii laboratorioista, testipakkauksista, logistiikasta ja kyseisen sovellusrajapinnan taustalla olevasta sääntelykehyksestä. Tuotteesi määrittää, ketkä testataan ja mitä tuloksilla tehdään. Kaikki tilauksen ja tuloksen välinen prosessi on jonkun muun operatiivinen ongelma.

Yleisin vertailukohde on Stripe, ja se kestää vertailun paremmin kuin useimmat muut vertauskuvat. Stripe ei keksinyt korttimaksuja, vaan se tiivisti viiden toimittajan projektin yhdeksi sovellusrajapinnaksi (API) ja yhdeksi hallintapaneeliksi. Diagnostiikka-alusta tekee saman asian järjestelmäkokonaisuudelle, joka tällä hetkellä koostuu laboratoriosta, testipakkausten toimittajasta, kuriiripalvelusta, tulosten jäsentäjästä sekä osapuolikohtaisesta tietosuojasopimuksesta. Et osta laboratoriota. Ostat integrointiprojektin poistamisen.

Yksi asia on syytä täsmentää, sillä se vaikuttaa siihen, miten palveluntarjoajia arvioidaan: DaaS-alusta ei yleensä ole itse laboratorio. Se koordinoi akkreditoitujen laboratorioiden toimintaa. Akkreditointi kuuluu sille, joka suorittaa analyysin, kun taas sovellusrajapinta (API), tuoteluettelo, logistiikka ja vaatimustenmukaisuusasiakirjat kuuluvat alustalle.

Miksi laboratorion integrointi kestää kauemmin kuin kukaan arvioi?

Arvio tehdään yleensä tarkastelemalla laboratorion rajapinta-asiakirjaa, jossa kuvataan tietomuoto. Työ tehdään kaikkialla muualla. Suurin osa aikataulun ylityksestä johtuu kuudesta tekijästä.

• Tilaus ei ole pelkkä POST-pyyntö. Kelvollinen tilaus edellyttää potilaan henkilötunnusta, tutkimuspakettia, jota laboratorio tosiasiallisesti tarjoaa käyttämälläsi koodilla, tilauslomaketta sekä viivakoodia, joka yhdistää fyysisen näyteputken kyseiseen tietueeseen. Jos viimeinen osa menee pieleen, saat tuloksia, joita et voi kohdistaa oikeaan potilaaseen.
• Fyysinen logistiikka tulee osaksi koodipohjaasi. Pakkaukset on hankittava, lähetettävä ja palautettava. Kuriireilla on noutoaikoja. Näytteet pilaantuvat. Yhtäkkiä tuotteellasi on tiloja kuten ”kuljetuksessa” ja ”nouto jäänyt väliin”, ja jonkun on päätettävä, mitä käyttäjä näkee kussakin tilanteessa.
• Tulosten esitysmuodot eivät käytännössä ole vakiintuneita. Yksi laboratorio lähettää tiedot HL7-muodossa, toinen CSV-tiedostona SFTP:n kautta ja kolmas PDF-tiedostona, jonka on tarkoitus olla ihmisen luettavissa. Vaikka saisitkin jäsenneltyjä tietoja, yksiköt ja merkkiaineiden nimet vaihtelevat, ja viitealueet riippuvat iästä, sukupuolesta ja tutkimusmenetelmästä.
• Viitealueet ovat laboratoriokohtaisia. Arvo on merkityksetön ilman analyysilaboratorion käyttämää viitealuetta, joten tietomallissasi on tallennettava arvot yhdessä viitealueiden kanssa sen sijaan, että ne koodattaisiin kiinteästi vain kerran.
• Poikkeukset ovat itse tuote. Hemolysoituneet näytteet, riittämätön näytemäärä, markkeri, jota ei saatu analysoitua, tai uuden näytteen otto. Normaali kulku on viikon työ, ja poikkeustilanteet vievät lopun vuosineljänneksen.
• Säännösten noudattaminen on jatkuva velvoite, ei vain väliaikainen vaihe. Jokaiselle toimittajalle on laadittava tietojenkäsittelysopimus, alihankkijoiden luettelo, palvelinten sijainti sekä perusteltu vastaus siihen, onko käyttöliittymäsi lääkinnällinen laite. Mitään näistä ei voida korjata jälkikäteen tuotteen julkaisun jälkeen.

Sitten kerrotaan tulos laboratorioiden lukumäärällä, sillä laboratorio, joka suorittaa rutiinikemian edullisesti, on harvoin sama, joka hoitaa sekvensoinnin, proteomiikan tai mikrobiomianalyysit. Jokainen uusi tutkimusmenetelmä tarkoittaa uutta yhteyspistettä, uutta sopimusta ja uutta tiedostomuotoa.

Miltä integrointi näyttää DaaS-sovellusliittymän (API) avulla?

Lyhyesti sanottuna, kun alusta toimii niin kuin pitääkin. Anivan sovellusliittymän (API) avulla uusi käyttäjä pääsee tulokseen neljällä kutsulla, ja vain kolmessa ensimmäisessä sinun on tehtävä päätös.

1. Luo profiili ja POST /api/v1/profiles, ja ilmoittamalla laboratoriolle tarvittavat tiedot, kuten etunimi, sukupuoli, syntymäaika ja profiiliryhmä, johon henkilö kuuluu.
2. Varaa aika ja POST /api/v1/appointments, ohittaen profiilin_tunnus, a location_id lähde: GET /api/v1/locations, ja scheduled_at aikaleima. Paneelit liitetään erillisessä kutsussa, joten varaus ja ostoskori pysyvät erillisinä.
3. Vahvista arvonta ja POST /api/v1/appointments/{id}/confirm ja putken viivakoodi. Tämä on se vaihe, josta laboratorioprosessi alkaa, mikä tarkoittaa, että fyysinen näyte ja digitaalinen tietue liitetään toisiinsa täsmälleen yhdessä prosessin vaiheessa.
4. Lue tulokset ja GET /api/v1/appointments/{id}/results kun käsittely on päättynyt.

Tässä on create-appointment-kutsu kokonaisuudessaan, jotta voit nähdä sen rakenteen:

# Schedule a blood draw appointment for a profile
curl -X POST https://anivahealth.com/api/v1/appointments \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "profile_id": "a3f1c2d4-8b7e-4f2a-9c1d-2e3f4a5b6c7d",
    "location_id": "b7e2d1f5-3c4a-4e8b-a2f1-9d0c1e2f3a4b",
    "scheduled_at": "2026-05-15T12:30:00+02:00"
  }'

# -> 201 Created
{ "id": "c9f3e2a1-...-1f0e9d8c7b6a",
  "status": "confirmed" }

Mielenkiintoisin osa puuttuu tuosta luettelosta. Siinä ei ole testipakkausten toimituslogiikkaa, kuriirien aikataulutusta, viivakoodialueiden hallintaa, HL7-jäsennintä, yksikkömuunnostaulukkoa, laboratoriokohtaista viitealueiden tietokantaa eikä erillistä sopimusta jokaiselle erikoisalalle. Nämä toiminnot ovat olemassa, mutta ne sijaitsevat yksinkertaisesti API:n toisella puolella.

Miten DaaS-sovellusliittymä (API) eroaa siitä, että sen rakentaa itse?

Kolme lähestymistapaa ovat toteuttamiskelpoisia, ja vertailun rehellinen tulos riippuu siitä, onko diagnostiikka itse tuotteesi vai tuotteesi tuotantopanoksena.

Koko järjestelmän rakentaminen talon sisällä on oikea ratkaisu, kun laboratorioyhteistyö, testipaneelin suunnittelu tai itse analyysi on yrityksesi kilpailuetu ja kun volyymisi on riittävän suuri perustellakseen pysyvän sisäisen palvelun, jossa on päivystävä vastuuhenkilö. Laboratorioiden integroiminen suoraan yksi kerrallaan pitää yksikköhinnat läpinäkyvinä ja toimii, jos myyt täsmälleen yhtä testipaneelia täsmälleen yhdellä markkinalla. DaaS-sovellusliittymä (API) vaihtaa osan hinnoittelun tarkkuudesta ja hallinnasta yhteen integraatioon, yhteen sopimukseen ja viikkoina mitattavaan käyttöönottoon.

Keskimmäisessä sarakkeessa näkyvä piilokustannus ei liity järjestelmän rakentamiseen, vaan sen ylläpitoon. Diagnostiikkajärjestelmän integrointi on elävä järjestelmä: laboratorioiden formaatit muuttuvat, testipaneelien nimet vaihtuvat, kuljetuspalvelujen toimitusajat muuttuvat ja säännökset muuttuvat. Joku tiimisi jäsenistä on vastuussa tästä ikuisesti, ja se on harvoin se työ, jota varten hän alun perin tuli yritykseen.

Mitä DaaS-arkkitehtuuriin kuuluu?

Kun palveluntarjoaja väittää kattavansa diagnostiikan alusta loppuun, tämän on sisällyttävä väitteeseen. Vertaa jokaista tarjousta tähän luetteloon, sillä puutteet muodostavat sinulle työtä.

• Laboratorioverkosto. Akkreditoitu yhteistyökumppani rutiiniverikokeisiin sekä erikoistuneet yhteistyökumppanit genomiikan, transkriptomiikan, proteomiikan ja mikrobiomin analysointiin – kaikki saatavilla yhdellä allekirjoittamallasi sopimuksella.
• Testiluettelo, jossa on vakiintuneet tunnisteet. Paneelit ja yksittäiset markkerit, joihin voi viitata ohjelmoinnin avulla, sekä mahdollisuus määritellä oma tuotteellesi räätälöity paneeli sen sijaan, että ostaisit vain valmiita tuotteita.
• Näytteenotto ja logistiikka. Laskimonäytteenotto yhteistyökumppaneiden toimipisteissä, kapillaarinäytteenottosarjat, kotinäytteenottosarjat, joissa on valmiiksi maksettu palautuslähetys, sekä sylki-, uloste- ja virtsanäytteet silloin, kun ne tarvitaan testipaneelissa – kaikki varustettu viivakoodilla ja käsitellään saman prosessin kautta.
• REST-rajapinta ja dokumentaatio, joita voi lukea ilman kutsua. Ennustettavat resurssit, selkeät virheilmoitukset ja ohjeet, joita uusi insinööri voi seurata jo ensimmäisenä iltapäivänään.
• Hiekkalaatikko. Realistista testidataa, ennen kuin kosketat oikeaa potilasta tai oikeaa letkua, jotta poikkeustilanteiden käsittely perustuu johonkin muuhun kuin pelkkään mielikuvitukseesi.
• Jäsennellyt tulokset. Arvot, yksiköt, viitealueet ja merkkitunnisteet JSON-muodossa, ja tulosteena PDF-tiedosto käyttöliittymän sijaan.
• White-label-käyttöliittymät. Halutessasi saat käyttöösi brändätyn potilaspaneelin ja tulos-PDF-tiedoston, ja jos haluat, voit näyttää kaiken omassa käyttöliittymässäsi.
• Säännösten noudattamista koskeva taso. Käsittelysopimus, luetellut alikäsittelijät, EU:n alueella sijaitsevat palvelinratkaisut sekä dokumentoitu kanta lääkinnällisten laitteiden luokitteluun.

Missä tuotteissa Diagnostics as a Service -palvelua tosiasiassa käytetään?

Malli on johdonmukainen. DaaS-malli on oikea ratkaisu tilanteissa, joissa testituloksen perusteella avautuu pääsy tuotteen muihin osiin ja joissa kukaan tiimin jäsenistä ei halua ottaa vastuuta kuriiripalveluista.

• Etäterveydenhuolto ja digitaaliset klinikat, jotka tarvitsevat objektiivista tietoa ennen konsultaatiota sekä keinon saattaa hoitoketju päätökseen sen jälkeen ilman, että potilasta pyydetään menemään muualle.
• Pitkäikäisyyttä ja terveyttä seuraavat sovellukset, jotka perustuvat toistuviin tutkimusryhmiin, joissa testien välinen kehityssuunta on lopputulos ja yksittäinen tulos on vain lähtökohta.
• Yritysten terveysalustat, jotka toteuttavat laajamittaisia seulontoja useilla toimipaikoilla, joissa logistiikka, eikä niinkään analysointi, on suurin rajoittava tekijä.
• Ravintolisä- ja ravitsemusbrändit, jotka haluavat suosituksia, jotka perustuvat mitattuun puutteeseen eikä kyselylomakkeeseen.
• Digitaaliset hoitomuodot ja hajautetut tutkimukset, joissa tarvitaan tutkimussuunnitelmassa määriteltyjä näytteitä, jotka on kerätty kotona ja joiden alkuperäketju on dokumentoitu.
• Vakuutusyhtiöt ja ennaltaehkäisyohjelmat, jotka tarvitsevat toistettavan lähtötilannemittauksen koko väestön osalta.
• Klinikkasoftware-toimittajat, jotka sisällyttävät diagnostiikkatoiminnot omien asiakkaidensa käyttöön, jotta klinikat voivat tilata tutkimuksia poistumatta jo käyttämästään järjestelmästä.

Jos tuotteesi on laboratorio tai analyysimenetelmä on patenttisi, tämä malli ei sovi sinulle. Kaikki muut ostavat infrastruktuuria.

Mitä EU:n vaatimustenmukaisuusratkaisun tulisi kattaa?

Kun kyseessä on tuote, jota markkinoidaan Saksassa tai laajemmin EU:ssa, viisi seikkaa ratkaisevat, voidaanko integraatio ottaa käyttöön. Palveluntarjoajan tulisi pystyä vastaamaan kaikkiin viiteen kysymykseen ilman, että hänen tarvitsee mennä tarkistamaan asiaa.

• Laboratorion laatustandardit. RiliBÄK koskee saksalaista laboratorion laadunvarmistusta ja ISO 15189 lääketieteellisten laboratorioiden akkreditointia. Molemmat kuuluvat analyysilaboratorion vastuualueeseen, joten kysy, mistä laboratoriosta on kyse, ja varmista, että kattavuus kuuluu sen vastuualueeseen.
• GDPR ja tietojenkäsittelysopimus. Sopimus (Auftragsverarbeitungsvertrag), jossa on lueteltu alihankkijoiden luettelo ja määritelty menettely sen muuttamiseksi, ei yleispätevä mallipohja.
• Tietojen sijainti. Missä tiedot fyysisesti sijaitsevat ja onko potilastietojen käsittelyketjussa mukana alihankkijoita, jotka sijaitsevat ETA:n ulkopuolella. Tähän kysymykseen vastataan kyllä tai ei.
• MDR, IVDR ja MPDG. Tulosten esittäminen viitealueiden ja kontekstin kera on yleensä suunniteltu siten, ettei se täytä lääkinnällisen laitteen määritelmää, vaan tulkinta jää lääkärin tehtäväksi. Jos tuotteeseesi sisältyy lisäksi pisteytystä, riskiennustetta tai neuvoja, tämä on luokittelukysymys, johon sinun on vastattava, ja palveluntarjoajan dokumentaatiossa tulisi tehdä selväksi, missä tämän vastuu päättyy.
• Ammattieettiset säännöt ja lahjonnan vastaiset säännöt. Saksassa rikoslain (StGB) 299a § ja MBO-Ä:n 31 § määrittelevät, miten rahavirrat voivat kulkea palveluntarjoajan ja potilaita välittävän tahon välillä. Järjestelypalkkiot ja ohjelmistokäyttöoikeuksista perittävät maksut ovat eri asia kuin potilasvälitysmääriin sidotut palkkiot, ja sopimuksen tulisi olla riittävän selkeä, jotta lakimiehesi voi hyväksyä sen.

Kymmenen kysymystä, jotka kannattaa esittää ennen palveluntarjoajan valintaa

1. Voinko tutustua ohjeisiin ja saada testikäyttöavaimen ennen kuin allekirjoitan mitään? Jos API on nähtävissä vasta sopimuksen solmimisen jälkeen, sitoudut toteuttamaan suunnitelmasi perustuen johonkin, jota et ole vielä lukenut.
2. Mitkä laboratoriot tutkivat näytteet, ja mihin niillä on akkreditointi? Nimet ja standardit, ei ”kumppaniverkostomme”.
3. Ovatko tulokset jäsenneltyjä, ja sisältävätkö ne yksiköt ja viitealueet kunkin merkkiaineen osalta? Pyydä todellista näytekokonaisuutta todellisesta testipaneelista, älä abstraktia kaaviota.
4. Miten merkkien ja paneelien tunnisteille annetaan versiot? Paneelien uudelleennimeäminen ja koodien muuttuminen ovat huomaamattomia vikojen lähteitä, joten kysy, mitä integraatiollesi tapahtuu, kun tuoteluettelo muuttuu.
5. Mistä saan tietää, että tulos on valmis? Tarkistamalla päätepistettä, webhookia tai takaisinsoittoa. Käytä nykyistä vastausta suunnitelmavaiheen vastauksen sijaan ja suunnittele sen perusteella, mitä tällä hetkellä on käytettävissä.
6. Mikä on virheiden semantiikka ja ovatko kirjoitukset idempotentteja? Fyysisen testin toistaminen kahdesti uudelleenkokeilun vuoksi on erityisen kallis virhetyyppi.
7. Miten poikkeukset tulevat esiin? Hemolisoitunut näyte, noutamatta jäänyt näyte, epäonnistunut merkkiaine. Kysy, mitä järjestelmäsi vastaanottaa ja kuka on yhteydessä potilaaseen.
8. Mitkä nouto- ja toimitustavat sekä mitkä maat ovat tällä hetkellä käytössä? Palvelun kattavuutta koskevissa tiedoissa kuvataan usein etenemissuunnitelma. Kysy, missä kaupungeissa on tarjolla saman päivän nouto tässä kuussa.
9. Mitä sääntöjenmukaisuuspaketti sisältää, ja voiko asianajajani lukea sen ensin? Käsittelysopimus, alikäsittelijöiden luettelo, palvelinten sijainti, laitteiden luokittelu.
10. Mitä tapahtuu tiedoilleni, jos lopetamme yhteistyömme? Vientimuoto, poistumisikkuna ja se, onko tietueet lukittu omistusoikeudellisten tunnisteiden taakse. Käyttäjiisi liittyvän historian tulisi olla siirrettävissä.

Missä Aniva sopii

Aniva on eurooppalaisille terveystuotteille kehitetty Diagnostics-as-a-Service-alusta. Yhden REST-rajapinnan kautta on saatavilla yli 2 500 parametria, jotka kattavat rutiiniverikokeet, hormonit, vitamiinit ja immunologian sekä koko genomin ja koko eksomin sekvensoinnin, transkriptomiikan, proteomiikan ja mikrobiomin analyysin. Tulokset toimitetaan jäsenneltynä JSON-muodossa, kehitystyöhön on käytettävissä testausympäristö, ja rajapinnan dokumentaatio on julkisesti saatavilla.

Taustalla rutiini- ja erikoistutkimukset suoritetaan ZOTZ|KLIMAS-laboratoriossa, jolla on RiliBÄK- ja ISO 15189 -sertifikaatit, ja moni-omiksen menetelmien takana toimivat erikoistuneet yhteistyökumppanit. Perusverikokeiden tulokset saadaan 24 tunnin kuluessa näytteenotosta. Tietojen käsittely tapahtuu EU:n alueella, ja palvelin sijaitsee Saksassa. Käsittelysopimus on osa vakiomuotoista käyttöönottoa eikä erillisen neuvottelun kohteena. Potilaille suunnatussa hallintapaneelissa ja PDF-tiedostoissa voidaan käyttää omaa brändiäsi, tai voit jättää ne pois ja näyttää tulokset omassa käyttöliittymässäsi.

Jos haluat tarkastella mallia klinikan ostajan näkökulmasta eikä insinööritiimin näkökulmasta, oheisessa artikkelissa käsitellään klinikoille suunnattua Diagnostics as a Service -palvelua, mukaan lukien hankintaan liittyvät kysymykset ja kustannusvertailu. Jos haluat mieluummin tutustua vain sovellusrajapintoihin, aloita lukemalla Aniva for Developers -artikkeli ja pyydä sandbox-avain.

Yhteenveto

Diagnostiikka on terveysteknologian alalla vähiten hohdokas integraatio ja yksi niistä, joita on helpointa aliarvioida, sillä rajapintadokumentti kuvaa vain tietomuotoa, kun taas todellinen työ liittyy fyysisiin näytteisiin, poikkeustilanteisiin ja vaatimustenmukaisuuteen. Diagnostics as a Service -malli siirtää tämän työn API:n taakse, mikä on kannattavaa aina silloin, kun testitulos on tuotteesi syöttötieto eikä itse tuote.

Palveluntarjoajan laadun mittari ei ole markkinointisivu, vaan se, pystytkö lukemaan ohjeet, hankkimaan testikäyttöavaimen, rakentamaan poikkeustilanteiden käsittelyprosessit realististen tietojen pohjalta ja antamaan lakimiehellesi käsittelysopimuksen luettavaksi ennen sitoutumista. Jos kaikki nämä neljä asiaa on mahdollista hoitaa viikon kuluessa, integraatio on todennäköisesti yhtä nopea kuin miltä se näyttää.

Usein kysyttyjä kysymyksiä

Mitä on ”Diagnostics as a Service”?

”Diagnostics as a Service” on malli, jossa tuote tilaa laboratoriotutkimuksia yhden sovellusrajapinnan (API) kautta ja saa takaisin jäsenneltyjä tuloksia, kun taas palveluntarjoaja huolehtii laboratoriotoiminnasta, näytteenottosarjoista, kuriiripalveluista sekä kyseisen sovellusrajapinnan taustalla olevasta sääntelykehyksestä. Se korvaa järjestelmän, johon muuten kuuluisi laboratori sopimus, näytteenottosarjojen toimittaja, kuriiripalvelu, tulosten jäsentäjä sekä erillinen tietojenkäsittelysopimus jokaisen osapuolen kanssa.

Kuinka kauan diagnostiikka-API:n integrointi kestää?

Dokumentoidun REST-rajapinnan ja testausympäristön avulla on realistista, että ensimmäiseen testitilaukseen kuluu vain muutama päivä ja tuotantoon siirtyminen muutama viikko, koska työ rajoittuu omaan tilausprosessiin, tulosten esittämiseen ja poikkeustilanteiden käsittelyyn. Saman toiminnallisuuden rakentaminen sisäisesti yksittäisiä laboratorioita varten on yleensä useita vuosineljänneksiä kestävä projekti, ja jokainen uusi laboratorio tai tutkimusmenetelmä edellyttää suuren osan työstä toistamista.

Onko diagnostiikka-alusta sama asia kuin laboratorio?

Yleensä ei. Useimmat alustat koordinoivat akkreditoitujen laboratorioiden toimintaa sen sijaan, että omistaisivat oman laboratorion. Laatuakkreditoinnit, kuten RiliBÄK ja ISO 15189, kuuluvat analyysin suorittavalle laboratoriolle, kun taas API, tuoteluettelo, logistiikka ja vaatimustenmukaisuuskehys kuuluvat alustalle. Kysy miltä tahansa palveluntarjoajalta, mitkä laboratoriot ovat heidän tuoteluettelonsa takana ja mihin kukin niistä on akkreditoitu.

Miltä API:sta saatavat laboratoriotulokset näyttävät?

Hyödyllinen vastaus on jäsennelty JSON-muotoinen vastaus, joka sisältää tunnisteen, arvon, yksikön sekä analysoivan laboratorion käyttämän viitealueen, sillä viitealueet ovat laboratoriokohtaisia ja riippuvat tekijöistä kuten iästä ja sukupuolesta. PDF-tiedoston tulisi olla tulos, jonka voit toimittaa käyttäjälle, ei muoto, jota koodisi joutuu jäsentämään. Pyydä todellista näytekuormaa ennen kuin suunnittelet tietomallisi.

Voinko tarjota potilaskokemusta white label -mallilla?

Kyllä, useimmissa tarjouksissa, vaikka niiden kattavuus vaihtelee. Tarkista, näkyvätkö logosi ja värit potilaan hallintapaneelissa, brändisi tulos-PDF-tiedostossa, oma aliverkkotunnuksesi sekä lähettäjän tunnistetietosi potilaille lähetettävissä sähköposteissa. Jos haluat mieluummin rakentaa käyttöliittymän itse, varmista, että sovellusrajapinta (API) tarjoaa kaikki tiedot, jotka palveluntarjoajan omassa hallintapaneelissa näkyvät.

Onko tuotteeni lääkinnällinen laite, jos siinä esitetään laboratoriotuloksia?

Tulosten esittäminen viitealueiden ja selkokielisen kontekstin kera on yleensä suunniteltu siten, ettei se täytä MDR-, IVDR- ja MPDG-asetusten mukaisia määritelmiä, ja tulkinta jää lääkärin tehtäväksi. Riskipisteytyksen, diagnoosin tai hoito-ohjeiden lisääminen muuttaa tätä analyysia, ja tuotteen luokittelu on sinun vastuullasi, ei alustan. Pyydä palveluntarjoajalta kirjallinen lausunto asiasta ja hanki oma sääntelyneuvonta kaikesta, mitä rakennat tämän pohjalta.

Missä potilastiedot tallennetaan DaaS-ympäristössä?

Se riippuu täysin palveluntarjoajasta, minkä vuoksi asia on syytä ottaa esille ensimmäisessä teknisessä neuvottelussa. Kysy, missä tiedot fyysisesti sijaitsevat, mitkä alihankkijat käsittelevät potilastietoja, sijaitseeko mikään niistä ETA:n ulkopuolella ja luetellaanko ne käsittelysopimuksessa sekä onko siinä määritelty muutosten käsittelyprosessi. Saksassa toimivan tuotteen osalta tavoitteena tulisi olla palvelinten sijainti yksinomaan EU:n alueella.

Voiko Diagnostics as a Service -palvelu hoitaa näytteiden ottamisen kotona?

Kyllä. Postitse lähetettävät testipakkaukset, joissa on valmiiksi maksettu palautuslähetys, kapillaariverinäytteenotto sormenpistolla, sylki-, uloste- ja virtsanäytteet kuuluvat kaikki DaaS-valikoiman vakiotarjontaan yhdessä kumppanipisteissä tehtävien laskimoverinäytteiden kanssa. Rakennuksesi kannalta ratkaiseva kysymys on, noudattavatko kaikki näytteenottomenetelmät yhtä tilausprosessia, yhtä tilamallia ja yhtä tulosmuotoa, vai onko jokainen niistä erillinen tapaus koodissasi.

Termien selitykset lyhyesti

• Diagnostics as a Service (DaaS) tarkoittaa laboratoriotestien tilaamista yhden sovellusrajapinnan (API) kautta, kun palveluntarjoaja huolehtii itse laboratorioista, testipakkauksista, logistiikasta ja taustalla olevasta sääntelykehyksestä.
• Jäsennellyillä tuloksilla tarkoitetaan merkkitunnistetta, arvoa, yksikköä ja viitealuetta koneellisesti luettavassa muodossa, eikä PDF-tiedostoa, jota koodisi joutuu jäsentämään.
• Viitealue on se arvojen vaihteluväli, jota analyysilaboratorio soveltaa arvoon; se riippuu käytetystä menetelmästä, iästä ja sukupuolesta, joten se liitetään tulokseen eikä sitä säilytetä koodipohjassasi.
• Sandbox on tuotantokäytöstä erillinen ympäristö, jossa on realistisia kuormia, ja juuri siellä poikkeusten käsittely tulisi toteuttaa ennen kuin varsinainen putki on olemassa.
• ”White-label” tarkoittaa, että loppukäyttäjä näkee tuotteesi tuotemerkin hallintapaneelissa, PDF-tiedostossa ja verkkotunnuksessa, kun taas alusta itsessään pysyy näkymättömänä taustalla.

Lähteet

• Aniva-sovellusliittymän (API) dokumentaatio
• ISO 15189:2022, Lääketieteelliset laboratoriot – laatu- ja pätevyysvaatimukset
• Asetus (EU) 2016/679, yleinen tietosuoja-asetus
• Lääkinnällisiä laitteita koskeva asetus (EU) 2017/745 (MDR)
• Asetus (EU) 2017/746 in vitro -diagnostiikkalaitteista (IVDR)
• Lääkinnällisten laitteiden lainsäädännön täytäntöönpanolaki (MPDG)
• Saksan rikoslain (StGB) 299a §, korruptio terveydenhuoltoalalla

Hanki sandbox-avain

Aniva tarjoaa tuotekehitystiimille yhden REST-rajapinnan, joka kattaa yli 2 500 parametria, jäsenneltyjä JSON-tuloksia, testausympäristön ja julkisen dokumentaation, ja jonka taustalla toimivat laboratoriot, testipakkaukset, kuriiripalvelut sekä EU-vaatimustenmukaisuusratkaisut. Aloita Aniva for Developers-palvelusta, lue API-dokumentaatio ja pyydä avain, kun haluat testata poikkeustilanteita todellisilla datapaketeilla.

Tämä artikkeli sisältää yleistä tietoa tuote- ja kehitystiimeille siitä, miten diagnostiikkainfrastruktuuri rakennetaan ja hankitaan. Se ei ole lääketieteellistä, oikeudellista tai sääntelyyn liittyvää neuvontaa, eikä siinä kuvata mitään diagnoosia tai hoitoa. Laboratorion akkreditointi ja viitealueet kuuluvat analyysin suorittavalle laboratoriolle, ja yksittäisten tulosten tulkinta on hoitavan lääkärin vastuulla. Päätetietojen yksityiskohdat perustuvat julkiseen API-dokumentaatioon artikkelin kirjoitushetkellä, ja ne voivat muuttua, joten kehitys on suoritettava nykyisen dokumentaation mukaisesti.