Community på Sveriges dataportal

@Björn-Hagström Även jag har stött på det vid ett par tillfällen. Försökte få dem att öppna upp för de IP-adresser jag använde men utan framgång.

Rent krasst så antar jag att man ser det som ett sätt att skydda sina API:er och att man antar att alla konsumenter är i Norden. Man tänker inte på att även svenska konsumenter kan ha sina servrar utomlands, i mitt fall Holland.

@jonor sa i DiBa:

Riksrevisionen bedömer att myndigheterna inte arbetar med att involvera användare i tillräcklig omfattning, när de utvecklar de digitala tjänsterna.

Tack för citatet. Å vad jag älskar Riksrevisionen!

@jonor @Matself Jag skulle gärna se att en ordentlig utredning gjorde en gedigen funktionsjämförelse och användarjämförelse (patient- och medarbetarupplevelse) mellan öppna alternativ som GNU Health och de system på marknaden idag som äter upp allt större delar sjukvårdsbudgetar t.ex. av den anledning som @Matself påpekar bra. Jag är säker på att det skulle vara billigare och bättre för ekonomi, patienten och medarbetarna att regionerna tillsammans sponsrade öppen källkod-projekt och anpassade dem till svensk sjukvård och reglering. SKRs dotterbolag Inera AB skulle med säkerhet kunna hitta kompetens för att drifta en öppen källkod lösning on-premise för varje region i något vackert bergrum. 😄

Såvitt jag förstått har inte regionerna gått med på att enas om standard/specifikation kring journaler och det vore en bra första vinst. 👍

@Matself tydlig exempel på en service som inte fokuserar på mottagaren. Hoppas en framtida lösning fokuserar mer på att mottagaren process.

En lösning som jag tycker funkar bra är de sms som jag får från 1177.

”Du har ett meddelande i 1177 Vårdguidens e-tjänster. Läs det genom att logga in på 1177 Vårdguiden. Obs! Du kan inte svara på detta sms”

Funkar bra för alla, med undantag för åldersspannet 13-18 år. (Men problemet för denna åldersgrupp här hänger ihop med tillgång till eleg)

@Björn-Hagström Verkar som om brevet ändå hade någon sorts substans. https://www.regeringen.se/regeringsuppdrag/2022/12/uppdrag-till-statskontoret-att-utfora-en-myndighetsanalys-av-myndigheten-for-digital-forvaltning/

Jo, jag förstår oron. Metadatan i detta fall har givetvis en viss nivå av konfidentialitet, möjligen på nivån "Intern: informationen ska endast spridas till medarbetare inom organisationen och till externa som har behov av informationen".
Om sedan höga krav på riktighet och tillgänglighet kommer in i bilden förs tankarna till en molnlösning i det fall man inte tror sig ha förmågan att leverera detta internt. Så vida konfidentialitetskraven inte står i vägen.

För exemplet övervakning så behöver metadata givetvis flöda till den molnbaserade övervakningsplattformen, och då gissar jag att konfidentialitetskravet "1 - Intern: informationen ska endast spridas till medarbetare inom organisationen och externa som har behov av informationen"
skulle kunna tolkas som ok? Allt är från fall till fall iofs.

Har det amerikanska företaget möjligheter att göra något av exempelvis följande: - Installera/uppdatera programvara som körs

Inte för en hybridlösning där det just bara är övervakningen och inget annat som körs i molnet.
Man ja, för exemplet Google Anthos och Azure Arc: det är en förutsättning för att deras marknadsplatser ska fungera. Och även för uppdatering av beroenden för övervakningsfunktionaliteten. Sedan är det kunden som styr över önskade applikationscontainers och möjligheten finns att även driftsätta plattformskomponenter vid sidan om molnplattformens gränssnitt.

- Konfigurera nätverk och omdirigera trafik.

Inte nödvändigtvis för en molnplattform som endast hanterar övervakning.
För ex Anthos/Arc så finns/krävs möjligheten att styra ingress/egress och trafik inom klustret. Man säljer ju ett centralt gränssnitt för administration av miljöer både i leverantörens och det egna datacentret och även hos konkurrentens datacenter. Sedan ger man ju givetvis inte ut åtkomst för att styra nätverkskonfiguration utanför kubernetesklustret.

Lägga till eller förändra autentiseringsinformation.

Anthos/Arc kan integrera mot ex Azure AD eller andra OAuth2/OIDC tjänster. Jag ser inte direkt hur de skulle modifiera dessa, men det finns ju möjligheter att skada om man sitter som en "man in the middle". RBAC inom klustret är också en feature att kunna styra från det centrala gränssnittet i molnet.

Åtkomst till administratörsgränssnitt även om de på pappret bara används för övervakning.

Yes, om molnplattformen erbjuder funktionalitet för att administrera infra i det egna datacentret så finns det ju spakar att dra i, även om de inte ska göra det...

Jag undrar om delar av detta kan utmanas med nya molnerbjudanden kring konfidentiella plattformar. Ex så pratar Google om compute där kunddata kan vara krypterad at rest - in transit och in use (smaka på den) och gav under senaste Google Next '22 ett exempel där två banker tillsammans bygger anti-fraud lösning tillsammans på samma infrastruktur och där bådas konfidentiella data nyttjades i samma plattform men förblev oläsbar för den andra parten. Men jag gissar att det här är ett upplägg som är mer experimentiellt än så länge.

@Stefan-Wallin vi har idag olika svenska nätverk för open source; NOSAD, Open Source Sweden, Sambruk… När DIGG tagit fram sina riktlinjer för open source har dessa bollats med ett antal organisationer som är aktiva i NOSAD. Utöver dessa organisationer har Sverige samarbeten via Ena och eSAM. Ur mitt perspektiv har vi behov att hantera en nationell open source katalog, säkerställa att myndigheter som delar sin källkod också använder samma metadatastandard så att koden kan hittas inom EU, säkerställa att det finns möjlighet till frågor om samt rekommendationer kring it-säk och juridik, samt att vi diskuterar affärsmodeller och visar på goda exempel. Allt detta kan göras idag under befintliga samarbeten och infrastruktur ( som detta forum). Men det kan finnas behov av att säkerställa tillgång till viss kompetens i organisationssamanslutningar. Att skapa en organisation är det lilla problemet.