Arkitekturkrav för system som ansluter till eHälsomyndighetens tjänster
1. Inledning
1.1 Syfte
Syftet med denna sida i handbok är att beskriva arkitekturkrav på systemleverantörers system som ansluter sig till 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-älsomyndighetens tjänster.
1.3 Informationsnivå
Allmän information.
1.4 Avgränsningar och förutsättningar
För aktörens drifttagande av system finns motsvarande dokument [6] och [7]. Systemleverantör rekommenderas att även läsa dessa dokument.
1.5 Referenser
2. Omfattning
Ofta talar man om till exempel expeditionssystem 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 expeditionssystemet, 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 systemleverantörer omfattar ett antal områden:
- Integration
- Komponentsamband
- Processimplementation
- Spårbarhet och loggning
- Avbrottshantering
- Distribution av mjukvara
3. Dokumentation
Systemleverantören ska tillhandahålla dokumentet Kravuppfyllnad Arkitektur Systemleverantö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 Integration
Syfte
- Säkerställa att anslutning till tjänstegränssnitt sker på korrekt sätt.
Krav
Krav 4.1.1:
Integrationen ska ske på följande sätt:
Gäller för release 16.1:
- Integration mot E-hälsomyndighetens tjänster sker via webbservices och SAML-biljetter.
- Vissa tillämpningar använder sig av partneringångar som använder sig av webbservices för att kommunicera med E-hälsomyndighetens tjänster.
- Hämtning av VARA-fil sker genom sftp.
Gäller för release 17.1:'
- Integration mot E-hälsomyndighetens tjänster sker via Säker åtkomst (webbservices, åtkomstintyg, SAML-biljett)
- Vissa tillämpningar använder sig av partneringångar som använder sig av webbservices för att kommunicera med E-hälsomyndighetens tjänster.
- Hämtning av VARA-fil sker genom sftp.
Rekommendation
Om E-hälsomyndighetens datamodell, till exempel OR, innehåller tillstånd, exempelvis nytt recept, påbörjad expedition, expedierat recept, makulerat recept, ska man inte lagra detta tillstånd lokalt. Om exempelvis en timeout sker, kan E-hälsomyndighetens och aktörens system få olika tillstånd. Detta kan då resultera i att användaren fastnar i ett tillstånd som endast kan lösas om förvaltningen manuellt hanterar ärendet. Den information som ligger i E-hälsomyndighetens system/databaser är alltid rätt (master) vid sådana tillfällen.
4.2 Komponentsamband
Med komponentsamband menas de ingående komponenter som systemet är uppbyggt av. Komponentsambandskartan ska visa hur systemets olika komponenter integrerar samt vilka komponenter som integrerats mot E-hälsomyndigheten.
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.
- Komponentuppdelningen syftar också till att ge en uppdelning av systemet/systemen så att förändringar som systemleverantören behöver göra enklare kan kategoriseras. Detta underlättar vid beslut av hur förändringen påverkar E-hälsomyndigheten och vilka tester som krävs i samband med ett nytt godkännande av till exempel service-pack.
- En förteckning över komponenterna som ingår i systemet samt versionsnummer för dessa komponenter.
Krav
Krav 4.2.1:
Det ska finnas en komponentsambandskarta som beskriver det system och komponenter som ingår i den produkt som systemleverantören levererar. Vidare ska det tydligt visa vilka komponenter som integreras med E-hälsomyndigheten. Den ska även visa var känsliga personuppgifter, i synnerhet tillsammans med läkemedelsuppgifter, lagras.
Exempel på en komponentsambandskarta för apoteksaktör ges nedan.
Krav 4.2.2:
Det ska finnas ett övergripande namn med versionsnummer för lösningen som systemleverantören vill ha godkänt samt en förteckning av ingående komponenter och deras version. Komponentuppdelningen beror lite på hur systemet är uppbyggt, det kan bestå av flera system som i sin tur består av flera komponenter som kan installeras och uppdateras oberoende av varandra.
Exempel
Expeditionssystem 1.2 sp2 (Övergripande namn och versionsnummer)
| Kassaklient |
|
1.2 |
|
| Receptexpedierings-klient |
|
2.0.3 |
|
| Central server |
|
2.0.2 |
|
|
Order |
|
Uppdateras aldrig i separata versioner |
|
Lager |
|
Uppdateras aldrig i separata versioner |
|
Kassa |
|
Uppdateras aldrig i separata versioner |
|
Receptexpediering |
|
Uppdateras aldrig i separata versioner |
|
Behörighetshantering |
|
Uppdateras aldrig i separata versioner |
|
Ekonomi |
|
Uppdateras aldrig i separata versioner |
|
Integrationslager |
|
Uppdateras aldrig i separata versioner |
| Integrationsmotor |
|
5.3.1 |
|
|
Varuförsörjning |
1.1 |
|
|
eHälsomyndigheten |
3.4 |
|
|
Kortbetalning |
1.2 |
|
|
Uppföljning |
3.4b |
|
| Huvudkontors-klient |
|
1.2 |
|
Krav 4.2.3:
Systemleverantör ska ange vilken av E-hälsomyndighetens release (STP-release) som systemet ska godkännas mot.
4.3 Processimplementation
Syfte
- Upptäcka felaktiga anropskedjor
- Upptäcka onödiga anrop. Detta för att kunna optimera och minska antalet anrop som görs mot E-hälsomyndigheten.
- 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
Krav 4.3.1:
Det ska finnas sekvensdiagram som visar anropsflödet mot E-hälsomyndighetens tjänsteplattform för normalfallen. Detta krävs för att kunna bedöma om anrop görs i onödan som kan påverka E-hälsomyndighetens tjänsteplattform.
Exempel på ett sekvensdiagram för orderberedning:
Rekommendation
Följ i största mån den kedja av anrop (process) som E-hälsomyndigheten beskriver i dokumentet [4] alternativ [5]. Undvik att göra onödiga anrop.
4.4 Spårbarhet och loggning
Syfte
- Relevant information ska loggas, dels sådan information som ska loggas enligt gällande 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.5 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 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.6 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.6.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.
Versionshistorik
| 1.0 |
2009-10-05 |
Första godkända dokumentet. |
| 2.0 |
2010-01-15 |
Uppdaterad för att även passa vårdsystemen. Uppdaterad och generaliserad för samtliga aktörer och externa integratörer mot Apotekens Service tjänster. Uppdaterat kapitel 6.1 med krav på integration via en central kommunikationsnod. Borttag av ledningssystem samt lagt till krav på tidssynkronisering |
| 3.0 |
2010-05-31 |
Uppdaterad med bland annat förtydliganden runt systemsambanden. Delat upp dokumentet i två dokument. Ett för systemleverantörer och ett för aktörer. |
| 4.0 |
2010-08-11 |
Uppdaterad och generaliserad för att passa samtliga systemleverantörer |
| 5.0 |
2013-01-02 |
Uppdaterat referenser till andra dokument samt integrationskrav. Dokumentet byter namn från "Granskningsprocessen - Arkitektur Systemleverantör". |
| 6.0 |
2014-01-28 |
Uppdaterat i samband med övergång från Apotekens Service till eHälsomyndigheten. Dokumentet byter namn från "Godkännandeprocessen Arkitektur Systemleverantör" och samtidigt renodlas dokumentet till att bara innehålla krav. |
| 7.0 |
2017-07-20 |
Lagt till ny referens i tabell, Kravuppfyllnad Arkitektur Aktör |
| 8.0 |
2017-07-20 |
Korrigerat stavfel |
| 9.0 |
2017-10-24 |
Förtydligat att det gäller versionspaket 16.1 |
| 10.0 |
2017-11-02 |
Tagit bort att det gäller versionspaket 16.1 |
