Följande information beskriver teknisk anslutning för respektive alternativ.

Denna sida beskriver den tekniska lösningen för Utbudstjänsten, med fokus på den logiska arkitekturen. Lösningsbeskrivningen utgör den huvudsakliga tekniska dokumentationen för tjänsten som helhet. Den inkluderar relevant information kring hur de specifikationer som utgör utbudstjänsten har implementerats, t.ex. HSA:s implementation av tjänsteproducent för utbudsinformation, och sträcker sig således utanför den formella omfattningen av Utbudstjänsten. Syftet är att beskriva lösningen på ett sätt som kan förstås av och vara till nytta för alla intressenter.

Utbudstjänsten tillhandahåller information om utbud av vård- och omsorgstjänster. Tjänsten gör det möjligt att söka efter vem som kan utföra en viss typ av vård- och omsorgstjänst, var tjänsten utförs, och vilka kontaktvägar som finns för utföraren.

Utförligare information kring tjänsten finns på Ineras hemsida.

Konceptuell modell

Nedanstående modell beskriver den information som hanteras i tjänsten, på en konceptuell nivå. Den inkluderas här för att ge läsaren den nödvändiga förståelse som krävs för denna lösningsbeskrivning. För utförligare dokumentation, se informationsspecifikationen.

Open

Figur 1, konceptuell modell

Utbud
Sammanfattningen av alla aktiviteter som erbjuds eller kan erbjudas av en organisation för att tillgodose behov av vård och omsorg hos invånare.

Utbudsansvarig organisation
Organisation som är huvudansvarig och innehållsansvarig för utbud.

Vård- och omsorgstjänst
Den tjänst som utförs av en organisatorisk enhet på en specifik plats, för att tillgodose behov av hälso- och sjukvård eller socialtjänst hos invånare. Detta skulle exempelvis kunna vara en viss operation eller undersökning.

Utförande enhet
Den organisatoriska enhet som utför en vård- och omsorgstjänst.

Verksamhetsbehov och scenarios för användning

Informationen om tjänsteutbud vänder sig till både invånare och professionen. Vilka typer av vård- och omsorgstjänster som finns har beskrivits med ett kodverk. Detta kodverk utgör en del av utbudstjänsten och har anpassats till att fungera för båda grupperna av användare.

Här är några exempel på hur utbudstjänsten kan användas:

• En invånare söker efter en vårdenhet som erbjuder en viss tjänst på 1177.se

• En invånare tittar på en enhets information på 1177.se, och kan då se vilka vårdtjänster som enheten erbjuder.

• En remittent använder ett system med stöd för elektronisk remiss och integration till utbudstjänsen. Remittenten kan hitta enheter som erbjuder önskad tjänst. När enhet har valts kan systemet ta reda på om enheten stödjer e-remiss, för att avgöra om remissen ska skickas elektroniskt.

• En remittent använder ett fristående webbgränssnitt för att söka i utbudstjänsten. Remittenten kan hitta postadress till enhet för att skicka en pappersremiss.

Arbetsflöden återfinns i tjänstekontraktsbeskrivningen och informationsspecifikationen.

Tjänstedomänen

Utbudstjänsten är implementerad i tjänstedomänen supportprocess.serviceprovisioning.healthcareoffering. I domänen finns följande tjänstekontrakt:

• GetCareServiceOfferings - hämtar de vård- och omsorgstjänster som ingår i det utbud som erbjuds av en utbudsansvarig organisation. Informationen kan filtreras på ett antal parametrar.

• GetOfferingCatalogues - hämtar information om utbudskataloger (=tjänsteproducenter), vilken adress de tillhandahålls på och vilka utbudsansvariga organisationer som tillhandahåller utbud i respektive katalog.

Dynamisk upptäckt av utbudsproducenter

Utbudstjänsten är designad för att det ska vara enkelt att tillgängliggöra nya utbud. En konsument kan hitta alla tillgängliga utbudskataloger, och vilka utbudsansvariga organisationer som hittas i respektive katalog, via GetOfferingCatalogues, och söker sedan i deras utbud via GetCareServiceOfferings. Figur 2 illustrerar lösningen.

Open

Figur 2, dynamisk upptäckt av utbudsproducenter.

Domänen är systemadresserad, och tillåter att en viss utbudsansvarig organisation har utbud tillgängligt i mer än en utbudskatalog. Konsumenter ansluts till GetCareServiceOfferings med anropsbehörighet på tjänstenivå, och ej på producentnivå. På så sätt får man automatiskt behörighet om en ny organisation ansluts via en ny tjänsteproducent.

Testrutiner vid anslutningar mot tjänsteplattformen innebär normalt end-to-end-tester med alla parter som deltar i ett informationsutbyte. Ofta krävs även tekniska förändringar hos konsumenten för att t.ex. anropa en ny logisk adress. Utbudstjänstens tekniska lösning möjliggör ett enklare införande av nya utbud. Information kan tillgängliggöras utan några tekniska förändringar, och endast om parterna så kräver behöver end-to-end-tester genomföras.

En konsument som inte vill nyttja möjligheten till dynamisk upptäckt av utbudsproducenter kan förstås fortsatt implementera en sådan lösning, där inte GetOfferingCatalogues nyttjas.

Utbudstjänstens implementation, logisk modell

Följande bild visar en logisk modell av utbudstjänstens implementation.

Figur 3, Utbudstjänstens implementation, logisk modell.

Modellen visar:

• Utbudstjänstens tjänstekontrakt finns tillgängliga på den nationella tjänsteplattformen, NTjP.

• För GetOfferingCatalogues finns en nationell tjänsteproducent.

• GetCareServiceOfferings kan ha flera tjänsteproducenter. Flera utbudsansvariga organisationer kan exponera sitt utbud i en tjänsteproducent. Den tekniska lösningen tillåter också att en utbudsansvarig organisation har sitt utbud uppdelat på flera tjänsteproducenter.

Figur 4 visualiserar de delar av den tekniska lösningen som hanteras av Utbudstjänstens förvaltning.

Figur 4, Komponenter som hanteras av Utbudstjänstens förvaltning

Dessa omfattar:

• De i tjänstedomänen supportprocess.serviceprovisioning.healthcareoffering ingående tjänstekontrakten.

• Den nationella tjänsteproducenten för GetOfferingCatalogues, inklusive administrationen av den information som tillhandahålls via denna.

Utbudsinformation i HSA

För att erbjuda ett enkelt sätt för organisationer som använder HSA att tillhandahålla sitt utbud via utbudstjänsten har stöd för hantering av utbudsinformation implementerats i denna plattform. Tjänstekontraktet GetCareServiceOfferings har implementerats i nationella HSA. Utbudsinformation kan hanteras enligt tre modeller:

Modell A: Aktör som enbart använder nationella HSA administrerar även utbudsinformation direkt i nationella HSA. För detta används verktyget HSA admin som tillhandahålls av HSA:s förvaltning.

Modell B: Aktör som har en lokal HSA-katalog och synkar information till nationella HSA hanterar utbudsinformation enligt samma modell. Aktören ansvarar själv för administrationsverktyg.

Modell C: Aktör som har en lokal HSA-katalog men inte önskar implementera stöd för utbudsinformation i denna kan välja att administrera utbudsinformation i nationella HSA. Detta ger en mer komplex administration där olika verktyg behöver användas. Modell B rekommenderas som förstahandsval för aktörer med lokal katalog.

Figur 5 illustrerar dessa modeller.

Figur 5, Administrativa modeller för utbudsinformation i HSA.

Det finns som framgår ovan inget behov för de som administrerar utbud i en regional HSA-katalog att själva implementera GetCareServiceOfferings.

Administrationsverktyg CDA

CDA, levererat av Cybercom, är det vanligast förekommande administrationsverktyget för regionala HSA-kataloger. I samband med genomförande av pilotprojekt för utbudstjänsten har stöd för administration av utbud implementerats i CDA. Varje region som använder CDA har ett separat avtal med leverantören och måste själva se till att de får åtkomst till funktionaliteten för utbudsadministration, men denna tillhandahålls i normalfallet utan någon extra kostnad. Regionala anpassningar av CDA kan påverka lösningen.

Registrering och tillgängliggörande av vårdtjänster

HSA erbjuder en möjlighet att dölja objekt så att de inte blir synliga för andra än behöriga aktörer. Denna funktion kan vara lämplig att använda vid registrering av vårdtjänster om man t.ex. önskar registrera en regions samtliga vårdtjänster utan att varje vårdtjänst direkt blir synlig i utbudstjänsten. (En vårdtjänst kan även tilldelas status INACTIVE för att informera en konsument om att den inte är redo att erbjudas, se livscykelmodell nedan)

Livscykelmodell

Vårdtjänster kan ha följande status:

• INACTIVE: innan vårdtjänsten är färdig att erbjudas

• ACTIVE: vårdtjänsten är färdigbeskriven och kan erbjudas

• DEPRECATED: vårdtjänsten ska inte längre erbjudas

Det är även tillåtet för en producent att radera vårdtjänster.

Förutom statusen har en vårdtjänst också en giltighetsperiod. I normalfallet ska en vårdtjänst enbart användas om aktuellt datum ligger inom giltighetsperiodens avgränsningar, och status = ACTIVE.

Hantering av tredjepartsenheter

En utbudsansvarig organisation kan ha avtal med enheter utanför den egna organisationen. Det kan handla om en region som har avtal med en privat utförare för att utföra tjänster för regionens räkning, eller att en region har avtal med en utförare inom en annan region. Dessa enheter benämner vi här för tredjepartsenheter. Tredjepartsenheter är av speciellt intresse för utbudstjänsten då denna är avsedd att kunna användas i sammanhang där enhetens identitet används för att i Ineras tjänsteadresseringskatalog (TAK) hitta information om enheten stödjer ett visst tjänstekontrakt, för att i följande steg nyttja detta tjänstekontrakt (t.ex. vid utfärdande av e-remiss).

Det har förekommit att utbudsansvariga organisationer har lagt upp egna definitioner av tredjepartsenheter, där enheterna har fått en ny identitet. Detta har i flera fall förekommit i HSA, där regioner administrerar information i lokala kataloger utan tillgång till andra organisationers information.

Vid förekomst av tredjepartsenheter i Utbudstjänsten gäller följande:

1. Lokala definitioner (med id som avviker från originaldefinitionen) bör undvikas. De medför att en konsument inte kan identifiera när samma enhet förekommer i olika organisationers utbud.

2. Om en lokal definition med id som avviker från originaldefinitionen förekommer så ska den vara registrerad som logisk adressat på detta id för de tjänstekontrakt som enheten erbjuder och som kan bli aktuella att nyttja i ett arbetsflöde där den enhets-identitet som erhållits via utbudstjänsten nyttjas. Notera att detta innebär en avvikelse från riktlinjer inom samverksansarkitekturen, och endast bör nyttjas i de fall då denna konfiguration redan är etablerad.

Tredjepartsenheter i HSA

Hanteringen av tredjepartsenheter i HSA påverkas av ett flertal faktorer.

• Användningen av lokala kataloger som synkas till nationella HSA. I de lokala katalogerna har organisationer enbart tillgång till sitt HSA-träd, och kan inte se andra organisationers information.

• Vårdtjänster registreras under enheter. Detta innebär att en vårdtjänst som en enhet som tillhör den privata vårdgivaren A utför på uppdrag av region B registreras hos vårdgivare A.

• En vårdtjänst måste knytas till ett avtal för att den ska bli tillgänglig i Utbudstjänsten. Avtalen definieras av utbudsansvarig organisation.

För att undvika behovet av att skapa lokala definitioner av tredjepartsenheter, som i HSA per definition tilldelas ett nytt id, kan något av följande tillvägagångssätt väljas:

A: Administration i lokal katalog. För vårdtjänster som inte finns i den lokala katalogen anges id manuellt när dessa kopplas till avtal. När informationen synkas till nationella HSA bör validering av att id:t är korrekt ske.

B: Administrera avtal i nationella HSA. HSA-ansvarig har tillgång till nationella HSA, och verktyget HSA Admin. I nationella HSA har man tillgång till andra organisationers enheter och kan knyta vårdtjänster definierade under dessa enheter till sina avtal. Det är tekniskt möjligt att skapa separata avtal för vårdtjänster hos tredjepartsenheter och administrera enbart dessa i nationella HSA, medan avtal för egna vårdtjänster administreras lokalt.

C. Administrera all utbudsinformation i nationella HSA. Detta alternativ kan väljas för att hålla ihop hela hanteringen i en miljö.