Introduktion

Formål

Læsevejledning

Definitioner og referencer

Introduktion til LAR

Løsningens opbygning

Der etableres med løsningen en webservice, som giver mulighed for opslag af lægemiddeloverfølsomhedsoplysninger for sundhedspersoner.

LAR indeholder yderligere en webservice, som giver mulighed for sundhedspersoner at registrere oplysninger vedr. lægemiddeloverfølsomhed for borgere.

Selve LAR Servicen ejer ikke data. Dette ansvar delegeres til den bagvedliggende CAVE Service (se i øvrigt CAVE Design og Arkitekturbeskrivelse).

LAR Servicen fungerer således primært som en fronten for CAVE Servicen. LAR Servicens ansvarsområder er følgende:

• Implementation af sikkerhed (DGWS)
• Anvendelse af samtykkedata i MinSpærring i forhold til opslag af lægemiddeloverfølsomhed - herunder håntering af værdispring
• Kald af behandlingsrelationservice til tjek/opfølgning
• Logning af opslag og registreringer (auditloging og MinLog)
• Mapning af kompleks FHIR model (i Cave Service) til enklere model mod anvenderne af LAR

Overblik over LAR

LAR er udviklet som en web applikation i henhold til Servlet specifikationen 2.5. Dette sikrer, at LAR kan afvikles på enhver Servlet Engine, der overholder denne specifikation - specielt på WildFly Application Server 8.2, der i øjeblikket anvendes på NSP.

Løsningen er opbygget af et antal (Maven) moduler, der hver dækker et overordnet ansvarsområde i LAR:

• Larservice-types: Har til ansvar at generere Java kode for LAR udfra dennes snitfladebeskrivelse (WSDL).
• Larservice-cave: Ansvar for at kalde den bagvedliggende CAVE (FHIR) REST service samt mapning mellem de typer, der anvendes i LAR snitfladen og den domænemodel, der eksponeres af den bagvedliggende CAVE (FHIR) REST service.
• Larservice-app: Forretningslogik, implementation af sikkerhedsprotokolen (DGWS) samt mapning af sikkerhedsprotokollens model og requestmodellen anvendt internt i LAR.
• Larservice-web: Modul, der samler de forgående moduler i en sammenhængende og eksekverbar (i f.eks. WildFly) WAR fil.
• Larservice-integrationstest: Integrationstests, der kan afvikles mod en kørende LAR service.

• SMB-Util: Utilities, der indeholder klientkode, der kan anvendes fra LAR til kald af de eksterne NSP services, der anvendes af LAR: Samtykke, MinLog og behandlingsrelationsservice.

Opslag af oplysninger om lægemiddeloverfølsomhed for en borger

Opslag af oplysninger om lægemiddeloverfølsomhed for en borger sker på følgende måde:

Først foretages der en validering af det indkommende request. Valideringen foretages på tre niveauer på vej ind i LAR Servicen:

• Sikkerheden håndhæves af modulet DGWS provider (se arkitekturtegning ovenfor). Kun kald, hvor sikkerhedskravene er overholdt sendes videre til LAR servicens forretningslogik (se i øvrigt afsnittet Sikkerhedskrav i forhold til kald af LAR).
• Valideringen af indholdet af requestet foretages i LAR forretningslogikken. For opslag af oplysning verficeres det, at:
  • TODO (@Lene kan du beskrive valideringerne for opslag?)
• Opslag i MinSpærring ved anvendelse af MSB-Util for at finde ud af, om der findes negative eller dataspecifikke samtykker for borgeren mod den opslående bruger eller organisationen, hvor opslaget foretages fra (en del af snitfladen for opslag). I tilfældet af negativt samtykke returnerer LAR uden videre en fejlkode til kalderen. NB! Der er i snitfladen mulighed for at angive, at man ønsker at foretage værdispring. Hvis kalderen angiver, at værdispring ønskes, så springes opslaget mod MinSpærring over.

For detaljer vedr. request- og responseformat for anvendere af LAR samt fejlkoder henvises til LAR Anvenderguide. Se i øvrigt også Beslutninger vedr LAR Snitfladen nedenfor.

LAR service transformerer i modulet til LAR-CAVE transformation (se tegning ovenfor) herefter requestet til FHIR og viderestiller forespørgselen til den bagvedliggende CAVE service, der står for selve dataopslaget. 

Kommunikationen med CAVE service (herunder fejlhåndtering) håndteres af LAR Servicens modul larservice-cave.

LAR servicen transformerer herefter FHIR responset fra CAVE til den mere simple responsemodel for LAR. Da FHIR stukturen i den bagvedliggende CAVE Service er mere kompleks, end det, der tillades i LAR har det været nødvendigt at foretage en række valg. Se afsnittet Mapning mellem LAR og CAVE for detaljer vedr. denne mapning.

Inden resultatet returneres sker der evt en filtrering af oplysningerne i henhold til MinSpærring (i tilfældet, hvor der findes dataspecifikt negativt samtykke).

De interne ider for de returnerede CAVE oplysninger (og ider for de frafiltrerede entries) logges vha AuditAPI'et (se i øvrigt LAR Driftsvejledning for detaljer vedr. indholdet af auditlogingsbeskeden).

Endelig sker der en registring af opslaget i MinLog. Se LAR Driftsvejledning for opsætning af registering i MinLog for opslag.

Registrering af oplysning om lægemiddeloverfølsomhed for en borger

Registrering af oplysninger om lægemiddeloverfølsomhed for en borger sker på følgende måde:

Først foretages der en validering af det indkommende request. Valideringen foretages på to niveauer på vej ind i LAR Servicen:

• Sikkerheden håndhæves af modulet DGWS provider (se arkitekturtegning ovenfor). Kun kald, hvor sikkerhedskravene er overholdt sendes videre til LAR servicens forretningslogik (se i øvrigt afsnittet Sikkerhedskrav i forhold til kald af LAR).
• Valideringen af indholdet af requestet foretages i LAR forretningslogikken. For opslag af oplysning verficeres det, at:
  • TODO (@Lene kan du beskrive valideringerne for registrering?)

For detaljer vedr. request- og responseformat for anvendere af LAR samt fejlkoder henvises til LAR Anvenderguide. Se i øvrigt også Beslutninger vedr LAR Snitfladen nedenfor.

LAR service transformerer i modulet til LAR-CAVE transformation (se tegning ovenfor) herefter requestet til FHIR og viderestiller registreringen til den bagvedliggende CAVE service, der står for selve dataregistreringen. 

Kommunikationen med CAVE service (herunder fejlhåndtering) håndteres af LAR Servicens modul larservice-cave.

LAR servicen transformerer herefter FHIR responset fra CAVE til responemodellen for LAR (@Lene hvad sender vi egentlig tilbage...bare lige to ord vedr dette).

Oprettelsen logges vha AuditAPI'et (se i øvrigt LAR Driftsvejledning for detaljer vedr. indholdet af auditlogingsbeskeden).

Registreringen medfører også et kald til MinLog. Se LAR Driftsvejledning for opsætning af registering i MinLog for oprettelse.

Designmålsætninger og -beslutninger

Sikkerhedskrav i forhold til kald af LAR

Det er besluttet, at der for både opslag af oplysninger og registrering af oplysninger i LAR kræves et niveau 4 SOSI Idkort (medarbejdercertifikat).

LAR servicen validerer sikkerheden på følgende måde:

• At der medsendes et gyldigt SOSI Idkort med niveau 4
• At der i SOSI Idkortet er et autorisationsid tilstede, der overholder det gældende format (Det kan være 5 tal, 5 konsonanter og/eller vokalen Y eller en kombination af tal og konsonanter og/eller vokalen Y.)
• At der i SOSI Idkortet er en uddannelseskode tilstede, der overholder det gældende format (4 cifre langt) 

Beslutninger vedr. LAR Snitfladen

Begrundelsen for at gøre feltet med autorisations-ID tvunget på snitfladen for registrering af lægemiddeloplysninger er, at datakvaliteten på det inkommende data øges, og at parterne har vurderet denne oplysning til at være meget vigtig.

En konsekvens heraf bliver, at det bliver vanskelligt at lave masse-indlæsning af historiske data (som måske ikke indeholder denne oplysning). Der skal findes en løsning på dette, men det ligger for nuværende uden for CAVE projektet.

Mapning mellem LAR og CAVE

TODO: Beskriv problemet med listen og løsning med foretruktne (LENE?)

Den konkrete opsætning af foretrukne kodesystemer er beskrevet i LAR Driftsvejledning.

Validering af requests i LAR

Der foretages validering for indkommende requests til både opslag og registreringer af lægemiddeloplysninger.

For opslag valideres det at:

• @Lene kan du beskrive valideringerne for opslag?
• LAR Service validerer ikke på værdierne for de indkommende kode systemer (dette overlades til CAVE Servicen - se i øvrigt CAVE Driftsvejledning)

For registreringer valideres det at:

• @Lene kan du beskrive valideringerne for registrering?
• LAR Service validerer ikke på værdierne for de indkommende kode systemer (dette overlades til CAVE Servicen - se i øvrigt CAVE Driftsvejledning)

Modellering af diverse identifiers i LAR

Der opereres flere steder i LAR snitfladen med eksterne identifiers f.eks. patientid, organisationsid og id for lægemiddel. For at lave den mest generelle snitfladet er der i LAR Servicen valgt en model, hvor disse identifiers skal angives som en struktur bestående af:

• Et kodesystem (OID)
• En kode (en streng, som antages at give mening i konteksten af det angivne kodesystem)

Som beskrevet i afsnittet vedr Validering af requests i LAR. så foretages der ikke i LAR en validering af de anvendte kodesystemer.