JHS 159 ISO OID-yksilöintitunnuksen soveltaminen julkishallinnossa, Liite 3 Muutokset edelliseen suosituksen versioon

  • Versio: 1.0
  • Julkaistu: 17.6.2010
  • Voimassaoloaika: toistaiseksi

1 Taustaa

1.1 ISO OID-tunnusjärjestelmän ohjeistus Suomessa

ISO OID-yksilöintijärjestelmän käyttöä lähdettiin Suomessa soveltamaan laajemmin terveydenhuollon piirissä HL7 CDA-standardin käyttöönoton myötä. Stakesin ja HL7 Finland-yhdistyksen toimesta laadittiin ohjeistus OID-yksilöintijärjestelmän käytöstä. Ensimmäinen versio tuotettiin jo vuonna 2004 ja sitä on sen jälkeen täydennetty. Ohjeesta vastaa nykyään THL ja sitä sovelletaan terveydenhuollon ja sosiaalitoimen tietojärjestelmissä. Erityisesti Kelan toimesta toteutettavat kansalliset eResepti- ja eArkisto-järjestelmät perustuvat OID-tunnusten käyttöön kyseisen ohjeen mukaisesti.

Terveydenhuollon ja sosiaalitoimen toimialoille laadittua ohjetta mukaillen laadittiin v. 2006 myös JHS suositus (JHS 159) ISO OID-yksilöintitunnuksen soveltamisesta julkishallinnossa.

Suomen juuren hallinnointi ja sen alle tulevien alipuiden numerointi oli aluksi 2000 luvun alusta Tieken vastuulla. Hallinnointivastuu siirtyi vuonna 2008 SFS:lle, jonka toimesta laadittiin keväällä 2009 SFS-standardi ISO OID-tunnuksen käytöstä Suomessa, SFS 5971 ISO OID-yksilöintitunnukset.

JHS suositukset ovat määräaikaisia, joten vuonna 2009 tuli ajankohtaiseksi suosituksen päivittäminen. Päivitystä varten muodostettiin työryhmä syksyllä 2009. Jäljempänä luetellaan joitakin päivitystyön tuloksena syntyneitä eroavuuksia edelliseen JHS-suositukseen nähden.

1.2 HL7-standardi ja OID-tunnusten käyttö

HL7-tietorakenteissa (data types) on erityisesti kaksi tietotyyppiä, joissa käytetään OID-tunnusta:

  • Tietotyyppi II (Instance Identifier), joka yksilöi esim. henkilön, asiakirjan, organisaation jne. II-tyyppinen tieto muodostuu kahdesta tietoalkiosta, root ja extension . Root sisältää käytettävän nimiavaruuden yksilöivän OID-tunnuksen ja extension sisältää kohteen yksilöintitunnuksen kyseisessä nimiavaruudessa.
  • Tietotyyppi CV (Code Value) johonkin koodistoon kuuluvan koodiarvon esittämistä varten. Tietorakenteeseen sisältyvät itse koodiarvo, mahdollisesti sen selväkielinen vastine sekä kyseisen koodiston yksilöivä tunnus OID-muodossa.

Hyvä johdanto HL7-standardiin löytyy mm. Tim Bensonin tulevan kirjan artikkelista

Principles of Health Interoperability HL7 and SNOMED: 1

Codes and Identifiers

Instance Identifier (II)

The II (Instance Identifier) data type has two main flavours: UUIDs and OID based identifier. Universally Unique Identifiers (UUID) are software generated identifiers, created on the fly to identify information artefacts uniquely. UUIDs are 16 byte (128 bit) numbers. The number of theoretically possible is large (more than 10 followed by 37 zeroes).

The standard way of displaying a UUID is as 32 hexadecimal digits, displayed in 5 groups separated by hyphens in the form 8 - 4 - 4 - 4 - 12, such as:

550e8400-e29b-41d4-a716-446655440000

UUIDs are usually used when the identifier in question is generated by a software application without human assistance.

The second type of identifier is that held in some type of register. Here we use an identifier for the register itself and each item, which is registered is allocated an identifier that is unique within that register. The convention in HL7 is to use an OID (object identifier) to identify the register itself. An OID is a node in a hierarchical tree structure, with the leftmost number representing the root and the rightmost number representing a leaf. Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its uspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the root OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its subtree. While most owners of an OID will "design" their namespace subtree in some meaningful way, there is no generally applicable way to infer any meaning on the parts of an OID. HL7 has its own OID 2.16.840.1.113883 (iso.country.us.organization.hl7) and maintains an OID registry with around 3,000 nodes.

The combination of an OID and a value is intended to be globally unique.

One way to obtain an OID in the UK is to use the company registration number. All companies registered in England and Wales may append their company registration number to the 1.2.826.0 root to obtain an OID that is unique to the company without further formality or charge. The hierarchy is:

  • Top of OID tree
  • 1 ISO assigned OIDs
  • 1.2 ISO member body
  • 1.2.826 Great Britain (GB/UK)
  • 1.2.826.0 UKNational registration.

For example, 1.2.826.0.1.4224538 means Abies Ltd.

Coded Value (CV)

CV includes a code value, an optional display name, a coding system identifier, enabling externally defined coding schemes to be used, and original text used.

2 Muutokset edelliseen versioon

2.1 Poistetut ohjeet

2.1.1 Semantiikka OID-tunnuksessa

Eri yhteyksissä on tullut esille ajatus, että jollekin kohteelle annetusta ISO OID-tunnuksesta olisi hyvä voida päätellä jotakin, esimerkiksi kuka on tunnuksesta vastaava taho tai mitä tyyppiä yksilöity kohde on. Myös on pohdittu, tulisiko OID-tunnusta voida parsia ohjelmallisesti tai tulisiko sitä katsomalla voida päätellä jotain, joko tunnusten muodostamisvaiheessa tai tunnuksia käytettäessä eri yhteyksissä.

Informaatioarkkitehtien keskuudessa nykyään vallitseva käytäntö on, että yksilöintitunnuksissa vältetään semantiikkaa missään muodossa. Tällä varmistetaan yksilöintitunnuksen käyttökelpoisuus, vaikka yksilöidyn kohteen ominaisuuksissa tapahtuisikin muutoksia.

Semantiikan välttäminen OID-tunnuksessa on myös yksi JHS-suositukseen tehdyistä täsmennyksistä. Tämä ilmenee mm. solmuluokan pois jättämisestä OID-puusta.

2.1.2 Solmuluokat

Aikaisemmassa suosituksessa on ohjeistettu yksilöitävien kohteiden luokittelua otettavaksi OID-puun solmuun, ns. solmuluokkana. Solmuluokka on kuitenkin luokitteleva tieto, joka on nimiavaruuden attribuutti ja jonka paikka on OID-tunnusten hallinnoinnissa käytettävässä tukirekisterissä. Solmuluokka on myös semanttista tietoa, jota OID-tunnuksessa ei tule olla. Näistä syistä solmuluokkaa ei enää ole mukana OID-puussa. Mikäli OID-tunnuksilla yksilöitäviä kohteita on tarve luokitella, on mahdollista perustaa solmuluokkakoodisto, jota ylläpidettäisiin kansallisesti. Koodiston perustamiseen ja ylläpitoon liittyvät kysymykset eivät kuitenkaan kuuluneet tämän JHS-suosituksen päivityksen toimeksiantoon.

2.2 Muutokset

2.2.1 Toimipaikat

Aikaisemmassa suosituksessa on ohjeena toimipaikkojen yksilöintitunnusten sijoittaminen suoraan organisaation Y-tunnuksen alle. Siihen sisältyy epäsuorasti vaatimus organisaation toimipaikkojen yksilöinnin keskitetystä hallinnoinnista. Kuitenkin laajemmissa organisaatioissa on toimipaikkojen hallinnointivastuu tyypillisesti hajautettu, esimerkiksi kunnissa eri hallintokunnille tai monialaisissa yrityksissä eri tulosyksiköille. Toisaalta myös tilastokeskuksen ja verohallinnon nykyiset käytännöt lähtevät toimipaikkojen toimialakohtaisuudesta. Näistä syistä on tässä JHS-suosituksessa luovuttu vaatimuksesta organisaation toimipaikkojen yksilöinnin keskitetystä hallinnoinnista. Hallinnointimallin valinta on siis organisaation itsensä päätettävissä.

2.3 Lisäykset

2.3.1 Nimiavaruus ja hallinnointivastuu

Yksilöintitunnusten ja nimiavaruuksien teoreettista taustaa on selvennetty. On täsmennetty ajatusta, että OID-puun solmut yksilöivät nimiavaruuksia ja niiden hallinnoinnista vastaavia tahoja. Todetaan, että nimiavaruuden yksilöimien kohteiden numerointi on nimiavaruudesta vastaavan tahon valittavissa. Esimerkiksi kunta, joka hallinnoi oman y-tunnuksensa alla olevaa nimiavaruutta, voi päättää mitkä kohteet yksilöidään keskitetysti kunnan tasolla ja minkä kohteiden hallinnointivastuu voidaan jakaa esimerkiksi hallintokunnille.

3 Yhteensopivuus aikaisempaan suositukseen

Suosituksen uusi versio on laadittu siten, että mahdollistaa aikaisemman version mukaisen tai toimialakohtaisten ohjeiden, kuten THL:n ohjeen mukaisen menettelyn.

Alaviitteet

1) Tim Benson, 2009 (Chapter 7 page 20): http://www.springer.com/978‐1‐84882‐802‐5