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 og ansvarsfordeling

2.3 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.

I det følgende beskrives nogle eksempler på sagers gang gennem systemet.

I dette tilfælde vil en sag blive meldt ind i JIRA. Netic modtager sagen og visiterer den til Trifork i JIRA. Et konkret eksempel kunne være et spørgsmål om en dobbeltordinationsadvarsel. I et tænkt eksempel kunne sagen gå på at brugeren ikke forstår baggrunden for en advarsel om dobbeltordination. I dette tilfælde vil Trifork analysere issuet, og nå frem til at dobbeltordinationsadvarslen f.eks. kan skyldes indholdet af et indholdsstof i et kombinationspræparat som brugeren ikke troede var vigtigt. I dette tilfælde vil Trifork skrive en kommentar i sagen, og motivere et ønske om at lukke sagen i Netics JIRA. Hvis muligt sættes status til AWAITING EXTERNAL REPSONSE (kun på incidents ikke på service requests). Sagen lukkes af indmelderen eller FSA'en.

Her meldes en sag ind i JIRA af en regional systemforvalter eller et LPS-system. Netic modtager JIRAen og visiterer den til Trifork. Trifork analyserer sagen, og konstaterer at sagen skyldes en fejl i forhold til systemets specificerede funktionalitet. Trifork opretter en sag i Triforks interne JIRA, der anvendes til at styre udviklingsprocessen internt. Sagen analyseres og prioriteres og det besluttes sammen med Projektet om rettelsen er vigtig nok til at den skal forårsage en nødrettelse, eller om rettelsen kan afvente et kommende release. Rettelsen implementeres hos Trifork, og det kommunikeres i den eksterne sag til kunden hvilket release rettelsen kan forventes at blive leveret med. Efter test af rettelsen lukkes sagen af indmelderen eller FSA'en.

Her meldes en sag ind i JIRA af en regional systemforvalter eller et LPS-system. Netic modtager JIRAen og visiterer den til Trifork. Trifork analyserer sagen, og konstaterer at systemets adfærd er som tiltænkt. Projektet kan I dette tilfælde vælge at oprette et ændringsønske på systemets backlog, hvis det vurderes at der er ønske hos brugerne om at tilpasse systemet. I dette tilfælde vil der blive oprettet en sag i videreudviklingsbackloggen, og den oprindelige JIRA-sag vil blive lukket af FSA'en med en henvisning hertil.

Ved uoverensstemmelse mellem leverandør og forvaltning, vil der kunne være behov for eskalering på begge sider.

For den fællesregionale forvaltnings side vil FSA'en kontakte sin kontorchef og vicekontorchef, sætte dem ind i situationen, hvorefter der lægges en plan for hvordan den pågældende situation skal håndteres.

Hos Trifork er ekskalationsstigen opad defineret med trin 1 - ansvarlig for Business Unit og Trin 2 - ansvarlig for Trifork Public - Healthcare.

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.

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.

FMB har fået etableret og godkendt 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 snitfladespecifikationen er færdig i december, således den kan danne basis for aftaler mellem regioner og anvendersystemer om implementering.

Årshjulet tager udgangspunkt i følgende elementer:

Et major release leveres som forudsætning for ibrugtagning af ny funktionalitet tilvejebragt via videreudvikling af FMB. Dermed bliver major releases kravsættende overfor anvendersystemerne omkring ibrugtagning af ny funktionalitet og de dermed afledte gevinster. Der leveres altid specifikation i december / release i FMB i marts. Således forventes det, at det faste årlige major release bliver fast ”fix punkt” i forventningen om, at regioner og almen praksis gradvis følger med på nye versioner af snitfladen.

Ifm. optionelle snitfladeændringer, vil anvendersystemerne altid kunne afvikles i uændret form efter frigivelse af nye minor releases (dvs. man kan blive på version 5.0.X selvom der kommer en version 5.1.X). Minor releases skal bl.a. være med til at sikre, at anvendersystemerne kan få nødvendige tilretninger med på snitfladen uden at det påvirker øvrige anvendersystemers snitflade til FMB. Det forventes, at minor releases kan frigives relativt hurtigt (og proaktivt) ift. at kunne understøtte anvendersystemerne, når behovet opstår.

Nye patches har ikke indflydelse på anvendersystemernes snitflade og kan leveres helt uafhængigt heraf. Patches indeholder fx fejlrettelser, optimeringer og kvalificeringer af datagrundlag og advarsler.

Forslag til forbedringstiltag kan komme fra forskellige steder fra. Brugergruppen er naturligvis et forum, hvor forbedringstiltag opstår, men de regionale forvaltere spiller også her en vigtig rolle, da det er dem, der skal videreformidle forbedringstiltag fra deres bagland til den fællesregionale forvaltning. Sidst men ikke mindst kan forbedringstiltag opstå som en del af løsningen af en indmeldt sag. Processen for udvikling af forbedringstiltag ser ud som nedenstående: