Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 37 Next »

Denna sida dokumenterar arbete med systemintegrationer för LIS system.

Definition

Som regel använder regionerna specialiserade system för att hantera infromation som skapas i samband med laboratorieverksamhet. Dessa benämns i detta sammanhang som LIS för LaboratorieInformationsSystem. I och med att biobankning ofta sker i samband med analyser är det även allmänt så att det är i LIS som information om prov, som bevaras i biobank, dokumenteras. Det förekommer att även andra system används inom delområden där biobankning förekommer. Rutiner för vad som primärdokumenteras i den allmänna patientjournalen respektive andra områdesspecifika system så som LIS varierar i någon grad mellan regioner. För läsbarhetens skull abstraheras dessa distinktioner bort i detta dokument och termen LIS representerar konceptuellt det system där information om bevarade prover primärt lagras och underhålls.

Det är för SBRs räkning aktuellt att bygga integrationer för regionernas LIS i syfte att uppnå de mål som regionerna har för den samverkan som ingåtts. Denna sida dokumenterar på en hög nivå de lösningsförslag som tagits fram och arbetet med att implementera dem.

Bakgrund

Biobank Sverige har inom ramen för regional samverkan i uppdrag att utveckla system och annat stöd som hjälper regionerna att fullgöra de skyldigheter som följer av att man bevarar humant material i biobanker. Exempelvis finns i systemet katalogfunktioner för information om biobanker och provsamlingar, processtöd för hantering av domänspecika processer såsom samtyckesreglering och processtöd för ansökningsförvaranden.

De funktioner som systemet har idag byggs baserat på metadata och information som registreras för de ärenden som hanteras. Det har dock identifierats ett behov av att även kunna hantera information om de prover som är bevarade för att fullt ut kunna uppnå målet för samverkansöverenskommelsen.

Mer specifikt finns användingsscenarier formulerade som illustrerar hur Svenska Biobanksregistret, med information om bevarade prover, kan användas för att:

  • skapa full spårbarhet över hur biologiskt material har bevarats och använts visavi provgivarna

  • förbättra provgivarnas möjligheter att ta ställning till provernas potentiella användning (reglera samtycke)

  • förbättra förutsättningar för framtida diagnostik, även för vård hos andra huvudmän

  • understödja klinisk forskning

  • lösa andra tillåtna ändamål gentemot andra myndigheter (exempelvis smittspårning eller identifiering av avlidna i samband med rättsfall)

Dessa användningsscenarier finns i ytterligare detalj formulerade i dokumentet Svenska Biobanksregistret - Användningsscenario.

Biobank Sverige IT har fått uppdraget att utveckla en gemensam teknisk lösning för hur SBR ska försörjas med information om prover för att stödja dessa användningsfall, givetvis med hänsyn till de skall-krav som respektive fall ställer på korrekt och uppdaterad information.

Framtagande av specifikation för de krav regionerna ställer för att uppfylla ändamålen som provinformationen ska användas för görs tillsammans med regionernas kontaktpersoner för LIS-anslutningarna och utifrån tecknat samverkansavtal med tillhörande PM. Krav kring integration gentemot LIS-leverantörer Samverkansavtal

Historik

Det samverkansavtal som idag utgör grunden för utvecklingen av SBR föregås av ett likaledes gemensamt arbete med SBR men som utfördes i regi av Inera AB mellan 2009 och 2020. Redan i den tidigare versionen av SBR fanns en funktion för att importera data om bevarade prover som regelbundet exporterades från ett antal regioners LIS system. Lösningen byggde på ett gemensamt XML format för provinformation och en tjänst som läste in data fråm en XML-fil som överfördes periodiskt (typiskt dygnsvis).

Erfarenheterna visar att en tjänst enligt dessa principer är förknippade med en del arkitekturella utmaningar som gör det svårt att tillgodose användningsfallens krav. Dels var det svårt att formulera och genomdriva ett gemensamt format för data, även med ett schema för innehållet, och dels fanns stora utmaningar att hantera överföringen transaktionssäkert med korrekt felhantering vid avbrutna inläsningar.

När det nya SBR utvecklades inom ramen för regional samverkan utvecklades en tekniskt bakåtkompatibel lösning men där kravet på korrekt format stärktes och där mottagande hanterades transaktionellt säkert.

Nytt lösningsförslag

Med utgångspunkt i de svårigheter som hindrat tidigare implementation fick BIS IT uppgift att ta fram ett lösningsförslag som är lättare att implementera för klienter men som samtidigt inte gör avkall på de krav som finns för den tänkta användningen.

Användningsfallen kan delas upp i två kategorier;

  • I den ena kategorin användningsfall söker användaren information om prover och dess egenskaper oaktat vem provgivaren egentligen är. Till dessa hör fall som rör exempelvis planerad forskning.

  • I den andra kategorin användningsfall är provgivaren i förväg känd men förekomsten av eventuella prov okänd. Till dessa hör fall där provgivaren eller dennes läkare vill veta om det finns prover bevarade från tidigare vårdepisoder. Utmaningen i det senare fallet är att frågan måste besvaras extensivt för att anses besvarad. Det behövs så att säga en utsaga även om innebörden av det som inte hittas.

Av denna anledning utarbetades olika förslag för de olika användningsfallen. I de fall där data om bevarade prov behöver kombineras över systemgränser löses enklast genom att uppgifterna samlas i en gemensam databas på samma sätt som tidigare var tänkt. För övriga användningsfall förefaller det enklare att uppnå målet genom att vända på implementationen och låta SBR backas av en enkel tjänst hos vårdgivaren. Ett förslag till ett enkelt API har utvecklats och som kan användas för att lösa de djupa frågorna utan att all data behöver överföras och kontinuerligt hållas synkroniserad. I sin enklaste form svarar den bara ja eller nej givet en personidentifierare och en tidsperiod, men förslaget innehåller möjlighet att även exponera ytterligare information ner till provnivå för den som har möjlighet.

Gemensamt för de båda lösningarna är sedan att de utgår från att begränsa teknikval till enklast möjliga nivåer av protokoll och att de givetvis bygger på öppna generiska standarder.

I och med att de största svårigheterna i tidigare försök kopplas till transaktioner och felhantering föreslås att tjänsten implementeras synkront. Detta för att förtydliga hanteringen av tillståndsförändringar och minska lösningens komplexitet. Det kan behövas en annan ansats för en initial överföring men givet den volym prover som regelbundet sparas i vårdens biobanker är det inte ett tekniskt problem att överföra informationen med ett anrop per provtagning, och omedelbart i samband med att det registrerats i lokalt LIS (som biobanksprov, givetvis). För att ytterligare förtydliga tillståndshantering införs en uttrycklig delete-operation som används för information om att ett prov förbrukats eller kasserats.

Förankring

Det lösningsförslag som utarbetats har presenterats för arkitekturråd hos Inera som fått representera regionernas gemensamma arbete med arkitekturfrågor för nationella tjänster. Den bedöming som gjordes kan sammanfattas med att det inte fanns alternativ inom pågående projekt som skulle kunna lösa användningsfallen eller att några sådana planerades. Framförallt var frågan om extensiva sökningar något som inte planerades för inom pågående arbeten för utbyte av journalinformation.

Gemensamma möten med leverantörer av LIS system hölls med avsikt att få en återkoppling på om integrationsarkitekturen skulle vara ändamålsenlig att implementera. Leverantörer erbjöds även att offerera kostnad för implementation av nödvändiga funktioner för integrationen.

Lösningsförslag

De tekniska lösningar som föreslagits för att uppfylla ändamålen hittas här: API- och anslutningsbeskrivning för integration mot SBR och API för förfrågan om förekomst av prov och Föreslagen arkitektur

Kontaktperson

FAQ

Nedan samlar vi frågor som är återkommande från regioner, leverantörer och andra intressenter.

Hur beskrivs den legala grunden för personuppgiftsbehandlingen?
I och med att det är tre uttalade och delvis skiljande syften bakom planerade integrationer baseras de delvis på olika legal grund.

För användningsfallen inom område ett; att kunna tillgodose patienters behov av information, är den legala grunden kopplad till fullgörande av legal skyldighet. Regionerna har en skyldighet att vara transparenta så att patienter får en rimlig chans att ta ställning i samtyckesfrågor och då måste informationen göras tillgänglig på ett bra sätt till de som berörs.

För användningsfall två, användning av bevarat material för patienters vård kommer lösningen att falla under lag om sammanhållen vård och omsorgsdokumentation. För att säkerställa att lagens krav på patientens möjlighet att bestämma över utlämnande baseras lösningen på patientens samtycke. (Vilket är ett av flera skäl till att vi menar att lösningen måste bygga på att vi behåller data i källsystem snarare än att aggregera upp i gemensamma datalager.)

För användningsfall kopplade till forskning är den legala grunden allmänintresse. Vården har ett uppdrag att befrämja forskning för utveckling av vårdens förmåga och kvalitet. Att tillgängliggöra information om prover som kan användas för forskning är en viktig förmåga för att stärka forskning som är möjlig inom vården.


Varför görs inte detta inom ramen för andra projekt för Nationell Patientöversikt, Tjänstekontrakt och Sammanhållen journal?
Det finns inititiativ och pågående projekt hos SKR och Inera som har likartade och angränsande syften som dessa, framförallt de som rör utbyte av information för patientens vård. Vi har samverkat med dessa och utrett möjligheterna att inkludera biobanksområdets informationsmängder respektive användningsfall. Den gemensamma bedömningen är dock att inget av dessa projekt i dagsläget har förutsättningar att lösa de användningsfall som eftersträvas, ens på sikt.

  • No labels