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.

<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>

<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>

<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>

<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.

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.