Indhold

Introduktion

Formål

Formålet med dette dokument er at beskrive systemarkitekturen for CAVE servicen. 

Læsevejledning

Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i CAVE Servicen. 

Det forventes at læseren har en REST services. For en kort introduktion til FHIR henves til snitfladebeskrivelsen i CAVE anvenderguide og ellers til https://www.hl7.org/fhir/.

Dokument historik

Definitioner og referencer

Introduktion til CAVE

Løsningens opbygning

CAVE servicen er en løsning, der udstiller en FHIR snitflade. Det sker ved hjælp af HAPI FHIR java frameworket. I CAVE servicen udstilles der to typer af operationer. 

1. Mulighed for at registrere og opdatere lægemiddeloverfølsomhedsoplysninger på en given borger.
2. Mulighed for at læse lægemiddeloverfølsomhedsoplysninger for en given borger. 

I FHIR terminologi så er data centreret omkring AllergyIntolerance ressourcen. De FHIR ressourcer, der ikke anvendes, er der heller ikke understøttelse for i servicen. 

CAVE servicen er installeret således at det kun er LAR der kan kalde servicen. 

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/id-62bb3e98-0d8a-4669-81f5-5d0d09445a20.html" name="test" height="590" width="800">You need a Frames Capable browser to view this content.</iframe>   

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

CAVE er udviklet som en web applikation i henhold til Servlet specifikationen 2.5. Dette sikrer, at CAVE 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 omkring to maven moduler. Hvert modul har sit eget ansvarsområde.

• Cave-Service: Forretningslogik og konfiguration af HAPI framworket. Ved at anvende HAPI FHIR framework skal vi ikke selv implementere datamodel, persistering osv. i servicen. Det skal blot konfigureres i servicen. Der er implemeteret ekstra validering i forhold til FHIR standarden samt transaktionel håndtering af bundles. Dette er for at sikre en høj datakvalitet i servicen.
• Cave-war: Modul, der samler de forgående moduler i en sammenhængende og eksekverbar (i f.eks. WildFly) WAR fil. Modulet indeholder også kode til integrationstests af CAVE servicen.

De med grå markerede komponenter er standard HAPI FHIR komponenter. 

Registrering og opdatering af oplysning om lægemiddeloverfølsomhed 

Registrering eller opdatering af overølsomhed for lægemiddel sker på følgende måde.

1. HAPI FHIR Servlet modtager et HTTP POST request. Eksempel på request kan ses i CAVE - Guide til anvendere.
2. Request behandles af registrerede interceoptore. 
   1. SLA logning
   2. Validering af format i forhold til FHIR standarden. 
   3. Validering af om request indeholder FHIR ressourcer vi tillader. 
   4. Forretningsmæssig validering af indhold. Se afsnittet input validering for detaljer. 
3. Behandling og persistering af request i bundle processor komponenten. 
   1. Verificering om patient, practitioner, pracitioner role og organization allerede findes. Hvis det er tilfældet anvendes disse når data persisteres ellers oprettes der nye. 
   2. AllergyIntolerance persisteres i databasen via HAPI JPA Server komponenten. 
4. De oprettede eller rettede data returneres til LAR servicen.

Opslag af oplysninger om lægemiddeloverfølsomhed

Opslag af oplysninger om lægemiddeloverfølsomhed sker på følgende måde. Der kan læses med eller uden historik.

1. HAPI FHIR Servlet modtager et HTTP Get kald. Eksempel på kald kan ses i CAVE - Guide til anvendere.
2. Request behandles af registrerede interceoptore. 
   1. SLA logning
   2. Validering af format i forhold til FHIR standarden. 
3. HAPI JPA serveren kaldes for at foretage søgningen og data returneres til kalderen.

Validering

Udover standard validering i forhold til FHIR standarden, så foretager cave servicen en række ekstra valideringer. Dette sker for at sikre en tilstrækelig høj datakvalitet, og for at sikre data opfylder de krav LAR servicen har. 

Nedenstående er de ekstra valideringer, der er lavet i forhold til FHIR standarden. 

Bundle

1. Den modtagne request skal bestå af en AllergyIntolerance, Patient, PractitionerRole, Practitioner og Orgnization ressource. 

AllergyIntolerance

Oprettelse

1. Identifier i AllergyIntolerance skal være unik

Opdatering

1. Identifier i AllergyIntolerance skal eksistere ved opdatering
2. ClinicalStatus må ikke være inactive
3. Patient må ikke ændres fra oprindelig værdi
4. VersionId skal være udfyldt og nyeste version

Oprettelse og opdatering

1. Der skal være et code element og system skal være valid oid. Se LAR - Guide til anvendere for valid værdi. 
2. Der må maksimalt være én reaction. 
3. Hvis der er en reaction så skal der være én manifestation. 
4. Hvis der er en reaction skal coding indeholde enten en kode og system eller en text. Hvis der er kode og system skal system være valid oid. Se LAR - Guide til anvendere for valid værdi. 
5. ClinicalStatus skal være sat. 
6. VerificationStatus skal være CONFIRMED. 
7. OnsetDateTime skal være sat.
8. Type skal være sat.
9. Category skal være sat.
10. Der skal være reference til en patient. 
11. Der skal være reference til en recorder. 

Patient

1. Der skal være en identifer med en kode og system, hvor system er CPR. Se LAR - Guide til anvendere for valid oid. 

PractitionerRole

1. Der skal være en reference til en practitioner. 
2. Der skal vræe en reference til en organization. 

Practitioner

1. Der skal være én identifier. 
2. Der skal være en system og kode. Kode skal være oid for autorisationsid. Se LAR - Guide til anvendere for valid oid. 

Organization

1. Der skal være én identifier. 
2. Der skal være en system og kode. Kode skal være oid for SOR. Se LAR - Guide til anvendere for valid oid. 

<iframe src="https://archi.nspop.dk/NSP/570928ca/views/b6213c38-7fd6-4146-9252-3a1eaebf480a.html" name="test" height="430" width="800">You need a Frames Capable browser to view this content.</iframe>   

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

Sikkerhed

Servicen er implementeret uden en egentlig sikkerhedsmodel. For at sikre utilsigtet adgang til servicen er den installeret således, at det kun er LAR servicen, der kan kalde den. Dermed er det LAR servicen, der afgør om en given slutbruger har adgang til CAVE servicen. 

Integrationer

CAVE servicen integrerer ikke til andre services. Registrering i Minlog,  MinSpærring og behandlerrelation tjek er anvendersystemets ansvar. Det vil sige at det er LAR servicen, der har ansvar for dette, da det CAVE kun er tilgængelig for LAR servicen. 

Designmålsætninger og -beslutninger

Anvendelse af HAPI FHIR

Det er besluttet at anvende HAPI FHIR som FHIR implementering. HAPI FHIR kan anvendes på flere niveauer. I cave servicen er det besluttet at anvende HAPI FHIR i størst muligt omfang. Det vil sige at det HAPI FHIR anvendes blandt andet til nedenståenbde. 

• Udstille REST snitflade, der overholder FHIR standarden
• Validering af data i forhold til FHIR standarden
• Persistering af data. Det betyder også datamodellen er den HAPI FHIR dikterer.