Helsetjenesteenhetsregister (HER)

Transkript

1 Helsetjenesteenhetsregister (HER) Oppbygging og vedlikehold Versjon mars 2003 KITH Rapport R10/03 ISBN

2 KITH-rapport Tittel Helsetjenesteenhetsregister (HER) Oppbygging og vedlikehold Versjon 1.0 Forfatter(e) Edgar Glück Oppdragsgiver(e) Sosial- og helsedirektoratet Rapportnummer R 10/03 ISBN Godkjent av URL HER v1.0.pdf Dato Antall sider Kvalitetssikret av Hans Jørgen Varfjell Kompetansesenter for IT i helsevesenet AS Postadresse Sukkerhuset 7489 Trondheim Besøksadresse Sverresgt 15, inng G Telefon Telefaks e-post firmapost@kith.no Foretaksnummer Prosjektkode Gradering Åpen Jacob Hygen Adm. direktør Sammendrag Rapporten er utarbeidet på oppdrag fra Sosial- og helsedirektoratet og beskriver oppbygging av et nytt og landsdekkende helsetjenesteenhetsregister (HER) over alle parter som kommuniserer elektronisk i helsesektoren. Rapporten foreslår løsninger for oppbygging av et slikt register og hvordan dette kan gjøres tilgjengelig ved publisering som en katalogtjeneste i helsenettet.

3 HELSETJENESTEENHETSREGISTER (HER) Forord Dette dokumentet er utarbeidet etter oppdrag fra Sosial- og helsedirektoratet. Denne rapporten beskriver hvordan et register for kommuniserende parter i helsesektoren (helsetjenesteenheter) kan oppbygges og vedlikeholdes. Et slikt register er en viktig forutsetning for elektronisk kommunikasjon mellom ulike parter i helsesektoren. Arbeidet er utført i en prosjektgruppe under ledelse av Hans Jørgen Varfjell og med representanter for KITH og MaXware. Versjon ii

4 HELSETJENESTEENHETSREGISTER (HER) Innhold 1 INNLEDNING Bakgrunn Formål med registeret Avgrensning Bruksområder for dokumentet Om dette dokumentet 2 2 OPPBYGGING AV REGISTERET Målsetting Avgrensning Løsningsprinsipp Løsningsforslag OID for organisasjoner (HER-id) OID for organisatorisk underenhet (HER-subid) Informasjonsinnhold Opplysninger om kommunikasjonsparten Opplysninger om relasjoner mellom parter Registeradministrative opplysninger INITIAL GENERERING AV REGISTERET Tilnærming Metode Kun eksisterende brukere Alle registrerte aktører Datakilder Personer Organisasjoner Underavdelinger av organisasjoner KATALOGTJENESTE Teknisk løsning Katalogstruktur og innhold Tilgang Bruk av katalogtjenesten LDAP søkemuligheter Anvendelsesmåter VEDLIKEHOLD AV REGISTERET Registeransvarlig organisasjon Informasjonsutveksling Sentral innrapportering Publisering av kataloginformasjon Spredning av kataloginformasjon...19 Versjon iii

5 INNLEDNING 5.3 Løpende oppgaver Tilgang av aktører Endring av registrerte opplysninger Sletting av aktører...20 VEDLEGG A OM BRUK AV UML I FIGURER 21 VEDLEGG B OBJECT IDENTIFIER (OID) 25 VEDLEGG C REGISTERINNHOLD 29 Versjon iv

6 HELSETJENESTEENHETSREGISTER (HER) 1 Innledning Dette kapitlet gir en kort beskrivelse bakgrunnen for arbeidet, formålet med registeret, bruksområder for dette dokumentet samt en kort oversikt over innholdet i dokumentet. 1.1 Bakgrunn Entydig identifisering av "rekvirenter" og andre kommunikasjonsparter i helsesektoren har vært etterlyst i mange år. De mange henvendelsene KITH stadig får fra aktørene i helsevesenet rundt problemer forbundet med manglende identifisering av "rekvirenter" spesielt og helsetjenesteenheter generelt, forsterker behovet for en snarlig løsning på dette området. SHD har i sin IT-Tiltaksplan 1 satt opp som mål å "Utvikle og sikre storskala innføring og bruk av et sett av prioriterte elektroniske meldinger" (tiltak nr. 6). Mens meldingsstandardene (Meldingsbatteriet) utvikles og etableres i regi av Standardiserings- og samordningsprogrammet (SSP), mangler det fremdeles løsninger for entydig identifisering av helsetjenesteenheter som er involvert i elektronisk kommunikasjonen. Selv om lokale og bilateralt avtalte identifikatorer vil kunne fungere i pilotprosjekter av mindre skala, er et nasjonalt samordnet identifiseringssystem en nødvendig forutsetning for en storskala og mange-til-mange kommunikasjon. Det er likeledes viktig at slike identifikatorer gjøres lettvint tilgjengelig for brukerne. 1.2 Formål med registeret Formålet med registeret er å få til en entydig identifisering av helsetjenesteenheter i helsesektoren spesielt for bruk ved elektronisk kommunikasjon. Identifisering av kommunikasjonsparter innebærer (grovt sett): Identifisering av personer, og i denne sammenheng, helsepersonell som er involvert i kommunikasjonen. Alt offentlig godkjente helsepersonell kan nå entydig identifiseres ved hjelp av HPR-nummer registrert i Helsepersonellregisteret (HPR). HPR vil kunne omfatte de fleste og sannsynligvis alle aktuelle helsepersonellkategorier. Det nylig reetablerte HPR ved Helsetilsynet er allerede 1 Versjon

7 INNLEDNING satt i full drift. På websidene til Helsetilsynet 2 er det nå mulig å søke på HPRnummer ved å oppgi fødselsnummer. Andre opplysninger fra HPR er ikke tilgjengeliggjort via denne søkefunksjonen. Identifisering av helsepersonell i en gitt rolle, f.eks. en lege som bedriftslege hos bedrift A versus legen som helsestasjonslege. Identifisering av organisasjoner i helsevesenet som deltar i kommunikasjon. Her er det ofte behov for entydig identifisering av de ulike administrative deler av organisasjonen, for eksempel avdelinger og poster innenfor et sykehus. Mens de fleste organisasjoner kan identifiseres entydig ved bruk av organisasjonsnummeret (foretaksnummer) mangler et system for å kunne identifisere administrative underenheter som avdelinger og poster. Registeret skal understøtte elektronisk informasjonsutveksling, men legger ikke nødvendigvis føringer for hvordan en gitt part skal adresseres for et gitt formål. 1.3 Avgrensning Det vil være en rekke problemstillinger som direkte eller indirekte er knyttet til et register som det foreslåtte. Noen av disse problemstillingene er foreslått å bli løst lokalt i alle fall i første omgang. Slike problemstillinger er blant andre: Håndtering av lokale identifikasjonsnumre for helsetjenesteenheter Håndtering (adressering) av meldinger som er adressert til parter som er bortreist eller ikke på vakt, herunder også tilgang til meldingsinnhold for tredjepart Håndtering av ikke-elektroniske adresser for postal levering av meldinger Det poengteres også at formålet med registeret primært er å identifisere partene og derfor har et annet siktemål en klassifikasjonssystem som måtte forefinnes for å klassifisere egenskaper eller funksjoner ved sykehus, avdelinger osv. Det vil imidlertid være mulig å legge til slike opplysninger i HER om ønskelig. 1.4 Bruksområder for dokumentet Dokumentet er ment å spesifisere hvordan et slikt identifiseringssystem for parter i helsevesenet skal bygges opp spesielt med sikte på å identifisere parter som kommuniserer elektronisk. 1.5 Om dette dokumentet Dokumentet er videre organisert som følger: Kap. 2 inneholder en beskrivelse av hvordan registeret er oppbygget Kap. 3 beskriver hvordan registeret kan etableres Kap. 4 beskriver bruk av HER som en katalogtjeneste Kap. 5 inneholder retningslinjer for vedlikehold av registeret 2 Versjon

8 INNLEDNING Vedlegg A inneholder en forklaring til bruk av UML-modeller Vedlegg B beskriver bruken av Object identifiers (OID) Vedlegg C beskriver innholdet i registeret Versjon

9

10 HELSETJENESTEENHETSREGISTER (HER) 2 Oppbygging av registeret Dette kapitlet inneholder en beskrivelse av hvordan registeret er konstruert for å identifisere de ulike kommunikasjonspartene i helsesektoren. 2.1 Målsetting Formålet med registeret er å kunne identifisere kommuniserende parter i helsesektoren på en entydig måte. Dette innebærer at alle parter i helsesektoren må kunne identifiseres entydig i dette systemet. Slike parter kan være: Helsepersonell (leger, sykepleiere, veterinærer osv.) Organisasjoner (sykehus, apotek, sykehjem, legesentre, legevakt osv.) Offentlige myndigheter (RTV, offentlige registre, osv.) For organisasjoner må det også være mulig å avspeile den organisasjonsmessige strukturen slik at en kan identifisere organisatoriske underenheter på flere nivå, for eksempel avdelinger, poster og seksjoner på et sykehus. I tillegg til at den enkelte part kan identifiseres entydig må det også være mulig å identifisere den enkelte part dersom denne har flere arbeidssteder eller roller. 2.2 Avgrensning Parter i helsesektoren kommuniserer også elektronisk med parter utenfor helsesektoren i forbindelse med bestilling av varer og ikke medisinske tjenester, økonomiske transaksjoner osv. HER vil kunne benyttes også for slike formål dersom det anses formålstjenlig av den kommuniserende part utenfor helsesektoren. Dette bruksområdet er imidlertid ikke registerets primære oppgave. 2.3 Løsningsprinsipp Løsningsforslaget er basert på at hver enkelt organisasjon i helsevesenet identifiseres entydig ved bruk av et sentralt tildelt identifikasjonsnummer (HER-id). Disse identifikasjonsnumrene gjøres tilgjengelig for søkning og oppslag gjennom nettbaserte katalogtjenester. Organisasjonen er typisk sykehus og andre helseinstitusjoner, apotek, legesentre og offentlige helserelaterte myndigheter som f.eks. RTV. Men også et legekontor for en Versjon

11 OPPBYGGING AV REGISTERET enkelt lege og f.eks. et kommunelegekontor oppfattes som organisasjoner i denne sammenheng. De regionale helseforetakene gis anledning til selv å tildele identifikasjonsnumre (HER-subid) til underenheter av eksisterende organisasjoner i sin egen region som også gjøres tilgjengelig på nettet for allment bruk. Organisatoriske underenheter for en helseinstitusjon kan være en avdeling, seksjon eller post på et sykehus eller en person eller utstyrsenhet ved en avdeling osv. Tilsvarende kan en kommunelegevirksomhet ha et utekontor som organisatorisk underenhet eller en legepraksis kan ha underenheter for ulike virksomheter som bedriftslege for bedrift A, helsestasjonslege, legevaktslege osv. 2.4 Løsningsforslag Løsningsforslaget er basert på bruk av objektidentifikatorer (OID se Vedlegg B) i henhold til ISO En sentral tildelingsmyndighet 3 vil tildele alle større helseinstitusjoner en OID mens mindre institusjoner vil få tildelt sin OID etter hvert som de tar i bruk elektronisk kommunikasjon. En tildelt OID vil bestå og kun bli markert som ugyldig dersom kommunikasjonsparten ikke lengre eksisterer. En tildelt OID skal ikke senere tildeles en annen kommunikasjonspart. Videre gjøres helseforetakene til egne tildelingsmyndigheter som tildeler identifikatorer til egne organisatoriske underenheter (avdeling, post osv.), utstyrsenheter og personer ved helseinstitusjoner innenfor den aktuelle regionen. Den sentrale tildelingsmyndigheten vil verifisere at regionalt registrerte opplysninger er fullstendige og innbyrdes korrekte. Tildeling av OIDer for organisatoriske underenheter av andre organisasjoner gjøres sentralt. Dette omfatter blant annet ulike roller for helsepersonell utenfor sykehus. Det bør vurderes om apotekene skal tildeles en OID fra en annen tildelingsmyndighet som gjør det mulig å benytte den foreslåtte Apotek-ID som siste ledd i OID for landets apotek. Det er imidlertid ikke noe til hinder for at apotekene også tildeles en OID i likhet med andre institusjoner i helsevesenet OID for organisasjoner (HER-id) Denne OIDen vil måtte ha minst 5 siffer for å kunne håndtere mer enn og ventelig mindre enn organisasjoner. For å ta høyde for at utgåtte OIDer ikke kan gjenbrukes foreslås det at denne OIDen får maksimalt 6 siffer selv om det ikke er noe til hinder for å tildele lengre identifikatorer senere om det skulle bli nødvendig. OIDene tildeles fortløpende, men komplekse organisasjoner som sykehus tildeles en HER-id med få sifre mens vanlige legekontor og andre enklere organisasjoner tildeler HER-id er som er noe lengre. Dette gjøres for at det totale identifikasjonsbegrepet for en part i en kompleks organisasjon ikke blir vesentlig lengre enn for en part i en mindre kompleks organisasjon. 3 Inntil videre KITH Versjon

12 OPPBYGGING AV REGISTERET Den fulle identifikasjon av en OID for en organisasjon vil være dette nummeret konkatenert med OIDen for tildelende myndighet ( som svarer til joint-iso-itu.country.norway.organisasjoner.offentlig-forvaltning.sosial-oghelsesektoren.her-id) som gjør identifikatoren entydig på verdensbasis. Siden OIDen for tildelende myndighet er konstant vil det likevel ikke være nødvendig å gjenta denne delen hver gang en part skal identifiseres i en melding da denne kan defineres som en konstant. Det antas videre at en OID vanligvis ikke vil bli tastet inn manuelt, men bli funnet frem til ut fra andre identifikatorer (organisasjonsnummer, HPR-nummer osv.) og at det derfor ikke er behov for å ha kontrollsiffer som en del av OIDen. Det kan diskuteres om f.eks. kommuneleger skal ha en OID basert på OIDen for kommunen de tilhører. I praksis vil det ventelig være best at en i første omgang tildeler en OID sentralt for å sikre at alle kommunikasjonsparter raskt kan få en OID. Uansett vil en vanskelig komme bort fra at noen parter på sikt også vil få tildelt en annen OID fra en annen tildelingsmyndighet. Det vil være nødvendig med en viss praktisk utprøving for å finne frem til praktisk gode løsninger på slike spørsmål OID for organisatorisk underenhet (HER-subid) Organisatoriske underenheter av en organisasjon i helsevesenet eller ulike virksomheter for en organisasjon identifiseres ved en egen OID under OIDen for vedkommende organisasjon. Organisatoriske underenheter kan være en avdeling, post eller seksjon ved et sykehus, men også personer eller utstyrsenheter. Organisasjonen tildeler OIDer fortløpende uten å ta hensyn til om det gjelder en avdeling, en utstyrsenhet, et mottaende program eller en person. Det skal således ikke være noen ytterligere struktur i tildeling av OIDer. OIDer for organisatoriske underenheter foreslås som et nummerisk begrep med maksimum 6 sifre (med mulighet for senere utvidelse om nødvendig). 2.5 Informasjonsinnhold Registeret må typisk inneholde: opplysninger om den enkelte kommunikasjonspart opplysninger om relasjoner mellom parter registeradministrative opplysninger I tillegg vil registeret kunne utvides til å omfatte: sertifikater for så vel personer som kommunikasjonsparter opplysninger om kommunikasjonspartens oppkoplingsmuligheter og muligheter for elektronisk samhandling opplysninger om kommunikasjonstrafikk over tid Detaljert beskrivelse av et forslag til registerets logiske struktur og informasjonsinnhold finnes i Vedlegg C. Versjon

13 OPPBYGGING AV REGISTERET Opplysninger om kommunikasjonsparten Denne delen gir nødvendige opplysninger for å kunne identifisere kommunikasjonsparten og består av 3 hoveddeler: Opplysninger om parten (som kan være en person, en organisasjon, en utstyrsenhet eller et program), i informasjonsmodellen representert ved Agent Opplysninger om den rollen denne parten opptrer i (en part kan opptre i flere roller), i informasjonsmodellen representert ved ServiceProvider Opplysninger om en eventuell organisasjon som denne parten i den aktuelle rollen er knyttet til, i informasjonsmodellen representert ved Organization ServiceProvider 0..* 0..* 1 Agent 1 0..* Relation 0..1 Organization Person Software Device Forenklet informasjonsmodell for HER Opplysninger om parten Dette er opplysninger om parten (som kan være en person, en organisasjon, en utstyrsenhet eller et program) uavhengig av den rollen parten opptrer i. En part er i informasjonsmodellen representert som en Agent med spesialiseringene Organization, Person, Software og Device. Opplysningene gjelder for denne parten uavhengig av hvilken rolle denne parten opptrer i. Opplysningene vil variere noe avhengig av om det er en person, en organisasjon, en utstyrsenhet eller et program, men kan omfatte blant annet: Navn (på person, organisasjon eller program) Identifikasjonsnumre, f.eks. HPR-nummer for helsepersonell, organisasjonsnummer for organisasjoner Gyldig tidsrom Adresser for parten Telekommunikasjonsadresser Administrativ tilhørighet (kommune, bydel) Type (foretak, avdeling, post, person, utstyrsenhet, programvare osv.) Medisinsk spesialitet (for organisasjon eller person) Versjon

14 OPPBYGGING AV REGISTERET Profesjon for helsepersonell (lege, tannlege, sykepleier osv.) Egenskaper for parten (avhengig av type) Det kan diskuteres om det vil være nødvendig med postadresse, telefon osv. dersom registeret kun skal ivareta behovet for elektronisk kommunikasjon. En vil anta at registeret bør være i stand til å håndtere ulike typer adresser selv om en i første omgang velgere kun å befolke registeret med elektroniske adresser. Det kan ventelig bli aktuelt å utvide opplysninger om egenskapene for de ulike partene. Kommunikasjonspart (part i bestemt rolle) Opplysningene omfatter de opplysningene som er spesifikke for den aktuelle parten i en bestemt rolle. En kommunikasjonspart er i informasjonsmodellen representert av ServiceProvider. Opplysningene består av: Identifikator i HER (OID) omfatter både HER-id og HER-subid Alternative identifikatorer Navn Rolle eller posisjon (institusjon, legekontor, poliklinikk, laboratorium, alders- og sykehjem, bedriftshelsetjeneste osv.) Gyldig tidsrom Adresser Telekommunikasjonsadresser Relatert organisasjon For enkelte roller vil det være aktuelt å gi opplysninger om en relatert organisasjon. Dette vil være de samme opplysningene som gis for en organisasjon som en part. For en lege i rollen som bedriftslege for Bedrift A vil relatert organisasjon være Bedrift A Opplysninger om relasjoner mellom parter Registeret må også inneholde opplysninger om relasjoner mellom partene for å angi strukturen i den enkelte organisasjon. Dette er i informasjonsmodellen representert av Relation. Det vil være aktuelt å angi at en organisasjon består av organisasjonsmessige underenheter (som kan være en avdeling, seksjon eller post) eller at en person eller utstyrsenhet er knyttet til en organisasjon eller organisasjonsmessige underenhet. Det er også mulig å angi et tidsrom for gyldigheten av denne relasjonen. Versjon

15 OPPBYGGING AV REGISTERET Registeradministrative opplysninger Registeret må også ha en del registeradministrative opplysninger som: Dato for ajourføring Registrert/endret av Bakgrunn for endringen Versjon

16 HELSETJENESTEENHETSREGISTER (HER) 3 Initial generering av registeret Dette kapittelet beskriver hvordan registeret tenkes befolket med opplysninger om eksisterende kommunikasjonsparter på bakgrunn av opplysninger som alt foreligger. 3.1 Tilnærming Formålet med registeret er primært å understøtte elektronisk informasjonsutveksling. Det kan derfor være nærliggende i første omgang kun å innlemme parter som alt er involvert i elektronisk informasjonsutveksling. En slik tilnærming må avveies mot det å samle inn mer fullstendige opplysninger om alle potensielle aktører basert på opplysninger fra eksisterende registre. 3.2 Metode Metoden vil variere ut fra den tilnærming som er valgt. Det vil uansett metode være fordelaktig om en kunne ta utgangspunkt i eksisterende HPR-register (hovedsakelig HPR-nummer og personens navn og profesjon) samt landets helseinstitusjoner Kun eksisterende brukere Dersom en kun ønsker å registrere etablerte brukere i første omgang vil det være naturlig å ta utgangspunkt i de registre som eksisterer ved de ulike sykehus, laboratorier og kommunikasjonssentraler og laste opplysninger fra disse registrene inn i HER. I tillegg kan det på et senere tidspunkt bli nødvendig å kontakte partene direkte for å verifisere opplysningene og fremskaffe nødvendige tilleggsopplysninger. Et stort antall parter kan ventelig kontaktes via e-post mens de resterende må kontaktes pr. post eller telefon Alle registrerte aktører Dersom en velger å etablere et register over alle potensielle kommunikasjonsparter vil det være mulig å ta utgangspunkt i en rekke registre både sentralt og lokalt som har deler av de samme opplysningene. De ulike registrene har imidlertid ulik grad av ajourføring av sine opplysninger og det vil derfor være ønskelig å samkjøre flere kilder for å sikre et så fullstendig og ajourført datagrunnlag som mulig. Versjon

17 INITIAL GENERERING AV REGISTERET Det vil antakelig uansett bli nødvendig med en initial generering basert på det mest omfattende registeret og påfølgende ajourføring basert på delregistre med antatt høyere ajourføringsgrad. I tillegg vil det ventelig bli nødvendig å kontakte partene direkte for å verifisere opplysningene. Et stort antall parter kan ventelig kontaktes via e-post mens de resterende må kontaktes pr. post eller telefon. 3.3 Datakilder Det vil antakelig være hensiktsmessig å se personer og organisasjoner separat i første omgang Personer Aktuelle datakilder er: 1. Helsepersonellregisteret hos Helsetilsynet 2. Regionale/lokale registre ved regionsykehusene, private laboratorier og hos nettverksleverandører 3. Brevreklame 4. Fellesekspedisjonen for medisinsk informasjon Det forventes at Helsepersonellregisteret vil være tilstrekkelig for å få opplysninger om alle personers HPR-numre og navn. Dette vil derfor være den primære kilden for å befolke registeret dersom en ønsker et register som omfatter mer enn parter som alt kommuniserer elektronisk. Det forventes imidlertid at adresseopplysninger i Helsepersonellregisteret for en stor del vil være dårlig ajourført og at andre kilder må benyttes for å ajourføre post- og e- post-adresser. Det må undersøkes nærmere hvilke muligheter som her foreligger dersom en i det hele tatt skal ha ajourførte postadresser for kommunikasjonspartene. Det er mulig at en kan klare seg uten ajourførte postadresser i HER. Regionale/lokale registre ved regionsykehusene, private laboratorier og hos nettverksleverandører vil ventelig være den beste kilden for korrekte opplysninger om etablerte aktører for elektronisk informasjonsutveksling. Det må derfor etableres et nærmere samarbeide med disse for utveksling av opplysninger. Tildeling av identifikatorer for personer i ulike roller vil ventelig måtte gjøres sentralt og manuelt for denne gruppen Organisasjoner Foretaksregisteret i Brønnøysund er ventelig den eneste kilden for initial befolkning av registeret over organisasjoner. Om mulig vil det være hensiktsmessig å få overført foretaksnummeret for alle organisasjoner som er relatert til helsevesenet dersom en ønsker et register som omfatter mer enn parter som alt kommuniserer elektronisk.. Deretter må registeret følges opp manuelt for å ivareta organisasjoner som ikke finnes i Foretaksregisteret. Versjon

18 INITIAL GENERERING AV REGISTERET Dersom en kun ønsker å befolke registeret med parter som alt kommuniserer elektronisk fåes også dette best fra eksisterende registre hos regionsykehus og laboratorier Underavdelinger av organisasjoner Som beskrevet ovenfor vil de regionale helseforetakene kunne tildele identifikatorer til sin organisatoriske strukturer (avdelinger, poster osv.), personell, utstyrsenheter og programvare for institusjoner i sin egen region. Hver region tildeler disse fortløpende en OID som en utvidelse av institusjonens egen OID. Versjon

19

20 HELSETJENESTEENHETSREGISTER (HER) 4 Katalogtjeneste Dette kapittelet beskriver hvordan sentrale registeropplysninger gjøres tilgjengelig i form av en nettbasert katalogtjeneste. Beskrivelse er utformet i samarbeid med MaXware. 4.1 Teknisk løsning Den foreslåtte løsningen er basert på at utvalgte deler av den sentrale HER-databasen mappes over til en katalogserver for eksempel ved bruk av en replikeringsmotor, MaxWare Data Synchronization Engine (DSE) eller tilsvarende produkter. Dette programmet tilbyr en måte å speile data fra en database til en katalogserver via LDAP-protokollen. Klientene som har behov for HER-info aksesserer denne på katalogtjeneren via LDAP-protokollen mot katalogtjenerens LDAP aksesspunkt. Klient Klient Klient Klient Klient LDAP access point Katalog tjener HER-katalog Replikeringsmotor SQLserver HER-dB Det vil også være mulig å tilby et web-basert grensesnitt samt gjøre informasjonen tilgjengelig fra en vanlig nettleser for eksempel ved bruk av MaXware Directory Browser som er en fritt tilgjengelig utvidelser av en vanlig nettleser eller andre tilsvarende produkter. Versjon

21 KATALOGTJENESTE Katalogtjenesten kan være sentralisert i form av ett LDAP-aksesspunkt som betjener alle, eller desentraliseres til et antall LDAP-aksesspunkter som hver har en kopi av den sentrale katalogen. Det er foreslått at en skal basere seg på en desentralisert løsning hvor katalogen er duplisert ved hvert av landets regionssykehus. De lokale katalogserverne synkroniseres periodisk med den sentrale katalogserveren slik at de lokale katalogserverne ajourføres med endringer som er gjort sentralt. Slik synkronisering foretas i pilotprosjektet ved bruk av MaXware s Data Synchronization Engine (DSE). Opplysninger som er registrert regionalt (nyregistreringer og endringer) vil måtte innrapporteres til den sentrale HER-databasen. Sentral HER tjeneste LDAP access point DSE Duplikat av HER tjeneste Publiseringskatalog DSE Duplikat av HER tjeneste SQL server DSE DSE Enhet Enhet Database Database De lokale katalogserverne kan ha en databasestruktur som kan være identisk til den sentrale HER-databasen eller den kan ha en annen oppbygging. 4.2 Katalogstruktur og innhold HER-katalogen inneholder et subsett av de opplysningene som finnes i HERdatabasen. Strukturen og informasjonsinnholdet er også tilpasset standarder for LDAP-kataloger. Katalogen har ett topnivå og under dette finnes organisasjoner (f.eks. sykehus, legekontor og apotek). En organisasjon kan bestå av underorganisasjoner (f.eks. avdelinger eller poster) på flere nivåer. Hver organisasjon kan ha tilknyttet personer, utstyrsenheter og programvare. Personer kan også ha tilknyttet utstyrsenheter og programvare mens utstyrsenheter kan ha tilknyttet programvare slik det er vist i figuren nedenfor. For detaljerte opplysninger om innholdet i LDAP-katalogen vises det til separat dokumentasjon. Versjon

22 KATALOGTJENESTE Top person Organization Software Device Person Device Software Organization Software Software Device Software 4.3 Tilgang HER-databasen vil kunne inneholde opplysninger som ikke skal ha ubegrenset distribusjon, f.eks. legers private telefonnumre. Slike opplysninger gjøres ikke tilgjengelig i katalogtjenesten. LDAP-serveren vil kunne ha adgangskontroll som gir differensiert tilgang til ulike opplysninger for ulike brukergrupper, men for å forenkle vedlikeholdet vil katalogtjenesten kun inneholde opplysninger som kan være fritt tilgjengelig for lesning i et nasjonalt helsenett. Det vil ikke være tilgang for brukerne å skrive til katalogen. 4.4 Bruk av katalogtjenesten En viktig funksjon vil være å gjøre registeret tilgjengelig for søkning som en tjeneste i et nasjonalt helsenettet. Det må her være mulig å søke på personers og organisasjoners navn (kombinert med andre tilleggsopplysninger) og få frem identifikasjonsbegrepet til parter som tilfredsstiller søkekriteriene. En vil ikke forvente at den sentrale katalogtjenesten benyttes for oppslag for hver eneste melding som overføres, men at aktørene benytter denne som et oppslagssted for nye adresser som så overføres egne operative adresseregistre eller lokale katalogservere LDAP søkemuligheter Det finns tre forskjellige måter å utføre søk på i LDAP. Disse er base, one-level og sub-tree, og har forskjellige anledning, fokus og resultat. Et LDAP søk består av følgende: 1. Et startpunkt for søket, dvs. noden i treet det skal søkes fra. 2. Et filter, som beskriver hva man søker på. 3. Hvilke attributter man ønsker returnert. 4. Hvordan man ønsker å søke, dvs. fullt sub-tre eller kun ett nivå. Versjon

23 KATALOGTJENESTE Base-søk Et base søk er når en ønsker å ta rede på de forskjellige attributtene for en bestemt post i databasen. Det utføres ved å slå opp i hovedtabellen på distinguished name (DN), f.eks. vis meg alle attributter (hele objektet) for uid=12345, ou=kardiologi, ou=rit, o=her. One-level søk Et one-level søk utføres når en ønsker å vite hvilke ulike objekt som finnes under et objekt. Dette utføres i databasen som ett direkteoppslag på parentdn, f.eks. finn alle objekter direkte under kardiologi på RIT, ou=kardiologi,ou=rit,o=her. Det kan også defineres et filter for å filtrere hvilke objekt som skal vises, f.eks. employeetype= lege Sub-tree søk Et sub-tree søk utføres når en ønsker å finne et objekt som har noen spesielle attributtverdier. Det kan f.eks. være finn alle de personer som har et fornavn eller etternavn som begynner med A i alle underenheter på RIT, ou=rit,o=her med filter: firstname= A* or sn= A*. Det vil tolkes som et oppslag på parentdn med * for å matche alle noder under Anvendelsesmåter Det vanligste bruksområdet vil ventelig være at et applikasjonsprogram benytter HER-katalogen for å finne frem til adresseinformasjon for sine kommunikasjonsparter. HER-ID Kommunikasjonsinfo Navn HER-ID Diverse HER-ID Undereheter av organisasjon Tjenesteytere i et geografisk område. En applikasjon har en HER-ID, og ønsker å kommunisere med eieren av denne. Oppslag i katalogen vil da returnere nødvendig kommunikasjonsinfo i form av telekommunikasjonsadresser. Det må være mulig å søke etter navn for å finne en HER-ID. Dette vil ikke nødvendigvis et entydig svar, da flere navn kan tilfredstille det samme søket. Det vil også kunne være annen informasjon man ønsker å søke på for å finne en HER-ID, for eksempel organisasjonsnavn etc. Underenheter av en gitt type under en organisasjon, f.eks. avdelinger på et sykehus. Tjenesteytere med en gitt rolle i et gitt geografisk område Versjon

24 HELSETJENESTEENHETSREGISTER (HER) 5 Vedlikehold av registeret Dette kapittelet beskriver hvordan det løpende vedlikehold av registeret er tenkt gjennomført. Etter den opprinnelige befolkning av registeret må det løpende vedlikeholdes. Dette gjelder tilgang og avgang av personer og organisasjoner, endring av adresseopplysninger samt endring av relasjoner, for eksempel mellom personer og organisasjoner. 5.1 Registeransvarlig organisasjon For at registeret skal kunne fungere over tid kreves det at en organisasjon gis ansvaret for å vedlikeholde registeret på vegne av Sosial- og helsedirektoratet og at denne organisasjonen gis nødvendige ressurser og myndighet til å kunne utføre oppgaven. 5.2 Informasjonsutveksling Sentral innrapportering De regionale helseforetakene må løpende innrapportere alle nye opplysninger og alle endringer til den sentrale HER-databasen. Her vil opplysningene bli verifisert før innlegging i den sentrale HER-databasen Publisering av kataloginformasjon Et utvalg av opplysningene i HER-databasen vil periodisk (for eksempel daglig) bli overført til den sentrale katalogserveren for publisering i det nasjonale helsenettet Spredning av kataloginformasjon Det sentrale katalogtjenesten vil periodisk utveksle informasjon med andre lokale katalogtjenester i nettet. På denne måten vil informasjon fra den sentrale katalogtjenesten også finnes dublert i de regionale katalogene. 5.3 Løpende oppgaver Tilgang av aktører For nye aktører som tilhører de regionale helseforetakene vil HER-id kunne tildeles regionalt av det regionale helseforetaket som da også må verifisere at registrerte opplysninger er korrekte. Versjon

25 VEDLIKEHOLD AV REGISTERET Opplysninger om øvrige nye aktører registreres som hovedregel også av de regionale helseforetakene, men tildeling av HER-id foregår sentralt. Opplysningene bør kunne oversendes det sentrale HER-registeret elektronisk i et avtalt format. Registeransvarlig skal kontrollere at oppgitte opplysninger er fullstendige og korrekte (dette kan evt. koples mot sertifisering) og at eventuelle oppgitte identifikasjonsbegrep stemmer før parten registreres i registeret. Spesielt bør det verifiseres at en og samme part ikke utilsiktet blir registrert flere ganger under ulike identifikasjonsbegrep Endring av registrerte opplysninger Registeransvarlig skal kontrollere at oppgitte opplysninger synes korrekte og endre registeret tilsvarende. Opplysninger om parter som opprinnelig er registrert av det enkelte helseforetak skal også kunne endres av helseforetaket Sletting av aktører Registeransvarlig skal på anmodning markere i registeret at vedkommende ikke lengre er en aktør i norsk helsevesen enten i en bestemt rolle eller i alle roller. Eksisterende opplysninger i registeret blir ikke fjernet, men opplysningene blir markert til ikke lengre å være gyldige. Opplysninger om parter som opprinnelig er registrert av det enkelte helseforetak skal også kunne markeres som utgått av helseforetaket. Versjon

26 HELSETJENESTEENHETSREGISTER (HER) Vedlegg A Om bruk av UML i figurer CEN/TC251 har vedtatt å benytte notasjonsspråket UML (Unified Modeling Language) i sitt arbeide med utarbeidelse av standarder. I figurene som inngår i denne rapporten benyttes kun et lite subsett av de mulighetene som UML tilbyr. Disse er kort beskrevet i dette kapittelet. Klasser, assosiasjoner og kardinaliteter A 1 0..* B En klasse er tegnet som en boks med klassens navn inni. Assosiasjoner mellom klasser vises med heltrukne linjer, er assosiasjonen retningsbestemt, vises dette med en pilspiss i den ene enden. I figuren ovenfor representere A og B to klasser, og det er en assosiasjon fra B til A. For eksempel kan A her representere et register med beskrivelse av flytyper, mens B er et register med flyruter. Det vil da være en referanse fra hver enkelt flyrute til den flytypen som benyttes på ruten, men det er ikke lagt opp til at det med utgangspunkt i flytypen skal være mulig å finne ut hvilke flyruter den benyttes på. Kardinaliteten som er vist med tallene ved linjens ender, angir at det for hver forekomst av B må finnes en (1) forekomst av A, og at det for hver forekomst av A kan finnes 0 eller flere (0..*) instanser av B. Aggregeringer Aggregering er en spesiell form for assosiasjon som benyttes når et hele skal bygges opp av flere deler. Aggregering symboliseres med et rutersymbol i den delen som utgjør helheten. En spesielt sterk form for aggregering er sammensetning (composition), som angis ved at rutersymbolet er fylt. Dette benyttes når en del alltid må inngå i ett, og bare ett, hele, delen kan altså ikke eksistere utenfor den enhet som den inngår i. Kardinaliteten blir da alltid 1 og angis normalt ikke. Versjon

27 OM BRUK AV UML I FIGURER Idrettsanlegg * 0..1 Byer * Hus 1..* 1..* Etasjer Hvordan aggregeringer benyttes, er enklest å forklare med et eksempel. Figuren ovenfor uttrykker følgende: Et Hus består av en eller flere Etasjer. Enhver Etasje må inngå i ett, og bare ett, enkelt Hus og eksisterer ikke utenfor den sammenheng som Huset utgjør. Etasjer kan bare refereres til som en del av det spesifikke Huset den inngår i. Et Hus derimot, har en selvstendig mening og kan inngå i flere sammenhenger. Et Hus kan maksimalt inngå i et Idrettsanlegg, mens et Idrettsanlegg kan bestå av flere hus, men det finnes også Idrettsanlegg uten Hus. Hvert enkelt Hus eller Idrettsanlegg kan maksimalt inngå i en By, men de kan også ligge utenfor byene. En By består av et eller flere Hus, og det kan også finnes Idrettsanlegg der. En By uten hus gir knapt noen mening, men det er ikke noe krav at det skal finnes et Idrettsanlegg der. Generaliseringer og spesialiseringer En generalisering benyttes for samle en del egenskaper (attributter og relasjoner) som er felles for flere klasser. Figuren nedenfor viser to eksempler på generaliseringer: Person Transportmiddel Pasient Helsepersonell Buss Tog Person er en generalisering av Pasient og Helsepersonell Transportmiddel er en generalisering av Buss og Tog. En annen måte å uttrykke det samme på er: Pasient og Helsepersonell er begge spesialiseringer av Person Buss og Tog er begge spesialiseringer av Transportmiddel. Versjon

28 OM BRUK AV UML I FIGURER Abstrakte klasser I forbindelse med generaliseringer benyttes det ofte abstrakte klasser. Dette er klasser som kun eksisterer i form av sine spesialiseringer. At en klasse er abstrakt, angis ved at klassenavnet står i kursiv. I figuren foran er Transportmiddel en abstrakt klasse, det vil si at konkrete transportmidler kun forekommer i form av spesialiseringene Buss og Tog, og det finnes ikke transportmiddel som er både Buss og Tog. Det vil ofte likevel gi mening å referere til Transportmiddel som sådan, en del egenskaper (som hastighet, energiforbruk etc.) kan være felles for disse, og når en for eksempel skal ut på en kortere reise, kan det være bekvemt å bestille denne uten i første omgang å ta stilling til om en skal benytte Buss eller Tog. Person, derimot, er en konkret klasse. Dette innebærer at det kan finnes Personer som verken er Pasient eller Helsepersonell (heldigvis!), og at samme Person kan være både Pasient og Helsepersonell. Oppsummering av benyttet UML-notasjon I dette avsnittet er det en kort oppsummering av benyttet UML-notasjon. A 0..1 B A er assosiert med maksimalt én B A 1 B A er assosiert med én og bare én B A 0..* B A kan være assosiert med ingen eller flere B A 1..* B A er assosiert med minst én B A * B A er assosiert med ubegrenset antall B A B A er en spesialisering av B A B A kan være en delmengde av B men kan også eksistere uavhengig av B A B A kan være en delmende av B og kan kun eksistere som en del av B Versjon

29

30 HELSETJENESTEENHETSREGISTER (HER) Vedlegg B Object Identifier (OID) Hva er en OID? En OID som står for Object IDentifier, er en streng bestående av siffer og skilletegn som benyttes for å identifisere et objekt entydig på verdensbasis iht. ISO Med et objekt menes vanligvis et veldefinert stykke informasjon, en definisjon eller en spesifikasjon. OID'er tildeles av "tilordningsmyndigheter" som er registrert av ISO eller en annen autorisert tilordningsmyndighet og som har fått tilordnet en "namespace", dvs. et "subtre" hvor tildelingsmyndigheten kan utstede nye OID'er. Oppbyggingen av sifferrekken er laget slik at deler av den entydig identifiserer den som har myndighet til å tildele nye OID er samt disse OID ene. En OID utgjør i sin oppbygging en globalt unik tekststreng som identifiserer et objekt. Identifikatoren består av grupper sifre skilt med skilletegn, og utgjør en trestuktur. ISO har definert en representasjonsform med mellomrom som skilletegn, omsluttet av { og }. Eksempel: { } som identifiserer ett av treene som norske OID er kan tilordnes under. ISO har også en form med både navn og nummer som ser slik ut for samme tre: {itut(0) administration(2) norway(242)} IETF, Internetts standardiseringsorgaisasjon, har definert punkum som skilletegn og sløyfet formen med både navn og nummer, Eksempel: som identifiserer Internetts OID. Denne notasjonsformen benyttes også av HL7 i deres høringsutkast til standarder, bl.a. for datatyper. Den opprinnelige definisjonen av OID kommer fra ITU-Ts X.208 (ASN.1), kapittel 28, samt appendiksene B, C og D. Selve kodingen er angitt i X.209. Hva som kan og skal identifiseres er kun begrenset av fantasien. Meningen er at én OID skal tildeles kun én gang for hvert objekt, men det er i prinsippet ikke noe i veien for at samme objekt kan være tildelt forskjellige OID'er fra forskjellige tilordningsmyndigheter. Eksempler på objekter som kan identifiseres med en objektidentifikator kan være: dokumenttyper i en filoverføringsprotokoll private innholdstyper i en melding i X.400 elektronisk post objekter som skal styres ved hjelp av en management-protokoll objektklasser og attributt-typer i en X.500 eller LDAP katalog, formattyper for medisinske bilder Versjon

31 OBJECT IDENTIFIER (OID) personer, organisasjoner, avdelinger, dokumenter, og produkter Objektidentifikatorer er brukt i en rekke internasjonale standarder fra ISO/IEC og rekommandasjoner fra ITU-T, f. eks. X.400, X.500 og standarder for OSI management. Vanligvis vil en OID i dag brukes til å identifisere et objekt i forbindelse med maskin til maskin-kommunikasjon. En objektidentifikator vil for eksempel kunne entydig identifisere et objekt som transporteres over et åpent nettverk. I slike tilfeller er det som regel ikke nødvendig å gi objektene tekstlige navn som er lettere å lese for mennesker. For å identifisere objektet plasseres det i en hierarkisk trestruktur. Den gir en veldefinert og lett programmerbar, fleksibel og entydig måte å identifisere objektene på. Komponentene i en slik struktur omtales som noder. Hvem tildeler OID er? OID er tildeles av registreringsautoriteter under en såkalt rotnode definert av ISO og ITU-T. Standarden ISO/IEC ITU-T X.680 definerer objektidentifikator-treet. Rotnoden i objektidentifikator-treet svarer til standarden ISO/IEC ITU-T X.680. Under rotnoden finner vi tre hovedgrener, med hver sin registreringsautoritet: Verdi Navn Registreringsautoritet 0 itu-t ITU-T 1 iso ISO 2 joint-iso-itu-t ISO og ITU-T i fellesskap Det er disse som tildeler OID er internasjonalt. Under hver av de tre grenene har ISO og ITU-T definert og nummerert noder som danner nye grener i flere nivåer. Tildeling av OID er i Norge I Norge er det Post- og teletilsynet som tildeler OID er under følgende tre grener: { itu-t(0) administration(2) norway(242)} { iso(1) member-body(2) norway(578)} { joint-iso-itu-t(2) country(16) norway(578)} Tidligere var det Statens teleforvaltning som gjorde dette. Ansvaret ble plassert hos dem ut fra dokumentet Norsk anbefaling. Tildeling av objektidentifikatorer i Norge, Statens teleforvaltning, 11. jan Den ansvarlige registreringsautoriteten for disse objektidentifikator-grenene er i dag Post- og Teletilsynet. Tildeling vil normalt skje fra grenen { joint-iso-itu-t(2) country(16) Norway(578)}. Det vil ikke være noen begrensninger på hvem som kan få tildelt en objektidentifikator. Versjon

32 OBJECT IDENTIFIER (OID) OID for offentlig forvaltning Arbeids- og administrasjonsdepartementet (AAD) har opprettet en OID for offentlig forvaltning under { joint-iso-itu-t(2) country(16) norway(578)} : ORGANISASJON / FIRMA KONTAKT- PERSON VERDI OBJEKT- BESKRIVELSE Arbeids- og administrasjonsd. Katarina de Brisis { } offentligforvaltning Opplysningen er sakset fra Post og telestystemets oversikt over norske OID er. Den finnes på Der finnes også OID ene til Det norske Radiumhospital: { }, det-norskeradiumhospital, og for RiTø, Telemedisinsk avdeling: { }, rito-telemed, som har opprettet sine egne OID er. Det har vært tatt uformell kontakt med AAD vedrørende den OID'en som som er registrert for offentlig forvaltning. Det synes klart at intensjonen med denne er at den igjen skal underinndeles, slik at forskjellige områder innen forvaltningen kan tildeles en OID som kan danne grunnlag for unik identifikasjon av objekter som hører inn under dette området. Mulige anvendelser av OID'er i helsevesenet I forbindelse med elektronisk samhandling innenfor helsevesenet er det i flere sammenhenger behov for unikt å kunne identifisere forskjellige typer objekter. KITH foreslår derfor at SHD anmoder AAD om å få tildelt en node under den OID som er registrert for offentlig forvaltning, til bruk innenfor elektronisk samhandling i helsevesenet. Denne noden blir en OID som skal benyttes for unik identifikasjon av utvalgte typer objekter som benyttes i forbindelse med elektronisk samhandling i helsevesenet. Videre foreslår KITH at det under denne OID'en opprettes nye noder beregnet for spesielle typer informasjon slik som f.eks. kodeverk og klassifikasjonssystem. I det etterfølgende beskrives kort to aktuelle eksempler hvor bruk av OID'er kan løse konkrete problem behov. Det understrekes at dette ikke er de eneste eksemplene, OID'er kan også benyttes i mange andre sammenhenger. Identifikasjon av kodeverk I de standarder mv. som KITH utarbeider, refereres det til en rekke kodeverk og klassifikasjonssystem. Det er et sterkt behov for entydig å kunne referere til disse i forbindelse med utveksling av informasjon. Standardiseringsorganisasjonen HL7 har besluttet å ta i bruk OID'er for å identifisere kodeverk som skal benyttes i de meldinger de utvikler, og KITH anbefaler at tilsvarende blir gjort i Norge. Versjon

33 OBJECT IDENTIFIER (OID) Identifikasjon av kommunikasjonsparter Ved EDI-kommunikasjon er det viktig å entydig kunne identifisere kommunikasjonsparter, deres adresser og eventuelle sertifikater. For entydig identifisering av kommunikasjonsparter pågår det i disse dager et forprosjekt i regi av Nasjonalt helsenett programmet for å utarbeide en testet kravspesifikasjon for Helsetjenesteenhetsregisteret, HER. Det pågår likeledes et forprosjekt for PKIinfrastruktur i helsenettet som bl. a. skal se på elektroniske sertifikater for aktørene i helsevesenet. I planleggingen av HER-registeret er det en forutsetning at registeret skal levere en entydig identifikator for helsevesenets kommunikasjonsparter, HER-Id, det være seg personer, organisasjoner eller deler av organisasjoner. Denne identifikatoren kan være en OID. Kopling til sertifikater hos en CA i en PKI-infrastruktur kan igjen gjøres via OID er. I HER forutsettes det at HER-Id også skal kunne muliggjøre kopling til andre opplysninger om kommunikasjonspartene som ikke vedlikeholdes av HER. Disse koplingene er også mulig å gjøre via OID er. Versjon

34 HELSETJENESTEENHETSREGISTER (HER) Vedlegg C Registerinnhold HER-databasen Nedenfor beskrives et forslag til datainnholdet og struktur for HER-databasen. Benyttede datatyper Databasen er beskrevet med bruk av datatyper som KITH benytter 4. Disse utgjør et subsett av det CEN har foreslått for bruk i helsesektoren i Europa og som igjen er et subsett av HL7 versjon 3 sine datatyper. Datatype Forkortelse Definisjon tekststreng ST En streng av tegn fra ISO 8859 tegnsett. enkel kode CS Kodeverdi av datatype streng. Koding er påkrevd og et sett av lovlige kodeverdier skal være spesifisert. kodet verdi CV Denne datatypen består av 4 komponenter: ICD (International Coding Scheme Designator som er definert i ISO 6523): av datatype streng, er en betinget komponent. Kodeverdi: av datatype streng, er en betinget komponent. Kodebetydning: av datatype streng, er en valgfri komponent. Opprinnelig tekst: av datatype streng, er en valgfri komponent dato/ klokkeslett TS Streng begrenset til å representere år, måned, dag, time, minutter, sekunder og lokal tid differanse faktor. bolsk BL En enkel type med to ulike verdier. Mulige verdier er sann (true) eller usann (false) (definisjon iht. ISO 8824). heltall INT En enkel type med forskjellige verdier som er medlemmer av settet med hele tall. (definisjon iht. ISO 8824). 4 For å forenkle dokumentasjonen er det i tillegg benyttet CEN/HL7s datatype II. Versjon

35 REGISTERINNHOLD Datatype Forkortelse Definisjon reelltall REAL En enkel type med forskjellige verdier som er medlemmer av settet med reelle tall. (definisjon iht. ISO 8824). identifier II Denne datatypen består av 2 komponenter: Streng som identifiserer enheten. Identifikatorer som angir type identifikator angitt som en OID. adresse URL Versjon

36 REGISTERINNHOLD Databasestruktur Figuren nedenfor viser strukturen av de sentrale tabellene i HER-databasen. ServiceProvider role/position : CS herid : II altid : SET<II> name : ST validfrom : TS validto : TS telecommunication : SET<URL> description : ST seealso : ST county : CS citydistrict : CS action : CS performed : TS reason : CS performedby : II 0..* * 0..* Address type : CS status : CS purpose : CS validfrom : TS validto : TS streetaddress : ST zipcode : CV Agent 1 type : CS identifier : SET<II> validfrom : TS validto : TS telecommunication : SET<URL> status : SET<CV> 0..1 county : CS citydistrict : CS 0..* action : CS performed : TS reason : CS performedby : II 1 Relation relation : CS validfrom : TS 0..* validto : TS 0..1 Organization name : ST type : CV specialty : SET<CV> Person profession : SET<CS> qualification : SET<CV> militaryrank : CS sex : CS dateofbirth : TS specialty : SET<CV> title : ST roomnumber : ST picture : ED secretary : II Software productnam e : ST manufacturer : ST internalname : ST filename : ST version : ST s oftwaredate : TS 1..* PersonName type : CS validfrom : TS validto : TS Device type : CV manufacturer : ST modelnam e : ST versio n : ST s eri al n um ber : II room Number : ST NameComponent type : CS 1..* name : ST Diagram: HER-database Versjon

37 REGISTERINNHOLD Figuren nedenfor viser HER-databasen med utvidelser for sertifikater og opplysninger om partenes oppkoplingsmuligheter og trafikk av ulike m,eldinger. ServiceProvider role/position : CS herid : II altid : SET<II> name : ST validfrom : TS validto : TS telecommunication : SET<URL> description : ST seealso : ST county : CS citydistrict : CS action : CS performed : TS reason : CS performedby : II 0..* * Connection type : CS characteristics : SET<CV> security : CS 0..* Encryption Certificate 0..* 1 0..* Address type : CS status : CS purpose : CS validfrom : TS validto : TS streetaddress : ST zipcode : CV 0..* 0..1 Signing 0..* Agent type : CS identifier : SET<II> validfrom : TS validto : TS telecommunication : SET<URL> status : SET<CV> county : CS citydistrict : CS action : CS performed : TS reason : CS performedby : II 0..* Relation relation : CS validfrom : TS validto : TS 1 History action : CS performed : TS reason : CS 0..* Message name : ST status : CS messagestart : TS messageend : TS 0..* Traffic periodstart : TS periodend : TS messages : INT 0..* 0..1 Organization name : ST type : CV specialty : SET<CV> Implementation id : II 1 status : CS syntax : CS vers ion : ST migdate : TS task : CV Person profession : SET<CS> qualification : SET<CV> militaryrank : CS sex : CS dateofbirth : TS specialty : SET<CV> title : ST roomnumber : ST picture : ED secretary : II Software productname : ST manufacturer : ST internalname : ST filename : ST vers ion : ST softwaredate : TS Device type : CV manufacturer : ST modelname : ST version : ST serial number : II roomnumber : ST PersonName NameCom ponent type : CS type : CS 1..* validfrom : TS name : ST valid To : TS 1..* Diagram: Utvidet databasestruktur Versjon