BKI - Beständiga kunskapsidentifierare
1.0.0 - ci-build
BKI - Beständiga kunskapsidentifierare
1.0.0 - ci-build
This page is part of the BKI - Best�ndiga kunskapsidentifierare (v1.0.0: Releases Draft) based on FHIR (HL7® FHIR® Standard) v5.0.0. . For a full list of available versions, see the Directory of published versions
| Datum | Version | Ändrad av | Kommentar | ||||
|---|---|---|---|---|---|---|---|
| 2022-03-22 | 0.1 | Olof Mattsson | Utkast | ||||
| 2023-11-13 | 0.2 | Anna Lund, Olof Mattson, Erik Tainio-Lagusson |
Ombearbetning och komplettering | ||||
| 2023-12-06 | 0.3 | Anna Lund, Olof Mattson, Erik Tainio-Lagusson, Helen Broberg |
Korrigeringar i samband med granskning | ||||
| 2023-12-06 | 1.0 | Helen Broberg | Granskad |
Detta dokument beskriver ett ramverk för skapandet av beständiga länkar eller URI:er och hur arbetet med dessa bör se ut för de resurser som Region Skåne själv äger eller kontrollerar på annat sätt. När man tillgängliggör resurser för andra är det viktigt att det finns ett enhetligt och beständigt sätt att referera till resurserna. Det är där beständiga länkar kommer in i bilden. Dokumentet presenterar en kort bakgrund kring beständiga länkar samt lyfter fram principer och riktlinjer för arbetet med beständiga länkar inom Region Skåne.
För mer information om beständiga länkar, nationellt och inom EU, hänvisar vi till givna referenser.
Ramverket används bland annat inom Enheten för digitalisering för att skapa beständiga referenser till resurser inom Terminologitjänsten och SDV, Skånes digitala vårdsystem. En fördel med de beständiga referenserna är att man kan utnyttja dessa till att skapa länkade data mellan olika förvaltnings- och produktionssystem.
| Begrepp | Beskrivning | |
|---|---|---|
| länk | Länk = hyperlänk Det finns olika typer av hyperlänkar på webben. Den vanligaste leder till en annan webbsida men det finns även hyperlänkar som leder till datafiler som kan laddas ned och hyperlänkar som kan returnera data. |
|
| URI | Uniform Resource Identifier Identifierare av en resurs på Internet eller i ett datornätverk. |
|
| URL | Uniform Resource Locator Är en typ av URI. Pekar ut var resursen finns. Vad vi i dagligt tal kallar för en webbadress eller länk är en URL. |
|
| beständig länk (PURI) | En URI som inte förändras, som identifierar något speciellt och där det inte finns någon oenighet om vad som identifieras. Beständiga länkar används som unika identifikatorer och länkar på samma gång. Med beständig syftas till att länken ej kommer att förändras under överskådlig framtid. Beständig länk kallas för PURI på engelska vilket står för Persistent Uniform Resource Identifier. |
|
| bki | Region Skånes implementation av beständiga länkar. Står för beständig kunskapsidentifierare och utgör en beständig länk med inledningen http://bki.skane.se. | |
| IANA | Internet Assigned Numbers Authority Ansvarar för standarden kring media types. |
|
| FHIR | Fast Healthcare Interoperability Resources Är en standard från HL7 som används för att standardisera hur man utbyter information mellan olika system. |
|
| Canonical Resource | En Canonical Resource i FHIR är en grundläggande komponent som fungerar som en gemensam referenspunkt i hälso- och sjukvårdssystemet. Den representerar ett viktigt koncept eller en central definition, som exempelvis kodsystem eller profil. Genom att använda en Canonical Resource undviks missförstånd och inkonsekvens i informationsutbyte. | |
| SDV | Skånes digitala vårdsystem. Det nya digitala vårdinformationssystemet som införs i hälso- och sjukvården inom Region Skåne. | |
| Millennium | Oracles vårdinformationssystem som är en del av SDV. | |
| Terminologitjänsten | Med Terminologitjänsten avses Region Skånes Terminologitjänst. Den del av Terminologitjänsten som riktar sig till slutanvändarna heter TIRS, Terminologi- och Informatikportalen. |
Detta dokument beskriver ramverket för beständiga länkar inom Region Skåne. Dokumentet riktar sig till personer som har en informatisk eller teknisk roll, som ansvarar för eller deltar i utformningen av IT-system. En beständig länk som använder sig av ramverket kallas för en bki vilket står för beständig kunskapsidentifierare.
En URI är en identifierare av en resurs på Internet eller i ett datornätverk. När man tillgängliggör resurser för andra är det viktigt att dessa identifierare inte ändras eller plötsligt identifierar en annan resurs, de behöver alltså vara beständiga.
En beständig länk kallas för PURI på engelska vilket står för Persistent Uniform Resource Identifier. Det är en internetadress som inte förändras, som identifierar något speciellt och där det inte finns någon oenighet om vad som identifieras. Beständiga länkar används som unika identifikatorer och länkar på samma gång. Med beständig syftas till att länken ej kommer att förändras under överskådlig framtid.
Ett fenomen som beständiga länkar hjälper till att avhjälpa är döda länkar. Med detta avses problemet att länkar har en tendens att sluta fungera. Problemet uppstår ofta då en webbplats görs om eller dokument flyttas till nya platser och i och med detta får nya URL:er. Genom att i stället identifiera resurserna med beständiga länkar och arbeta med ompekning kommer man runt problemet.
Ett annat område där beständiga länkar är en förutsättning är länkade data. Länkade data är en metod för att publicera strukturerade data på ett sätt som gör det möjligt att följa kopplingar mellan informationsobjekt över flera källor. Länkade data bygger på webbstandarder som HTTP och URI:er men i stället för att använda dem för att presentera information för människor är syftet att göra data läsbart för maskiner. Målet är att möjliggöra för vitt skilda aktörer att beskriva sin information på ett enhetligt sätt och därmed förenkla återanvändning och interoperabilitet.
Målsättningen med ramverket är att kunna skapa beständiga länkar för regionspecifika dokument och resurser som är och förblir beständiga över tid. Genom att skapa beständiga länkar som inte bryts uppstår förtroende för länkarna vilket medför att dokument och resurser sprids mer digitalt. Vi får möjlighet att länka data mellan våra olika system med en global unik nyckel. Det kommer leda till ökad tillgänglighet på kunskap som rimligen kommer att bidra till förbättrad och effektivare vård.
De första ansatserna till att ta fram riktlinjer för beständiga länkar gjordes i slutet av 1990-talet. Riktlinjerna har därefter utvecklats och anpassats av olika organisationer.
2012 genomförde EU en studie om beständiga länkar där man gick igenom exempel från olika länder, identifierade bästa praxis och utfärdade rekommendationer (ref 1).
2014 genomfördes ett nationellt arbete där bland annat Kommunförbundet i Stockholms län och Sveriges kommuner och landsting (nuvarande SKR) deltog. Det nationella ramverk (ref 2) som togs fram tolkar EU:s ramverk, lägger på nationella principer, råd, mallar och verktyg. Till stora delar är det nationella ramverket en översatt delmängd av EU:s ramverk med språkliga utvidgningar.
Region Skånes arbete med beständiga länkar påbörjades 2019 i och med införandet av SDV. En förstudie genomfördes 2020 med positivt resultat. En första implementation av beständiga länkar gjordes inom ramen för införandet av Terminologitjänsten.
Det ramverk som har tagits fram innehåller en tolkning av EU:s ramverk och det nationella ramverket. Syftet har varit att förenkla och skapa en stringens, möjliggöra ett distribuerat arbetssätt samt att säkerhetsställa att ramverket kan upprätthållas. Ramverket har förfinats och validerats i arbetet med Terminologitjänsten.
Inom ramen för arbetet har även en tjänst tagits fram för den tekniska hanteringen av de beständiga länkarna. Tjänsten, som är en del av Terminologitjänsten, utvecklas och förvaltas under ledning av Enheten för digitalisering.
Beslut om att använda sig av beständiga länkar kan tas av respektive projekt, organisation eller system inom Region Skåne. Beslutar man sig för att använda sig av beständiga länkar måste man bemanna för att sätta upp regelverket för sitt tilldelade område, så kallad bki-sektor, samt säkerhetsställa förvaltningen. Man måste även utse en ansvarig ägare.
En viktig faktor för att bibehålla tillit till beständiga länkar är att de är och förblir beständiga samtidigt som de ska vara enkla att skapa runt om i organisationen. För detta krävs både förvaltande organisation och distribuerad kunskap om ramverket.
En viktig faktor för att bibehålla tillit till beständiga länkar är att de är och förblir beständiga, samtidigt som de ska vara enkla att skapa runt om i organisationen. För detta krävs både förvaltande organisation och distribuerad kunskap om ramverket.
I detta kapitel definieras de begrepp som används i ramverket.
Läser du dokumentet för första gången rekommenderar vi att du går direkt till efterföljande kapitel där respektive begrepp och dess användning beskrivs mer ingående. Detta kapitel föreslås användas parallellt som referens.
Begreppsmodell
| Begrepp | Definition |
|---|---|
| bki | Beständig länk med standardiserad uppbyggnad och förvaltning, inleds alltid med http://bki.skane.se |
| bki-segment | De olika delar som bygger upp en bki |
| bki-värd | bki-segment som avser huvuddomänen i en bki, är alltid bki.skane.se |
| bki-sektor | bki-segment som anger området inom vilken bki:n identifierar |
| bki-typ | bki-segment som anger vilken typ av resurs som identifieras |
| bki-koncept | bki-segment som kan vara en samling av något, vilken slags resurs det är eller namnet på ett konceptschema |
| bki-referens | bki-segment som unikt identifierar den specifika resursen inom bki-sektorn och bki-konceptet |
| bki-historiksegment | bki-segment som identifierar en specifik historisk förekomst, har formatet _history/[versionsid] |
| bki-versionsspecificering | Identifiering av en specifik fastslagen version, har formatet |[versionsid] |
| bki-parameter | Frågeparameter som kommer efter bki:n och består av en namngiven parameter och ett värde |
| bki-formatparameter | bki-parameter där den namngivna parametern är _format och värdet är ett dokumentformat |
| referens-bki | Fullständig bki som identifierar en viss resurs, består av bki-segmenten bki-värd, bki-sektor, bki-typ, bki-koncept och bki-referens |
| identifierings-bki | referens-bki med bki-typ “id” |
| dokument-bki | referens-bki med bki-typ “doc” |
| definitions-bki | referens-bki med bki-typ “def” |
| dataset-bki | referens-bki med bki-typ “set” |
| fhir-bki | referens-bki med bki-typ “fhir” |
| koncept-bki | bki som identifierar ett visst bki-koncept, består av bki-segmenten bki-värd, bki-sektor, bki_typ och bki-koncept där bki-typ alltid är ”ont” |
| rymd-bki | bki som identifierar en samling av bki:er |
| sektorrymds-bki | bki som identifierar samlingen av alla bki:er inom en bki-sektor, består av bki-segmenten bki-värd och bki-sektor |
| typrymds-bki | bki som identifierar samlingen av alla referens-bki:er av en viss bki-typ inom en bki-sektor, består av bki-segmenten bki-värd, bki-sektor och bki_typ där bki-typ aldrig är ”ont” |
| konceptrymds-bki | bki som identifierar samlingen av alla referens-bki:er som hör till ett visst bki-koncept och har en viss bki-typ inom en bki-sektor, består av bki-segmenten bki-värd, bki-sektor, bki_typ och bki-koncept där bki-typ aldrig är ”ont” |
| ontologirymds-bki | bki som identifierar samlingen av alla koncept-bki inom en bki-sektor, består av bki-segmenten bki-värd, bki-sektor och bki-typ där bki-typ alltid är ”ont” |
Bki står för beständig kunskapsidentifierare och har formen av en URI. Precis som en vanlig URI är bki:n uppbyggd av olika delar enligt ett fastställt format. Nedan visas en fullständig bki med alla förekommande delar. Observera att bki:n definieras med http och inte https. På grund av att det är en typ av id-sträng.
bki: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}
/_history/[förekomstversionsid]|[verksamhetsmässigt versionsid]
?{bki-parameter}&{bki-parameter}
De delar i bki:n som följer efter ett snedstreck benämns bki-segment. I en vanlig grundläggande bki som används för att identifiera en resurs används bki-segmenten bki-värd, bki-sektor, bki-typ, bki-koncept och bki-referens. De grundläggande bki-segmenten och dess användning beskrivs i nästa kapitel Referens-bki och grundläggande bki-segment.
För att hantera versioner finns det två olika metoder. Antingen använder man sig av bki-historiksegment eller bki-versionsspecificering. Det går också att kombinera de båda metoderna. Bki-historiksegmentet i bki:n ovan är ”_history/[förekomstversionsid]”. Bki-versionsspecificeringen är ”|[verksamhetsmässigt versionsid]”. Hanteringen av versioner beskrivs i kapitlet Versioner.
Det är möjligt att ange parametrar för bki:n med hjälp av bki-parametrar. En bki-parameter anges sist i bki:n efter ett frågetecken. Det är möjligt att ange flera bki-parametrar separerade med &-tecken. I nuvarande ramverksversion är endast en typ av bki-parameter definierad; bki-formatparametrar. Beskrivning finns i kapitlet Parametrar.
Det finns bki:er som inte innehåller alla grundläggande bki-segment. Dessa beskrivs i kapitlet Speciella typer av bki:er.
En bki följer med några få undantag samma regler som en vanlig URI när det gäller vilka tecken som är tillåtna och inte. För det generella regelverket se RFC 3986 (ref 3).
referens-bki: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}
En fullständig bki benämns referens-bki. Den är fullständig i meningen att den innehåller alla grundläggande bki-segment. En referens-bki identifierar en viss specifik resurs som till exempel ett specifikt dokument eller ett specifikt kodverk.
Regelverket och användningen av respektive bki-segment beskrivs i separata delkapitel nedan.
Exempel på referens-bki:er:
http://bki.skane.se/sdv-millennium/id/eventcode/21466531
http://bki.skane.se/invanartjanster/fhir/StructureDefinition/InvitationAppointment
bki-värd: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}
Det första bki-segmentet i en bki är bki-värd. Med bki-värd avses huvuddomänen vilket alltid är bki.skane.se.
bki-sektor: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}
Närmast efter bki-värd kommer bki-sektor. Enligt både EU:s ramverk (ref 1) och det nationella ramverket (ref 2) kan sektorn hanteras som en subdomän, det vill säga enligt formatet http://sektor.värd. Detta är dock inte möjligt för en bki i nuvarande ramverksversion.
Bki-sektorn anger inom vilket område bki:n identifierar och ska ha ett namn som speglar områdets innehåll. Bki-sektorerna måste vara unika och ha en ägare som ansvarar för sektorn. För att säkerhetsställa detta förvaltas och tilldelas bki-sektorerna centralt av Enheten för digitalisering.
Den som har blivit tilldelad en bki-sektor bygger upp sitt eget regelverk för hur efterföljande bki-segment ska hanteras. Vi rekommenderar att man följer riktlinjerna i detta dokument men det kan i vissa fall finnas behov av att avvika.
Exempel på bki-sektorer markerade med fetstil:
http://bki.skane.se/rstermlista/id/termpost/11963
http://bki.skane.se/sdv-millennium/id/powerform/196622233
http://bki.skane.se/invanartjanster/fhir/StructureDefinition/CommunicationPatient
bki-typ: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}
Bki-typ anger vilken typ av resurs som identifieras. Bki-ramverket innehåller följande typer:
Bki-typerna fhir och ont har lagts till jämfört med EU:s ramverk och det nationella ramverket. Troligtvis kommer det att tillkomma fler bki-typer framöver. Ett exempel på en typ som lagts tills av en annan organisation är ”bib” som används av Kungliga biblioteket.
Exempel på bki:er med de olika bki-typerna:
…/id/powerform/196570549 identifierar en PowerForm i SDV Millennium
…/doc/RD-beslut/2023-O000001 identifierar ett dokument avseende ett RD-beslut
…/def/dataprodukt/vaardkontakt identifierar definitionen av dataprodukten vårdkontakt
…/set/dataprodukt/vaardkontakt identifierar innehållet i dataprodukten vårdkontakt
…/fhir/StructureDefinition/CommunicationPatient identifierar en FHIR-instans
…/ont/powerform identifierar begreppet PowerForm i en ontologi
Det är möjligt att använda sig av flera bki-typer för en och samma resurs. Till exempel def för att definiera en dataprodukt och set för att identifiera innehållet i den.
En fullständig bki som identifierar en resurs benämns, som tidigare sagts, referens-bki. Om det behöver framgå vilken bki-typ det är så används följande specialiseringar av begreppet:
bki-koncept: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}
Bki-koncept används för att dela in resurserna som identifieras i olika kategorier. Det kan vara en samling av något, vilken slags resurs det är eller namnet på ett konceptschema.
Följande regler gäller för val av koncept:
Vilka bki-koncept som ska användas bestäms per bki-sektor. En faktor som påverkar valet av bki-konceptet är att bki-referenserna måste vara unika inom dessa.
Exempel på bki-koncept för bki-sektorn sdv-millennium markerade med fetstil:
http://bki.skane.se/sdv-millennium/id/powerform/196622233
http://bki.skane.se/sdv-millennium/id/discretetaskassay/2574107763
bki-referens: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}
Bki-referensen är id:t för den specifika resursen och måste vara unik inom respektive bki-sektor och bki-koncept. Det är ägaren av bki-sektorn som ansvarar för detta.
Bki-referensen bör om möjligt återanvända existerande identifierare. Är datakällan en databas kan man med fördel återanvända primärnycklarna i denna. Har man existerande unika namn eller id:n på dokument i en dokumentsamling så bör man återanvända dessa.
Har man ingen existerande källa är det en fördel att använda sig av text som bki-referens. Detta eftersom det är betydligt enklare för en människa att förstå vad som identifieras. Om man har väldigt många instanser inom bki-konceptet är det dock bättre och säkrare med löpnummer eller GUID/UUID.
text /stad/stockholm
löpnummer /stad/1234
GUID/UUID /stad/324abbff-4f1f-4c00-9b05-be80e79aef53
I de fall bki-referenserna är texter så bör dessa vara på svenska men de kan vara på ett annat språk om det bedöms lämpligare.
Exempel på bki-referenser markerade med fetstil:
http://bki.skane.se/rstermlista/id/termpost/11434
http://bki.skane.se/sdv-millennium/id/nomenclature/286054267
http://bki.skane.se/invanartjanster/fhir/StructureDefinition/InvitationAppointment
Ramverket innefattar två olika metoder att hantera versioner. Metoderna bygger på hur det fungerar i FHIR.
Den första metoden använder sig av bki-historiksegment och handlar om att identifiera historiska förekomster, benämnda förekomstversioner. Den andra metoden använder sig av bki-versionsspecificering och handlar om att identifiera verksamhetsmässiga versioner. Det är också möjligt att använda sig av en kombination av de båda metoderna. De två metoderna och kombinationen av dem båda beskrivs i nästkommande delkapitel.
Versioner använder man sig av när man vill identifiera en viss specifik version. Anger man inte version identifierar man alltid den senaste versionen.
Det rekommenderas att metoderna i ramverket följs om det inte finns tekniska eller verksamhetsmässiga krav som talar emot dessa. Finns det speciella krav inom en bki-sektor är det alltså möjligt att specificera en annan hantering. Det är också möjligt att inte hantera versioner alls inom en bki-sektor.
bki-historiksegment: _history/[versionsid]
Bki-historiksegment används för att identifiera förekomstversioner. Med en förekomstversion avses en version av en samling eller en resurs som existerade vid ett visst specifikt tillfälle. Förekomstversioner hanterar förändringar i den faktiska lagrade datan och är mer av teknisk natur. En viss instans av datat kan bara tillhöra en förekomstversion.
Ett bki-historiksegment består av ordet ”_history” följt av ett snedstreck och versionens id. Anledningen till att vi valt att ha ett inledande understrykningstecken i ”_history” är för att följa hur det skrivs i FHIR-standarden. Versionens id är i detta fall vanligen ett automatiskt genererat datum eller löpnummer.
Värt att notera vid användningen av datum är att datumet ska identifiera versionen som sådan (typiskt datumet då versionen skapades). Det är inte ett valfritt datum för vilket man vill ha ut det vid tidpunkten giltiga datat.
Bki-historiksegmentet har olika innebörd beroende på var det placeras i bki:n.
Versionshantering av bki-ramverket
http://{bki-värd}/_history/[versionsid]/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}
http://bki.skane.se/_history/v1/sdv-millennium/id/powerform/2127452
Anger att man vill använda sig av v1 av bki-ramverket för att identifiera den senaste versionen av en PowerForm med id 2127452.
Versionshantering av sektorrymden
http://{bki-värd}/{bki-sektor}/_history/[versionsid]/{bki-typ}/{bki-koncept}/{bki-referens}
http://bki.skane.se/sdv-millennium/_history/20230809/id/powerform/2127452
Anger att man vill använda sig av den historisk versionen av sektorrymden för sektorrymds-bki http://bki.skane.se/sdv-millennium som släpptes 2023-08-09 och identifiera en PowerForm med id 2127452.
Versionshantering av typrymden
http://{bki-värd}/{bki-sektor}/{bki-typ}/_history/[versionsid]/{bki-koncept}/{bki-referens}
http://bki.skane.se/sdv-millennium/id/_history/20230809/powerform/2127452
Anger att man vill använda sig av den historisk versionen av typrymds-bki http://bki.skane.se/sdv-millennium/id som släpptes 2023-08-09 och identifiera en PowerForm med id 2127452. Denna kan vara giltig om koncept-bki:erna har en annan releasecykel än referens-bki:erna.
Versionshantering av konceptrymden
http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/_history/[versionsid]/{bki-referens}
http://bki.skane.se/sdv-millennium/id/powerform/_history/20230809/2127452
Anger att man vill använda sig av den historisk versionen av koncept-bki http://bki.skane.se/sdv-millennium/id/powerform som släpptes 2023-08-09 och identifiera en PowerForm med id 2127452.
Versionshantering av referens-bki
http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}/_history/[versionsid]
http://bki.skane.se/sdv-millennium/id/powerform/2127452/_history/20230809
Anger att man vill använda sig av den historisk versionen av identifierings-bki http://bki.skane.se/sdv-millennium/id/powerform/2127452 som släpptes 2023-08-09.
Identifiera alla versioner av en referens-bki
http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}/_history
Notera att man i detta fall inte anger något versionsid.
http://bki.skane.se/sdv-millennium/id/powerform/2127452/_history
Anger att man vill använda sig av samtliga versioner av identifierings-bki:n för att identifiera samlingen av versioner. Används oftast i samband med ytterligare parametrar i ett API.
bki-versionsspecificering: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}|[versionsid]
Bki-versionsspecificering används för att identifiera verksamhetsmässiga versioner. Med verksamhetsmässiga versioner avses versioner som hanteras på en högre nivå än förekomstversioner som är mer av teknisk natur. Verksamhetsmässig version fokuserar på att versionen är en del av objektet som ses, förstås och används av slutanvändarna. Den verksamhetsmässiga versionen visas samt interageras med inom en verksamhetsmässig kontext. Ett vanligt exempel där det används verksamhetsmässiga versioner är kodverk.
En bki-versionsspecificering består av ett lodstreck följt av versionens id så som verksamheten refererar till det. Bki-versionsspecificeringen kommer alltid sist i URI:n bortsett från eventuella parametrar (se kapitlet Parametrar).
Vid användning av verksamhetsmässig version ska objektet ha ”version” som en egenskap som används för att hantera de olika verksamhetsmässiga versionerna.
Med verksamhetsmässig version kan man ha flera aktiva versioner samtidigt men en viss instans av datat kan bara tillhöra en verksamhetsmässig version.
Exempel på en bki med verksamhetsmässig version:
http://bki.skane.se/invanartjanster/fhir/ImplementationGuide/communication|2.0.1
Anger att man vill använda sig av version 2.0.1 av fhir-bki http://bki.skane.se/invanartjanster/fhir/ImplementationGuide/communication.
Syftet i detta fall är att identifiera en implementationsguide i HL7 FHIR där versionen sätts av författarna och inte av systemet.
http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}/_history/[förekomstversionsid]|[verksamhetsmässigt versionsid]
För att lösa vissa scenarion behöver man kombinera metoderna för verksamhetsmässig version och förekomstversion. Ovan visas hur en referens-bki som använder sig av båda metoderna är uppbyggd.
Ett exempel på ett scenario är ett kodverk som publiceras i verksamhetsmässiga versioner. Flera verksamhetsmässiga versioner existerar samtidigt med olika statusar (utkast, aktiv, inaktiv etc). Inom respektive verksamhetsmässig version behöver man hantera olika förekomstversioner av kodvärdena. Framför allt gäller detta under tiden kodverket har statusen utkast.
Ett annat exempel är ett regelverk som existerar i olika verksamhetsmässiga versioner. För respektive version finns ett separat dokument som beskriver regelverket uppmärkt med versionsid. Dokumenten versionshanteras i olika förekomstversioner.
Flera olika förekomstversioner kan ha samma verksamhetsmässiga version. Samma förekomstversion kan också finnas för flera verksamhetsmässiga versioner. Dock kan en viss instans av datat bara tillhöra en förekomstversion och en verksamhetsmässig version.
Utelämnar man bki-historiksegment från bki:n ska den senaste förekomstversionen returneras. På samma sätt ska den senaste verksamhetsmässiga versionen returneras om man utelämnar bki-versionsspecificering.
I det fiktiva exemplet nedan finns det fyra olika instanser av datat. Varje instans tillhör en förekomstversion och en verksamhetsmässig version, det vill säga förekomstversionerna för respektive verksamhetsmässig version hanteras separat. Instans D är den senaste versionen.
Följande anrop ska returnera följande instanser:
bki-parameter: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}/{bki-referens}?{bki-parameter}&{bki-parameter}
bki-parameter: [namngiven parameter]=[värde]
Det är möjligt att ange parametrar för bki:n med hjälp av bki-parametrar. En bki-parameter följer URI-standarden för frågesträngar. Den anges sist i bki:n efter ett frågetecken och består av en namngiven parameter och ett värde. Det är möjligt att ange flera bki-parametrar. Dessa separeras då med ett &-tecken. Observera att bki-parametern kommer allra sist och alltså efter eventuellt bki-historiksegment och bki-versionsspecificering.
I nuvarande ramverksversion är endast en typ av bki-parameter definierad; bki-formatparametrar. Den beskrivs i nästa delkapitel.
Värt att notera är att det både i EU-ramverket och det nationella ramverket rekommenderas att undvika frågesträngar. Detta eftersom de oftast är beroende av en specifik implementation.
Exempel på bki-parameter markerad med fetstil:
http://bki.skane.se/invanartjanster/fhir/ValueSet/action-type?_format=text/html
bki-formatparameter: _format=[dokumentformat]
Genom att använda sig av en bki-formatparameter kan man ange i vilket format man önskar få tillbaka informationen. Lösningen med en parameter har valts för att kunna hålla själva bki:n ren från formatinformation. Format kommer och går men bki:n ska bestå.
För en bki-formatparameter är den namngivna parametern ”_format”. Anledningen till att vi valt att ha ett inledande understrykningstecken i ”_format” är för att följa hur det skrivs i FHIR-standarden.
Rekommendationen är att använda sig av media types för att ange dokumentformaten. Media types är en standard från IANA för att beskriva format i URI:er (ref 4).
Exempel på vanliga media types:
text/html Hyper Text Markup Language (html)
application/xml Extensible Markup Language (xml)
application/pdf Portable Document Format (pdf)
application/msword Microsoft Word (doc)
Det är möjligt att definiera andra dokumentformat inom en bki-sektor om det av någon anledning inte passar att följa standarden.
I nedanstående exempel anges fyra olika format. Fhir-bki:n identifierar ett urval och med hjälp av bki-formatparametern kan man få information om detta urval i fyra olika format. Informationen som returneras har samma innebörd, bara formaten är olika.
http://bki.skane.se/invanartjanster/fhir/ValueSet/action-type?_format=text/html
http://bki.skane.se/invanartjanster/fhir/ValueSet/action-type?_format=application/fhir+json
http://bki.skane.se/invanartjanster/fhir/ValueSet/action-type?_format=application/xml
http://bki.skane.se/invanartjanster/fhir/ValueSet/action-type?_format=xlsx
Dokumentformatet ”xlsx” är inte en media type utan har definierats inom bki-sektorn invanartjanster.
Med speciella typer av bki:er avser vi bki:er som inte är fullständiga, det vill säga de innehåller inte alla grundläggande bki-segment.
koncept-bki: http://{bki-värd}/{bki-sektor}/ont/{bki-koncept}
Koncept-bki är en speciell typ av bki som används för att identifiera ett visst bki-koncept. En koncept-bki har alltid den reserverade bki-typen ont som står för ontologi. En koncept-bki saknar bki-referens.
Genom att använda en ontologi, det vill säga ett begreppssystem, får man möjlighet att koppla metadata till resurserna. Koncept-bki:n används för att koppla bki-konceptet till motsvarande begrepp i ontologin.
Observera att det inte är nödvändigt att använda sig av koncept-bki:er och en ontologi för att använda bki-ramverket.
Exempel på koncept-bki:er:
http://bki.skane.se/sdv-millennium/ont/interactiveviewsection
http://bki.skane.se/rstermlista/ont/termpost
En annan speciell typ av bki:er är rymd-bki:er. De identifierar en samling av andra bki:er under en viss struktur.
Beroende på vilken typ av rymd-bki det är saknas ett eller flera bki-segment i formatet. De olika undertyperna beskrivs i separata delkapitel nedan.
sektorrymds-bki: http://{bki-värd}/{bki-sektor}
En sektorrymds-bki identifierar en bki-sektor med allt dess innehåll. Den består endast av bki-segmenten bki-värd och bki-sektor.
Exempel på sektorrymds-bki:er:
http://bki.skane.se/sdv-millennium
http://bki.skane.se/rstermlista
typrymds-bki: http://{bki-värd}/{bki-sektor}/{bki-typ}
En typrymds-bki identifierar samlingen av alla referens-bki:er av en viss bki-typ inom en bki-sektor. Den består av bki-segmenten bki-värd, bki-sektor och bki-typ. Bki-typ kan vara vilken typ som helst förutom den reserverade typen ont.
Exempel på typrymds-bki:er:
http://bki.skane.se/sdv-millennium/id
http://bki.skane.se/invanartjanster/fhir
konceptrymds-bki: http://{bki-värd}/{bki-sektor}/{bki-typ}/{bki-koncept}
En konceptrymds-bki identifierar samlingen av alla referens-bki:er som hör till ett visst bki-koncept och har en viss bki-typ inom en bki-sektor. Den består av bki-segmenten bki-värd, bki-sektor och bki-typ. Bki-typ kan vara vilken typ som helst förutom den reserverade typen ont.
Exempel på konceptrymds-bki:er:
http://bki.skane.se/rstermlista/id/termpost
http://bki.skane.se/invanartjanster/fhir/ValueSet
ontologirymds-bki: http://{bki-värd}/{bki-sektor}/ont
En ontologirymds-bki identifierar samlingen av alla koncept-bki:er inom en bki-sektor. Den består av bki-segmenten bki-värd, bki-sektor och bki-typ där bki-typ alltid är den reserverade bki-typen ont som står för ontologi.
Observera att det inte är nödvändigt att använda sig av koncept-bki:er och en ontologi för att använda bki-ramverket.
Exempel på ontologirymds-bki:er:
http://bki.skane.se/sdv-millennium/ont
http://bki.skane.se/rstermlista/ont
FHIR står för Fast Healthcare Interoperability Resources. Det är en standard från HL7 som används för att standardisera hur man utbyter information mellan olika system.
HL7 FHIR kräver beständiga länkar för identifiering av instanser av så kallade canonical resources. Dessa kan flyttas runt och användas i många olika installationer och identifieras därför med en beständig länk. Bki-ramverket hanterar behovet av att identifiera FHIR-instanser på samma sätt som man identifierar andra resurser.
Använder man FHIR:s begreppssystem och det man vill identifiera är FHIR canonical resources så kan man använda sig av bki-typ ”fhir”. Bki-koncepten som används tillsammans med bki-typ “fhir” är namnen på de resurstyper som är definierade av HL7 FHIR till exempel CodeSystem, ValueSet, ActivityDefinition och StructuredDefinition.
Detta är praktiskt vid framtagandet av en implementationsguide. Med bki-typ “fhir” får man en sammanhållen och gemensam struktur på sina beständiga länkar.
Exempel på fhir-bki:er:
http://bki.skane.se/invanartjanster/fhir/StructureDefinition/CommunicationPatient
http://bki.skane.se/invanartjanster/fhir/CodeSystem/csSectionType
Om det handlar om befintliga resurser som mappas till det tekniska formatet FHIR så bör man behålla den ursprungliga URI:n, om en sådan existerar. Detta är speciellt vanligt och viktigt när det handlar om kodverk. Kodverken är ofta välbeskrivna och identifierade sedan tidigare.
Exempel på FHIR-instanser som skulle kunna identifieras utan bki-typ ”fhir”:
Fhir.CodeSystem.URI: http://bki.skane.se/sdv-millennium/id/codevalueset/101694
kodverk definierat i SDV Millennium, den kanoniska identifieraren ändras inte vid mappning till FHIR-formatet
Fhir.Questionnaire.URI: http://bki.skane.se/sdv-millennium/id/powerform/195155611
formuläret är definierat i SDV Millennium, den kanoniska identifieraren ändras inte vid mappning till FHIR-formatet