Formålet med drift- og samarbejdshåndbogen er at konsolidere viden om drift og forvaltning af systemet på et sted. Dette afsnit af wikien indeholder beskrivelser, suppleret med eksterne links og dokumenter.

Vær opmærksom på at visse dele af Drift- og samarbejdshåndbogen kan være adgangbeskyttede, så kun særlige brugertyper har adgang. Derudover linkes også til eksterne websider, hvoraf nogle kan være adgangsbeskyttede, f.eks. på Netics confluence site.

2.1 Kundens styringsmodel

2.2 Nøgleroller

2.3 Ansvarsfordeling

2.4 Møderækker og fora

SLA-krav

SLA-rapportering sker månedligt. Denne kan tilgås via dette adgangsbeskyttede link til netics confluence site: Månedlige driftrapporter

Driftmæssig rapportering sker månedligt. Denne kan tilgås via dette adgangsbeskyttede link til netics confluence site: Månedlige driftrapporter

Rapportering om support og vedligehold sker månedligt. Denne kan tilgås via dette adgangsbeskyttede link til netics confluence site: Månedlige driftrapporter Derudover afholdes med 2-3 ugers mellemrum defect board møder hvor JIRA issues gennemgås.

Det er IT-supporten i de enkelte regioner og leverandøren af det enkelte lægepraksissystem (LPS), som agerer hhv. 1. level og 2. level support. Supporten i regionerne kan kontaktes 24/7, hvis der opleves problemer med funktionalitet relateret til FMB. Dette er valgt, da de enkelte regioner og LPS-leverandørerne selv forvalter det medicinsystem, hvori beslutningsstøttesystemet integreres, og derfor har den enkelte region og LPS-leverandør kompetencer til varetagelse af 1. level og 2. level support. Nedenstående tegning viser, hvordan support flowet.

Hver region varetager 1. level support internt i deres egen IT-support, hvor procedurerne i den enkelte region følges. Den regionale forvalter afklarer visitationsprocessen med egen IT-support. Kan IT-supporten ikke løse sagen, forventes det, at de tildeler sagen til den regionale forvalter af FMB.

Den enkelte lægepraksis kontakter sin egen LPS-leverandør, hvis der opleves fejl. Hos de enkelte LPS-leverandører kvalificeres sagen på samme måde som hos regionerne.

I dagstid (8.00 - 15.30) vil 2. level support typisk vil være den regionale forvalter af FMB i den enkelte region.

Den regionale forvalter og LPS-leverandørerne har kompetence til at vurdere, om der er tale om fejl i: • Anvendersystemets implementering af FMB (fx inddata) • Snitfladen • Beslutningsstøttemotoren (ATAH) eller datagrundlaget (fx uddata)

Er der fejl i anvendersystemets egen implementering af beslutningsstøttefunktionaliteten eller på inddata, kontakter den regionale forvalter leverandørerne af de regionale medicinsystemer via allerede etablerede support flows. Vurderer den regionale forvalter, at der er fejl i snitfladen, beslutningsstøttemotoren (ATAH) eller datagrundlaget (uddata), skal der oprettes en Jira sag hos Netic. Som udgangspunkt er det den regionale forvalter, som opretter sager i Jira hos Netic.

Netic varetager 3. level support. Netic kan blive kontaktet af de fem regionale forvaltere samt LPS-leverandørerne. Indmelderen vurderer, om sagen er af teknik eller klinisk/fagligt karakter. Er der tale om en teknisk sag, sættes Netic på sagen. Er der tale om en klinisk/faglig sag, sættes Trifork på sagen. Korrespondance om sagen vil som udgangspunkt være mellem indmelder (den regionale forvalter eller LPS-leverandøren) og Netic/Trifork. FSA inddrages i relevante sager. For at kunne følge med i indmeldte sager i Jira, får FSA’en automatisk en advisering hver gang, der oprettes en sag i Jira hos Netic.

« MAL Eksempel på sagsgang gennem JIRA »

« MAL og Sabina har begge lektier her »

Releases nummereres efter et X.Y.Z (major.minor.patch) versioneringsprincip.

En version hvor der kun er ændringer Z-delen kan indeholde bugfixes og mindre tilpasninger, der ikke giver anledninger til ændringer i snitfladen. Det vil således ikke kræve ændringer i anvendersystemerne.

En version, hvor X fastholdes, men Y ændres kan indeholde “ikke-destruktive” snitflade ændringer. Dette vil typisk være en tilføjelse af et eller flere nye optionelle elementer i snitfladen, der kan udstille ny funktionalitet, men hvor anvendersystemerne uden ændringer vil kunne fortsætte på snitfladen. Der skal her være en præcist defineret fortolkning af default adfærd når et nyt element ikke er specificeret, og adfærd mod klienter skal være konsistent.

Endelig repræsenterer versioner hvor X skifter typisk en version med snitfladeændringer, hvor det kræver ændringer i anvendersystemerne at tilgå snitfladen. Alene af den grund er der brug for formaliseret kommunikation og planlægning i forbindelse med udrulning med henblik på en smidig migreringsproces for de enkelte anvendersystemer.

Udrulning af nye releases styres via Region Nords change management system, og releases er beskrevet på denne side under Release Notes.

Forskellige tidsfrister for varsling af nye releases gør sig gældende, alt afhængig af om det er et major, minor eller patch-release. Major-releases kræver lang forudgående planlægning, da den nye snitflade kan kræve ændringer i anvendersystemerne. Minor-versionerne er knap så krævende ift. lange varsler, men kan indeholde snitfladeændringer der kræver tilpasninger i et anvendersystem, der ønsker at udnytte eventuel ny funktionalitet. Endelig kræver idriftsættelse af patches med bugfixes og små ændringer typisk kortere varsler da der ikke kræves ændringer i anvendersystemerne.

«SKEMA MED TIDSKRAV»

Releases planlægges i samarbejde med kunden, og udrulles typisk trinvis til først develop-miljøet (intern test), dernæst til exttest-miljøet (beregnet til test for kunde og eksterne parter) og når verificeret her til produktion. Typisk kan det forventes at et nyt release vil være tilgængelig for test på exttest for anvendersystemer i 1-2 uger inden der releases til produktionssystemet. Nødrettelser der idriftsættes hurtigere kan sevlfølgelig forekomme ved kritiske fejl.

Relevante oplysninger om releaset kan findes her: Release Notes

Oplysninger om datoer for release til de forskellige miljøer ses her: Miljøer og versioner

FMB er designet med høj oppetid for øje, og derfor vil langt de fleste nye releases blive lagt på produktionssystemet uden nedetid under opdateringen. Der kan i sjældne tilfælde forekomme behov for servicevinduer, typisk ved opgradering af underliggende infrastruktur komponenter (kubernetes, os, virtualisering, netværk).

Selve release-processen foregår automatiseret og reproducerbart, ved at det versionsnummer af applikationen der skal på produktionssystemet ændres i en konfigurationsfil. Denne fil er under versionsstyring, og når ændringen bliver gemt i det centrale git-repository, iværksættes den relevante deployment-pipeline.

Efter release til produktion overvåges systemet via loganalyseværktøjer med henblik på afdækning af uventede sideeffekter, og for i det hele taget at få bekræftet at systemet er kørende og fungerer efter opdateringen.

Er velsagtens dækket af ovenstående?

FMB er i gang med at etablere et fast årshjul, der bl.a. skal understøtte regionernes muligheder for at planlægge implementering i og indgå kontrakter med anvendersystemerne.

Årshjulet vil angive de overordnede rammer for major og eventuelt også minor releases. Patches vil kunne frigives løbende efter behov. Helt overordnet planlægges der med et fast årligt major-release, hvor snitfladespecifkationen er færdig «PRÆCIST HVORNÅR», således den kan danne basis for aftaler mellem regioner og anvendersystemer om implementering.

Det er endvidere et scenarie, at der, ved behov, kan gennemføres et ekstra major release en gang om året. Det vil i givet fald være et krav at anvendersystemer, der ikke ønsker / har mulighed for at implementere snitfladen umiddelbart kan forblive på den gamle snitfladeversion.