Find mere information her: docs.meldenbivirkning.dk

Slettes:

Indledning

Lægemiddelstyrelsens bivirkningsservice (BivWS) er en teknisk snitflade til indberetning af lægemiddelbivirkninger til Lægemiddelstyrelsen. Webservicen kan kaldes af de fagsystemer i typisk primær-eller sekundærsektoren, der benyttes af sundhedsfaglige.

Formålet er at muliggøre en smidig og tidsbesparende indberetning af bivirkninger direkte fra eget fagsystemved at integrere løsningen i fagsystemet og dermed udnytte den information om eksempelvis patienten, lægemidler og indberetter, som allerede findes i systemet. Forventningen til løsningen er derfor både at øge antallet og kvaliteten af bivirkningsindberetninger.

BivWS gøres tilgængelig på Den Nationale Serviceplatform (NSP) af Sundhedsdatastyrelsenog benytter den danske nationale standard for identitetsbaserede webservices i Sundhedssektoren, Den Gode Webservice (DGWS). Systemer, der anvender BivWS (anvendersystemer), vil gøre dette gennem NSP.

Dette dokument beskriver arkitekturen bag BivWS og den snitflade anvendersystemet skal benytte i form af DGWS på NSP. Kendskab til DGWS forudsættes, og dokumentation af DGWS er ikkeen del af dette dokument.

Logikken i BivWS er implementeret af den engelske lægemiddelstyrelse (MHRA), som driver den i sammenhæng med Lægemiddelstyrelsens bivirkningsdatabase og -sagsbehandlingssystem(Sentinel). Når et anvendersystem kalder webservicen på NSP, viderestiller NSP kaldet til BivWS i England.

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

Ibrugtagning og test

For at få adgang til servicen, skal anvendersystemet kalde BivWS på NSP via Sundhedsdatanettet med et gyldigt certifikat. Det enkelte anvendersystem skal ikke oprettes som bruger med eget brugernavn og password, da BivWS kun har én bruger (NSP), som kalder servicen.

For at få adgang til produktion skal der gennemføres en certificeringstest med Lægemiddelstyrelsen, hvor såvel brugergrænsefladen i anvendersystemet samt kvaliteten af det indberettede vurderes. En certificerings-test forventes at vare 2-3 timer og skal aftales med Lægemiddelstyrelsen. Efter bestået certificeringstest vil der blive åbnet for produktionsadgang.

Der ligger en række godkendelseskriterier til grund for certificeringen. Godkendelseskriterier, certificeringstests og testscenarier er beskrevet i BivWS-Godkendelseskriterier.

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 Sundhedsfaglige, der indberetter bivirkninger.

På systemaktørsiden tilgår anvendersystemer Løsningen gennem NSP, hvor E2B-snitfladen udstilles via DGWS. NSP tjekker autenticiteten af afsender og autoriserer denne til at bruge den reellewebservice, hvorefter der viderestilles til BivWS hos MHRA.

BivWS validerer E2B-kuverten og lægger denne på Sentinel FTP-serveren, hvis valideringen gårgodt. Hvis valideringen fejler, returneres en fejlkode direkte via NSP til anvendersystemet.

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

Web Service-snitflade

Webservicen fra MHRA har 4 operationer, men det er kun de 2 operationer nævnt nedenfor, som kan anvendes til at indberette bivirkninger til Lægemiddelstyrelsens bivirkningsdatabase:

• ValidateE2Bxml: Servicens valideringsregler anvendes på det indsendte XML, men data lagres ikke og sendes ikke videretil Sentinel i denne operation.
• UploadE2Bxml: Det indsendte XML valideres og sendes derpå videre til Sentinel.

OBS! Username og password i E2Bxml-filen bliver ikke valideret, så de kan være tomme

OBS! XML-strukturen, der indsendes som en tekststreng i XML-elementet e2bXml skal være indesluttet i en CDATA markering, som i følgende eksempel:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope ...>
    <soapenv:Header>
    ...
    </soapenv:Header>
    <soapenv:Body>
        <sub:ValidateE2BXml>
            <e2bXml>
                <![CDATA[
                <ichicsr lang="en">
                <ichicsrmessageheader>
                ...
                </ichicsrmessageheader>
                <ichicsr>
                ...
                </ichicsr>
                ]]>
            </e2bXml>
        </sub:ValidateE2BXml>
    </soapenv:Body>
</soapenv:Envelope>

Begge operationer returnerer et svar med potentielt følgende to værdisæt:

a) Succes:

Dette er en boolsk værdi, der angiver om indberetningener valid. Hvis en eller flere indberetninger ikke kan valideres, returneres ”false”, ellers ”true”.

b) Valideringsfejl

Hvis servicen ikke kunne validere indberetningen imod XML-skemaet, returneres en fejl med en liste over de felter, der fejlede. Se bilag2for eksempel

WSDL og test XML

BivWS udstiller én WSDL. Se link til WSDL (test): https://wsdl.nspop.dk/bivwsp/submissionservice?wsdl

For at se specifikationen for XML-strukturen der indlejres i e2bXml elementet se link til MHRA (følg linket øverst på siden til Service Description): http://webapp02.laegemiddelstyrelsen.dk/submissionService.asmx

Eksempler på E2Bxml testdata kan hentes på https://www.nspop.dk/display/web/NSP+Service%3A+Bivirkningsindberetning

BivWS Feltoversigt (BivWS Fields and Validations) kan hentes på https://www.nspop.dk/display/web/NSP+Service%3A+Bivirkningsindberetning

E2B

Som input tager begge operationer en XML-fil, der overholder den internationale E2B-standard [E2B]. E2B(R2) er den gældende standard, men den kommende E2B(R3)-standard er introduceret men ikke obligatorisk at anvende endnu. I R3 vil der komme ændringer til enkelte E2Bxml dataelementer. I en overgangsperiode vil der ske en automatisk mapning fra R2 til R3 i Lægemiddelstyrelsens systemer.

E2B-formatet rummer imidlertid ikke understøttelse for danske attributter, der er nødvendige for sagsbehandlingen i Lægemiddelstyrelsen. Formatet er derfor udvidet med 4 ekstra dataelementer, som er vist i tabellerne nedenfor.

I XML-elementet patient:

I XML-elementet primarysource, som de sidste 3 elementer og i nævnte rækkefølge:

BivWS kan kun modtage et udvalg af alle de informationer, som den fulde E2B-standard indeholder. De relevante dataelementer, som kan sendes via BivWS er beskrevet i dokumentet ”BivWS Fields and Validations”, som indeholder en kort beskrivelse af dataelementernesamt reference til E2B guideline:

• E2B(R2) element number and name (in guideline)
• Element name
• User guidance
• Element source
• Length, value allowed, notes
• Validation
• Forslag til feltnavn i brugergrænsefladen
• Forslag til hjælpetekst til feltet i brugergrænsefladen

BivWS feltoversigt (BivWS Fields and Validations) kan hentes på https://www.nspop.dk/display/web/NSP+Service%3A+Bivirkningsindberetning

Integrationen til BivWS på NSP

Produktionsmiljøet

BivWS kan tilgås via den “centrale NSP”, hvilket kræver sundhedsdatanet aftaler. Nedenfor beskrives adgang gennem forskellige NSP kanaler, men da disse ofte ændres, er det en god idé at konsultere dokumentationen på nspop.dk. Det anbefales at læse Kom Godt i Gang Guiden.

Forskellige typer adgange:

• Adgang gennem de decentrale NSP'er er forbeholdt regionerne og beskrives
  ikke her.
• Adgang til BivWS gennem den central NSP's Viderestillingsservice (c-NSP +GW). Anvendes af andre systemer inkl. LPS systemer: http://cnsp.nsp.dsdn.dk:8080/decoupling

NSP Testmiljøer

Til brug for aftestningen af integration til BiWS stilles en række testmiljøer til rådighed. Det forventes, at brugeren allerede har læst Tilslutningsguiden, hvor der er en række generelle oplysninger om formål for de enkelte testmiljøer, hvordan testbrugere og -patienter oprettes, hvordan man får certifikater, samt generelle forudsætninger for at kunne bruge miljøerne.

Der er en række URL'er, der kan benyttes til at tilgå BivWS.

NSP endpoints på testsystemer er udstillet på internettet. I nedenstående URL'er kan “test2” erstattes med et af de andre testmiljøer, dvs. "test1", "prodtest" og "uddannelse". Bemærk at NSP'en her ikke følger de fastsatte navnekonventioner for testsystemerne, og anvender "uddannelse", ikke "udd".

• Adgang til BivWS gennem NSP gateway (NGW), også kendt som kommune gateway. Anvendes af EOJ systemer: https://test2-kgw.eksterntest.nspop.dk/sosigw/proxy/soap-request
• Adgang til BivWS svarende til en decentral NSP. Anvendes af EPS systemer: http://test2-cnsp.ekstern-test.nspop.dk:8080/decoupling
• Adgang til BivWS gennem NSP Viderestillingsservice. Anvendes af andre, inkl. LPS systemer: http://test2.ekstern-test.nspop.dk:8080/decoupling

For prodtest og udd er der også mulighed for at teste gennem Sundhedsdatanettet. Dette kræver en Sundhedsdatanet-aftale.

• Adgang til BivWS gennem NSP gateway (NGW) på SDN: Prodtest URL: https://prodtest-kgw.nsp.dsdn.dk/sosigw/proxy/soap-request , Udd https://uddannelse-kgw.nsp.dsdn.dk/sosigw/proxy/soap-request
• Adgang til BivWS svarende til en decentral NSP: http://prodtest-cnsp.eksterntest.nspop.dk:8080/decoupling
• Adgang til BivWS gennem NSP Viderestillingsservice på SDN: Prodtest
  URL: http://195.80.254.14:8080/decoupling,
  Udd http://195.80.254.13:8080/decoupling

Den Gode Webservice

BivWS udstilles på NSP ved hjælp af DGWS. Et anvendersystem danner derfor en DGWS kuvert og indlejrer bivirkningsindberetningen i form af en E2Bxml-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”.

Id-kortets versionsnummer refererer til den tilhørende DGWS specifikation og autentifikationsniveauet angiver hvilke typer af akkreditiver der er medsendt. På det laveste niveau, ”1” medsendes ingen akkreditiver, mens niveau ”2” tillader brugernavn og password. På niveau ”3” medsendes en digital signatur foretaget med et OCES virksomhedscertifikat (VOCES) og niveau ”4” tillader alene medarbejder OCES-signaturer (MOCES).

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.

BivWS definerer, at der maksimalt må gå 24 timer siden brugeren blev autentificeret til et servicekald udføres. Dette ”Timeout” implementeres af serviceudbyderen og kan medsendes i DGWS-kuverter som et hint om hvad klienten forventer.

BivWS giver ikke mulighed for at anvendersystemet kan få en uafviselig kvittering ligesom kaldet heller ikke kan prioriteres.

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.