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.

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 (udfra SOSI Idkortet) 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.

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.

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

@Jonas: Hvor laves opslag til behandlingrelation (kan du putte ind et sted?)

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.

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).

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 (TODO)
• At der i SOSI Idkortet er en uddannelseskode tilstede, der overholder det gældende format (TODO) 

Mapning mellem LAR og CAVE

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