Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 22 Next »

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 (givet legala förutsättningar under utredning)
    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

Huvudman

principal

Provgivare

person.personIdType

Format på identifierare för provgivaren. Någon av:

  • RSV704

  • RSV707

  • OTHER

person.personId

Prov

sample.sampledate.from

sample.sampledate.to

Svar

Obligatoriskt

Finns prov

sampleAvailable

Ja

Någon av
- YES
- NO
- UNKNOWN

Totalt antal prover

samplesAvailable

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

Obligatoriskt

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
Samtyckeshantering:
Avgöra om provet omfattas av begäran om ändring av samtycke.

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:
Att se var provet är taget för att avgöra om det omfattas av begäran om ändring av samtycke.

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:

  • CARE_AND_TREATMMENT

  • EDUCATION_DEVELOPMENT_QUALITY

  • RESEARCH

  • PRODUCT

Samtyckeshantering:
Att se nuvarande samtycke för att avgöra om det påverkas vid ny begäran om ändring av samtycke.

departmentName

Ja

Nuvarande provförvaringsenhet

Sträng av minst ett, max 100 tecken från ASCII 33-126

Sökning för vård:
För att kontakta rätt enhet om provet är relevant
Samtyckeshantering:
För att avgöra vart eventuell förfrågan om samtyckesförändring ska skickas

sampleCollection

Nej

Nuvarande provsamling

Sträng av minst ett, max 100 tecken från ASCII 33-126

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

  • No labels