Arkitekturkrav för aktör som ansluter system till E-hälsomyndighetens tjänster

Denna sida beskriver arkitekturkrav på aktör som vill ansluta ett godkänt system till E‑hälsomyndighetens produktionsmiljö. Målgrupp för denna sida är aktör som använder och driftar IT-system som nyttjar E‑hälsomyndighetens tjänster. För systemleverantörer finns motsvarande dokument (ref 3). Aktörer rekommenderas att läsa även detta dokument.




1. Referenser


Dokument Ver Beskrivning
1 Övergripande krav kring it- och informationssäkerhet
Detta dokument innehåller generella krav på säkerhet som anslutande system och anslutande aktörer behöver leva upp till
2 Säkerhetskrav på extern part för enskild individs direktåtkomst till E‑hälsomyndighetens register
Detta dokument är en utökning av de generella säkerhetskraven och berör anslutande tillämpningar som ska användas av privatpersoner (till exempel apoteksaktörers e-handelslösningar)
3 Arkitekturkrav för system som ansluter till E-hälsomyndighetens tjänster
Detta dokument omfattar arkitekturkrav på systemleverantörers system som integrerar mot E‑hälsomyndighetens tjänster. 

2. Omfattning

Ofta talar man om till exempel expedieringssystem och journalsystem som ett system men i verkligheten kan de omfattas av flera system, till exempel en integrationsmotor tillsammans med en e-receptmodul, journalserver och journalklient. 

För att säkerställa att arkitekturen och säkerheten följer E‑hälsomyndighetens riktlinjer och krav är det viktigt att se helheten. Kraven omfattar därför inte enbart de system som har integration mot E‑hälsomyndigheten utan även de system som används av slutanvändaren (det som oftast kallas exempelvis expedieringssystemet, journalsystemet eller vårdinformationssystemet). Alltså ingår hela kedjan från slutanvändaren via eventuella integrationssystem till E‑hälsomyndigheten.

Därför är det viktigt att systemleverantören och aktören definierar vilka komponenter och system som ingår i en lösning, både till namn och också version. Det är även lämpligt att man väljer ett övergripande namn så att det finns något att referera till.

Kraven för aktörer omfattar ett antal områden:

  • Systemsamband
  • Nätverkstopologi
  • Spårbarhet och loggning
  • Avbrottshantering
  • Distribution av mjukvara
  • Tidssynkronisering
  • Produktions- och testmiljö

3. Arkitektur- och säkerhetskrav

Säkerhetskraven i sin helhet finns specificerade i (ref 1) och (ref 2).

3.1. Systemsamband

Med systemsamband menas de samband som finns mellan systemleverantörens system, aktörens system samt E‑hälsomyndighetens system som är relevanta för att visa hur systemleverantörens system integrerar. Systemsambandskartan ska visa var känsliga personuppgifter lagras och till vilka system denna information flödar.

Syfte

  • Hitta eventuella svagheter i systemsambanden som kan äventyra obruten produktion.
  • Ge E‑hälsomyndigheten kunskap om hur systemen är uppbyggda och hur de kommunicerar med varandra. Detta kommer att underlätta vid felsökning.
  • Kartlägga var känsliga personuppgifter finns lagrade, framför allt information om personuppgifter kopplade till förskrivna läkemedel.
  • En förteckning över system som ingår i systemsambandskartan samt versionsnummer för dessa system.

Krav 3.1.1

All kommunikation mot E‑hälsomyndigheten ska ske via en central fokalpunkt/integrationsplattform. Detta kan ske på två sätt, antingen via en kanalisering av en IP-adress mot Sjunet eller via en integrationsplattform som i sin tur kommunicerar med E‑hälsomyndighetens tjänsteplattform (STP och ECP), se exemplen nedan.

Exempel utan integrationsplattform:

  Exempel med integrationsplattform:

  

KRAV

Krav 3.1.2

Det ska finnas en systemsambandskarta mellan systemleverantörens system, aktörens system samt E‑hälsomyndighetens system som beskriver de systemsamband som är relevanta och kan påverka integrationen mot E‑hälsomyndigheten. Systemsambandskartan ska visa var personuppgifter, i synnerhet tillsammans med läkemedelsuppgifter, lagras och till vilka system denna information flödar. Exempel på två systemsambandskartor ges nedan.

Exempel utan integrationsmotor:

  

Exempel med integrationsmotor:

  

KRAV

Krav 3.1.3

Det ska finnas ett övergripande namn med versionsnummer för lösningen som aktören vill ansluta samt en förteckning av ingående systemen och deras version.

Exempel

Övergripande systemnamn 1.2 (Övergripande namn och versionsnummer)

System Delsystem eller komponent Version Beskrivning/kommentar
Expedieringssystem
1.2 Systemleverantörens system som E‑hälsomyndigheten har godkänt.

Kassa 1.2

Server 2.0.2


Integrationsmotor 5.3.1

Admin 1.2
Centralt Varuregister
2.0
Statistikuppföljning
4.5.6
Ekonomisystem


4.3B

KRAV

Krav 3.1.4

Aktören ska ange vilken version av systemleverantörens system som de vill ansluta.

KRAV

3.2. Nätverkstopologi

Syfte

  • Säkerställa att känsliga personuppgifter är skyddade
  • Ge E‑hälsomyndigheten kunskap om hur systemen är uppbyggda och hur de kommunicerar med varandra. Detta kommer att underlätta vid felsökning.

Krav 3.2.2

Det ska finnas en nätverkskarta som beskriver de system som ska godkännas och visar hur de integrerar med E‑hälsomyndigheten. Alla servrar, klienter brandväggar och nät som kan ha betydelse för E‑hälsomyndigheten ska finnas med på nätverkskartan. Eventuella kopplingar till Sjunet och Internet ska synas.

KRAV

3.3. Spårbarhet och loggning

Syfte

  • Relevant information ska loggas, dels sådan information som ska loggas enligt lagar och förordningar dels information som kan användas vid felsökning.
  • Säkerställa att känslig logginformation inte går att manipulera.

Rekommendation

Systemet ska logga relevant information som kan krävas vid felsökning.

REKOMMENDATION

3.4. Avbrottshantering

Syfte

  • Säkerställa att systemet kan hantera avbrott i E‑hälsomyndighetens miljö. Det kan gälla till exempel avbrott i Nationella läkemedelslistan, HKDB eller FOTA.

Rekommendation

Vid avbrott i expedieringssystem i samband med inrapportering till FOTA bör transaktionerna automatiskt läggas på kö i systemet så att dessa kan inrapporteras automatiskt då FOTA är i full drift igen.

REKOMMENDATION

3.5. Distribution av mjukvara

Syfte

  • Säkerställa att systemleverantörens system och aktören kan distribuera ny programvara, exempelvis akuträttningar, snabbt och effektivt.

Krav 3.5.1

Förutsatt att en akuträttning tagits fram så ska denna kunna produktionssättas på samtliga installerade system inom 24 timmar.

KRAV

Rekommendation

Skapa ett automatiskt sätt att kunna uppdatera system med ny programvara.

REKOMMENDATION

3.6. Tidssynkronisering

Syfte

  • För att säkerställa att logginformation är korrekt krävs bland annat att klockorna är synkroniserade.

Krav 3.6.1

De system som integrerar mot E‑hälsomyndigheten och loggar information som till exempel tidpunkt för åtkomst ska tidsynkroniseras via ett atomur minst en gång per timme.

KRAV

3.7. Produktions- och testmiljö

Syfte

  • En aktör måste ha minst två miljöer; en produktionsmiljö och en testmiljö. En produktionsmiljö får aldrig kopplas mot E‑hälsomyndighetens testmiljö och tvärtom. Detta för att säkerställa att riktiga personuppgifter skyddas. Aktören kan nöja sig med att ha en produktionsmiljö och ställa krav på sin systemleverantör att denne tillhandahåller testmiljön. Men det är aktörens ansvar att dessa miljöer finns och är tillgängliga.
  • En aktör måste kunna genomföra felsökning i en kontrollerad miljö som inte är produktionsmiljön men som ändå är produktionslik. Detta för att kunna återskapa fel och testa rättningar av dessa fel innan rättningarna produktionssätts.

Krav 3.7.1

En produktionsmiljö får aldrig kopplas mot E‑hälsomyndighetens testmiljö och tvärtom.

KRAV

Krav 3.7.2

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

KRAV

Versionshistorik

Version Datum Kommentar
1.0 2021-11-27 Ny handbok vård- och apotekstjänster