Implementasjonsguide for elektronisk legeerklæring

Transkript

1 Implementasjonsguide for elektronisk legeerklæring Basert på RTV blankett IA Versjon.0. desember 200 Status: "Til utprøving" KITH Rapport 8/0 ISBN

2

3 KITH-rapport TITTEL Implementasjonsguide for elektronisk legeerklæring Basert på RTV blankett IA Status: "Til utprøving" Forfatter Espen Stranger Seland Oppdragsgiver Rikstrygdeverket Kompetansesenter for IT i helsevesenet AS Postadresse Sukkerhuset 7005 Trondheim Besøksadresse Sverresgt 5, inng G Telefon Telefaks e-post firmapost@kith.no Foretaksnummer Rapportnummer URL Prosjektkode KITH R 8/0 ISBN Dato Antall sider Kvalitetssikret av Gradering desember Annebeth Askevold Å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 blanketten Legeerklæring ved arbeidsuførhet "RTV blankett blankett AI 08-08". Informasjonsinnhodlet er beskrevet i rapporten "KITH R5/0 Sykmeldingsattest og Legeerklæring, Informasjonsmodell for elektronisk meldingsutveksling". Dette dokumentet beskriver selve XML-skjemaet, en del detaljer rundt implementeringen, hvilke 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 skal utprøves i pilotprosjekt i forbindelse med Rikstrygdeverket sitt Ei@- prosjekt.

4

5 Forord Implementasjonsguide for elektronisk sykmelding Forord Denne rapporten er utarbeidet på oppdrag fra Rikstrygdeverket. Den beskriver en melding i XML-syntaks, basert på informasjonsinnholdet i blanketten Legeerklæring ved arbeidsuførhet som er beskrevet i rapporten "KITH R5/0 Sykmeldingsattest og Legeerklæring, Informasjonsmodell for elektronisk meldingsutveksling". Det er utarbeidet en tilsvarende melding for sykmeldingsattest (RTV blankett IA Denne rapporten følger samme oppbygging siden begge meldingene er utarbeidet i samme tidsperiode og i samme oppdrag. Det er ikk tidligere utarbeidet implementasjonsguider for meldinger i XML-syntaks til bruk i det norske helsevesenet. Begge meldingene baserer seg på samme informasjonsmodell og er dokumentert i et felless skjema siden meldingene inneholder mange felles deler. Leserne oppfordres til å komme med tilbakemeldinger på presentasjonsformen, komme med forslag til forbedringer, rapportere uklarheter og eventuelle feil og mangler. Rapporten er utarbeidet i nært samarbeid med oppdragsgiveren. KITH vil benytte anledningen til å takke for aktiv medvirkning og nyttige tilbakemeldinger. Versjon.0 i

6

7 Innholdsfortegnelse Implementasjonsguide for elektronisk sykmelding Innholdsfortegnelse Forord i Innholdsfortegnelse iii Innledning. Bakgrunn....2 Bruksområder....3 Leserveiledning....4 Om dette dokumentet Referanser 3 3 Meldingens bruksområder 5 3. Funksjon Notasjon 7 4. Forhold til standarder og arbeid...7 Syntaks...7 Utførelse...7 Fremtidig bruk Mapping fra DIM til XML...8 Element eller attributt...8 Forskjeller i kardinalitet mellom DIM og XML skjema...8 Uoverensstemmelser XML...8 Validering...8 Namespace...8 Datatyper...9 Navnepolitikk...9 Metainformasjon Meldingens innhold og struktur 5. Informasjonsmodell... Oversikt Legeerklæring... UML-diagram for Legeerklæring...5 UML-diagram for Personopplysninger Detaljer rundt implementeringen...7 Versjon.0 iii

8 Innholdsfortegnelse 5.3 Kodeverk Mapping av felt fra blankett til DIM og XML XML Schema Skjema...25 Vedlegg A Meldingseksempler 39 Eksempel Legeerklæring Uførepensjon...39 Eksempel 2 Legeerklæring Rehabiliteringspenger...4 Eksempel 3 Legeerklæring Yrkesrettet attføring...44 Vedlegg B Eksempler ordinære papirskjemaer 47 Eksempel Legeerklæring - Uførepensjon...48 Eksempel 2 Legeerklæring - Rehabiliteringspenger...5 iv Versjon.0

9 Innledning 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.. Bakgrunn I Rikstrydeverkets prosjekt for elektronisk innrapportering av saksdokumenter, EI@, prioritereres arbeidet med sykemelding og legeerklæring. Det er et mål å starte elektronisk overføring av begge disse dokumentene i løpet av første kvartal av KITH har i den forbindelse blitt bedt om å utarbeide implementasjonsguider for disse meldingene i XML syntaks. KITH har i samme avtale utarbeidet en informasjonsmodell som beskriver informasjonsinnholdet i blankettene Sykmeldingsattest og Legeerklæring ved arbeidsuførhet som er beskrevet i rapporten " Sykmeldingsattest og Legeerklæring, Informasjonsmodell for elektronisk meldingsutveksling" []. Meldingen er direkte basert på UML-modellen som er beskrevet i informasjonsmodellen[]. Meldingen er beskrevet som et XML Schema som finnes elektronisk på Bruksområder Dokumentet beskriver hvordan Rikstrygdeverkets blankett for legeerklæring "IA Fastsatt 0.99" skal overføres elektronisk ved hjelp av XML-syntaks. Meldingen er basert på blanketten for Legeerklæring og Rikstrygdeverkets retningslinjer[2]..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, kodeverk som skal benyttes samt noen eksempler. Detaljert beskrivelse av informasjonsinnholdet finnes i informasjonsmodellen[] 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, Informasjonsmodell for elektronisk meldingsutveksling av Denne er basert på blanketten "IA Fastsatt 0.99" for legeerklæringen og Rikstrygdeverkets retningslinjer[2]. Versjon.0

10 Innledning Alle referanser finnes på side 3. For de som ikke er kjent med XML og XML Schema henvises det til referansene [3] og [4]..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 og bruksområder. 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 blanketter av eksemplene i vedlegg A. 2 Versjon.0

11 2 Referanser Implementasjonsguide for elektronisk sykmelding Referanser Dette dokumentet er basert på og henviser til følgende dokumenter:. KITH R5/0: Informasjonsmodell for elektronisk sykmelding og legeerklæring. 2. Rikstrygdeverket: Veiledning til leger om legeerklæring ved arbeidsuførhet. 3. Extensible Markup Language (XML).0 (Second Edition): 4. XML Schema a. Part 0: Primer: b. Part : Structures: c. Part 2: Datatypes: 5. SSP FG: 6. Health Level 7 (HL7): 7. Unified Modelling Language (UML): 8. Statistisk Sentralbyrå: C 52 Standard for yrkesklassifisering (STYRK) ISBN Versjon.0 3

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. Funksjon Elektronisk legeerklæring (ELE) som er beskrevet i dette dokumentet, baserer seg på samme informasjon som kan overføres i Rikstrygdeverkets blankett for Legeerklæring ved arbeidsuførhet, RTV blankett IA (Fastsatt 0.99) og Rikstrygdeverkets retningslinjer[2]. Elektronisk overført legeerklæring skal kunne likestilles med papirskjemaet. ELE sendes fra lege, eller annet helsepersonell som er berettiget til å utstede legeerklæring, til Rikstrygdeverket. Meldingen er beskrevet som et XML Schema. Dette skjemaet ligger lagret elektronisk på Versjon.0 5

14

15 Notasjon 4 Notasjon 4. Forhold til standarder og arbeid Syntaks Den elektroniske meldingen som er beskrevet i dette dokumentet skal overføres som en XML-melding[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 for instansmeldinger. E spesifikk XML-melding (for eksempel en legeerklæring) kan valideres opp mot skjemaet. XML XML er et strukturert tekstformat for data, som er meget velegnet til elektronisk dokumentutveksling (EDI). Utførelse Det finnes i dag få retningslinjer som angir hvordan en elektronisk melding beskrevet ved hjelp av XML-syntaks skal 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 samordningsprogrammets Faggruppe (FG)[5] er i gang med å definere et rammeverk for hvordan XML skal benyttes ved meldingsutveksling, men dette arbeidet er foreløpig ikke avsluttet. Meldinger som utarbeides på et senere tidspunkt kan derfor avvike noe fra strukturen på meldingen og representasjon av datatyper som er beskrevet i dette dokumentet. Arbeidet er derfor gjort så enkel så mulig når det gjelder bruk av datatyper, variabler og strukturering. Det er viktig å komme i gang med pilottesting av meldingen og høste erfaringer med overføringer av XML-meldinger. I denne versjonen er det benyttet standard XML datatyper. Det kan i en senere versjon være aktuelt å gå over til å benytte HL7 sine datatyper når disse er endelig vedtatt og utprøvd. Fremtidig bruk Informasjonsmodellen og skjemautformingen er tilrettelagt for noen mulige fremtidige utvidelser. Det er av denne grunn tatt med noen attributter i skjemaet som foreløpig ikke vil bli benyttet. Dette gjelder spesielt personopplysningsdelen som inneholder en del attributter som ikke har direkte relevans i dag. Noen mulige utvidelser er beskrevet under: = Pasienten kan registreres med flere adresser slik at det for eksempel er mulig å håndtere både folkeregisteradresse og en eventuell kontaktadresse. Tilsvarende er det mulig å utvide meldingen med flere telefonnumre til pasienten. Versjon.0 7

16 Notasjon = Flere arbeidsgivere kan oppgis og det skal være mulig å oppgi mer presis adresse og kontaktinformasjon for arbeidsgivere. Det er også tatt høyde for å angi organisasjonsnummer til arbeidsgiver. = Mulighet for å oppgi mer detaljert adresse og organisasjonstilknytningsinformasjon for legen (ev. annen avsender). Det påpekes at disse punktene ikke innebærer noen forpliktelse for fremtidig utvikling, men at de er tatt med som kontekstuell informasjon for å lette forståelsen av strukturen i skjema. 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. All tekstlig informasjon der det skal taes vare på formattering eller lengre tekster, er representert som elementer I skjemaet selv om innholdet er metainformasjon. Forskjeller mellom DIM og XML skjema Meldingen er en avbildning av informasjonen i domene informasjonsmodellen som dekker flere meldinger. Det kan derfor være forskjell i kardinalitet mellom DIM og XML/IG. Stort sett vil det i tilfeller hvor DIM en tillater mange, bli en-til-en i XML/Skjema. PERSONOPPLYSNINGSDELEN Personopplysningsdelen i informasjonsmodellen har sin rot i det arbeidet som er gjort for EPJ. Derfor har denne en mer generell struktur med større uttrykkskraft enn det papirblanketten har. Uoverensstemmelser Hvis det finnes uoverensstemmelser mellom informasjonsmodellen (se []) og dette dokumentet (implementasjonsguiden), er det implementasjonsguiden og XML-skjemaet som har presedens. 4.3 XML Validering XML-skjemaet har blitt validert i henhold til XML Schema-standarden med verktøyene XMLSpy 4.0 og XSV.204/.09. Det ble ikke funnet noen feil eller advarsler ved disse valideringene. Namespace STANDARD 8 Versjon.0

17 Notasjon 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 skal være lokalisert på KITH s server. Dette er en avtale mellom RTV og KITH. Datatyper targetnamespace=" xmlns:rtv=" Det er brukt basale XML Schema-datatyper[4.c]. Det kan i en senere revisjon av meldingen være aktuelt å gå over til å benytte HL7 datatyper, men siden det foreløpig ikke foreligger erfaringer eller en vedtatt definisjon av hvordan HL7 datatyper skal representeres ved hjelp av XML syntaks, har prosjektet besluttet å benytte XML datatyper direkte. KODEVERK 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.3 Kodeverk I selve skjemabeskrivelse" (se kapittel 6), er den tekstlige beskrivelsen for kodene lagt inn i appinfo-taggen. Alle kodeverkstyper er basert på nonnegativeinteger. For oversikt over de inkluderte kodeverkene, se Kodeverk side 9. TYPEVARIGHETDATO Det er opprettet et complex element med navn typevarighetdato som benyttes til å beskrive et tidsrom mellom to datoer. Elementet inneholder fradato(date) og TYPETEKST 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 legeerklæringen 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. Norske navn er brukt, med unntak av personopplysningsdelen som er basert på tidligere arbeid for EPJ og følger den navngivning som er definert i EPJ. Dette følger av informasjonsmodellen. ELEMENTER Versjon.0 9

18 Notasjon Elementnavn har stor forbokstav. I elementnavn som består av flere delnavn / delord, vil hvert delnavn / delord skilles med stor forbokstav. Eksempel: ATTRIBUTTER LegeerklaringGjelder Attributtnavn har liten forbokstav. I attributtnavn som består av flere delnavn / delord, vil hvert delnavn / delord skilles med stor forbokstav. Eksempel: TYPER datotelefonkonsultasjon 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 typelegeerklaring 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. XML Schema basert på Unicode skal kunne forstå bruk av norske bokstaver i tagger, men det er ikke alle 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. Informasjon om øvrige tekniske hensyn finnes under Detaljer rundt implementeringen side 7. 0 Versjon.0

19 5 Meldingens innhold og struktur 5. Informasjonsmodell Implementasjonsguide for elektronisk sykmelding Meldingens innhold og struktur Deler av informasjonsmodellen er inkludert for å få et enkelt overblikk over hva skjemaet er basert på. Informasjonsmodellen er beskrevet ved hjelp av Unified Modelling 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. Oversikt Legeerklæring Hierarkisk modell av Legeerklæringen. Se under for Pasientopplysninger og Legeunderskrift, samt typen typeadresse som benyttes av de to sistnevnte. Versjon.0

20 Meldingens innhold og struktur Figur 5- Hierarkisk oversikt over skjemabeskrivelsen, øvre del 2 Versjon.0

21 Meldingens innhold og struktur Figur 5-2 Hierarkisk oversikt over skjemabeskrivelsen, nedre del Versjon.0 3

22 Meldingens innhold og struktur Figur 5-3 Hierarkisk oversikt over Pasientopplysninger Figur 5-4 Hierarkisk oversikt over Legeunderskrift Figur 5-5 Hierarkisk oversikt over typeadresse. PersonAdr og VirksomhetsAdr er av denne typen. 4 Versjon.0

23 Meldingens innhold og struktur UML-diagram for Legeerklæring Melding AvsendersRef : string M ottagersref : string MaalForm : kodet Skjema- versjon : string M eldingsid : String M elding generert : datetime Samarbeid/kontakt hvilken annen instans : string kontakttype : kodet 0..* Pasientopplysninger har flere arbeidsforhold : kodet Legens underskrift mv. 0.. dato for underskrift : date Legeerklæring ved arbeidsu førhet 0.. Pasient trygdekontor : string Helsepersonell helsepersonellnummer : string kategori helsepersonell : kodet type helsevirksomhet : kodet Legeerklæringen gjelder..* type legeerklæring : kodet Forbehold kan hele innholdet gjøres kjent for pasienten : kodet opplysninger som bør unndras pasienten : tekst Person fødselsnummer : string etternavn : string mellomnavn : string fornavn : st ring..* Arbeidsforhold yrkeskode : kodet primært arbeidsforhold : kodet yrkebetegnelse : string 0..* 0.. Virksomhet betegnelse : string Organisasjonsnummer : string 0..* 0.. Adresse Persons adresse Virksomhets adresse Postadresse Gateadresse : string postnummer : string poststed : string 0.. land : string adressetype : kodet Teleinformasjon 0..* type telekommunikasjon : Kodet teleadresse : string Vurdering yrkesskade/yrkessykdom bør vurderes : kodet eventuell skadedato : date 0.. Årsakssammenheng legeerklæring 0.. årsakssammenheng : tekst 0.. Andre opplysninger legeerklæring andre opplysninger : tekst legen øns ker kopi av vedtak : kodet Henvist til behandling henvist dato : date antatt ventetid : integer Spesifikasjon : tekst Diagnosekodesystem kodesystem : kodet..* Enkeltdiagnose diagnose : string kodeverdi : string sortering : integer Henvist til utredning henvist dato : date antatt ventetid : integer Spesifikasjon : tekst Diagnose og arbeidsuførhet helt arbeidsufør fra : date 0.. status presens : tekst symptomer og behandling : tekst Aktuelt tiltak type tiltak : kodet hvilke andre tiltak : tekst Forslag til tiltak utover medisinsk behandling begrensninger i forhold til tiltak : tekst begrunnelse for at det ikke er behov for tiltak : tekst Er noen av følgende tiltak aktuelle nå : kodet Evt. nærmere opplysninger : tekst * Plan utredning og behandling når bør det hentes inn nye legeopplysninger : integer videre behandling er ikke aktuelt : tekst ny vurdering av tidligere plan : tekst Behandlingsplan : tekst Utredningsplan : tekst Prognose legeerklæring behandlingen antas til å bedre arbeidsevnen : kodet 0.. antatt varighet av sykdom : Tekst antatt varighet av funksjonsnedsettelse : Tekst antatt varighet av nedsatt arbeidsevne : Tekst 0.. Vurdering av funksjonsevne bes krivelse av funksjonsevn e : tekst krav som stilles i arbeidet : tekst..* Pasientens arbeidssituasjon arbeidssituasjon : kodet annen arbeidssituasjon : string 0.. Vurdering av arbeidsevne kan gjenoppta tidligere arbeid : kodet når tidligere arbeid kan gjenopptas : kodet vil kunne ta annet arbeid : kodet når annet arbeid kan gjenopptas : kodet hva pasienten ikke kan gjøre : tekst andre hensyn som må tas ved valg av arbeid : tekst Figur 5-6 Elektronisk legeerklæring, UML-diagram Versjon.0 5

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

25 Meldingens innhold og struktur 5.2 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 []. De fleste kommentarene i denne tabellen finnes i informasjonsmodellen under feltene "Bruk" eller "Kommentar" i beskrivelsen. ELEMENT/ATTRIBUTTNAVN sendersid recieversid BRUK OG KOMMENTARER Benyttes som intern referanse i avsendersystemet. Finnes ikke på dagens blankett. Mottager (RTV) vil lagre denne uten endring og vil returnere denne ved eventuell oppfølgende korrespondanse. Identifikatoren må ikke være knyttet til pasienten (personidentifiserbar). Den må kunne sendes åpent uten at informasjonen skal kunne knyttes til en aktuell pasient. Benyttes som intern referanse i mottagersystemet. Finnes ikke på dagens blankett. messageid flerearbeidsforhold etternavn mellomnavn fornavn typehelsevirksomhet Avsender (lege) skal benytte denne som en referanse i det tilfelle at denne meldinger er svar på en melding fra RTV. Den er til fremtidig bruk. Unik identifikator som skal kunne identifisere denne meldingen. Finnes ikke i dagens papirskjema. Må fylles ut ved første gangs innsendelse. Denne benyttes kun for sykmelding. Navn oppgis delvis strukturert i papirskjemaet (etternavn, fornavn) Tatt med for fremtidig bruk. Opplysningene oppgis i denne versjonen som en tekststreng. Kodeverk vil bli implementert i neste versjon. hprnr 9 siffer uten mellomrom. Tatt med for fremtidig bruk. adressetype (i typeadresse) Denne opplysningen oppgis ikke spesifikt i dagens skjema. Er tatt med for fremtidig bruk. For pasienten forventes det at adressetypen er HP, forlkeregisteradresse. antattventetid typelegeerklaring arbeidssituasjon annenarbeidssituasjon BorTilbakeholdes BegrensningerTiltak Verdi i uker. Det benyttes en forekomst av klassen for hver valgmulighet (tilsvarer et kryss på blanketten). Hvis både felt 0. og felt 0.3 er avkrysset må meldingen inneholde to forekomster. Det benyttes en forekomst av klassen/elementet for hver falgmulighet (tilsvarer et kryss på blanketten). Eksempelvis, hvis både feltene Inntektsgivende arbeid () og Student (3) er avkrysset må meldingen innholde to forekomster av klassen/element. Dette feltet skal fylles ut med opplysninger om hvilken annen arbeidssitausjon pasienten har. Skal fylles ut hvis arbeidssituasjon er fyllt ut med verdi 4 = annen. Opplysningene skal bare gis hvis det er krysset av for ja () i TilbakeholdInnhold. If TilbakeholdInnhold!= TRUE the BorTilbakeholdes=NULL. If tiltak= (ja) thenbegrensningertiltak!=null BegrunnelseIkkeTiltak Begrensninger i forhold til tiltak og begrunnelse for at det ikke er behov for tiltak skrives i samme felt på pairskjemaet. If tiltak= 2 (Nei) then begrunnelseikketiltak!=null. Begrensninger i forhold til tiltak og begrunnelse for at det ikke er behov for tiltak skrives i samme felt på pairskjemaet. Versjon.0 7

26 Meldingens innhold og struktur AktueltTiltak En forekomst av klassen inneholder et tiltak. Flere tiltak forutsetter flere forekomster av klassen. HvilkeAndreTiltak Skal bare benyttes hvis typetiltak= 7 (Andre) Enkeltdiagnose En hoveddiagnose skal alltid oppgis. Både felt 2. og 2.2 mappes inn i dette elementet, verdien i sortering avgjør om det er en hoveddiagnose eller en bidiagnose. kodeverdi Kodeverdien skal inneholde de skilletegn (punktum, mellomrom etc. ) som kreves i henhold til regelverk for det enkelte kodeverk. sortering Hoveddiagnose = 0, første bidiagnose =, osv. Denne verdien finnes ikke i papirskjemaet. Sorteringsverdi = 0 svarer til hoveddiagnose (felt 2.) og sorteringsverdie = eller større svarer til bidiagnose(r) (felt 2.2). nyelegeopplysninger fodselsnummer PersonAdr virksomhetsbeteegnelse Yrkesbetegnelse Yrkeskode Legeunderskrift Sorteringsrekkefølge er innført for å kunne skille på hoveddiagnose og bidiagnose ved automatisk behandling og for statistiske forhold og for å kunne benytte samme struktur både for legeerklæring og sykmeldingsattest. Denne opplysningen skal angies som uker fra dags datoi (datoen LE er signert/sendt). Format tegn, bare siffer. Fødselsnummeret kontrolleres for gyldighet når det mottas hos RTV og ELE med ikke gyldige fødselsnummer vil avvises. Det forventes bare en personadr fra en pasient. Hvis det er flere personadresser er det den første i rekkelfølgein i XML meldingen som vil bli gjort gjeldende. Denne skal ha adressetype=hp (folkeregistereadresse). Her forventes Firmanavn på arbeidsgiver. Arbeidsgivers adresse skal være i en PostalAdress under Virksohetsadresseelementet. Hvis flere adresser er oppgitt vil kun den først være gjeldende. Her legges SM.5 og LE:.5. Yekeskode er en tillegskoding av yrke i henhold til SSB s Styrk kodeverk. Hele strukture knyttet til legeunderskrift er lignende den for pasientopplysninger, med noen variasjoner. Det viktigste punktet er at det forventes en adresse under legeunderskrift. Denne kan være en personadresse eller en virksomhetsadresse. Det skal være den adresse som trygdekontoret skal henvende seg til for oppfølging av denne LE/SM. Det samme gjelder telefonnr. Det skal være angitt ett telefonnr. I fall det er flere adresser/telefonnr, så er det den første som gjelder. 8 Versjon.0

27 Meldingens innhold og struktur 5.3 Kodeverk Tabellen under viser en oversikt over kodeverkene som er benyttet i elektronisk sykmeldingsattest. Forklaringene finnes også i appinfo-elementet under annotationelementet under hver type. Kolonnen "Brukes av" viser hvilket informasjonselement som benytter kodeverket. Kolonnen "Representasjon" inneholder navnet på kodeverket som i skjemaet er representert som simpletype. Kolonnen "Verdier" inneholder selve kodeverdien med tilhørende betydning. BRUKES AV REPRESENTASJON VERDIER KOMMENTAR Legeerklæring gjelder typelegeerklaring Sykefravær mer enn 8 uker 2 Rehabiliteringspenger 3 Yrkesrette attføring 4 Uførepensjon Målform typeformoflanguage Bokmål 2 Nynorsk Kontakttype typekontakt Behandlende lege 2 Arbeidsgiver 3 Arbeidskontor 4 Basisgruppe 5 Annen instans Kodesystem typekodesystem ICPC 2 ICD-9 3 ICD-0 Type tiltak typetiltak Kjøp av helsetjenester 2 Reisetilskudd i stedet for sykepenger 3 Aktiv sykmelding 4 Hjelpemidler på arbeidsplassen 5 Yrkesrettet attføring 6 Friskmelding til arbeidsformidling 7 Andre nargjenopptaarbeid martaannetarbeid typenaetter Nå 2 Etter arbeidssituasjon typearbeidssituasjon Inntektsgivende arbeid 2 Hjemmearbeidende 3 Student 4 Annet flerearbeidsforhold primartarbeidsforhol NyVurdering borvorderes tiltak gjenopptaarbeid taannetarbeid bedrearbeidsevne tilbakeholdinnhold typejanei Ja 2 Nei Kategori helsepersonell typehelsepersonell BI Bioingeniør ET Ergoterapeut FA Farmasøyt FO Fotterapeut FT Fysioterapeut Merk at ikke alle disse kategoriene har rett til å sende ELE. Hele kodeverket er tatt med for å kunen bruke et Versjon.0 9

28 Meldingens innhold og struktur Adressetype Kodeverk fra HL7. Type telekommunikasjon Kodeverk fra HL7 med noen nasjonale utvidelser. Alle koder som gjenfinnes i HL7 sitt kodeverk har originalteksten oppgitt i parentes (for eksempel Primary Home). typeadressetype typetelekomtype 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 PE Perfusjonist TH Tannhelsesekretær TT Tanntekniker RES Besøksadresse (Visit address) PST Postadresse (Mail address) INV Faktureringsadresse (Invoice address) TMP Midlertidig adresse (Temporary address) BAD Ubrukelig adresse (Bad address) H Bostedsadresse (Home) HP Folkeregistrert adresse (Primary Home) HV Ferieadresse (Vacation home) WP Arbeidsplass (Work place) ABC Alfabetisk (Alphapetic) SYL Stavet (Syllabic) IDE Ideografisk (Ideographic) H Hjemme (Home) HP Hovedtelefon (Primary home) HV Ferietelefon (Vacation home) WP Arbeidsplass (Work place) WD Arbeidsplass, direktenummer WC Arbeidsplass, sentralbord AS Telefonsvarer (Answering service) EC Nødnummer (Emergency contact) PG Personsøker (Pager) MC Mobiltelefon (Mobile contact) F Fax Yrkeskode string Yrkeskodene som skal bli brukt er STYRK (Ref. pkt. 8). standardisert kodeverk. 20 Versjon.0

29 5.4 Mapping av felt fra blankett til DIM og XML. Implementasjonsguide for elektronisk sykmelding Meldingens innhold og struktur Tabellen under viser en oversikt over klassenavn / attributtnavn i informasjonsmodellen [] (Navn), element og attributtnavn i skjemaet (Kortnavn) og tilhørende feltbeskrivelse i blankettene (Opprinnelse). Klassenavn er skrevet med fet skrift i tabellen. Sykmelding (SM) og legeerklæring (LE) har mange felles felter. Informasjon fra begge blankettene og meldingene er av praktiske årsaker tatt med. NAVN KORTNAVN OPPRINNELSE Melding Message - AvsendersRef sendersid - MottagersRef receiversid - MaalForm formoflanguage - Skjema-versjon schemaversion - MeldingsId messageid - Melding generert gendate - Sykmeldingen gjelder SykmeldGjelder Type sykmelding typesykmelding SM blokk 0 (felt ) Legeerklæringen gjelder LegeerklaringGjelder - Type legeerklæring typelegeerklaring LE blokk 0 (felt ) Samarbeid/kontakt Kontakt SM blokk 8 og LE blokk 9 Hvilken annen instans anneninstans SM blokk 8 og LE blokk 9 Kontakttype kontakt SM blokk 8 og LE blokk 9 Merknad Merknad Merknadstekst Merknadstekst SM blokk 5 Pasientopplysninger Pasientopplysninger - Har flere arbeidsforhold flerearbeidsforhold SM felt.7 Legens underskrift mv. Legeunderskrift - Dato for underskrift signaturdato SM felt 6. og LE felt. Adresse Address Postadresse PostalAddress Personadresse: SM felt.4 Gateadresse StreetAddress og LE felt.4 Postnummer PostalCode Arbeidsgivers adresse: SM felt.6 Poststed City og LE felt.6 Land Country - Adressetype typeadresse - Teleinformasjon Teleinformasjon Type telekommunikasjon typetelekom Telenummer telenummer Lege: SM felt 6.3 og LE felt.3 Person Person Fødselsnummer fodselsnummer SM felt.2 og LE felt.2 Etternavn Etternavn SM felt. og LE felt. Mellomnavn Mellomnavn SM felt. og LE felt. Fornavn Fornavn SM felt. og LE felt. Arbeidsforhold Arbeidsforhold - Yrkeskode yrkeskode SM og LE felt.5 Primært arbeidsforhold primartarbeidsforhold Yrkebetegnelse yrkesbetegnelse SM og LE felt.5 Virksomhet Virksomhet - Betegnelse virksomhetsbetegnelse SM og LE blokk Ikke i bruk i dagens blankett Organisasjonsnummer organisasjonsnummer SM og LE blokk Ikke i bruk i dagens blankett Pasient Pasient Trygdekontor trygdekontor SM felt.3 og LE felt.3 Helsepersonell Helsepersonell Versjon.0 2

30 Meldingens innhold og struktur NAVN KORTNAVN OPPRINNELSE Helsepersonellnummer hprnr Kategori helsepersonell typehelsepersonell Type helsevirksomhet typehelsevirksomhet Behandlingsopplysninger mv Behandlingsopplysninger sykmelding Symptomer, status og behandling Behandling SM felt 7. Henvist utredning Henvist dato henvistdato SM felt 7.2. og LE felt 3.. Antatt ventetid antattventetid SM felt og LE 3..2 Spesifikasjon spesifikasjon SM felt 7.2 Henvist behandling Henvist dato henvistdato SM felt og LE felt 3..3 Antatt ventetid antattventetid SM felt og LE felt 3..4 Spesifikasjon spesifikasjonbehandling SM felt 7.2 Plan utredning og behandling Når bør det hentes inn nye nyelegeopplysninger LE felt 3.5 legeopplysninger Videre behandling er ikke aktuelt ikkeviderebehandling LE felt 3.6 Ny vurdering av tidligere plan NyVurdering LE felt 3.4 Behandlingsplan BehandlingsPlan LE felt 3.3 Utredningsplan UtredningsPlan LE felt 3.2 Friskmeldt Friskmeldt fra dato fradato SM felt 3. Arbeidsufør Antas fortsatt arbeidsufør fortsattarbeidsufor SM felt 3.2 Arbeidsufør enkeltstående behandlingsdager Behandlingsdager behandlingsdager SM felt 2.7 Antall behandlingsdager pr. uke antbehandingsdagerpruke SM felt 5 Helt arbeidsufør Helt arbeidsufør fra dato fradato SM felt 2.4 Helt arbeidsufør til dato tildato SM felt 2.4 Delvis arbeidsufør Uførhetsgrad uforhetsgrad SM felt 2.6 Delvis arbeidsufør fra dato fradato SM felt 2.5 Delvis arbeidsufør til dato tildato SM felt 2.5 Arbeidsuførhet sykmelding ArbeidsuforhetSykmelding Dato telefonkonsultasjon datotelefonkonsultasjon SM felt 2.3 Første fraværsdag forstefraversdag SM felt 2. Dato første konsultasjon forstekonsultasjon SM felt 2.2 Vurdering av funksjonsevne VurderingFunksjonsevne Beskrivelse av funksjonsevne funksjonsevne LE felt 5. Krav som stilles i arbeidet kravarbeid LE felt 5.2 Vurdering av arbeidsevne VurderingArbeidsevne Kan gjenoppta tidligere arbeid gjenopptaarbeid LE felt 5.3a Når tidligere arbeid kan gjenopptas nargjenopptaarbeid LE felt 5.3a Vil kunne ta annet arbeid taannetarbeid LE felt 5.3b Når annet arbeid kan gjenopptas nartaannetarbeid LE felt 5.3a Hva pasienten ikke kan gjøre ikkegjore LE felt 5.4a Andre hensyn som må tas ved valg hensynannetyrke LE felt 5.4 b av arbeid Pasientens arbeidssituasjon Arbeidssituasjon Arbeidssituasjon Arbeidssituasjon LE felt 5.2 Annen arbeidssituasjon annenarbeidssituasjon LE felt 5.2 Årsakssammenheng legeerklæring ArsakssammenhengLegeerklaring Årsakssammenheng ArsakssammenhengLegeerklering LE blokk 7 22 Versjon.0

31 Meldingens innhold og struktur NAVN KORTNAVN OPPRINNELSE Forbehold ForbeholdLegeerklaring Bør noe av innholdet tilbakeholdes? TilbakeholdInnhold LE felt 0. Opplysninger som bør unndras BorTilbakeholdes LE blokk 0, tekstfelt under felt 0. pasienten Prognose legeerklæring Prognose behandlingen antas til å bedre bedrearbeidsevne LE felt 6a arbeidsevnen Antatt varighet av sykdom antattvarighet LE felt 6b Antatt varighet av varighetfunksjonsnedsettelse LE felt 6c funksjonsnedsettelse Antatt varighet av nedsatt varighetnedsattarbeidsevne LE felt 6 d arbeidsevne Andre opplysninger AndreOpplysninger legeerklæring Andre opplysninger Opplysninger LE blokk 8 Legen ønsker kopi av vedtak onskeskopi LE felt 9.2 Forslag til tiltak utover medisinsk ForslagTiltak behandling Begrensninger i forhold til tiltak BegrensningerTiltak SM felt 7.3 og LE felt 4 Begrunnelse for at det ikke er BegrunnelseIkkeTiltak SM felt 7.3 og LE felt 4 behov for tiltak Er noen av følgende tiltak aktuelle tiltak SM felt 7.3 og LE felt 4 nå Evt. nærmere opplysninger Opplysninger SM felt 7.3 og LE felt 4 Aktuelt tiltak AktueltTiltak Type tiltak typetiltak SE felt 7.3 og LE felt 4 Hvilke andre tiltak HvilkeAndreTiltak SM felt 7.3 og LE felt 4 Diagnosekodesystem DiagnoseKodesystem Kodesystem kodesystem SM felt 4.2 og LE felt 2.3 Enkeltdiagnose Enkeltdiagnose Diagnose diagnose SM felt 4. Kodeverdi kodeverdi SM felt 4.. Sortering sortering Diagnose og arbeidssituasjon DiagnoseArbeidssituasjon Annen lovfestet fraværsgrunn annenfravarsgrunn SM felt 4.3 Antas sammenheng med sammenhengarbeidssituasjon SM felt 4.3 arbeidssituasjon Diagnose og arbeidsuførhet DiagnoseArbeidsuførhet Helt arbeidsufør fra arbeidsuforfra LE felt 2.4 Status presens StatusPresens LE felt 2.6 Symptomer og behandling SymptomerBehandling LE felt 2.5 Vurdering VurderingYrkesskade yrkesskade/yrkessykdom Bør vurderes børvurderes SM felt 4.5. og LE felt 2.7. Eventuell skadedato skadedato SM felt og LE felt Versjon.0 23

32

33 XML Schema 6 XML Schema Dette kapittelet inneholder de delene av XML skjemaet som er relevant for legeerklæringen. Selve skjemaet, som kan lastes ned elektronisk fra, dekker også elektronisk overføring av sykmelding og inneholder en del elementer som ikke er tatt med i denne rapporten. Kapittelet inneholder en opplisting av skjemaet med en referanser til hvor opplysningene i selve skjemaet er referert på blanketten. Merk: Det gjøres oppmerksom på at det kan være avvik mellom skjemaet som er listet opp i denne rapporten og selve skjemaet som ligger på Ved eventuelle avvik er det den elektroniske utgaven som gjelder. Opplistingen av skjemaet i denne rapporten er i hovedsak tatt med for å vise hvor de ulike delen i skjemaet kan refereres til i blanketten. Opplysninger om endringer etc. vil bli løpende oppdatert på 6. Skjema <!--= = = = SKJEMAINFORMASJON = = = =--> <?xml version=".0" encoding="iso-8859-"?> <!-- edited with XML Spy v4. U ( by Espen Stranger Seland (KITH) --> <!--Generated on :33:07 at KITH by Espen Stranger Seland--> <!--XML-Schema level supported is specified by W3C --> <!--This version: > <!--Copyright 200 Rikstrygdeverket--> <!-- <schema targetnamespace=" xmlns=" xmlns:xsd=" xmlns:rtv=" elementformdefault="qualified"> <!--RTV Sykmelding (SM) og Legeerklæring (LE) + Personopplysninger (PO). --> Versjon.0 25

34 XML Schema <!--= = = = LEGEERKLÆRING = = = =--> <element name="legeerklaring"> <documentation>spesialisering av den abstrakte klassen Melding, til klassen Legeerklæring ved arbeidsuførhet.</documentation> <complextype> <sequence> <element ref="rtv:legeerklaringgjelder" maxoccurs="unbounded"/> <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"/> </sequence> <attribute name="formoflanguage" type="rtv:typeformoflanguage" use="required" default=""/> <attribute name="sendersid" type="string" use="optional"/> <attribute name="receiversid" type="string" use="optional"/> <attribute name="schemaversion" type="string" use="required" fixed="ia Fastsatt 0.99 Elektronisk 0.4"/> <attribute name="messageid" type="string" use="required"/> <attribute name="gendate" type="datetime" use="required"/> </complextype> </element> <!--= = = = Blokk 5 Medisinsk begrunnet vurdering av funksjons- og arbeidsevne= = = =--> <!--= = = = VURDERINGFUNKSJONSEVNE = = = =--> <element name="vurderingfunksjonsevne"> <documentation>for å beskrive hvordan pasientens generelle funksjonsevne er nedsatt.</documentation> <complextype> <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> </complextype> </element> <!--= = = = Blokk 7 Årsakssammenheng = = = =--> <!--= = = = ARSAKSSAMMENHENGLEGEERKLARING = = = =--> <element name="arsakssammenhenglegeerklaring" type="rtv:typetekst"> <documentation>for å angi hvor stor betydning funksjonsnedsettelsen har for at arbeidsevnen er nedsatt.</documentation> </element> 26 Versjon.0

35 XML Schema <!--= = = = Blokk 0 Forbehold = = = =--> <!--= = = = FORBEHOLDLEGEERKLARING = = = =--> <element name="forbeholdlegeerklaring"> <documentation>for å angi om det er noe i legeerklæringen som pasienten ikke bør få vite av medisinske grunner.</documentation> <complextype> <sequence> <element name="bortilbakeholdes" type="rtv:typetekst" minoccurs="0"/> </sequence> <attribute name="tilbakeholdinnhold" type="rtv:typejanei" use="optional"/> </complextype> </element> <!--= = = = Blokk 8 Andre opplysninger = = = =--> <!--= = = = ANDREOPPLYSNINGER = = = =--> <element name="andreopplysninger"> <documentation>for å angi andre opplysninger.</documentation> <complextype> <sequence> <element name="opplysning" type="rtv:typetekst"/> </sequence> <attribute name="onskeskopi" type="rtv:typejanei" use="optional"/> </complextype> </element> <!--= = = = Blokk 0 Legeerklæring = = = =--> <!--= = = = LEGEERKLARINGGJELDER = = = =--> <element name="legeerklaringgjelder"> <documentation>for å angi om legeerklæringen gjelder sykefravær i mer enn 8 uker, rehabiliteringspenger, yrkesrettet attføring eller uførepensjon. Det benyttes en forekomst av klassen for hver valgmulighet (tilsvarer et kryss på skjemaet). Hvis både felt 0. og felt 0.3 er avkrysset må meldingen inneholde to forekomster av klassen.'</documentation> <complextype> <attribute name="typelegeerklaring" type="rtv:typelegeerklaring"/> </complextype> </element> <!--= = = = Blokk 6 Prognose = = = =--> <!--= = = = PROGNOSE = = = =--> <element name="prognose"> <documentation>for å angi prognose for bedring av arbeidsevnen, varighet av sykdom/skade, varighet av funksjonsnedsettelse, varighet av nedsatt arbeidsevne.</documentation> <complextype> <sequence> <element name="antattvarighet" type="rtv:typetekst" minoccurs="0"/> <element name="varighetfunksjonsnedsettelse" type="rtv:typetekst" minoccurs="0"/> <element name="varighetnedsattarbeidsevne" type="rtv:typetekst" minoccurs="0"/> </sequence> <attribute name="bedrearbeidsevne" type="rtv:typejanei"/> </complextype> </element> Versjon.0 27

36 XML Schema <!--= = = = Blokk 5 Medisinsk begrunnet vurdering av funksjons- og arbeidsevne = = = =--> <!--= = = = VURDERINGARBEIDSEVNE = = = =--> <element name="vurderingarbeidsevne"> <documentation>for å angi vurdering av arbeidsevne, begrensninger i forhold til arbeidet pasienten er sykmeldt fra og begrensninger ved vurdering av alternativt arbeid eller yrke.</documentation> <complextype> <sequence> <element name="ikkegjore" type="rtv:typetekst" minoccurs="0"/> <element name="hensynannetyrke" type="rtv:typetekst" minoccurs="0"/> </sequence> <attribute name="gjenopptaarbeid" type="rtv:typejanei" use="optional"/> <attribute name="nargjenopptaarbeid" type="rtv:typenaetter" use="optional"/> <attribute name="taannetarbeid" type="rtv:typejanei" use="optional"/> <attribute name="nartaannetarbeid" type="rtv:typenaetter" use="optional"/> </complextype> </element> <!--= = = = ARBEIDSSITUASJON = = = =--> <element name="arbeidssituasjon"> <documentation>for å angi type arbeid og hvilke krav som stilles.</documentation> <complextype> <attribute name="arbeidssituasjon" type="rtv:typearbeidssituasjon"/> <attribute name="annenarbeidssituasjon" type="string"/> </complextype> </element> <!--= = = = Blokk 2 = = = =--> <!--= = = = DIAGNOSEARBEIDSUFORHET = = = =--> <element name="diagnosearbeidsuforhet"> <documentation>for å angi dato for når sykmeldingsperioden begynte i dette sykmeldingstilfellet.</documentation> <complextype> <sequence> <element ref="rtv:diagnosekodesystem"/> <element ref="rtv:vurderingyrkesskade"/> <element name="statuspresens" type="rtv:typetekst"/> <element name="symptomerbehandling" type="rtv:typetekst"/> </sequence> <attribute name="arbeidsuforfra" type="date"/> </complextype> </element> 28 Versjon.0

37 XML Schema <!--= = = = Blokk 3 = = = =--> <!--= = = = PLANUTREDBEHANDLE = = = =--> <element name="planutredbehandle"> <documentation>plan, utredning og behandling.</documentation> <complextype> <sequence> <element ref="rtv:henvistutredning" minoccurs="0"/> <element ref="rtv:henvistbehandling" minoccurs="0"/> <element name="nyelegeopplysninger" type=" nonnegativeinteger " minoccurs="0"/> <element name="ikkeviderebehandling" type="rtv:typetekst" minoccurs="0"/> <element name="nyvurdering" type="rtv:typetekst" minoccurs="0"/> <element name="behandlingsplan" type="rtv:typetekst" minoccurs="0"/> <element name="utredningsplan" type="rtv:typetekst" minoccurs="0"/> </sequence> </complextype> </element> <!--= = = = Kodeverk = = = =--> <!--= = = = TYPELEGEERKLARING = = = =--> <simpletype name="typelegeerklaring"> <documentation>kodeverdier -4 </documentation> <appinfo> Sykefravær mer enn 8 uker 2 Rehabiliteringspenger 3 Yrkesrette attføring 4 Uførepensjon</appinfo> <restriction base="nonnegativeinteger"> <enumeration value=""/> <enumeration value="2"/> <enumeration value="3"/> <enumeration value="4"/> </restriction> </simpletype> <!--= = = = TYPENAETTER = = = =--> <simpletype name="typenaetter"> <documentation>kodeverider -2</documentation> <appinfo> Nå 2 Etter</appinfo> <restriction base="nonnegativeinteger"> <enumeration value=""/> <enumeration value="2"/> </restriction> <!-- Kodeverk: Kodeverk er ikke spesifisert i skjema --> </simpletype> Versjon.0 29

38 XML Schema <!--= = = = TYPEARBEIDSSITUASJON = = = =--> <simpletype name="typearbeidssituasjon"> <documentation>kodeverdier -4</documentation> <appinfo> Inntektsgivende arbeid 2 Hjemmearbeidende 3 Student 4 Annet</appinfo> <restriction base="nonnegativeinteger"> <enumeration value=""/> <enumeration value="2"/> <enumeration value="3"/> <enumeration value="4"/> </restriction> </simpletype> <!--= = = = Blokk 8 Samarbeid/Kontakt = = = =--> <!--= = = = KONTAKT = = = =--> <element name="kontakt"> <documentation>for å angi hvem legen ønsker at trygdekontoret skal ta kontakt med.</documentation> <complextype> <attribute name="kontakt" type="rtv:typekontakt" use="required"/> <attribute name="anneninstans" type="string" use="optional"/> </complextype> </element> <!--= = = = Blokk 3 Plan for medisinsk utredning og behandling = = =--> <!--= = = = HENVISTUTREDNING = = = =--> <element name="henvistutredning"> <documentation>for å angi type utredning, hvor denne skal foregå, henvisningsdato og antatt ventetid.</documentation> <complextype> <sequence> <element ref="rtv:spesifikasjon"/> </sequence> <attribute name="henvistdato" type="date" use="required"/> <attribute name="antattventetid" type="nonnegativeinteger" use="required"/> </complextype> </element> <!--= = = = HENVISTBEHANDLING = = = =--> <element name="henvistbehandling"> <documentation>for å angi type behandling, hvor denne skal foregå, henvisningsdato og antatt ventetid.</documentation> <complextype> <sequence> <element ref="rtv:spesifikasjon"/> </sequence> <attribute name="henvistdato" type="date" use="required"/> <attribute name="antattventetid" type="nonnegativeinteger" use="required"/> </complextype> </element> 30 Versjon.0

39 <!--= = = = Blokk 2 Diagnose og sykdomsopplysninger = = =--> <!--= = = = DIAGNOSEKODESYSTEM = = = =--> Implementasjonsguide for elektronisk sykmelding XML Schema <element name="diagnosekodesystem"> <documentation>for å angi benyttet diagnosekodesystem.</documentation> <complextype> <sequence> <element ref="rtv:enkeltdiagnose" minoccurs="0" maxoccurs="unbounded"/> </sequence> <attribute name="kodesystem" type="rtv:typekodesystem" use="required"/> </complextype> </element> <!--= = = = Blokk 4 Forslag til tiltak ut over medisinsk behandling= = = =--> <!--= = = = AKTUELTTILTAK = = = =--> <element name="aktuelttiltak"> <documentation>for å angi ett aktuelt tiltak. En forekomst av klassen inneholder et tiltak. Flere tiltak forutsetter flere forkomster av klassen.</documentation> <complextype> <sequence> <element name="hvilkeandretiltak" type="rtv:typetekst"/> </sequence> <attribute name="typetiltak" type="rtv:typetiltak" use="required"/> </complextype> </element> <!--= = = = Blokk 2 Diagnose og sykdomsopplysninger = = =--> <!--= = = = ENKELTDIAGNOSE = = = =--> <element name="enkeltdiagnose"> <documentation>for å angi kodeverdi, tekstlig beskrivelse av kodeverdi og sorteringsrekkefølge for enkeltdiagnoser (en pasient kan ha flere diagnoser). En hoveddiagnose må alltid oppgis.</documentation> <complextype> <attribute name="diagnose" type="string" use="optional"/> <attribute name="kodeverdi" type="string" use="required"/> <attribute name="sortering" type="nonnegativeinteger" use="required"/> </complextype> </element> <!--= = = = VURDERINGYRKESSKADE = = = =--> <element name="vurderingyrkesskade"> <documentation>for angi om trygdekontoret bør vurdere om det er en yrkesskade/yrkessykdom.</documentation> <complextype> <attribute name="borvurderes" type="rtv:typejanei"/> <attribute name="skadedato" type="date" use="optional"/> </complextype> </element> Versjon.0 3

40 XML Schema <!--= = = = Blokk 4 Forslag til tiltak ut over medisinsk behandling= = = =--> <!--= = = = FORSLAGTILTAK = = = =--> <element name="forslagtiltak"> <documentation>for å angi aktuelle tiltak ut fra medisinsk vurdering, nærmere opplysninger om disse tiltakene, evt. begrensninger i forhold til tiltakene eller begrunnelse for at det ikke er aktuelt med tiltak.</documentation> <complextype> <sequence> <element ref="rtv:aktuelttiltak" minoccurs="0" maxoccurs="unbounded"/> <element name="opplysninger" type="rtv:typetekst"/> <choice> <element name="begrensningertiltak" type="rtv:typetekst"/> <element name="begrunnelseikketiltak" type="rtv:typetekst"/> </choice> </sequence> <attribute name="tiltak" type="rtv:typejanei" use="optional"/> </complextype> </element> <!--= = = = Blokk Opplysninger om pasienten og om arbeidsforhold= = =--> <!--= = = = PASIENTOPPLYSNINGER = = = =--> <element name="pasientopplysninger"> <complextype> <sequence> <element ref="rtv:pasient"/> </sequence> <attribute name="flerearbeidsforhold" type="rtv:typejanei" use="required"/> </complextype> </element> <!--= = = = Blokk Legens underskrift mv. = = =--> <!--= = = = LEGEUNDERSKRIFT = = = =--> <element name="legeunderskrift"> <complextype> <sequence> <element ref="rtv:helsepersonell"/> </sequence> <attribute name="signaturdato" type="date" use="required"/> </complextype> </element> <!--= = = = Blokk 4 Forslag til tiltak ut over medisinsk behandling= = = =--> <!--= = = = SPESIFIKASJON = = = =--> <element name="spesifikasjon" type="rtv:typetekst"/> <simpletype name="typetekst"> <documentation>type for utførende beskrivelser</documentation> <restriction base="string"> <whitespace value="preserve"/> </restriction> </simpletype> 32 Versjon.0