Arkitektur, arkivering og tilgangsstyring

Størrelse: px
Begynne med side:

Download "Arkitektur, arkivering og tilgangsstyring"

Transkript

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

2 Side 2 EPJ Standard 2001 KITH

3 EPJ Standard Side 3

4 Side 4 EPJ Standard Innhold INNLEDNING DEL II KLASSER OG ATTRIBUTTER Innledning Forkortelser mv Kort om klassediagrammene Grunnleggende arkitektur EPJ Journalinnhold (EPJINNH) Journalansvar (EPJANSVAR) Journal hendelse (EPJHENDELSE) EPJ grunnkomponent Journalrot (JOURNROT) Revisjonsinfo (EREVINFO) EPJ link (EPJLINK) Felles egenskaper ved komponenter EPJ komponent Formål med registrering (FORMEDREG) Informasjonskategori (INFOKAT) Signalinformasjon (SIGNALINFO) Varselinformasjon (VARSELLINFO) Informasjonskilde (INFOKILDE) Ekspedert til (EKSPTIL) Ekstern referanse (EKSTERNREF) Komponent hendelse (KOMPHENDE) Komponenttyper EPJ sak (EPJSAK) Sakstype (EPJSAKSTYPE) EPJ saksstruktur (EPJSAKSTRUK) EPJ Sakshode (EPJSAKSHODE) Saksinnhold (EPJSAKSIH) Importert komponent (IMPORTKOMP) EPJ dokument (EPJDOKUMENT) Dokumenttype (EPJDOKTYPE) EPJ dokumentstruktur (EPJDOKSTRUK) KITH

5 EPJ Standard Side Dokumentinnhold (EPJDOKIH) EPJ fragment (EPJFRAG) EPJ fragmenttype (EPJFRAGTYPE) Avsnittsinformasjon (EPJAVSNINFO) Fragmentstruktur (EPJFRAGSTRU) Dataelementer EPJ dataelement EPJ dataelement type (EPJDETYPE) Kodeverk dataelement (EPJKVDE) Alfanumerisk element (EPJDEALFA) Numerisk element (EPJDETALL) Fri tekst (EPJDETEKST) Tidsangivelse (EPJDEDATOKL) Kodet verdi (EPJDEKODE) Boolsk verdi (EPJDEBOOLSK) Enhetsreferanse (EPJDEORG) Personreferanse (EPJDEPERSON) Adressereferanse (EPJDEADR) Dataansamling (EPJDEDATAMS) Ikke-elektronisk element (EPJDEIKEL) Fragmentreferanse (EPJDEFRAG) Utstyrsreferanse (EPJDEMTUT) Programvarereferanse (EPJDPROG) Tjenesteyterreferanse (EPJDETJYTER) Tjenesteutførelsereferanse (EPJDETJUTF) Tiltaksreferanse (EPJDETJUTF) Tilgangsstyring Roller, tjenesteutførelse og tiltak Tjenesteyter (TJENYTER) Opptredener (OPPTRED) På vegne av (PVEGNEAV) Rolle (ROLLE) Rolle - enhet (ROLLENHET) Rollemal (ROLLEMAL) Rolle - tiltak (ROLLETILTAK) Tiltaksmal (TILTMAL) Tiltaksmalstruktur (TILTSTRUKT)

6 Side 6 EPJ Standard Formål med tiltak (TILTAKFORM) Informasjonsbehov (INFOBEHOV) Kan kun utføres ved enhet (TILTKANUT) Varslingsregler (VARSELTJENUT) Tiltaksautorisasjon (TILTAUTORI) Tilgang til hjelperegister (TILGHJELPREG) Tilgang til kodeverk (TILGKODEV) Tilgang til funksjon (TILGFUNK) Tilgang til autorisering (TILGAUTOR) Tilgang til pseudonymformål (TILGPSEUDO) Tjenesteutførelse (TJENUTF) Besluttet tiltak (BESLUTILT) Informasjon om sletting (INFOSLETT) Tiltaksavhengighet (TILTAVH) Kan kun utføres av (KANUTFAV) Særskilt varsling (SVARSL) Tilgang til komponent (TILTKOMP) Utføres ved enhet (UTFENHET) Registreringsinfo (REGINFO) Samtykke Samtykke (EPJSAMTYKKE) Samtykke til tjenesteutførelse (EPJSAMTUT) Representant for pasient (PASIENTREPR) Samtykkekrav (EPJSAMTKRAV) Samtykkekrav gjelder (SAMTILKOMP) Unntak fra krav om samtykke (UNTSAMTYK) Kodeverk og klassifikasjonssystemer Hovedstruktur for kodeverk Kodeverk (KVERK) Kodeverknode (KVNODE) Kodeverksstruktur (KVSTRUKT) Kodeverkelement (KVELEMENT) Kodeverkrevisjon (KVREV) Koblinger mellom kodeverk Kodelink (KVLINK) Anvendt Kodeverkelement (KVANVEND) Termer, begrep og definisjoner Term (KVTERM) KITH

7 EPJ Standard Side Element-Term (KVELEMTERM) Termlink (KVTERMLINK) Begrep (KVBEGREP) Definisjon av begrep (KVDEF) Tilleggsinformasjon for kodeverk Kodenodeinformasjon (KVNINFO) Kodenodeinformasjon link (KVNINFOLINK) Kodeformat (KVKFORMAT) Personrelatert informasjon Person (EPJPERSON) Persondata (EPJPERDATA) Personnavn (EPJPERNAVN) Personnavnkomponent (EPJPNAKOMP) Sekundær person ID (EPJSEKPID) Hjemstavn (EPJHJEMST) Pasient (EPJPASIENT) Pårørende (EPJSLEKT) Rolle i forhold til pasient (ROLLEPAS) Pseudonym (EPJPSEUDO) Pseudonymformål (EPJPSEUDOFOR) Persons adresse (EPJPERADR) Språkkunnskap (EPJSPRAKUN) Stilling (EPJSTILLING) Yrke og utdanning (EPJYRKE) Organisasjon Organisatorisk enhet (ORGENHET) Organisasjonsstruktur (ORGSTRUKT) Info organisatorisk enhet (ORGINFO) Sekundær enhets-id (SEKORGID) Organisasjonslink (ORGLINK) Virksomhet (VIRKSOMHET) Administrativ enhet (ADMENHET) Enhets adresse (ORGADR) Medisinsk teknisk utstyr og programvare Medisinsk teknisk utstyr (MEDTEKUTSTYR) Utstyrsplassering (MTUTPLASS) Programvare (PROGVARE)

8 Side 8 EPJ Standard Stedsrelatert informasjon Adresse (EPJADRESSE) Stedsadresse (STEDSADR) Nasjon (NASJONINFO) E-post adr (EPOSTADR) Adressekomponent (ADRESSEKOMP) Teleinformasjon (TELEINFO) Adresse i bruk (ADRIBRUK) Arkivering EPJ Arkivinfo (EPJARKINFO) EPJ arkivkomponent (EPJARKOMP) Arkivdokument (EPJARKDOK) Digital signatur (DIGISIGN) Klassifisering (EPJKLASS) Arkiv (ARKIV) Arkivperiode (ARKIVPERIODE) Arkivdel (ARKIVDEL) Ordningsprinsipp (ORDNPRINS) Ordningsverdi (ORDNVERDI) Tilgangskode (TGKODE) Type ordningsprinsipp (ORDNPRINSTYPE) Arkivstatus (ARSTATUS) Lagringsformat (LAGRFORMAT) Lagringsenhet (LAGRENHET) FORMATER FOR EKSPORT Generelt om utveksling og eksportformat Det elektroniske dokumentlageret Dokumentformater Produksjonsformater Arkivformater Godkjente arkivformater Ren tekst - ISO Latin : SGML (Standard Generalized Markup Language) - ISO 8879: TIFF (Tagged Image File Format), versjon 6 - ISO 12639: PDF (Portable Document format) Eksport av dokumenter for avlevering KITH

9 EPJ Standard Side Eksport- og avleveringsformat Informasjon om de eksporterte data Format for eksport av klasseinformasjon Eksport av elektronis ke dokumenter REFERERTE KODEVERK

10 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 KITH

11 EPJ Standard Side 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.

12 Side 12 EPJ Standard 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 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å (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 KITH

13 EPJ Standard Side 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

14 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..* EPJ grunnkomponent 1..* EPJ link * Revisjonsinfo 0..* 1..* Besluttet tiltak 1 0..* 1 Tjenesteutførelse Journalrot 1 0..* EPJ sak EPJ komponent Figur 1. Grunnleggende arkitektur for EPJ

15 EPJ Standard Side 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

16 EPJark 2: Arkitektur, arkivering og sikkerhet Side 16 Tekniske spesifikasjoner 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 = 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 = Dette attributtet skal inneholder kodenode ID til den relevante kategori.

17 EPJ Standard Side 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.

18 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

19 EPJ Standard Side 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 = 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

20 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

21 EPJ Standard Side 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 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

22 EPJark 2: Arkitektur, arkivering og sikkerhet Side 22 Tekniske spesifikasjoner 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.

23 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 = Dette attributtet skal inneholder kodenode ID til den relevante revisjonstype.

24 EPJark 2: Arkitektur, arkivering og sikkerhet Side 24 Tekniske spesifikasjoner 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 = 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

25 EPJ Standard Side 25

26 EPJark 2: Arkitektur, arkivering og sikkerhet Side 26 Tekniske spesifikasjoner 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 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.

27 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 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.

28 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 = 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

29 EPJ Standard Side 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 = Dette attributtet skal inneholder kodenode ID til den relevante informasjonskategori.

30 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

31 EPJ Standard Side 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.

32 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 = 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

33 EPJ Standard Side 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 = Dette attributtet skal inneholder kodenode ID til det relevante signalkategori.

34 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

35 EPJ Standard Side 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.

36 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

37 EPJ Standard Side 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.

38 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 = 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 = 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

39 EPJ Standard Side 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.

40 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 = 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

41 EPJ Standard Side 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.

42 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

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

44 EPJark 2: Arkitektur, arkivering og sikkerhet Side 44 Tekniske spesifikasjoner 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

45 EPJ Standard Side 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 = 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.

Tilleggsopplysninger for saksbehandling i pleie- og omsorgssektoren

Tilleggsopplysninger for saksbehandling i pleie- og omsorgssektoren Tilleggsopplysninger for saksbehandling i pleie- og omsorgssektoren Side av 6 Tilleggsopplysninger for saksbehandling i pleie- og omsorgssektoren Tillegg til Noark-4 KITH-rapport 7/03 Versjon 0.92 KITH

Detaljer

Kravspesifikasjon for elektronisk dokumentasjon av sykepleie

Kravspesifikasjon for elektronisk dokumentasjon av sykepleie Kravspesifikasjon for elektronisk dokumentasjon av sykepleie Del II: Tekniske krav til informasjonsinnhold v. 1.1 KITH Rapport R 13/03 ISBN 82-7846-175-9 KITH 2003 KITH-rapport Tittel Kravspesifikasjon

Detaljer

Journalarkitektur og generelt om journalinnhold

Journalarkitektur og generelt om journalinnhold HIS 80507:2007.. EPJ Standard del 3: Journalarkitektur og generelt om journalinnhold Versjon.6 Opprinnelig dato.2.2008 Sist endret 5.02.202 KITH 2/08:202 Publikasjonens tittel: EPJ Standard del 3: Journalarkitektur

Detaljer

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

K I T H. Cave, Reservasjoner og ønsker, Praktiske forhold mv. EPJ standardisering: KRAVSPESIFIKASJON OG TEKNISK STANDARD K I T H INFORMASJONSTEKNOLOGI FOR HELSE OG VELFERD EPJ standardisering: Cave, Reservasjoner og ønsker, Praktiske forhold mv. KRAVSPESIFIKASJON OG TEKNISK STANDARD VERSJON.0 30 mars 2004 KITH-rapport 42/03

Detaljer

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

K I T H. Ekstern korrespondanse. EPJ standardisering: KRAVSPESIFIKASJON OG TEKNISK STANDARD. VERSJON 1.0 30 mars 2004 KITH-rapport 45/03 K I T H INFORMASJONSTEKNOLOGI FOR HELSE OG VELFERD EPJ standardisering: Ekstern korrespondanse KRAVSPESIFIKASJON OG TEKNISK STANDARD VERSJON 1.0 30 mars 2004 KITH-rapport 45/03 ISBN 82-7846-222-4 KITH-rapport

Detaljer

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

Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten Del II: Tekniske krav til informasjonsinnhold HIS 1104-2:2001 Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten Side 1 av 110.. Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten Del II:

Detaljer

Variabelliste og utkast til informasjonsmodell

Variabelliste og utkast til informasjonsmodell Variabelliste og utkast til informasjonsmodell Dette dokumentet beskriver et utkast til informasjonsmodell for uttrekk av data fra et EPJ-system. Modellen er i stor grad basert på eksisterende EPJ-standarder

Detaljer

Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten

Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten HIS 1104-1:2001.. Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten Versjon 1.6 pprinnelig dato 1.12.2008 Sist endret 15.02.2012 KITH 21/08:2012 Side 2 av 180 Kravspesifikasjon

Detaljer

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

Verktøy for håndtering av Begrepsapparat, Kodeverk og Klassifikasjonssystem for Verktøy for håndtering av Begrepsapparat, Kodeverk og Klassifikasjonssystem Versjon 1.1 KITH Rapport 28/02 ISBN 82-7846-155-4 KITH-rapport TITTEL for: Verktøy for håndtering av Begrepsapparat, Kodeverk

Detaljer

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

Standarder for elektronisk pasientjournal Hvorfor er det behov for slike og hva dekker de? Standarder for elektronisk pasientjournal Hvorfor er det behov for slike og hva dekker de? Torbjørn Nystadnes, KITH DRG-konferansen Clarion hotel Royal Cristiania 27. februar 2008 Innhold 4Litt om KITH

Detaljer

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

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

Detaljer

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

Noark-4, del 1: Endringer i forhold til den trykte utgaven (Kommuneforlaget, 1999) RIKSARKIVAREN 17.08.2005 Noark-4, del 1: Endringer i forhold til den trykte utgaven (Kommuneforlaget, 1999) Endringer pr. 17.08.2005 er markert med blå tekst KAPITTEL 1 1.4.1-4. avsnitt, ff: Kravene innenfor

Detaljer

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

Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten Del II: Tekniske krav til informasjonsinnhold Kravspesifikasjon for elektronisk journal i helsestasjons- og skolehelsetjenesten Del II: Tekniske krav til informasjonsinnhold Versjon 1.0 Statens helsetilsyn KITH Kravspesifikasjon for elektronisk journal

Detaljer

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

K I T H. Dokumentasjon av individuell plan. EPJ standardisering: KRAVSPESIFIKASJON OG TEKNISK STANDARD. VERSJON mars 2004 KITH-rapport 43/03 K I T H INFORMASJONSTEKNOLOGI FOR HELSE OG VELFERD EPJ standardisering: Dokumentasjon av individuell plan KRAVSPESIFIKASJON OG TEKNISK STANDARD VERSJON 1.0 30 mars 2004 KITH-rapport 43/03 ISBN 82-7846-220-8

Detaljer

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

Elektronisk pasientjournal - Hvor står vi og hvor går vi? Elektronisk pasientjournal - Hvor står vi og hvor går vi? Av, KITH MedILog 2005 Hotell Bristol 27. oktober 2005. Innhold Hvor står vi? Utbredelse av EPJ-system Samhandling i omsorgskjeden Standarder for

Detaljer

Person, organisasjon mv

Person, organisasjon mv HIS 80508:2007.. EPJ Standard del 4: Person, organisasjon mv Versjon.6 Opprinnelig dato.2.2008 Sist endret 5.02.202 KITH 2/08:202 Publikasjonens tittel: EPJ Standard del 4: Person, organisasjon mv. Teknisk

Detaljer

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

Om det pågående arbeid med standard for arkivering av EPJ Hva med kommunenes behov? Om det pågående arbeid med standard for arkivering av EPJ Hva med kommunenes behov? Torbjørn Nystadnes Helsedirektoratet, standardiseringsseksjonen KDRS samling - Trondheim 13. november 2013 Innhold Prosjektets

Detaljer

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

EPJ standardisering: Elektronisk dokumentasjonssystem for pleie- og omsorgstjenesten endret KITH 21/08:2012 HIS 8038:2004.. EPJ standardisering: Elektronisk dokumentasjonssystem for pleie- og omsorgstjenesten Versjon.6 Opprinnelig dato Teknisk.2.2008 standard Sist for informasjonsinnhold endret 5.02.202 KITH

Detaljer

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

Forespørsel om fastlege Informasjonsmodell og XML meldingsbeskrivelse HIS 1022:2010 HIS 1022:2010.. Forespørsel om fastlege Informasjonsmodell og XML meldingsbeskrivelse Versjon 1.6 Opprinnelig dato 1.12.2008 Sist endret 15.02.2012 KITH 21/08:2012 Publikasjonens tittel: Forespørsel om

Detaljer

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

HIS 1031:2011. VERSJON 1.1 1. juni 2011 KITH-standard 1031 : 2011 HIS 03:20.. EPJ standard: Tverrfaglig spesialisert behandling av rusmiddelmisbruk Versjon.6 Opprinnelig dato.2.2008 Sist endret 5.02.202 KITH 2/08:202 VERSJON.. juni 20 KITH-standard 03 : 20 Publikasjonens

Detaljer

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

K I T H. Tilleggsopplysninger for saksbehandling i pleie- og omsorgssektoren. Tillegg til Noark-4: TEKNISKE SPESIFIKASJONER K I T H INFORMASJONSTEKNOLOGI FOR HELSE OG VELFERD Tillegg til Noark-4: Tilleggsopplysninger for saksbehandling i pleie- og omsorgssektoren TEKNISKE SPESIFIKASJONER VERSJON.0 2 mars 2004 KITH-rapport 7/03

Detaljer

NOARK Hva? Fra: Wikipedia, den frie encyklopedi

NOARK Hva? Fra: Wikipedia, den frie encyklopedi NOARK Hva? "NOARK (Norsk Arkivstandard) ble opprinnelig utviklet som en kravspesifikasjon for elektroniske journalsystemer i Statsforvaltningen. Den første versjonen NOARK 1 kom i 1984, med påfølgende

Detaljer

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

Høringsutkast til EPJ standard del 2: Tilgangsstyring, redigering, retting og sletting HIS 80506 Høringsutkast 2015 Høringsutkast til EPJ standard del 2: Tilgangsstyring, redigering, retting og sletting Publikasjonens tittel: EPJ standard del 2: Tilgangsstyring, redigering, retting og sletting

Detaljer

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

EPJ standardisering: Generelt journalnotat og Fellesfaglig dokumentasjon Kravspesifikasjon og teknisk standard EPJ standard: Generelt journalnotat og Fellesfaglig dokumentasjon Side av 56.. EPJ standardisering: Generelt journalnotat og Fellesfaglig dokumentasjon Side 2 av 56 EPJ standard: Generelt journalnotat

Detaljer

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

K I T H. Generelt journalnotat og Fellesfaglig dokumentasjon. EPJ standardisering: KRAVSPESIFIKASJON OG TEKNISK STANDARD K I T H INFRMASJNSTEKNLGI FR HELSE G VELFERD EPJ standardisering: Generelt journalnotat og Fellesfaglig dokumentasjon KRAVSPESIFIKASJN G TEKNISK STANDARD VERSJN.0 30 mars 2004 KITH-rapport 44/03 ISBN 82-7846-22-6

Detaljer

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

Uttrekkstandard for elektronisk pasientjournal (EPJ) Torbjørn Nystadnes Helsedirektoratet, Avdeling arkitektur, metode og standardisering Uttrekkstandard for elektronisk pasientjournal (EPJ) Torbjørn Nystadnes Helsedirektoratet, Avdeling arkitektur, metode og standardisering NHA seminar - Gardermoen 6. mars 2014 Innhold Litt om EPJ standarder

Detaljer

Standard: Organisasjonsoppsett

Standard: Organisasjonsoppsett Helse Sør-Øst RHF Teknologi og ehelse/regionale standarder, prosedyrer, brukerveiledninger og opplæring for DIPS/Regionale Standardområder DIPS Standard: Organisasjonsoppsett Utgave: 1.00 Utarbeidet/revidert

Detaljer

Standardisering hvorfor det?

Standardisering hvorfor det? Standardisering hvorfor det? Grete Bach grete.bach@kith.no Seniorrådgiver ekommune 2008 KITH Kompetansesenter for IT i helse- og sosialsektoren KITH AS etablert i 1990 Aksjeselskap, not-for-profit Aksjeeierne

Detaljer

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

Noark-5 hva blir det til? Ståle Prestøy IKA Trøndelag. 23. mai 2007 Noark-5 - hva blir det til? 1 Noark-5 hva blir det til? Ståle Prestøy IKA Trøndelag 23. mai 2007 Noark-5 - hva blir det til? 1 Hvorfor Noark-5? Generell teknologisk utvikling (1998-2006) Flere organ i samme database Sikring av dokumenters

Detaljer