Note: Denna funktion är under utveckling, följ utvecklingen i JIRA-74 och JIRA-9!

Innehåll

Inledning

Denna SAD beskriver en implementation av ett engagemangsindex enligt krav och tjänstekontrakt som beskrivs i nationella tjänstekontraktsbeskrivningen för Engagemangsindex.

Engagemangsindex är en stödtjänst som beskrivs i den nationella tekniska arkitekturen (T-boken, REV B). Stödtjänsten är en plattformsfunktion för nationell och regional infrastruktur. Stödtjänsten möjliggöra för andra tjänster att hitta information om patienten över vårdgivar- och landstingsgränser. Informationsinnehållet i engagemangsindex styrs i detalj av varje tillämpningsområde (”tjänstedomän”), så som patientens tidbokning, e-remiss, patentöversikt och formulärhantering.

Engagemangsindex är en form av patientindex som möjliggör för nationella invånar- och vårdgivartjänster att hitta den information om patienten som är relevant för e-tjänstens funktion. Engagemangsindex innehåller ingen originalinformation. Index-informationen är en spegling av vissa attribut från källsystemen.

Den index-information som finns i Engagemangsindex lagras i syfte att vara till stöd för andra tjänster med behov av att integrera information från flera källor och huvudmän. Ansvaret för vilken information som når medarbetare, patienter och tredje-part ligger därför hos de tjänster som använder engagemangsindex. Engagemangsindex erbjuder ingen direktåtkomst för slutanvändaren.

Den nationella tjänsteplattformen hittar till informationen med hjälp av en kod som identifierar informationsägaren (t.ex. HSA-id för en vårdenhet). Men för att en e-tjänst ska kunna använda tjänsteplattformen för att hämta alla informationsmängder om t.ex. patientens tidbokning behöver e-tjänsten få hjälp med information om hos vilka vårdenheter/mottagningar det finns tidbokningar. Engagemangsindex är den stödtjänst som kan redovisa var (hos vilka verksamheter) patienten har bokade tider.

T-boken innehåller ett antal vägledande exempel som beskriver systemsamverkan för engagemangsindex, t ex följande för "E-tjänst för invånare":

Implementationsnära delar av detta designdokument är baserade på att Mule ESB CE (v3.3.1 eller senare) samt Apache ActiveMQ används samt att tjänsten driftsätts antingen i den nationella tjänsteplattformen (NTjP) eller i en regional tjänsteplattform (RTjP).

Dokumentets delar

Dokumentet är indelat i följande delar:

Exempel
Belysande exempel på tillämpning av Engagemangsindex
Arkitekturella krav
Beskriver de arkitekturella egenskaper som är gemensamma för aggregerande tjänster.
Följsamhet mot T-bokens styrande principer
Beskriver hur implementationen av engagemangsindex följer T-bokens styrande principer
Systemsamverkan
Ger en översiktlig bild av vilka system som samverkar samt dess primära roller i denna samverkan
Användningsfall
Beskriver de användningsfall som har störst påverkan på designen.
Logisk vy
Beskriver designens logiska uppdelning.
Deploymentvy
Beskriver hur lösningen skall driftsättas i QA och produktionsmiljöer.
Testvy
Beskriver integrationstester som behövs för att säkerställa den totala lösningens funktionalitet.
Implementationsvy
Beskriver centrala delar av implementationen.

Arkitekturella krav

Arkitekturella krav på ett engagemangsindex finns på övergripande nivå i den nationella tekniska arkitekturen (T-boken, REV B) samt på tjänstekontraktsnivå i den nationella tjänstekontraktsbeskrivningen för Engagemangsindex.

Övergripande arkitekturella mål

Engagemangsindex syfte i den nationella arkitekturen beskrivs i T-boken, REV B. Syftet med denna implementation är att stödja samtliga icke-funktionella krav som beskrivs i tjänstekontraktsbeskrivningen och vara tillämpbar i alla de scenario och vägledande exempel för Enagemangsindex som beskrivs i T-boken.

Implementationen ska också stödja användning inom ramen för avgränsingar och anvisningar:

För E-tjänster med verksamhetsintegration finns tjänstekontrakt som specificerar kraven på meddelandeutbyte mellan e-tjänsten och verksamhetssystemen. Oftast ställer dessa tjänstekontrakt även krav på uppdatering av engagemangsindex. Det beskrivs i så fall i respektive tjänstedomäns tjänstekontraktsbeskrivning. Några exempel är tidbokning och remisstatusföljaren. För att vara producent av t.ex. tjänstekontrakten för tidbokning måste vårdsystemen alltså uppdatera engagemangsindex enligt de instruktioner som finns i tjänstekontraktsbeskrivningen för tidbokningsdomänen.
Det är endast genom att källsystemen synkroniserar index-information till Engagemangsindex som invånartjänster i Mina vårdkontakter kan fungera fullt ut. Det är inte bara Mina vårdkontakter som är beroende av informationen i engagemangsindex för sin funktion. Har man väl integrerat källsystemet med engagemangsindex kommer patienterna automatiskt att få tillgång till en mängd tjänster. Det gäller även vårdpersonal som använder olika ombudsfunktioner för t.ex. tidbokning.
E-tjänster som behöver konsumera information i engagemangsindex ska i första hand göra detta indirekt via en s.k. aggregerande tjänst. Det krävs särskilt godkännande för att integrera direkt med engagemangsindex. Ett exempel på en aggregerande tjänst är ”Mina bokade tider”. Det är en RIV TA-tjänst på Tjänsteplattformen som internt använder Engagemangsindex för att sammanställa alla bokade tider patienten har tvärs alla anslutna system i Sverige. Genom att den aggregerande tjänsten finns, blir kopplingen mot engagemangsindex återanvändbar. Utan aggregerande tjänst behöver varje tillämpning investera i integration med Engagemangsindex (som konsument), ev. cache-funktioner etc.

Utveckling av aggregerande tjänster innebär att utveckla en nationell SOA-tjänst som ska nås via nationella tjänsteplattformen. Arkitektur för aggregerande tjänster ingår inte i denna SAD.

Icke funktionella krav

Ett engagemangsindex ska klara mycket höga volymer av uppdateringar med låg svarstid för de uppdaterande källsystemen. Vid nationell utrullning och när alla källsystem i Sverige är integrerade enligt ett antal tjänstedomäner, handlar det om flera miljoner uppdateringar per dygn. Datavolymerna ökar över tiden, men indexposterna speglar i många fall att det finns en förekomst av en informationsmängd för en patient hos en vårdenhet (exempel: samtliga tjänstedomäner inom journaldokumentation) samt vad som är senaste datum. Det gör att volymen på sikt inte ökar med antalet vårdbesök, utan främst av att patienter under sitt livsförlopp löpande ökar antalet vårdenheter man varit i kontakt med. En överslagskalkyl ger en uppskattning på ca 250 miljoner poster för Sveriges befolkning. Implementationen behöver därför på sikt möjliggöra effektiv uppdatering och sökning i ett register med 250 miljoner poster. Med effektiv avses här att uppfylla de svarstider för uppdateringar och sökningar i indexet som kravställs i tjänstekontraktsbeskrivningen.

Det är också stora krav på tillgänglighet eftersom e-tjänsters funktion förlitar sig på att information om händelser i källsystemen når indexet inom en rimlig tidsperiod. Källsystemens uppdateringsfunktion för engagemangsindex är också beroende av att engagemangsindex alltid är tillgängligt så att inte uppdateringar skapar driftsstörningar för verksamheterna som använder källsystemen.

Följsamhet mot T-bokens styrande principer

IT2: Informationssäkerhet

*Förutsättningar att uppfylla*	*Uppfyllnad*
Verksamhetskritiskt IT-stöd designas för att möta verksamhetens krav på tillgänglighet vid frånfall av ett externt beroende. Ju fler beroenden till andra komponenters tillgänglighet, desto lägre egen tillgänglighet.	Systemet har beroenden till tjänsteplattformens tjänsteadresseringskatalog (dess tjänsteproducent enligt tjänstedomän för tjänsteadressering). För att minska riskerna cachar implementationen data från uppslagen mot tjänsteadresseringskatalogen. Systemet har uppdateringsberoenden till de system som prenumererar på indexhändelser (producenter av ProcessNotification). Tjänstekontraktsbeskrivningen föreskriver robusthetskrav för EI som denna implementation tillgodoser genom asynkron hantering av notifiering med omsändningsalgoritmer.
Verksamhetskritiska nationella stödtjänster (t.ex. tillgång till behörighetsstyrande information) erbjuder möjlighet till lokala instanser som med tillräcklig aktualitet hålls uppdaterade med nationell master.	Detta index uppfyller kraven för att kunna tillämpas regionalt. Det är öppen källkod och öppet tillgängligt för regional tillämpning. Arkitekturen för EI (enligt tjänstekontraktsbeskrivningen) stödjer federering genom notifieringsfunktionen så att nationellt index kan uppdateras via regionala index.
Krav mellan integrerande parter regleras genom integrationsavtal. Integrationsavtal är det avtal där informationsägaren godkänner att en ett visst system får agera mot information genom ett visst tjänstekontrakt. Exempelvis skall enligt integrationsprocessen för den nationella tjänsteplattformen ett avtalsnummer för ett integrationsavtal registreras i samband med att man "öppnar dörren" för en viss tjänstekonsument mot en viss kombination av informationsägare och tjänstekontrakt.	Den organisation som erbjuder ett engagemangsindex behöver ha personuppgiftsbiträdesavtal upprättade enligt CeHis modellavtal 2, med berörda vårdgivare.
Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid flera samverkande system.	Redundant infrastruktur är nödvändig för en driftsinstans av EI eftersom många e-tjänster beror av EI. Detta behöver säkerställas genom en väl avvägd infrastrukturdesign för aktuell driftspunkt.
En sammantagen tolkning av tillämpliga lagar och förordningars konsekvenser för teknisk realisering av informationsfångst, utbyte och lagring.	Cehis och SLL:s patientdatajurister har genomlyst Engagemangsindex ur juridiska perspektiv. Tjänsten påverkas av PUL då data lagras, men inte av PDL då ingen direktåtkomst erbjuds (stödtjänster saknar användargränssnitt). Den organisation som erbjuder ett engagemangsindex behöver ha personuppgiftsbiträdesavtal upprättade enligt CeHis modellavtal 2, med berörda vårdgivare.
Förutsättningar för spårbarhet etableras i form av loggningsregler för komponenter som deltar i säkert informationsutbyte.	Tjänstekonsument och tjänsteproducent ansvarar för att följa de krav som finns på spårbarhet och loggning. Stödtjänsten i sig är inte en aktiv part i att delge medarbetare eller patienter information.
Interoperabla, internationellt beprövade och för leverantörer tillgängliga standarder tillämpas för kommunikation mellan parter som har upprättat tillit.	Allt informationsutbyte sker enligt nationella tjänstekontrakt för engagemangsindex.

IT3: Nationell funktionell skalbarhet

*Förutsättningar att uppfylla*	*Uppfyllnad*
Nationella tjänstekontrakt definieras med nationell täckning som funktionell omfattning. Det är möjligt för ett centraliserat verksamhetssystem som användas av alla verksamheter i Sverige att realisera varje standardiserat tjänstekontrakt. Det får inte finnas underförstådda funktionella avgränsningar till regioner, kommuner, landsting eller andra organisatoriska avgränsningar i nationella tjänstekontrakt.	Enligt tjänstekontraktens specifikation kan ett index vara nationellt eller regionalt. Samma lösning (denna implementation) stödjer båda rollerna. En indexinstans kan inte ha rollen som två regionala index. Det är i någon mening ett avsteg, men det ligger inte i lösningen utan i det nationella tjänstekontraktets struktur.
SLA ska definieras för varje tjänstekontrakt. Detta SLA ska ta hänsyn till framtida kapacitet för tjänstekontraktet med avseende på transaktionsvolym, variationer i användningsmönster och krav på tillgänglighet, i kombination med förmåga till kontinuerlig förändring.	Detta projekt har inte ansvarat för att specificera tjänstekontrakten. Tjänstekontrakten är kravdokument för detta projekts implementation av ett engagemangsindex.
Integration ska ske över en integrationsinfrastruktur (t.ex. virtualiseringsplattform) som möjliggör uppföljning av tjänsteproducenters fullföljande av SLA.	Nationell Tjänsteplattform eller regionala tjänsteplattformar förutsätts användas för indexets kommunikation med omvärlden.
System och e-tjänster som upphandlas kan utökas med fler organisationer som kunder utan krav på infrastrukturella ingrepp (jämför s.k. SaaS)	Nej, det är inte möjligt. Enligt tjänstekontraktens specifikation kan ett index vara nationellt eller regionalt. Samma lösning (denna implementation) stödjer båda rollerna. En indexinstans kan inte ha rollen som två regionala index. Det är i någon mening ett avsteg, men det ligger inte i lösningen utan i det nationella tjänstekontraktets struktur.

IT4: Lös koppling

*Förutsättningar att uppfylla*	*Uppfyllnad*
Meddelandeutbyte baseras på att kommunikation etableras utgående från vem som äger informationen som ska konsumeras eller berikas, inte vilket system, plattform, datalager eller tekniskt gränssnitt som informationsägaren för stunden använder för att hantera informationen. Genom centralt administrerad förmedlingstjänst skapas lös koppling mellan informationskonsument och informationsägarens tekniska lösning.	Meddelandeutbyte är baserade på tjänstekontrakt. Tjänstekontrakten följer T-boken och RIV-TA2.1 Den logiska adresseringen till EI sker med hjälp av journalsystemens hsa-id, adresseringen ifrån EI (ProcessNotification) sker med hjälp av en fråga till tjänsteadresseringskatalogen för att få alla producenters system-hsa-id som då används till den logiska adressen.
En arkitektur som skapar lös koppling mellan konsumenter och producenter, avseende adressering och standarder för kommunikation.	T-boken och RIV-TA 2.1 tillämpas genom att all kommunikation sker via nationella fastställda tjänstekontrakt.
En nationell integrationspunkt ska kunna erbjudas för varje nationellt standardiserat tjänstekontrakt, som en fasad mot bakomliggande brokiga systemlandskap.	Projektet förutsätter att all kommunikation med EI (in och utgående) sker via virtuella tjänster i en tjänsteplattform.
Nationella tjänstekontrakt förvaltas i en nationellt koordinerad förvaltning.	Detta projekt har inte ansvarat för att specificera tjänstekontrakten. Tjänstekontrakten är kravdokument för detta projekts implementation av ett engagemangsindex.
För en process inom vård och omsorg kan flera tjänstekontrakt ingå. Därför är det viktigt att alla tjänstekontrakt baseras på en gemensam referensmodell för informationsstruktur.	Detta projekt har inte ansvarat för att specificera tjänstekontrakten. Tjänstekontrakten är kravdokument för detta projekts implementation av ett engagemangsindex.
Parter som samverkar i enlighet med arkitekturen integrerar med system hos parter som lyder under annan styrning (t.ex. myndigheter, kunder och leverantörer). Det kan leda till att vård- och omsorgsgivare antingen: Nationellt bryggar informationen (semantisk översättning) eller Nationellt införlivar externt förvaltat tjänstekontrakt som standard. Observera att semantisk bryggning av information till vårdens referensmodell förutsätter en nationell förvaltning av bryggningstjänster. För att införliva ett externt förvaltat tjänstekontrakt förutsätts en transparent, robust och uthållig tjänstekontraktsförvaltning hos den externa parten.	Projektet har inget uppdrag att etablera elektronisk samverkan med externa parter.
Befintliga system behöver anpassas till nationella tjänstekontrakt. Detta kan göras av leverantörer direkt i produkten, eller genom fristående integrationskomponenter (”anslutningar”). En anslutning bör ligga nära (logiskt vara en del av) det system som ansluts, oavsett om det är i rollen som konsument eller producent för anslutningen som genomförs.	Projektets utgångspunkt är att källsystem-leverantörer och e-tjänster som prenumererar på index-notifieringar anpassas till de aktuella tjänstekontrakten. Det finns inga komponenter för system-specifika anpassningar i lösningen.
Interoperabla standarder för meddelandeutbyte tillämpas, så att integration med till exempel en Web Service kan utföras utan att anropande system behöver tillföras en för tjänsteproducenten specialskriven integrationsmodul (s.k. agent).	Tjänstekontrakten som tillämpas är utformade enligt RIV-TA 2.1.

IT5: Lokalt driven e-tjänsteförsörjning

*Förutsättningar att uppfylla*	*Uppfyllnad*
När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas: Alla leveranser tillgängliggörs under öppen källkodslicens. Valet av licensformer samordnas nationellt genom rekommendationer. Utvecklingen bedrivs från start i en allmänt tillgänglig (över öppna nätverk) projektinfrastruktur där förvaltningsorganisation kan förändras över tiden inom ramen för en kontinuerligt tillgänglig projektinfrastruktur (analogi: ”Projektplatsen för e-tjänsteutveckling”). Det innebär full insyn och åtkomst för utvecklare till källkod, versionshantering, ärendehantering, stödforum och andra element i en projektinfrastruktur under projektets och förvaltningens hela livscykel. Upphandlade e-tjänster fungerar på de vanligaste plattformarna hos vårdgivarna och hos nationella driftspartners (Windows, Linux, Unix) t.ex. genom att vara byggda för att exekvera på en s.k. Java virtuell maskin. Gemensam referensmodell för e-tjänsters interna uppbyggnad stimulerar och förenklar återanvändning och överföring av förvaltningsansvar mellan organisationer.	Denna lösning är öppen källkod och publicerad på Google Code enligt RIVTA-riktlinjer för detta. Utvecklingen har bedrivits på Google Code från start, med möjlighet till full insyn. Även test-automationsmiljöer är publika och resultatet av byggen redovisas publikt. Se http://build.callistasoftware.org:8080/jenkins/job/engagemangsindex/lastCompletedBuild/testReport/ Lösningen är utvecklad för att kunna driftsättas i vilken Java EE 6-plattform som helst, som stödjer Java EE 6 Full Profile (web-services och JMS används). Den är därmed portabel över olika operativsystem och även över olika Java EE 6-implementationer.
Minsta möjliga – men tillräcklig – mängd standarder och stödjande gemensamma grundbultar för nationella e-tjänstekanaler säkerställer att även utvecklingsenheter i mindre organisationer kan bidra med e-tjänster för en integrerad användarupplevelse och att en gemensam back-office för anslutning av huvudmän till e-tjänster finns etablerad. I den mån etablerade standarder med bred tillämpning i kommersiella e-tjänster finns (t.ex. för single-sign-on), bör de användas i syfte att möjliggöra upphandling av hyllprodukter.	Engagemangsindex är inte en e-tjänst.
Utveckling sker mot globalt dominerande portabilitetsstandarder i de fall mellanvara (applikationsservrar) tillämpas. Det är möjliggöraren för nyttjande av free-ware och lågkostnadsverktyg i organisationer som inte orkar bära tunga licenskostnader för komplexa utvecklingsverktyg och driftsplattformar.	EI är skriven med Java EE 6 som grund och kräver en certifierad Java EE 6 applikationsserver (Full Profile), alla ingående ramverk som används är öppen källkod och leveransen av EI själv är även den släppt som öppen källkod. I projektet så har JBoss 7, Mysql 5.5 samt IDE’n Netbeans använts men med målet att var och en av komponenterna är utbytbara för möjliggöra lokala anpassningar.
Nationell (eller regional – beroende på sammanhang vård/omsorg) förvaltning är etablerad (t.ex. s.k. Portal Governance), med effektiva processer för att införliva lokalt utvecklade e-tjänster i nationella e-tjänstekanaler. Systematisk och effektiv allokering av resurser för drift är en viktig grundförutsättning.	Engagemangsindex är inte en e-tjänst.
Genom lokal governance och tillämpning av det nationella regelverket får lokala projekt den stöttning som behövs för att från början bygga in förutsättningar för integration i samordnade (t.ex. nationella) e-tjänstekanaler.	Engagemangsindex är inte en e-tjänst.

IT6: Samverkan i federation

*Förutsättningar att uppfylla*	*Uppfyllnad*
Att gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör kostnadseffektiva och leverantörsneutrala lösningar.	RIV-TA tillämpas
Det behövs organ och processer för att godkänna utgivare av elektroniska identitetsintyg och certifikat som är giltiga i federationen.	SITHS HCC certifikat används i enlighet med T-boken och RIV-TA2.1. Nationell eller regional SITHS förvaltning ansvarar för utgivning av certifikat. Engagemangsindex-komponenten kräver inte PKI för kommunikation, utan kan vid behov förlita sig på att en tjänsteplattform agerar SSL-part i informationsutbytet med källsystem och e-tjänster.
Aktörer i olika nät, inklusive öppna nät ska vara välkomna i elektronisk samverkan genom att samverkande komponenter är säkra.	Kommunikation sker via nationellt tjänsteplattform. Via den nationella tjänsteplattformen kan EI nås från internet och Sjunet.
Att Ingående parter i federationen är överens om ett antal gemensamma ståndpunkter: att stark autentisering likställs med 2-faktors autentisering att vid samverkan acceptera följande metoder för stark autentisering; eID, PKI med lagring av nyckelpar på SmartCard eller motsvarande och metoder baserade på engångslösenord, antingen genererade i en fysisk enhet eller säkert distribuerad till fysisk enhet att tillämpa en gemensam certifikat- och utfärdarpolicy, likvärdig med SITHS, som ett minimikrav för egen eller annans PKI att sträva mot en autentiseringslösning, framför flera olika, för att realisera stark autentisering i den egna organisationen och i federation att enbart acceptera SAMLv2, eller senare version, vid identitetsfederering samt tydliggöra att det i förekommande fall är det enda sättet att logga in och säkerställa det inte finns någon bakväg in att tillämpa ett gemensamt ramverk för att ingå i en federation att tillämpa en gemensam katalogpolicy, med utgångspunkt från HSA policy, som ett minimikrav för egna kataloger att stäva mot att all gränsöverskridande kommunikation skall vara möjlig både över Sjunet och Internet. Det är den egna organisationen som beslutar vilken tillgänglighet som är tillräcklig för anslutningen att sträva efter att möjliggöra kontroll av trafik till och från den egna infrastrukturen i en eller få kontrollpunkter att utgå från att kommunikation över Internet och Sjunet har ett likvärdigt skyddsbehov	Engagemangsindex erbjuder inte ett användargränssnitt och har därför heller inget behov av att identifiera användare i en SSO-federation.

Systemsamverkan

Följande figur ger en schematisk översikt av systemsamverkan för tjänsten:

De samverkande systemen beskrivs mer formellt av följande komponentmodell samt tillhörande text:

Not: I komponentmodellen nedan är SKLTP's Virtualiseringplattform bortabstraherad i syfte att öka bildens läsbarhet men den används i samtliga externa samband, dvs i anrop mellan engagemangsindex och källsystem, konsumenter samt andra federerade engagemangsindex.

TBS: ERSÄTT AGGREGERINGSPLATTFORMENS TEXT

Tjänstekonsument
Frågar den aggregerande tjänsten efter tidbokningar för ett specifik patientid via tjänstekontraktet GetAggregatedSubjectOfCareSchedule.
Engagemangsindex
Förser via en prenumerationstjänst (tjänstekontrakt ProcessNotification) den aggregerande tjänsten med information om vilka vårdmottagningar som har tidbokningar för vilka patienter.
Tillhandahåller oxå en frågetjänst (tjänstekontrakt FindContent) som gör det möjligt för den aggregerande tjänsten att läsa upp index-information om en viss patients samtliga bokningar.
Tjänsteproducent (för källsystem)
Tillhandahåller en tjänst, GetSubjectOfCareSchedule, för åtkomst av tidbokningar i det specifika källsystemet.
NTjP - Virtualiseringsplattformen (VP)
Alla informationsutbyten mellan tjänstekonsumenter och tjänsteproducenter sker via virtuella tjänster i den nationella tjänsteplattformen.
NTjP - Aggregerande tjänst för Tidbokning
Tillhandahåller aggregerande tjänst för Tidbokning till konsumenter via tjänstekontraktet GetAggregatedSubjectOfCareSchedule.

Utgående från informationen tjänsten får från det nationella engagemangsindexet så kan tjänsten avgöra vilka vårdmottagningar som har tidbokningar för en patient.

Med hjälp av NTjP - Virtualiseringstjänst för Tidbokning kan den aggregerande tjänsten hämta patientens bokade tider och kallelser hos var och en av de vårdmottagningar som listats av engagemangsindex. Dessa kan sedan sättas samman till ett samlat svar från den aggregerande tjänsten. Svaret cachas internt i den aggregerande tjänsten under en begränsad tid (30 dagar) för att avlasta källsystemen om tidbokningar för samma patient efterfrågas inom denna tidsperiod. Patientinformation som finns i cachen hålls uppdaterad med hjälp av uppdateringar från prenumerationen i engagemangsindexet.

Användningsfall

Tjänsten uppfyller följande användningsfall för att möta de arkitekturella kraven:

Källsystem uppdaterar engagemangsindex
Engagemangsindex hämtar uppdateringar från ett källsystem
(som alternativ till att källsystemet initierar uppdateringar)
Federerat engagemangsindex uppdaterar engagemangsindex
Engagemangsindex bearbetar inkomna uppdateringar och notifieringar
Prenumerant tar emot förändringar från ett engagemangsindex
Tjänstekonsument begär information från ett engagemangsindex