HL7 CDA FAQ päivitetty 15.1.2005 Tämän dokumentin OID-tunnus on 1.2.246.777.11.2005.9. HL7 Help Desk on tarkoitettu HL7 yhdistyksen toteuttamien standardien ja rajapintojen käyttöönottoon liittyvään neuvontaan sekä toimittajille että asiakkaille. Toiminta rahoitetaan kansallisen terveysprojektin ja HL7 Finland ry:n toimesta. Mikäli neuvonnan aihe on selvillä, niin kannattaa ottaa suoraan yhteyttä suoraan kyseiseen asiantuntijaan. Asiantuntijat siirtävät tarvittaessa kysymykset oikealle osaajalle ja tarvittaessa vastaukset muotoillaan yhdessä. Osa vastauksista on syytä käsitellä yleisemminkin ja tuoda ne ehkä osin uudelleenmuotoiltuna FAQ-listalle, joka avautuu aihealueittain linkkien perusteella. Aihealueet: 1 Standardointi 2 HL7 CDA R1 määritykset 3 HL7 CDA R2 määritykset 4 HL7 CDA sanomat (SOAP) 5 HL7 V2 sanomat 6 HL7 V3 sanomat 7 Oid-tunnus 8 Sovellutusrajapinnat API 9 Dokumenttiarkisto Help Desk toiminta päättyi 31.12.2004 ja sitä antoivat seuraavat henkilöt: Yhteystiedot: - Antero Ensio antero.ensio@ensitieto.fi - Timo Tarhonen timo.tarhonen@tto.fi - Timo Itälä timo.itala@conceptia.fi - Aino Virtanen aino.virtanen@satshp.fi - Pasi Leino pasi.leino@lforce.fi - Ari Vähä-Erkkilä ari.vaha-erkkila@primesolutions.fi - Esa Matinmikko cda-helpdesk@mawell.com - Jari Porrasmaa jari.porrasmaa@uku.fi Toiminnan jatkumisesta ja siihen osallistuvista henkilöistä tiedotetaan WWW.HL7.fi sivuilla, kun vuoden 2005 työohjelma on sovittu.
1 Standardointi 1.1 Voiko sosiaali- ja terveydenhuollon tietotekniikan standardeja itse muuttaa? Mikäli käyttää standardia, on sitä käytettävä sellaisenaan. Standardin kehittäminen tapahtuu standardiorganisaation puitteissa ja siihen työhön on yleensä halukkailla mahdollisuus osallista sekä Suomessa että maailmalla. Mikäli muuttaa itse standardia, niin uudesta lopputuloksesta ei enää saa käyttää standardin nimeä eikä puhua edes mukailusta standardista. 1.2 Miten toimin, jos havaitsen sosiaali- ja terveydenhuollon tietotekniikan standardeissa virheitä ja puutteita? Ensin pyritään selvittämään ongelma Help Deskin kanssa, jota kautta korjaukset ja kehitysideat viedään eteenpäin. Myös virallisesti muutosesityksellä voi lähestyä HL7 Finland ry:n teknillistä komiteaa (Timo Tarhonen co-chair ja Antero Ensio co-chair). 1.3 Mistä saan tietoa sosiaali- ja terveydenhuollon tietotekniikan standardeista? Sosiaali- ja terveydenhuollon tietotekniikan standardeista on tehty myös suomeksi selvityksiä. Tuorein julkaisu on ladattavissa www.oskenet.fi kohdassa julkaisut / osaavien keskusten verkoston julkaisuja / Antero Ensio ja Pekka Ruotsalainen: Tietoturvallinen kommunikaatioalusta: Suositus kansallisesti noudatettaviksi standardeiksi. Osaavien keskusten verkoston julkaisuja 7/2004. Myös www.hl7.fi sivulla on linkkilista muun muassa standardeihin. 1.4 Miten toimin, jos tarvittavaa sosiaali- ja terveydenhuollon tietotekniikan standardia ole olemassa? Vähimmällä omalla työpanoksella pääsee, jos saa jonkun kansallisen tahon ymmärtämään standardin tarpeen ja on valmis rahoittamaan sen tekemistä. Myös itse voi tehdä vaikka yksinään standardin noudattaen niiden tekemisessä vallitsevia toteutustapoja ja hyväksyttämällä sen esimerkiksi HL7 Finland ry:ssä. Mikäli standardi ei täytä yleisiä periaatteita ja tarpeita, niin sen hyväksyttäminen saattaa olla vaikeaa, minkä takia usein kannattaa jo tekovaiheessa hakea hankkeella laajempaa hyväksyntää esitetylle ratkaisulle. 1.5 Miten voin varmistua, että oma tai toisen osapuolen tuote ja rajapinnat ovat standardien mukaisia? Rajapintojen toimivuudesta voidaan lopullisesti varmista vain kokeilemalla niitä erilaisissa yhteyksissä. Asiakkaalle usein riittää rajapinnan toimiminen johtavien tuotteiden kanssa ja voidaan olettaa niiden toimiminen myös muiden tuotteiden kanssa. Parhaillaan ollaan suunnittelemassa rajapintojen toimivuuden testaamista ja sertifiointia. Lisäksi aina on varmistuttava standardin määritysdokumentin versiosta, eli että varmasti käyttää tuoreinta versiota.
2 HL7 CDA R1 määritykset 2.1 Voiko R1 käyttää R2 valmistumisen jälkeen? Nykyiset viiteperusteiset aluetietojärjestelmät käyttävät R1 muotoa ja voidaan varsin helposti päivittää käyttämään sekä R1 että R2-muotoa. Mikäli tiedot välitetään vain näyttämistä varten, niin päivitystä R2-muotoon ei tarvitse tehdä. Vuonna 2005 valmistuvat adapterit tulevat tukemaan R2-muotoa sekä mahdollisesti lisäksi R1-muotoa. 2.2 Tyhjän tietoelementin siirto? Tyhjä elementti voi puuttua kokonaan tai sen arvo voi olla tyhjä. Pakolliseksi määritelty elementti voi joissakin tapauksissa olla tyhjä, mutta se ei saa puuttua. Asia ratkeaa sen perusteella, mitä schema määrää. 2.3 Voinko tehdä oman tyylitiedoston? Oma tyylitieto on mahdollista aina tehdä, mutta silloin pitää huolehtia, että kaikista lähteistä tulevat tiedot pystytään näyttämään kaikilla tuetuilla selaimilla. 2.4 Mitä merkkejä saa tekstissä käyttää? Tässä vaiheessa tiedot siirretään vain näyttämistä varten, joten kaikki Latin-1 merkit on käytettävissä. R1 ei tue lihavointia, kursivoitua, alleviivausta tai voisiko tässä sanoa: ylä- ja alaindeksejä kuten R2. Olisiko hyvä tässä pohtia kysymystä merkistöstä: Käytetäänkö Latin-1 vai Unicode-merkistöjä? Ja todeta, että kysymys on varsin oleellinen, kun pohditaan arkistoitavan sisällön merkistöä. Perusjärjestelmissä on myös huolehdittava, että tiedot voidaan välittää toisiin järjestelmiin sekä säilyttää joko sähköisenä, paperilla tai mikrofilmillä. Värien säilytys paperilla tai mikrofilmillä on mahdotonta. Myöskään mitään efektejä (esim. vilkkuminen) ei voi käyttää. R2 määritysten yhteydessä joudutaan tarkentamaan käytetty merkistö ja sallitut merkit ja tehosteet, joten tuotteissa kannattaa toimia varovaisesti. Liittyykö tämä huomautus merkistöön, vai olisiko tässä hyvä tehdä uusi kysymys, esimerkiksi miten merkkien ulkoasuun voi vaikuttaa? Ala- ja yläindeksit CDA R1 dokumenteissa Joissakin perusjärjestelmissä on mahdollista sijoittaa tekstiaineiston joukkoon ala- ja yläindeksejä. Tarve on saada ne näkyviin myös CDA R1 dokumentissa. Ratkaisumalli Ratkaisu lähtee siitä, että CDA R1 tekstissä olevat ala- ja yläindeksit on merkattava siten, että XSLT-tyylitiedoston tekemä muunnos osaa tunnistaa ne ja sijoittaa ne tuottamassaan HTML-dokumentissa vastaavien tagien sisään. HTML-kielessä käytetään ala- ja yläindeksien osoittamiseen tageja <sub> ja <sup>. CDA R1 standardissa on käytettävissä local_markup - rakenne, jolla voidaan mm. ilmaista muotoilussa huomioonotettavia asioita.
Ala- ja yläindeksien käyttämisen ratkaisumalli perustuu loca._markup - rakenteen käyttöön. Local_markup -rakenne ala- ja yläindeksien ilmaisemiseen Ala- ja yläindeksejä voidaan sijoittaa sellaisiin CDA R1 dokumentin sisältöelementteihin, joissa voi olla <local_markup> -elementti. Näitä ovat <content> ja <td> -elementit. Local_markup -elementin descriptor-attribuutilla ilmaistaan ala- ja yläindeksit seuraavasti: Alaindeksi: <local_markup descriptor="sub">tähän alaindeksin arvo</local_markup> Yläindeksi: <local_markup descriptor="sup">tähänyläindeksin arvo</local_markup> Tyylitiedosto 0.91 HL7 tyylitiedosto versiosta 0.91 eteenpäin tunnistaa kyseisest local_markup rakenteet ja tuottaa HTLM-koodiin vastaavat sisällöt seuraavasti: Alaindeksi: <sub>alaindeksin arvo</sub> Yläindeksi <sup>yläindeksin arvo</sup> Esimerkki: Taulukon elementissä oleva alaindeksimääritys <td>h<local_markup descriptor="sub">2</local_markup>o</td> tulee näkyviin seuraavasti: H2O Erikoismerkit R1 dokumenteissa Joissakin perusjärjestelmissä on mahdollista sijoittaa tekstin joukkoon erikoismerkkejä. Tarve on saada ne näkyviin myös CDA R1 dokumentissa. Ratkaisumalli Ratkaisu lähtee siitä, että CDA R1 tekstissä olevat erikoimerkit voidaan sijoittaa XML-sisältöön käyttäen merkkiä vastaavaa Unicode-koodiston numeerista arvoa. Tyylitiedoston tekemässä muunnoksessa kyseinen arvo siirtyy suoraan HTML-dokumenttiin, josta selain näyttää sen katsojalle haluttuna merkkinä. Esimerkki: Kreikkalaisen aakkoston kirjain alfa esitetään CDA R1 dokumentissa seuraavasti: <td>α </td> jolloin se tulee selaimella katsottaessa näkyviin seuraavasti: α
3 HL7 CDA R2 määritykset 3.1 Mikä on R2 valmistumisen aikataulu? HL7 CDA R2 paikallistamismääritykset valmistuvat 15.1.2005 mennessä, jolloin niin on huomioitu joulukuun 2004 HL7 CDA R2 äänestyspaketin sisältö. 4 HL7 CDA sanomat (SOAP) 4.1 Miten validoidaan SOAP-kehyksessä oleva CDA dokumentti? SOAP-kehys voi sisältää mitä tahansa sisältöä. Siksi SOAP-kehyksen ja sen sisällön validointi SOAP-kehyksen schemalla koskee vain kehyksen validisuutta. Sisällön validointi tapahtuu purkamalla kehys pois ja sen jälkeen validoimalla sisältö sitä vastaavalla schemalla. 5 HL7 V2 sanomat 5.1 Milloin HL7 V2 sanomien käyttö on kielletty? HL7 V2 on Suomessa laajasti käytössä. HL7 CDA R2 on määritelty vain osa nykyisin käytössä olevista sanomista. Jatkossa V3 tulee korvaan osan sanomia tulevaisuudessa. Esimerkiksi laboratoriotutkimusten tilausten siirtoon on edelleen käytössä vain V2 sanomat. Nykyisiä toimivia V2 siirtoja ei kannata korvata uusilla ratkaisuilla, niin niiden uusiminen tulee tapahtumaan järjestelmien uusimisen myötä. 6 HL7 V3 sanomat 6.1 Voiko HL7 V3 sanomia ottaa välittömästi käyttöön? HL7 CDA R2 7 Oid-tunnus 7.1 Mistä saa tietoa OID-tunnuksesta? - Stakesin ohje www.terveyshanke.fi Tutustu tarkemmin tästä >> Sähköiset potilasasiakirjat Toimipaikkarekisteri versio 10 2004-11-22 final.doc - www.hl7.org sivuilta kohdassa OID - Ans1 FAQ OID-tunnuksesta http://asn1.elibel.tm.fr/oid/faq.htm 7.2 Kuka antaa Suomessa OID tunnuksen? - Tieke ry antaa OID-tunnuksen - Stakesilla on sosiaali- ja terveydenhuollon juuri (1.2.246.537) ja sen alle tulevat terveydenhuollon organisaatiot (julkiset ja yksityiset)
- HL7 Finland ry:llä on myös oma juuri (1.2.246.777) ja sen alle voivat liittyä HL7 yhdistyksen jäsenet. HL7 Finland ry:n dokumentit on merkitty tämän juuren alle kuten tämäkin asiakirja (OID-tunnus on 1.2.246.777.11.2005.9). - jokainen voi hankkia oman juuren, mutta HL7 CDA ja Dicom standardissa terveydenhuoltopalveluntuottajien on käytettävä Stakesin juuren alaista tunnusta 7.3 Missä terveydenhuollossa tullaan käyttämään OID-tunnusta? - Dicom - HL7/CDA R1 ja R2 7.4 Onko OID-tunnus käytössä terveydenhuollon lisäksi muilla toimialoilla? On käytössä esimerkiksi: - pankit - varmenteet 7.5 Minkä muotoinen on OID-tunnus OID-tunnus on positiivisten kokonaislukujen (nolla mukaan lukien ilman etunollia) muodostama tiivis (ilman välilyöntejä) merkkijono, jossa luvut on erotettu toisistaan pisteellä. esim. 0.1.23.12345678912234445.0.33. 8 Sovellutusrajapinnat API (kontekstinhallinta ja ydinpalvelut) 8.1 Miten kontekstitietojen (itemien) arvoihin sisältyvä tolppa-merkki ( ) koodataan? Alustava periaatepäätös: Käytetään CCOW-standardin ja HL7:n merkintätapaa. Tolppamerkin koodaus jää asiakas-sovellusten vastuulle. Näin asiakassovelluksen on koodattava kontekstitiedon arvoissa oleva tolppamerkki escape-sekvenssillä \F\. Taustaa ratkaisulle: Koska GetItemValues- ja SetItemValues-metodit käyttävät tolppamerkkiä taulukon erottimena kuten CCOW-standardissa, on tolppa-merkin sisällyttäminen itse dataan (kontekstitiedon arvoihin) mahdotonta. Tolppa-merkki periytyy CCOW-standardiin HL7-standardista. Dataan sisältyvät erotin-merkit(separators) pitää korvata HL7- standardin mukaan ns. escape-sekvensseillä. Käytännössä pitäisi korvata \F\-merkinnällä. CCOWstandardissamainitaan muina erottimina myös & -ja ^ -merkit. Näiden escape-sekvensseinä ovat & - merkille \T\ ja ^ merkille \S\. CCOW-standardissa kontekstin tiedoilla lienee aina jokin HL7-tietotyyppi. Tällöin tietojen tulisi myös olla koodattuna HL7-tyyliin. HL7-escape-merkintöjen huomioiminen mutkistaa client-toteutuksia, mutta palvelintoteutusten kannalta ne ovat helppoja, koska palvelimen ei tarvitse
välittää niistä mitään. Palvelin voi säilöä tiedot kontekstiin raakamuodossa ja palauttaa ne samassa muodossa. Asiakas-sovellusten, jotka tarvitsevat vain henkilötunnusta ja käyttäjätunnusta ei tarvitse edelleenkään välittää asiasta. Eteneminen (tilanne 29.10.204): Tehdään merkkien koodauksesta alustava periaatepäätös, sillä uutta virallista kansallista HL7 Finland standardiversiota kontekstinhallinnan määrittelyyn ei ole vähään aikaan tulossa. Tulevaan kontekstinhallinnan määrittelyn versioon lisätään kohta escape-sekvensseistä. Lisäksi tarkastetaan, onko kontekstiin tallennettavien tietojen oltava HL7-muotoisia, joka edellyttäisi siten sen mukaista käsittelyä. 8.2 Minimikontekstinhallinnan ja CCOW-standardin yhteensopivuus? PlugIT-kontekstinhallinta ei ole CCOW-standardin kanssa yhteensopiva. Alla on listattuna erot CCOW-standardin ja PlugIT-kontekstinhallinnan välillä sekä pohdintaa sen seurauksista. Minimitoteutuksen erot CCOW-standardiin: Osallistuvien sovellusten ei tarvitse toteuttaa uusia rajapintoja (CCOW-standardin ContextParticipant), koska context manager ei koskaan kutsu sovelluksia. Context managerin tarvitsee toteuttaa vain kontekstinhallintaan liittymisessä tarvittavat join / leave ja kontekstin tietosisällön käsittelyssä tarvittavat get/set tyyppiset metodit rajapinnassaan. Kartoitusvaihetta (survey phase) ei tarvitse suorittaa, mikä yksinkertaistaa komponentin toteutusta huomattavasti. Sovellukset eivät päivitä tilaansa automaattisesti, vaan ainoastaan käyttäjän niin halutessa. Tämä voi olla jopa toivottu ominaisuus verrattuna CCOW-standardin automaattiseen päivitykseen. Toteutettavaksi jää minimaalinen määrä rajapintoja. Periaatteessa riittävät seuraavat CCOW-standardin rajapinnat (ja nämäkin karsittuina versioina): - ContextManager-rajapinta: kontekstinhallintaan liittyminen ja siitä eroaminen - ContextData-rajapinta: kontekstin tiedon käsittely. Palvelinpohjaiseen määritykseen lisätty metodi JoinCommonWithIp, jota ei löydy CCOW-standardista Turvallisuutta ei ole ratkaistu standardi-tavalla. Tilanteessa, jossa minimitason määritysten mukaisesti toteutettu asiakassovellus haluaisi käyttää CCOW-standardin mukaista koordinaattoria, ovat ongelmina:
Sovelluksesta puuttuu ContextParticipant-rajapinta. Näin koordinaattori ei voi ilmoittaa sovellukselle kontekstin muutoksista, eikä kartoittaa haluaako sovellus vaihtaa kontekstia vai ei. Sovellus ei voi hakea kontekstia, koska se ei ole em. kohdassa kuvatusta syystä ilmoittanut koordinaattorille olevansa halukas vaihtamaan kontekstia. Sovelluksella ei ole myöskään antaa koordinaattorin vaatimaa contextcoupon-tunnistetta, sillä tämä tunniste puuttuu kokonaan minimitason kontekstinhallintaratkaisun metodeista. Sovellus ei voi asettaa kontekstia, sillä CCOW-standardissa kontekstin saa asettaa vasta, kun on saanut koordinaattorilta uuden contextcoupon-tunnisteen ehdotettavalle uudelle kontekstille. Asettaminen vaatii myös kahden minimitason määrityksistä karsitun metodin käyttöä. Vastaavasti tilanteessa, jossa CCOW-yhteensopiva asiakassovellus haluaisi käyttää minimitason määritysten mukaista koordinaattoria ovat ongelmina: CCOW-yhteensopiva sovellus olettaa kartoitusvaihetta. CCOWstandardin mukainen sovellus ei hae kontekstista tietoja ennen kuin koordinaattori on ilmoittanut kontekstin vaihtuneen. Minimitason kontekstinhallintaratkaisussa koordinaattoriin ei ole toteutettu sovelluksen ContextParticipant-rajapinnan kutsumista ja näin se ei ilmoita kontekstin muutoksista. CCOW-standardin mukainen sovellus ei myöskään voi asettaa kontekstia. Ennen kuin se voi asettaa kontekstin, on sen kutsuttava minimitason määrityksistä puuttuvaa metodia (StartContextChanges). Lisäksi sovelluksen on lopetettava kontekstin asetus metodiin (EndContextChanges), jota ei ole toteutettu minimitason määritysten mukaiseen koordinaattoriin. Kontekstimuutosten toteuttamiseksi minimitoteutuksessa context managerin tarvitsee siis toteuttaa vain kontekstinhallintaan liittymisessä ja siitä eroamisessa, sekä kontekstin tietosisällön käsittelyssä tarvittavat metodit. Tiedon käsittely tapahtuu yksinkertaisilla get/set metodeilla. Context manager ei kutsu osallistuvia sovelluksia (ei CCOW-standardin ilmoituksia kontekstin muutoksista tai kartoituksen tuloksista). 8.3 Miksi CCOW-standardia ei hyödynnetty suoraan? Käytännössä CCOW-standardin mukainen toteutus oli PlugIThankkeen osapuolten mielestä liian raskas tapa toteuttaa työpöytäintegraatiota, (esim. kukaan hankkeen osapuolista ei halunnut toteuttaa CCOW-standardin mukaista context manageria.)
CCOW-standardin mukaisia valmiita tuotteita (context managereita) oli markkinoilla vain muutamia ulkomaisia. Näin epävarmuustekijöiksi nousivat kontekstinhallintaympäristön hinnoittelu sekä mahdollinen riippuvaisuus ulkomaisesta toimittajasta. Pohjois-Savon shp teki yhdelle context managertoimittajalle tarjouspyynnön, mutta se ei johtanut toimittajan puolelta aluksi edes yhteydenottoon. Tarjousta ei ole tullut missään vaiheessa, ainakaan tähän päivään mennessä. PlugIT -hankkeen aikana selvisi, että hankkeen eri osapuolien mielestä kontekstin välittäminen järjestelmien kesken ei välttämättä saanut olla automaattista (kuten CCOWstandardissa), vaan sen haluttiin tapahtuvan käyttäjän toimesta/aloitteesta. Kontekstinhallinnan tarpeet Suomessa olivat näin vain tietojen vienti kontekstivarastoon ja niiden haku sieltä, eikä kontekstin vaihtumiseen haluttu automatiikkaa. Keskeisin kontekstinhallinnan toiminnallisuus oli näin saavutettavissa kevyemmälläkin ratkaisulla kuin CCOW-standardin mukainen tapa. Kevyemmän ratkaisun ansiosta context managerin toteuttaminen on varsin yksinkertaista (matala toteuttamiskynnys, joka oli määrittelyjen tavoitteena). Myös muutokset sovelluksiin, jotka haluavat liittyä kontekstinhallintaan ovat pieniä. Negatiivisena puolena on tietysti tuo yhteensopimattomuus suoraan CCOW-standardiin. 8.4 Miksei minimikontekstinhallinnan määrittely tue web service-tyyppistä kutsumekanismia ja XML-viestiformaattia? Kontekstinhallinnan määrittelyä työstettiin PlugIT-hankkeessa yhdessä hankkeen eri osapuolten kanssa. XML:n käyttöä ehdotettiin osapuolille mutta he katsoivat XML:n käytön tarpeettomaksi kontekstinhallintaratkaisuun. Perusteluina "perus" http-viestien käyttämiseen olivat mm. toteuttamisen yksinkertaisuus (niin sovellukseen kuin palvelutoteutukseen) sekä soveltuvuus myös vanhempaan tekniikkaan perustuviin tuotteisiin. Määrittelyjä ohjasi osittain myös osapuolten tarve ja tarvetta web service-ratkaisulle ei ainakaan tuolloin ollut. Web services-tekniikkaa ei olla ottamassa tulevaisuudessa mukaan kontekstinhallinnan määrittelyihin ellei sille ole tarvetta. Web services-ratkaisuja tutkitaan jatkossa SerAPI-hankkeessa, joka jatkaa myös PlugIT-hankkeessa aloitettua työtä.
9 Dokumenttiarkisto 9.1 Missä dokumentit sijaitsevat ja miten ne voi ladata? Dokumentit sijaitsevat HL7 Filnand ry:n kotisivuilla www.hl7.fi, josta ne ovat ladattavissa seuraavista osoitteista: HL7 CDA paikallistamisprojekti: Soveltamisopas Implementointiopas v.1.00 (1.10.2002) http://proxnet.vtt.fi/hl7/jasenet/doc/cda_010.zip Avoimet Rajapinnat-hanke: Määrittelydokumentit Avoin Rajapinta v. 1.1.2 (2.3.2003) http://proxnet.vtt.fi/hl7/jasenet/doc/cda-adapteri-v1.12.zip http://proxnet.vtt.fi/hl7/jasenet/doc/0301koodistot.doc Open CDA-hanke: Määrittelydokumentit Open CDA määrittelydokumentti v. 1.0 (2.2.2004) http://www.vtt.fi/virtual/hl7/opencda.zip Viiteaihion päivitys v.1.1.4 (10.3.2004) SOAP-kehyssuositus Lähete ja hoitopalaute v.1.1 (23.4.2004) http://proxnet.vtt.fi/hl7/jasenet/tc/0405uudetskeemat.zip 9.2 Ovatko dokumentit maksullisia? Vanhemmat dokumentit sijaitsevat tällä hetkellä HL7 Filnand ry:n jäsenistön sivuilla ja niiden käyttö edellyttää jäsenen organisaatiokohtaista käyttäjätunnusta ja salasanaa. Uudemmat dokumenttien rahoittamiseen on osallistunut kansallinen terveyshanke ja nämä dokumentit ovat vapaasti kaikkien käytettävissä. 9.3 Mistä löydän dokumentin tuoreimman version? Viimeisin, voimassaoleva versio löytyy projektikohtaisista määrityksistä. Projekteissa on voitu tarkentaa tai päivittää jo aikaisemmin määriteltyjä osia. Tällöin tuorein versio löytyy ao. projektin aineistosta. Jatkossa on tarkoitus, että viimeisin versio löytyy yhdestä paikasta, jonne projektit tuottavat lopputuloksensa ja niiden päivitykset.