Indledning

Sundhedsstyrelsens Bivirkingswebservice (BivWS) er en teknisk snitflade til indberetning af bivirkninger, observeret ved brug af lægemidler. Webservicen kaldes af fagsystemer i typisk primær- eller sekundærsektoren, der benyttes af sundhedsprofessionelle. Intentionen er at gøre det let at foretage indberetningen af bivirkninger fra eget system, ved automatisk at overføre stamoplysninger på bla. patienten, lægemidlerne og indberetteren fra fagsystemet til webservicen.

...

Terminologi

Følgende termer og centrale begreber er relevante i kontekst af denne specifikation:

Arkitektur

Løsningen har én direkte brugeraktør, en ICSR Administrator, der har til ansvar at overvåge om E2B-filer flyttes succesfuldt til Sentinel. Desuden har systemet en indirekte brugeraktør i de Sundhedsprofessionelle, der står for de faktiske indberetninger. På systemaktørsiden tilgår anvendersystemer løsningen gennem NSP, hvor E2B-snitfladen udstilles via DGWS. NSP’en checker autenticiteten af afsenderen og autoriserer denne til at bruge den faktiske webservice, hvorefter der viderestilles til BivWS hos MHRA.

...

Figuren nedenfor illustrerer det it-kompleks, som webservicen indgår i, samt hvordan sammenhængen er mellem webservicen og dets anvendere:

Image RemovedImage Added

Web Service-snitflade

Webservicen har to operationer:

...

b)    evt. valideringsfejl

Valideringsfejl

Hvis servicen ikke kunne validere den indrapporterede bivirkning imod XML-skemaet, returneres en fejl med en liste over de felter, der fejlede. Følgende data leveres:

• _SafetyReportID – Dette er det unikke ID på den rapport, der forårsagede valideringsfejlen..
• _FieldName – Dette er navnet på det felt, der fejlede valideringen.
• _ValidationMessage – En tekstuel beskrivelse på engelsk af hvorfor valideringen fejlede.
• _Severity – En angivelse af hvor alvorlig fejlen var ud fra følgende to muligheder:
• Error – Fejlen var så alvorlig, at bivirkingsrapporten ikke er sendt videre til Sentinel
• Warning – Fejlen var ikke alvorlig og bivirkningsrapporten er sendt videre til Sentinel

Success

Dette er en boolsk værdi, der angiver om de indsendte rapporter er valide. Hvis en eller flere rapporter ikke kan valideres, returneres ”false”, ellers ”true”.

E2B

De to metoder tager begge en XML fil som input, der overholder den internationale specifikation E2B i version 3 (se [E2B])

...

Den udvidede E2B DTD findes i et separat bilag.

BivWS via Den Gode Webservice hos NSP

Bemærk! Dette afsnit beskriver hvordan integrationen fra et anvendersystem i primær- eller sekundærsektoren til BivWS hos NSP implementeres. Afsnittet henvender sig til Leverandøren af integrationen mellem anvendersystemet og NSP. Kendskab til DGWS forudsættes.

BivWS udstilles på NSP vha. Den Gode Webservice. Et anvendersystem danner derfor en DGWS-kuvert og indlejrer bivirkningsindberetningen i form af en E2B-fil i denne, før hele kuverten sendes til NSP. Dette afsnit beskriver hvilke metadata, der skal være til stede i DGWS-kuverten til BivWS.

Netværk

Den Gode Webservice kræver et krypteret transportlag og aftaler mellem de udvekslende parter for at sikre konfidentialitet af data. BivWS udstilles på NSP via følgende netværkstyper:

Id-kort-attributter

Oplysninger om afsenderens identitet lagres i DGWS id-kortet. Hvis afsenderen identificerer en bruger er id-kortet af typen ”USER” og hvis det identificerer et system, af typen ”SYSTEM”.

...

Kommunikationsmodel

Den Gode Webservice definerer to overordnede kommunikationsmodeller: Sign On (SO) og Single Sign On (SSO). I et SO scenarium kommunikerer klient og serviceudbyder alene med hinanden, mens SSO scenariet introducerer en betroet tredjepart, Identitetsudbyderen (IdP) til at varetage autentifikationen. Service der kan håndtere SSO siges at indgå i SOSI føderationen.

Kuvert-attributter

I DGWS SOAP kuverters headere findes en række meta-oplysninger om de enkelte servicekald, hvoraf nogle udtrykker forventninger til serviceudbyderen. Selvom forventningerne i princippet kan variere fra operation til operation, idet der kan være forskel på hvor sensitive data der udveksles, ensretter denne specifikation attributterne på tværs af operationer aht. simpliciteten.

...

Logning

Persondataloven og Sundhedsloven udstikker retningslinjer for hvornår det påkrævet at logge hvem der har haft adgang til data. Dette fortolkes i bredeste forstand som at have set eller opdateret personfølsom information om en anden person. Logning udføres af både klient og serviceudbyder.

BivWS hos MHRA

Bemærk! Dette afsnit beskriver hvordan integrationen fra Den Nationale Serviceplatform (NSP) til BivWS hos MHRA i England implementeres. Afsnittet henvender sig til Leverandøren af integrationen mellem NSP og BivWS og ikke anvendersystemer.

...

http://dhma-ehr-service.web10.redantdev.com/SubmissionService.asmx?op=ValidateE2B.

Sikkerhed

Den Gode Webservice termineres hos NSP’en, der validerer den medsendte SAML-kuvert, autentificerer og autoriserer afsenderen til at benytte servicen. Transportlaget mellem NSP og BivWS krypteres med Secure Sockets Layer (SSL) via 128 bit nøgler, som sikrer konfidentialiteten af det transporterede indhold og de akkreditiver, der anvendes til at logge på.

Som akkreditiver forventer BivWS et brugernavn og et password, samt en identifikation af det kaldende system. Sundhedsstyrelsens opretter ét brugernavn og password, som NSP’en benytter ved alle kald, ligesom det vil være NSP’en, der står som kaldende system. Indberetninger, der sendes uden korrekt brugernavn og password får ikke et svar tilbage og vil heller ikke blive behandlet.

Referencer

[DGWS]         Den Gode Webservice, http://www.medcom.dk/wm110731

...