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

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.

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.

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.

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.

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.

3.6. Tidssynkronisering

Syfte

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

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.

Versionshistorik