Implementasjonsguide for elektronisk sykmeldingsattest

Transkript

1 Implementasjonsguide for elektronisk sykmeldingsattest Basert på RTV blankett IA Fastsatt 6.88 Endret juni 2003 Status: "Til utbredelse" KITH Rapport 21/03 ISBN

2

3 KITH-rapport TITTEL Implementasjonsguide for elektronisk sykmeldingsattest Status: "Til utbredelse" Forfatter Espen Stranger Seland Oppdragsgiver Rikstrygdeverket Kompetansesenter for IT i helsevesenet AS Postadresse Sukkerhuset 7489 Trondheim Besøksadresse Sverresgt 15, inng G Telefon Telefaks e-post firmapost@kith.no Foretaksnummer Rapportnummer KITH R 21/03 URL Prosjektkode ISBN Dato 01. juni 2003 Antall sider 76 Kvalitetssikret av Annebeth Askevold Gradering Åpen Godkjent av Jacob Hygen adm. direktør Sammendrag Denne implementasjonsguiden er utarbeidet på oppdrag fra Rikstrygdeverket. Den beskriver en melding i XML-syntaks, basert på informasjonsinnholdet i blankettene Sykmeldingsattest og Legeerklæring ved arbeidsuførhet som er beskrevet i rapporten "KITH R20/03 Sykmeldingsattest og Legeerklæring ved arbeidsuførhet, Informasjonsmodell for elektronisk meldingsutveksling versjon 2.1 av Dette dokumentet beskriver selve XML-skjemaet, en del detaljer rundt selve implementeringen, kodeverk som skal benyttes samt noen eksempler. Detaljert beskrivelse av informasjonsinnholdet finnes i informasjonsmodellen. Meldingen er beskrevet som et XML Schema som finnes elektronisk på Meldingen er direkte basert på UML-modellen som er beskrevet i informasjonsmodellen. Meldingen inkluderer støtte for elektronisk signering i selve sykmeldingen, ved hjelp av en PKI-løsning med personlige digitale sertifikat og XML DSig. Meldingen har vært utprøvd i pilotprosjekt og er klar for utbredelse. Dette dokumentet erstatter "KITH R14/02 Implementasjonsguide for elektronisk sykmeldingsattest versjon 2.0" av

4

5 Forord Forord Denne rapporten er utarbeidet på oppdrag fra Rikstrygdeverket og er en revisjon av KITH R14/02 Implementasjonsguide for elektronisk sykmeldingsattest, versjon 2.0 av Denne revisjonen inkluderer støtte for elektronisk signering i selve sykmeldingen, ved hjelp av en PKIløsning med personlige digitale sertifikat og XML Dsig. Meldingen har også vært gjennom en utprøvingsfase og endrer status fra "Til utprøving" til "Til utbredelse". Det er også lagt til en nytt kodeverksvalg (ICPC-2), og det er gjort mindre syntaktiske utbedringer på XML-standarden. Forord versjon 2.0 Denne rapporten er utarbeidet på oppdrag fra Rikstrygdeverket og er en revisjon av KITH R16/01 Implementasjonsguide for elektronisk sykmeldingsattest, versjon 1.0 av Bakgrunnen for revisjonen er endringer i sykmeldingsattesten som ble innført med virkning fra Implementasjonsguiden og XML Schema som er utarbeidet i dette oppdraget er en direkte revisjon av tidligere utarbeidet dokumentasjon for å inkludere endringene i den nye papirblanketten samtidig som det er vektlagt å ikke endre fellesdeler og forhold som vedrører delen for legeerklæring ved arbeidsuførhet. Informasjonsmodellen er revidert etter samme prinsippene, og denne meldingsbeskrivelsen er direkte avledet av informasjonsmodellen beskrevet i KITH R13/02 Sykmeldingsattest og Legeerklæring, Informasjonsmodell for elektronisk meldingsutveksling versjon 2.0 av Forord versjon 1.0 Denne rapporten er utarbeidet på oppdrag fra Rikstrygdeverket. Den beskriver en melding i XML-syntaks, basert på informasjonsinnholdet i blankettene Sykmeldingsattest og Legeerklæring ved arbeidsuførhet som er beskrevet i rapporten KITH R15/01 Sykmeldingsattest og Legeerklæring, Informasjonsmodell for elektronisk meldingsutveksling. Det er ikke tidligere utarbeidet noen implementasjonsguider for XML-meldinger til bruk i det norske helsevesenet. Leserne oppfordres derfor til å rapportere uklarheter, eventuelle feil og mangler samt forslag til forbedringer i dokumentasjonen. Rapporten er utarbeidet i nært samarbeid med oppdragsgiveren. KITH vil benytte anledningen til å takke for aktiv medvirkning og nyttige tilbakemeldinger. Status: Til utprøving i

6

7 Innholdsfortegnelse Implementasjonsguide for elektronisk sykmelding Innholdsfortegnelse Implementasjonsguide for elektronisk sykmeldingsattest 1 Basert på 1 RTV blankett IA Fastsatt 6.88 Endret Innledning Bakgrunn Bruksområder Leserveiledning Om dette dokumentet 2 2 Referanser 3 3 Meldingens bruksområder Funksjon Begrensninger 5 4 Notasjon Forhold til standarder og arbeid 7 Syntaks 7 Utførelse og sammenheng med andre XML-meldinger Mapping fra DIM til XML 8 Element eller attributt 8 Uoverensstemmelser 8 Validering 8 Namespace 8 Datatyper 8 Navnepolitikk 9 Metainformasjon 10 5 Meldingens innhold og struktur Meldingsstruktur 11 Oversikt SykmeldingsattestHierarkisk oversikt over sykmeldingsattest Informasjonsmodell 18 UML-diagram for Sykmelding (uten personopplysninger) 18 UML-diagram for Personopplysninger 19 iii

8 Innholdsfortegnelse 5.3 Detaljer rundt implementeringen Kodeverk Digital signatur 23 Kryptering 24 6 XML Schema Skjema 25 Vedlegg A Meldingseksempler 45 Eksempel 1 Førstegangs sykmelding 45 Eksempel 2 Endring av uføregrad 47 Eksempel 3 Forlengelse med friskmelding 49 Eksempel 4 Første gang sykmelding med del II 51 Eksempel 5 Første gangs sykmelding med feil og ugyldig fødselsnummer53 Eksempel 6 Første gangs sykmelding annen fraværsgrunn 55 Eksempel 7 Første gangs sykmelding med flere diagnoser og merknad 57 Eksempel 8 Første gangs sykmelding for en selvstendig næringsdrivende59 Vedlegg B Eksempler ordinære papirskjemaer 61 Eksempel 1 Førstegangs sykmelding 62 Eksempel 2 Endring av uføregrad 63 Eksempel 3 Forlengelse med friskmelding 64 Eksempel 4 Første gang sykmelding med del II 65 Eksempel 5 Første gangs sykmelding med feil og ugyldig fødselsnummer66 Eksempel 6 Første gangs sykmelding annen fraværsgrunn 67 Eksempel 7 Første gangs sykmelding med flere diagnoser og merknad 68 Eksempel 8 Første gangs sykmelding for en selvstendig næringsdrivende69 iv

9 Innledning 1 Innledning Dette kapittelet gir en kort beskrivelse av dokumentet: Bakgrunn for arbeidet, bruksområder av dette dokumentet, samt en oversikt over innholdet og veiledning til hvordan dokumentet kan benyttes. 1.1 Bakgrunn I Rikstrygdeverkets prosjekt for elektronisk innrapportering av saksdokumenter, EI@, prioritereres arbeidet med å etablere meldinger for elektronisk innsending av sykemeldingsattest og legeerklæring ved arbeidsuførhet. Arbeidet med meldingene ble påbegynt sommeren 2001 da det fantes liten erfaring med å benytte XML Schema til meldingsdokumentasjon. Denne meldingen avviker derfor noe fra nyere meldingen som er utviklet for bruk innenfor helsevesenet. Meldingen har vært utprøvd og er klar til utbredelse i stor skala. Meldingsdokumentasjonen ble første revidert våren 2002 på grunn av endringer i regelverket med medfølgende endringer i sykmeldingsattesten med virkning fra Denne revisjonen inkluderer støtte for elektronisk signering i selve sykmeldingen, ved hjelp av en PKI-løsning med personlige digitale sertifikat og XML DSig, og endrer status på meldingen til "Til utbredelse". Informasjonsmodellen som beskriver informasjonsinnholdet og den logiske strukturen i blankettene Sykmeldingsattest og Legeerklæring ved arbeidsuførhet [1] er revidert etter samme prinsippene. Denne rapporten er en revisjon av og erstatter KITH R16/01 Implementasjonsguide for elektronisk sykmeldingsattest, versjon 1.0 av og KITH R14/02 Implementasjonsguide for elektronisk sykmeldingsattest, versjon 2.0 av Meldingen er direkte basert på UML-modellen som er beskrevet i informasjonsmodellen[1]. Meldingen er beskrevet som et XML Schema som finnes elektronisk på Siste versjon per 01. juni 2003 er rtv-smlepo-v068.xsd. Den elektroniske sykmeldingsattesten skal brukes sammen med det norske rammeverket for elektronisk kommunikasjon i helsevesenet, basert på ebxml [13]. 1.2 Bruksområder Dokumentet beskriver hvordan Rikstrygdeverket sin blanketten sykmeldingsattest "IA Bokmål Fastsatt 6.88 Endret " skal overføres elektronisk ved hjelp av XML-syntaks. Meldingen er basert på blanketten for sykmeldingsattesten og Rikstrygdeverkets retningslinjer[2]. Beskrivelsen gjelder kun del A av blanketten (fra legen til Trygdeetaten). Meldingen til pasient og arbeidsgiver må fremdeles skrives ut på papirblanketter. 1

10 Innledning 1.3 Leserveiledning Dokumentet er myntet på leverandører og it-personell som skal implementere meldingen. Dokumentet inneholder mye tekniske detaljer som kun er relevant for de som skal implementere meldingen. Dokumentet beskriver selve XML-skjemaet, en del detaljer rundt selve implementeringen, meldingsspesifikke kodeverk som skal benyttes samt noen eksempler. Detaljert beskrivelse av informasjonsinnholdet finnes i informasjonsmodellen[1] og er ikke repetert i dette dokumentet. Det anbefales at informasjonsmodellen benyttes som tilleggsinformasjon til dette dokumentet når meldingen skal implementeres. XML-skjemaet er basert direkte på informasjonsmodellen som beskriver informasjonsinnholdet i blankettene Sykmeldingsattest og Legeerklæring ved arbeidsuførhet. Sykmeldingsattesten er basert på blanketten "IA Bokmål Fastsatt 6.88 Endret " og Rikstrygdeverkets retningslinjer[2]. Alle referanser finnes på side 3. For de som ikke er kjent med XML og XML Schema henvises det til referansene [3] og [4]. For å forbedre dokumentasjonen og sikre ensartet implementering, oppfordres leserne til å rapportere eventuelle feil eller uoverensstemmelser i dokumentasjonen til KITH og/eller RTV. Leserne oppfordres også til å komme med forslag til hvordan innhold og presentasjon kan gjøres bedre i fremtiden. 1.4 Om dette dokumentet Dokumentet er organisert på følgende måte: Kapittel 2 inneholder opplysninger om referanser og dokumenter som denne rapporten er basert på og henviser til. Kapittel 3 forteller om meldingens funksjon, bruksområder og begrensninger. Kapittel 4 beskriver litt av metodikken om hvordan meldingen er utarbeidet og valg som er gjort i forhold til navnepolitikk, datatyper og bruk av XML. Kapitelet inneholder også en kortfattet beskrivelse av sammenhengen mellom UML-modellen og XML Schema. Kapittel 5 beskriver hvordan meldingen er bygget opp. Her er det inkludert UML-diagram fra informasjonsmodellen. Kapittelet kan leses av personer uten teknisk bakgrunn. Kapittel 6 inneholder selve XML-skjemabeskrivelsen. Vedlegg A inneholder eksempler på XML-meldinger Vedlegg B inneholder tilhørende papirblanketter av eksemplene i vedlegg A. 2

11 Referanser 2 Referanser Dette dokumentet er basert på og henviser til følgende dokumenter: 1. KITH R20/03: Sykmeldingsattest og Legeerklæring ved arbeidsuførhet Informasjonsmodell for elektronisk meldingsutveksling av , ISBN Rikstrygdeverket: Retningslinjer til leger om utstedelse av sykmeldingsattest. 3. Extensible Markup Language (XML) 1.0 (Second Edition): 4. XML Schema a. Part 0: Primer: b. Part 1: Structures: c. Part 2: Datatypes: 5. SSP FG1: 6. Health Level 7 (HL7): 7. Unified Modeling Language (UML): 8. Statistisk Sentralbyrå: C 521 Standard for yrkesklassifisering (STYRK) ISBN KITH R 17/01: Datatyper til bruk ved meldingsutveksling med mer, Versjon 1.1, 1. februar 2002, ISBN XML-Signature Syntax and Processing. W3C Recommendation 12 February 2002: Exclusive XML Canonicalization Version 1.0. W3C Recommendation 18 July 2002: ENV : Health informatics - Security for healthcare communication - Part 2: Secure data objects.europeisk prestandard, mars KITH R25/02: Rammeverk for elektronisk kommunikasjon i helsevesenet, basert på ebxml. Versjon 0.9. Versjon 1.0 kommer høsten

12

13 3 Meldingens bruksområder Implementasjonsguide for elektronisk sykmelding Meldingens bruksområder Dette kapittelet inneholder en beskrivelse av hvilke funksjoner meldingen skal dekke. Det er også påpekt noen begrensninger knyttet til hvordan meldingen kan benyttes. 3.1 Funksjon Elektronisk sykmeldingsattest (ESMA) som er beskrevet i dette dokumentet, dekker informasjon som kan overføres i Rikstrygdeverket sin blankett for sykmeldingsattest "AI Bokmål Fastsatt 6.88 Endret " og Rikstrygdeverkets retningslinjer[2]. Elektronisk overført sykmelding skal kunne likestilles med papirskjemaet. ESMA sendes fra lege, eller annet helsepersonell som er berettiget til å utstede sykmelding, til Rikstrygdeverket. Meldingen er beskrevet som et XML Schema. Dette skjemaet ligger lagret elektronisk på Begrensninger Denne meldingen dekker kun del A av sykmeldingsattesten som går fra legen til Trygdeetaten. Del B, C og D vil fortsatt formidles på papir. 5

14

15 Notasjon 4 Notasjon 4.1 Forhold til standarder og arbeid Syntaks Den elektroniske meldingen som er beskrevet i dette dokumentet skal overføres som en XMLmelding[3]. Meldingen er definert ved hjelp av et XML Schema som er nærmere beskrevet i kapittel 6 XML Schema. XML SCHEMA XML Schema [4.c] benyttes til å definere regler for struktur, innhold og semantikk, som et spesifikt XML-dokument (for eksempel en sykmeldingsattest) kan valideres opp mot. XML XML er et strukturert tekstformat for data, som er meget velegnet til elektronisk dokumentutveksling (EDI). Utførelse og sammenheng med andre XML-meldinger Første versjon av denne meldingen ble utviklet da det fantes få retningslinjer som anga hvordan en elektronisk melding beskrevet ved hjelp av XML-syntaks skulle defineres og beskrives for å kunne bli benyttet til bruk innen det norske helsevesenet. Det pågår mange aktiviteter, både nasjonalt og internasjonalt i forhold til å benytte XML ved meldingsutveksling (EDI) generelt, og til bruk innenfor helsevesenet spesielt. Standardiserings- og samordningsprogrammet har utarbeidet noen retningslinjer for hvordan XML skal benyttes ved meldingsutveksling innenfor helsevesenet i Norge, basert på internasjonalt arbeid. Denne metodikken erbare delvis fulgt i denne meldingsdokumentasjonen siden dette er en ren revisjon av arbeid som ble utført høsten 2001 da denne metodikken ikke var ferdig. Meldinger som utarbeides for andre formål innenfor helsesektoren kan derfor avvike noe fra strukturen på meldingen, benyttede datatyper og modelleringsprinsipper som er beskrevet i dette dokumentet. Arbeidet i dette dokumentet er gjort så enkel som mulig når det gjelder bruk av datatyper, variabler og strukturering. Det har vært høyt prioritert å komme i gang med pilottesting av meldingen. og høste erfaringer med overføringer av XML-meldinger. Det har ikke vært ønskelig at endringene i sykmeldingsattesten skulle påvirke selve metodikken i meldingsdokumentasjonen som ble utarbeidet høsten I denne versjonen er det benyttet standard XML datatyper. Det kan i en senere versjon være aktuelt å gå over til å benytte datatyper som er definert i [9] som er basert på HL7 sine datatyper når disse er utprøvd og benyttet i andre meldinger. 7

16 Notasjon 4.2 Mapping fra DIM til XML Element eller attributt I all hovedsak er data (informasjon som skal behandles) lagt i et element, mens metainformasjon er lagt i et attributt i det relevante elementet. Denne regel er ikke blitt brukt gjennomgående i dette dokumentet, men det finnes en god balanse i skjemaets struktur. Av og til kan det være vanskelig å skille mellom data og metadata. Uoverensstemmelser Hvis det finnes uoverensstemmelser mellom DIM en og IG en, i praksis UML-diagrammene (se [1]) og XML-skjemaet, er det IG/XML-skjemaet som har presedens. For å forbedre dokumentasjonen og sikre ensartet implementering, oppfordres leserne til å rapportere uoverensstemmelser i dokumentasjonen til KITH og/eller RTV. XML Validering XML-skjemaet har blitt validert i henhold til XML Schema-standarden med verktøyene XMLSpy 5.3 og XSV 1.204/ 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 2001, og er per dags dato siste versjon av XML Schema. SKJEMA Skjemaet skal være lokalisert på KITHs server. Dette er en avtale mellom RTV og KITH. Datatyper targetnamespace= " xmlns:rtv=" Det er brukt basale XML Schema-datatyper[4.c]. KITH benytter nå datatyper som er basert på HL7 datatyper og CEN sine anbefalinger vedrørende datatyper og som er beskrevet i [9]. Denne definisjonen var ikke klar da første versjon av meldingsbeskrivelsen ble utarbeidet. Siden dette er en revisjon av tidligere meldingsdokumentasjon; har prosjektet besluttet å benytte XML datatyper direkte på tilsvarende måte som i versjon 1.0. KODEVERK Alle attributter som har forhåndsdefinerte valg, er definert som datatypen kodet, og det er etablert et meldingsspesifikt kodeverk som inneholder lovlige valg. Hvert kodeverk er implementert som en simpletype med en enumeration for hvert lovlige valg. Alle kodeverk som er benyttet i meldingen, er beskrevet i avsnitt 5.4 Kodeverk 8

17 Notasjon I selve skjemabeskrivelse" (se kapittel 6), er den tekstlige beskrivelsen for kodene lagt inn i taggen <documentation>. Alle kodeverdier er basert på nonnegativeinteger. For oversikt over de inkluderte kodeverkene, se Kodeverk side 21. TYPEVARIGHETDATO Det er opprettet et complex element med navn typevarighetdato som benyttes til å beskrive et tidsrom mellom to datoer. Elementet inneholder attributtene TYPETEKST fradato(date) tildato(date) Det er opprette en Simple type med navn typetekst, basert på string med whitesp= preserve Denne datatypen benyttes til utførende beskrivelser i sykmeldingen der det er viktig å bevare linjeskift og mellomrom. Navnepolitikk Hvert element og attributt har et egen navn. Disse navnene, som er kortnavn i informasjonsmodellen, er basert på tekstene foran hvert felt i blanketten. ELEMENTER Elementnavn har stor forbokstav. I elementnavn som består av flere delnavn / delord, vil hvert delnavn / delord skilles med stor forbokstav. Eksempel: ATTRIBUTTER SykmeldGjelder Attributtnavn har liten forbokstav. I attributtnavn som består av flere delnavn / delord, vil hvert delnavn / delord skilles med stor forbokstav. Eksempel: TYPER flerearbeidsforhold Både complextype og simpletype begynner alltid med betegnelsen type, og påfølgende navn begynner med stor forbokstav. Navn som består av flere delnavn / delord, vil bli atskilt med stor forbokstav mellom hvert delnavn / delord. Eksempel: NORSKE BOKSTAVER typesykmelding Følgende transkribering foretrekkes: Æ = E Ø = O Å = A Dette for å holde navnene korte. Der misforståelser kan forekomme tillates det å bruke formene ae, oe og aa i kortnavnene. 9

18 Notasjon 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, heller ikke innbyrdes avengigheter eller sjekk av algoritme for lovlig fødselsnummer Det forutsettes at denne type betingelser blir håndtert av avsenderapplikasjonen. Det er mange felt som har knyttet betingelser til hvilken type informasjon datafeltet kan inneholde og hvilke felt som kan benyttes samtidg. Denne informasjonen finnes under Detaljer rundt implementeringen side

19 Meldingens innhold og struktur 5 Meldingens innhold og struktur Dette kapittelet beskriver meldingens innhold og struktur. Den hierarkiske meldingsstrukturen er vist ved hjelp av grafiske oversikter generert fra XML Spy. Noen UML-diagrammer fra informasjonsmodellen er repetert i dette dokumentet for å lette oversikten og øke lesbarheten. Kapittelet inneholder også en tabell med relevante detaljer og betingelser som må tas hensyn til ved implementering av meldingen. Dette kapittelet er primært til bruk for de som skal implementere meldingen og trenger forståelse for hvordan informasjonen skal overføres ved hjelp av XML syntaks. 5.1 Meldingsstruktur Den enkelte melding omfatter kun en sykmeldingsattest og et sykmeldingstilfelle. Hvis pasienten har flere arbeidsforhold må det sendes en melding (en sykmeldingsattest) for hvert arbeidsforhold. Den funksjonelle struktur av meldingen er: En melding kan inneholde en sykmeldingsattest Hver sykmeldingsattest er relatert til kun et arbeidsforhold. Hver sykmeldingsattest er relatert til et sykmeldingstilfelle. Alle svarrapporter i meldingen er relatert til en lege eller annet helsepersonell som kan utstede sykmeldinger, en pasient og et trygdekontor. Hierarkisk oversikt over sykmeldingsattest Alle bokser med todo har et hierarki med elemneter under seg som er vist på følgende figurer. Det er kun elementer som vises i diagrammene. Attributter vises kun i informasjonsmodellen og i UMLdiagrammene. 11

20 Meldingens innhold og struktur Figur 1 Hierarkisk oversikt over sykmeldingsattest 12

21 Meldingens innhold og struktur Figur 2 Opplysninger om personen og om arbeidsforholdet, blokk 1 13

22 Meldingens innhold og struktur Figur 3 Opplysninger om arbeidsuførhet og arbeidsmulighet, blokk 2 Figur 4 Opplysninger om Friskmelding / Prognose, blokk 3 14

23 Meldingens innhold og struktur Figur 5 Opplysninger om Diagnose mv., blokk 4 Figur 6 Opplysninger om legens underskrift mv., blokk 6 15

24 Meldingens innhold og struktur Figur 7 Opplysninger om Medisinske opplysninger, blokk 7 (del II) Figur 8 Opplysninger om Forenklet funksjonsvurdering, blokk 8 (del II) 16

25 Meldingens innhold og struktur Figur 9 Oversikt over elementet for XML Digital Signature 17

26 Meldingens innhold og struktur 5.2 Informasjonsmodell Deler av informasjonsmodellen er inkludert for å få et enkelt overblikk over hva skjemaet er basert på. Informasjonsmodellen er beskrevet ved hjelp av Unified Modeling Language (UML)[7]. Personopplysninger er tatt ut i et eget diagram av praktiske årsaker. Klassen Melding er felles i begge diagrammene og er toppen i meldingshierarkiet. Detaljert beskrivelse av informasjonsinnholdet finnes i informasjonsmodellen[1] og er ikke repetert i dette dokumentet. Det anbefales at informasjonsmodellen benyttes som tilleggsinformasjon til dette dokumentet når meldingen skal implementeres. UML-diagram for Sykmelding (uten personopplysninger) 6 /11Legens underskrift mv. (from 1+S6/L11 Pasient og legeopplysninger) 1 Pasientopplysninger (from 1+S6/L11 Pasient og legeopplysninger) Digital signatur 0 Sykmeldingen gjelder type sykmelding : kodet Melding maalform : kodet avsendersref : string mottagersref : string skjema-versjon : string meldingsid : string melding generert : datetime Sykmeldingsattest 5 Merknad : tekst 1 +Del II Varighet 2.4 arbeidsufør fra dato : date 2.4 arbeidsufør til dato : date grad : integer Arbeidsuførhet/arbeidsmulighet 2.1 Første fraværsdag : date 2.2 Dato første konsultasjon : date 2.3 Dato telefonkonsultasjon : date 2.7 antall behandlingsdager : tekst 2.6 Personen kan ikke være på jobb 2.6 Personen kan ikke være på jobb : boolean 2.5 Forutsetninger for å jobbe Reisetilskudd foreslås fra : date Aktiv sykmelding fra : date Eventuelt : tekst 7 Medisinske opplysninger 7.1 Symptomer, status og pågående behandling : tekst 7.2 Spesifiser type og hvor : tekst Henvist til utredning/behandling 7.2 henvist : kodet 7.2 uke : integer Friskmelding/Prognose 3.2 Arbeidsufør antas fortsatt arbeidsufør : integer 3.1 Friskmeldt friskmeldt fra dato : date 8 Forenklet funksjonsvurdering 8.2 Hva bør personen ikke utføre eller utsettes for : tekst 8.3 Hjelpemiddelbehov bør vurderes : boolean 8.4 Forhold i arbeidsmiljøet : tekst 8.5 Foreslår kontakt med BHT : boolean Del II 1 S4 Diagnose og arbeidssituasjon Svangerskapsrelatert : boolean 4.3 Annen lovfestet fraværsgrunn : string Yrkessykdom : boolean Yrkesskade : boolean Eventuell skadedato : date S4/L2 Diagnosekodesystem S4.2/L2.3 kodesystem : kodet Vurdering av funksjonsevnen type vurdering : kodet svar : kodet nå/etter : kodet 0..1 S S1.8.2 Identifikasjon Personen er kjent : boolean Legitimasjon er vist : boolean 1..* S4/L2 Enkeltdiagnose S4.1/L diagnose : string S4.1.2/L kodeverdi : string xx sortering : integer 18

27 Meldingens innhold og struktur UML-diagram for Personopplysninger Melding (from Meldingspakke (inkludert merknader og samarbeid/kontakt)) 1 6 /11Legens underskrift mv. dato for underskrift : date Helsepersonell helsepersonellnummer : string kategori helsepersonell : kodet type helsevirksomhet : kodet 1 1 Pasientopplysninger har flere arbeidsforhold : kodet 1 Pasient 1.3 trygdekontor : string Person fødselsnummer : string etternavn : string mellomnavn : string fornavn : string 1 0..* Persons adresse Arbeidsforhold yrkeskode : string 1 0..* primært arbeidsforhold : kodet yrkebetegnelse : string 0..* 0..1 Virksomhet betegnelse : string Organisasjonsnummer : string Virksomhets adresse Postadresse gateadresse : string postnummer : string poststed : string land : string Adresse adressetype : kodet 1 0..* Teleinformasjon type telekommunikasjon : Kodet teleadresse : string 19

28 Meldingens innhold og struktur 5.3 Detaljer rundt implementeringen Tabellen under beskriver en kortfattet representasjon av relevante detaljer og betingelser som må tas hensyn til ved implementering av meldingen. Informasjonsinnholdet er beskrevet detaljert i informasjonsmodellen [1]. De fleste kommentarene i denne tabellen finnes i informasjonsmodellen under feltene "Bruk" eller "Kommentar" i beskrivelsen. Kolonnen Klassenavn inneholder klassenavn fra UML-modellen, tagnavn i parentes. Kolonnen Element/Attributtnavn inneholder tagnavn brukt i XML Schema Kolonnen Bruk og kommentarer inneholder betingelser som er knyttet til informasjonselementet Kolonnen til høyre sier om informasjonen er påkrevd (M), betinget påkrevd (D) eller frivillig (O). KLASSENAVN ELEMENT/ATTRIBUTTNAVN BRUK OG KOMMENTARER Melding (Message) sendersid Benyttes som intern referanse i avsendersystemet. Dette feltet finnes ikke i dagens papirskjema. receiversid Benyttes som intern referanse i mottagersystemet. Dette feltet finnes ikke i dagens papirskjema. formoflanguage Denne opplysningen er knyttet til målformen på papirskjemaet. Opplysningen må oppgis for at RTV skal vite hvilken målform som skal benyttes ved skriftlig tilbakemelding. schemaversion Beskriver hvilken versjon av XML-schema som benyttes. Skal ha fast verdi IA Fastsatt 6.88 Endret Elektronisk XML 2.0 messageid Det er viktig at det ikke genereres meldingsid på grunnlag av personnummer eller annen sensitiv informasjon, da denne identifikasjonen også vil bli brukt ukryptert i f.eks. kvitteringsmeldingen. Digital signatur (ds:signature) ds:signature Elementet er i XML Schema-definisjonen satt til O, men dette er kun for å gjøre implementering lettere i en overgangsfase. Se kapittel 5.5 for bruk. Sykmeldingen gjelder (SykmeldGjelder) Identifikasjon (Identifikasjon) Pasientopplysninger (Pasientopplysninger) Adresse (Address) Virksomhet (Virksomhet) Enkeltdiagnose (Enkeltdiagnose) typesykmelding Kjent Legitimasjon flerearbeidsforhold typeadresse organisasjonsnummer diagnose Kode 1 og 2 kan ikke forekomme i samme instans av meldingen. Kode 1 og 3 kan ikke forekomme i samme instans av meldingen. Hvis opplysninger i Del II skal kunne fylles ut ("Medisinske opplysninger" og "Forenklet funksjonsvurdering", må det finnes en instans av attributtet med kodeverdi 4 (Informasjon i del II) Eneste lovlige verdi er true. Hvis felt "Personen er kjent" er avkrysset skal Kjent ha verdien true. Hvis elementet "Kjent" har verdi=true skal ikke element "Legitimiasjon" være med. Eneste lovlige verdi er true. Hvis felt "Legitim. er vist" er avkrysset skal Legitimasjon ha verdien true. Hvis elementet "Legitimasjon" har verdi=true skal ikke element "Kjent" være med. Har kun mening for sykmeldingsattest, og skal ha verdi selv om felt 1.7 "Har personen flere arbeidsforhold" ikke er avkrysset. Attributtet skal ha verdi 1 (ja) hvis felt 1.7 er avkrysset, verdi 2 (nei) hvis feltet ikke er avkrysset. Denne opplysningen oppgis ikke spesifikt i dagens blankett. Er tatt med for fremtidig bruk. Denne opplysningen er ikke påkrevd på dagens blankett. Tatt med for fremtidig bruk. Tekstlig kodemening som hører til kodeverdien. Må benyttes sammen med attributtet "kodeverdi" og attributtet " kodesystem". Tilhørende diagnosekode må oppgis i attributtet " kodeverdi". Behøver ikke være utfylt hvis elementet AnnenFraversgrunn har verdi. O O M M O M M D D D O O D 20

29 Meldingens innhold og struktur Diagnose og arbeidssituasjon (DiagnoseArbeidssituasjon) Forutsetninger for å jobbe (Forutsetninger) kodeverdi Diagnosekoden Må benyttes sammen med attributtet "SM / LE kodeverdi" og attributtet "SM 4.2 / LE 2.3 kodesystem". Tilhørende tekstlig kodemening må oppgis i attributtet "SM / LE kodeverdi". Behøver ikke være utfylt hvis elementet AnnenFraversgrunn har verdi. sortering Sorteringsrekkefølge: 0=hoveddiagnose, 1=første bidiagnose, 2=andre bidiagnose, osv. Sorteringsrekkefølge må oppgis ved bruk av multippelt kodeverk. AnnenFraversgrunn Enten alle feltene 4.1 (diagnose), (kodeverdi) og 4.2 (kodesystem), og/eller felt 4.3 (annenfravarsgrunn) må være utfylt. Må fylles ut hvis feltene 4.1 (diagnose), (kodeverdi) og 4.2 (kodesystem) ikke har verdier. Yrkessykdom Skal kun ha verdi når felt "Bør trygdekontoret vurdere om det er en yrkessykdom?" er sann. Skal da ha verdien "true". Yrkesskade Skal kun ha verdi når felt "Bør trygdekontoret vurdere om det er en yrkesskade?" er sann. Skal da ha verdien "true". Forutsetninger Forutsetninger er med hvis felt 2.5 "Personen kan likevel være på jobb under forutsetning av" er aktuell. Forutsetninger kan ikke ha verdi hvis IkkeJobb=true. ReisetilskuddFra Minst et av elementene må ha verdi hvis felt 2.5 "Personen kan AktivSykmeldFra likevel være på jobb under forutsetning av" er aktuell Eventuelt Kan kun fylles ut hvis "Aktiv sykmelding foreslås fra D (dato)" (AktivtSykmeldtFra) er utfylt. Personen kan ikke være på jobb IkkeJobb IkkeJobb har verdien true hvis felt 2.6 "Personen kan ikke D (IkkeJobb) være på jobb" er avkrysset. IkkeJobb kan ikke ha verdi hvis Forutsetninger er med. Arbeidsuførhet/arbeidsmulighet ForsteFraversdag Må angis ved første gangs utfylling. Dvs. hvis D (ArbeidsuforhetSykmelding) sykmeldingsattest felt 0.1 er utfylt, så skal også felt 2.1 være utfylt. Det er anbefalt at første fraværsdag alltid fylles ut, også ved forlengelse av sykmeldingstilfellet. ForsteKonsultasjon Må angis ved første gangs utfylling. Dvs. hvis D sykmeldingsattest felt 0.1 er utfylt, så skal også felt 2.2 være utfylt. DatoTlfKonsultasjon Et av elementene, "ForsteFraversdag", "ForsteKonsultasjon", må være utfylt. D ArbeidsuforBehandlingsdager Dette elementet skal være med hvis felt 2.7 "Enkeltstående D behandlingsdager pr. uke/mnd" er avkrysset. Må oppgis hvis pasienten er 100% arbeidsufør de dagene behandlingen gis, men fullt arbeidsfør de andre dagene. Eksempel: 2 dager per uke. Varighet (Varighet) fradato Fra dato <= til dato.må fylles ut hvis felt 0.1 (Første attest for dette sykmeldingstilfellet) eller felt 0.2 (Forlengelse av D sykmeldingstilfellet) er avkrysset. tildato Fra dato <= til dato.må fylles ut hvis felt 0.1 (Første attest for D dette sykmeldingstilfellet) eller felt 0.2 (Forlengelse av sykmeldingstilfellet) er avkrysset. grad Tall i prosent. M Skal alltid fylles ut. Hvis personen er helt arbeidsufør skal tallet være 100. Vurdering av funksjonsevne naetter Må fylles ut hvis svar har kodeverdi "ja". D svar Hvis svar er "nei", må felt 8.2 fylles ut. D Hvis svar er "ja", må "nå/etter" fylles ut. ikkeutforeutsette Må utfylles hvis det er svart "nei" i felt 8.1 ("svar" i vurdering av D funksjonsevne). Medisinske opplysninger i del II Behandling Må fylles ut når felt 0.4 er avkrysset (Informasjon i del II). D D D D D D D D D 21

30 Meldingens innhold og struktur 5.4 Kodeverk Tabellen under viser en oversikt over kodeverkene som er benyttet i elektronisk sykmeldingsattest. Forklaringene finnes også i documentation-elementet under annotation-elementet sammen med alle definerte valg, eksempelvis: <enumeration value="le"> <documentation>lege</documentation> NAVN TypeSykmelding typejaneivetikke TypeHenvisning TypeVurdering TypeFormOfLanguage TypeKodesystem MERK! Kun kode 1, 3 og 4 er lovlige valg for sykmeldinsattest selv om skjemaet inneholder 4 valg. Kodeverdiene avviker også noe fra kodeverdiene på papirblanketten. KODEVERDI / KODEMENING 1 Første attest for dette sykmeldingstilfellet 2 Forlengelse av sykmeldingstilfellet 3 Endringer 4 Informasjon i Del II 5 Legeerklæring ved sykefravær i mer enn 8 uker er sendt 1 Ja 2 Nei 3 Vet ikke 1 Henvist til utredning 2 Henvist til behandling 3 Anbefalt til kjøp av helsetjeneste 1 Antas personen å kunne gjenompta nåværende arbeid 2 Antas personen å ha behov for tilrettelagt arbeid 3 Antas personen å ha behov for annet arbeid 1 Bokmål 2 Nynorsk 1 ICPC 3 ICD-10 4 ICPC-1 5 ICPC-2 typejanei typehelsepersonell 1 Ja 2 Nei BI Bioingeniør ET Ergoterapeut FA Farmasøyt FO Fotterapeut FT Fysioterapeut HP Hjelpepleier HS Helsesøster JO Jordmor KI Kiropraktor LE Lege OI Ortopediingeniør OP Optiker PS Psykolog RA Radiograf SP Sykepleier TL Tannlege TP Tannpleier VE Veterinær VP Vernepleier AA Ambulansearbeider AT Apotektekniker AU Audiograf HE Helsesekretær KE Klinisk ernæringsfysiolog OA Omsorgsarbeider OR Ortoptist 22

31 Meldingens innhold og struktur PE Perfusjonist TH Tannhelsesekretær TT Tanntekniker MT Manuellterapeut IN Institusjon TypeAdressetype RES Besøksadresse PST Postadresse INV Faktureringsadresse TMP Midlertidig adresse BAD Ubrukelig adresse H Bostedsadresse HP Folkeregistrert adresse HV Ferieadresse WP Arbeidsplass ABC Alfabetisk SYL Stavet IDE Ideografisk TypeTelekomtype H Hjemme eller ukjent HP Hovedtelefon HV Ferietelefon WP Arbeidsplass WD Arbeidsplass, direktenummer WC Arbeidsplass, sentralbord AS Telefonsvarer EC Nødnummer PG Personsøker MC Mobiltelefon F Fax Yrkeskode C521 STYRK [8] 5.5 Digital signatur Digital signering av elektronisk sykmeldingsattest skjer ved hjelp av XML DSig[REF] og 'enveloped signature', som gjør at den digitale signaturen vil ligge inne i selve XML-meldingen. Meldingen skal signeres med XMLDsig enveloped signature. Dette innebærer at Signature-elementet skal inneholde følgende Transform-elementer: SignedInfo skal ha et CanonicalizationMethod element, et SignatureMethod element og ett eller flere Reference elementer, som definert i XML Signature [XMLDSIG]. Canonicalization method som benyttes på data som skal signeres er: <CanonicalizationMethod Algorithm=" beskrevet i [XMLC14N]. Denne algoritmen ekskluderer kommentarer. SignatureMethod elementet skal være til sted og skal ha en Algorithm attributt. Verdien for Algorithm attributtet skal være: <SignatureMethod Algorithm=" Det første Transform elementet har en Algorithm attributt med verdien: <Transform Algorithm=" Resultatet av dette er å ekskludere forelder Signature-elementet og alle barn. Det siste Transform-elementet BØR ha et Algorithm-attributt med følgende verdi: <Transform Algorithm=" Algoritmens funksjon er å kanonisere XML-dokuemntet og fjerne kommentarer. Signeringen skal foregå på applikasjonsnivå dvs. utføres av applikasjonen som genererer sykmeldingen/legeerklæringen. 23

32 Meldingens innhold og struktur Det stilles følgende krav til implementering av signatur-løsningen: Avsender skal presenteres for informasjonen som skal signeres på en for avsender naturlig og forståelig måte. Avsender skal avkreves PIN/passord for hver enkelt melding som sendes. Kryptering Etter signering skal meldingen krypteres iht. S/MIME. Valg av krypteringsparametere som algoritmer, nøkkellengder osv. forutsettes å følge ENV [12]. Dette innebærer at meldingen krypteres som et CMS-objekt, og MIME-header for payload settes til application/pkcs7-mime. Følgende algoritmer benyttes: Message Digest: SHA-1 Signature Algorithm: rsaencryption Key encryption: rsaencryption Mer om dette og informasjon om øvrig sikkerhet på meldingstjenestenivå og transportnivå, se Rammeverk for elektronisk kommunikasjons i helsevesenet[13]. 24

33 XML Schema 6 XML Schema Dette kapittelet inneholder de delene av XML skjemaet som er relevant for sykmeldingen. Selve skjemaet, som kan lastes ned fra dekker også elektronisk overføring av legeerklæring og inneholder en del elementer som ikke er tatt med i denne rapporten. 6.1 Skjema <?xml version="1.0" encoding="iso "?> <!-- Edited by Espen Stranger Seland, KITH ( <!-- Version > (ref innledningen) <!-- Copyright Rikstrygdeverket --> <!-- --> <!-- Filename: rtv-smlepo-v068.xsd --> <!-- Changes since version 0.67: --> <!-- Added annotation for code calue "5" in typekodesystem --> <!-- Changed NyVurdering from "int" to "rtv:typetekst" --> <!-- Changes since version 0.66: --> <!-- Added digital signatur for Legeerklaering (LE) --> <!-- Changes since version 0.65: --> <!-- New namespace --> <!-- Changes since version 0.64: --> <!-- Added enumeration value "5" to typekodesystem, representing ICPC-2. --> <!-- Changes since version 0.63: --> <!-- Namespace for XMLDsig added --> <!-- Removed "logic" from DiagnoseKodesystem. Every element is now optional --> <!-- ds:signature is now optional (0..1) for debugging convenience. --> <!-- --> <schema targetnamespace=" xmlns=" xmlns:xsd=" xmlns:rtv=" xmlns:ds=" elementformdefault="qualified" attributeformdefault="unqualified"> <import namespace=" schemalocation=" <!--RTV Sykmelding (SM) og Legeerklæring (LE) + Personopplysninger (PO). --> <!--= = = = SYKMELDING = = = =--> <element name="sykmelding"> <documentation>spesialisering av den abstrakte klassen Melding, til klassen Sykmeldingsattest.</documentation> <sequence> <element ref="rtv:sykmeldgjelder" maxoccurs="4"/> <element ref="rtv:pasientopplysninger"/> <element ref="rtv:identifikasjon" minoccurs="0"/> <element ref="rtv:arbeidsuforhetsykmelding"/> <element ref="rtv:friskmeldingprognose" minoccurs="0"/> <element ref="rtv:diagnosearbeidssituasjon"/> <element ref="rtv:merknad" minoccurs="0"/> <element ref="rtv:legeunderskrift"/> <element ref="rtv:medisinskeopplysninger" minoccurs="0"/> <element ref="rtv:funksjonsvurdering" minoccurs="0"/> <element ref="ds:signature" minoccurs="0"/> </sequence> <attribute name="formoflanguage" type="rtv:typeformoflanguage" use="required"/> <attribute name="sendersid" type="string" use="optional"/> <attribute name="receiversid" type="string" use="optional"/> 25

34 XML Schema <attribute name="schemaversion" type="string" use="required" fixed="ia Fastsatt 6.88 Endret Elektronisk XML 2.0"/> <attribute name="messageid" type="string" use="required"/> <attribute name="gendate" type="datetime" use="required"/> <element name="sykmeldgjelder"> <documentation>for å angi om det er første attest for dette sykmeldingstilfellet, forlengelse av sykmeldingstilfellet, endringer, om del II er benyttet, og/eller om legeerklæring ved sykefravær i mer enn 8 uker er sendt. </documentation> <attribute name="typesykmelding" type="rtv:typesykmelding" use="required"> <documentation>kategorisering av om dette er første attest for dette sykdomstilfellet, om det er en forlengelse, om det er en endring, om del II er benyttet eller om legeerklæring ved sykefravær utover 8 uker er sendt.</documentation> </attribute> <element name="arbeidsuforhetsykmelding"> <documentation>for å angi første fraværsdag, dato for første konsultasjon, dato for telefonkonsultasjon, arbeidsmuligheter og tiltak. Oopplysninger om varighet angis i klassene Varighet. </documentation> <sequence> <element name="forstefraversdag" type="date"> <documentation>pasientens opplysning om første fraværsdag.</documentation> <element name="forstekonsultasjon" type="date" minoccurs="0"> <documentation>legens opplysninger om når første konsultasjon har vært utført.</documentation> <element name="datotelefonkonsultasjon" type="date" minoccurs="0"> <documentation>dato for når telefonkonsultasjon er utført.</documentation> <element ref="rtv:varighet" minoccurs="0"/> <choice> <element name="ikkejobb" type="boolean"> <documentation>angir om personen ikke kan være på jobb under sykmeldingen.</documentation> <element name="forutsetninger"> <documentation>personen kan likevel være på jobb i nevnte periode under forutsetning av følgende.</documentation> <sequence> <element name="reisetilskuddfra" type="date" minoccurs="0"> <documentation>dato fra når reisetilskudd foreslås.</documentation> <element name="aktivsykmeldfra" type="date" minoccurs="0"> <documentation>når aktiv sykmelding foreslås fra.</documentation> 26

35 XML Schema <element name="eventuelt" type="rtv:typetekst" minoccurs="0"> <documentation>eventuelt hva bør personen ikke utføre eller utsettes for ved aktiv sykmelding.</documentation> </sequence> </choice> <element name="arbeidsuforbehandlingsdager" type="rtv:typetekst" minoccurs="0"/> </sequence> <element name="identifikasjon"> <documentation>for å angi hvordan pasienten er identifisert.</documentation> <choice> <element name="kjent" type="boolean"> <documentation>angir om personen er kjent.</documentation> <element name="legitimasjon" type="boolean"> <documentation>angir om legitimasjon er vist.</documentation> </choice> <element name="friskmeldingprognose"> <documentation>opplysninger om når personen forventes å bli helt arbeidsfør, eller prognose om fortsatt arbeidsuførhet.</documentation> <choice> <element ref="rtv:friskmeldt"/> <element ref="rtv:arbeidsufor"/> </choice> <element name="diagnosearbeidssituasjon"> <documentation>for å angi om fravær fra arbeid har andre årsaker enn egen sykdom, om sykdommen er svangerskapsrelatert, og evt. angivelse av skadedato for yrkessykdom/yrkesskade.</documentation> <sequence> <element ref="rtv:diagnosekodesystem" minoccurs="0"/> <element name="svangerskap" type="boolean" minoccurs="0"/> <element name="annenfraversgrunn" type="rtv:typetekst" minoccurs="0"/> <element name="yrkessykdom" type="boolean" minoccurs="0"/> <element name="yrkesskade" type="boolean" minoccurs="0"/> <element name="skadedato" type="date" minoccurs="0"/> </sequence> <element name="merknad" type="rtv:typetekst"> <documentation>for å angi merknader</documentation> <element name="medisinskeopplysninger"> <documentation>del II. For å angi opplysninger om behandling, utredning, tiltak.</documentation> 27

36 XML Schema <sequence> <element name="behandling" type="rtv:typetekst"> <documentation>opplysninger om symptomer, status presens og pågående behandling.</documentation> <element name="spesifikasjon" type="rtv:typetekst" minoccurs="0"> <documentation>hvis pasienten er henvist til utredning eller behandling, kan legen spesifisere type utredning/behandling (f.eks. røntgen, fysioterapi) og angi hvor behandlingen skal foregå (institusjon, poliklinikk, spesialist etc.).</documentation> <element ref="rtv:henvisttil" minoccurs="0" maxoccurs="3"/> </sequence> <element name="funksjonsvurdering"> <documentation>del II. Beskriver en forenklet funksjonsvurdering. OBS: Dette feltet gir gjennomslag til personens arbeidsgiver.</documentation> <sequence> <element ref="rtv:vurderingfunksjonsevnesm" minoccurs="3" maxoccurs="3"/> <element name="ikkeutforeutsette" type="rtv:typetekst" minoccurs="0"> <documentation>angir hva personen ikke bør utføre eller utsettes for.</documentation> <element name="hjelpemiddelbehov" type="boolean" minoccurs="0"> <documentation>angir om hjelpemiddelbehov bør vurderes.</documentation> <element name="forhold" type="rtv:typetekst" minoccurs="0"> <documentation>angir forhold i arbeidsmiljøet som bør drøftes med arbeidsgiveren, evt. forslag til tiltak.</documentation> <element name="kontaktbht" type="boolean" minoccurs="0"> <documentation>angir om det foreslås kontakt med BHT.</documentation> </sequence> <element name="vurderingfunksjonsevnesm"> <documentation>for å angi pasientens funksjonsevne.</documentation> <attribute name="typevurdering" type="rtv:typevurdering" use="required"> <documentation>benyttes for å oppgi hvilken type vurdering som er gjort. Antas personen a) å kunne gjenoppta nåværende arbeid b) å ha behov for tilrettelagt arbeid c) å ha behov for annet arbeid</documentation> </attribute> <attribute name="svar" type="rtv:typejanei" use="required"/> <attribute name="naetter" type="rtv:typenaetter" use="optional"/> <element name="friskmeldt"> 28

37 XML Schema <documentation>inneholder opplysninger om når pasienten forventes å bli helt arbeidsfør. Klassen er en spesialisering av den abstrakte klassen Friskmelding/prognose.</documentation> <attribute name="fradato" type="date" use="required"/> <element name="arbeidsufor"> <documentation>inneholder opplysninger om antall uker pasienten forventes å være fortsatt arbeidsufør. Klassen er en spesialisering av den abstrakte klassen Friskmelding/prognose.</documentation> <attribute name="fortsattarbeidsufor" type="nonnegativeinteger" use="required"/> <element name="varighet"> <documentation>fra dato, til dato</documentation> <complexcontent> <extension base="rtv:typevarighetdato"> <attribute name="grad" type="integer" use="required"> <documentation>grad av uførhet i prosent. Hvis personen er helt arbeidsufør skal tallet være 100.</documentation> </attribute> </extension> </complexcontent> <element name="henvisttil"> <documentation>angir om personen er eller vil bli henvist til utredning, behandling og/eller anbefalt til kjøp av helsetjenste og hvilken uke henvisningen gjelder.</documentation> <attribute name="henvist" type="rtv:typehenvisning" use="required"> <documentation>angir om det er henvist til utredning, og/eller behandling og/eller anbefalt kjøp av helsetjeneste.</documentation> </attribute> <attribute name="uke" type="integer" use="required"> <documentation>angir hvilken uke henvisningen gjelder.</documentation> </attribute> <complextype name="typevarighetdato"> <documentation>varighet mellom to datoer.</documentation> <attribute name="fradato" type="date" use="required"/> <attribute name="tildato" type="date" use="required"/> <simpletype name="typesykmelding"> <documentation>kodeverdier 1-5</documentation> <restriction base="nonnegativeinteger"> <enumeration value="1"> <documentation>første attest for dette sykmeldingstilfellet</documentation> <enumeration value="2"> 29

38 XML Schema <documentation>forlengelse av sykmeldingstilfellet</documentation> <enumeration value="3"> <documentation>endringer</documentation> <enumeration value="4"> <documentation>informasjon i Del II</documentation> <enumeration value="5"> <documentation>legeerklæring ved sykefravær i mer enn 8 uker er sendt</documentation> </restriction> </simpletype> <simpletype name="typejaneivetikke"> <documentation>kodeverdier 1-3</documentation> <restriction base="nonnegativeinteger"> <enumeration value="1"> <documentation>ja</documentation> <enumeration value="2"> <documentation>nei</documentation> <enumeration value="3"> <documentation>vet ikke</documentation> </restriction> </simpletype> <simpletype name="typehenvisning"> <documentation>kodeverdier 1-3</documentation> <restriction base="nonnegativeinteger"> <enumeration value="1"> <documentation>henvist til utredning</documentation> <enumeration value="2"> <documentation>henvist til behandling</documentation> <enumeration value="3"> <documentation>anbefalt til kjøp av helsetjeneste</documentation> </restriction> </simpletype> <simpletype name="typevurdering"> <documentation>kodeverdier 1-3</documentation> <restriction base="nonnegativeinteger"> <enumeration value="1"> <documentation>antas personen å kunne gjennoppta nåværende arbeid</documentation> 30

39 XML Schema <enumeration value="2"> <documentation>antas personen å ha behov for tilrettelagt arbeid</documentation> <enumeration value="3"> <documentation>antas personen å ha behov for annet arbeid</documentation> </restriction> </simpletype> <!--= = = = LEGEERKLÆRING = = = =--> <element name="legeerklaring"> <documentation>spesialisering av den abstrakte klassen Melding, til klassen Legeerklæring ved arbeidsuførhet.</documentation> <sequence> <element ref="rtv:legeerklaringgjelder" maxoccurs="4"/> <element ref="rtv:pasientopplysninger"/> <element ref="rtv:planutredbehandle" minoccurs="0"/> <element ref="rtv:diagnosearbeidsuforhet"/> <element ref="rtv:forslagtiltak"/> <element ref="rtv:vurderingfunksjonsevne"/> <element ref="rtv:prognose"/> <element ref="rtv:arsakssammenhenglegeerklaring" minoccurs="0"/> <element ref="rtv:forbeholdlegeerklaring"/> <element ref="rtv:andreopplysninger" minoccurs="0"/> <element ref="rtv:legeunderskrift"/> <element ref="rtv:kontakt" minoccurs="0" maxoccurs="unbounded"/> <element ref="ds:signature" minoccurs="0"/> </sequence> <attribute name="formoflanguage" type="rtv:typeformoflanguage" use="required"/> <attribute name="sendersid" type="string" use="optional"/> <attribute name="receiversid" type="string" use="optional"/> <attribute name="schemaversion" type="string" use="required" fixed="ia Fastsatt Elektronisk 1.1"/> <attribute name="messageid" type="string" use="required"/> <attribute name="gendate" type="datetime" use="required"/> <element name="vurderingfunksjonsevne"> <documentation>for å beskrive hvordan pasientens generelle funksjonsevne er nedsatt.</documentation> <sequence> <element ref="rtv:arbeidssituasjon" maxoccurs="unbounded"/> <element ref="rtv:vurderingarbeidsevne" minoccurs="0"/> <element name="funksjonsevne" type="rtv:typetekst" minoccurs="0"/> <element name="kravarbeid" type="rtv:typetekst" minoccurs="0"/> </sequence> <element name="arsakssammenhenglegeerklaring" type="rtv:typetekst"> <documentation>for å angi hvor stor betydning funksjonsnedsettelsen har for at arbeidsevnen er nedsatt.</documentation> <element name="forbeholdlegeerklaring"> <documentation>for å angi om det er noe i legeerklæringen som pasienten ikke bør få vite av medisinske grunner.</documentation> <sequence> 31