API för förfrågan om förekomst av prov

Syfte

Integrationen har två syften:

1. Hitta prov för vilka provgivare vill förändra samtycke eller se vilka prov som finns bevarade
   När en provgivare vill förändra samtycke för ett prov utgår detta från var provet är taget (vilken huvudman). Provet kan dock skickas till andra huvudmän (antingen delar av provet eller provet i sin helhet). För att säkerställa att allt material hittas behöver därför samtliga enheter där provet kan förvaras kontaktas för att säkerställa att förfrågan hanteras korrekt. Idag finns ingen komplett tillgänglig strukturerad dokumentation kring vart prov skickas som kan utnyttjas för detta.
   Det viktigaste är att kunna filtrera bort den majoritet av enheter som via denna integration kan garantera att de INTE har något prov givet de aktuella kriterierna för att på så sätt inte överbelasta enheterna med irrelevanta förfrågningar.

2. Hitta prov för en persons vård och behandling
   Som en del av en persons vård och behandling kan man ibland ha stor nytta av provmaterial taget tidigare. Dessa prov kan vara tagna var som helst i landet (och sedan distribuerats på samma sätt som i punkt 1).
   Detta gör att vi behöver fråga varje enskild enhet huruvida de har prov från den aktuella personen för att på så sätt kunna presentera för behandlande läkare var det finns prov, var det kanske finns prov och var det inte finns prov, så att denne kan fortsätta processen genom kontakt med relevanta enheter.

Sökning på prov på individnivå kan också vara aktuellt för forskning exempelvis vid kliniska läkemedelsprövningar.

Generella principer

Integration mot Svenska Biobanksregistret (SBR) kan göras på två olika sätt.

1. Överföring av data kring biobanksprov till respektive huvudmans del i SBR (mellanlagring)

2. Slagningar mot LIS-system på enskilda individer från SBR när frågan uppstår

Dessa står inte emot varandra, utan ska ses som två olika möjligheter att uppnå samma mål.
Den första lösningen möjliggör också framtida funktioner för att göra forskningssökningar baserat på egenskaper hos provet.

Integrationen är byggd med REST och skyddas av certifikat. Frågor ställs på på personnivå från SBR till respektive LIS-system.
Om inte SBR får ett korrekt svar tillbaka kommer detta tydligt att visas i gränssnittet. Endast vid korrekta svar (oavsett innehåll) kommer svaret att visas upp för användaren.

Implementation

Integrationen implementeras på så sätt att SBR ställer en fråga till alla anslutna laboratorieinformationssystem som då har möjlighet att svara ja/nej/kanske på huruvida prov finns.
Vi ger också möjlighet att skicka med mer information för att ytterligare kunna förbättra för läkare eller den som hanterar samtyckesförändring, men denna information är inte obligatorisk.

Frågan som ställs kommer att innehålla huvudman, personidentifierare och ett datumintervall för när provet är taget.

Svaret måste innehålla förekomst av prov (ja/nej/kanske) samt enhet där prov hanteras och kan innehålla:

• Provtagningsdatum
  (för att göra det enklare för behandlande läkare att bedöma om provet är relevant samt för att inte skicka ut begäran om förändring av samtycke på prov som inte berörs av begäran)

• Huvudman och klinik där provet togs
  (för att inte skicka ut begäran om förändring av samtycke på prov som inte berörs av begäran )

• Provmaterial / provtyp
  (för att göra det enklare för behandlande läkare att bedöma om provet är relevant samt för att inte skicka ut begäran om förändring av samtycke på prov som inte berörs av begäran)

• Anatomisk position
  (för att göra det enklare för behandlande läkare att bedöma om provet är relevant)

• Samtyckesinformation
  (för att inte skicka ut begäran om förändring av samtycke på prov som redan har korrekt samtycke registrerat)

Meddelandestruktur

Fråga

Svar

Prov

Datumformat

För samtliga datum används RSV-3339 utan tidszon, t.ex. 1998-06-22.

Personidentifierare

För att identifiera en provgivare används antingen personnummer (RSV704), samordningsnummer (RSV707) eller annat (OTHER)

Personnummer

Formatet ska vara ÅÅÅÅMMDD-NNNN, det vill säga enligt det officiella formatet men med den skillnaden att “-” alltid används (även om personen är äldre än 100 år) och att årtusende och århundrade alltid anges.
Se https://skatteverket.se/privat/folkbokforing/personnummer

Exempel: 19121212-1212

Samordningsnummer

Formatet ska vara ÅÅÅÅMMXX-NNNN, det vill säga enligt det officiella formatet men med den skillnaden att “-” alltid används (även om personen är äldre än 100 år) och att årtusende och århundrade alltid anges. XX är siffran för födelsedag ökad med talet 60.
Se https://skatteverket.se/offentligaaktorer/informationsutbyte/folkbokforingsamordningsnummer

Exempel: 19121272-1219

Annat

Formatet för annat är sträng av minst ett, max 50 tecken från ASCII 33-126. Vid sökning med annat ska alla exakta matchningar, oavsett typ, returneras.

Säkerhet och identifiering

Integrationen skyddas av certifikat och kräver att sändande system har ett av Inera utfärdat funktionscertifikat där sändande system identifieras med HSA-id.
Omvänt så identifieras svarande system med ett ssl-certifikat enligt nedan där URI:n garanterar identiteten.

Funktionscertifikatet som används behöver vara utfärdat under något av:

• Rot: SITHS e-id Root CA v2

  • Mellanliggande: SITHS e-id Function CA v1

• Rot: SITHS Root CA v1

  • Mellanliggande: SITHS Type 3 CA v1

Se https://inera.atlassian.net/wiki/spaces/IAM/pages/448103163/SITHS+Funktionscertifikat+-+Anv+ndarguide