Teknisk fördjupning · Swedwise Healthcare Suite
Så är Healthcare Suite faktiskt byggd
Arkitektur, motorer, Omnigateway, ramverk, Kubernetes-plattform, livscykel, testning, observability och legacy-bryggor — för den som vill se hur sviten hänger ihop tekniskt.
Arkitektur
Så hänger komponenterna ihop
Integrationsmotorerna driver flödena. Observability-stacken övervakar, korrelerar och driver ärenden — allt knutet till CMDB. Tips: klicka på en nod i diagrammet för att hoppa till funktionsbeskrivningen.
Två integrationsmotorer
Rätt motor för rätt flöde — säkerhet och API Governance i botten
Vården behöver både traditionell meddelandeintegration och moderna API-drivna tjänster. Healthcare Suite kombinerar två etablerade motorer under ett gemensamt ramverk så att val av teknik styrs av användningsfallet — inte av plattformens begränsningar.
xT
Produkt från Xware
Integrationsmotor för meddelande- och dokumentflöden
- Produkt från Xware, beprövad i svensk vård för EDI, HL7 och dokumentbaserade flöden
- Stark spårbarhet på meddelandenivå
- Säker hantering av patientrelaterad information
MuleSoft
Produkt från Salesforce / MuleSoft
API-ledd integrationsmotor
- Anypoint Platform med inbyggd API Manager för full API Governance
- Policy-driven säkerhet: OAuth 2.0, mTLS, JWT, rate limiting och threat protection per API
- API-katalog och versionering som gör det möjligt att exponera vårdens tjänster säkert mot interna och externa konsumenter
- FIPS-läge, kryptering i transit och i vila samt detaljerad audit log
Omnigateway
Samma säkerhet och API Governance — oavsett integrationsplattform
Med MuleSoft Anypoint Flex Gateway (Omnigateway) kan vi lägga samma säkerhet, policys och API Governance framför vilken integrationsplattform eller vilket API som helst — oavsett om det körs på MuleSoft, xT, BizTalk, IBM, Boomi, Azure APIM, egna microservices eller äldre legacy. Kunden behöver inte byta plattform för att få en gemensam säkerhetsmodell.
Plattformsoberoende
Flex Gateway körs som lättviktig runtime framför valfria backends — moln, on-prem, hybrid eller Kubernetes. Samma policy-motor oavsett var API:et lever.
Enhetlig säkerhet
OAuth 2.0, mTLS, JWT-validering, IP-allowlist, threat protection och rate limiting appliceras centralt — samma kontroll för alla API:er.
En API-katalog för allt — även event-drivet
Alla gränssnitt — REST, SOAP och event-drivna flöden beskrivna med AsyncAPI (Kafka-topics, event-streams, pub/sub) — registreras i Anypoint Exchange. En sökbar katalog, en konsumentupplevelse, en kontraktsmodell, oavsett om bakomliggande teknik är ett synkront API eller en Kafka-topic.
Event-driven arkitektur på samma plattform
MuleSoft har inbyggda connectors för Kafka, JMS, Solace och Azure Event Hubs. Samma runtime och samma governance används för synkrona API:er och event-drivna flöden — vi behöver inte resa en separat integrationsstack för meddelandebaserad arkitektur.
Observability över allt
Trafik, latens, fel och konsumtion samlas i samma vy och vidare in i OpenText Operations Bridge / AIOps — oavsett vilken backend som faktiskt levererar svaret.
Bygger på MuleSoft Anypoint Flex Gateway. Mer info: docs.mulesoft.com/gateway
Vårt ramverk
Samma standard för varje integration — oavsett motor
En standard för alla integrationer
Vårt ramverk definierar hur integrationer ska byggas oavsett motor — namngivning, felhantering, retries, loggformat, säkerhetsmönster och övervakningspunkter.
Säkerhet och regelefterlevnad
Inbyggda kontroller för GDPR, patientdatalagen och NIS2. Tydlig separation av miljöer, hemlighetshantering och åtkomstmodell.
Förvaltningsbart över tid
När varje integration följer samma mönster blir suiten enkel att förvalta, migrera och utöka — utan att den tekniska skulden växer.
Nodinite — ramverket i praktiken
Loggning, larm och förvaltning enligt en gemensam standard
Ramverket realiseras tekniskt med Nodinite — en svensk plattform för loggning, övervakning och förvaltning av integrationer. Nodinite är den gemensamma standard som tvingar varje integration, oavsett om den körs i xT eller MuleSoft, att logga, larma och spåras på samma sätt. Det är skillnaden mellan ett dokumenterat ramverk och ett ramverk som faktiskt efterlevs i produktion.
Enhetligt logghuvud
Varje meddelande loggas med samma metadata — affärsobjekt, korrelations-ID, system, miljö och status — så att samma sökning fungerar tvärs över alla integrationer.
Business Activity Monitoring
Verksamhetsnära vyer per flöde (remisser, svar, beställningar) — drift och förvaltning ser samma bild som verksamheten, inte bara tekniska loggar.
Sök, resend & repair
Felade meddelanden kan sökas fram, inspekteras och köras om direkt från Nodinite — utan att utvecklare behöver gå in i respektive plattform.
Larm och SLA per integration
Tröskelvärden, SLA och larmregler definieras per integration enligt ramverket — och triggar automatiskt ärenden i OpenText Service Management.
Tvingar ramverket i praktiken
Eftersom integrationer måste logga till Nodinite för att alls bli förvaltningsbara blir standarden inte valfri — den blir en naturlig del av definition of done.
Spelar ihop med OpenText
Nodinite täcker integrations- och meddelandelagret. OpenText Operations Bridge, AIOps och CMDB lägger sig ovanpå för infrastruktur, korrelation och ITSM — tillsammans en komplett bild.
Bygger på Nodinite. nodinite.com
Plattform
Kubernetes i botten — skalbarhet, redundans och zero-downtime
Hela suiten körs i Kubernetes vilket ger en modern, molnoberoende grund med inbyggd skalning, självläkning och säkerhet på infrastrukturnivå.
Kubernetes-native
Hela suiten — xT-runtimes, MuleSoft Flex Gateway, OpenText-komponenter och portaler — paketeras som containrar och körs i Kubernetes (OpenShift, Rancher, EKS, AKS, GKE eller on-prem).
Skalbarhet
Horisontell autoskalning per komponent. Tunga meddelandeflöden och API-trafik skalas oberoende — ni betalar för faktisk last, inte för värsta tänkbara topp.
Redundans & hög tillgänglighet
Flera repliker över noder och availability zones. Self-healing pods, rolling upgrades och automatisk failover — ingen enskild nod är kritisk.
Zero-downtime releases
Blue/green och canary-deployer via Kubernetes gör att uppgraderingar av integrationer och plattform kan rullas ut utan avbrott för vårdens flöden.
Resursisolering & säkerhet
Namespaces, NetworkPolicies, secrets management och RBAC ger tydlig isolering mellan miljöer, kunder och flöden — och uppfyller krav på GDPR, patientdatalagen och NIS2.
Infrastructure as Code
Helm-charts och GitOps (Argo CD/Flux) gör miljöer reproducerbara. Disaster recovery, miljökopior och nya regionala installationer kan rullas ut snabbt.
Så hänger det ihop
En sammanhängande livscykel — från plan till support
Healthcare Suite är inte en samling lösa produkter. Varje fas i livscykeln är kopplad till nästa via gemensam CMDB, ramverk och ärendeflöde.
- 01Plan
CMDB & beroendekarta
Alla integrationer, API:er och anslutna system modelleras som CI:er med tydliga beroenden — en förändring i ett system visar direkt konsekvenser i andra.
- 02Build
Ramverk & standard
Varje ny integration byggs enligt samma mönster för säkerhet, loggning och felhantering — oavsett om den körs i xT eller MuleSoft.
- 03Test
Funktionellt, last & säkerhet
Test-delen i sviten täcker funktionella tester, lasttester och säkerhetstester inklusive pentester av exponerade API:er och flöden.
- 04Release
Deploymentfönster
Releases planeras mot CMDB och pågående ärenden. Deploymentfönster, konsekvensanalys och godkännanden hanteras i ett flöde.
- 05Run
Övervakning & AIOps
Operations Bridge + AIOps övervakar i realtid. Avvikelser triggar automatiskt ärenden i Service Management med rätt prioritet och ägare.
- 06Support
Ärende & rotorsak
Ärenden kopplas till exakt det meddelande, API-anrop eller flöde som triggat dem — kort tid till rotorsak och åtgärd.
CMDB i centrum
Tjänster, integrationer, API:er och infrastruktur är modellerade med beroenden. En förändring i ett system visar direkt vad som påverkas — och vilka deploymentfönster som passar.
Proaktiv AI
AIOps lär sig hur flödena normalt beter sig och flaggar avvikelser innan de blir incidenter — ofta innan användaren märker något.
Planerade uppgraderingar
Uppgraderingar av xT, MuleSoft eller anslutna system planeras mot CMDB, testas i sviten och driftsätts i kontrollerade fönster.
Test i sviten
Test, säkerhet och pentester — inte ett separat projekt
Testdelen i Healthcare Suite täcker hela spannet — från funktionella tester och last till pentester och sårbarhetsskanning av exponerade API:er.
Funktionella tester
Automatiserade tester av integrationer och API:er som del av CI/CD — körs vid varje förändring innan release.
Last- och prestandatester
Simulering av verkliga vårdvolymer för att säkerställa att flödena håller även vid toppbelastning.
Pentester & sårbarhetsskanning
Återkommande penetrationstester och sårbarhetsskanning av exponerade API:er, MuleSoft-policys och integrationsändpunkter.
Regressionstester
Skyddar mot att uppgraderingar av xT, MuleSoft eller anslutna system bryter etablerade flöden.
Tillval
Tillvalet Observability
Tillvalet Observability bygger helt på OpenText-produkter och ger full transparens och kontroll genom hela integrationskedjan. Realtidsövervakning, proaktiv incidenthantering och AI-drivna insikter gör att avvikelser identifieras innan de påverkar verksamheten. Kombinationen av observability och ITSM ger snabbare felsökning, högre tillgänglighet och kortare ledtider vid incidenter — vilket säkerställer stabila integrationer, bättre användarupplevelse och minskad affärsrisk.
Observability (Operations Bridge)
Central monitoring av meddelanden, loggar och prestanda över xT, MuleSoft och anslutna system. Sökbar historik, korrelerade larm och affärsregler.
ITSM (Service Management)
Incident-, problem-, förändrings- och konfigurationshantering. Ärenden kopplas direkt till de integrationer och meddelanden som triggat dem.
AIOps
Proaktiv AI som upptäcker mönster, korrelerar händelser och förutsäger störningar innan de når användarna — med föreslagna åtgärder och automation.
CMDB & Release Management
Konfigurationsdatabas med beroenden mellan tjänster, API:er, integrationer och underliggande infrastruktur. Driver planering av uppgraderingar, deploymentfönster och konsekvensanalys.
Observability-stacken bygger på OpenText-produkter — Operations Bridge, Service Management, AIOps samt CMDB & Release Management.
Tillägg — legacy environments
Brygga över gamla system under övergångsperioden
Verkligheten i vården är att gamla system lever länge. Healthcare Suite har tilläggsmoduler som låter er köra vidare på legacy under övergångsperioden — utan att kompromissa med säkerhet, spårbarhet eller övervakning.
Legacy connectors
Färdiga adaptrar för äldre protokoll och format: HL7 v2, EDIFACT, X12, fil/SFTP, MQ, SOAP/WS-*, COM+, databasköer och flatfiler — exponeras som moderna API:er via Omnigateway.
Protokollöversättning
xT översätter mellan gammalt och nytt (t.ex. HL7 v2 ↔ FHIR, EDIFACT ↔ PEPPOL, SOAP ↔ REST) så att nya konsumenter kan börja användas innan gamla system fasas ut.
Strangler-mönster
Stegvis migrering: Omnigateway sätts framför det gamla systemet, trafik flyttas konsument för konsument till det nya — utan big-bang och utan att bryta befintliga flöden.
Säkerhetslyft för gamla API:er
OAuth 2.0, mTLS, rate limiting och threat protection läggs ovanpå legacy-system som saknar modern säkerhet — ni får dagens skyddsnivå utan att röra koden i det gamla systemet.
Observability för legacy
Loggar, mätvärden och spårning från äldre system samlas i OpenText Operations Bridge och AIOps — samma övervakning och ärendeflöde som för moderna integrationer.
Tidsbegränsade övergångslicenser
Tilläggen kan tecknas för en avgränsad migreringsperiod och avvecklas automatiskt när legacy är utfasat — ni betalar bara så länge ni faktiskt behöver bron.
Vill ni gå tillbaka till översikten — problemet, paketen, nivåerna och leveransen?