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

Denna sida beskriver generella arkitekturkrav på aktör som ansluter system till E-hälsomyndighetens tjänster.

1. Inledning

1.1 Syfte

Syftet med denna sida är att beskriva arkitekturkrav på aktörers drifttagande av system mot E-hälsomyndighetens tjänster.

1.2 Målgrupp

Målgrupp för denna sida är aktör som använder, utvecklar eller förvaltar IT-system som nyttjar E-hälsomyndighetens tjänster.

1.3 Informationsnivå

Allmän information.

1.4 Förutsättningar och avgränsningar

För systemleverantören finns motsvarande dokument [6] och [7]. Även aktören rekommenderas att läsa dessa dokument.

1.5 Referenser

Nr	Dokument	Ver	Beskrivning
1	Kravuppfyllnad Arkitektur Aktör	6.0
2	Säkerhetskrav på extern part som ansluter till eHälsomyndighetens tjänster Säkerhetskrav på extern part som ansluter till eHälsomyndighetens tjänster 17.1		Senaste version ska alltid tillämpas Övre länk gäller för 16.1, nedre länk gäller för 17.1
3	Säkerhetskrav på extern part för enskild individs direktåtkomst till eHälsomyndighetens register Säkerhetskrav på extern part för enskild individs direktåtkomst till eHälsomyndighetens register 17.1		Senaste version ska alltid tillämpas Övre länk gäller för 16.1, nedre länk gäller för 17.1
4	Handbok för apoteksaktörer		Senaste version ska alltid tillämpas
5	Handbok för vårdaktörer		Senaste version ska alltid tillämpas
6	Arkitekturkrav för system som ansluter till eHälsomyndighetens tjänster		Senaste version ska alltid tillämpas
7	Kravuppfyllnad Arkitektur Systemleverantör	7.0

2. Omfattning

Ofta talar man om till exempel expeditionssystem och journalsystem som ett system men i verkligheten kan de omfattas av flera system, exempelvis 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 expeditionssystemet, journalsystemet eller vårdinformationssystemet). Alltså ingår hela kedjan från slutanvändaren via eventuella integrationssystem till E-hälsomyndigheten.

Det är därför 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. Dokumentation

Aktören ska tillhandahålla dokumentet Kravuppfyllnad Arkitektur Aktör [1] samt de bilagor som beskrivs i detta dokument.

4. Arkitektur- och säkerhetskrav

Säkerhetskraven i sin helhet finns specificerade i [2] och [3]. Dock finns referenser till specifika säkerhetskrav i detta dokument.

4.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 läkemedel.
• En förteckning över system som ingår i systemsambandskartan samt versionsnummer för dessa system.

Krav

Krav 4.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), se exemplen nedan.

Exempel utan integrationsplattform:

 

Exempel med integrationsplattform:

 

Krav 4.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 4.1.3:

Det ska finnas ett övergripande namn med versionsnummer för lösningen som aktören vill ha godkänt 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
Expeditionssystem		1.2	Systemleverantörens system som E-hälsomyndigheten 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 4.1.4:

Aktören ska ange vilken version av systemleverantörens system som de vill godkännas mot.

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

Se övergripande säkerhetskrav [2], krav S3, S4 och S8.

Krav 4.2.1:

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.

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

Krav

Se övergripande säkerhetskrav [2], krav S7.

Rekommendation

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

4.4 Avbrottshantering

Syfte

• Säkerställa att systemet kan hantera avbrott i E-hälsomyndighetens miljö. Det kan gälla till exempel avbrott i Receptdepå human, LF, HKDB eller FOTA.
• Läkemedelsförteckningen (LF) har lagkrav på momentan uppdatering, därför får inte rättning av registret ske "dagen efter" (apoteksaktörer och deras system).

Rekommendation

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

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

Krav 4.5.1:

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

Rekommendation

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

4.6 Tidssynkronisering

Syfte

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

Krav

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

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

Krav 4.7.1:

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

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

Versionshistorik