Den Gode LÆ-blanket Webservice (DGLÆ:WS)

Transkript

1 Den Gode LÆ-blanket Webservice (DGLÆ:WS) MedCom arbejdspapir. Ver HVO Den Gode LÆ-blanket Webservice (DGLÆ:WS)...1 Del A: Formål og funktionalitet...2 Formål (=Usecase)...2 Sagsgangen i forbindelse med LÆ-blanketterne består af tre dele:...2 Den gode Webservice sikkerhedsniveau Webservice funktionalitet og flow... Fejl! Bogmærke er ikke defineret. MedCom Arbejdspapir. Den LÆ Webservice 1

2 Del A: Formål og funktionalitet Formål (=Usecase) Indenfor mange områder i den kommunale sagsbehandling, bl.a. vedrørende førtidspension og sygedagpenge, foregår der skriftlig kommunikation i form af forskellige blanketter - de såkaldte LÆ-blanketter. Kommunikationen sker primært mellem kommunen og de praktiserende læger, men også mellem kommunen og speciallæger på såvel sygehus som i privatpraksis. De benyttede blanketter er standardiserede, og denne standardisering foregår i lægeforeningens attestudvalg, hvor der er repræsentation fra de praktiserende læger samt Kommunernes Landsforening. Elektroniske udgaver af disse blanketter indgår som en naturlig del af lægernes praksiser, men forsendelsen er ikke elektronisk i dag. Sagsgangen i forbindelse med LÆ-blanketterne består af tre dele: 1) Anmodning fra kommunen med ønske om udfyldelse af en attest 2) Svar til kommunen i form af den udfyldte blanket 3) Afregning 1 Det er hensigten, at denne sagsgang gøres elektronisk og i denne forbindelse anvendes to standarder: MedComs Den Gode WebService (DGWS) til forsendelsen og MedComs Den Dynamiske (DDB) til indholdet. Nærværende dokument beskriver hvordan forsendelsesstandarden (DGWS) konkret påtænkes at blive taget i anvendelse i forbindelse med LÆ-blanketter. På MedComs hjemmeside forefindes endvidere de enkelte indholdsmæssige standarder som hedder DDB:LÆxxx og hvor xxx angiver nummeret for blanketten eksempelvis DDB:LÆ125. Der er altså fire typer dokumentation der er nødvendig for at lave integration til LÆ-blanketter: 1) Den generelle DGWS dokumentation 2 2) Den generelle DDB dokumentation 3 3) Den specifikke DGLÆ:WS beskrivelse (nærværende dokument) 4 4) De specifikke DDB:LÆxxx beskrivelser 5 Den Gode LÆ-blanket WebService (DGLÆ:WS) DGLÆ:WS benyttes til webservice kommunikation af LÆ-blanketter typisk mellem kommune og praktiserende læge. DGLÆ:WS kan benyttes til kommunikation af alle typer LÆ-blanketter. 1 Indgår ikke i nærværende WS forløb udover at anmodningsblanketterne per 1. juni 2006 indeholder oplysninger om elektronisk betaling (dvs. EAN nr. mv.) og disse oplysninger vil også blive inddraget i den elektroniske overførsel af anmodningsblanketten. 2 Link - mangler 3 Link - mangler 4 Link - mangler 5 Link - mangler MedCom Arbejdspapir. Den LÆ Webservice 2

3 DGLÆ:WS benytter Sikkerhedsniveau 5, det vil sige OCES Digital Signatur samt enten VPN- eller SSL-kryptering, dvs. kommunikationen kan foregå enten via det Internet-baserede sundhedsdatanet (VPN), eller SSL-krypteret via det åbne Internet. Kommentar [HVO1]: OBS: Uafklaret hvilket sikkerhedsniveau der skal benyttes. Jeg har skrevet niveau 5 for at skrive noget! Der er tre aktører i kommunikationen: Kommunen, blanketen og lægepraksis. Kommunen og lægepraksis er klienter, der laver DGLÆ:WS-kald op mod blanketen. en formidler således blanketterne mellem kommunen og lægepraksis og dermed forventes blanketen dels hele tiden at være opdateret med de nyeste versioner af DDB:LÆxxx-blanketterne og dels at være online døgnet rundt, således at klienterne kan kalde en når som helst. Typisk vil blanket en blive opstillet af tredje part, men en kommune kan naturligvis også vælge selv at opstille en blanket. Kommunikationen sker i seks DGLÆ:WS-kald: 1. LAE_GetEmtyForm Kommunen beder via et DGLÆ:WS-kald til blanketen om en opdateret, men tom DDB:LÆxxx-anmodningsblanket. 2. LAE_SendFilledRequestform Kommunen udfylder anmodningsblanketten og sender den via et DGLÆ:WS-kald retur til blanketen. 3. LAE_GetAllRequestforms Kald der bruges når blanketudfyldelse ikke kræver patientens fremmøde og lægen derfor hverken kender patientens cpr nr. eller blankettype: Lægeet laver et DGLÆ:WS-kald og modtager fra blanketen hhv. den udfyldte anmodningsblanket og den tomme 6 returblanket der knytter sig til anmodningsblanketten. 4. LAE_GetSpecificRequestfrom Kald der bruges når blanketudfyldelse kræver patientens fremmøde, og lægen derfor kender til både patientens cpr. nr. og blankettypen: Når patienten møder op/booker en tid, laver lægeet et DGLÆ:WS-kald, hvor der forespørges på et specifikt cpr.nr og en bestemt LÆ-blanket. 5. LAE_SendFilledAnswerform Når lægen har udfyldt svarblanketten, initierer han/hun, at lægeet via et DGLÆ:WS-kald sender den udfyldte blanket op på blanket en. 6. LAE_GetAllFilledAnswerforms Kommunen afhenter den udfyldte returblanket ved at initiere et DGLÆ:WS-kald. 6 Helt tom er den ikke, idet stamdata fra anmodningsblanketten - eksempelvis patientens navn og cpr. vil være udfyldt allerede. MedCom Arbejdspapir. Den LÆ Webservice 3

4 Den gode Webservice sikkerhedsniveau 5 DGLÆ:WS sendes i MedCom s Den Gode Webservice, der er en fælles SOAP kuvert der bl.a. varetager sikkerheds- og autentifikationsforholdene. Kommentar [HVO2]: Jeg er som tidligere nævnt usikker på, hvilket sikkerhedsniveau der skal anvendes her redegøres for eksempelvis sikkerhedsiveau 5. En SOAP kuvert består af en header -del og en body - del : header -delen indeholder kuvertens forsendelses- og sikkerhedsdata. body-delen er som udgangspunkt tomt og benyttes til at indlejre det valgte indhold eksempelvis en LÆ121 anmodningsblanket. Sikkerhedsdelen i DGWS gør det muligt at vælge mellem fem sikkerhedsniveauer og fire time-outs, dvs. det tidsinterval der tillades inden brugeren skal promptes for fornyet password. Ved kommunikation af patientfølsomme LÆ-blanketter skal anvendes Sikkerhedsniveau 5 og instant timeout. Dette indebærer at meddelelsen signeres med Digital Signatur for såvel kald (request meddelelsen) som svar (response meddelelser) at brugeren skal promptes for fornyelse af password inden afsendelse af hvert webservice kald. Såvel klient (kommune- og læge) som webservice udbyder (blanket) skal derfor understøtte både signering (afsendelse) og verificering (modtagelse) af OCES digitale signatur. Det fremgår af dokumentationen for DGWS hvordan sikkerheden skal implementeres i klient- og webservice erne. Tillige er de fem sikkerhedsniveauer beskrevet i dokumentationen for DGWS. MedCom Arbejdspapir. Den LÆ Webservice 4

5 Webservice funktionalitet og flow De ovenfor nævnte fem WS-kald er beskrevet yderligere nedenfor: Kald 1 - LAE_GetEmtyForm (kommune) Request i kald 1 et (typisk kommunens ESDH-) anmoder om en tom LÆ-anmodningsblanket. I kaldet angives hvilken anmodningsblanket kommunen ønsker at modtage. Response i kald 1 en returnerer en tom, men opdateret anmodningsblanket til klientet. Request i kald 2 et (typisk kommunens ESDH-) fremsender en udfyldt LÆ-anmodningsblanket til blanket en. Kald 2 LAE_SendFilledRequestform (kommune) Response i kald 2 en validerer data og hvis blanketten er mangelfuldt udfyldt (mandatory felter i DDB, der ikke er udfyldt), så returneres blanketten med besked herom. Når blanketten er udfyldt som den skal kommer der én af to beskeder til klientet: 1. Ok anmodningsblanketten ligger klar på blanket en til lægens afhentning. 2. Lægen kan ikke kommunikere LÆ-blanketter elektronisk. Det grafiske element i DDB gør, at kommunen nu blot kan printe anmodningsblanketten og sende den 7 per post. 7 Samt en opdateret og evt. delvist udfyldt svarblanket, som blanket en ligeledes medsender som response i de dette kald nr. 2. MedCom Arbejdspapir. Den LÆ Webservice 5

6 Request i kald 3 Dette kald bruges når blanketudfyldelse ikke kræver patientens fremmøde og lægen derfor hverken kender patientens cpr nr. eller blankettype: Kald 3 - LAE_GetAllRequestforms et (lægens IT-) anmoder om at modtage LÆ-blanketter, der venter på lægens udfyldelse. Dvs. kaldet indeholder udelukkende lægens ydernr. (læge) Response i kald 3 en returnerer anmodningsblanketten samt tilhørende svarblanket. Dog kun på den type lægeblanketter der ikke kræver patientens fremmøde ellers bruges kald nr. 4. Såfremt der ligger anmodningsblanketter for mere end én patient, eller flere anmodningsblanketter på den samme patient, fremsender blanket en disse i særskilte responses til klienten. Kald 4 - LAE_GetSpecificRequestfrom (læge) Kald 5 - LAE_SendFilledAnswerform (læge) Request i kald 4 Kald der bruges når blanketudfyldelse kræver patientens fremmøde. Kaldet foretages først når patienten møder op/booker tid og indeholder lægens ydernr., patientens cpr. nr samt blankettype. Response i kald 4 en returnerer anmodningsblanketten samt tilhørende svarblanket. Request i kald 5 Når lægen har udfyldt svarblanketten, initierer han/hun, at klientet (lægens IT-) via et DGLÆ:WS-kald sender den udfyldte blanket op på blanket en. Response i kald 5 en validerer data og hvis blanketten er mangelfuldt udfyldt (mandatory felter i DDB, der ikke er udfyldt), så returneres blanketten med besked herom. Når blanketten er udfyldt som den skal kommer der en kvittering om at blanketten nu ligger klar til afhentning hos kommunen. MedCom Arbejdspapir. Den LÆ Webservice 6

7 Request i kald 6 et (kommunens IT-) anmoder om at modtage udfyldte LÆ-svarblanketter, der venter på kommunens modtagelse. Kald 6 - LAE_GetAllFilledAnswerforms (kommune) Response i kald 6 en returnerer den udfyldte svarblanket. Såfremt der ligger svarblanketter for mere end én patient, eller flere svarblanketter på den samme patient, fremsender blanket en disse i særskilte responses til klienten. Såfremt der på blanket en ligger et antal anmodningsblanketter, som en læge efter nogle dage (eksempelvis 5) endnu ikke har afhentet, så sendes de retur til kommunen med én response per patient/sag. Kommunen kan så tage kontakt til lægen mhp. at afklare hvorfor lægen ikke har hentet blanketten. MedCom Arbejdspapir. Den LÆ Webservice 7