Ilmanvaihdon huoltotiedot digitaaliseen kotiprofiiliin

Digitaaliseen kotiprofiiliin koottu ilmanvaihdon huoltotieto on käyttökelpoista, kun tietueesta selviävät järjestelmän osa, tiedon lähde, voimassa oleva versio ja se, onko kyse suunnitellusta työstä, tehdystä huollosta vai vielä vahvistamattomasta havainnosta. Ammattilaisen tehtävä on pitää nämä tiedot erotettavina myös silloin, kun niitä siirretään huoltokirjan, työnohjausjärjestelmän ja kohteen muun dokumentaation välillä.

Tämä opas keskittyy ilmanvaihtojärjestelmän perustietojen ja huoltohistorian mallintamiseen. Se täydentää yleisiä palvelusopimustietoja ja yksittäisen huoltokäynnin toteumakirjausta: tarkastelun kohteena ovat ilmanvaihdon laitteiden, alueiden, mittausten ja muutosten suhteet. Kotiprofiili tarkoittaa tässä yleistä digitaalista tietomallia, ei väitettä minkään tietyn palvelun ominaisuuksista. Artikkeli ei määritä laitekohtaisia huoltovälejä, ilmavirtojen hyväksymisrajoja tai tietosuojaroolia yksittäiselle palvelulle. Yleinen ilmanvaihdon kunnossapito kuuluu eri hakutarpeeseen kuin tässä kuvattu tietomallinnus; asukaskäyttöön suunnatut perustoimet käsitellään ilmanvaihdon huoltoa ja puhdistusta koskevassa oppaassa, kun taas tämän tekstin lukija suunnittelee ylläpidon tietovirtaa.

Rajaa profiilin käyttötarkoitus

Ennen kenttien suunnittelua ylläpidon tilaaja, palveluntuottaja ja tiedon omistaja sopivat, mitä päätöksiä profiilin avulla tehdään. Yksi tavoite voi olla löytää ilmanvaihtokoneen oikea käyttöohje ennen huoltokäyntiä. Toinen voi olla selvittää, mitä suodatin- tai puhallinkokoonpanoa viimeksi käsiteltiin. Kolmas voi olla tarkistaa, mihin huoneistoihin tai tiloihin järjestelmän osa vaikuttaa. Tietomalli rakennetaan näiden tarpeiden ympärille, ei yleiseksi asiakirjojen keräyspaikaksi.

Eri käyttötarpeet vaativat eri tietokerroksen. Järjestelmä- ja laitetieto kuvaa kohteen rakennetta. Huolto-ohjelma kuvaa suunniteltua työtä ja sen perustetta. Työmääräin ohjaa yksittäistä tehtävää; toteumaraportti kertoo, mitä kyseisellä käynnillä tapahtui. Muutoshistoria kertoo esimerkiksi laitteen vaihdosta tai hyväksytystä asetuksen muutoksesta. Jos kaikki kerrokset tallennetaan yhteen vapaatekstikenttään, käyttäjä ei pysty päättelemään, mikä tieto on nykytilaa ja mikä yksittäisen työn havainto.

Rakentamislain 139 §:ssä edellytetään uudelle rakennukselle konekielisesti luettavaa, tietomalliin tai koneluettaviin tietoihin perustuvaa käyttö- ja huolto-ohjetta. Ohje laaditaan myös luvanvaraisessa korjaus- tai muutostyössä toimenpidealueesta. Pykälä luettelee ohjeeseen kuuluvia perus-, toteuma-, historia- ja ylläpidon seurantatietoja, edellyttää huolto-, korjaus- ja muutostöiden merkitsemistä sekä asettaa vastuun ohjeen ajantasaisuudesta rakennuksen omistajalle. Tämä ei tarkoita, että laki määräisi kaikille olemassa oleville rakennuksille saman digitaalisen tuotteen tai tietomallin. Palveluntuottaja ja omistaja voivat sopia tiedon tuottamisen ja välittämisen käytännöistä, mutta sopimusehto ei sellaisenaan siirrä laissa nimettyä vastuuta. Rakentamislaki 751/2023, 139 § – Finlex.

Taulukon erottelu kannattaa näkyä myös käyttöliittymässä. Esimerkiksi kenttätyöntekijälle voidaan näyttää laitteen perustiedon lisäksi sovittu tehtävä ja viimeisin olennainen huoltotieto, kun taas kohdetiedon ylläpitäjä tarvitsee versionhallinnan ja hyväksymistiedot. Kaikille ei tarvitse näyttää koko historiaa, mutta tehtävässä tarvittava tieto ei saa jäädä käyttöoikeusrajan taakse vahingossa.

Rakenna ilmanvaihdon tietomalli kohteen rakenteesta

Ilmanvaihtotietomallin lähtökohta on kohteen todennettava rakenne, ei järjestelmän oletettu tai yleinen rakenne. Luettavissa oleva hierarkia auttaa huoltoa löytämään oikean laitteen ja tunnistamaan sen vaikutusalueen, mutta jokainen linkitys tarvitsee lähteen. Tässä artikkelissa kuvattu rakenne on ammattilaisen suunnittelumalli, ei virallinen standardi tai vaatimus tietylle ohjelmistolle.

Yhdistä rakennus, järjestelmä ja laite

Ilmanvaihdon laite ei toimi tietomallissa irrallisena rivinä. Siihen liitetään rakennus, järjestelmäkokonaisuus, palveltava alue ja tarvittaessa alemman tason osat, kuten puhallin tai suodatinkammio. Tunnisteet valitaan kohteen hyväksytystä tietokäytännöstä. Jos tunnistetta ei ole, sovitaan väliaikainen tunniste ja sen vahvistamisen omistaja. Vapaamuotoinen nimi, kuten ”yläkerran kone”, voi auttaa käyttäjää, mutta ei yksin korvaa yksilöivää kohdetunnistetta.

Järjestelmän palvelualue esitetään tarkkuudella, joka tukee työn suunnittelua. Se voi olla rakennus, porrashuone, asuntojoukko tai muu dokumentoitu vyöhyke. Rajauksen yhteyteen lisätään viite piirustukseen, malliin tai muuhun hyväksyttyyn lähteeseen. Jos palvelualue on epäselvä, tieto merkitään tarkistettavaksi eikä päätellä pelkän laitteen nimen perusteella.

Laitetietueeseen voidaan sisällyttää laiteluokka, valmistaja ja malli silloin kun ne tunnetaan, sarja- tai kohdetunniste, sijainti, käyttöönottotiedon lähde sekä linkki hallittuun ohjeeseen. Näiden kenttien täyttö ei tarkoita, että jokainen tieto olisi saatavilla jokaisesta vanhasta kohteesta. Tuntematon, puuttuva ja vahvistettu arvo erotetaan toisistaan. Tiedon laadun tila kertoo, onko arvo saatu dokumentista, kentällä varmennettu vai vielä selvityksessä.

Kun järjestelmään kuuluu useita koneita tai muutettavia osia, tietueiden väliset suhteet ovat usein yksittäisiä teknisiä kenttiä tärkeämpiä. Ilmanvaihtokoneen vaihtaminen ei tarkoita, että sen palvelualue vaihtuu; puhaltimen vaihto ei välttämättä muuta koko koneen perustietuetta. Mallissa kuvataan, mikä kohde korvautui, mikä jatkaa käyttöä ja mistä päivästä muutos on voimassa.

Tallenna lähde ja aikaleima tiedon yhteyteen

Jokaisella teknisesti merkityksellisellä tiedolla on lähde. Suunnitteluarvon lähde voi olla hyväksytty suunnitelma, laitteen tunnistetieto tyyppikilpi tai luovutusasiakirja ja huollossa tehty havainto allekirjoitettu raportti tai työmääräin. Profiiliin merkitään lähteen tyyppi, tunniste, versio tai päiväys sekä vastaanoton tai varmennuksen ajankohta. Dokumenttiviite ei korvaa alkuperäisen aineiston säilyttämistä, jos kohteen käytäntö edellyttää sitä.

Aikaleimoissa erotetaan tiedon tapahtuma-aika, kirjausaika ja voimaantulo. Jos laite vaihdettiin maanantaina mutta järjestelmätietue päivitettiin perjantaina, molemmat ajankohdat ovat tärkeitä. Samoin huollon suunniteltu määräpäivä on eri asia kuin työn suoritusaika. Tietomallissa ei käytetä yhtä päivämääräkenttää kaikille näille käsitteille.

Versiohistoria estää vanhaa arvoa näkymästä nykyisenä. Kun uudempi lähde hyväksytään, vanha tieto merkitään korvatuksi tai poistuneeksi sovitun mallin mukaan ja uusi tieto liitetään hyväksynnän näyttöön. Pelkkä viimeksi muokattu aikaleima ei osoita, että tieto olisi teknisesti tarkistettu. Tietueella voidaan siksi olla erilliset tilat esimerkiksi ehdotettu, lähteestä varmennettu, käytössä, korvattu ja selvitettävä.

Älä päättele puuttuvaa arvoa

Teknisen tiedon puute on usein työjonon kysymys. Jos laitteen tyyppi tai palvelualue ei ole tiedossa, profiiliin avataan selvitystehtävä ja nimetään rooli, joka voi hankkia tai vahvistaa tiedon. Kentälle ei keksitä korvaavaa arvoa toisesta samankaltaisesta koneesta. Jos väliaikaista tietoa tarvitaan työn käynnistämiseen, sen väliaikaisuus ja käyttöraja kuvataan, ja tilaaja tai tekninen vastuuhenkilö hyväksyy menettelyn.

Tietosanasto vähentää saman tiedon kirjautumista eri tavoin. Kentän määritelmä kertoo esimerkiksi, tarkoittaako ”asennuspäivä” ensimmäistä käyttöönottoa, viimeisintä laitevaihtoa vai tietueen luontia. Samoin ”suodattimen tyyppi” voidaan esittää laitevalmistajan tai järjestelmäsuunnittelijan tunnisteena, mutta korvaavaa tuotetta ei valita ilman sovellettavaa perustetta. Kenttien merkitys, sallitut arvot ja yksiköt dokumentoidaan järjestelmien välillä.

Mallinna huollon, mittauksen ja muutoksen tiedot

Kun perustietueet ovat hallittuja, seuraava kerros kuvaa ylläpidon tapahtumia. Suunniteltu tehtävä, toteutunut työ, mittaus, havainto ja hyväksytty muutos on pidettävä erillään, jotta huoltokirjan nykytila ei sekoitu yksittäisen käynnin havaintoon. Kiinteistön yleisen huoltokirjan tehtävä- ja historiatiedot muodostavat laajemman taustan; kiinteistön huoltokirjaa koskeva yleisopas käsittelee tätä kokonaisuutta, kun taas ilmanvaihtokohtaiset toteumat voidaan yhdistää siihen tunnisteilla ja lähdeviitteillä.

Erota tehtävän suunnitelma ja toteutunut käynti

Huolto-ohjelma sisältää tehtävän tarkoituksen, kohteen, toistuvuuden tai muun käynnistimen, tiedon lähteen ja vastuuroolin. Toistuvuus tuodaan valmistajan tai kohteen hyväksytystä ohjeesta tai sovitusta ohjelmasta. Artikkeli ei anna yleispäteviä vaihtovälejä, puhdistusjaksoja tai säätöaikoja. Jos lähteen voimassaolo on epäselvä, se merkitään suunnitelman tarkistustehtäväksi. Kohteen aikataulutettu kokonaisuus voidaan suhteuttaa kiinteistön määräaikaishuoltojen hallintaan, mutta ilmanvaihdon tehtävän lähde ja toteuma on silti esitettävä omana tietonaan. Ympäristöministeriön asetus 1009/2017 koskee uuden rakennuksen sisäilmaston ja ilmanvaihdon suunnittelua ja rakentamista sekä laajennusta ja kerrosalaan laskettavan tilan lisäämistä; sen suunnittelusäännöksiä ei pidä esittää kaikkien olemassa olevien rakennusten yleisinä huoltoväleinä. Asetuksen 8 § edellyttää suunnittelussa keskeisten toimintojen mitattavuuden, ohjattavuuden ja seurattavuuden huomioimista, ja 24 § käsittelee puhdistettavuutta ja huollettavuutta. Näistä voi johtaa ylläpitotietomallin suunnittelutarpeita, ei yksittäisen vanhan kohteen hyväksymisrajoja.

Yksittäinen työmääräin viittaa suunniteltuun tehtävään, mutta sisältää oman tunnisteen, ajankohdan ja kohdeviitteen. Toteumaraporttiin kirjataan, mitä tehtiin, mitä jäi tekemättä, mitä havaittiin ja mikä jatkotoimi syntyi. Muutaman rivin huoltoraportti voi olla riittävä yksinkertaiselle työlle, mutta se ei saa muuttaa suunniteltua huoltoa tehdyksi ennen toteumaa.

Jos huolto on osittainen, alkuperäisen työmääräimen tila säilyy osittaisena, vaikka tehdyt vaiheet kirjataan toteumaan. Jatkotehtävän avaaminen ei muuta tekemätöntä vaihetta suoritetuksi. Kokonaan toteutunut huolto ja siitä syntynyt erillinen tutkimustarve voidaan sen sijaan käsitellä eri tiloissa. Alkuperäisen työmääräimen ja jatkotehtävän linkki säilyttää asiayhteyden.

Tallenna mittaus käyttökelpoisena havaintona

Ilmanvaihdon mittausmerkintä tarvitsee suureen lisäksi yksikön, mittauspisteen, ajankohdan, tekijän tai vastuuroolin, menetelmäviitteen sekä olosuhteen tai käyttötilan, jos ne vaikuttavat tuloksen tulkintaan. Esimerkiksi lukema ilman yksikköä tai mittauspisteen nimeä ei ole vertailukelpoinen. Jos lukema kirjataan käsin, tarkistetaan, ettei desimaalierotin tai yksikkö muutu järjestelmäsiirrossa.

Suunnitteluarvo, huollossa mitattu arvo ja hyväksymisraja ovat eri tietoja. Ne voivat olla rinnakkain raportissa vain, jos lähteet ja tarkoitukset erottuvat. Hyväksymisrajaa ei kopioida suunnitelmasta mittaustulokseksi eikä yksittäisen mittauksen perusteella päätellä koko järjestelmän toimivuutta. Tämä tietomalli ei aseta ilmanvaihdolle teknisiä tavoitearvoja; ne tarkistetaan kohteen suunnitelmista, soveltuvista ohjeista ja asiantuntijalta.

Mittauspisteiden nimet pidetään vakaina, jotta eri käyntien tuloksia voidaan verrata. Jos pisteen tunniste muuttuu, vanhan ja uuden tunnisteen vastaavuus dokumentoidaan. Mittaustiedon siirrossa testataan myös puuttuva arvo, yksikkövirhe ja toistuva tunniste. Virheellinen tietue ohjataan tarkistukseen eikä automaattisesti hyväksytä.

Pidä asetukset, havainnot ja diagnoosit erillään

Käyttöasetus, havaittu tila ja tekninen diagnoosi kuuluvat eri tietueisiin tai tiloihin. Jos huoltaja havaitsee näytöltä ohjauksen nykyisen tilan, hän voi kirjata sen havaintona yhdessä ajan ja laitteen kanssa. Pysyväksi asetustiedoksi se päivittyy vasta, kun muutoksen tekijä, peruste, hyväksyntä ja voimaantulo ovat tiedossa. Näin profiili ei vahingossa muuta yksittäistä havaintoa kohteen hyväksytyksi asetukseksi.

Hälytys tai käyttäjän ilmoitus voi käynnistää selvityksen, mutta se ei ole itsessään vian syy. Digitaalinen järjestelmä voi liittää sen laitteeseen ja näyttää avoimena tapahtumana. Työntekijä tai asiantuntija dokumentoi tehdyn tutkimuksen ja päätelmän erikseen. Jos syytä ei selvitetty, merkintä kertoo sen ja jatkotoimen.

Suunnittele hyväksyminen ja tiedonsiirto

Tietueen tekninen oikeellisuus ei yksin riitä, jos ei tiedetä, kuka saa ehdottaa, hyväksyä ja julkaista muutoksen kohteen ylläpitotiedoksi. Tiedon siirrossa tarvitaan sama jäljitettävyys kuin manuaalisessa päivityksessä: lähde, vastaanottaja, tarkistus, virhetilanne ja korjausvastuu. Alla oleva menettely erottaa roolit ja tekniset rajapinnat tekemättä oletuksia tietyn huoltoalustan toiminnoista.

Kuka saa päivittää mitäkin

Operatiivinen ylläpitovastuu, sopimuksen hyväksyjä, kohdetiedon ylläpitäjä ja henkilötietojen käsittelyroolit ovat eri käsitteitä. Tietomallissa nimetään vähintään, kuka ehdottaa muutosta, kuka varmistaa tiedon lähteen, kuka hyväksyy pysyvän kohdetiedon ja kuka toteuttaa teknisen päivityksen. Sama ihminen voi toimia useassa roolissa, mutta hyväksymistapahtuman on silti oltava jäljitettävissä. Yhtiön kunnossapitovastuun yleinen tausta ja tiettyjen LVI-järjestelmien tarkasteluperiaatteet eivät silti ole tämän artikkelin hakutarkoitus; esimerkiksi LVI-järjestelmän tarkastus kuntotarkastuksessa käsittelee teknisen kunnon arviointia, ei ylläpitotiedon tietomallia.

Käyttöoikeus rajataan tehtävän mukaan. Kenttätyöntekijä voi lisätä käyntitoteuman ja havaintoehdotuksen, mutta pysyvän laitteen tai suunnitteluarvon muuttaminen voi edellyttää nimettyä hyväksyjää. Oikeuksia tarkistetaan roolin tai palveluntuottajan vaihtuessa. Tietueen muutoshistoriaan kirjataan tekijä, ajankohta, lähde ja syy soveltuvassa laajuudessa.

Rakentamislain käyttö- ja huolto-ohjetta koskeva velvoite ei ratkaise kaikkia palvelusopimuksen luovutusrooleja. Jos asunto-osakeyhtiön ilmanvaihdon kunnossapitovastuuta käsitellään, asunto-osakeyhtiölain 4 luvun yhtiön ja osakkeenomistajan vastuunjaon lähtökohta sekä yhtiöjärjestys ja olosuhteet tarkistetaan. Yksittäisen kohteen työnjako ja tietojen hyväksyntä sovitaan toimivaltaisten osapuolten kanssa. Asunto-osakeyhtiölaki 1599/2009, 4 luku – Finlex.

Määrittele integraation lähde ja virhepolku

Ennen järjestelmäintegraatiota sovitaan, mikä järjestelmä on ensisijainen kullekin tietoryhmälle. Huoltokirja voi olla rakennuksen perustietojen lähde, työnohjausjärjestelmä yksittäisen käynnin tapahtumien lähde ja hallittu asiakirja-arkisto hyväksyttyjen ohjeiden lähde. Tämä on esimerkkimalli, ei vaatimus tietyn tuotteen käytöstä. Jos kaksi järjestelmää kirjoittaa samaa kenttää, ristiriitatilanteeseen nimetään ratkaisu eikä käytetä hiljaista viimeisin päivitys voittaa -sääntöä.

Kenttäkartoituksessa määritetään lähdekenttä, vastaanottokenttä, muunnos, yksikkö, pakollisuus, vastaavuus ja virhetilanne. Tunnisteen tai mittausyksikön katoaminen on käsittelyvirhe, ei tyhjän kentän täyttämistä myöhemmin muistista. Tuontiin lisätään tarkistus esimerkiksi tuntemattomille tunnisteille, kaksoiskappaleille, puuttuville yksiköille, vanhentuneille versioille ja huonosti muodostetuille päivämäärille.

Testaus tehdään kuvitteellisella aineistolla, jossa on sekä onnistuva että hylättävä esimerkki. Varmistetaan, että työmääräimen toteuma liittyy oikeaan laitteeseen, vanha arvo säilyy historiassa, muutoksen hyväksyntä näkyy ja poikkeama jää avoimeksi, kunnes sen sulkemisehto täyttyy. Tuotantoon siirrossa sovitaan myös palautusmenettely, jos väärä tietue päivittyy laajasti.

Rajaa henkilötiedot tarkoitukseen

Huoltopyyntö voi sisältää yhteystietoja, kulun järjestämistä tai asukkaan kuvaileman oireen. Profiiliin siirrettävän henkilötiedon tarpeellisuus arvioidaan tehtävän mukaan. Huoneistotunnistekin voi liittyä tunnistettavaan henkilöön; nimen poistaminen ei yksin tee aineistosta anonyymiä. Arvio perustuu tietosuoja-asetuksen 4 artiklan henkilötiedon määritelmään. Yhteystietojen käyttöoikeus, säilytys ja poistaminen sovitetaan todelliseen käsittelyyn.

EU:n yleisen tietosuoja-asetuksen 5 artikla edellyttää henkilötietojen rajaamista käsittelyn tarkoitukseen nähden tarpeelliseen, täsmällisyyden ylläpitämistä ja säilytysajan rajaamista. Asetuksen 6 artiklassa säädetään käsittelyn oikeusperusteista. Käyttömukavuus ei yksin muodosta oikeusperustetta. Tietosuoja-asetus, 5–6 artikla.

Rekisterinpitäjän ja käsittelijän roolit selvitetään käsittelyn todellisen järjestelyn perusteella. Asetuksen 4 artikla määrittelee roolit, 12–14 artiklat käsittelevät informointia ja 32 artikla riskiä vastaavia turvatoimia. Yhteinen tietokenttä ei itsessään oikeuta kaikkien käyttäjien pääsyä henkilötietoihin. Yksittäisen palvelun soveltamisarvio tehdään organisaation tietosuojavastuullisen kanssa. Tietosuoja-asetus, 4, 12–14 ja 32 artikla.

Teknisissä havainnoissa vapaatekstiä ohjataan kertomaan laite, sijainti, aika ja havaittu oire. Kenttään ei kerätä tarpeettomia tietoja asukkaan terveydestä tai elämäntilanteesta. Kuvan käyttöä harkittaessa arvioidaan, onko kuva tarpeen työn tarkoitukseen ja voiko se sisältää tunnistettavan henkilön tai muuta ylimääräistä tietoa. Tietosuojaroolit ja säilytysaika eivät määräydy sillä perusteella, mikä rooli päivittää laitekenttää.

Ota ilmanvaihdon profiilitiedot käyttöön hallitusti

Käyttöönotto kannattaa aloittaa rajatusta kohteesta tai järjestelmäryhmästä. Aluksi inventoidaan lähteet ja tunnisteet, sovitetaan ne tietomalliin ja merkitään puutteelliset tietueet selvitykseen. Seuraavaksi testataan yksi tavallinen huolto, yksi mittaustietue, yksi havainto ja yksi hyväksytty muutos. Testauksen tavoitteena on seurata tietoa koko ketjussa, ei todistaa teknistä järjestelmää toimivaksi.

Hyväksymistarkastelussa arvioidaan, näkeekö huoltaja oikean koneen ja sen lähdeasiakirjan, erottuuko mitattu tieto suunnitteluarvosta, säilyykö avoimen poikkeaman tila ja pystyykö kohdetiedon omistaja hyväksymään pysyvän muutoksen. Samalla tarkistetaan, ettei tietomalli väitä olevansa standardinmukainen tai virallinen huoltokirja ilman asianmukaista määrittelyä.

Pilotin jälkeen työnjohto ja kohdetiedon omistaja käyvät otoksen läpi. Otos voi sisältää normaalin huollon, osittaisen työn, mittauksen ja muuttuneen laitetiedon. Jokaisesta löydöksestä kirjataan, korjataanko lähdeasiakirja, kenttämäärittely, integraatio vai ohjeistus. Puuttuva tieto ei muutu valmiiksi sillä, että se on lisätty järjestelmään; sen luotettavuus perustuu lähteeseen ja hyväksyttyyn käsittelyyn.

Seurannassa voidaan laskea puuttuvat kone–alue-suhteet, mittausyksiköt ja muutosviitteet. Perusjoukko ja ajanjakso kirjataan mittarin määritelmään. Luvut kuvaavat tietoprosessia, eivät ilmanvaihdon teknistä suorituskykyä.

Kuvitteellinen tiedonsiirtotapaus

Seuraava tapaus on kuvitteellinen. Huollon toimija vaihtuu rakennuksessa, jossa on useita ilmanvaihtokoneita ja aiemmasta järjestelmästä viety tietueita. Osa riveistä sisältää laitteen tunnisteen ja asiakirjaviitteen, osa vain vapaamuotoisen sijainnin. Kahdelle mittaustiedolle on kirjattu lukema ilman yksikköä. Esimerkin puutteet ovat keksittyjä, eivätkä kuvaa alan yleistä tilannetta.

Uusi toimija ei tuo kaikkia rivejä suoraan hyväksyttyyn perustietoon. Tunnistetut laitteet yhdistetään lähdeasiakirjoihin ja kohteen nykyisiin tunnisteisiin. Vapaamuotoiset sijainnit viedään selvitysjonoihin, joissa tilaaja nimeää tarkistajan. Yksiköttömät mittaustiedot säilytetään alkuperäisenä tapahtumatietona, mutta niitä ei verrata suunnitteluarvoihin eikä käytetä hyväksyntänä ennen menetelmän ja yksikön vahvistamista.

Yhdellä koneella laite on vaihdettu aiemmin, mutta raportti ei näy perustietueessa. Työnjohto liittää vaihtoa koskevan luovutusasiakirjan, varmistaa voimaantulopäivän ja pyytää kohdetiedon hyväksyjää päivittämään laitteen. Vanha laite merkitään poistuneeksi, ja sen huoltohistoria säilytetään yhteydessä vanhaan tunnisteeseen. Uusi laite saa oman tunnisteen, palvelualueen ja dokumenttiviitteen.

Testissä varmistetaan, että työntekijä näkee hyväksytyn käyttöohjeen, mutta ei voi huomaamatta muuttaa suunnitteluarvoa. Havainto yhdistyy järjestelmän osaan ja avoimeen jatkotehtävään. Tietomallin käyttöönottoa koskevassa päätöksessä luetellaan hyväksytyt tietoryhmät, selvityksessä olevat rivit ja niiden omistajat. Tietoryhmän hyväksyntä ei ole ilmanvaihtojärjestelmän tekninen hyväksyntä. Esimerkki osoittaa tietojen siirron hallintaa, ei kohteen teknistä kuntoa eikä minkään palvelun ominaisuutta.

Yhteenveto

Digitaalinen ilmanvaihdon huoltotieto on käyttökelpoista vasta, kun nykytilan perustiedot, huoltosuunnitelma, työkohtainen toteuma, mittaus, havainto ja hyväksytty muutos eivät sekoitu toisiinsa. Laitteen, järjestelmän ja palvelualueen tunnisteet yhdistetään lähdeasiakirjoihin; tekniselle arvolle merkitään lähde, versio ja ajankohta. Puuttuva tieto jätetään selvitykseen, eikä samankaltaisen laitteen tietoa kopioida oletuksena.

Rakentamislain käyttö- ja huolto-ohjeen velvoitteet, sopimuksen työnjako, tekninen suunnittelu ja henkilötietojen käsittely ovat eri asioita. Käyttöönotto kannattaa rajata testattavaan kohteeseen, jossa tarkistetaan sekä hyväksytyn tiedon kulku että virheiden käsittely. Digitaalinen kotiprofiili on tässä toimintamalli, ei väite valmiin tuotteen ominaisuuksista tai korvaaja rakennuksen omistajan lakisääteiselle vastuulle.

Usein kysytyt kysymykset

Mitä ilmanvaihdon tietoa digitaaliseen kotiprofiiliin kannattaa tallentaa?

Tallenna määriteltyyn ylläpitokäyttöön tarvittavat tiedot, kuten järjestelmän ja laitteen tunniste, palvelualue, tiedon lähde, huoltohistorian viite ja hyväksytty muutos. Tehtävän tarkka toteuma voi olla työmääräinjärjestelmässä, jos profiili linkittää siihen luotettavasti.

Voiko mittaustuloksen tallentaa ilman yksikköä?

Arvo voidaan säilyttää alkuperäisenä tapahtumatietona, mutta sitä ei pidä tulkita tai verrata ilman suuretta, yksikköä ja mittauspisteen tunnistetta. Puuttuva tieto merkitään selvästi ja täydennetään lähteestä tai mittauksen tekijältä.

Määrittääkö rakentamislaki jokaiselle kiinteistölle digitaalisen ilmanvaihtoprofiilin?

Rakentamislain 139 § käsittelee käyttö- ja huolto-ohjetta tietyissä rakennus- ja muutostilanteissa sekä ohjeen sisältöä ja ajantasaisuutta. Se ei sellaisenaan määrää käyttämään tiettyä digitaalista palvelua tai rakennetta.

Kuka saa hyväksyä ilmanvaihtotiedon pysyväksi kohdetiedoksi?

Se sovitaan kohteen tiedonhallinta- ja sopimusmenettelyssä. Tehtävärooli, lähteen varmennus, teknisen muutoksen hyväksyjä ja tietosuojarooli ovat erillisiä kysymyksiä, vaikka sama henkilö hoitaisi niistä useamman.

Saako asukkaan ilmoitus tallentua ilmanvaihdon huoltotietoon?

Ilmoitus voidaan käsitellä tehtävän kannalta tarpeellisessa laajuudessa. Henkilötietojen käyttötarkoitus, oikeusperuste, käyttöoikeus ja säilytys arvioidaan todellisen käsittelyn mukaan; tekninen oire erotetaan tarpeettomista henkilötiedoista.

Lähteet

• Finlex: rakentamislaki 751/2023, 139 § – käyttö- ja huolto-ohje
• Finlex: asunto-osakeyhtiölaki 1599/2009, 4 luku – kunnossapitovastuu
• Finlex: ympäristöministeriön asetus uuden rakennuksen sisäilmastosta ja ilmanvaihdosta 1009/2017 – nykytila ja soveltamisala
• EUR-Lex: yleinen tietosuoja-asetus (EU) 2016/679, 4–6, 12–14 ja 32 artikla