Hej, jag heter Axel Ekberg och jag arbetar som Data Engineer på
Socialstyrelsen.
Vi ska nu prata om stöd för systemintegration kopplat till
ICD, därav namnet API och teknisk funktionalitet.
Huvudkomponenten i presentationen och i ICD-11
tekniska landskap heter ICD-API.
Ordet systemintegration som jag nämnde här inledningsvis kan
tyckas väldigt brett och diffust men exempelvis så
möjliggör ICD-API för utveckling av nya hälso- och
sjukvårdssystem eller applikationer.
I videon praktisk introduktion till ICD-11 söktjänst och
kodningsverktyg så visas några exempel på hur vi kan nyttja de
nya digitala verktygen som lanserats i samband med
publiceringen av ICD-11.
Verktygen, söktjänsten och kodningsverktyget tillhandahålls
av WHO och finns uppsatta för end-users eller slutanvändare.
Verktygen riktar sig främst till personal inom hälso- och
sjukvården som stöd i deras arbete.
ICD-API är en förutsättning för att verktygen, söktjänsten och
kodningsverktyget ska fungera då de bygger på ICD-APIs
funktionalitet och dess inbyggda logik.
Ett annat sätt att se på de här två olika delarna är att kodningsverktyget
och söktjänsten lämpar sig bättre för mänsklig interaktion
och ICD-API lämpar sig för maskin-till-maskin interaktion
med ICD-innehållet.
För framgångsrik implementation och användandet av ICD-11 så
spelar ICD-API en minst sagt central roll.
Så, vad är då ett API?
API är ett begrepp som i diskussioner kring moderna IT
-lösningar är näst intill oundvikligt.
ICD-API är ett HTTP-baserat rest-API som stödjer interaktion
via i princip alla programmerings- språk och tekniska plattformar.
Vi skulle kunna diskutera och prata om olika typer av API:er
under en längre tid men vi nöjer oss nu med att konstatera
att HTTP eller HTTPS-baserade rest-API är
är den vanligaste typen av API-er idag och de använder HTTP
-metoder för att möjliggöra maskin-till-maskinkommunikation.
Ett APIs huvudsakliga uppgift är att ange hur
programvarukomponenter ska interagera med varandra.
Ofta när man pratar om API-er stöter man på en definition lik
den som ni kan se på bilden här.
Ett kontrakt som definierar hur programvarukomponenter
samverkar, vilka data som kan nås och hur tjänster kan användas.
API-er abstraherar bort en del av komplexiteten hos
underliggande system, vilket gör det enklare för utvecklare
att bygga applikationer genom att interagera med andra program
eller tjänster utan att fullt behöva förstå deras interna funktionalitet.
En distinktion som kan vara värd att notera är skillnaden på API
-specifikation och en API -implementation.
Termen API används ofta relativt frikostigt och min
uppfattning är att det ibland syftas på specifikationen och
ibland på implementationen.
Specifikationen definierar vad ett API kan göra eller genomföra
medan implementationen syftar till den faktiska koden eller
applikationen.
Alltså hur saker fungerar och se till att lösningen levererar det
som tidigare har definierats.
En jämförelse som ibland används är en beställning på en restaurang.
Menyn definierar vad köket och personalen kan leverera och åstadkomma.
Köket och dess personal tar emot din order och levererar
tillbaka det som du har beställt.
Hur köket och personalen går tillväga varierar högst roligt
från restaurang till restaurang.
Men att de har processer och verksamhetsregler och viss logik
och har implementerat det är högst troligt.
Och du som gäst behöver inte bry dig om hur de har satts upp.
Du är nöjd så länge du får den hamburgare som du har beställt.
En aning simplifierat men ett ganska talande exempel.
Här kan ni också se hur DIGG, myndigheten för digital
förvaltning, definierar de centrala termerna API Request
och API Response på sin webbplats dataportal.se.
Sammanfattningsvis så skapar ett API effektiv kommunikation
mellan programvarukomponenter och möjliggör för enklare
sammanlänkning av tekniska byggblock eller funktioner.
Som möjliggör för systemutvecklare att bygga
välfungerande applikationer.
Det underlättar också fördelning av data då en organisation
exempelvis exponerar data till allmänheten eller andra
organisationer via ett API.
Innan vi går vidare ska jag försöka konkretisera konceptet
en aning ytterligare.
Kanske framförallt för er som inte är helt bekanta med API:er
genom att gå igenom ett exempel från verkligheten.
Exemplet som jag personligen tycker är ganska bra på APIs
funktionalitet är värderapplikationer i våra
mobiltelefoner.
De allra flesta idag använder någon typ av smart mobiltelefon
med någon form av väderapplikation installerad.
Vi har inte all världens väderdata lagrat i våra
mobiltelefoner.
Men när vi vill ha reda på hur mycket det exempelvis kommer att
regna i Borås imorgon så skickar våra mobiltelefoner en
begäran till en central väderdatabas som returnerar det
data som mobilapplikationen har frågat efter.
Och i slutändan så visas data upp på ett strukturerat sätt i
våra mobila applikationer.
Och som vi kan se på bilden här, när man talar om API så
används ofta termerna klient och server.
Som avslutning till denna introduktion kommer jag visa upp
ett exempel på hur ICD-API kan integreras i ett fiktivt system
med hjälp av Embedded Classification Tool.
Embedded Classification Tool kan du läsa mer om på WHOs webbplats
för ICD API.
Förhoppningsvis så bidrar den här filmsnutten till lite
inspiration.
Så, nu är min förhoppning att vi tillsammans ska skaffa oss
lite bättre kunskaper om ICD API och Embedded Classification Tool.
Embedded Classification Tool, ofta förkortat ECT i
dokumentationen, är ett JavaScript-bibliotek som
möjliggör integration av verktygen, kodningsverktyget och
söktjänsten i applikationer eller system.
Embedded Classification Tool möjliggör för förenklad
interaktion med ICD-API och underlättar en hel del för oss
systemutvecklare.
Vi kan nyttja Embedded Coding Tool, en integrerad variant av
kodningsverktyget för att exempelvis fånga upp sökningar
och data som returneras av ICD-API.
Och vad vi väljer att göra med de här datamängderna som
returneras, där har vi nästintill oändliga möjligheter.
Vi ska nu kika på ett exempel som jag har byggt där vi touchar
vid några av de här funktionerna.
Javascript och webbutveckling är ingenting som jag sysslar med på
daglig basis.
Ni får gärna ha översyn med det.
Journalsystem och patientanteckningar lika så.
Kanske ganska uppenbart när vi kikar igenom det här exemplet.
Med det sagt så kanske det visar på att det är ganska
simpelt att bygga lösningar med den här komponenten ECT.
Det vi ser framför oss här är ett journalsystem för mitt
privata sjukhus.
Västra mjukisdjurssjukhuset heter det.
Den enda anställda är jag och jag tar hand om mjukisdjur med
lite olika åkommor.
Journalsystemet är kanske något kontroversiellt.
Jag har bland annat bilder på mina patienter här så jag ska se
vem som är vem.
Jag har faktiskt redan gått live med ICD-11 i mitt system och
byggt in lite funktioner för att enklare kunna klassificera
sjukdomar korrekt och de tänkte jag gå igenom och visa lite
snabbt nu.
Som ni kan se här så för jag anteckningar om mina patienter
för att enklare kunna dra till minnes vad som drabbat dem och
senare någonting som kan hjälpa mig i mitt klassificeringsarbete.
Jag har integrerat kodningsverktyget i mitt
journalsystem för att kunna söka på koder.
Jag har också ställt in så att kodningsverktyget använder sig
av svenska.
Det här är ganska enkelt att ändra i inställningarna.
Jag skulle också kunna applicera andra typer av
inställningar i mitt kodningsverktyg där jag redan
från start exempelvis kan filtrera så att jag enbart visar upp
ögonsjukdomar om jag istället skulle bedriva ett mjukisdjurs-
ögonsjukhus exempelvis.
Jag kan söka på koder via kodningsverktyget och skicka
frågor till ICD-API.
Svaren som jag får eller de svar jag väljer kan jag
exempelvis nyttja för att skicka andra frågor till ICD-API.
I det här fallet så skickar jag frågor till en lokal
installation av ICD-API som körs som en Windows-service
direkt på min server.
Hur jag designar min lösning och vilka svar jag väljer att
fånga upp, vilka frågor jag väljer att skicka tillbaka till
ICD-API och så vidare.
Det går att kombinera på en rad olika sätt genom att använda API
-ets olika endpoints.
Som ni kan se i min patientlista här ute till vänster så är det
två patienter som saknar värde i kolumnen ICD-11.
Det är Gisela Gris och det är Gunnar Gås.
Nu ska vi se till att tilldela de koder genom två olika tillvägagångssätt.
I det första fallet så tänkte jag använda mitt integrerade
kodningsverktyg och det har jag placerat här längst upp till
höger under rubriken kodningsverktyget.
Jag kan se i mina anteckningar att jag är ute efter att hitta
koden för allergisk renit orsakad av pollen eller
någonting i den stilen.
Jag börjar med att testa och söka här uppe på pollenallergi helt enkelt.
Och jag får en träff och här är det då logiken som finns i API
som söker upp koder och ger den bäst matchande koden som svar
vilket förhoppningsvis är den koden som jag är ute efter.
Så jag får upp koden här i sökfältet och klickar på önskat
sökalternativ.
Sådär.
Systemet, mitt journalsystem här då, använder koden jag valt
för att sedan hämta andra data såsom beskrivning, vi har URI, kod och titel.
Och den kontrollerar även här faktiskt om det finns några
kodningsanmärkningar.
Och i det här fallet då inga kodningsanmärkningar.
När jag har hittat den kod som jag söker efter så väljer jag
här att importera koden.
Och scrollar ner för att spara den till min patient.
Sådär, då har vi... en ICD-11-kod för Gisela gris.
Att kunna skicka frågor till ICD-API bidrar till möjligheten
att skräddarsy lösningar.
Jag kan få ut andra saker såsom överordnade koder eller
postkoordineringsalternativ, kanske kapiteltillhörighet och
visualisera det i den applikationen som jag valt att
bygga utifrån vad som anses relevant.
Här till exempel då genom att inkludera beskrivningen så kan
jag ganska snabbt se om den sjukdomen som jag beskrivit i
mina anteckningar stämmer överens med beskrivningen från ICD-API.
Vi väljer att nollställa kodningsverktyget här och för
att visa på ett annat exempel det är att kunna hämta ut de här
eventuella kodningsanmärkningarna som kan
hjälpa mig i min kodning och som skulle kunna ge mig en
indikation på hur jag bör koda.
Så om jag istället här väljer att söka på Diabetiskt fotsår.
Jag får en träff.
Så gör vi så där och då så ser vi att här hittar jag en
kodningssamärkning som potentiellt då skulle kunna
hjälpa mig i mitt dagliga arbete.
Vi väljer att nollställa den igen och vi hoppar ner till Gunnar Gås.
Här använder jag mig av en annan lösning som inte använder
sig av Embedded Coding Tool utan skickar direkta frågor till
ICD-API via det här JavaScript -bibliotekets fördefinierade
funktioner och har på så sätt skapat mig egen
autokodningsfunktionalitet.
Jag kan plocka en anteckning från en patient här.
Sådär.
Jag väljer att ta anteckningen direkt från Mr Gunnar Gås
och skriver in det i mitt textfält under autokodning.
När jag klickar på knappen här högst upp så har jag byggt upp
det på så sätt att då skickas en fråga...
en API-request till en specifik endpoint...
i min installation av ICD-API.
Den här texten blir då en del av requesten.
Jag får ett API-respons där jag har valt ut vilka parametrar
jag ska ta hand om och i det här fallet så har jag valt att
omhänderta koden, namnet eller titeln.
Och någonting som kallas för Match score.
Jag väljer att klicka här och ser då att det är det här jag
får returnerat av ICD-API.
Och för att förtydliga här så är Match score en indikator på
hur väl ICD-API anser att koden matchar den text som jag valt
att skicka in.
Jag tycker att det ser bra ut så jag importerar koden och
uppdaterar min patientinformation.
Sådär.
Jag hoppas att ni har fått lite inspiration inför nästa del.
Lycka till!
Så, vad vi har gjort och gått igenom nu.
Vi har touchat på några av de nya
tekniska möjligheterna med ICD-API.
Och det här är bara ett axplock av de funktionerna som faktiskt finns.
Vi har också i den här filmen visat på lite vad klassificering
av ICD genom ett integrerat kodningsverktyg kan bidra till i
en organisation eller i ett system.
Avslutningsvis så ser ni två länkar till Socialstyrelsens
webbplats om ni har frågor om klassifikationer och koder.
Eller vill hitta mer information om ICD-11 på Socialstyrelsens webbplats.
Tack så mycket och lycka till!
Undertexterna är AI-genererade och granskade av expert.