Standard for utveksling av journalopplysninger

Størrelse: px
Begynne med side:

Download "Standard for utveksling av journalopplysninger"

Transkript

1 Standard for utveksling av journalopplysninger Populær presentasjon av CEN ENV KITH Rapport 17/99

2 KITH-rapport Tittel Standard for utveksling av journalopplysninger Populær presentasjon av CEN ENV Forfatter(e) Edgar Glück, Glen Thorsen og Torbjørn Nystadnes (ansvarlig) Oppdragsgiver(e) Sundhedsstyrelsen, Danmark Rapportnummer R 17/99 ISBN URL Dato Antall sider 74 Kvalitetssikret av Grete Bach Kompetansesenter for IT i helsevesenet AS Postadresse Sukkerhuset N-7489 Trondheim Besøksadresse Sverresgt 15, inng G Telefon Telefaks e-post Foretaksnummer Prosjektkode SST-R1 Gradering Godkjent av Kenneth R. Iversen Ass. direktør Sammendrag Denne rapporten inneholder en popularisert framstilling av innholdet i de nylig vedtatte CEN/TC251 prestandarder vedrørende kommunikasjon av elektroniske pasientjournaler (prenv del 1-4), som er men å gi helsepersonell, leverandører og andre interesserte, enkel tilgang til hovedinnholdet i disse prestandardene. Del 1 beskriver en generell arkitektur for innholdet i en elektronisk pasientjournal som skal sikre at journalinformasjon kan utveksles mellom system fra forskjellige leverandører. Arkitekturen er meget generell og er ment å dekke de aller fleste behov. På enkelte områder stiller standarden meget detaljerte krav, mens den på andre områder er lite konkret og overlater mye til de som skal ta standarden i bruk. Del 2 inneholder ett sett av begrep for entydig å kunne karakterisere inneholdet av de komponenter som en elektronisk pasientjournal bygges opp av. For enkelte komponenttyper, og da spesielt de som benyttes for strukturering av journalopplysningene, inneholder prestandarden inneholder også utkast til de kodeverk som skal eller kan benyttes. Del 3 beskriver de data som er nødvendige for at den enkelte virksomhet kan etablere de regler for tilgang til journalinformasjon i tråd med de krav myndighetene stiller, og ut fra de behov den enkelte virksomhet har. Del 4 beskriver hvordan journalopplysninger utveksles mellom ulike parter ved bruk av et sett av meldinger og hvordan disse meldingene er bygget opp. Som prestandard har forslaget ingen bindende konsekvenser for de europeiske landene. Innen tre år må det imidlertid tas stilling til om prestandarden skal bli en formell CEN-standard, revideres og utstedes på nytt som en prestandard eller trekkes tilbake. Målsettingen er i løpet av denne tre-års perioden å fange opp svakheter og mangler ved den foreliggende prestandarden for så å modifisere forslaget før det publiseres som en CENstandard eller evt. en revidert prestandard. Ingen

3 Forord Denne rapporten inneholder en popularisert beskrivelse av de nylig vedtatte CEN/TC251 prestandarder vedrørende kommunikasjon av elektroniske pasientjournaler (prenv del 1-4). Målsettingen med oversettelsen og populariseringen har vært å gi helsepersonell, leverandører og andre interesserte, enkel tilgang til hovedinnholdet i disse prestandardene, som av mange regnes som vanskelig tilgjengelig. Rapporten konsentrerer seg om de sentrale begrep og strukturer, underordnede begrep og strukturer er bare beskrevet i de tilfeller hvor dette er nødvendig for forståelsen. Det er lagt stor vekt på å få en helhetlig og lett tilgjengelig beskrivelse av prenv 13606, noe som blant annet har resultere i at inndelingen i fire deler ikke er beholdt i rapporten. For eksempel falt det naturlig å innarbeide de sentrale deler av del 2, Benyttede termer (Domain Termlist), på de steder i arkitekturbeskrivelsen hvor kodeverkene benyttes. I tillegg til en popularisert beskrivelse av prestandarden, inneholder rapporten en kort omtale av status i CEN sitt standardiseringsarbeide innenfor området elektroniske pasientjournaler. Som vedlegg er det inkludert en liste med oversettelse av de mest sentrale termer og utkast til norsk definisjon av disse. Denne versjonen er utarbeidet av Kompetansesenter for IT i helsesektoren i Norge (KITH AS) etter oppdrag fra Sundhedsstyrelsen i Danmark.

4 Innhold INNLEDNING... 1 Formål 1 Historikk 1 Status 1 Om rapportens innhold 3 Terminologi...3 Om bruk av UML i figurer...3 JOURNALARKITEKTUR... 6 EPJ hovedstrukturkomponent 7 Primære journalstrukturkomponenter 9 Mappe...9 Tids- og Stedsbundet Post...10 Navngitt avsnitt...11 Dataelementsammensetning...12 Dataelement 14 Seleksjon 15 Koblingselement 17 Generaliserte komponenter 18 Primær journalstrukturkomponent...18 Journalkomponent...19 Journalarkitekturkomponent...19 Tilgangsregler 25 Tilgangsregel...25 Referanse til Tilgangsregel...27 Tilgangsloggelement...28 UTVEKSLING AV JOURNALOPPLYSNINGER Behov 29 Omfang og formål 31 Kommunikasjonsparter 33 Meldinger 35 Anvendelsesområder 37 Overføring initiert av avsender...37

5 Overføring initiert av en rekvirent...38 Henvisning av pasient...38 Parallell behandling hos to eller flere parter...39 Anvendelser som involverer en tredje part...40 Meldingsinnhold 43 Felles meldingsinnhold...43 Forespørselsmeldingen...44 Varslingsmeldingen...44 Journalmeldingen...45 Journalmeldingen...46 Journalinnholdet 47 "Tomme" journalkomponenter...47 Detaljeringsnivåer...48 Detaljeringsnivåer...49 Opprinnelsesmarkering...50 NAVNEKATEGORIER A.1 Kategorisett for navn på Tids- og Stedsbundet Post 51 A.2 Kategorisett for navn på Navngitte Avsnitt 54 SENTRALE TERMER Utvalg av komponenter i ENV med første forslag til oversettelse av termer og utkast til definisjoner og forklaringer på norsk 67

6 STANDARD FOR UTVEKSLING AV JOURNALOPPLYSNINGER Kapittel Innledning Formål Formålet med den foreliggende firedelte prestandard (prenv 13606) er å beskrive hvordan elektroniske pasientjournaler skal kunne utveksles helt eller delvis mellom aktører i helsevesenet. Dette inkluderer beskrivelser av: Hvordan journalen må være strukturert for å muliggjøre slik kommunikasjon (del-1 og del-4) Hvilke koder som kan eller skal benyttes (del-2) Hvordan tilgangen til journalopplysninger skal reguleres (del-3) Hvordan interaksjonen mellom aktørene som skal kommunisere, skal foregå (del-4) Historikk En felles struktur for alt innhold i enhver pasientjournal har i mange år vært et fjernt mål. Den Europeiske standardiseringsorganisasjon (CEN) har tilnærmet seg problemstillingen gjennom teknisk komite for helseinformatikk (TC251) ved først å utarbeide en overordnet struktur. Denne ECHRA-prestandarden (Electronic HealthCare Record Architechture) ble utarbeidet av en gruppe ledet av dr. Petter Hurlen og forelå i 1995 (CEN ENV 12265). Det videre arbeidet var opprinnelig ment å omfatte en standard for utvidet journalarkitektur samt en standard for utveksling av journalopplysninger. Ved nærmere ettertanke har det vært vanskelig å finne andre begrunnelser for standardisering av journalstrukturen enn for utveksling av journalinformasjon. Som et resultat av dette ble det ved årsskiftet 1997/98 startet fire prosjektteam som skulle frembringe hver sin del av en europeisk standard for utveksling av journalopplysninger. Status De fire prosjektteamene la våren 1999 fram et forslag til en firedelt prestandard: Del 1 - Utvidet journalarkitektur (CEN ENV Extended Architecthure): Denne beskriver en arkitektur for innholdet i en elektronisk pasientjournal (EPJ) som skal sikre at journalinformasjon kan utveksles mellom system fra forskjellige leverandører. Denne arkitek- 1

7 INNLEDNING turen er også beskrevet i del 4, men her er det foretatt en del utvidelser og mindre endringer. Disse forskjellene er begrunnet med at det for meldingen foreligger en del spesielle behov for konkretiseringer etc. som ikke fullt ut kan dekkes av den generelle arkitekturen som beskrives i del 1. Del 2 - Benyttede termer (CEN ENV Domain termlist): Denne beskriver ett sett av begrep for entydig å kunne karakterisere inneholdet av de komponenter som en EPJ bygges opp av. For enkelte komponenttyper, og da spesielt de som benyttes for strukturering av journalopplysningene, inneholder prestandarden inneholder også utkast til de kodeverk som skal eller kan benyttes. Del 3 - Regler for tilgangskontroll (CEN ENV Distribution rules): Denne beskriver de data som er nødvendige for at den enkelte virksomhet kan etablere de regler for tilgang til journalinformasjon i tråd med de krav myndighetene stiller, og ut fra de behov den enkelte virksomhet har. Del 4 - Meldinger for utveksling av journalopplysninger (CEN ENV Messages for the exchange of information): Denne beskriver hvordan journalopplysninger utveksles mellom ulike parter ved bruk av et sett av meldinger og hvordan disse meldingene er bygget opp. CEN/TC251 aksepterte enstemmig forslagene til prestandard på sitt møte Ettersom problemstillingen er meget omfattende og kompleks er det ikke overraskende at ikke alle problemstillinger er løst fullt ut eller at dokumentene er fullstendig samordnet. Det har imidlertid vært enighet om at det er bedre å arbeide videre med praktiske implementeringer basert på det foreliggende forslaget enn å fortsette dette som et rent skrivebordsarbeide. Ikke minst er det viktig å ha en slik samlende prestandard på et tidspunkt hvor mange leverandører er i ferd med å ta fatt på problemstillingene og hvor en frykter at ulike inkompatible tilnærminger ville bli resultatet dersom ikke denne foreliggende prestandarden ble akseptert. En hovedinnvending mot CENs meldingsstandarder har vært størrelsen på dokumentet og den duplisering av informasjon som finner sted ved at alle informasjonsobjekter er beskrevet fullt ut i hver enkelt meldingsstandard. Det er mer eller mindre vedtatt at felles informasjonsobjekter kun skal beskrives en gang og senere bare refereres til. På den måten reduseres omfanget betraktelig og en får lettere oversikt over når objektet er benyttet uforandret. Denne forbedringen er heller ikke inkludert i den foreliggende prestandarden. Som prestandard har forslaget ingen bindende konsekvenser for de europeiske landene. I løpet av tre år må en imidlertid ta stilling til om prestandarden skal bli en formell CEN-standard, utstedes på nytt som en prestandard eller trekkes tilbake. Målsettingen er i løpet av denne tre-års 2

8 INNLEDNING perioden å fange opp svakheter og mangler ved den foreliggende prestandarden for så å modifisere forslaget før det publiseres som en CENstandard eller evt. en revidert prestandard. Om rapportens innhold De tre første delene av prestandarden henger tett sammen og er derfor beskrevet samlet i kapittel 2, mens del 4, meldinger og kommunikasjonsscenarier, er beskrevet i kapittel 3. Ettersom hensikten med denne rapporten er å gi leserene en overordnet forståelse av innholdet i prestandarden, er gjengivelsen på ingen måte komplett. Det er imidlertid lagt stor vekt på at det ikke skal være uoverensstemmelser mellom denne rapporten og prestandarden, slik at de forenklinger som er gjort hovedsakelig har vært å utelate forhold som ikke er vesentlige for en overordnet forståelse. Terminologi Det er foretatt en oversettelse av et utvalg av de mest sentrale begrep som er benyttet i prestandarden. Første gang et slikt oversatt begrep benyttes i denne rapporten, angis den norske termen i halvfet skrift etterfulgt av den engelske termen i parenteser. I vedlegg B finnes et utvalg av de oversatte termene med definisjoner og i noen tilfeller også eksempler. EPJ benyttes i denne rapporten som forkortelse for Elektronisk Pasient- Journal (electronic healthcare record, EHCR). Om bruk av UML i figurer CEN/TC251 har vedtatt å benytte notasjonsspråket UML (Unified Modeling Language) i sitt arbeide med utarbeidelse av standarder. Tre av prosjektteamene har da også benyttet UML i sine dokumenter, men beklageligvis har ikke alle benyttet et modelleringsverktøy som for eksempel Rational Rose, slik at kvaliteten av resultatet ikke alltid er like godt. Spesielt i del 1 er det en del formelle feil som trekker kvaliteten ned. Figurene i kapittel 2 er utarbeidet spesielt for denne rapporten. Disse tar utgangspunkt i figurene fra de foreliggende prestandardene, men er omarbeidet for klarere å få fram de forholdene som forsøkes illustrert. Alle assosiasjoner mellom de klasser som inngår i figurene er beholdt slik som i prestandardene, også i de tilfeller hvor det synes klart at det må foreligge en feil. I figurene som inngår i denne rapporten benyttes kun et lite subsett av de mulighetene som UML tilbyr. Disse er kort beskrevet nedenfor. Klasser, assosiasjoner og kardinaliteter En klasse er tegnet som en boks med klassens navn inni. I prenv skrives klassens navn altid med stor forbokstav for hvert enkelt ord i 3

9 INNLEDNING navnet, mens attributter skrives med små bokstaver. Denne konvensjonen er også forsøkt fulgt i denne rapporten. Første gang det refereres til en klasse, skrives den i halvfet skrift etterfulgt av den engelske betegnelsen i parenteser. Senere skrives klassenavnet i kursiv. A 1 B Assosiasjoner mellom klasser vises med heltrukne linjer, er assosiasjonen retningsbestemt, vises dette med en pilspiss i den ene enden. I figuren ovenfor representere A og B to klasser, og det er en assosiasjon fra B til A. For eksempel kan A her representere et register med beskrivelse av flytyper, mens B er et register med flyruter. Det vil da være en referanse fra hver enkelt flyrute til den flytypen som benyttes på ruten, men det er ikke lagt opp til at det med utgangspunkt i flytypen skal være mulig å finne ut hvilke flyruter den benyttes på. Kardinaliteten som er vist med tallene ved linjens ender, angir at det for hver forekomstav B må finnes en (1) forekomst av A, og at det for hver forekomst av A kan finnes 0 eller flere () instanser av B. Idrettsanlegg Byer 0..1 Hus 1..* 1..* Etasjer Aggregeringer Aggregering er en spesiell form for assosiasjon som benyttes når et hele skal bygges opp av flere deler. Aggregering symboliseres med et rutersymbol i den delen som utgjør helheten. En spesielt sterk form for aggregering er sammensetning (composition), som angis ved at rutersymbolet er fylt. Dette benyttes når en del alltid må inngå i ett, og bare ett, hele, delen kan altså ikke eksistere utenfor den enhet som den inngår i. Kardinaliteten blir da alltid 1 og angis normalt ikke. Hvordan aggregeringer benyttes, er enklest å forklare med et eksempel. Figuren ovenfor uttrykker følgende: Et Hus består av en eller flere Etasjer. Enhver Etasje må inngå i ett, og bare ett, enkelt Hus og eksisterer ikke utenfor den sammenheng som Huset utgjør. Etasjer kan bare refereres til som en del av det spesifikke Huset den inngår i. Et Hus derimot, har en selvstendig mening og kan inngå i flere sammenhenger. 4

10 INNLEDNING Et Hus kan maksimalt inngå i et Idrettsanlegg, mens et Idrettsanlegg kan bestå av flere hus, men det finnes også Idrettsanlegg uten Hus. Hvert enkelt Hus eller Idrettsanlegg kan maksimalt inngå i en By, men de kan også ligge utenfor byene. En By består av et eller flere Hus, og det kan også finnes Idrettsanlegg der. En By uten hus gir knapt noen mening, men det er ikke noe krav at det skal finnes et Idrettsanlegg der. Generaliseringer og spesialiseringer En generalisering benyttes for samle en del egenskaper (attributter og relasjoner) som er felles for flere klasser. Figuren nedenfor viser to eksempler på generaliseringer: Person er en generalisering av Pasient og Helsepersonell Transportmiddel er en generalisering av Buss og Tog. Person Transportmiddel Pasient Helsepersonell Buss Tog En annen måte å uttrykke det samme på er: Pasient og Helsepersonell er begge spesialiseringer av Person Buss og Tog er begge spesialiseringer av Transportmiddel. Abstrakte klasser I forbindelse med generaliseringer benyttes det ofte abstrakte klasser. Dette er klasser som kun eksisterer i form av sine spesialiseringer. At en klasse er abstrakt, angis ved at klassenavnet står i kursiv. I figuren foran er Transportmiddel en abstrakt klasse, det vil si at konkrete transportmidler kun forekommer i form av spesialiseringene Buss og Tog, og det finnes ikke transportmiddel som er både Buss og Tog. Det vil ofte likevel gi mening å referere til Transportmiddel som sådan, en del egenskaper (som hastighet, energiforbruk etc.) kan være felles for disse, og når en for eksempel skal ut på en kortere reise, kan det være bekvemt å bestille denne uten i første omgang å ta stilling til om en skal benytte Buss eller Tog. Person, derimot, er en konkret klasse. Dette innebærer at det kan finnes Personer som verken er Pasient eller Helsepersonell (heldigvis!), og at samme Person kan være både Pasient og Helsepersonell. 5

11 JOURNALARKITEKTUR Kapittel Journalarkitektur Dette kapitlet inneholder en samlet beskrivelse av de tre første delene av prestandarden prenv Hovedvekten er her lagt på del 1, Utvidet journalarkitektur som beskriver en kommunikasjonsarkitektur for EPJ som skal sikre at journalinformasjon kan utveksles mellom forskjellige system. Eksempler på termer fra del 2, Benyttede termer, er tatt med som en del av beskrivelsen av de klasser hvor termene skal benyttes. Den arkitekturen som beskrives i del 1 av prestandarden, er en referansearkitektur beregnet for kommunikasjon av hele eller deler av en elektronisk pasientjournal som omhandler en enkelt person. Arkitekturen er uavhengig av virksomhetstype og skal gjelde for alle typer pasientjournaler på sykehus, hos primærleger, eller i andre virksomheter innenfor helsevesenet. Det sies eksplisitt at prestandarden ikke omhandler hvordan elektroniske pasientjournaler skal bevares i et elektronisk pasientjournalsystem, men at den kun beskriver hvordan journalen skal kunne betraktes når den skal kommuniseres. Når det gjelder de grunnleggende forhold, er det kun små forskjeller mellom den journalarkitekturen som prenv beskriver, og den som er beskrevet i prestandarden EHCRA (ENV 12265) fra Journalen betraktes fortsatt som bestående av to hovedtyper komponenter, Dataelementer (Data Item) og forskjellige typer strukturkomponenter (component complex). Dataelementene representerer de minste enheter i en pasientjournal som har en selvstendig mening. Strukturkomponentene som det finnes flere undertyper av, benyttes både til å bygge opp dokumenter og andre typer større, selvstendige informasjonsenheter sammensatt av Dataelementer, og til å organisere disse større informasjonsenhetene på en hensiktsmessig måte i journalen. I tillegg finnes det mulighet for opprette forskjellige typer koblinger mellom komponenter i journalen. Figur 1 viser de mest sentrale komponentene som inngår i pasientjournalen, slik denne er beskrevet i den foreliggende prestandarden. 6

12 JOURNALARKITEKTUR EPJ Hovedstrukturkomponent Mappe Tids- og Stedsbundet Post Navngitt avsnitt Koblingselement Dataelementsammensetning Seleksjon Dataelement Figur 1. Oppbygging av den elektroniske pasientjournalen EPJ hovedstrukturkomponent Enhver journal inneholder alltid en EPJ hovedstrukturkomponent (EHCR Root Architectural Component) som alt innholdet i journalen direkte eller indirekte er knyttet opp mot. Med utgangspunkt i papirjournalen, kan EPJ hovedstrukturkomponent betraktes som journalens omslag. Den omslutter hele journalens innhold, men inneholder selv lite informasjon utover pasientens navn og andre sentrale personopplysninger. 7

13 JOURNALARKITEKTUR I dette omslaget (EPJ hovedstrukturkomponent) kan følgende andre komponenttyper plasseres: Mappe (Folder original component complex) Tids- og Stedsbundet Post (Composition original component complex) Seleksjon (Selected Component Complex) Koblingselement (Link Item) Disse blir nærmere beskrevet i det etterfølgende. De grunnleggende personopplysninger vedrørende pasienten skal alltid tilknyttes EPJ hovedstrukturkomponenten og disse skal gjøres tilgjengelig ved hjelp av en unik identifikator, slik at de kan refereres fra journalen for øvrig. Ettersom Dataelementer ikke kan knyttes direkte til EPJ hovedstrukturkomponent, innebærer dette at disse opplysningene må samles i en eller flere Tids- og Stedsbundne Poster som eventuelt plasseres i en Mappe eller knyttes direkte til EPJ hovedstrukturkomponenten. Ideelt bør pasienten ha kun en journal og således bare ha én EPJ hovedstrukturkomponent, men unntak tillates. For eksempel tillates det at hver enkelt avdeling på et sykehus kan ha egne journaler om samme pasient i samme journalsystem. For øvrig vil selvfølgelig en pasienten kunne ha journaler i ulike andre journalsystem (hos sin primærlege, på sitt lokalsykehus osv.) 8

14 JOURNALARKITEKTUR Primære journalstrukturkomponenter Primære journalstrukturkomponenter (original component complex, OCC) benyttes til å bygge opp hovedstrukturene i journalen. En hver komponent, enten denne er en strukturkomponent, et Dataelement eller et Koblingselement, skal inngå i én og bare én primær journalstrukturkomponent. Denne utgjør komponentens opprinnelige kontekst. Det finnes fire forskjellige typer primære journalstrukturkomponenter: 1. Mappe 2. Tids- og Stedsbundet Post 3. Navngitt avsnitt (Headed section original component complex) 4. Dataelementsammensetning (Cluster original component complex) Mappe Til å foreta en høynivå gruppering av dokumenter og annet innhold i journalen, benyttes Mapper. Innholdet i en Mappe vil kunne komme fra kontakter som strekker seg over lange tidsrom innenfor en institusjon, avdeling eller behandlingsenhet, og kan derfor inneholde informasjon som er samlet og innført av forskjellige personer og til forskjellig tid. Prestandarden inneholder ikke forslag til standardiserte mappekategorier, men eksempler på bruk av Mapper kan være: Poliklinikkjournal Journal fra et eller flere innleggelsestilfelle i institusjon, avdeling eller behandlingsenhet Diabetesjournal Psykiatrisk journal Journal for svangerskap, fødsel og barselomsorg (fødejournal) En Mappe kan være åpen eller lukket. Ny informasjon legges inn i Mappen så lenge den er åpen mens den skal være sperret for nye registreringer hvis den er lukket. En lukket Mappe kan imidlertid gjenåpnes. En Mappe kan, i tillegg til underordnede Mapper, inneholde følgende komponenttyper: Tids- og Stedsbundet Post Seleksjon Koblingselement Disse blir nærmere beskrevet i det etterfølgende. 9

15 JOURNALARKITEKTUR Tids- og Stedsbundet Post En Tids- og Stedsbundet Post er en sammensetning av informasjon som utgjør én sammenhengende registrering i journalen, for eksempel i form av et journalnotat. Dette er den eneste typen strukturkomponent som blir obligatorisk i enhver journal, ettersom ethvert Dataelement som registreres direkte eller indirekte må inngå i en Tids- og Stedsbundet Post. Mens en Mappe kan være åpen slik at ny informasjon kan legges inn i den på et senere tidspunkt, eksisterer ikke denne muligheten for en Tidsog Stedsbundet Post. Denne er enten gyldig eller ugyldig. Er den ugyldig innebærer dette enten at den er slettet eller at den i sin helhet er erstattet av en ny Tids- og Stedsbundet Post. En Tids- og Stedsbundet Post vil ofte være forbundet med et tids- og stedsbundet tilfelle av helsetjenesteytelser, men er ikke begrenset til dette. For eksempel vil sammensatte rapporter og sammenfatninger av klinisk forløp og status registreres i form av en Tids- og Stedsbundet Post. Navnekategori Kategorikode (UID) Eksempel på navn på Tids- og Stedsbundet Post Konsultasjonsnotater DTC01 Sykepleievurdering Forløpsnotater DTC02 Resymé av forløp Prosedyrenotater DTC03 Operasjonsbeskrivelse Rekvisisjon av prøver / prosedyrer DTC04 Rekvisisjonsskjema for blodprøver Kliniske henvisninger DTC05 Henvisningsbrev til spesialist Rapport fra tjeneste- eller omsorgsepisode DTC06 Epikrise Rapport om forløp DTC07 Melding om innleggelse Diagnostiske prøveresultater DTC08 Meldinger til ikke-kliniske instanser DTC09 Blodprøvesvar Smittevernmelding Anamnesiske oversikter DTC10 Faste medikamentordineringer Kliniske statusoversikter DTC11 Kurveark Planer for omsorgstjenester DTC12 Sykepleieplan Varsler DTC13 Varsel om allergi og annet det må tas hensyn til Annet DTC90 10

16 JOURNALARKITEKTUR I del 2 av prestandarden er det definert standardiserte kategorier navn for Tids- og Stedsbundet Post, med tilhørende unik identifikator. Disse er listet opp i foregående tabell. I vedlegg A finnes en mer omfattende beskrivelse av disse kategoriene. En Tids- og Stedsbundet Post vil normalt inngå i en Mappe, men den kan alternativt plasseres direkte under EPJ hovedstrukturkomponent. Følgende komponenttyper kan inngå i en Tids- og Stedsbundet Post: Navngitt avsnitt Dataelementsammensetning Seleksjon Dataelement Koblingselement Disse blir nærmere beskrevet i det etterfølgende. Navngitt avsnitt Et Navngitt avsnitt er en sammensetning av informasjon med et felles tema eller som fremkommer ved en felles prosess i pasientomsorgen, og benyttes alltid som en underinndeling av en Tids- og Stedsbundet Post. Ettersom et Navngitt avsnitt alltid vil tilhøre en Tids- og Stedsbundet Post, kan heller ikke et Navngitt avsnitt være åpent for videre registrering, det er enten gyldig eller ugyldig. Selv om dette ikke eksplisitt er sagt i prestandarden, må en kunne anta at et Navngitt avsnitt som inngår i en ugyldig Tids- og Stedsbundet Post, også vil være ugyldig. Det samme vil for øvrig gjelde for Dataelementsammensetning og Dataelement. 11

17 JOURNALARKITEKTUR I del 2 av prestandarden er det definert standardiserte kategorier navn for Navngitte avsnitt, med tilhørende unik identifikator. Disse er listet opp i etterfølgende tabell. Navnekategori Kategorikode (UID) Eksempel på navn på Navngitt avsnitt Pasientanamnese DTH01 Tidligere sykehistorie Annen anamnese DTH02 Smittekontakt Aktuelle problemer og livsstil DTH03 Røykevaner Regelmessige tiltak DTH04 Fast medisinering Nåværende sykehistorie og funn. DTH05 Aktuelle vurderinger DTH06 Diagnose Status presens (funn) Utførte tiltak DTH07 Foreskrevet medisinering Planlagte tiltak DTH08 Spesialisthenvisning Fremtidsutsikter DTH09 Prognose Annet DTH90 I vedlegg A finnes en mer omfattende beskrivelse av disse kategoriene. Et Navngitt avsnitt kan, i tillegg til underordnede navngitte avsnitt, inneholde følgende komponenttyper: Dataelementsammensetning Seleksjon Dataelement Disse blir nærmere beskrevet i det etterfølgende. Dataelementsammensetning En Dataelementsammensetning benyttes der hvor det er behov for å gruppere Dataelementer for at de samlet skal få et meningsinnhold som ikke uten videre framgår dersom en slik gruppering ikke er gjort. Prestandarden inneholder ikke forslag til standardiserte kategorier for Dataelementsammensetning, men eksempler på bruk kan være: Blodtrykksregistrering (systolisk og diastolisk blodtrykk) Differensialtelling av hvite blodlegemer En Dataelementsammensetning kan, i tillegg til underordnede Dataelementsammensetninger, kun inneholde Dataelement. 12

18 JOURNALARKITEKTUR Til en Dataelementsammensetning er det mulig å knytte en standardisert merknadsreferanse (annotation identifier). I del 2 av prestandarden er det definert en lang rekke slike standardiserte merknader. Disse er inndelt i 14 kategorier som for eksempel Gjenstand for informasjonen (subject of information), som igjen inneholder følgende koder: UID Beskrivelse Eksempler og kommentarer DS00 pasient gravid kvinne DS01 slektning mor, far, søster, bror DS01 foster eller nyfødt (i morens journal) DS03 mor (i barnets journal) DS04 donor inkl. transplantert organ eller vev, f.eks. blodprodukt DS05 annen entitet kontaktperson på skole, insekt som er skadeårsak 13

19 JOURNALARKITEKTUR Dataelement Dataelement representerer de minste enheter i en pasientjournal som har en selvstendig mening. De kan i utgangspunktet ikke brytes ned i mindre enheter uten at meningsinnholdet tapes. Dataelement Tekst Dataelement Kodet Dataelement Kvantifiserbar Observasjon Medisinering Hendelse Ekstern Datareferanse Referanse til Fysisk Enhet Pasientrelatert enhet Tilknyttet Stedsangivelse Personidentifikator Personnavn Adresse Teleinformasjon Språk Lokalt Definert Dataelement Figur 2. Spesialiseringer av Dataelement Dataelement er en abstrakt klasse som det i del 4 av prestandarden er beskrevet 14 forskjellige typer (spesialiseringer) av. I tillegg er det gitt 14

20 JOURNALARKITEKTUR mulighet for Lokalt Definerte Dataelement (community defined data item). Disse er beregnet for å definere andre dataelementer enn det som kan uttrykkes ved bruk av de 14 forhåndsdefinerte typene av dataelementer, noe som for eksempel kan benyttes i forbindelse med nasjonal standardisering. I denne rapporten vil det føre for langt å beskrive de forskjellige spesialiseringene av Dataelementer i detalj. Det kan her kort nevnes at flere av spesialiseringene har en intern struktur som kan være ganske kompleks, mens andre, slik som Tekst Dataelement (Text Data Item) og Kodet Dataelement (Structured Coded Data Item) har et innhold av mer grunnleggende karakter. Det er fullt mulig, og også tillatt, å realisere flere av de komplekse typene Dataelement, for eksempel Medisinering (Medication Data Item), ved å benytte Dataelementsammensetninger og Dataelementer av mer grunnleggende type. Det er ikke gitt noen begrunnelse hvorfor disse sammensetningene av Dataelementer er tatt med i prestandarden som egne spesialiseringer. De samme standardiserte merknadsreferanser som er beskrevet for Dataelementsammensetning kan også knyttes til Dataelement. Seleksjon En Seleksjon er en strukturkomponent som benyttes når det er behov for å gjenbruke data som finnes registrert i en elektronisk pasientjournal, i en annen informasjonssammenheng enn den dataene opprinnelig ble registrert i. En Seleksjon kan enten være statisk eller dynamisk. Innholdet i en statisk Seleksjon er uforanderlig og skal framstå med samme innhold, uavhengig av når Seleksjonen åpnes og hvem som åpner den. Slike Seleksjoner kan for eksempel benyttes for å framstille en (statisk) rapport som skal inngå i journalen som et selvstendig dokument. Til en dynamisk Seleksjon, derimot, er det knyttet et seleksjonskriterium som utføres hver gang Seleksjonen åpnes, slik at innholdet vil kunne variere over tid og også ut fra hvem som åpner Seleksjonen. For eksempel kan en la en dynamisk Seleksjon foreta et uttrekk av eksisterende data om foreskrevne medikamenter, slik at den uttrykker begrepet nåværende medisinering. For kommunikasjonsformål vil det ikke være forskjell på en statisk og dynamisk seleksjon ettersom journalinnholdet forhåpentligvis ikke er endret underveis. 15

21 JOURNALARKITEKTUR Seleksjon Mappe Koblingselement Tids- og Stedsbundet Post Dataelementsammensetning Navngitt avsnitt Dataelement Seleksjonsinformasjon Figur 3. Seleksjon En Seleksjon kan inneholde alle typer primære journalstrukturkomponenter samt Dataelementer, Koblingselementer og andre Seleksjoner. Dette er illustrert i Figur 3 ovenfor. 16

22 JOURNALARKITEKTUR Koblingselement Et Koblingselement benyttes for å opprette en kobling fra en komponent i en pasientjournal til en annen komponent i samme eller en annen pasientjournal. Dette er vist i Figur 4 nedenfor. Koblingselement En og bare én kildekomponent er tillatt 0..1 EPJ Hovedstrukturkomponent 0..1 En og bare én målkomponent er tillatt 0..1 Mappe Tids- og Stedsbundet post Navngitt Avsnitt Dataelementsammensetning Dataelement Seleksjon 0..1 Figur 4. Koblingselement Det er i del 2 av prestandarden definert 31 standardiserte kategorier av koblingsbetegnelser med tilhørende unik identifikator. Eksempler på disse kan være: <kildekomponenten> er forårsaket av <målkomponenten> Eksempel: leverskaden er forårsaket av medikamentet <kildekomponenten> er holdepunkt for <målkomponenten> Eksempel: prøvesvaret er holdepunkt for infeksjonssykdom <kildekomponenten> er utviklet fra <målkomponenten> <kildekomponenten> utgjør et rammeverk for <målkomponenten> <kildekomponenten> er indikasjon for <målkomponenten> 17

23 JOURNALARKITEKTUR Generaliserte komponenter For enkelt å kunne beskrive egenskaper (attributter og relasjoner) som er felles for flere av de komponentene som inngår i prestandarden, er det innført tre abstrakte klasser som er generaliseringer av de komponentene som er beskrevet i det foregående. Dette er vist i figur Figur 5 nedenfor. Journalarkitekturkomponent Journalkomponent EPJ Hovedstrukturkomponent Primær Journalstrukturkomponent Seleksjon Koblingselement Dataelement Mappe Tids- og Stedsbundet Post Navngitt Avsnitt Dataelementsammensetning Figur 5. Generaliseringer Primær journalstrukturkomponent Dette er en abstrakt klasse som er en generalisering av: Mappe Tids- og Stedsbundet Post Navngitt avsnitt Dataelementsammensetning Det er ingen egne relasjoner eller attributter knyttet til Primær Journalstrukturkomponent, utover de som arves fra generaliseringen Journalkomponent (Record Component), se nedenfor. Klassen benyttes primært for å samle de Journalstrukturkomponentene som har den egenskap at utgjøre den opprinnelige konteksten til sine medlemmer. 18

24 JOURNALARKITEKTUR Journalkomponent Dette er abstrakt klasse som er en generalisering av: Primær Journalstrukturkomponent Dataelement Seleksjon Koblingselement Til klassen er det knyttet en attributt, kategori komponentnavn (component name category), som benyttes for å foreta en grov gruppering av komponentenes innhold. For eksempel kan kategori komponentnavn for en Tids- og Stedsbundet Post ha innholdet "DTC01 Konsultasjonsnotater", og komponenten vil da inneholde en innkomstjournal, en sykepleiejournal eller lignende. Attributtet kategori komponentnavn benyttes bare for enkelte typer komponenter, og skal da ta en verdi fra den listen over standardiserte kategorier komponentnavn som finnes i del 2 av prestandarden. I tillegg arves alle relasjoner og attributter fra generaliseringen Journalarkitekturkomponent (Architectural Component), se nedenfor. Journalarkitekturkomponent Dette er abstrakt klasse som er en generalisering av: EPJ Hovedstrukturkomponent Journalkomponent Til denne klassen knyttes en mengde informasjon av forskjellig slag som gjennom spesialiseringene arves ned til følgende konkrete klasser: EPJ Hovedstrukturkomponent Mappe Tids- og Stedsbundet Post Navngitt avsnitt Dataelementsammensetning Dataelement Seleksjon Koblingselement Dette medfører at all den informasjon som beskrives i resten av dette kapitlet, kan knyttes til enhver komponent i pasientjournalen, fra det minste Dataelement til den EPJ Hovedstrukturkomponent som utgjør selve journalen. 19

25 JOURNALARKITEKTUR Journalarkitekturkomponent Komponentnavnstruktur 1 Referanse til tilgangsregel Relatert dato og klokkeslett Attestatsjonsinformasjon Revisjonsinformasjon Statusinformation for komponent Presentatsjonsinformasjon +Opphav +Tilknyttet 1 Aktuell helsetjenesteagent 1 1 Figur 6. Journalarkitekturkomponent Enhver Journalarkitekturkomponent skal alltid inneholde pasientidentifikasjon, og det finnes også mulighet til å angi hvilket språk som er benyttet for innholdet i komponenten. Pasientidentifikasjonen skal være unik innenfor hele det område hvor det skal kunne utveksles pasientjournalinformasjon. Dette attributtet er obligatorisk, slik at det må angis pasientidentifikasjon for hvert eneste lille dataelement som inngår i journalen, det er ikke tilstrekkelig å angi at identifikasjonen kan arves fra de høyere nivå i journalstrukturen. Figur 6 viser informasjon som er en del av Journalarkitekturkomponent, og som i prestandarden er beskrevet i separate klasser. Resten av dette kapittelet er viet beskrivelsen av disse klassene. Som det framgår av figuren, er ikke alt obligatorisk, men det er likevel betydelige mengder informasjon som må knyttes til hvert enkelt lille Dataelement. Komponentnavnstruktur Til enhver Journalarkitekturkomponent må det knyttes ett, og bare ett, komponentnavn som skal være beskrivende for den type informasjon komponenten inneholder. Ved å benytte attributtene i klassen Komponentnavnstruktur (Component Name Structure) kan komponentnavnet enten registreres som fri tekst eller i form av en eller flere koder, hentet fra et registrert sett av koder. 20

26 JOURNALARKITEKTUR Hva som er lovlige komponentnavn vil variere med komponentypen, men prestandarden refererer til noen eksisterende, registrerte sett av koder som skal benyttes for enkelte komponenttyper. Statusinformasjon for Komponent Klassen Statusinformasjon for Komponent (Component Status Information) inneholder attributter som benyttes til å angi komponentens status, når status ble endret og hvem som endret status. Statusverdiene gyldig (current), erstattet (superseded) og slettet (deleted) kan benyttes for alle typer komponenter. For Mapper kan gyldig suppleres med gyldig og åpen (current and open), gyldig og lukket (current and closed) samt gyldig og gjenåpnet (current and reopened). Det kan ikke knyttes mer enn en statusverdi til en komponent, slik at det for eksempel ikke er mulig å bevare hvem som endret status til gyldig for en komponent som senere har fått status endret til slettet. Relatert Dato og Klokkeslett Klassen Relatert Dato og Klokkeslett (Related Date and Time) inneholder attributter som benyttes til å knytte tidspunkt for en eller flere "hendelser" (related date/time role) til en komponent. Det er i del 2 av prestandarden definert 38 standardiserte "hendelser" som det kan knyttes et tidspunkt til. Eksempler på disse kan være: Attestert dato Diktert dato Fødselsdato(!) Kvalitetskontrollert dato Planlagt starttidspunkt for prosedyre Presentasjonsinformasjon Større eller mindre deler av en pasientjournal vil kunne ha et innehold som er krever en bestemt presentasjon for at informasjonen skal kunne oppfattes riktig av brukeren. Klassen Presentasjonsinformasjon (Presentation Information) er ment å skulle dekke dette behovet, men ettersom den inneholder pekere på et uspesifisert format til uspesifiserte applikasjoner, maler, prosedyrer etc, er det vanskelig å se hvordan dette skal kunne løses på en måte som gjør det mulig å utveksle journaler mellom uavhengige virksomheter i helsevesenet. Det er mulig å knytte mer enn en Presentasjonsinformasjon til en komponent. I slike tilfeller er det imidlertid ikke mulig å angi hvilken Presentasjonsinformasjon som skal benyttes til et bestemt formål, slik at en for eksempel kan skille mellom utskrift på papir og framvisning på skjerm. 21

27 JOURNALARKITEKTUR Revisjonsinformasjon Håndtering av revisjoner er i denne prestandarden bare overfladisk behandlet. Dersom innholdet av en komponent skal endres, forutsettes det at komponenten i sin helhet blir erstattet med en ny komponent, og en forekomstav klassen Revisjonsinformasjon (Revision Information) benyttes til å peke til foregående versjon av komponenten. Det tas ikke stilling til hva som skal skje med de komponenter som den endrede komponenten inngår i eller bli referert fra. Dersom for eksempel et Dataelement som inngår i et prøveresultat blir endret, er det uklart om dette skal innebære en ny revisjon av prøvesvaret, og eventuelt også andre dokumenter i journalen som refererer til prøvesvaret. Skal enhver endring innebære at alle komponenter som direkte eller indirekte blir påvirket av endringen, også blir erstattet med en ny komponent, vil situasjonen raskt bli uoversiktlig. Attestasjonsinformasjon Klassen Attestasjonsinformasjon (Attestation Information) inneholder attributter som benyttes til å attestere innholdet av en komponent. Det skal alltid angis en digital signatur, et tidspunkt og referanse til en Aktuell Helsetjenesteagent. I tillegg årsaken for attestering angis. 22

28 JOURNALARKITEKTUR Aktuell Helsetjenesteagent Klassen Aktuell Helsetjenesteagent (Healthcare Agent in Context) har en meget kompleks oppbygging, de sentrale delene av denne er vist i Figur 7. Her framgår det at Helsetjenesteagent (Healthcare Agent) er en generalisering av: Helsetjenesteenhet (Healthcare Party) Helsetjenesteprogramvare (Healthcare Software) Helsetjenesteinnretning (Healthcare Device) En Helsetjenesteenhet er igjen en generalisering av: Helsetjenesteperson (Healthcare Person) Det er i del 2 av prestandarden definert 22 standardiserte, men ikke obligatoriske, typer helsetjenesteperson, herunder også pasienten selv og dennes representant. Helsetjenesteorganisasjon (Healthcare Organisation) Aktuell helsetjenesteagent 1 Helsetjenesteagent Helsetjenesteagentrelasjon 1 Helsetjenesteenhet Helsetjenesteprogramvare Helsetjenesteinnretning Helsetjenesteperson Helsetjenesteorganisation Figur 7. Aktuell Helsetjenesteagent Aktuell Helsetjenesteagent benyttes til å beskrive Helsetjenesteagenter som utøver en funksjon i forhold til den registrerte komponenten. Det skilles mellom Opphavelig helestjenesteagent (originating healthcare 23

29 JOURNALARKITEKTUR agent), som er den Helsetjenesteagent som har registrert komponenten i journalen, og Tilknyttet helsetjenesteagenter (related healthcare agent) har en annen funksjon i forhold til komponenten. Det er også mulig å angi at Helsetjenesteagenten i denne sammenhengen har en relasjon (Healthcare Agent Relationship) til en annen Helsetjenesteagent. Dette kan for eksempel benyttes for å uttrykke: Doktor Hansen på Kirurgisk avdeling Sekretær Olsen på vegne av doktor Hansen Røntgenapparat nr 4 benyttet av radiolog Jensen Når det gjelder Aktuell Helsetjenesteagent, så er det betydelig inkonsistens mellom del 1 og del 4 av prestandarden. Spesielt bør her nevnes at det i del 4 gir mulighet til å angi rolle til tilknyttet helsetjenesteagent (role of related healthcare agent). Det er i del 2 av prestandarden definert 18 standardiserte, men ikke obligatoriske, roller for tilknyttete helsetjenesteagenter, for eksempel: Utførte en prosedyre Ansvarlig for en omsorgsperiode Autoriserte en aktivitet Kilde til informasjonen Registrerte informasjonen 24

30 JOURNALARKITEKTUR Tilgangsregler Del 3 av prestandarden beskriver mekanismer for å styre tilgang til informasjon i journalen, samt hvordan slik tilgang skal logges. Utgangspunktet her er at en virksomhet skal kunne bygge opp et sett av regler for tilgang som kan tilknyttes de enkelte komponenter i pasientjournalene ved behov. Dette kan fortrinnsvis skje automatisk, for eksempel på grunnlag av komponentens informasjonsinnhold. Den løsning som er valgt, gjør det imidlertid også mulig ad hoc å opprette nye regler for å styre tilgangen til en enkelt komponent eller en samling av komponenter. Figur 8 viser de mest sentrale delene av datamodellen for tilgangsstyring. Journalarkitekturkomponent Referanse til tilgangsregel 1 Registrert samtykke Tilgangsregel Tilgangsloggelement * Hvordan Hvor Når Hvorfor Hvem Figur 8. Tilgangsregel Tilgangsregel Klassen Tilgangsregel (Distribution Rule) benyttes for å beskrive de regler som benyttes for styring av tilgang til journalinformasjon. En Tilgangsregel er bygget opp av opp til fem adskilte delregler som tar for seg hver sitt forhold. Den som skal gis tilgang på grunnlag av en Tilgangsregel, må oppfylle minst ett kriterium innenfor hver av delreglene som inngår i regelen. En Tilgangsregel skal alltid ha en forfatter, og det kan også angis om regelen skal innebære rett til å endre, slette etc. 25

31 JOURNALARKITEKTUR Hvorfor Klassen Hvorfor (Why) inneholder attributter som benyttes til å beskrive til hvilket formål det skal kunne gis tilgang. Denne delregelen gir mulighet til å stille krav om at den som skal få tilgang må: Ha angitt et bestemt Formål (Purpose of Use) for tilgangen Delta i utførelsen av en bestemt prosess knyttet opp mot behandlingen av pasienten Ha en bestem rolle Være autorisert for en bestemt tilgangskode (sensitivity class) Være pasienten selv Enhver Tilgangsregel må inkludere minst en Hvorfor-delregel. Hvem Klassen Hvem (Who) inneholder attributter som benyttes til å beskrive hvem som skal kunne få tilgang. Dette kan gjøres enten ved å angi en yrkeskategori eller en Helsetjenesteagent. Det er også mulig å angi at alle som deltar i omsorg for pasienten skal kunne gis tilgang. Dette er mest aktuelt i kombinasjon med andre delregler, og da særlig Hvorfor. For eksempel kan en ha en Tilgangsregel som innebærer at alle som deltar i omsorg for pasienten og er autorisert for en bestemt tilgangskode får tilgang. Når Klassen Når (When) inneholder attributter som benyttes for å angi at tilgang kan gis under en bestemt omsorgsperiode (episode of care), eller eventuelt under en hvilken som helst omsorgsperiode.. Hvordan Klassen Hvordan (How) inneholder attributter som benyttes til å beskrive hvilke tilgangsmetoder som kan benyttes og hvilken sikkerhetspolitikk som kreves for at tilgang skal gis. Det kan her også angis at det kreves samtykke fra pasienten og/eller andre for at tilgang skal kunne gis. Hvor Klassen Hvor (Where) inneholder attributter som benyttes for å angi at regelen kun gjelder innenfor en bestemt nasjon eller gruppe av nasjoner. Det kan også angis at Tilgangsregelen er obligatorisk i følge lovgivningen i disse nasjonene. 26

32 JOURNALARKITEKTUR Referanse til Tilgangsregel Enhver Tilgangsregel kan knyttes til en eller flere komponenter i samme og/eller forskjellige journaler. Klassen Referanse til Tilgangsregel (Distribution Rule Reference) inneholder attributter som benyttes til å beskrive spesielle forhold som gjelder for denne tilknytningen. Når en Tilgangsregel knyttes til en komponent, kan det om ønskelig angis at tilgangen kun skal gis i et tidsrom avgrenset av et starttidspunkt og et sluttidspunkt. Skal bruken av en bestemt Tilgangsregelen for en komponent opphøre, gjøres dette ved å endre sluttidspunktet. Dersom flere Tilgangsregler er tilknyttet samme komponent, er hovedregelen at tilgang skal gis til de som fyller kravene fra minst en av disse reglene. Det er imidlertid gitt muligheten til å innføre "sperre-regler" som innebærer at tilgang aldri skal gis til de som fyller kravene fra en eller flere av disse. Dette er en mekanisme som fortrinnsvis kun bør benyttes til å hindre enkeltpersoner sin tilgang til en pasients journal. Benyttes mulighetene til å lage komplekse regler fullt ut, er det betydelig fare for at en ved et uhell kan blokkere behandlende helsepersonells tilgang til vitale data. For å hindre at eventuelle overordnede krav som skal gjelde for tilgang til en komponent, blir omgått av nye Tilgangsregler, er det gitt mulighet for at en Tilgangsregel kan knyttes til en komponent som "basisregel". Dersom en eller flere slike "basisregler" er knyttet til en komponent, tillates det ikke at det tilknyttes vanlige Tilgangsregler som ikke oppfyller de kravene som stilles av minst en av basisreglene. Et eksempel kan belyse dette: En pasient ønsker at tilgang til en del av journalen bare skal gis når pasienten selv eksplisitt har godkjent dette. I tillegg skal det kunne gis tilgang ved nødsituasjoner. For å oppnå dette tilknyttes to "basisregler": 1. Tilgang til ethvert formål etter pasientsamtykke. 2. Tilgang når formålet er nødhjelp. Dette vil hindre at det kan tilknyttes Tilgangsregler som ikke har nødhjelp som formål eller som ikke inneholder krav om pasientsamtykke. Regelen "Tilgang for doktor Hansen med formål forskning" vil således bli avvist mens reglene "Tilgang for helsepersonell med formål nødhjelp" og "Tilgang til forskningsformål etter pasientsamtykke" vil bli godtatt. Samtykke fra pasienten eller andre skal i utgangspunktet også registreres, ved at det til den aktuelle komponenten tilknyttes en Tilgangsregel med referanse til den Tilgangsregelen som inneholder krav om samtykke. I Figur 8 representeres dette ved assosiasjonen Registrert samtykke (Consent demonstration). Hvis doktor Hansen i eksemplet ovenfor får pasientens samtykke til å benytte journalinformasjonen til forskningsformål, så kan regelen "Tilgang for doktor Hansen med formål forsk- 27

33 JOURNALARKITEKTUR ning" registreres med pasienten som forfatter og tilknyttes komponenten med "Registrert samtykke"-referanse til tilgangsregelen "Tilgang til ethvert formål etter pasientsamtykke". Tilgangsloggelement Klassen Tilgangsloggelement (DR Access Log Item) inneholder attributter som benyttes til å logge tilgang til informasjon i pasientjournalene. Det enkelte Tilgangsloggelement er knyttet opp mot den Referanse til Tilgangsregel som forbinder den komponent tilgangen gjelder med den Tilgangsregel som ble anvendt for å få tilgang. I selve loggen inngår det blant annet informasjon om den Aktuelle Helsetjenesteagent som fikk tilgang, når tilgangen ble gitt og det formål som ble angitt for tilgangen. Dersom det benyttes en annen metode enn online tilgang, for eksempel med journalmeldingen, gis det også mulighet for å logge at mottak av informasjonen er bekreftet. 28

34 UTVEKSLING AV JOURNALOPPLYSNINGER Utveksling av journalopplysninger Kapittel Del-4 av denne europeiske prestandarden spesifiserer et sett av meldinger som muliggjør elektronisk overføring av journalopplysninger mellom ulike journalsystem. Løsningen er ment å dekke de krav som dagens journalsystem stiller såvel som mer omfattende krav som er forventet i fremtiden. Behov Behovet for utveksling av journalopplysninger og derved den foreliggende standarden er begrunnet ut fra følgende forhold: Sykehus, spesialister og allmennpraktikere lagrer i stigende utstrekning sine pasientopplysninger i form av elektroniske pasientjournaler. Nåværende journalsystem er svært forskjellige når det gjelder strukturering av journalopplysningene og detaljeringsgrad for disse. Tilgjengelighet til pasientopplysninger og til riktig tid er vesentlig for å kunne tilby gode helsetjenester og unngå feil og unødvendige kostnader. Pasientene oppsøker over tid ulike leger og sykehus. Bruk av meldingene som er spesifisert i denne prestandarden vil: Muliggjøre overføring av elektroniske pasientjournaler i sin helhet eller deler av disse. Gjør det mulig å håndtere forespørsler om utlevering av pasientjournalen Reduserer behovet for at helsepersonell manuelt må duplisere informasjon i ulike journalsystem Reduserer tid og anstrengelser for å kunne etablere elektronisk kommunikasjon av pasientjournaler Reduserer leverandørenes anstrengelser for å få sine applikasjoner til å kunne kommunisere med en rekke andre journalsystem Reduserer kostnadene ved å utveksle journalinformasjon mellom pasientrettede informasjonssystem. Denne standarden spesifiserer kun krav til innhold og struktur for de aktuelle meldingene uten å stille krav om bruk av noen spesiell syntaks. Før 29

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

Medisinsk-faglig innhold i epikriser fra poliklinikker og legespesialister - Den gode spesialistepikrise Medisinsk-faglig innhold i epikriser fra poliklinikker og legespesialister - "Den gode spesialistepikrise" Versjon 1.0 31. desember 2002 KITH Rapport R31/02 ISBN 82-7846-158-9 KITH-rapport Medisinsk-faglig

Detaljer

Elvira. Standarder for elektronisk pasientjournal

Elvira. Standarder for elektronisk pasientjournal Elvira Rapport fra delprosjekt Forfatter: Torbjørn Nystadnes, KITH Dato: 7. mars 2001 KITH - Kompetansesenter for IT i helsevesenet Postadresse: Sukkerhuset, 7489 Trondheim Besøksadresse: Sverres gt 15,

Detaljer

Hjelpenummer for personer uten kjent fødselsnummer

Hjelpenummer for personer uten kjent fødselsnummer Hjelpenummer for personer uten kjent fødselsnummer KITH Rapport 11/98 KITH-rapport Tittel Hjelpenummer for personer uten kjent fødselsnummer Kompetansesenter for IT i helsevesenet AS Postadresse Sukkerhuset

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

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

SOSI standard - versjon 4.0 1 Del 1: Regler for navning av geografiske elementer. DEL 1: Regler for navning av geografiske elementer SOSI standard - versjon 4.0 1 DEL 1: Regler for navning av geografiske elementer SOSI standard - versjon 4.0 2 INNHOLDSFORTEGNELSE DEL 1: Regler for navning av geografiske elementer 1 0 Orientering og

Detaljer

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

Overføring av EPJ ved bytte av fastlege

Overføring av EPJ ved bytte av fastlege Elektronisk pasientjournal standard Anvendelse av EPJ-melding: Overføring av EPJ ved bytte av fastlege Versjon 1.0 26. juni 2002 Status: Til utprøving KITH Rapport 12/02 ISBN 82-7846-137-6 KITH-rapport

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

Høringsuttalelse: Forslag til forskrift om Norsk helsearkiv og Helsearkivregisteret

Høringsuttalelse: Forslag til forskrift om Norsk helsearkiv og Helsearkivregisteret v2.2-18.03.2013 Helse- og omsorgsdepartementet Postboks 8011 Dep 0030 OSLO Deres ref.: 13/443 Vår ref.: 13/10923-5 Saksbehandler: Elisabeth Sagedal, Siri Utkilen Dato: 26.03.2014 Høringsuttalelse: Forslag

Detaljer

Funksjonskrav i ELIN-helsestasjon prosjektet

Funksjonskrav i ELIN-helsestasjon prosjektet Funksjonskrav i ELIN-helsestasjon prosjektet Utvikling av helsefaglig innholdsstandard og struktur for elektronisk informasjonsutveksling i helsestasjonstjenesten i kommunene Fødselsepikrise for nyfødt

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