Arkitekturella krav

Arkitekturella krav på ett engagemangsindex finns på övergripande nivå i den nationella tekniska arkitekturen (T-boken, REV B) i form av styrande principer 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änsningar 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

Detta stycke kompletterar de icke funktionella krav som finns fastställda i tjänstekontraktet för engagemangsindex samt i T-bokens styrande principer.

Prestandakrav

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.

Standardiserade felkoder

Implementationen av SKLTPs Engagemangsindex skall returnera standardiserade felmeddelanden enligt följande.

Referens till regel eller krav i TK 1.0-RC9	Felscenario	Felkod	Feltext	Exempel på SOAP Fault
§ 6.4 Statusrapportering	Vid ett tekniskt fel levereras ett generellt undantag (SOAP-Exception).	EI000	A technical error has occurred, error message: <technical details>	Expandera källa <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>EI000: A technical error has occurred, error message: The request contains more than 1000 engagements. Maximum number of engagements per request is 1000.</faultstring> </soap:Fault> </soap:Body> </soap:Envelope>
TBD	TBD	EI001	The payload does not follow the XML Schema, error messge: <error>
§7.5 Update-R1	Element i inkommande request till Update måste vara sinsemellan unika.	EI002	EngagementTransaction <position1> and <position2> have the same key. That is not allowed. See rule for Update-R1 in service contract	Expandera källa <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>EI002: EngagementTransaction #1 and #2 have the same key. That is not allowed. See rule for Update-R1 in service contract</faultstring> </soap:Fault> </soap:Body> </soap:Envelope>
§7.5 Update-R7	Logisk adress i request till Update måste vara identisk med Engagemangsindexets ownerid.	EI003	Invalid routing. Logical address is <logical address> but the owner is <owner>. They must be the same. See rule for Update-R7 in service contract	Expandera källa <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>EI003: Invalid routing. Logical address is wrong-logical-address but the owner is ei-hsa-id. They must be the same. See rule for Update-R7 in service contract</faultstring> </soap:Fault> </soap:Body> </soap:Envelope>
§7.4 Update / §10.4 ProcessNotification	När engagemang saknar någon av de fält som enligt tjänstekontraktet är obligatoriska.	EI004	The payload does not validate, error message: <details about the validation error>	Expandera källa <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>EI004: The payload does not validate, error messge: dataController is missing but mandatory</faultstring> </soap:Fault> </soap:Body> </soap:Envelope>

Felkoder per tjänst

Nedan anges för vilka tjänster ovanstående felkoder förekommer, samt om eventuella specialiseringar förekommer.

Tjänst	Felkod	Orsak
update-service	EI000	För många engagemang i samma begäran. Denna information skickas i <technical details>.
update-service	EI002	När begäran innehåller dubbletter av engagemang
update-service	EI003	Returneras när begäran innehåller felaktig logisk adress jämfört med ownerid för engagemangsindex.
update-service	EI004	När någon av de obligatoriska fälten börjar eller slutar med ett White space.
update-service	EI004	När begäran innehåller ett engagemang utan någon av de i tjänstekontraktet definierade obligatoriska fälten

find-content-service	EI000	När någon av de obligatoriska fälten registeredResidentIdentification eller serviceDomain saknas i begäran. . Denna information skickas i <technical details>.

notification-service	EI000	För många engagemang i samma begäran
notification-service	EI002	När begäran innehåller dubbletter av engagemang
notification-service	EI004	När begäran innehåller ett engagemang utan någon av de i tjänstekontraktet definierade obligatoriska fälten

Fältlängder

Då data sparas i en relationsdatabas så finns begränsningar på fältlängder. Fältlängderna finns definierade i SKLTP EI SAD - Implementationsvy under avsnittet 'Mappning till tabell'.

En validering ska göras att fältlängderna i payload ej överskrider längden på motsvarande kolumner i databasen. För kolumner av typen TIMESTAMP ska antalet tecken i payload vara 14.

Webbläsaren stöds inte