Stream: finnish PHR
Topic: Device profiili
Lauri Karppinen (Oct 01 2020 at 08:26):
Laitoin implementers kanavalle kysymystä tuosta kalibrointikoodista. Tässä siihen linkki, jos on kiinnostusta seurata tai liittyä keskusteluun: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Additional.20string.20to.20device.20resource
Yritin perehtyä tuohon DeviceMetric profiiliin, ja tuntuu, että se on enemmänkin tarkoitettu ns calibrointi "actionille". Kuitenkin kaikki muu tarvittava tieto saataisiin tallennettua device resourceen, niin kokonaisen uuden resurssin lisääminen pelkästään yhtä stringiä varten tuntuisi melko raskaalle ratkaisulle?
Lauri Karppinen (Oct 01 2020 at 08:33):
Oli puhetta Tikessä myös Devicen testaamisesta toiselle serverille. Mitä serveriä olisi hyvä käyttää testaamiseen? Olemme olleet toistaiseksi aika pitkään määrittelyn ikiloopissa, ja ei olla oikein päästy testivaiheeseen asti omien resurssien kanssa. Kaikki neuvot tähän ovat tervetulleita. Ehkä näistä voisi olla jotain seuraavan kommentointikokouksen koulutusosiossa? Tosin taisimme sopia, että testattaisiin tämän kuun loppuun mennessä.
Aleksi Aho (Oct 08 2020 at 06:02):
Uuden resurssityypin lisääminen on ehdottomasti turhan raskas keino, jos kalibrointikoodi voidaan laittaa myös deviceen. Onko @Mikael Rinnetmäki kokemusta, missä tällaista kannattaa testata?
Mikael Rinnetmäki (Oct 20 2020 at 08:19):
Tuosta "ehdottomasti turhan raskas keino" voi olla eri mielipiteitä. @Lauri Karppinen kuvasi casen, jossa kalibrointi on kertaluontoinen ja tehtaalla suoritettava. Toisaalta on olemassa myös suuri joukko laitteita, joita kalibroidaan pitkin laitteen elinkaarta. Onko sitten yhteensopivuuden kannalta järkevää, että yhdelle erityistapaukselle tehdään omanlaisensa kuvaus, ja kaikki muut tapaukset hoidetaan eri tavalla?
Mikael Rinnetmäki (Oct 20 2020 at 08:20):
@Lauri Karppinen @Aleksi Aho testiserveriksi suosittelisin https://hapi.fhir.org/. On lähellä Omatietovarannon omaa toteutusta, mutta ei ole rajoituksia profiilien luonnin suhteen tms.
Lauri Karppinen (Oct 27 2020 at 08:39):
En ole ilmeisesti onnistunut selittämään meidän use casea tuon koodin suhteen tarpeeksi hyvin. Tässä vielä tarkennus mitä tuolla kalibrointi koodilla meidän tapauksessamme tarkoitetaan:
"Kalibrointikoodi on tekstimuotoinen koodi, jolla mittalaite ohjelmallisesti säätää itsensä tarkaksi tietyn virtausanturierän kanssa käytettäväksi. Eri virtausantureiden tuotantoerissä on pientä variaatiota, joka korjataan käyttämällä kalibrointikoodia. Kalibrointikoodi sisältää eräkohtaiset korjauskertoimet sekä koodin tarkistussumman.
Kalibrointikoodi on laitteen kannalta erittäin tärkeä, koska laitteen mittaussignaali ja siten saadut mittaustulokset säätyvät - kalibroituvat - sen mukaan.
Koodin tallennus on laaduntarkkailun vuoksi tarpeellinen, sen pohjalta voi jälkikäteen tarkistaa onko mittaukset tehty oikealla kalibrointikoodilla ja myös milloin kalibrointikoodi on vaihdettu (mittausten päivämääristä ja kellonajoista). Jos mittaustulokset muuttuvat kalibrointikoodin vaihtumisen hetkellä, voi tämä muutos johtua paitsi oikeasta mitattavan keuhkojen toiminnan muutoksesta myös kalibrointikoodin vaihtamisesta. Tällöin pitää selvittää kuinka tutkittava/tutkija sen vaihtoi. Eli vaikkapa, että oliko ennen tätä hetkeä tehdyt mittaukset tehty varmasti oikealla kalibrointikoodilla (unohdus). Tai onko sillä hetkellä otettu varmasti oikean tuotantoerän kalibrointikoodi käyttöön (koodien sekaantuminen).
Virtausanturin kalibrointikoodi on verrattavissa veren glukoosimittarin mittaliuskan koodiin.
Kalibrointikoodi on yleensä erilainen eri tuotantoerille, mutta ei välttämättä. Eli tuo ei yksiselitteisesti kerro tuotantoerää, mutta koska se on jokaiselle tuotantoerälle ominainen, se näin ollen toimii tarvittaessa myös virtausanturin tuotantoerän tunnisteena. Joka tapauksessa sen perusteella voidaan virtausanturierät rajoittaa huonoimmillaankin muutamaan. Medikrossa on tieto jokaisen virtausanturierän kalibrointikoodeista."
devicemetric.calibration tarjoaisi paikan kalibroinnille, mutta sielläkään ei tunnu olevan paikkaa stringille, joka on ainoa asia, mitä meidän pitäisi kalibrointiin liittyen tallentaa. Toisena vaihtoehtona tuossa linkkaamassani viestissä implementers kanavalle ehdotettiin: Device.property elementtiä. John Moehrke viestin perusteella se olisi rajoittamaton joukko arvo-avain pareja, mutta en nyt suoraan ymmärtänyt senkään käyttöä. Propertyn alta löytyvät ainoastaan: type, valueQuantity ja valueCode.
Vaikeaa sanoa, mikä nyt olisi se kaikista "oikein"/paras tapa tallentaa tuo kalibrointikoodin stringi. Alunperin tuohon extensionin käyttöön on suunnitelmissamme päädytty varmaan juuri siksi, ettei sitä juuri oikeaa paikkaa tuntunut löytyvän. Resurssi tuolle extensionille on jo valmiiksi tehtynä, joten liputan edelleen sen puolesta. Ehdotuksia tietenkin otetaan edelleen vastaan, ja pitäähän tuo device resurssi tietenkin saada mahdollisimman yleiskäyttöiseksi, ja kaikille sopivaksi.
Oliko asia niin että sinne device resurssiin jokatapauksessa täytyy lisätä paikka sille omatietovarannon creatingApplication extensionille. Onko siitä jotain haittaa, jos sinne lisätään myös meidän calibrationCode extension?
Last updated: Apr 12 2022 at 19:14 UTC
