WebReq ændringer 2018

Transkript

1 WebReq ændringer 2018 Til leverandører der anvender integrerede systemkald til WebReq Version 1.01 W 1-1 -

2 WebReq ændringer 2018 Formål... 3 Introduktion... 3 Browserkrav og kryptering... 4 Brugerens cpr.-nummer... 5 Webservice for returneringer af rekvisitioner i denne session... 6 Web-service til Billetløsningen... 7 Adgangskrav... 8 Login... 8 Fail over... 8 Funktionalitet... 9 SendParameterstreng

3 Formål Introduktion DMDD har længe haft et ønske om at opdatere og forbedre sikkerheden i forbindelse med brugen af WebReq. En del af forholdene har været drøftet ved flere af de halvårlige WebReq-brugermøder, og der er allerede annonceret ændringer i forbindelse med januar mødet i år, som vil træde kraft i løbet af Persondataforordningen, som træder i kraft i år, er endnu en grund til, at alle leverandører i denne sammenhæng tager et samlet ansvar for at komme up to date med disse opgaver. Dette dokument beskriver således forskellige forhold, som: 1) dels kræver decideret programmering og netværks setup. Mærket: Programmering krævet 2) dels i visse tilfælde opdatering af rekvirentens installation (browsere og måske hardware) og endelig fokus på opsætninger i leverandørens program. Mærket: Opmærksomhedspunkt Alt sammen af hensyn til sikkerhed, sporbarhed og at logningskrav er opfyldt. Dette dokument er anmeldt til MedCom inden 1. april 2018, således at dele heraf evt. kan indgå i lægesystemernes testcamp - jf. aftale med PL - i efteråret. Dokumentet vil også være tilgængeligt på DMDD s hjemmeside

4 Browserkrav og kryptering Opmærksomhedspunkt for leverandørerne ift. deres installationer Omkring WebReq er der for øjeblikket et landskab, der ser således ud i forhold til rekvirenternes installationer af browsertyper: Internet Explorer 98,36 % Google Chrome 1,32 % Firefox 0,26 % Andre 0,06 % IE fordelingen: IE v ,01 % IE v ,10 % IE v ,61 % IE v ,54 % IE v ,10 % De 20,01% på IE v.7.0 er nok ikke et korrekt billede af installationer af PC ere ude i lægepraksis klinikker generelt. Men måske er en del af forklaringen også, at man i nogle tilfælde parkerer en sådan gammel PC til denne ene funktion nemlig at rekvirere. IE v. 7.0 blev releaset i oktober I WebReq har vi fra DMDD s side altid bestræbt os på at kunne favne over mange typer printere, browsertyper og generationer af browsere. Men nu er vi nået dels grænsen for de sikkerhedshuller, der kan accepteres og dels giver det også uforholdsmæssigt mange udfordringer på programmeringen af selve web-interfacet i WebReq med de 10 år yngre programmeringsværktøjer, vi anvender i dag. Dette har i sidste ende også betydning for at være begrænset i de muligheder, vi kan stille til rådighed for resten af brugerne, som har opdateret udstyr. Krav til sikkerhed Der er mange argumenter for at hæve kravet for browsertyper. Specielt er der omkring IE 7.0 i mange sammenhænge beskrevet decideret sikkerhedshuller, herunder bl.a. krypteringsnøgle længde mm. Derudover er der også et generelt hastighedsproblem i forhold til nyere og andre typer af browsere. Da IE v. 7.0 udgør langt, langt hovedparten af de gamle ikke opdaterede installationer, har vi valgt at hæve kravet til minimum IE v. 10,0. Overgang For at give brugerne af for gamle browsere mulighed for at sikre sig en stabil drift uden at få blokeret deres adgang, vil vi i WebReq introducere et popup-vindue, der fortæller brugeren, at den PC, de arbejder fra, skal opdateres for at kunne blive ved med at anvendes, når der arbejdes i WebReq. Ikrafttrædelse Warning-popup en i forbindelse med brug af for gamle browsere vil træde i kraft pr Blokering for adgang af for gamle browsere vil træde i kraft sammen med december releasen af WebReq - mellem 1. og 10. december

5 Brugerens cpr.-nummer Opmærksomhedspunkt for leverandørerne ift. opsætninger Krav til sikkerhed og log Der har de senere år været arbejdet på at dels at opdatere indberetninger til Min Log på NSP en og dels at kunne give adgang for WebReq-brugeren til at springe til Laboratorie Svarportalen. Kravet er i begge til fælde, at WebReq skal vide, hvem der sidder bag skærmen og rekvirerer. I WebReq er det i dag således, at skulle denne oplysning mangle, blokeres der for adgangen til Laboratorie Svarportalen. Vi kan se i statistikken for det integrerede systemkald, at alle systemer kan levere den data til WebReq. Men vi kan også se, at der i ca. 10% af kaldene mangler denne oplysning om brugerens/rekvirentens cprnummer i kaldet. Overgang Som nævnt bliver brugeren ikke generet af denne opsætningsmangel i deres system i dag bortset fra, at brugeren i dette kald ikke kan gå i Laboratorie Svarportalen - han/hun kan stadig godt rekvirere. Men der er så en mangel i vores login-indberetning til Min Log, og det vil fremadrettet være sikkerhedsmæssigt kritisabelt jf. Persondataforordningen - specielt når det er os bevidst. Ikrafttrædelse Fremadrettet vil WebReq - når denne data mangler - derfor prompte brugeren for NemID under login via et sådant integreret kald. Blokering for adgang uden brugerens cpr.nr. vil træde i kraft sammen med december releasen af WebReq - mellem 1. og 10. december

6 Webservice for returneringer af rekvisitioner i denne session Programmering krævet af nogle leverandører Baggrund I WebReq blev der for 10 år siden på forsøgsbasis udviklet en lægesystem-webservice, der oprindeligt var tiltænkt udviklet til brug for store lægehuse med eget laboratorie, hvor man typisk har et prøvetagningsliste-behov. Denne webservice er specielt designet til ovennævnte udgangspunkt og har derfor nogle mangler i forhold til, hvad den svarer på og tager med og ikke tager med af rekvisitioner. Den har aldrig været en del af Tilbagesvars-løsningen, men er trods det delvist blevet benyttet af nogle systemer. Den vil blive omlagt i løbet af året. Overgang Der vil i løbet af sensommeren blive stillet en ny Webservice til rådighed med lidt flere parametre, således at det oprindelige behov stadig bliver opfyldt, men der tages samtidig højde for, at den også vil kunne dække andre behov i forbindelse med Tilbagesvar. Den nye webservice vil også tilbyde noget funktionalitet, der gør, at der holdes styr siden sidst - returnerede rekvisitioner, således at der ikke i den grad skal poll es, som det er tilfældet i den gamle webservice i dag. Både den gamle og denne nye webservice bliver begge tilgængelige i løbet af sommeren i test-setup et og senere i driftssetup et for WebReq. De berørte lægesystemer vil således have mulighed for at kunne teste og betjene deres brugere optimalt i overgangsfasen og endvidere fremadrettet. Beskrivelsen af denne nye webservice vil være klar i løbet af forsommeren. Når ikrafttrædelsestidspunktet er passeret, vil den gamle webservice blive lukket ned. Ikrafttrædelse Fremadrettet vil alene den nye webservice fungere i WebReq. Den vil have sin beliggenhed sammen med Tilbagesvars-servicerne, således at vi kan have glæde af den større datakraft og fail-over mulighed, som er til rådighed i dette setup. Der skal altså ikke søges om nye SDN-aftaler i denne forbindelse. Lukning for adgang til den gamle webservice vil træde i kraft sammen med december releasen af WebReq - mellem 1. og 10. december

7 Billetløsningen sikkert login Programmering krævet af leverandørerne Krav til sikkerhed Der er her tale om en mindre opdatering, hvor man trækker en billet på Sundhedsdatanettet, inden man får adgangen til WebReq. Der bliver brugt samme parameteropbygning som hidtil og samme scrambling som hidtil. Se beskrivelsen vedr. SDN-opsætning, URL og billet-webservicen på de følgende sider. Overgang Disse beskrevne services bliver tilgængelige i løbet af sommeren i test-setup et og senere i driftssetup et for WebReq i august måned. Brugeren bliver i overgangsfasen ikke generet af denne nye mulighed for sikkert login, idet den gamle metode bliver ved med at eksistere. Når ikrafttrædelsestidspunktet er passeret, vil det dog være sådan, at brugeren bliver promptet og checket for sin autorisation i forhold til WebReq ved hvert opkald, hvis ikke systemleverandøren har programmet og installeret billetløsningsmuligheden hos rekvirenten. Dvs. fra ca. 1. september 2018 til ikrafttrædelsestidspunktet vil begge løsninger kunne anvendes uden nogen synlige forandringer for brugeren - både på gammel login -måde og på ny login -måde. Der vil i overgangsfasen blive etableret nogle ekstra sikkerhedscheck alene hos DMDD, der giver en større sikkerhed og sporbarhed end det er tilfældet nu; men som dog ikke er helt tilstrækkelige i forhold til det sikkerhedsniveau, som billetløsningen tilbyder. Ikrafttrædelse Fremadrettet vil WebReq kun fungere ligesom den plejer, - hvis billet-løsningen er på plads. Blokering for adgang uden billetløsning vil træde i kraft sammen med december releasen af WebReq - mellem 1. og 10. december Der er i løsningen taget højde for en automatisk fail-over mulighed, hvis Sundhedsdatanettet skulle være nede. Dette som en nødvendig proaktiv mulighed for ikke at lade de ca daglige brugere i stikken i forhold til deres til tider meget pressede arbejdsdag

8 Web-service til Billetløsningen Adgangskrav Til test er der udstillet en webservice der er tilgængelig via internettet. Produktionswebservicen udstilles via Sundhedsdatanettet. Url til testsystem Url til produktionssystem kommer senere Login Ved kaldet anendes validering på systemleverandør niveau, brugernavn er det samme som medsendes i parameterkaldet, og password til testsystemet er kxjykejyuk7gfrq7 Password til produktion udsendes direkte til leverandørerne. Fail over I det kaldende system bør det implementeres således, at hvis kaldet til WebService fejer, så kaldes WebReq på den nuværende måde. Dette bør laves for at det stadig er muligt at kommer på WebReq selvom forbindelsen til Sundhedsdatanettet måtte være nede. Brugeren vil dog så blive promptet for NemID

9 Funktionalitet Det udbydes et kald til at sende en parameterstreng til WebReq. Denne valideres ikke, men modtages blot, og gemmes. Der returneres en billet, der så skal medsendes efterfølgende. Denne billet er gyldig i 5 minutter efter udstedelse, og tillader kun login en gang. Eksempel: Parameterstreng krypteret: ÚÙµ^ ƒ xæmx *ÚÙµ^xƒY/*ÚÙµ^ƃºD*ÚÙµ^Mƒ*ÚÙµ^XƒÛ*ÚÙµ^ ƒ *ñáµ^ ƒxx xm àmn *ñáµ^xƒiáìc{iüìì*ñáµ^æƒ;júïïújì*ñáµ^mƒ áúûiü¾¾jim *ñáµ^xƒð*ñáµ^ ƒ nnnihj_µjñhúj* ñáµ^vƒ^ *ñáµ^ ƒ¹mxæ x MM *ñáµ^nƒ *ñáµ ^ƒì*úûì^ ƒ*úûì ^ƒü!µ*úûì^xƒ xxxæææm MMXXX * Ukrypteret rvt01=123456;rvt02=mt;rvt03=ib;rvt04=;rvt05=k;rvt06=1;pat01= ;pat02=nancy Ann;pat03=Berggren;pat04=Park Alle 48;pat05=_;pat06=1999 Hestepære;pat07=081;pat08= ;pat09=1;pat10=n;rkn08=;rkn10=Amt;rkn05= ; Det nuværende WebReq kald vil se sådan ud ƒ xæmx *ÚÙµ^xƒY/*ÚÙµ^ƃºD*ÚÙµ^Mƒ*ÚÙµ^ XƒÛ*ÚÙµ^ ƒ *ñáµ^ ƒxx xm àmn *ñáµ^xƒiáìc{iüìì*ñáµ^æƒ;júïïújì*ñáµ^mƒ áúûiü¾¾ji M *ñáµ^xƒð*ñáµ^ ƒ nnnihj_µjñhúj*ñáµ^vƒ^ *ñáµ^ ƒ¹mxæ x MM *ñáµ^nƒ *ñáµ ^ƒì*úûì^ ƒ*úûì ^ƒü!µ*úûì^xƒ xxxæææmmmxxx * Dette skal erstattes med den returnerede billet i stedet 3c44a347-e b-b2d4-433ffc034efe - 9 -

10 SendParameterstreng Sender en parameterstreng til WebReq, og returnerer en billet Request data Navn Beskrivelse Mandatory Brugernavn Brugernavn/systemnavn M Password Tilhørende password M Ydernummer Ydernummer Parameterstreng Krypterede parameterstreng Response data Navn Beskrivelse Mandatory SendParameterstrengResult GUID, der skal medsendes ved efterfølgende parameterkald til WebReq M Fejlmelding Exception