Förslag på ny anslutningsbeskrivning enligt aktuellt tänk kring hur integrationerna nyttjas. Denna kombineras med mer fristående och avskalade API-beskrivningar, som inte innehåller så mycket kring-info.

Som beskrivits ovan finns ett tvådelat integrationsbehov mellan LiS och SBR:

...

Sökning på person-id görs i detta alternativ mot LIS. Det innebär med andra ord en mer omfattande integration, men tanken är att detta ändå kan vara enklare att implementera för ett LIS med funktionella begränsningar. En sökning kan besvaras med ja/nej (prov finns / prov finns inte) utan att någon detaljerad information om prover måste returneras. Det kan också vara enklare att på en fråga tillhandahålla aktuell information än att fånga upp förändringar att skicka till SBR.

...

Leverantörernas implementation bör behöver tillåta opt-out, t.ex. för kunder som önskar hantera informationsförsörjning till SBR på annat sätt, som t.ex. genom att nyttja information som exporterats till ett datalager.

Hantering av historiskt data

Vid anslutning ska befintligt data tillgängliggöras i SBR. Det innebär att man från LIS:et måste skicka över befintliga prover, utan att detta är triggat av en uppdatering av provet. Samma funktionalitet ska kunna användas för att ladda om datat i SBR. Överföringarna bör göras via det vanliga API:t. Om en sådan lösning är svår att realisera kan alternativa lösningar övervägas.

Hanterad datamängd

-Definiera org / enhet / provsamling / provtyper / tidsperiod, så att SBR vet om det är värt att söka i systemet / datat-Fundering: På vilken nivå definierar vi förekomst av icke-digitaliserade prover? Huvudman? Labb?