Bakgrund
SBR (Svenska Biobanksregistret) har två integrationer. En för att ta emot prov och tillhörande information i syfte att exponera denna för forskare (dels för feasibility, dels för att monitorera insamlingstakt i forskares egna studier) och verksamheten för kvalitetsutveckling, uppföljning och utbildning. API- och anslutningsbeskrivning för integration mot SBR
Den andra integrationen (som beskrivs här) används för att hitta prover för specifik person, antingen inom ramen för samtyckesförändringar eller för att hitta tidigare tagna prov som kan vara relevanta för personens eller anhörigs vård och behandling. Sökning på prov på individnivå kan också vara aktuellt för forskning exempelvis vid kliniska läkemedelsprövningar.
Den senare ställer mycket högre krav på datakvalitet och täckningsgrad, samtidigt som fokus är på förekomst av prov och inte nödvändigtvis på detaljer kring provet som är relevanta för att hitta prov för forskning. Detta gör att vi tagit fram två olika, kompletterande, sätt att integrera mot SBR.
Syfte
Integrationen har två syften:
Hitta prov för vilka provgivare vill förändra samtycke
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.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.
Generella principer
Version: 1.0
För övergripande beskrivning av integrationer och anslutningsalternativ, se Anslutningsbeskrivning . Här beskrivs API för sökning på person-id mot LIS-system. Anrop mot detta API sker från SBR vid behov när användare nyttjar systemet.
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.
...
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)Nuvarande provförvaringsenhet
(För att skicka eventuell NEJ-talong rätt samt för att kontakta rätt enhet om provet behövs för vård och behandling)
Meddelandestruktur
Fråga
...
Meddelandestruktur
Fråga
Term | Obligatoriskt | Innehåll | Syfte |
|---|---|---|---|
principal | Nej | Huvudman som stod för provtagningen. Sträng av minst ett, max 100 tecken från ASCII 33-126 | |
person.personIdType | Ja |
Typ av identifierare för |
provgivare. Någon av:
“OTHER“ används för reservnummer. | |
person.personId |
Ja | Identifierare för provgivaren. Format bestäms av person.personIdType Notera att för personnummer och samordningsnummer används inte skatteverkets officiella definition. Se personidentifierare nedan | ||
sample.sampledate.from | Provtagningsdatum i formatet ISO-8601 (se nedan) | ||
sample.sampledate.to | Provtagningsdatum i formatet ISO-8601 (se nedan) |
Svar
Term | Obligatoriskt | Innehåll |
|---|
Syfte | |||
|---|---|---|---|
sampleAvailable | Ja | Finns prov. Någon av | |
samplesAvailable | Nej | Totalt antal prover |
Nej
Totalt antal prov som hittats. Används för att avgöra om listade prover är samtliga prover eller om det kan finnas andra |
Prover
samples | Nej | Lista av prover enligt nedan som hittats |
Prov
Term | Obligatoriskt | Innehåll | Syfte |
|---|---|---|---|
sampleDate | Nej | Provtagningsdatum i formatet ISO-8601 (se nedan) | Sökning för vård: avgöra vilket prov som är mest lämpligt vid flera träffar |
material_type | Nej | Provmaterial, t.ex. Vävnad, Helblod, Plasma eller Urin Sträng av minst ett, max 50 tecken från ASCII 33-126 | Sökning för vård: avgöra om provet är relevant |
anatomical_position | Nej | Lista av anatomisk position uttryckt i text där varje element är en sträng av minst ett, max 100 tecken från ASCII 33-126 | Sökning för vård: avgöra om provet är relevant |
sampleOrigin.principal | Nej | Huvudman som stod för provtagningen Sträng av minst ett, max 100 tecken från ASCII 33-126 | Samtyckeshantering: |
sampleOrigin.careFacility | Nej | Vårdenhet/klinik där provet togs Sträng av minst ett, max 100 tecken från ASCII 33-126 | |
consent.opposeTo | Nej | Lista av de samtycken provgivaren aktivt motsatt sig. Noll eller flera av:
| Samtyckeshantering: |
departmentName | NejJa | Nuvarande provförvaringsenhet Sträng av minst ett, max 100 tecken från ASCII 33-126 | Sökning för vård: |
sampleCollection | Nej | Nuvarande provsamling Sträng av minst ett, max 100 tecken från ASCII 33-126 |
...
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.
Regler
Om konsumenten anger huvudman men tjänsteproducenten inte håller information om huvudman där provet togs ska producenten returnera… (TODO alla prover som hittas för personen, utan information om sampleOrigin? inga prover?)
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