På denna sida sammanfattas icke-funktionella krav på aktörer och system som ska ansluta till Nationella läkemedelslistan.

---

---

1. Kravområden

1.1. Nertid- och avbrottshantering

Dessa krav har till syfte att säkerställa att anslutande system kan hantera avbrott av E-hälsomyndighetens tjänster.

Vid oplanerad nertid av Nationella läkemedelslistan kan otillgänglighet visa sig på flera olika sätt. Tjänster kan vara

• helt otillgängliga (ej nåbar)
• tillgänglig men ej kunna ge svar på ställda frågor (svar ges, men med felkod)
• delvis otillgänglig (delar av systemet är otillgängligt och för vissa anrop ges svar med felkod).

Anslutande system ska kunna hantera samtliga dessa fall. Det är av vikt att hantering finns för när tjänst åter blir tillgänglig igen, utan att (exempelvis) manuella åtgärder krävs för att återuppta fungerande läge. Detta kan exempelvis åstadkommas med återförsöksförfarande (retry).

För att hantera uppdateringar av systemet kommer servicefönster att användas. Anslutande system ska kunna hantera otillgänglighet av tjänster vid servicefönster.

Hantering av planerad nertid

Krav-ID: IK 1

Det ska finnas stöd i anslutande system att förhålla sig till planerad nertid ("servicefönster") av E-hälsomyndighetens tjänster. Detta kan exempelvis åstadkommas genom att kunna försätta systemet i ett läge där anrop mot E-hälsomyndighetens tjänster inte sker och relevant information visas för slutanvändare.

Hantering av oplanerad nertid

Krav-ID: IK 2

Det ska finnas stöd i anslutande system att förhålla sig till bortfall av tillgänglighet av E-hälsomyndighetens tjänster. Systemet ska kunna hantera avsaknad av svar eller svar med felkoder. Om möjligt även visa upp relevant information för slutanvändare i systemet.

1.2. Uppdatering av mjukvara

Dessa krav har till syfte att säkerställa att systemleverantörens system och användande aktör av systemet snabbt och effektivt kan distribuera ny programvara vid planerad release (för E-hälsomyndighetens tjänster) eller vid akuträttningar.

Stöd för produktionssättning av planerade releaser

Krav-ID: IK 3

Systemet ska kunna uppdateras kontinuerligt enligt gällande releaseplan från E-hälsomyndigheten med anpassningar som krävs för kompatibilitet.

Stöd för produktionssättning av akuta rättningar

Krav-ID: IK 4

Systemet ska kunna uppdateras om allvarliga fel upptäcks, utanför ordinarie releaseplan. Dessa fel ska kunna rättas och releasas skyndsamt. 

1.3. Momentan läsning av information

Syftet med Nationella läkemedelslistan är att uppdaterad och aktuell information ska hämtas från registret vid varje tillfälle som information från Nationella Läkemedelslistan ska användas. Ovan nämnda syfte är en av anledningarna till att det inte är tillåtet med lagring av information från Nationella läkemedelslistan i anslutande system med undantag för vad som anges i övergripande krav OK 9 avseende komplettering av journal.

Läsning av Nationella läkemedelslistan sker momentant

Krav-ID: IK 5

Anslutande system ska säkerställa att aktuell information används från Nationella läkemedelslistan. 

1.4. Dubbletthantering vid omsändning

Omsändning definieras här som ett anrop från aktörssystem till Nationella läkemedelslistan och där svar uteblir (exempelvis på grund av timeout vid oplanerad nertid) och där det är oklart om anropet mottogs och bearbetades. Dubbletthantering detaljeras vidare i Krav på anropsresultat och felhantering.

Unikt ID i anrop för dubletthantering

Krav-ID: IK 6

Anslutande system ska implementera hantering av Anrops-Id vid omsändning för att dubletthantering ska fungera.

1.5. Tidssynkronisering

Dessa krav har till syfte att säkerställa att anslutande system och E-hälsomyndighetens tjänster har synkroniserad tid. Detta är viktigt exempelvis för att giltighetstid för säkerhetsintyg ska kunna gå att avgöra korrekt och för att tidsstämplar i logginformation ska gå att använda för felsökning.

Tidssynkronisering tillämpas

Krav-ID: IK 7

System som integrerar mot E-hälsomyndigheten ska tillämpa tidssynkronisering genom att använda sig av NTP eller motsvarande.

1.6. Miljöer

Dessa krav har till syfte att säkerställa möjlighet till exempelvis felsökning under kontrollerade former. För vissa fel som kan inträffa är det inte möjligt eller lämpligt att felsöka i produktionsmiljö och av denna anledning behöver dessa fel avhjälpas i produktionslik testmiljö (där eventuella fel går att återskapa). Med produktionslik avses främst funktionella förmågor. 

Tillhandahållande av miljöer

Krav-ID: IK 8

En aktör måste säkerställa att det är möjligt att kunna genomföra felsökning i en kontrollerad miljö som inte är produktionsmiljön men som ändå är produktionslik.

1.7. Disaster recovery

I händelse av större katastrof kan E-hälsomyndigheten komma att tvingas ta upp system på en annan end-point (adress/IP-nummer till tjänst hos E-hälsomyndigheten) än den som vanligtvis används för produktionstrafik. Trots att detta är en osannolik händelse är det av vikt att anslutande aktörers system har möjlighet att genomföra en akut ändring av adresser / IP-nummer som används för kommunikation mot E-hälsomyndighetens tjänster. Detta kan exempelvis uppnås genom att adresser och IP-nummer hanteras genom konfigurationsfiler, miljövariabler eller liknande.

Stöd för omkonfiguration av end-points

Krav-ID: IK 9

System som integrerar mot E-hälsomyndigheten ska ha stöd för att akut genomföra byte av adresser för kommunikation mot E-hälsomyndighetens tjänster.

1.8. Hantering av batch-läsningar

I händelse av läsning av större mängder data från E-hälsomyndighetens system (batch-läsning - läsning av data med maskin-till-maskin-användare), ska det vara möjligt att schemalägga sådana läsningar till tider när det är mindre belastning på E-hälsomyndighetens tjänster. Det kan vara lämpligt att utföra batch-läsningar utanför kontorstid eller på helger och ska göras i samråd med E-hälsomyndigheten.

Schemaläggning av batch-läsningar

Krav-ID: IK 10

System som utför batch-läsning av data från E-hälsomyndighetens system måste kunna schemalägga dessa, så att de inträffar förutsägbart och utan att störa övrig trafik. Detta görs i samråd med E-hälsomyndigheten.

1.9. Hantering av logiska ID:n

För att resursinstanser ska ha ett standardiserat format och utgöra en unik identifierare används så kallat "logiskt ID" (ett UUID) som representation. I vissa fall är detta även en del i skydd av personlig integritet, exempelvis för personnummer. Då det inte är möjligt att med säkerhet garantera att logiska ID:n är beständigt över tid för vissa resurser är det inte lämpligt att lagra logiska ID:n i anslutande system för användning vid framtida anrop. Anropande system ska därför allltid utföra relevanta uppslag av logiska ID:n för dessa resurser, för att säkerställa att rätt information används. Logiska ID:n får efter uppslag återanvändas under en och samma session - där en session är alla anrop som sker för en användare som använder ett och samma säkerhetsintyg.

Hantering av logiska ID:n

Krav-ID: IK 11

För tjänsteanrop som använder sig av ett logiskt ID som referens till resurserna Patient och RelatedPerson ska uppslag av logiskt ID göras i den session som föranleder användandet av det logiska ID:t och inte använda ett sedan tidigare lagrat logiskt ID.

1.10. Hantering och presentation av informationsmängder

För att information ska hanteras korrekt måste anslutande system hantera information på ett korrekt sätt. Detta innefattar fältlängder, datatyper och hantering av hela svaret på ställda frågor. Detta gäller både hur information behandlas internt i systemet och hur information presenteras för användare. Som exempel måste ett fält av sträng-typ med fältlängd 800 kunna hanteras i sin helhet. Det är inte tillåtet att ha en begränsning på exempelvis 500 tecken vid behandling eller visning. Detta gäller även för tjänsteanrop som innehåller flera svar, exempelvis en sökning eller en fråga där svaret innehåller "en patients samtliga förskrivningar" där samtliga förskrivningar måste kunna hanteras och presenteras i systemet utan inbyggda begränsningar.

E-hälsomyndigheten förbehåller sig rätten att utan förvarning ändra innehållet i beskrivande text av felmeddelanden. För att ta logiska beslut rekommenderar vi användning av felkoder. Felkoder i sig kommer dock inte ändra innebörd oannonserat.

Hantering av informationsmängder och datatyper

Krav-ID: IK 12

System måste säkerställa att datatyper och fältlängder kan hanteras korrekt och i sin helhet. Detta definieras i FHIR-profiler som publiceras på sidan om Nationella läkemedelslistan på Simplifier (simplifier.net).

Hantering samtliga delar av svaret

Krav-ID: IK 14

System måste säkerställa att svar kan hanteras i sin helhet så att ingen information försvinner på grund av begränsningar.

Tolkning av felmeddelanden

Krav-ID: IK 15

System ska inte tolka eller ta logiska beslut baserat på innehåll i beskrivande (textuell) information som felmeddelanden eller värde i värdemängd, utan i stället använda sig av kodade värden för detta ändamål. 

Användning av fritextfält

Krav-ID: IK 16

Fritextfält ska inte innehålla betydelsebärande koder för maskinell tolkning.

1.11. Hantering av kodade värden

Ett kodverk är en uppsättning koder och termer som ska användas för ett särskilt syfte. Ett sådant syfte kan till exempel vara för att ange administreringsmetod på en förskrivning. Kodverken är tillgängliga i Nationella läkemedelslistan via FHIR:s resurs Valueset (värdemängd översatt). När ett system använder värdemängder och ska skicka ett valt värde till Nationella läkemedelslistan ska koden (ej termen) skickas in. Koden ska hämtas från en värdemängd som är gällande.

Hantering av värde i värdemängd

Krav-ID: IK 17

Det är alltid koden, för valt värde i en värdemängd, som ska skickas in till Nationella läkemedelslistan.

Aktiv version av kod används

Krav-ID: IK 18

I attribut av kodad typ får endast kod från den aktiva versionen av en värdemängd användas när attributet ändras eller en ny resurs skapas.

1.12. Hantering av PDF:er

PDF-rapporter som returneras från E-hälsomyndighetens tjänster får inte sparas i anropande system efter användning (exempelvis efter utskrift). Det är heller inte tillåtet att använda delar av rapporter eller göra förändringar i rapporter.

Krav-ID: IK 19

PDF-rapporter som returneras från E-hälsomyndighetens tjänster får inte sparas i anropande system.

Krav-ID: IK 20

Det är inte tillåtet att ändra eller göra utklipp från PDF-rapporter utan de ska användas i sin helhet - rapporter ska visas i sin helhet för användare.

1.13. Heltäckande och robust implementation av FHIR-standard

Dessa krav har till syfte att säkerställa att anslutande system har ett fullgott stöd för FHIR. Nationella läkemedelslistans tjänstegränssnitt bygger på FHIR version 4.0.1. Förändringar av detta tjänstegränssnitt kommer komma att behöva göras över tid, exempelvis på grund av lagförändringar eller för att stödja ny funktionalitet i Nationella läkemedelslistan.

Förändringar i tjänstegränssnittet som bryter bakåtkompabilitet hanteras som extern release (se Releaseinformation v21). Övriga förändringar hanteras som intern release, exempelvis tillägg av icke-obligatoriska informationsmängder (element).

För att säkerställa att anslutande system inte får problem vid interna releaser, och heller inte behöver genomgå omfattande förändringar i samband med övergång till extern release, krävs en robust och heltäckande implementation av FHIR. Rekommendationen är därför att använda ett standardbibliotek för FHIR-hantering. FHIR är en plattformsoberoende specifikation som på många sätt är dynamisk för att maximera interoperabilliteten och skapa en robust kommunikation. Anslutande system skall kunna hantera bakåtkompatibla förändringar i API:et utan att det stoppar eller hindrar informationsflödet.

Exempel på bakåtkompatibla förändringar som anslutande system behöver hantera (ej komplett lista).

• Ordningen på FHIR-element som levereras i svar kan variera.
• Nya icke obligatoriska attribut kan tillkomma (exempelvis en Extension, eller ett FHIR standardattribut).
• Datatyper kan få förändrade (begränsande) egenskaper (min, max mm).
• Nya FHIR-profiler kan tillkomma.
• Referenser till objekt förändras (inbäddad resurs vs. extern länk).
• Förändringar kan göras av koder i dynamiska värdemängder, se krav Krav-ID: 34:1:1 i TA-34 Hämta värdemängder och kodrelationer.
  

Stöd för FHIR 4.0.1

Krav-ID: IK 21

Anslutande system ska ha en robust och heltäckande implementation av FHIR 4.0.1 som standard så att bakåtkompatibla förändringar/tillägg som behöver göras i så kallad Intern release inte riskerar resultera i en bruten integration.

Versionshistorik