Vård & omsorg · Swedwise Healthcare Suite

Healthcare Suite — integrationsplattformen för svensk vård i förändring

En sammanhållen svit som hanterar journalbyte, nya digitala vårdtjänster och regulatoriska krav under ett gemensamt ramverk — istället för fyra parallella plattformar och fyra leverantörer. Integration, API governance, observability och ITSM levereras som en livscykel med en partner som äger helheten.

En sammanhållen integrations- och tjänsteplattform för svensk hälso- och sjukvård.

Healthcare Suite är inte en enskild produkt utan en helhetslösning. Vi kombinerar integration, API governance, observability, AIOps och ITSM under ett gemensamt ramverk så att vårdens kritiska informationsflöden kan byggas, övervakas och förvaltas under en gemensam livscykel.

01

Integration

En integrationsförmåga som täcker både meddelandeintensiva vårdflöden (HL7, EDI, dokument) och moderna API- och event-drivna integrationer (REST, FHIR, AsyncAPI/Kafka) — utan att tvinga in allt i en och samma motor.

02

Governance

Ett gemensamt ramverk som säkerställer att varje integration följer samma standard för namngivning, säkerhet, loggning och felhantering.

03

Observability & AIOps

End-to-end-insyn över alla integrationer och meddelanden — oavsett motor — med korrelerade larm, prediktion och föreslagna åtgärder.

04

Service Management (ITSM)

Incidenter, förändringar och drift av hela integrationskedjan i ett enhetligt ITSM-flöde, kopplat till exakt det meddelande eller API som triggat ärendet.

För vem

Tre roller i regionen — tre olika frågor som måste få samma svar

En integrationsplattform misslyckas sällan tekniskt. Den misslyckas när CIO, arkitekt och förvaltningsledare inte ser samma bild av risk, ägarskap och kostnad. Healthcare Suite är byggd för att ge alla tre ett gemensamt språk.

CIO / IT-direktör

Hur byter vi journalsystem utan att riskera vården?

Ett gemensamt ramverk, en partner som äger hela kedjan från meddelande till ärende, och en TCO som går att försvara i regionstyrelsen — inte fyra parallella avtal.

Integrationsarkitekt

Hur bygger vi för förändring i 10 år framåt?

Rätt motor för rätt jobb — meddelandeflöden och API/event-drivna flöden under samma ramverk. FHIR, OpenAPI och AsyncAPI som kontraktsstandard, Omnigateway framför allt och Nodinite som tvingar samma loggstandard oavsett motor.

Förvaltningsledare

Hur hinner vi förvalta det vi redan har?

Integrationer som beställningsbara tjänster med pris, ledtid och SLA. ITSM, CMDB och observability i ett flöde — så att larm har en ägare och changes har konsekvensanalys.

Funktioner som krävs

13 funktioner en regional integrationsförmåga behöver — innan vi pratar leverantörer

Innan vi pratar produkter — det här är funktionerna en regional integrationsförmåga behöver för att hänga ihop över tid. Varje funktion påverkar en mätbar effekt. Om vi är överens om att alla behövs, då är frågan inte längre vilken leverantör — utan hur många plattformar ni vill drifta för att täcka dem.

01

Bygga & exponera

Funktioner för att leverera integrationer

API-gateway & policy enforcement

En gemensam policy- och säkerhetspunkt framför alla API:er — oavsett vilken backend eller plattform som levererar svaret.

KPI: Tid till nytt API i produktion · andel API:er med enhetlig säkerhet

Integrationsmotor för meddelandeflöden

Hantering av HL7, EDIFACT, fil och dokument med spårbarhet per meddelande — vårdens kritiska informationsflöden.

KPI: Meddelandevolym per FTE · andel spårbara meddelanden

Ofta underskattad

Event-driven & asynkron integration

Hybridarkitektur kräver både synkrona API:er och event-/batchflöden. Utan event-stöd byggs allt som synkrona kedjor som blir spröda.

KPI: Andel integrationer som är löst kopplade · MTTR vid backend-incidenter

Domän- & kontraktsstandarder (FHIR m.fl.)

Integrationer som bygger på standardkontrakt (FHIR, PEPPOL, OpenAPI) blir återanvändbara och överlever leverantörsbyten.

KPI: Andel integrationer på standardkontrakt · kostnad per ny konsument

Legacy-brygga & protokollöversättning

Gamla system lever länge. Behovet att exponera dem som moderna API:er utan att röra koden i dem är avgörande för stegvis migrering.

KPI: Antal legacy-system bakom modern gateway · tid till utfasning

02

Styra & återanvända

Funktioner för att förvalta som produkter

API-katalog & developer experience

Sökbar katalog med dokumentation, sandbox och prenumeration. Utan det byggs samma integration om och om igen.

KPI: Andel återanvända API:er · antal konsumenter per API

Tjänstekatalog & beställningsflöde

Integrationer som beställningsbara tjänster med pris, ledtid och SLA — inte långa förstudier.

KPI: Ledtid från beställning till driftsatt integration

Integrationsramverk & standarder

Gemensam standard för namngivning, loggning, felhantering och säkerhet — tvingande, inte valfri. Annars växer den tekniska skulden.

KPI: Andel integrationer som följer ramverket · onboarding-tid för nya utvecklare

Ofta underskattad

ICC / Center for Enablement

Governance-funktion som äger ramverket, standarder och kompetensspridning. Utan ICC blir varje team sin egen ö.

KPI: Andel team som följer standarden · antal återanvändbara tillgångar

Ofta underskattad

Livscykel- & produktägarskap

Integrationer behandlas som långlivade digitala produkter med ägare, versionering och SLA — inte som engångsprojekt.

KPI: Andel integrationer med ägare · andel med definierad SLA

03

Drifta & följa upp

Funktioner för att hålla i gång och förbättra

Business Activity Monitoring (BAM)

Verksamhetsnära vyer per flöde (remisser, svar, beställningar) — så att drift och verksamhet ser samma bild.

KPI: Tid från avvikelse till verksamhetslarm

Observability & AIOps

Realtidsövervakning av meddelanden, API:er och infrastruktur — med AI som korrelerar och förutsäger störningar innan de når användarna.

KPI: MTTR · andel incidenter upptäckta före användaren

ITSM, CMDB & change management

Ärenden, beroenden och förändringar i ett flöde. Utan CMDB saknas konsekvensanalys; utan ITSM blir larm utan ägare.

KPI: Andel incidenter med rotorsak inom SLA · andel changes utan oplanerade avbrott

Är vi överens om att alla 13 funktionerna behövs? Då är frågan inte längre vilken leverantör — utan hur många plattformar ni vill drifta för att täcka dem. Det leder direkt till nästa avsnitt.

Varför en helhet?

Varför man inte bör köpa delarna var för sig

01

Delarna förstärker varandra

En integrationsmotor utan observability är en blackbox. Observability utan ITSM blir larm utan ägare. ITSM utan CMDB saknar konsekvensanalys. Test utan ramverk blir punktinsatser. Suiten är designad så att varje del gör de andra mer värdefulla.

02

En livscykel — inte en produktlista

Att köpa delar var för sig skapar glapp: olika leverantörer, olika datamodeller, olika ansvar. Healthcare Suite levererar plan, build, test, release, run och support som ett sammanhängande flöde.

03

Lägre risk, snabbare värde

Standardisering, automatisering och proaktiv AI minskar både incidenter och tiden till åtgärd. Kunden betalar en gång för en helhet i stället för att integrera ihop flera leverantörer själv.

04

En partner — ett ansvar

Swedwise tar ansvar för helheten: från integration och säkerhet till övervakning, ärenden och uppgraderingar. Kunden slipper peka mellan leverantörer när något händer.

Paket

Tre paket — välj den nivå där värdet till verksamheten tar fart

Paketen sätter den kommersiella ramen runt nivåerna. Base ger en stabil integrationsförmåga, Enterprise lägger till operations och governance i full bredd, och Platinum tar bort volymtaket helt — så att verksamheten kan beställa nya integrationer och API:er när behovet uppstår, utan att varje nytt flöde behöver gå via en kommersiell förhandling.

Base

Stabil integrationsplattform

Fast årsavgift + volym

  • Integrationsmotor (xT eller MuleSoft) i drift
  • Ramverk, säkerhet och kontraktsstandarder
  • Omnigateway framför befintliga API:er
  • Nodinite loggstandard för samtliga flöden
  • Tjänstekatalog med beställningsflöde
  • Standard SLA · kontorstid med beredskap

Volymramar & tillval

  • Upp till ett definierat antal integrationsflöden
  • Upp till ett definierat antal exponerade API:er
  • Observability & ITSM som tillval
Mest valda

Enterprise

Operations + governance i full bredd

Fast årsavgift + volym

  • Allt i Base
  • Operations Bridge — observability för plattform och flöden
  • Service Management, CMDB & Release Management
  • uCMDB-koppling: verksamhetens affärstjänster övervakas
  • Chargeback/showback per kostnadsställe
  • Riktad påverkanskommunikation vid larm & changes
  • Förhöjd SLA · 24/7-jour på P1

Volymramar & tillval

  • Större men fortfarande definierat volymtak
  • AIOps & auto-remediering som tillval
All-inclusive

Platinum

Inga volymtak — full AI-driven drift

Fast årsavgift, all-inclusive

  • Allt i Enterprise
  • Fritt antal integrationsflöden
  • Fritt antal exponerade API:er
  • Fritt antal konsumenter och prenumerationer
  • AIOps med korrelation, prediktion och föreslagna åtgärder
  • Auto-remediering av kända händelsemönster
  • Dedikerat förvaltningsteam & arkitektpartner
  • Premium SLA · 24/7 på alla prioriteter

Vad det möjliggör

  • Verksamheten kan beställa nya flöden och API:er löpande — utan att varje nytt flöde triggar en kommersiell förhandling

Platinum är paketet där förvaltningsekonomin vänds: när nya integrationer och API:er inte längre kostar styckvis vågar verksamheten faktiskt beställa dem. Det är där sviten går från att vara en drifttjänst till att vara en plattform för att leverera nya funktioner och nytt värde till vårdens patienter och medarbetare.

Nivåer

Nivå för nivå — vad ni får i en samlad svit

Healthcare Suite är byggd för att införas stegvis. Varje nivå står på föregående och tillför ett mätbart värde. Tabellen sammanfattar vad ni får, vad det förutsätter och vilken effekt det ger i drift — så att ni kan börja där behovet är störst och bygga ut i takt med mognaden.

NivåVad ni fårFörutsätter · Effekt
1 · IntegrationxT och/eller MuleSoft i drift med ramverk, säkerhet och kontraktsstandarder (HL7, FHIR, EDIFACT, OpenAPI, AsyncAPI). Omnigateway framför befintliga API:er.Förutsätter: en motor på plats. Effekt: stabila flöden, enhetlig säkerhet, kortare ledtid per ny integration.
2 · Governance & katalogNodinite som tvingande loggstandard. API-katalog (Anypoint Exchange) och tjänstekatalog med beställningsflöde, SLA och ägarskap per integration.Förutsätter: nivå 1. Effekt: integrationer som produkter — sökbara, återanvändbara och förvaltningsbara över tid.
3 · Observability & ITSMObservability, CMDB, ITSM och Release Management. Larm, beroenden och ärenden i ett flöde, kopplade till exakt meddelande eller API.Förutsätter: nivå 1–2. Effekt: kortare MTTR, konsekvensanalyserade releaser, larm med ägare.
4 · AI-driven driftAIOps: korrelation, prediktion och föreslagna åtgärder. Self-service för verksamhet och utvecklare. Auto-remediering av kända händelsemönster.Förutsätter: nivå 1–3 (data och CMDB är grunden). Effekt: störningar upptäcks före användaren, drift skalar utan att bemanningen gör det.

Nivåerna är logiska steg, inte hårda paket. Många kunder har idag delar av nivå 1–2 i drift och tar nivå 3–4 i samband med kommande upphandling eller större systembyte.

TCO — operationell kostnad

En plattform vs. fragmenterat landskap — vad det faktiskt kostar

Den största kostnaden för en region är sällan licenser — det är driften av flera lösningar parallellt. Olika kompetenser, olika leverantörsavtal, olika integrationsmönster mellan plattformarna och dubbelt arbete vid varje incident. En sammanhållen plattform där samma funktioner levereras under ett ramverk minskar både den löpande operationella kostnaden och tiden från behov till driftsatt integration.

Fragmenterat landskap

4 plattformar

Integration · API · Observability · ITSM — var för sig.

  • Licens- & avtalsbredd100%
  • Kompetenser att rekrytera100%
  • MTTR vid incident90%
  • Leveranstid per integration85%

Healthcare Suite

1 plattform

Samma funktioner — ett ramverk, en partner, en livscykel.

  • Licens- & avtalsbredd45%
  • Kompetenser att rekrytera55%
  • MTTR vid incident40%
  • Leveranstid per integration45%

Illustrativ jämförelse av relativ operationell kostnad — inte uppmätta tal. Validera mot er baseline.

Dubbla kompetenser

Varje plattform kräver egna specialister — utveckling, drift, säkerhet, support. Med flera plattformar betalar regionen för samma roll flera gånger.

Integrationer mellan plattformarna

När motorerna inte hänger ihop måste flödena mellan dem byggas och förvaltas separat — ofta som de mest spröda delarna av landskapet.

Längre MTTR vid incident

Olika monitoring-stackar betyder att man måste korrelera manuellt mellan verktyg innan rotorsaken är hittad — och innan rätt leverantör kan engageras.

Leverantörsfingerpekning

När något bryts mellan två leverantörers ansvar går tid åt att bevisa var felet ligger. En partner som äger helheten tar bort den friktionen.

Dubbla licenser & avtal

Två API-managers, två loggplattformar, två ITSM-verktyg. Var och en med eget förvaltnings-, support- och uppgraderingsbehov.

Kostnad per integration

Den primära TCO-mätaren är inte plattformskostnad utan vad varje ny integration kostar att leverera och förvalta över sin livscykel.

Referenspunkter från oberoende studier & kundcase

Vad andra har mätt — siffror att validera mot er baseline

Forrester TEI — MuleSoft (2025)

426% ROI · payback < 6 mån

Sammanvägd treårsstudie: −60 % effort för API-leverans, +40 % snabbare time-to-market, 45 % återanvändning av API-tillgångar.

Läs källan →

Forrester TEI — MuleSoft (2025)

−30 % integrationskostnader

Komposabel arkitektur och återanvändning sänker både utvecklings- och förvaltningskostnaden per integration.

Läs källan →

OpenText kundcase — Redcentric (UK MSP)

+25 % produktivitet

10 000+ CI under övervakning. Operations Bridge + AIOps reducerade event-bruset och möjliggjorde auto-remediering.

Läs källan →

OpenText kundcase — Vodafone Intelligent Services

−20 % MTTR på P1 · €1M+ värde

3 miljoner IT-events/månad. Konsoliderad observability gav driftsättning ”på minuter” och mätbar incidentreduktion.

Läs källan →

Källor: Forrester Total Economic Impact™ of MuleSoft Anypoint Platform (2025) · OpenText publicerade kundcase (Redcentric, Vodafone Intelligent Services). Siffrorna är från andra organisationers miljöer och bör valideras mot er egen baseline innan de används som mål.

Leveransmodell

Köp som tjänst — i er private cloud eller hos oss

Healthcare Suite levereras som en tjänst med flexibel deploymentmodell. Samma funktionalitet, ramverk och förvaltningsprocesser oavsett var den körs.

Managed service hos Swedwise

Vi driver hela suiten åt er i vår private cloud. Ni får färdig kapacitet, SLA, patchning, uppgraderingar och 24/7-övervakning som en tjänst — utan egen drift.

Private cloud hos kunden

Hela suiten driftas i er egen private cloud eller on-prem (t.ex. region-/landstings-IT). Ni behåller full datasuveränitet och nätverkskontroll — vi ansvarar för applikationslager, ramverk och förvaltning.

Hybrid

Känsliga vårdflöden körs lokalt nära journalsystemen, medan API-exponering, katalog och observability körs centralt. Samma kodbas, samma policys, ett gränssnitt.

Samma produkt — olika leveransmodeller

Oavsett deploymentmodell är funktionalitet, ramverk och förvaltningsprocesser identiska. Ni kan starta som managed service och senare flytta in i egen private cloud — eller tvärtom.

Tjänstekatalog & self-service

Integrationer som beställningsbara tjänster — inte projekt

Tjänstekatalogen, API-katalogen och self-service-portalen gör att verksamheten kan beställa, följa och konsumera integrationer på samma sätt som vilken IT-tjänst som helst — med pris, ledtid och SLA tydligt.

Tjänstekatalog för integrationer

Färdigpaketerade integrationer (HL7 v2/v3, FHIR, DICOM, CDA, EDIFACT, PEPPOL, SDK) presenteras som beställningsbara tjänster med beskrivning, ägare, SLA och pris — istället för som tekniska projekt.

Self-service portal

En portal där utvecklare hittar API:er, administratörer hanterar åtkomst och verksamheten beställer nya flöden. Bygger på Anypoint Exchange + OpenText Service Management som gemensamt gränssnitt.

API-katalog & developer experience

Versionerade API:er med dokumentation, exempel, sandbox och kontraktstester. Konsumenter prenumererar, får nycklar och ser sin egen användning och kvot.

Beställning av nya integrationer

Strukturerade beställningsformulär fångar källa, mål, datatyper, volym, SLA och säkerhetskrav — så att utvecklare kan börja bygga direkt enligt ramverket utan långa förstudier.

Prissättning & intern fakturering (chargeback)

Varje tjänst i katalogen har ett pris — engångskostnad för uppsättning och löpande kostnad per månad/transaktionsvolym. Vid beställning ser verksamheten direkt vad det kommer kosta, och förbrukningen fakturas eller showbackas automatiskt till rätt kostnadsställe via uCMDB och Service Management. Inga svarta lådor i förvaltningsbudgeten.

Tjänster i uCMDB — övervakning av era affärstjänster

När en verksamhetstjänst beställs registreras den i uCMDB med sina beroenden till integrationer, API:er och bakomliggande system. Övervakning, SLA-uppföljning och incidenthantering följer med automatiskt — vi kan erbjuda Operations Bridge och AIOps för era affärstjänster, inte bara för plattformen.

Riktad påverkanskommunikation

När ett larm eller en planerad förändring träffar ett objekt i uCMDB vet vi exakt vilka verksamhetstjänster och vilka beställare som påverkas. Notifieringar går till rätt mottagare med rätt budskap — istället för bred driftinformation som ingen läser eller, värre, missar.

Beställningsflöde — ny integration

Från idé till driftsatt integration i ett sammanhängande flöde

  1. 01Upptäck

    Sök i tjänstekatalogen

    Beställaren letar upp en befintlig integration eller väljer 'Ny integration'. Katalogen visar ägare, SLA, pris och leveranstid.

  2. 02Beställ

    Strukturerad beställning

    Formulär med källa, mål, standard (HL7/FHIR/EDI), volym och säkerhetskrav. Godkännandeflöde startas automatiskt.

  3. 03Provisionera

    Automatisk eller manuell tilldelning

    Färdiga tjänster provisioneras automatiskt med nycklar och åtkomst. Nya integrationer routas till utvecklingsteamet med all kontext.

  4. 04Bygg & testa

    Ramverk + CI/CD + tester

    Utveckling sker enligt ramverket i xT eller MuleSoft. Funktionella tester, last och pentester körs innan release.

  5. 05Driftsätt

    Planerat deploymentfönster

    Release koordineras mot CMDB, beroenden och pågående ärenden. Konsekvensanalys och godkännanden i ett flöde.

  6. 06Förvalta

    Övervakning, ärenden, SLA & fakturering

    Beställaren följer status, SLA, incidenter och faktisk kostnad i portalen. Avvikelser triggar automatiskt ärenden i Service Management — och vid larm går riktad påverkanskommunikation till exakt de tjänster och beställare som berörs enligt uCMDB.

Teknisk fördjupning

Vill ni se hur sviten är byggd?

Hittills har vi pratat om problemet, funktionerna, paketen och leveransen. På fördjupningssidan visar vi arkitekturen, motorerna (xT, MuleSoft, OpenText, Nodinite), Omnigateway, ramverket, Kubernetes-plattformen, livscykel, testning, observability och legacy-bryggor. Bra att öppna när tekniska frågor dyker upp i mötet.

Effekt för verksamheten

Vad ni får ut av Healthcare Suite

  • Stabilare integrationer och färre kritiska avbrott
  • Kortare ledtider från incident till åtgärd
  • Säkrare hantering av patientdata och tydlig spårbarhet
  • Lägre total ägandekostnad genom ett gemensamt ramverk
  • En partner för hela kedjan — från integration till support

Vill ni se hur Healthcare Suite kan se ut i er miljö? Vi går igenom era flöden och visar ramverket konkret.