Generell melding for forespørsel om og overføring av journalinformasjon

Transkript

1 Elektronisk pasientjournal standard Generell melding for forespørsel om og overføring av journalinformasjon Versjon.9 9. desember 2003 Status: Til utprøving KITH Rapport 46/03 ISBN

2 KITH-rapport TITTEL Generell melding for forespørsel om og overføring av journalinformasjon Forfatter(e): Espen Stranger Seland Oppdragsgiver(e) Sosial og helsedirektoratet / Standardiserings- og samordningsprogrammet Kompetansesenter for IT i helsevesenet AS Postadresse Sukkerhuset N-7489 Trondheim Besøksaddresse Sverresgt 5 Telefon Telefaks e-post firmapost@kith.no Foretaksnummer Rapportnr. R 46/03 URL Prosjektnr. ISBN Dato Antall sider Kvalitetssikret av Gradering Torbjørn Nystadnes Åpen Godkjent av: Jacob Hygen, Direktør Sammendrag Dette dokumentet beskriver en generell melding for forespørsel om og overføring av journalinformasjon, beregnet til bruk innenfor alle deler av det norske helsevesenet hvor det utveksles hele eller deler av elektroniske pasientjournaler. Hoveddelen av rapporten består av en informasjonsmodell som beskiver meldingen. På grunnlag av denne informasjonsmodellen er det utarbeidet et XML schema som skal benyttes ved utveksling av journalinformasjon. Hvordan meldingen skal anvendes for bestemte formål, f.eks. overføring av journal ved bytte av fastlege, publiseres som egne dokumenter.

3 Arkitektur, arkivering og tilgangsstyring Forord Dette dokumentet er revidert for å imøtekomme nye krav. Revideringen er gjort på vegne av Helse Vest og Samordning- og standardiseringsprogrammet (SSP) under SHdir. Denne versjonen,.9 er satt med status Til utprøving, og vil etter pilotering settes til versjon 2.0 og Til utbredelse. Forord versjon.0 Denne standarden er utarbeidet under Sosial- og helsedirektoratets program for Standardisering og samordning av informasjons- og kommunikasjonssystemer i helsevesenet. Standarden beskriver en generell melding som skal kunne benyttes for flere formål:. Forespørsel om overføring av journalinformasjon. 2. Svar på forespørsel om overføring av journalinformasjon. 3. Overføring av komplette elektroniske pasientjournaler, eller deler av slike, som følger den norske EPJ-standarden 4. Overføring av ustandardiserte journaldokumenter, f.eks. ved bytte av fastlege. 5. Overføring av andre dokumenter som enten har sitt opphav i, eller skal overføres til, en pasientjournal Dette er altså ment å være en meget fleksibel melding som i utgangspunktet kan benyttes ved overføring av informasjon på ethvert format. F.eks. kan en benytte meldingen til å overføre en komplett journal i form av et sett dokumenter ved bytte av fastlege. Disse dokumentene kan være rene tekstdokumenter, på PDF-format eller andre anerkjente format, og, dersom en ønsker det, kan en også vedlegge den komplette journalen i et proprietært format. Hvordan meldingen skal anvendes for bestemte formål, f.eks. overføring av journal ved bytte av fastlege, publiseres som egne dokumenter. KITH-rapport 46/03 Status: Til utprøving Side 3

4 INNHOLD. INNLEDNING 6 2. MELDINGENS BRUKSOMRÅDER 7 2. Overføring av standardisert journalinformasjon Overføring av ustandardisert journalinformasjon Overføring av andre typer dokument Forespørsel og svar 8 3. NOTASJON 9 3. Bruk av UML i informasjonsmodellen Klasser, attributter og datatyper Assosiasjoner og kardinaliteter Generaliseringer og spesialiseringer 3..4 Abstrakte klasser 3..5 Overgang fra UML til XML Bruk av XML Validering Namespace Metainformasjon 3 4. INFORMASJONSMODELL 4 4. Oversikt Full modell Person og virksomhet Virksomhet (Virksomhet) Person (Person) Arbeidsforhold (Arbeidsforhold) Pasient (Pasient) Rolle i forhold til pasient (HpRollePas) Helsepersonell (Helsepersonell) Adresse (Address) EPJ-melding EPJ-melding (EpjMeld) Kopimottaker (Kopimottaker) 25 KITH-rapport 46/03 Status: Til utprøving Side 4

5 4.5 Dokument Dokument (EpjMeldDokument) Annet Dokument (AnnetDok) Ustandardisert Journaldokument (UstdEpjDok) Referanse (Referanse) Programvaremiljø (Programvare) Forespørsel og svar Forespørsel (ForespOmEpj) Svar (Svar) Strukturert journal Strukturert journal (StdJournaldok) Oversikt over kodeverk 42 VEDLEGG REFERANSER 46 VEDLEGG 2 XML SCHEMA 47 KITH-rapport 46/03 Status: Til utprøving Side 5

6 . INNLEDNING Dette dokumentet beskriver en generell melding for forespørsel om og overføring av journalinformasjon, beregnet til bruk innenfor alle deler av det norske helsevesenet hvor det utveksles hele eller deler av elektroniske pasientjournaler. Meldingen kommer i stedet for det opprinnelig planlagte settet av separate meldinger for utveksling av journalinformasjon: Generell melding for overføring av alle typer journaler som følger den norske EPJstandarden. Overføring av EPJ ved bytte av fastlege (FLO-meldingen) Overføring av journal innenfor helsestasjons- og skolehelsetjenesten. Melding for forespørsel om overføring av EPJ samt melding for svar på slik forespørsel Under arbeidet med disse ble det klart at det var en rekke felles problemstillinger, og at det ville være hensiktsmessig å utvikle en felles melding som kan benyttes ved all overføring relatert til EPJ. Etter som meldingen er generell, vil det være behov for tilleggsinformasjon når den skal anvendes for bestemte formål, f.eks. overføring av journal ved bytte av fastlege. Denne informasjonen vil bli publisert i egne rapporter. Hoveddelen av dette dokumentet, kapittel 4, består av en informasjonsmodell for meldingen. Et XML schema for meldingen finnes i Vedlegg 2. KITH-rapport 46/03 Status: Til utprøving Side 6

7 2. MELDINGENS BRUKSOMRÅDER Dette er en generell melding beregnet til bruk innenfor alle deler av det norske helsevesenet hvor det er behov for å overfør elektroniske pasientjournaler eller deler av slike. Meldingen inneholder en del fast strukturert informasjon som beskriver aktørene: Navn, yrkeskategori, helsepersonellnummer mv. for det helsepersonell som står som ansvarlig for oversendelsen av journalinformasjonen. Navn, adresse, organisasjonsnummer mv. til virksomhet som journalinformasjonen overføres fra og helsepersonellets rolle innenfor denne. Navn, adresse, fødselsnummer og/eller andre entydige identifikatorer for angjeldende pasient. Til pasienten kan det så knyttes et eller flere Dokument. Disse kan deles inn i følgende hovedkategorier:. Standardisert journalinformasjon. Benyttes for hele journaler eller deler av slike som følger den norske EPJ-standarden. Det pågår for tiden en revisjon av denne standarden som bl.a. inkluderer utarbeidelse av XML schema som skal benyttes når en journal, eller deler av denne, skal håndteres som et XML-dokument. 2. Ustandardisert journalinformasjon. Benyttes for hele journaler eller deler av slike som ikke følger den norske EPJ-standarden, f.eks. rene tekstdokument, PDF-dokument, skannede dokument Word-dokument etc. Slike dokument skal beskrives av et sett attributter som beskriver innholdet og hvor informasjonen opprinnelig ble journalført. 3. Annet dokument. Kan f.eks. benyttes for dokumenter som følger andre standarder. Under forutsetning av at dette er avtalt mellom partene som kommuniserer, kan også proprietære format overføres på denne måten. 4. Forespørsel med eventuelt svar Med unntak av forespørsel og svar, så overføres hvert enkelt Dokument som en separat "bodypart" i meldingen. Den generelle melding for overføring av journaldokumenter gir også mulighet for oversending av journalinformasjon for flere pasienter i samme melding. Etter hvert kan det være aktuelt å benytte dette f.eks. i forbindelse med legevakttjenesten. 2. Overføring av standardisert journalinformasjon Den løsning som her er valgt, innebærer at selve journalinnholdet isoleres helt fra den informasjon som er relatert til overføringen av innholdet. Dette medfører ikke bare at samme melding kan benyttes for å overføre journaler på forskjellig format, men også at det kan utarbeides et standardisert format for journaler som kan benyttes for flere typer kommunikasjon. Den grunnleggende EPJ-standarden vil bli revidert slik at den er best mulig egnet for dette formålet. Det vil bli utarbeidet et XML Schema som skal kunne benyttes når standardisert journalinformasjon skal overføres ved hjelp av denne meldingen. Samme XML schema vil også kunne benyttes ved andre former for overføring av journalinformasjon, f.eks. WEBbaserte løsninger. KITH-rapport 46/03 Status: Til utprøving Side 7

8 2.2 Overføring av ustandardisert journalinformasjon Når det gjelder overføring av journal ved bytte av fastlege (FLO-meldingen), så er dette å betrakte som overføring av ustandardisert journalinformasjon inntil videre. Det blir utarbeidet et separat dokument med beskrivelse av hvordan denne meldingen skal benyttes til dette formålet. Dette dokumentet vil inneholde en beskrivelse av hvilke kategorier som skal kunne benyttes ved slik overføring av journalinformasjon og hvilket, eventuelt hvilke, format som skal tillates for de enkelte kategorier. Rent tekstformat vil sannsynligvis være mest hensiktsmessig for det meste, men det kan f.eks. også være aktuelt å benytte PDF og TIFF. 2.3 Overføring av andre typer dokument Kan f.eks. benyttes for dokumenter som følger andre standarder. Under forutsetning av at dette er avtalt mellom partene som kommuniserer, kan også proprietære format, inkludert vanlige tekstdokumenter utarbeidet med MS Word eller lignende, overføres på denne måten. 2.4 Forespørsel og svar Forespørselsdelen av meldingen gir mulighet for å etterspørre komplette journaler eller et antall kategorier journalinformasjon. I tillegg kan det formuleres spørsmål i fri tekst. Det gis mulighet for å stille flere spørsmål i samme melding. Dette medfører at en ved svar på slike forespørsler må koble de enkelte svarene til de spørsmål som er stilt. Meldingen gir mulighet både for svar i form av vedlagte journaldokumenter, fri tekst og forskjellige koder for avslag mv. KITH-rapport 46/03 Status: Til utprøving Side 8

9 3. NOTASJON 3. Bruk av UML i informasjonsmodellen I denne standarden er notasjonsspråket UML (Unified Modeling Language) benyttet ved utarbeidelsen av informasjonsmodellen. Dette er et meget kraftfullt notasjonsspråk som vinner stadig større utbredelse blant leverandørene av programvare over hele verden, og det er også meget benyttet i internasjonalt standardiseringsarbeid. I diagrammene som inngår i denne standarden benyttes kun et lite subsett av de mulighetene som UML tilbyr. Disse er kort beskrevet i det etterfølgende. 3.. Klasser, attributter og datatyper En klasse er tegnet som en boks med klassens navn inni. Navnet til klasser skrives alltid med stor forbokstav, mens attributter skrives med små bokstaver. Denne konvensjonen er også forsøkt fulgt i denne rapporten. I dokumentteksten benyttes kursiv både for klassenavn og attributtnavn. Selv om navn på klasser og attributter i utgangspunktet er på entallsform, blir det i løpende tekst benyttet flertallsform der dette språklig sett er det korrekte. I en del diagrammer vises også de attributtene som inngår i klassen. Dette er illustrert i figuren nedenfor. Arbeidsforhold yrkeskode : CS primært arbeidsforhold : BL yrkesbetegnelse : ST(70) virksomhet : INT(0) Den datatype som benyttes for et attributt, er angitt atter attributtnavnet. For attributter som skal ha en maksimal tillatt lengde, er denne gitt i parentes etter datatypen. Bruken av datatyper følger fullt ut anbefalingene i KITH-rapport 7/0 Datatyper til bruk ved meldingsutveksling mv. ( Datatyper v..pdf) 3... Kodeverk Alle kodeverk som benyttes i denne meldingen er identifisert gjennom en kodeverksnummer. Dette nummeret vil etter hvert utgjøresiste ledd i en global, unik identifikator av kodeverket. En oversikt over de kodeverk som refereres finnes i kapittel?????? 3..2 Assosiasjoner og kardinaliteter Assosiasjoner mellom klasser vises med heltrukne linjer. Er assosiasjonen retningsbestemt, vises dette med en pilspiss i den ene enden. KITH-rapport 46/03 0..* A BStatus: Til utprøving Side 9

10 I figuren ovenfor representerer 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å. Tallene (kardinaliteten) som er vist ved linjens ender, angir at det for hver forekomst av B må finnes en () forekomst av A, og at det for hver forekomst av A kan finnes 0 eller flere (0..*) forekomster av B. Merk: For at det skal være mulig å mappe UML-modellen direkte over til XML, må minst en av endene på en hver assosiasjon ha kardinaliteten eller 0... Dette innebærer at det i de tilfeller hvor det er behov for en "mange-til-mange relasjon", så må det innføres en ekstra klasse slik at en får en "mange-til-en relasjon" og en "en-til-mange relasjon", slik som vis i etterfølgende figur. A..* 0..* B A..* AB 0..* B Aggregeringer Aggregering er en spesiell form for assosiasjon som benyttes når et hele skal bygges opp av flere deler. Aggregering symboliseres med et rutersymbol i den delen som utgjør helheten. En spesielt sterk form for aggregering er sammensetning (composition) som angis ved at rutersymbolet er fylt. Dette benyttes når en del alltid må inngå i ett, og bare ett, hele, delen kan altså ikke eksistere utenfor den enhet som den inngår i. Kardinaliteten blir da alltid eller 0.. og kan være sløyfet dersom den er. Mens en sammensetning (composition) får sitt innehold gjennom instansverdier fra de aktuelle klassene (contaiment by value) får andre aggregeringer sitt innhold gjennom referanser til instansverdier fra de aktuelle klassene (contaiment by reference). Denne forskjellen benyttes aktivt under oppbyggingen av meldingsstrukturen. Idrettsanlegg * 0.. Byer * Hus..*..* Etasjer Hvordan aggregeringer benyttes, er enklest å forklare med et eksempel slik som vist i figuren foran. KITH-rapport 46/03 Status: Til utprøving Side 0

11 Figuren uttrykker følgende: Et Hus består av en eller flere Etasjer. Enhver Etasje må inngå i ett, og bare ett, enkelt Hus og eksisterer ikke utenfor den sammenheng som Huset utgjør. Etasjer kan bare refereres til som en del av det spesifikke Huset den inngår i. Et Hus derimot, har en selvstendig mening og kan inngå i flere sammenhenger. Et Hus kan maksimalt inngå i et Idrettsanlegg, mens et Idrettsanlegg kan bestå av flere hus, men det finnes også Idrettsanlegg uten Hus. Hvert enkelt Hus eller Idrettsanlegg kan maksimalt inngå i en By, men de kan også ligge utenfor byene. En By består av et eller flere Hus, og det kan også finnes Idrettsanlegg der. En By uten Hus gir knapt noen mening, men det er ikke noe krav at det skal finnes et Idrettsanlegg der Generaliseringer og spesialiseringer En generalisering benyttes for å samle en del egenskaper (attributter og relasjoner) som er felles for flere klasser. Figuren nedenfor viser to eksempler på generaliseringer: Person 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. KITH-rapport 46/03 Status: Til utprøving Side

12 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. Merk at instanser fra abstrakte klasser aldri vil kunne forekomme i en konkret meldingsinstans, det er kun spesialiseringene som kan forekomme som instanser. Av den grunn vil abstrakte klasser ikke finnes igjen i det XML schema som skal benyttes ved meldingsutvekslingen Overgang fra UML til XML Under utarbeidelsen av informasjonsmodellen er det tatt hensyn til at XML-syntaks skal benyttes for meldingen, og all informasjon som er nødvendig for å kunne utarbeide et XML schema er tatt med i modellen. Ved overgang fra UML til XML schema benyttes følgende prinsipper for attributter og klasser: Alle attributter blir et XML element av den type (complextype) som datatypen angir. Alle konkrete klasser blir et sammensatt XML element som inneholder XML elementer for hvert attributt som inngår i klassen. For assosiasjoner benyttes følgende prinsipper: Dersom en klassen er en aggregering En sammensetning (composition), innebærer at aggregeringen inneholder instansverdier fra de aktuelle klassene (contaiment by value). I XML innebærer dette at det XML elementet som utgjør aggregeringen, vil inneholde de klasser som inngår i aggregeringen i form av XML elementer. For aggregeringer som får sitt innhold gjennom referanser til instansverdier fra de aktuelle klassene (contaiment by reference) og for andre assosiasjoner som ikke innbærer aggregering, benyttes XML funksjonene key og keyref. I UML-modellen skal det i slike tilfeller finnes en attributt i klassen på den siden av assosiasjonen hvor kardinaliteten er eller 0.. som inneholder en referanse til primærnøkkelen for en instans av klassen på den andre enden av assosiasjonen. Sist nevnte attributt blir i XML et element som registreres som key for det XML elementet som utgjør klassen. Først nevnte attributt blir i XML et element og dette blir angitt som keyref og satt til å peke på den angitte key. 3.2 Bruk av XML Den elektroniske meldingen som er beskrevet i dette dokumentet skal overføres som en XMLmelding [3]. Et XML Schema [4] benyttes til å definere regler for struktur, innhold og semantikk for meldingen. En spesifikk instans av XML-meldingen kan valideres opp mot skjemaet. Selve XML Schema et for denne meldingen er nærmere beskrevet i Vedlegg 2. KITH-rapport 46/03 Status: Til utprøving Side 2

13 3.2. Validering XML-skjemaet har blitt validert i henhold til XML Schema-standarden med verktøyene XMLSpy 5.4 og XSV.204/.09. Det ble ikke funnet noen feil eller advarsler ved disse valideringene Namespace Standard Gjeldende namespace for meldingen (XML Schema) som er beskrevet i dette dokumentet er xmlns:xsd=" xmlns=" Dette er versjonen som kom i mai 200, og er per dags dato siste versjon av XML Schema Skjema Skjemaet vil være lokalisert på KITH s server. targetnamespace=" xmlns:epj=" " Norske bokstaver Følgende transkribering er foretrekket for norske tag-navn: Æ = E Ø = O Å = A Dette for å holde navnene korte. Der misforståelser kan forekomme tillates det å bruke formene ae, oe og aa i kortnavnene. XML Schema basert på Unicode skal kunne forstå bruk av norske bokstaver i tagger, men det er ikke all programvare som støtter dette godt nok enda Metainformasjon Det er ikke lagt inn detaljerte krav i skjemaet for elementer og attributter. Det er for eksempel ikke lagt inn minimal og maksimal tillatt lengde på en variabel selv om dette er mulig. KITH-rapport 46/03 Status: Til utprøving Side 3

14 4. INFORMASJONSMODELL 4. Oversikt <<top>> EPJ-melding (from EPJ-melding) 0..* Kopimottaker (from EPJ-melding)..* Pasient (from Person og virksomhet) Rolle i forhold til pasient (from Person og virksomhet) 0.. Helsepersonell (from Person og virksomhet)..*..* Virksomhet (from Person og virksomhet) +Opprettet av 0..* Programvaremiljø (from Dokument) +Produsert av Person (from Person og virksomhet) Arbeidsforhold (from Person og virksomhet) * Dokument (from Dokument) 0.. Adresse (from Person og virksomhet) Referanse (from Dokument) 0.. +Opprinnelig journalført hos Forespørsel (from Forespørsel og svar) Strukturert journal (from Strukturert journal) Annet Dokument (from Dokument) 0.. Svar (from Forespørsel og svar) Ustandardisert Journaldokument (from Dokument) KITH-rapport 46/03 Status: Til utprøving Side 4

15 4.2 Full modell <<top>> EPJ-melding (from EPJ-melding) meldingstype : CS implementert versjon : ST programvareversjon : ST melding generert : TS id : ST meldingstype EPJ : CS merknad : ST 0..*..* Pasient (from Person og virksomhet) fødselsnummer : ST D-nummer : BL fødselsdato : TS kjønn : CS annen ID : ST type annen ID : ST nasjonalitet : CS trygdekontor : ST Programvaremiljø (from Dokument) meldingsintern programvare ID : ID programvare type : INT produsent : ST betegnelse : ST versjon : ST merknad : ST +Produsert av Referanse (from Dokument) id : ST href : URL XML-dokument : ST 0..* Rolle i forhold til pasient (from Person og virksomhet) rolle i forhold til pasien : CS referanse til pasient : IDREF 0.. Person (from Person og virksomhet) meldingsintern person ID : ID etternavn : ST mellomnavn : ST fornavn : ST..* Helsepersonell (from Person og virksomhet) helsepersonellnummer : ST kategori helsepersonell : CS 0..* 0.. Dokument (from Dokument) meldingsinternt dokument ID : ID type innhold : CV svar på forespørsel : BL pasientsamtykke : CS merknad : ST produsert av programvare : IDREF Kopimottaker (from EPJ-melding) kontaktperson : IDREF virksomhet : IDREF merknad : ST Arbeidsforhold (from Person og virksomhet) yrkeskode : CS primært arbeidsforhold : BL yrkebetegnelse : ST virksomhet : IDREF 0....* Virksomhet (from Person og virksomhet) meldingsintern virksomhet ID : ID avsender : BL betegnelse : ST organisasjonsnummer : ST type helsevirksomhet : CS 0.. Adresse (from Person og virksomhet) Type : CS Gateadresse : ST Postnummer : ST Poststed : ST Fylke/kommune : CS Land : CS Telekommunikasjon : SET<URL> +Opprettet av +Opprinnelig journalført hos Forespørsel (from Forespørsel og svar) type forespørsel : CS kategori journalinformasjon : CV spørsmål i fritekst : ST hastegrad : CS kun informasjon yngre enn : TS kun informasjon eldre enn : TS formål med forespørsel : CS beskrivelse av formål : ST 0.. Svar (from Forespørsel og svar) kode for svar : CS begrunnelse for svar : ST svar i fri tekst : ST Strukturert journal (from Strukturert journal) Ustandardisert Journaldokument (from Dokument) opprinnlig journalført hos : IDREF innholdskategori : CV innholdsbeskrivelse : ST tidligste registrering : TS seneste registrering : TS Annet Dokument (from Dokument) virksomhet : IDREF innholdsbeskrivelse : ST tidligste registrering : TS seneste registrering : TS KITH-rapport 46/03 Status: Til utprøving Side 5

16 4.3 Person og virksomhet 0.. Rolle i forhold til pasient rolle i forhold til pasien : CS referanse til pasient : IDREF Helsepersonell helsepersonellnummer : ST kategori helsepersonell : CS Person meldingsintern person ID : ID etternavn : ST mellomnavn : ST fornavn : ST Pasient fødselsnummer : ST D-nummer : BL fødselsdato : TS kjønn : CS annen ID : ST type annen ID : ST nasjonalitet : CS trygdekontor : ST Arbeidsforhold yrkeskode : CS primært arbeidsforhold : BL yrkebetegnelse : ST virksomhet : IDREF Adresse Type : CS Gateadresse : ST Postnummer : ST Poststed : ST Fylke/kommune : CS Land : CS Telekommunikasjon : SET<URL> 0.. Diagram: Person og virksomhet Virksomhet meldingsintern virksomhet ID : ID avsender : BL betegnelse : ST organisasjonsnummer : ST type helsevirksomhet : CS KITH-rapport 46/03 Status: Til utprøving Side 6

17 4.3. Virksomhet (Virksomhet) Denne klassen benyttes til å beskrive de virksomheter som direkte eller indirekte skal kunne refereres fra en eller flere EPJ. Dette kan f.eks. være pasienters arbeidsgivere, virksomheter som det overføres journalinformasjon til, eller som har vært kilde til informasjon i EPJ, f.eks. et eksternt laboratorium. Assosierte klasser: Er en del av 'EPJ-melding' 'by value' Inneholder 0.. 'Adresse' 'by value' Inneholder 'Annet Dokument' 'by reference' rolle: Opprettet av Inneholder 'Ustandardisert Journaldokument' 'by reference' rolle: Opprinnelig journalført hos Inneholder 'Arbeidsforhold' 'by reference' Inneholder 'Kopimottaker' uspesifisert meldingsintern virksomhet ID (virkid) avsender (ErAvsender) betegnelse (VirksomhetNavn) organisasjonsnum mer (OrgNr) type helsevirksomhet (TypeHelsevirkso mhet) ID Meldingsintern virksomhets-id. Benyttes kun for å opprettholde interne referanser i selve meldingen. "V0" BL Verdi "true" dersom denne virksomheten er meldingens avsender, verdi "false" ellers. ST Virksomhetens offisielle betegnelse eller navn "St Olavs Hospital HF" 0.. ST Virksomhetens offisielle organisasjonsnummer, tildeles av Bedrifts- og Foretaksregisteret i Brønnøysund. " " 0.. CS Dersom dette er en virksomhet innenfor helsevesenet, kan det her angis en kode som angir hvilken type helsevirksomhet dette er. Koder for type helsevirksomhet finnes i administrativt kodeverk nr V="85." DN="Allminnelige somatiske sykehustjenester" Person (Person) Abstrakt klasse, benyttes som toppnode for å knytte sammen informasjon om alle personer, inkludert pasienter og helsepersonell. Kommentar: ESS: Bør samkjøres. Vi må ant. ha inn kjønn grunnet at meldingen vil ha mange bruksområder med uviss tilknytning til regelverk mv. Assosierte klasser: KITH-rapport 46/03 Status: Til utprøving Side 7

18 Abstrakt klasse, spesialiserer som 'Helsepersonell', 'Pasient' Inneholder 0.. 'Arbeidsforhold' 'by value' Inneholder 0..* 'Dokument' 'by value' Inneholder 0.. 'Adresse' 'by value' meldingsintern person ID (perid) etternavn (FamilyName) mellomnavn (MiddleName) fornavn (GivenName) ID Meldingsintern person ID. Benyttes kun for å opprettholde interne referanser i selve meldingen. P+to løpende sifre. "P0" 0.. ST For å angi personens etternavn. "Nordmann" 0.. ST For å angi personens mellomnavn, dvs. navn som personen vanligvis ikke benytter sammen med fornavnet, og som heller ikke inngår som en del av etternavnet. 0.. ST For å angi personens fornavn. "Ola" Arbeidsforhold (Arbeidsforhold) For å angi informasjon om personens arbeidsforhold. Assosierte klasser: Er en del av 'Person' 'by value' Er en del av 'Virksomhet' 'by reference' yrkeskode (Yrkeskode) 0.. CS For å angi hvilket yrke pasientene har. Yrkeskoder finnes i administrativt kodeverk nr Dette kodeverket som i Norge vedlikeholdes av SSB, er en standard for yrkesklassifisering (STYRK) basert på EUs utgave av den internasjonale standarden for yrkesklassifisering fra Den internasjonale arbeidsorganisasjonen (ILO): International Standard Classification of Occupations (ISCO-88 COM). V="7342" DN="Fotografer" Kommentar: Elektronisk utgave (PDF): KITH-rapport 46/03 Status: Til utprøving Side 8

19 primært arbeidsforhold (primartarbeidsfor hold) yrkebetegnelse (Yrkesbetegnelse) virksomhet (virkidref) BL Verdi "true" dersom dette er pasientens primære arbeidsforhold, verdi "false" ellers. "true" 0.. ST For å angi yrke/yrkesbetegnelse i fritekst "Fotograf" IDREF Meldingsintern referanse til beskrivelse av den virksomhet personen arbeider. V+to løpende sifre. "V0" Pasient (Pasient) Informasjon om pasient. Assosierte klasser: Spesialisering av 'Person' Er en del av 'EPJ-melding' 'by value' Inneholder 'Rolle i forhold til pasient' 'by reference' Inneholder 0.. 'Arbeidsforhold' 'by value' Inneholder 0..* 'Dokument' 'by value' Inneholder 0.. 'Adresse' 'by value' meldingsintern person ID (perid) etternavn (FamilyName) mellomnavn (MiddleName) fornavn (GivenName) ID Meldingsintern person ID. Benyttes kun for å opprettholde interne referanser i selve meldingen. P+to løpende sifre. "P0" 0.. ST For å angi personens etternavn. "Nordmann" 0.. ST For å angi personens mellomnavn, dvs. navn som personen vanligvis ikke benytter sammen med fornavnet, og som heller ikke inngår som en del av etternavnet. 0.. ST For å angi personens fornavn. "Ola" KITH-rapport 46/03 Status: Til utprøving Side 9

20 fødselsnummer (FodselsNr) 0.. ST For å angi pasientens fødselsnummer, eventuelt D-nummer. Hvis det benyttes fødsels- eller D-nummer, skal ikke fødselsdato eller kjønn fylles ut. D-nummer (DNr) 0.. BL Verdi "true" dersom det i attributte "fødselsnummer" registreres et D- nummer, dvs. en unik personidentifikasjon som folkeregistret tildeler personer som ikke er bosatt i Norge, men som likevel er skatte- og/eller trygdepliktig. Verdi "false" ellers. fødselsdato (Fodselsdato) 0.. TS Pasientens fødselsdato kjønn (Sex) 0.. CS Sosialt kjønn. annen ID (AnnenId) type annen ID (TypeAnnenId) nasjonalitet (Nasjonalitet) trygdekontor (Trygdekontor) Hvis fødselsdato benyttes, skal også kjønn (Sex) fylles ut. Skal kun brukes i kombinasjon med fødselsdato. 0.. ST Fritekst for annen identifikasjon. For en amerikansk statsborger kan det være naturlig å angi Social Security Number: ST Beskriver hva slags type annen ID som evt. er i bruk. Amerikansk statsborger, Social Security Number. 0.. CS Ppasientens nasjonalitet. Skal kun brukes hvis pasientens nasjonalitet ikke er norsk (NO). Landskode iht. ISO ST Trygdekontoret som pasienten tilhører Rolle i forhold til pasient (HpRollePas) Helsepersonellets rolle i forhold til en pasient. Assosierte klasser: Er en del av 'Helsepersonell' 'by value' Er en del av 'Pasient' 'by reference' rolle i forhold til pasien (HpRollekode) CS Helsepersonellets rolle i forhold til en pasient. Koder for type helsepersonellets rolle i forhold til pasienten finnes i administrativt kodeverk nr KITH-rapport 46/03 Status: Til utprøving Side 20

21 referanse til pasient (peridref) IDREF Meldingsintern referanse til pasienten. P+to løpende sifre. "P02" Helsepersonell (Helsepersonell) For å beskrive egenskaper ved personen som helsepersonell. Assosierte klasser: Spesialisering av 'Person' Er en del av 'EPJ-melding' 'by value' Inneholder 0.. 'Rolle i forhold til pasient' 'by value' Inneholder 'Kopimottaker' 'by reference' Inneholder 0.. 'Arbeidsforhold' 'by value' Inneholder 0..* 'Dokument' 'by value' Inneholder 0.. 'Adresse' 'by value' meldingsintern person ID (perid) etternavn (FamilyName) mellomnavn (MiddleName) fornavn (GivenName) helsepersonellnum mer (hprnr) kategori helsepersonell (type) ID Meldingsintern person ID. Benyttes kun for å opprettholde interne referanser i selve meldingen. P+to løpende sifre. "P0" 0.. ST For å angi personens etternavn. "Nordmann" 0.. ST For å angi personens mellomnavn, dvs. navn som personen vanligvis ikke benytter sammen med fornavnet, og som heller ikke inngår som en del av etternavnet. 0.. ST For å angi personens fornavn. "Ola" ST Helsepersonellnummeret er en offisielt tildelt entydig personidentifikasjon av offentlig godkjente helsepersonell. 0.. CS Kode som angir kategori helsepersonell i henhold til helsepersonellregisterets inndeling. Koder for kategori helsepersonell finnes i administrativt kodeverk nr KITH-rapport 46/03 Status: Til utprøving Side 2

22 4.3.7 Adresse (Address) Adresse og telekommunikasjon. Assosierte klasser: Er en del av 'Person' 'by value' Er en del av 'Virksomhet' 'by value' Type (TypeAdr) 0.. CS Kode for type adresse. Gateadresse (StreetAdr) Postnummer (PostalCode) Kodeverdier: H Bostedsadresse PST Postadresse WP Arbeidsadresse INV Faktureringsadresse 0.. ST V="H" DN="Bostedsadresse" "Gangveien " 0.. ST "265" Poststed (City) 0.. ST Fylke/kommune (County) "Hvam" 0.. CS Kommunenummer angis med fire siffer, i henhold til SSB sin inndeling. De to første sifrene angir fyle og de to siste er kommunens nummer innenfor fylket. Liste finnes på V="0236" DN="Nes" Land (Country) 0.. CS Kode for land iht. ISO 366. V="NO" DN="Norge" Telekommunikasjo n (Telecom) 0..* URL "tlf: " "fax: " "mailto:foo.bar@example.com" KITH-rapport 46/03 Status: Til utprøving Side 22

23 4.4 EPJ-melding <<top>> EPJ-melding meldingstype : CS implementert versjon : ST programvareversjon : ST melding generert : TS id : ST meldingstype EPJ : CS merknad : ST Diagram: EPJ-melding KITH-rapport 46/03 Status: Til utprøving Side 23

24 4.4. EPJ-melding (EpjMeld) Toppnode i EPJ-meldingen. Kommentar: ESS: EPJ-hode må få samme meldingshode som de andre meldingene. Assosierte klasser: Inneholder..* 'Virksomhet' 'by value' Inneholder..* 'Pasient' 'by value' Inneholder..* 'Helsepersonell' 'by value' Inneholder 0..* 'Programvaremiljø' 'by value' Inneholder 0..* 'Kopimottaker' 'by value' meldingstype (Type) implementert versjon (MIGVersion) programvareversjo n (SoftwareVersion) melding generert (GenDate) CS Meldingens funksjon Skal alltid være "EPJ" <Type V="EPJ"/> ST Spesifikasjon av benyttet implementasjon av meldingen. (Versjonsnummer til implementasjonsguide som er benyttet for implementeringen). Feltet inneholder identifikasjon av benyttet implementasjonsguide på formen "vn ccyy-mm-dd". <MIGVersion>v </MIGVersion> 0.. ST Versjon av programvaren som sender/genererer applikasjonsmeldingen. Frivillig, men det kan være praktisk for mottaker. Bør kunne loggføres. ".0" TS Tidspunkt for generering av meldingen angitt med dato og klokkeslett. Dato og klokkeslett. <GenDate> T09:30:47-0:00</GenDate> id (Id) ST Entydig referansenummer for meldingen. Unik ID. Det foreslås å bruke UUID. <Id>4c66458-c42-4c4-baae-7b096f64f6e7</Id> KITH-rapport 46/03 Status: Til utprøving Side 24

25 meldingstype EPJ (TypeEpjMeld) merknad (Merknad) CS Hva slags type EPJ-melding det dreier seg om, f.eks. om det er overføring av EPJ og relaterte vedlegg eller Forespørselsmelding 0.. ST Koder for type EPJ-melding finnes i administrativt kodeverk nr Kopimottaker (Kopimottaker) Kopimottaker(e) av meldingen, Assosierte klasser: Er en del av 'EPJ-melding' 'by value' Er en del av 'Virksomhet' uspesifisert Er en del av 'Helsepersonell' 'by reference' kontaktperson (peridref) virksomhet (virkidref) merknad (Merknad) 0.. IDREF Referanse til kontaktperson. Brukes kun om helsepersonell. IDREF Referanse til virksomhet. 0.. ST For merknader. F.eks. kan man skrive navn på kontaktperson her, hvis kontaktperson knyttet til virksomhet ikke er helsepersonell. KITH-rapport 46/03 Status: Til utprøving Side 25

26 4.5 Dokument Referanse id : ST href : URL XML-dokument : ST Dokument meldingsinternt dokument ID : ID type innhold : CV svar på forespørsel : BL pasientsamtykke : CS merknad : ST produsert av programvare : IDREF Annet Dokument virksomhet : IDREF innholdsbeskrivelse : ST tidligste registrering : TS seneste registrering : TS Ustandardisert Journaldokument opprinnlig journalført hos : IDREF innholdskategori : CV innholdsbeskrivelse : ST tidligste registrering : TS seneste registrering : TS +Produsert av Strukturert journal Programvaremiljø meldingsintern programvare ID : ID programvare type : INT produsent : ST betegnelse : ST versjon : ST merknad : ST Svar kode for svar : CS begrunnelse for svar : ST svar i fri tekst : ST Forespørsel type forespørsel : CS kategori journalinformasjon : CV spørsmål i fritekst : ST hastegrad : CS kun informasjon yngre enn : TS 0.. kun informasjon eldre enn : TS formål med forespørsel : CS beskrivelse av formål : ST Diagram: Dokument KITH-rapport 46/03 Status: Til utprøving Side 26

27 4.5. Dokument (EpjMeldDokument) Dette er en abstrakt klasse som benyttes som basis for de forskjellige typene innhold som kan overføres med denne meldingen. Assosierte klasser: Abstrakt klasse, spesialiserer som 'Strukturert journal', 'Ustandardisert Journaldokument', 'Forespørsel', 'Annet Dokument' Er en del av 'Person' 'by value' Er en del av 'Programvaremiljø' 'by reference' Inneholder 'Referanse' 'by value' meldingsinternt dokument ID (dokid) type innhold (TypeEpjMeldDok ) svar på forespørsel (SvarForesp) pasientsamtykke (Samtykke) ID Benyttes kun for å opprettholde interne referanser i selve meldingen. "D0" CV Kode som angir hvilken type innhold dette dokumentet har. Koder for type innhold i dokumenter som overføres med EPJ-meldingen finnes i administrativt kodeverk nr Følgende muligheter finnes i dette kodeverket: - Forespørsel - Svar på forespørsel - Ustandardiserte journaldokument (FLO-melding) - Standardisert journal fra helsestasjonsjourn eller skolehelsetjeneste Kodeverket vil bli utvidet med nye verdier etterhvert som standardiseringen skrider fram. I tillegg kan det for bestemte formål benyttes egne kodeverk for kommunikasjon av andre typer dokumenter mellom kommunikasjonsparter hvor dette er avtalt på forhånd. Dette kan f.eks. benyttes for å overføre journaler ellerjournaldokumenter på proprietært format som instanser av "Annet Dokument". BL Verdi "true" dersom journalinformasjon oversendes som svar på en forespørsel, "false" ellers. CS Angir om det er det innhentet samtykke fra pasient. Følgende muligheter skal finnes: - Ja, samtykke er innhentet - Svar på forespørsel e.l. som pasienten har gitt sitt samtykke til - Pasientens samtykke er ikke påkrevd i dette tilfellet - Nei, pasienten har ikke gitt sitt samtykke merknad (Merknad) 0.. ST Til fritt bruk Koder for status for innhenting av pasientens samtykke finnes i administrativt kodeverk nr KITH-rapport 46/03 Status: Til utprøving Side 27

28 produsert av programvare (progidref) 0.. IDREF Unik referanse til en beskrivelse av den programvaren som dette dokumentet er produsert av. S+to løpende sifre. "S0" Annet Dokument (AnnetDok) Denne klassen benyttes primært for overføring av frittstående dokumenter som enten stamme fra eller skal overføres til, en pasientjournal. Men kan f.eks. også benyttes ved overføring av komplette journaler på proprietært format. Det er verdien av attributtet "type innhold" som avgjør hvordan dokumentinnholdet skal tolkes. Assosierte klasser: Spesialisering av 'Dokument' Er en del av 'Virksomhet' 'by reference' Er en del av 'Person' 'by value' Er en del av 'Programvaremiljø' 'by reference' rolle: Produsert av Inneholder 'Referanse' 'by value' meldingsinternt dokument ID (dokid) type innhold (TypeEpjMeldDok ) svar på forespørsel (SvarForesp) ID Benyttes kun for å opprettholde interne referanser i selve meldingen. "D0" CV Kode som angir hvilken type innhold dette dokumentet har. Koder for type innhold i dokumenter som overføres med EPJ-meldingen finnes i administrativt kodeverk nr Følgende muligheter finnes i dette kodeverket: - Forespørsel - Svar på forespørsel - Ustandardiserte journaldokument (FLO-melding) - Standardisert journal fra helsestasjonsjourn eller skolehelsetjeneste Kodeverket vil bli utvidet med nye verdier etterhvert som standardiseringen skrider fram. I tillegg kan det for bestemte formål benyttes egne kodeverk for kommunikasjon av andre typer dokumenter mellom kommunikasjonsparter hvor dette er avtalt på forhånd. Dette kan f.eks. benyttes for å overføre journaler ellerjournaldokumenter på proprietært format som instanser av "Annet Dokument". BL Verdi "true" dersom journalinformasjon oversendes som svar på en forespørsel, "false" ellers. KITH-rapport 46/03 Status: Til utprøving Side 28

29 pasientsamtykke (Samtykke) CS Angir om det er det innhentet samtykke fra pasient. Følgende muligheter skal finnes: - Ja, samtykke er innhentet - Svar på forespørsel e.l. som pasienten har gitt sitt samtykke til - Pasientens samtykke er ikke påkrevd i dette tilfellet - Nei, pasienten har ikke gitt sitt samtykke merknad (Merknad) produsert av programvare (progidref) virksomhet (virkidref) innholdsbeskrivels e (Innhold) tidligste registrering (FraDato) seneste registrering (TilDato) 0.. ST Til fritt bruk Koder for status for innhenting av pasientens samtykke finnes i administrativt kodeverk nr IDREF Unik referanse til en beskrivelse av den programvaren som dette dokumentet er produsert av. S+to løpende sifre. "S0" IDREF Meldingsintern referanse til beskrivelse av den virksomhet hvor dette dokumentet er utarbeidet. V+to løpende sifre. "V0" ST Overskrift eller annen kort tekst som beskriver dokumentets innhold. TS Dato og eventuelt klokkeslett som angir når den eldste delen av dokumentets innhold ble registrert. 0.. TS Dato og eventuelt, som angir når den yngste delen av dokumentets innhold ble registrert. Dersom hele dokumentet ble registrert den dato som er angitt i "tidligste registrering", kan dette attributtet utelates Ustandardisert Journaldokument (UstdEpjDok) Denne klassen benyttes ved overføring av ustandardiserte journaldokumenter, f.eks. ved bytte av fastlege. Slike dokumenter kan typisk overføres på PDF-format, men også andre formater kan benyttes. Attributtene i denne klassen inneholder kun overordnet informasjon hovedsakelig beregnet for enkel sortering hos mottaker. Et ustandardisert journaldokument kan inneholde informasjon fra flere enkelttilfeller av helsehjelp, og innholdet kan være ført av forskjellige personer. Selve dokumentinnholdet må derfor inneholde all nødvendig informasjon om hvem som har ført de enkelte deler av dokumentet, når de ble ført etc. Assosierte klasser: Spesialisering av 'Dokument' Er en del av 'Virksomhet' 'by reference' KITH-rapport 46/03 Status: Til utprøving Side 29

30 Er en del av 'Person' 'by value' Er en del av 'Programvaremiljø' 'by reference' rolle: Produsert av Inneholder 'Referanse' 'by value' meldingsinternt dokument ID (dokid) type innhold (TypeEpjMeldDok ) svar på forespørsel (SvarForesp) pasientsamtykke (Samtykke) ID Benyttes kun for å opprettholde interne referanser i selve meldingen. "D0" CV Kode som angir hvilken type innhold dette dokumentet har. Koder for type innhold i dokumenter som overføres med EPJ-meldingen finnes i administrativt kodeverk nr Følgende muligheter finnes i dette kodeverket: - Forespørsel - Svar på forespørsel - Ustandardiserte journaldokument (FLO-melding) - Standardisert journal fra helsestasjonsjourn eller skolehelsetjeneste Kodeverket vil bli utvidet med nye verdier etterhvert som standardiseringen skrider fram. I tillegg kan det for bestemte formål benyttes egne kodeverk for kommunikasjon av andre typer dokumenter mellom kommunikasjonsparter hvor dette er avtalt på forhånd. Dette kan f.eks. benyttes for å overføre journaler ellerjournaldokumenter på proprietært format som instanser av "Annet Dokument". BL Verdi "true" dersom journalinformasjon oversendes som svar på en forespørsel, "false" ellers. CS Angir om det er det innhentet samtykke fra pasient. Følgende muligheter skal finnes: - Ja, samtykke er innhentet - Svar på forespørsel e.l. som pasienten har gitt sitt samtykke til - Pasientens samtykke er ikke påkrevd i dette tilfellet - Nei, pasienten har ikke gitt sitt samtykke merknad (Merknad) produsert av programvare (progidref) 0.. ST Til fritt bruk Koder for status for innhenting av pasientens samtykke finnes i administrativt kodeverk nr IDREF Unik referanse til en beskrivelse av den programvaren som dette dokumentet er produsert av. S+to løpende sifre. "S0" KITH-rapport 46/03 Status: Til utprøving Side 30

31 opprinnlig journalført hos (virkid) innholdskategori (Innholdskat) innholdsbeskrivels e (Innhold) tidligste registrering (FraDato) seneste registrering (TilDato) 0.. IDREF Meldingsintern referanse til beskrivelse av den virksomhet, f.eks. det legekontor, som førte den pasientjournal dette dokumentet opprinnelig ble registrert i. Dersom et dokument f.eks. opprinnelig ble ført av en lege på legekontor A og senere overført til legekontor B, skal det her angis "legekontor A" dersom dokumente overføres fra legekontor B til legekontor C. Merk at virksomheten dokumentet opprinnelig ble journalført hos, ikke nødvendigvis er det samme som den virksomhet hvor informasjonen stammer fra. Er dokumentet f.eks. en epikrise som en fastlege har mottatt fra et sykehus og registrert i journalen, er det det legekontor fastlegen tilhører og ikke sykehuset som angis her. 0.. CV Dersom journaldokumentet kan knyttes til en standardisert informasjonskategori, kan kode for denne (og det kodeverk koden inngår i) angis her. 0.. ST Overskrift eller annen kort tekst som beskriver journaldokumentets innhold. TS Dato, eventuelt dato og klokkeslett, som angir når den elste delen av dokumentets innhold ble ført i journalen. 0.. TS Dato, eventuelt dato og klokkeslett, som angir når den yngste delen av dokumentets innhold ble ført i journalen. Dersom hele dokumentet ble registrert den dato som er angitt i "tidligste registrering", kan dette attributtet utelates Referanse (Referanse) Referanse/peker til det evt. vedlagte dokumentet. Dokumentet kan ligge direkte inkludert i EPH-meldingen, som et annet vedlegg i samme sending, eller finnes eksternt. Man bruker kun én av metodene. Det vanligste vil være å referere til en annen XML-melding i samme sending ved hjelp av XML-meldingens ID-nummer (med Id), eller referere til filnavn (bruk href). Med href er det også mulig å referere til ekstern plassering via f.eks. http eller ftp. Assosierte klasser: Er en del av 'Dokument' 'by value' id (Id) 0.. ST Det refererte dokumentets ID-nummer, f.eks. meldings-id hvis det er et XML-dokument. <Id>7997c94-0b3f-45-a263-0eeea2de86</Id> KITH-rapport 46/03 Status: Til utprøving Side 3

32 href (Href) 0.. URL Selve referansen (pekeren) til dokumentet. Dette er en URI som peker på filens posisjon og navn. XML-dokument (XmlDoc) <Href V=" <Href V="file://document.doc"/> <Href oc"/> 0.. ST For å legge inn XML-dokumenter direkte. Ved å benytte xs:any kan uavhengig XML legges inn i XmlDoc <XmlDoc> <Tilfeldig>XML</Tilfeldig> </XmlDoc> Kommentar: Beskrevet som en string (ST) av praktiske årsaker Programvaremiljø (Programvare) Denne klassen benyttes til å beskrive programvare som dokumentet er produsert med. Assosierte klasser: Er en del av 'EPJ-melding' 'by value' Inneholder 'Dokument' 'by reference' rolle: Produsert av meldingsintern programvare ID (progid) programvare type (TypeProgramvare ) produsent (Produsent) betegnelse (Betegnelse) ID Unik identifikasjon av programvaren innenfor journalsystemet. S+to løpende sifre. "S0" 0.. INT Angir hvilken type programvare dette er. Programvaretypene defineres i et eget, felles kodeverk med kodeverk ID = Koder for type programvare finnes i administrativt kodeverk nr ST Navn mv. på produsenten av programvaren. "Adobe" 0.. ST Leverandørens offisielle betegnelse for programvaren. "Acrobat" KITH-rapport 46/03 Status: Til utprøving Side 32

33 versjon (Versjon) 0.. ST Eventuell angivelse av en spesiell versjon, revisjon, patchnummer etc., for programvaren. merknad (Merknad) "5.0" 0.. ST Til fri bruk. KITH-rapport 46/03 Status: Til utprøving Side 33

34 4.6 Forespørsel og svar Forespørsel type forespørsel : CS kategori journalinformasjon : CV spørsmål i fritekst : ST hastegrad : CS kun informasjon yngre enn : TS kun informasjon eldre enn : TS formål med forespørsel : CS beskrivelse av formål : ST Svar 0.. kode for svar : CS begrunnelse for svar : ST svar i fri tekst : ST Diagram: Forespørsel og svar KITH-rapport 46/03 Status: Til utprøving Side 34

35 4.6. Forespørsel (ForespOmEpj) Forespørsel vedrørende journal - Type forespørsel : Ønsker å få oversendt hel journal / Ønsker å få overført en eller flere kategorier journalinformasjon / Spør om mottakeren vil ha tilsendt pasientens journal / Spør om mottakeren kan motta et sett av journaler for deponering / Spørsmålet er formulert i fri tekst - Kategori journalingormasjon (type CV) - Spørsmål i fri tekst - Ønsker kun informasjon fra perioden fra/til dato. - Formål med forespørselen : Ny pasient som det skal opprettes journal for / Helsehjelp til eksisterende pasient / Annet - Nærmere beskrivelse av formål med forespørselen - Hastegrad : Øyeblikkelig hjelp / Pågående helsehjelp / Innen 24 timer /Ubestemt Assosierte klasser: Spesialisering av 'Dokument' Er en del av 'Person' 'by value' Er en del av 'Programvaremiljø' 'by reference' rolle: Produsert av Inneholder 0.. 'Svar' 'by value' Inneholder 'Referanse' 'by value' meldingsinternt dokument ID (dokid) type innhold (TypeEpjMeldDok ) ID Benyttes kun for å opprettholde interne referanser i selve meldingen. "D0" CV Kode som angir hvilken type innhold dette dokumentet har. Koder for type innhold i dokumenter som overføres med EPJ-meldingen finnes i administrativt kodeverk nr Følgende muligheter finnes i dette kodeverket: - Forespørsel - Svar på forespørsel - Ustandardiserte journaldokument (FLO-melding) - Standardisert journal fra helsestasjonsjourn eller skolehelsetjeneste Kodeverket vil bli utvidet med nye verdier etterhvert som standardiseringen skrider fram. I tillegg kan det for bestemte formål benyttes egne kodeverk for kommunikasjon av andre typer dokumenter mellom kommunikasjonsparter hvor dette er avtalt på forhånd. Dette kan f.eks. benyttes for å overføre journaler ellerjournaldokumenter på proprietært format som instanser av "Annet Dokument". KITH-rapport 46/03 Status: Til utprøving Side 35

36 svar på forespørsel (SvarForesp) pasientsamtykke (Samtykke) merknad (Merknad) produsert av programvare (progidref) type forespørsel (TypeForesp) kategori journalinformasjon (KatEpjInfo) spørsmål i fritekst (Fritekst) BL Verdi "true" dersom journalinformasjon oversendes som svar på en forespørsel, "false" ellers. CS Angir om det er det innhentet samtykke fra pasient. Følgende muligheter skal finnes: - Ja, samtykke er innhentet - Svar på forespørsel e.l. som pasienten har gitt sitt samtykke til - Pasientens samtykke er ikke påkrevd i dette tilfellet - Nei, pasienten har ikke gitt sitt samtykke 0.. ST Til fritt bruk Koder for status for innhenting av pasientens samtykke finnes i administrativt kodeverk nr IDREF Unik referanse til en beskrivelse av den programvaren som dette dokumentet er produsert av. S+to løpende sifre. "S0" CS Kode som angir hva forespørselen gjelder Koder for type forespørsel vedr. overføreing av EPJ-informasjon finnes i administrativt kodeverk nr Ønsker å få oversendt hel journal - Ønsker å få overført en eller flere kategorier journalinformasjon - Spør om mottakeren vil ha tilsendt pasientens journal - Spør om mottakeren kan motta et sett av journaler for deponering - Spørsmålet er formulert i fri tekst 0.. CV Dersom forespørselen gjelder en bestemt kategori informasjon fra EPJ, kan kode for denne angis her. Koder kategori EPJ-informasjon beregnet ved overføring av journal ved bytte av fastlege finnes i administrativt kodeverk nr Også andre kodeverk kan benyttes, under den forutsetning at avsender og mottaker er enige om dette. 0.. ST Ved behov kan spørsmål formuleres i fri tekst. KITH-rapport 46/03 Status: Til utprøving Side 36