Arkitektur, arkivering og tilgangsstyring



Like dokumenter
Tilleggsopplysninger for saksbehandling i pleie- og omsorgssektoren

Kravspesifikasjon for elektronisk dokumentasjon av sykepleie

Variabelliste og utkast til informasjonsmodell

Journalarkitektur og generelt om journalinnhold

K I T H. Cave, Reservasjoner og ønsker, Praktiske forhold mv. EPJ standardisering: KRAVSPESIFIKASJON OG TEKNISK STANDARD

K I T H. Ekstern korrespondanse. EPJ standardisering: KRAVSPESIFIKASJON OG TEKNISK STANDARD. VERSJON mars 2004 KITH-rapport 45/03

Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten

Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten Del II: Tekniske krav til informasjonsinnhold

Standarder for elektronisk pasientjournal Hvorfor er det behov for slike og hva dekker de?

Verktøy for håndtering av Begrepsapparat, Kodeverk og Klassifikasjonssystem

EPJ standardisering: Cave, Reservasjoner og ønsker, Praktiske forhold mv. Kravspesifikasjon og teknisk standard

Om det pågående arbeid med standard for arkivering av EPJ Hva med kommunenes behov?

Elektronisk pasientjournal - Hvor står vi og hvor går vi?

Forespørsel om fastlege Informasjonsmodell og XML meldingsbeskrivelse HIS 1022:2010

Noark-4, del 1: Endringer i forhold til den trykte utgaven (Kommuneforlaget, 1999)

Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten Del II: Tekniske krav til informasjonsinnhold

K I T H. Dokumentasjon av individuell plan. EPJ standardisering: KRAVSPESIFIKASJON OG TEKNISK STANDARD. VERSJON mars 2004 KITH-rapport 43/03

Person, organisasjon mv

HIS 1031:2011. VERSJON juni 2011 KITH-standard 1031 : 2011

K I T H. Tilleggsopplysninger for saksbehandling i pleie- og omsorgssektoren. Tillegg til Noark-4: TEKNISKE SPESIFIKASJONER

EPJ standardisering: Elektronisk dokumentasjonssystem for pleie- og omsorgstjenesten endret KITH 21/08:2012

EPJ standardisering: Generelt journalnotat og Fellesfaglig dokumentasjon Kravspesifikasjon og teknisk standard

K I T H. Generelt journalnotat og Fellesfaglig dokumentasjon. EPJ standardisering: KRAVSPESIFIKASJON OG TEKNISK STANDARD

NOARK Hva? Fra: Wikipedia, den frie encyklopedi

- <!-- Generated on :28:44 at KITH. - <!-- XML-Schema level supported is specified by W3C. - <!--

Høringsutkast til EPJ standard del 2: Tilgangsstyring, redigering, retting og sletting

Uttrekkstandard for elektronisk pasientjournal (EPJ) Torbjørn Nystadnes Helsedirektoratet, Avdeling arkitektur, metode og standardisering

Standardisering hvorfor det?

Forespørsel og svar om egenandel

PERIODISERING AV ELEKTRONISK JOURNAL OG ARKIV

Innrapportering av trekk til NAV

Noark-5 hva blir det til? Ståle Prestøy IKA Trøndelag. 23. mai 2007 Noark-5 - hva blir det til? 1

Del 1 Generelle funksjonskrav for alle delområder

Standard: Organisasjonsoppsett

Innføring i. Grunnkurs for saksbehandlere SENTRALE BEGREP. Elektronisk arkiv og saksbehandling ved Høgskolen i Telemark Jorunn Pedersen

Beskrivelse av filformatet for likningsoppgaven pass og stell av barn

HIS 80510:2015. EPJ standard: Felles funksjonelle krav. Versjon 1.6 Opprinnelig dato Sist endret KITH 21/08:2012

SOSI standard - versjon Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer

HIS 80506:2015. EPJ standard del 2: Tilgangsstyring, redigering, retting og sletting. Funksjonelle krav og teknisk standard

Person, organisasjon mv

Journalarkitektur og generelt om journalinnhold

RiskManager Avvikshåndtering. Kurshefte for meldere

Bakgrunn Innlogging Brukere med tilgang Registrere infeksjoner Registrere antibiotika Registreringer...

Medisinsk-faglig innhold i epikriser fra poliklinikker og legespesialister - "Den gode spesialistepikrise"

Transaksjonsstandard for virkesomsetningen i Norge. Business Acknowledge. Versjon 2.0. Desember 2007 SKOG-DATA AS

Periodisering og avlevering av elektronisk arkiv hvem, hva, når? Rådgiver Ole-Bjørn Fossbakk og rådgiver Solveig Heløe Olsen, IKA Troms

Kurs eldremedisin, Hedmark 04. juni 2015 Kjellaug Enoksen, sykehjemsoverlege Askøy kommune. Spesialist i indremedisin og samfunnsmedisin, Godkjenning

Fagkurs for kommuner Krav til informasjonssikkerhet (105 minutter)

HVEM ER JEG OG HVOR «BOR» JEG?

Om utkast til EPJ standard del 3: Arkivuttrekk

Transaksjonsstandard for virkesomsetningen i Norge. Transportert virke. Versjon 2.0. Desember 2007 SKOG-DATA AS

HIS 80708:2007. Kommunikasjon av EPJ-innhold Side 1 av 18 Løsningsskisse. Kommunikasjon av EPJ-innhold Løsningsskisse

Behov for oppdatering av EPJ standard som følge av regelverksendringer mv

NOARK EGENERKLÆRING OM SYSTEMFUNKSJONALITET FRA PRODUSENTER AV NOARK-SYSTEMER

HØRINGSUTTALELSE - ENDRINGER I FORVALTNINGSLOVEN

Produktspesifikasjon. Oppdateringslogg. 1. Kjente bruksområder og behov. 2. Innhold og struktur. 2.1 UML-skjema. Dato Datakatalog versjon Endringer

NOARK Hva? Fra: Wikipedia, den frie encyklopedi

Feilretting i Noark-4

1 Krav til behandling av diagnoser i en elektronisk pasientjournal

HENSIKT OG OMFANG...2

Hvorfor ny versjon av Noark?

K I T H. Ebrev. Elektronisk utsending av brev FOR HELSE OG VELFERD.. INFORMASJONSTEKNOLOGI

Framgangsmåte for klargjøring og avlevering av elektronisk arkivmateriale til arkivdepot Supplerende bestemmelser for kommuner tilknyttet IKAT

Transaksjonsstandard for virkesomsetningen i Norge. Transportoppdrag. Versjon 2.0. Desember 2007 SKOG-DATA AS

Standard for kommunikasjon av EPJ-innhold Informasjonsmodell og XML meldingsbeskrivelse

EFO/NELFO Vareformat versjon 3.0 Rev.:

EPJ standard. Tilgangsstyring, retting og sletting

K I T H. Tverrfaglig spesialisert behandling av rusmiddelmisbruk. EPJ standard: KRAVSPESIFIKASJON OG TEKNISK STANDARD

Eksport /Import person

Fagområde: Annen naturinformasjon

Elvira. Standarder for elektronisk pasientjournal

Utskrivningsrapport Veiledning i bruk av meldingen for logistikkmeldinger

I databasen ligger det over 100 tabeller. De henger sammen dels via synlige koder, dels via usynlige interne ID-er. De ser man normalt bare når det

Retningslinjer for deponering og avlevering av digitalt arkiv. Kontaktkonferansen 2018 Arkiv Troms v/jan Grav, IT-rådgiver

Høringsuttalelse - Forslag til ny kommunal helse- og omsorgslov

AP226 Use Case Diagram - SBL

SOSI-forvaltning - logisk modell

Brukerdokumentasjon. Adresseregisteret Om Adresseregisteret

Overgang til RT4 hjelp for saksbehandlere

Produktspesifikasjon. Fartsgrense (ID=105) Oppdateringslogg. 1. Kjente bruksområder og behov. 2. Innhold og struktur. 2.

K I T H. EPJ standard: Enkelte vedtak om tvang i det psykiske helsevern KRAVSPESIFIKASJON OG TEKNISK STANDARD

Instruks for elektronisk arkivmateriale som avleveres eller overføres som depositum til IKA Møre og Romsdal IKS

Sikkerhetskrav for systemer

K I T H. Introduksjon til EPJ standard. EPJ Standard del 1: VERSJON desember 2007 KITH-rapport 5/05 FOR HELSE OG VELFERD ISBN

Leverandørregisteret. Søk og vedlikehold. VISMA RETAIL AS Wirgenes vei 1, 3157 Barkåker, Telefon:

Akseptansetest av mottak Svarrapportering av medisinske tjenester Mikrobiologi

K I T H. Felles funksjonelle krav. EPJ Standard: VERSJON mars 2006 KITH-rapport 10/05 FOR HELSE OG VELFERD ISBN

Diskusjon:SportsAdmin Medlemsadministrasjon

UML 1. Use case drevet analyse og design Kirsten Ribu

Egenerklæringsskjema for godkjenning av Noark 5-løsning

Norsk Arkivråd - Høstseminar 2009 Erfaringer med bruk av NOARK 5

Manual MicroBuild.no Engineering

RiskManager Avvikshåndtering Kurshefte for behandlere

WinMed Allmenn NPR. Lysaker Torg 15 Postboks LYSAKER. Tlf: Fax: E-post:

Utvidet kravspesifikasjon for ArkN4

BRUKERVEILEDNING PROFILE

Ajourføring og kontroll av skogsbilveier

Oversikt over Document Portal

Skatteetaten Boligsameie Beskrivelse av filformatet for innsending av opplysninger til Skatteetaten Gjelder fra og med innrapportering i januar 2016

Transkript:

Elektronisk pasientjournal standardisering Arkitektur, arkivering og tilgangsstyring Del II: Tekniske spesifikasjoner KITH 2001

Side 2 EPJ Standard 2001 KITH

EPJ Standard Side 3

Side 4 EPJ Standard Innhold INNLEDNING DEL II...10 11. KLASSER OG ATTRIBUTTER...11 11.1 Innledning...11 11.1.1 Forkortelser mv... 12 11.1.2 Kort om klassediagrammene... 13 11.2 Grunnleggende arkitektur...14 11.2.1 EPJ... 15 11.2.2 Journalinnhold (EPJINNH)... 16 11.2.3 Journalansvar (EPJANSVAR)... 17 11.2.4 Journal hendelse (EPJHENDELSE)... 19 11.2.5 EPJ grunnkomponent... 21 11.2.5.1 Journalrot (JOURNROT)... 21 11.2.5.2 Revisjonsinfo (EREVINFO)... 22 11.2.6 EPJ link (EPJLINK)... 24 11.2.7 Felles egenskaper ved komponenter... 26 11.2.7.1 EPJ komponent... 26 11.2.7.2 Formål med registrering (FORMEDREG)... 27 11.2.7.3 Informasjonskategori (INFOKAT)... 29 11.2.7.4 Signalinformasjon (SIGNALINFO)... 31 11.2.7.5 Varselinformasjon (VARSELLINFO)... 33 11.2.7.6 Informasjonskilde (INFOKILDE)... 35 11.2.7.7 Ekspedert til (EKSPTIL)... 37 11.2.7.8 Ekstern referanse (EKSTERNREF)... 39 11.2.7.9 Komponent hendelse (KOMPHENDE)... 41 11.3 Komponenttyper...43 11.3.1 EPJ sak (EPJSAK)... 44 11.3.1.1 Sakstype (EPJSAKSTYPE)... 45 11.3.1.2 EPJ saksstruktur (EPJSAKSTRUK)... 49 11.3.1.3 EPJ Sakshode (EPJSAKSHODE)... 53 11.3.1.4 Saksinnhold (EPJSAKSIH)... 54 11.3.2 Importert komponent (IMPORTKOMP)... 56 11.3.3 EPJ dokument (EPJDOKUMENT)... 58 11.3.3.1 Dokumenttype (EPJDOKTYPE)... 60 11.3.3.2 EPJ dokumentstruktur (EPJDOKSTRUK)... 62 2001 KITH

EPJ Standard Side 5 11.3.3.3 Dokumentinnhold (EPJDOKIH)... 64 11.3.4 EPJ fragment (EPJFRAG)... 66 11.3.4.1 EPJ fragmenttype (EPJFRAGTYPE)... 68 11.3.4.2 Avsnittsinformasjon (EPJAVSNINFO)... 70 11.3.4.3 Fragmentstruktur (EPJFRAGSTRU)... 71 11.4 Dataelementer...73 11.4.1 EPJ dataelement... 74 11.4.1.1 EPJ dataelement type (EPJDETYPE)... 75 11.4.1.2 Kodeverk dataelement (EPJKVDE)... 77 11.4.1.3 Alfanumerisk element (EPJDEALFA)... 78 11.4.1.4 Numerisk element (EPJDETALL)... 78 11.4.1.5 Fri tekst (EPJDETEKST)... 79 11.4.1.6 Tidsangivelse (EPJDEDATOKL)... 80 11.4.1.7 Kodet verdi (EPJDEKODE)... 81 11.4.1.8 Boolsk verdi (EPJDEBOOLSK)... 81 11.4.1.9 Enhetsreferanse (EPJDEORG)... 83 11.4.1.10 Personreferanse (EPJDEPERSON)... 83 11.4.1.11 Adressereferanse (EPJDEADR)... 84 11.4.1.12 Dataansamling (EPJDEDATAMS)... 85 11.4.1.13 Ikke-elektronisk element (EPJDEIKEL)... 87 11.4.1.14 Fragmentreferanse (EPJDEFRAG)... 87 11.4.1.15 Utstyrsreferanse (EPJDEMTUT)... 88 11.4.1.16 Programvarereferanse (EPJDPROG)... 88 11.4.1.17 Tjenesteyterreferanse (EPJDETJYTER)... 89 11.4.1.18 Tjenesteutførelsereferanse (EPJDETJUTF)... 89 11.4.1.19 Tiltaksreferanse (EPJDETJUTF)... 90 11.5 Tilgangsstyring...91 11.5.1 Roller, tjenesteutførelse og tiltak... 91 11.5.1.1 Tjenesteyter (TJENYTER)... 92 11.5.1.2 Opptredener (OPPTRED)... 93 11.5.1.3 På vegne av (PVEGNEAV)... 94 11.5.1.4 Rolle (ROLLE)... 96 11.5.1.5 Rolle - enhet (ROLLENHET)... 97 11.5.1.6 Rollemal (ROLLEMAL)... 98 11.5.1.7 Rolle - tiltak (ROLLETILTAK)... 99 11.5.1.8 Tiltaksmal (TILTMAL)... 101 11.5.1.9 Tiltaksmalstruktur (TILTSTRUKT)... 104

Side 6 EPJ Standard 11.5.1.10 Formål med tiltak (TILTAKFORM)... 106 11.5.1.11 Informasjonsbehov (INFOBEHOV)... 107 11.5.1.12 Kan kun utføres ved enhet (TILTKANUT)... 108 11.5.1.13 Varslingsregler (VARSELTJENUT)... 109 11.5.1.14 Tiltaksautorisasjon (TILTAUTORI)... 111 11.5.1.15 Tilgang til hjelperegister (TILGHJELPREG)... 113 11.5.1.16 Tilgang til kodeverk (TILGKODEV)... 115 11.5.1.17 Tilgang til funksjon (TILGFUNK)... 116 11.5.1.18 Tilgang til autorisering (TILGAUTOR)... 118 11.5.1.19 Tilgang til pseudonymformål (TILGPSEUDO)... 120 11.5.1.20 Tjenesteutførelse (TJENUTF)... 121 11.5.1.21 Besluttet tiltak (BESLUTILT)... 123 11.5.1.22 Informasjon om sletting (INFOSLETT)... 125 11.5.1.23 Tiltaksavhengighet (TILTAVH)... 127 11.5.1.24 Kan kun utføres av (KANUTFAV)... 128 11.5.1.25 Særskilt varsling (SVARSL)... 129 11.5.1.26 Tilgang til komponent (TILTKOMP)... 131 11.5.1.27 Utføres ved enhet (UTFENHET)... 132 11.5.2 Registreringsinfo (REGINFO)... 133 11.5.3 Samtykke... 134 11.5.3.1 Samtykke (EPJSAMTYKKE)... 135 11.5.3.2 Samtykke til tjenesteutførelse (EPJSAMTUT)... 136 11.5.3.3 Representant for pasient (PASIENTREPR)... 137 11.5.3.4 Samtykkekrav (EPJSAMTKRAV)... 138 11.5.3.5 Samtykkekrav gjelder (SAMTILKOMP)... 139 11.5.3.6 Unntak fra krav om samtykke (UNTSAMTYK)... 140 11.6 Kodeverk og klassifikasjonssystemer... 141 11.6.1 Hovedstruktur for kodeverk... 142 11.6.1.1 Kodeverk (KVERK)... 143 11.6.1.2 Kodeverknode (KVNODE)... 147 11.6.1.3 Kodeverksstruktur (KVSTRUKT)... 149 11.6.1.4 Kodeverkelement (KVELEMENT)... 150 11.6.2 Kodeverkrevisjon (KVREV)... 152 11.6.3 Koblinger mellom kodeverk... 154 11.6.3.1 Kodelink (KVLINK)... 155 11.6.3.2 Anvendt Kodeverkelement (KVANVEND)... 157 11.6.4 Termer, begrep og definisjoner... 159 11.6.4.1 Term (KVTERM)... 160 2001 KITH

EPJ Standard Side 7 11.6.4.2 Element-Term (KVELEMTERM)... 161 11.6.4.3 Termlink (KVTERMLINK)... 163 11.6.4.4 Begrep (KVBEGREP)... 164 11.6.4.5 Definisjon av begrep (KVDEF)... 165 11.6.5 Tilleggsinformasjon for kodeverk... 167 11.6.5.1 Kodenodeinformasjon (KVNINFO)... 168 11.6.5.2 Kodenodeinformasjon link (KVNINFOLINK)... 170 11.6.5.3 Kodeformat (KVKFORMAT)... 171 11.7 Personrelatert informasjon... 172 11.7.1 Person (EPJPERSON)... 173 11.7.2 Persondata (EPJPERDATA)... 174 11.7.3 Personnavn (EPJPERNAVN)... 177 11.7.4 Personnavnkomponent (EPJPNAKOMP)... 180 11.7.5 Sekundær person ID (EPJSEKPID)... 181 11.7.6 Hjemstavn (EPJHJEMST)... 183 11.7.7 Pasient (EPJPASIENT)... 185 11.7.8 Pårørende (EPJSLEKT)... 186 11.7.9 Rolle i forhold til pasient (ROLLEPAS)... 188 11.7.10 Pseudonym (EPJPSEUDO)... 190 11.7.11 Pseudonymformål (EPJPSEUDOFOR)... 191 11.7.12 Persons adresse (EPJPERADR)... 192 11.7.13 Språkkunnskap (EPJSPRAKUN)... 194 11.7.14 Stilling (EPJSTILLING)... 195 11.7.15 Yrke og utdanning (EPJYRKE)... 197 11.8 Organisasjon... 198 11.8.1 Organisatorisk enhet (ORGENHET)... 199 11.8.2 Organisasjonsstruktur (ORGSTRUKT)... 200 11.8.3 Info organisatorisk enhet (ORGINFO)... 202 11.8.4 Sekundær enhets-id (SEKORGID)... 204 11.8.5 Organisasjonslink (ORGLINK)... 206 11.8.6 Virksomhet (VIRKSOMHET)... 208 11.8.7 Administrativ enhet (ADMENHET)... 210 11.8.8 Enhets adresse (ORGADR)... 212 11.9 Medisinsk teknisk utstyr og programvare... 213 11.9.1 Medisinsk teknisk utstyr (MEDTEKUTSTYR)... 213 11.9.2 Utstyrsplassering (MTUTPLASS)... 214 11.9.3 Programvare (PROGVARE)... 215

Side 8 EPJ Standard 11.10 Stedsrelatert informasjon... 216 11.10.1 Adresse (EPJADRESSE)... 217 11.10.2 Stedsadresse (STEDSADR)... 218 11.10.3 Nasjon (NASJONINFO)... 219 11.10.4 E-post adr (EPOSTADR)... 221 11.10.5 Adressekomponent (ADRESSEKOMP)... 222 11.10.6 Teleinformasjon (TELEINFO)... 224 11.10.7 Adresse i bruk (ADRIBRUK)... 226 11.11 Arkivering... 227 11.11.1 EPJ Arkivinfo (EPJARKINFO)... 228 11.11.2 EPJ arkivkomponent (EPJARKOMP)... 230 11.11.3 Arkivdokument (EPJARKDOK)... 231 11.11.4 Digital signatur (DIGISIGN)... 233 11.11.5 Klassifisering (EPJKLASS)... 235 11.11.6 Arkiv (ARKIV)... 237 11.11.7 Arkivperiode (ARKIVPERIODE)... 238 11.11.8 Arkivdel (ARKIVDEL)... 239 11.11.9 Ordningsprinsipp (ORDNPRINS)... 242 11.11.10 Ordningsverdi (ORDNVERDI)... 245 11.11.11 Tilgangskode (TGKODE)... 247 11.11.12 Type ordningsprinsipp (ORDNPRINSTYPE)... 248 11.11.13 Arkivstatus (ARSTATUS)... 249 11.11.14 Lagringsformat (LAGRFORMAT)... 250 11.11.15 Lagringsenhet (LAGRENHET)... 251 12. FORMATER FOR EKSPORT... 252 12.1 Generelt om utveksling og eksportformat... 252 12.1.1 Det elektroniske dokumentlageret... 253 12.2 Dokumentformater... 254 12.2.1 Produksjonsformater... 254 12.2.2 Arkivformater... 255 12.2.3 Godkjente arkivformater... 256 12.2.4 Ren tekst - ISO Latin-1 8859-1:1987... 257 12.2.5 SGML (Standard Generalized Markup Language) - ISO 8879:1986... 257 12.2.6 TIFF (Tagged Image File Format), versjon 6 - ISO 12639: 1997... 258 12.2.7 PDF (Portable Document format)... 259 12.3 Eksport av dokumenter for avlevering... 259 2001 KITH

EPJ Standard Side 9 12.4 Eksport- og avleveringsformat... 261 12.4.1 Informasjon om de eksporterte data... 261 12.4.2 Format for eksport av klasseinformasjon... 265 12.4.3 Eksport av elektronis ke dokumenter... 266 13. REFERERTE KODEVERK... 267

Side 10 EPJ Standard INNLEDNING DEL II På grunn av omfanget av de tekniske spesifikasjonene er denne standarden delt i 2 rapporter: Del I (kapitlene 1-10) omfatter den funksjonsrettede beskrivelsen og kravspesifikasjonen. Funksjonskravene knyttes her også opp mot tilhørende prosedyrer og rutiner Del II (kapitlene 11-12) inneholder de tekniske spesifikasjonene. Den primære målgruppen for denne Del II av standarden er systemleverandører som ønsker å utvikle EPJ-systemer. Men også for systemutviklere vil det være nødvendig å gjøre seg kjent med den beskrivende fremstillingen i Del I for å forstå meningen med kravene og de sammenhenger de inngår i. Sammen vil de formaliserte funksjonskravene i Del I og de tekniske spesifikasjonene i Del II utgjøre den konkrete referanseramme for utviklingen av et EPJ-system basert på denne standarden. For som bruker eller vurderer å ta i bruk et EPJ-system, vil det som regel være tilstrekkelig å sette seg inn i rapportens Del I. Men ønskes detaljinformasjon om datamodell mv., eller ønsker å kontrollere i hvilken grad et EPJ-system oppfyller kravene i standarden, er det også nødvendig å forholde seg til del II. For systemleverandørene skal rapporten være et arbeidsredskap i systemutviklingen. Det er lagt vekt på å systematisere og formalisere kravspesifikasjonen slik at man lett kan identifisere hva som er krav, hvilket nivå kravene ligger på og hva som er rene anbefalinger eller forslag. 2001 KITH

EPJ Standard Side 11 11. KLASSER OG ATTRIBUTTER 11.1 Innledning Selv om beskrivelsen av klasser og attributter i denne standarden kan synes vel detaljert, er det viktig å være oppmerksom på at denne beskrivelsen er beregnet på eksport av EPJ for overføring til arkivdepot eller intern langtidsarkivering, samt ved eventuelt skifte av leverandør for EPJ-system. Denne detaljerte formen for beskrivelse skal ikke forstås slik at utformingen av klasser og attributter i EPJ-systemet skal være eksakt slik som beskrevet. Den enkelte leverandør står fritt til å utforme sin egen datamodell så lenge den informasjonen og de funksjoner som beskrives, blir gjort tilgjengelig for systemets brukere. Det er dog en forutsetning at datatypen til hvert enkelt attributt i EPJ-systemene, er kompatibel med det format som er angitt for tilsvarende attributt i dette kapitlet. Dette innebærer spesielt at det ikke tillates at noe EPJ-system inneholder tekst eller numeriske attributter med større lengde enn det som er angitt for tilsvarende attributter i denne standarden. En mulig konsekvens av en så normalisert datamodell som den som presenterer i denne standarden, er dårlig ytelse på enkelte områder. For å motvirke dette vil den enkelte leverandør måtte tilpasse datamodellen til de behov de ser hos sine kundegrupper, og benytte de tekniske løsninger de finner mest hensiktsmessig. Det understrekes derfor at det ved anskaffelse av et EPJ-system ikke bør stilles krav om at systemet internt skal benytte den datamodell som er beskrevet i denne standarden. Ved eksport av data for avlevering til arkivdepot er kravene absolutte både når det gjelder attributtenes format og fordeling på klasser. Det anbefales at det tas med funksjoner for eksport og import av alle attributter i alle klasser, også de som ikke skal avleveres til arkivdepot, da dette vil lette overgangen til nye systemversjoner. For enkelte hjelpeklasser knyttet til arkivering, er det tatt med en oversikt over faste verdier. Disse verdiene er å oppfatte som obligatoriske krav i den grad det attributt som henter sine verdier fra hjelpeklassen, er med i løsningen. Dersom kun faste verdier benyttes, kan klassen utelates ved eksport for avlevering.

Side 12 EPJ Standard 11.1.1 Forkortelser mv I beskrivelsen av de enkelte klasser benyttes følgende forkortelser mv: Betegnelse Betegnelse for attributtet. Denne benyttes i de fleste tilfeller hvor det refereres til attributtet fra andre deler av denne standarden. K - Type krav, se kapittel 1.4.1 i del I av denne standarden. Kravtypen gjelder både attributtet som sådant og eventuelle funksjoner beskrevet i merknadsfeltet. Dersom kravtypen er satt i kursiv skal attributtet ikke tas med ved eksport for avlevering til arkivdepot, men det bør likevel finnes en opsjon for å inkludere disse attributtene, f.eks. ved overføring av en periode til en egen database. O - Obligatorisk innhold. Markert med x dersom attributtet alltid skal ha verdi. Markert med b dersom attributtet må ha verdi når nærmere spesifiserte betingelser er oppfylt. Beskrivelsen av betingelsene er enten angitt i merknadsfeltene eller under klassen. Format Format på attributtet ved utveksling og eksport, f.eks. for avlevering til arkivdepot. (Merk: et annet format kan gjerne benyttes ved lagring m.v.) Følgende koder benyttes: X(n) - Tekststreng med maksimal lengde n tegn. 9(n) - Tall med maksimalt n siffer. Eksporteres med sin virkelige lengde eller med ledende 0 til full lengde. MERK: 9(10) benyttes i denne standarden for "long integer" og gir da en øvre grense på 2.147.483.647. (Negative verdier benyttes ikke for noen attributter i denne standarden) tidspkt - dato og klokkeslett på formen YYYYMMDDHHMMSS (Merk: dette formatet bør ikke benyttes ved fremvising på skjerm mv.) dato - Dato på formen YYYYMMDD. (Merk: et annet format kan benyttes ved fremvising på skjerm m.v.) tekst - Tekst av fri lengde. binær - Binært innhold av fri lengde. Kortnavn Alfanumerisk kortnavn for attributtet. Kortnavnet er unikt for hele standarden. Benyttes som (SGML-)tagg til elementet ved uttrekk for eksport. Benyttes også andre steder i standarden hvor det er behov for en kort, entydig referanse til et attributt. Merknader Beskrivelse av attributtet med regler for innholdet dersom slike finnes. 2001 KITH

EPJ Standard Side 13 11.1.2 Kort om klassediagrammene Hele datamodellen er i det etterfølgende illustrert med et sett UML klassediagrammer. Etter hver figur følger en beskrivelse av de fleste klassene som inngår i figuren. De fleste figurene inneholder også en del klasser som er tatt med for å vise sammenhengen med resten av datamodellen, og beskrives andre steder i dokumentet. Slike klasser er markert ved at klassenavnet er angitt med en annen skrift, f.eks. Tjenesteytelse i stedet for Tjenesteytelse. En del assosiasjoner mellom klassene er utelatt i diagrammene. Dette er i all hovedsak assosiasjoner til klasser som Person, Organisatorisk enhet, Revisjonsinfo og Registreringsinfo, altså klasser som refereres fra en rekke forskjellige steder i datamodellen, og som kan ses på som sekundære i forhold til det modellen skal illustrere. Assosiasjonene til disse klassene er representert ved attributter der hvor de refereres fra. Alle andre assosiasjoner er for øvrig også beskrevet med attributter. Dette er gjort fordi det ved eksport til arkivdepot, se kapittel 12, og ved eksport i forbindelse med skifte av leverandør av EPJ-systemet, skal legges ut en fil for hver klasse. Disse attributtene er da nødvendige for å opprettholde assosiasjonen. Kardinalitet er også angitt for de aller fleste assosiasjoner. Unntaket er ved den sterke formen for aggregering, sammensetning, når kardinaliteten er 1 i den enden av assosiasjonen som utgjør helheten. I del I av denne standarden finnes det for øvrig en kort introduksjon til datamodellene i kapittel 1.6.3.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 14 Tekniske spesifikasjoner 11.2 Grunnleggende arkitektur Pasient 1 EPJ 0..* Journalansvar 1 1..* Journal hendelse Journalinnhold 1 1 1 0..* 1..* EPJ grunnkomponent 1..* EPJ link 0..1 1..* Revisjonsinfo 0..* 1..* Besluttet tiltak 1 0..* 1 Tjenesteutførelse Journalrot 1 0..* EPJ sak EPJ komponent Figur 1. Grunnleggende arkitektur for EPJ

EPJ Standard Side 15 11.2.1 EPJ Denne klassen knytter innholdet i en journal, identifisert ved en forekomst av klassen Journalinnhold, opp mot den Pasient journalen omhandler. Også journaler ført av andre virksomheter registreres i denne klassen, dersom det er importert informasjon fra disse.. journal ID O x 9(10) EPJ_ID Unik ID som identifiserer journalen innenfor journalsystemet. pasient ID O x 9(10) EPJ_PASID Unik referanse som identifiserer pasienten innenfor journalsystemet virksomhet ID A x 9(10) EPJ_ORGID Her registreres referanse til den virksomheten som fører denne journalen. ekstern journal ID A 9(10) EPJ_EKSTEPJID Her registreres det journal ID som identifiserer den aktuelle EPJ innenfor virksomheten identifisert gjennom attributtet "virksomhet ID". ekstern journal A X(1) EPJ_EKSTERN Verdi 1 dersom dette er en referanse til en journal som føres av en annen virksomhet, verdi 0 dersom journalen føres av egen virksomhet. For denne klassen benyttes kortnavnet EPJ. Unik nøkkel: EPJ_ID

EPJark 2: Arkitektur, arkivering og sikkerhet Side 16 Tekniske spesifikasjoner 11.2.2 Journalinnhold (EPJINNH) Denne klassen benyttes for å knytte sammen alt som inngår i en journal, en Journalrot, et antall EPJ grunnkomponenter, Besluttede tiltak, Journalhendelser samt informasjon om Journalansvarlig. journal ID O x 9(10) EPI_EPJID Unik ID som identifiserer journalen innenfor virksomheten. EPJ status O x 9(10) EPI_STATUS Angir status for journalen, f.eks. "aktiv", "mors", "pasientforholdet avsluttet". Status for EPJ defineres i et eget, felles kodeverk med kodeverk ID = 9001. Dette attributtet skal inneholder kodenode ID til den relevante status. journalkategori A 9(10) EPI_KATEGORI Angir hvilken kategori journal dette er. For denne klassen benyttes kortnavnet EPJINNH. Unik nøkkel: EPI_EPJID Journalkategorier defineres i et eget, felles kodeverk med kodeverk ID = 9002. Dette attributtet skal inneholder kodenode ID til den relevante kategori.

EPJ Standard Side 17 11.2.3 Journalansvar (EPJANSVAR) Denne klassen benyttes for å holde rede på hvem som til enhver tid er journalansvarlig og eventuelt hvilken del av virksomheten (organisatorisk enhet) som fører denne journalen.. journal ID O x 9(10) EPA_EPJID Unik ID som identifiserer journalen innenfor virksomheten. Utgjør sammen med "journalansvarlig person ID" og "registrert ved revisjon" en unik nøkkel for denne klassen. organisatorisk enhet O x 9(10) EPA_ORGID Referanse til en Organisatoriske enhet (avdeling, virksomhet el.) som journalen tilhører. Dersom journalen er felles for hele virksomheten (sykehuset) skal attributtet den registrering som representerer virksomheten, hvis ikke skal det refereres til den organisatoriske enhet innenfor virksomheten som journalen tilhører. journalansvarlig person ID O x 9(10) EPA_JOURNANSV Unik referanse til den Tjenesteyter som er journalansvarlig. Utgjør sammen med "journal ID" og "registrert ved revisjon" en unik nøkkel for denne klassen. fra tidspunkt O x tidspkt EPA_FRA Det tidspunkt vedkommende Tjenesteyter tiltrådte som journalansvarlig person. til tidspunkt O tidspkt EPA_TIL Det tidspunkt vedkommende Tjenesteyter fratrådte som journalansvarlig person. Dette attributtet skal oppdateres automatisk når det a) registreres en ny journalansvarlig, og b) når det registreres en Journal hendelse som innebærer at journalen avsluttes.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 18 Tekniske spesifikasjoner registrert ved revisjon O x 9(10) EFA_REGREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne registreringen ble gjort. Utgjør sammen med "journalansvarlig person ID" og "journal ID" en unik nøkkel for denne klassen. For denne klassen benyttes kortnavnet EPJANSVAR. Unik nøkkel: EPA_EPJID, EPA_JOURNANS, EFA_REGREV

EPJ Standard Side 19 11.2.4 Journal hendelse (EPJHENDELSE) Denne klassen benyttes for å registrere alle former for hendelser knyttet til journalinnholdet som helhet. Med hendelse menes her opprettelse av journal, avslutning av journal, gjenåpning av avsluttet journal etc. journal ID O x 9(10) EPH_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. Utgjør sammen med "EPJ hendelse" og "registrert ved revisjon" en unik nøkkel for denne klassen. registrert ved revisjon O x 9(10) EPH_REV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne registreringen ble gjort. Utgjør sammen med "journal ID" og "registrert ved revisjon" en unik nøkkel for denne klassen. EPJ hendelse O x 9(10) EPH_HENDELSE Attributtet benyttes for å angi hvilken hendelse registreringen gjelder. Utgjør sammen med "journal ID" og "registrert ved revisjon" en unik nøkkel for denne klassen. Komponent hendelser defineres i et eget, felles kodeverket med kodeverk ID = 9048. Dette attributtet skal inneholder kodenode ID til det den relevante hendelsen. Eksempler på slike hendelser kan være: journal opprettet journal avsluttet og overført til annen virksomhet journal avsluttet og overført til arkivdepot journal avsluttet uten overføring journal gjenåpnet journal mottatt elektronisk fra annen virksomhet

EPJark 2: Arkitektur, arkivering og sikkerhet Side 20 Tekniske spesifikasjoner virksomhet ID O 9(10) EPH_ORGID Dersom hendelsen innebærer overføring av en journal til eller fra en annen virksomhet, eller på annen måte har tilknytning til en annen virksomhet, registreres referanse til denne virksomheten her. tidspunkt for hendelse O tidspkt EPH_TIDSPKT Benyttes dersom det tidspunkt hendelsen "inntraff" er signifikant forskjellig fra registreringstidspunktet. For denne klassen benyttes kortnavnet EPJHENDELSE. Unik nøkkel: EPH_ID

EPJ Standard Side 21 11.2.5 EPJ grunnkomponent Dette er en abstrakt klasse som kun benyttes for å samle de egenskaper som er felles for alle de forskjellige typer innholdskomponenter som inngår i journalen, inkludert Journalroten. Klassen inneholder to kun to attributter, journal ID (EKO_EPJID og EPJ komponent ID (EKO_ID). Disse arves videre til de to spesialiseringene av EPJ grunnkomponent, Journalrot og EPJ komponent. Merk at pasienten ikke er identifisert verken i Journalinnhold, EPJ grunnkomponent eller noen av spesialiseringene av denne. Dette legger forholdene til rette for at det skal være lett å gi tilgang til journalinformasjon til formål hvor identifisering av pasienten ikke er nødvendig. 11.2.5.1 Journalrot (JOURNROT) Denne klassen benyttes for å knytte sammen de enkelte innholdskomponentene, d.v.s. alle spesialiseringene av EPJ komponent, til journaler. Merk at pasienten ikke er identifisert verken i journalroten eller i EPJ komponent. Dette legger forholdene til rette for at det skal være mulig å gi tilgang til journalinformasjon til formål hvor identifisering av pasienten ikke er nødvendig. For å være kompatibel med den europeiske prestandarden ENV13606 på dette området, tillates det at det kan inngå mer enn en Journalrot i samme EPJ. Det normale vil imidlertid være at det er kun en Journalrot i en EPJ. journal ID O x 9(10) EKO_EPJID Unik referanse til journalen. (Arvet fra den abstrakte klassen EPJ grunnkomponent.) Utgjør sammen med "EPJ komponent ID" en unik nøkkel for denne klassen. EPJ komponent ID O x 9(10) EKO_ID Unik identifikasjon av komponenten innen journalen. (Arvet fra den abstrakte klassen EPJ grunnkomponent.) Utgjør sammen med "journal ID" en unik nøkkel for denne klassen. For denne klassen benyttes kortnavnet JOURNROT. Unik nøkkel: EKO_EPJID

EPJark 2: Arkitektur, arkivering og sikkerhet Side 22 Tekniske spesifikasjoner 11.2.5.2 Revisjonsinfo (EREVINFO) Denne klassen benyttes for å bevare informasjon om når endringer i journalen blir gjort, hvem som har utført endringene og hvilken tjenesteutførelse endringene er knyttet oppmot. Merk: Ved enhver endring i en EPJ skal det legges til en ny instans i Revisjonsinfo. Denne skal inneholde informasjon om tidspunkt for endringen, hvem som foretok endringen og hvilken Tjenesteytelse endringen er relatert til. Dersom det ved samme anledning blir foretatt flere endringer som blir gjort tilgjengelig samtidig for de øvrige brukerne av den aktuelle EPJ, bør alle disse endringene knyttes opp mot samme instans av Revisjonsinfo. Se for øvrig beskrivelsen av EPJ komponent og Komponent hendelse for mer detaljer om hvordan endringer i innholdskomponenter skal håndteres. journal ID O x 9(10) ERE_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. revisjonsnummer O x 9(10) ERE_REVNR Unik identifikasjon av en revisjon innenfor en journal. Starter med 1 og telles opp i steg på 1. Sortering på revisjonsnummer vil gi en ren, kronologisk rekkefølge. revisjonstidspunkt O x tidspkt ERE_TID Skal inneholde det tidspunktet hvor den/de endringer som er gjort under revisjonen, blir gjort tilgjengelig for andre enn den som gjør registreringen (registrert av), eller, dersom registreringen ikke blir gjort umiddelbart tilgjengelig for andre, det tidspunktet registreringen avsluttes. registrert av person ID O x 9(10) ERE_PERID Unik referanse innenfor journalsystemet til den Person (NB: Ikke tjenesteyter), som utførte registreringen. Dette er ikke nødvendigvis den samme som er ansvarlig for den informasjon som ble registrert. relatert til tjenesteutførelse O x 9(10) ERE_TUTID Unik referanse innenfor journalsystemet til den Tjenesteutførelse registreringen er en del av. Denne identifiserer både den Tjenesteyter som er ansvarlig for registreringen og det Besluttede tiltak som ligger til grunn.

EPJ Standard Side 23 revisjonstype A x 9(10) ERE_REVTYPE Angir hvilken type revisjon dette gjelder. merknad A X(255) ERE_MERKNAD Til fri bruk. For denne klassen benyttes kortnavnet EREVINFO. Unik nøkkel: ERE_EPJID, ERE_REVNR De forskjellige typer revisjoner for EPJ defineres i et eget, felles kodeverk med kodeverk ID = 9003. Dette attributtet skal inneholder kodenode ID til den relevante revisjonstype.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 24 Tekniske spesifikasjoner 11.2.6 EPJ link (EPJLINK) Denne klassen benyttes for å opprette forskjellige former for referanser mellom komponenter i journalen. link ID O1 x 9(10) ELN_ID Unik ID som identifiserer denne linken innenfor EPJ-systemet. link fra journal O1 x 9(10) ELN_FRAEPJID Unik referanse til journalen linken går fra. link fra komponent O1 x 9(10) ELN_FRAKOMPID Unik referanse til komponenten (innen journalen) linken går fra. link til journal O1 x 9(10) ELN_TILEPJID Unik referanse til journalen linken går til. link til komponent O1 x 9(10) ELN_TILKOMPID Unik referanse til komponenten (innen journalen) linken går til. toveis link O1 x X(1) ELN_TOVEIS Verdi 1 dersom denne linken skal være tilgjengelig fra begge komponentene, verdi 0 dersom den bare skal være tilgjengelig fra "fra-komponenten". linktype O1 x 9(10) ELN_LINKTYPE Attributtet benyttes for å angi hvilken type link dette gjelder. merknad A X(255) ELN_MERKNAD Til fri bruk. Linktyper defineres i et eget, felles kodeverk med kodeverk ID = 9012. Dette attributtet skal inneholder kodenode ID til den relevante linktype. registrert ved revisjon O1 x 9(10) ELN_FRAREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne linken ble registrert. slettet ved revisjon O1 9(10) ELN_TILREV Dersom bruken av linken skal opphøre, skal attributtet inneholde "revisjon ID" til den revisjon av EPJ, hvor dette skjedde. For denne klassen benyttes kortnavnet EPJLINK. Unik nøkkel: ELN_ID

EPJ Standard Side 25

EPJark 2: Arkitektur, arkivering og sikkerhet Side 26 Tekniske spesifikasjoner 11.2.7 Felles egenskaper ved komponenter Journalinnhold EPJ grunnkomponent 0..1 EPJ link 0..* 1..* Journalrot Varsling 0..* EPJ komponent 1..* Komponent hendelse Signalinformasjon 0..* 0..* Informasjonskilde Informasjonskategori 0..* 0..* Ekspedert til Formål med registrering 0..* 0..* Ekstern referanse Figur 2. Klassediagram som viser felles egenskaper ved komponenter 11.2.7.1 EPJ komponent Dette er en abstrakt klasse som kun benyttes for å samle de egenskaper som er felles for de forskjellige typer innholdskomponenter som inngår i journalen, med unntak av Journalroten. Klassen er en spesialisering av den abstrakte klassen EPJ grunnkomponent. Klassen inneholder to kun tre attributter, "journal ID" (EKO_EPJID), "EPJ komponent ID" (EKO_ID) og "gyldig" (EKO_GYLDIG). De to første er arvet fra EPJ grunnkomponent og alle tre arves videre til spesialiseringene av EPJ komponent. I tillegg arves assosiasjoner med en rekke andre klasser, disse beskrives i det etterfølgende.

EPJ Standard Side 27 Revisjonshåndtering Ved enhver endring av en EPJ komponent skal det legges inn en Komponent hendelse som beskriver hvilken type endring det gjelder og som knytter hendelsen opp til en instans av Revisjonsinfo hvor det finnes informasjon om hvem som foretok endringen og når den skjedde. Dersom en endring innebærer at en EPJ komponent blir erstattet av en annen, skal det også registreres en instans av EPJ link med en linktype som angir at den ene komponenten blir erstattet av den andre. Merk at endringen kun skal registreres på det nivå den skjer, slik at det ikke skal registreres nye revisjoner av de komponenter som inneholder en komponent som har blitt endret. Dersom for eksempel et EPJ fragment må endres sli at det må erstattes av et nytt EPJ fragment, så skal det på den opprinnelige versjonen av fragmentet registreres en EPJ hendelse som angir at fragmentet er erstattet av et nytt, mens det på den korrigerte versjonen av fragmentet skal registreres en hendelse som angir at det erstatter en utgått komponent. Det skal altså ikke eksplisitt registreres noen ny revisjon av for eksempel et EPJ dokument som det endrede fragmentet inngår i. Det krav som stilles i del I av denne standarden om at det skal være mulig å se journalen slik den var på et bestemt tidspunkt, er ment å skulle kunne realiseres ved at alle komponenter, komponent hendelser mv. som er registrert etter det aktuelle tidspunktet, utelates ved framvising av journalen. 11.2.7.2 Formål med registrering (FORMEDREG) Denne klassen benyttes til å angi til hvilke formål som de enkelte registreringer i journalen kan benyttes. Dersom formål ikke er angitt eksplitt, skal "fars" formål arves ved registrering. Dersom det registreres nye formål eller allerede eksisterende formål slettes, skal det gis mulighet for å la endringen gjelde også for "barna". journal ID O x 9(10) EFO_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. Utgjør sammen med "EPJ komponent ID", "formål" og "gyldig fra revisjon" en unik nøkkel for denne klassen. EPJ komponent ID O x 9(10) EFO_EKOID Unik referanse til den aktuelle komponenten innenfor journalen. Utgjør sammen med "journal ID", "formål" og "gyldig fra revisjon" en unik nøkkel for denne klassen.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 28 Tekniske spesifikasjoner registrert ved revisjon O x 9(10) EFO_FRAREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne registreringen ble gjort. Utgjør sammen med "EPJ komponent ID", "formål" og "journal ID" en unik nøkkel for denne klassen. slettet ved revisjon O 9(10) EFO_TILREV Dersom bruken av et registrert formål skal opphøre, skal attributtet inneholde "revisjon ID" til den revisjon av EPJ, hvor dette skjedde. formål O x 9(10) EFO_TYPE Angir hva som er formålet med den registrerte informasjonen. Utgjør sammen med "EPJ komponent ID", "journal ID" og "gyldig fra revisjon" en unik nøkkel for denne klassen. Formål defineres i et eget, felles kodeverk med kodeverk ID = 9004. Dette attributtet skal inneholder kodenode ID til det relevante formål. ulovlig formål A x X(1) EFO_ULOVFOR Verdi 1 dersom denne komponenten ikke tillates benyttet til det angitte formål, 0 hvis den tillates benyttet. For denne klassen benyttes kortnavnet FORMEDREG. Unik nøkkel: EFO_EPJID, EFO_EKOID, EFO_TYPE, EFO_FRAREV

EPJ Standard Side 29 11.2.7.3 Informasjonskategori (INFOKAT) Denne klassen benyttes til å angi til hvilken kategori informasjon innholdet i de enkelte registreringer tilhører. Dersom informasjonskategori ikke er angitt eksplitt, skal "fars" informasjonskategori arves ved registrering. Dersom det registreres nye informasjonskategorier eller allerede eksisterende informasjonskategorier slettes, skal det gis mulighet for å la endringen gjelde også for "barna". journal ID O x 9(10) EIK_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. Utgjør sammen med "EPJ komponent ID", "kategori" og "gyldig fra revisjon" en unik nøkkel for denne klassen. EPJ komponent ID O x 9(10) EIK_EKOID Unik referanse til den aktuelle komponenten innenfor journalen. Utgjør sammen med "journal ID", "kategori" og "gyldig fra revisjon" en unik nøkkel for denne klassen. registrert ved revisjon O x 9(10) EIK_FRAREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne registreringen ble gjort. Utgjør sammen med "EPJ komponent ID", "kategori" og "journal ID" en unik nøkkel for denne klassen. slettet ved revisjon O 9(10) EIK_TILREV Dersom bruken av et registrert formål skal opphøre, skal attributtet inneholde "revisjon ID" til den revisjon av EPJ, hvor dette skjedde. kategori O x 9(10) EIK_KAT Angir hvilken kategori den informasjonen som utgjør komponentens innhold, tilhører. Utgjør sammen med "EPJ komponent ID", "journal ID" og "gyldig fra revisjon" en unik nøkkel for denne klassen. Informasjonskategori defineres i et eget, felles kodeverk med kodeverk ID = 9005. Dette attributtet skal inneholder kodenode ID til den relevante informasjonskategori.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 30 Tekniske spesifikasjoner For denne klassen benyttes kortnavnet INFOKAT. Unik nøkkel: EIK_EPJID, EIK_EKOID, EIK_KAT, EIK_FRAREV

EPJ Standard Side 31 11.2.7.4 Signalinformasjon (SIGNALINFO) Denne klassen benyttes for å kunne merke komponenter i journalen som skal fremheves for forskjellige formål, slik som f.eks.: - Cave (medikamentallergi, matallergi etc.) - Varselinformasjon (se egne beskrivelse av klassen Varselinformasjon) - Informasjon som skal inngå i "kurven". journal ID O2 x 9(10) ESI_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. Utgjør sammen med "EPJ komponent ID", "signalkategori" og "registrert ved revisjon" en unik nøkkel for denne klassen. EPJ komponent ID O2 x 9(10) ESI_EKOID Unik referanse til den aktuelle komponenten innenfor journalen. Utgjør sammen med "journal ID", "signalkategori" og "gyldig fra revisjon" en unik nøkkel for denne klassen. registrert ved revisjon O2 x 9(10) ESI_FRAREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne registreringen ble gjort. Utgjør sammen med "EPJ komponent ID", "signalkategori" og "journal ID" en unik nøkkel for denne klassen. slettet ved revisjon O2 9(10) ESI_TILREV Dersom komponenten ikke lengre skal være merket med denne signalkategorien, skal attributtet inneholde "revisjon ID" til den revisjon av EPJ, hvor registrering av dette skjedde.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 32 Tekniske spesifikasjoner signalkategori O2 x 9(10) ESI_SIGNKAT Angir hvilken signalkategori innhold den registrerte informasjonen tilhører. Utgjør sammen med "EPJ komponent ID", "journal ID" og "registrert ved revisjon" en unik nøkkel for denne klassen. Signalkategorier defineres i et eget, felles kodeverk med kodeverk ID = 9006. Dette attributtet skal inneholder kodenode ID til det relevante signalkategori. gyldig til A tidspkt ESI_GYLTIL Dersom det allerede ved registrering er klart at det kun er i et begrenset tidsrom det er nødvendig å markere komponenten med en signalkategori, kan dette tidspunktet registreres her. For denne klassen benyttes kortnavnet SIGNALINFO. Unik nøkkel: ESI_EPJID, ESI_EKOID, ESI_KAT, ESI_FRAREV

EPJ Standard Side 33 11.2.7.5 Varselinformasjon (VARSELLINFO) Denne klassen benyttes for å kunne knytte varsel om tidsfrister mv. til komponenter i journalen. I motsetning til registrert Signalinformasjon som alltid skal hentes fram i forbindelse med tilknyttede tiltak, skal registrert Varsling kun hentes fram når angitte tidsfristene er passert, og varslingen skal opphøre når det er registrert at den oppgave el. som varslet gjelder er fullført. journal ID A x 9(10) EVI_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. Utgjør sammen med "EPJ komponent ID", "signalkategori" og "registrert ved revisjon" en unik nøkkel for denne klassen. EPJ komponent ID A x 9(10) EVI_EKOID Unik referanse til den aktuelle komponenten innenfor journalen. Utgjør sammen med "journal ID", "signalkategori" og "registrert ved revisjon" en unik nøkkel for denne klassen. registrert ved revisjon A x 9(10) EVI_FRAREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne registreringen ble gjort. Utgjør sammen med "EPJ komponent ID", "signalkategori" og "journal ID" en unik nøkkel for denne klassen. slettet ved revisjon A 9(10) EVI_TILREV Dersom dette varselet om tidsfrist e.l., ikke lengre skal være tilknyttet komponenten, skal attributtet inneholde "revisjon ID" til den revisjon av EPJ, hvor registrering av dette skjedde. signalkategori A x 9(10) EVI_SIGNKAT Angir hvilken signalkategori innhold den registrerte varselinformasjonen tilhører. Utgjør sammen med "EPJ komponent ID", "journal ID" og "gyldig fra revisjon" en unik nøkkel for denne klassen. Signalkategorier defineres i et eget, felles kodeverk med kodeverk ID = 9006. Dette attributtet skal inneholder kodenode ID til det relevante signalkategori.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 34 Tekniske spesifikasjoner varseltidspunkt A x tidspkt EVI_FRIST Det tidspunkt som varselet skal gis på. forvarsel A tidspkt EVI_FORVAR Dersom det skal gis et forvarsel før den endelige fristen går ut, kan tidspunkt for dette registreres her. varselmelding A X(255) EVI_MELDING Tekst som skal inngå i meldinger mv. som skal vises eller skrives ut, når varsel skal gis, f.eks. om at tidsfristen er passert. gjennomført ved revisjon A 9(10) EVI_OK Når den oppgave el. som varslet gjelder er fullført, kvitteres det for dette ved å registrere "revisjon ID" til den revisjon av EPJ, hvor registrering av dette skjedde, i dette attributtet. All varsling skal deretter opphøre. For denne klassen benyttes kortnavnet VARSELINFO. Unik nøkkel: EVI_EPJID, EVI_EKOID, EVI_ESIKAT, EVI_FRAREV

EPJ Standard Side 35 11.2.7.6 Informasjonskilde (INFOKILDE) Dersom kilde til informasjonen er en annen enn den som er ansvarlig for registreringen, kan dette registreres her. Dette gjelder også dersom kommer fra medisinsk teknisk utstyr eller det er benyttet en spesiell programvare for å komme fram til informasjonen. Informasjonskilde ID O2 x 9(10) EIK_ID Unik ID som identifiserer denne registreringen av informasjonskilde innenfor virksomheten. journal ID O2 x 9(10) EKI_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. EPJ komponent ID O2 x 9(10) EKI_EKOID Unik referanse til den aktuelle komponenten innenfor journalen. registrert ved revisjon O2 x 9(10) EKI_FRAREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne registreringen ble gjort. slettet ved revisjon O2 9(10) EKI_TILREV Dersom informasjonskilden ikke lengre skal være knyttet til komponenten, skal attributtet inneholde "revisjon ID" til den revisjon av EPJ, hvor dette skjedde. rolle til informasjonskilde A X(255) EKI_IKROLLE Attributtet benyttes for å angi hvilken rolle informasjonskilden har i forhold til pasienten. f.eks. at vedkommende er pasientens nabo. virksomhet O2 9(10) EKI_ORGID Dersom kilden til informasjonen er en virksomhet eller annen form for organisatorisk enhet, kan referanse til denne registreres her. person O2 9(10) EKI_PERID Dersom kilden til informasjonen er en person, kan referanse til vedkommende registreres her.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 36 Tekniske spesifikasjoner medisinsk teknisk utstyr A 9(10) EKI_DMTID Dersom informasjonen kommer fra medisinsk teknisk utstyr, kan referanse til dette registreres her. programvare A 9(10) EKI_DPRID Dersom informasjonen er utarbeidet ved hjelp av spesiell programvare, kan referanse til denne registreres her. For denne klassen benyttes kortnavnet INFOKILDE. Unik nøkkel: EKI_ID

EPJ Standard Side 37 11.2.7.7 Ekspedert til (EKSPTIL) Dersom informasjon i journalen sendes til andre virksomheter eller personer, i eller utenfor helsevesenet, benyttes denne klassen til å registrere informasjon om dette. ekspedering ID O2 x 9(10) EKS_ID Unik ID som identifiserer denne registreringen av ekspedering innenfor virksomheten. journal ID O2 x 9(10) EKS_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. EPJ komponent ID O2 x 9(10) EKS_EKOID Unik referanse til den aktuelle komponenten innenfor journalen. registrert ved revisjon O2 x 9(10) EKS_FRAREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor ekspederingen ble registrert. slettet ved revisjon O2 9(10) EKS_TILREV Dersom registreringen skal slettes på grunn av feilregistrering eller av andre årsaker, skal attributtet inneholde "revisjon ID" til den revisjon av EPJ, hvor dette skjedde. ekspedert tidspunkt O2 tidspkt EKS_TID Tidspunkt for ekspedering. Angis dersom dette er signifikant forskjellig fra registreringstidspunktet. ekspedert til virksomhet ID O2 b 9(10) EKS_ORGID Dersom informasjonen er sendt til en virksomhet eller annen form for organisatorisk enhet, skal referanse til denne registreres her. Minst et av attributtene "ekspedert til virksomhet ID" og "ekspedert til person ID" må ha innhold.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 38 Tekniske spesifikasjoner ekspedert til person ID O2 b 9(10) EKS_PERID Dersom informasjonen er sendt til en person, skal referanse til vedkommende registreres her. Attributtet kan også benyttes til å registrere referanse til kontaktperson innenfor angitt virksomhet. Minst et av attributtene "ekspedert til virksomhet ID" og "ekspedert til person ID" må ha innhold. formål med ekspedering A 9(10) EKS_FORM Attributtet benyttes for å angi hva som er formålet med ekspederingen, f.eks. melding til offentlig myndighet, henvisning e.l. Formål med ekspedering defineres i et eget, felles kodeverk med kodeverk ID = 9008. Dette attributtet skal inneholder kodenode ID til det relevante formål. forsendelsesmåte A 9(10) EKS_FORSEND Attributtet benyttes for å angi hvordan informasjonen ble ekspedert, f.eks. med brev, faks, e-post etc. Forsendelsesmåter defineres i et eget, felles kodeverk med kodeverk ID = 9009. Dette attributtet skal inneholder kodenode ID til det relevante forsendelsesmåte. svar påkrevd A X(1) EKS_SVAR Verdi 1 dersom det kreves eller forventes et svar som følge av ekspederingen, verdi 0 ellers. svarfrist A tidspkt EKS_SVARFRIST Dersom det er satt en first for å svare, kan dette angis her. Kan eventuelt også benyttes for å angi når svar er ventet, selv om tidspunktet ikke utgjør noen absolutt frist. For denne klassen benyttes kortnavnet EKSPTIL. Unik nøkkel: EKS_ID

EPJ Standard Side 39 11.2.7.8 Ekstern referanse (EKSTERNREF) Ofte bidrar flere virksomheter innenfor helsevesenet til å yte pasienten helsehjelp knyttet til samme problem, eller problemkompleks. Det kan da være nyttig å kunne opprette referanser mellom relevante sakene i de journaler som pasienten har hos de forskjellige virksomheter som bidrar til helsehjelpen. Denne klassen benyttes til dette. ekstern referanse ID A x 9(10) ERF_ID Unik ID som identifiserer denne registreringen av ekstern referanse innenfor EPJ-systemet. journal ID A x 9(10) ERF_EPJID Unik referanse som identifiserer journalen som komponenten er importert til, innenfor journalsystemet. EPJ komponent ID A x 9(10) ERF_EKOID Unik referanse til den aktuelle komponenten innenfor denne journalen. registrert ved revisjon A x 9(10) ERF_FRAREV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor den eksterne referansen ble registrert. slettet ved revisjon A 9(10) ERF_TILREV Dersom registreringen skal slettes på grunn av feilregistrering eller av andre årsaker, skal attributtet inneholde "revisjon ID" til den revisjon av EPJ, hvor dette skjedde. ekstern journal ID A 9(10) ERF_EKSTEPJID Referanse til den journal, representert ved en registrering i klassen EPJ, som denne komponenten er importert fra. Gjennom denne registreringen kan den virksomheten hvor komponenten opprinnelig ble registret, identifiseres.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 40 Tekniske spesifikasjoner ekstern komponent ID A 9(10) ERF_EKSTEKOID Unik referanse til den aktuelle komponenten innenfor den journalen den opprinnelig ble registrert i. Merk: Ved senere utvidelser kan det bli aktuelt å åpne for at komponenter av typene EPJ Sak og EPJ dokument registrert i journaler om samme pasient i andre virksomheter, kan bli inkludert uten at innholdet kopieres. Standarden må da utvides med nye spesialiseringer av EPJ Komponent som den importerte komponenten plasseres under. formål med referanse A 9(10) ERF_FORM Attributtet benyttes for å angi hva som er formålet med referansen. Formål med referanse defineres i et eget, felles kodeverk med kodeverk ID = 9010. Dette attributtet skal inneholder kodenode ID til det relevante formål. merknad A X(255) ERF_MERKNAD Benyttes f.eks. for å beskrive referansen og formålet med denne. For denne klassen benyttes kortnavnet EKSTERNREF. Unik nøkkel: ERF_ID

EPJ Standard Side 41 11.2.7.9 Komponent hendelse (KOMPHENDE) Denne klassen benyttes for å registrere alle former for hendelser knyttet til de enkelte komponentene. Med hendelse menes her registrering, godkjenning, korrigering etc. Komponent hendelse utgjør forbindelsen mellom komponenten og revisjoner av komponenten. komponent hendelse ID A x 9(10) ERH_ID Unik ID som identifiserer denne registreringen av komponent hendelse innenfor EPJ-systemet. journal ID O x 9(10) EKH_EPJID Unik referanse som identifiserer journalen innenfor journalsystemet. EPJ komponent ID O x 9(10) EKH_EKOID Unik referanse til den aktuelle komponenten innenfor journalen. registrert ved revisjon O x 9(10) EKH_REV Attributtet skal inneholde "revisjon ID" til den revisjon av EPJ hvor denne registreringen ble gjort. kodeverk for komponent hendelse O x 9(10) EKH_KODEVERK Attributtet benyttes for å angi hvilket kodeverk som skal benyttes for å angi komponent hendelser. Standardverdi skal være 9011, men skal kan endres. tidspunkt for hendelse O tidspkt EKH_TIDSPKT Benyttes dersom det tidspunkt hendelsen "inntraff" er signifikant forskjellig fra registreringstidspunktet. Kan f.eks. benyttes for å angi det tidspunkt informasjonen oppsto, dersom den ble registrert på et senere tidspunkt.

EPJark 2: Arkitektur, arkivering og sikkerhet Side 42 Tekniske spesifikasjoner komponent hendelse O x 9(10) EKH_HENDELSE Attributtet benyttes for å angi hvilken hendelse registreringen gjelder. Komponent hendelser defineres i det kodeverket som er angitt i attributtet "kodeverk for komponent hendelse". Dette attributtet skal inneholder kodenode ID til den relevante hendelsen. Eksempler på slike hendelser kan være: registrering påbegynt registrering avsluttet registrering ikke godkjent godkjent av ansvarlig tjenesteyter godkjent av stedfortreder godkjenning opphevet erstattet av ny komponent (identifisert gjennom EPJ link) erstatter utgått komponent (identifisert gjennom EPJ link) mottatt elektronisk fra annen virksomhet delkomponent slettet utgår uten erstatningskomponent signert av person ID O2 9(10) EKH_SIGNAV Dersom den aktuelle hendelsen innebærer at komponenten har blitt signert, skal dette attributtet inneholde referanse til den Person som har signert komponenten. elektronisk signatur O2 binær EKH_ELSIGN <Det er ikke avklart ennå hvilke krav som vil bli satt til elektronisk signatur. Beskrivelsen av dette attributtet utstår derfor inntil videre.> For denne klassen benyttes kortnavnet KOMPHENDE. Unik nøkkel: ERH_ID

EPJ Standard Side 43 11.3 Komponenttyper EPJ 1 Journalinnhold 1 1..* Journalrot EPJ grunnkomponent 0..1 0..* EPJ komponent EPJ link 0..* EPJ sak 1 0..1 0..* Importert komponent EPJ basisdokument 0..* 1 EPJ dokumenttype 0..1 0..* 1 EPJ sakstype 0..1 0..* 0..* EPJ saksstruktur 0..* 0..1 1..* 0..* 0..1 0..* Saksinnhold 1..* 0..* 0..1 EPJ dokument 0..1 0..1 1..* 0..* EPJ dokumentinnhold EPJ Dokumentstruktur 0..* 0..* 1 1 0..* EPJ sakshode EPJ fragment EPJ fragmenttype 1 1 0..* 0..* 0..* Avsnittsinformasjon EPJ dataelement EPJ fragmentstruktur 0..* Fragmentreferanse 0..* 0..* 1 1 EPJ dataelement type Figur 3. Komponenttyper og sammenhengen mellom disse

EPJark 2: Arkitektur, arkivering og sikkerhet Side 44 Tekniske spesifikasjoner 11.3.1 EPJ sak (EPJSAK) Denne klassen inneholder attributter som benyttes som "toppnode" for de saker som inngår i journalen. Sakene beskrives gjennom fragmentene som inngår i sakshodet. journal ID O x 9(10) EKO_EPJID Unik referanse til journalen. (Arvet fra den abstrakte klassen EPJ komponent.) Utgjør sammen med "EPJ komponent ID" en unik nøkkel for denne klassen. EPJ komponent ID O x 9(10) EKO_ID Unik identifikasjon av saks-komponenten innen journalen. (Arvet fra den abstrakte klassen EPJ komponent.) Utgjør sammen med "journal ID" en unik nøkkel for denne klassen. gyldig O x X(1) EKO_GYLDIG Verdi 1 dersom innholdet av denne komponenten er gyldig, dvs. ikke erstattet av en annen komponent e.l. Verdi 0 ellers. Attributtet skal oppdateres automatisk på grunnlag av de Komponent hendelser som er knyttet til komponenten. (Arvet fra den abstrakte klassen EPJ komponent.) lukket O x X(1) EPS_LUKKET Verdi 1 dersom saken er lukket for videre registrering, verdi 0 dersom den fortsatt er åpen for registrering. Attributtet oppdateres på grunnlag av endringer i Komponent hendelser tilknyttet saken. EPJ sakstype ID O x 9(10) EPS_ESTID Unik referanse til den Sakstype som beskriver de generelle egenskapene til saken. For denne klassen benyttes kortnavnet EPJSAK. Unik nøkkel: EKO_EPJID, EKO_ID

EPJ Standard Side 45 11.3.1.1 Sakstype (EPJSAKSTYPE) Denne klassen inneholder attributter som er felles for alle saker av en bestemt type, uavhengig av hvilken journal sakene inngår i. Merk: Med unntak av at det kan tas med nye dokumenttyper, sakstyper eller signalkategorier som lovlig innhold i saken, skal ikke egenskapene til en sakstype som er tatt i bruk for en eller flere saker, kunne endres av noen, heller ikke systemansvarlig. EPJ sakstype ID O x 9(10) EST_ID Unik ID som identifiserer denne sakstypen innenfor EPJ-systemet. standard sakstype O 9(10) EST_SSTYPE Standard sakstyper som skal kunne benyttes på tvers av virksomheter i helsevesenet, defineres i et eget, felles kodeverk med kodeverk ID = 9013. Attributtet skal kun benyttes dersom det er fullt samsvar mellom den "lokale" sakstypen og den standardiserte sakstypen. betegnelse O X(70) EST_BETEG Den betegnelse som benyttes for denne sakstypen. gyldig fra A x 9(10) EST_GYLDFRA Attributtet skal inneholde "registrering ID" tilhørende en instans av Registreringsinfo som identifiserer tidspunkt for registrering av denne sakstypen, hvem som foretok registreringen og det tidspunkt hvor denne sakstypen ble godkjent for bruk innenfor virksomheten. gyldig til A 9(10) EST_GYLDTIL Attributtet skal inneholde "registrering ID" tilhørende en instans av Registreringsinfo som identifiserer tidspunkt for registrering, hvem som foretok registreringen og det tidspunkt denne sakstypen ikke lengere skal kunne benyttes ved opprettelse av nye saker.