...

Der kan opstå et issue som i validering i forhold til nye data, der tikker ind. Så verifikationen skal indeholde nok detaljer i diff'en, så vi efterfølgende kan udersøge om diff'en er resultat af nye data.

Idriftsættelse af NXRG

I forbindelse med risikovurderingen af NXRG er blandt andet identificeret følgende to overordnede risici i forhold til idriftsættelsen af NXRG:

1. Fejl i migrering af data fra xDB til NXRG database
2. Ændringer i snitflader dvs forskelle i de konkrete implemenationer af ITI-XX services i hhv OpenText og NXRG

I forhold til punkt 1, så har vi i projektet tidligere identificeret dette, og skitseret mitigeringsforslag (se afsnit om Migrering ovenfor).

Punkt 2 handler om, at NXRG skal kunne svare sammenligneligt [med OpenText Registry] på requests fra anvenderne (via samarbejdende NSP services) efter idriftsættelsen. Dette betyder, at et request, der rammer NXRG skal give nogenlunde samme response, som hvis det havde ramt OpenText Registry.

Snitfladerne er velbeskrevne i specifikationerne, og der anvendes samme versioner (Netic må kunne se dette???) af openehealth library i NXRG, som der anvendes i OpenText. Som beskrevet i afsnittet om Validering ovenfor, så er det muligt både på OpenText og på NXRG at disable/enable validering af requests og responses for de enkelte ITI-XX services. Dog vil der sikkert være andre forretningsregler i OpenText, som ikke kan overstyres på denne måde. F.eks. kan vi konstatere, at det ikke er muligt at foretage en ITI-18 søgning uden at angive patientid, mens det er muligt at søge uden at angive statuskode, hvis validering af requests er disablet.

Indtil videre har vi identificeret følgende forslag til mitigeringstrategier i forhold til risikoen for utilsigtede snitfladeændringer i forbindelse med idriftsættelsen af NXRG:

1. Overblik over forskelle ved afvikling af XDS Toolkit mod OpenText Registry
2. Parallel drift (i produktion) af NXRG og OpenText registry
3. Afvikling af "anvender integrationstest"
4. Hurtig udrulning af NXRG på test1

De forskellige strategier kan implementeres uafhængigt og i supplemenet til hinanden. De enkelte punkter gennemgås nedenfor.

Overblik over forskelle på NXRG og OpenText Registry gennem afvikling af IHE Toolkit tests

Da OpenText Registry er closed source er det ikke muligt ved kodeinspektion at danne sig et overblik over, hvilke valideringer, der findes i OpenText Registry. Vi har forsøgt at køre Tookit Tests op i mod test1 for at give en ide om, hvorledes denne svarer (se NXRG - Testvejledning).

Parallel drift

I dette forslag går vi efter hurtigt at sætte NXRG i drift. Idriftsættelsen skal ske efter initiel (+ evt delta) migrering af data (dvs. midt november).

Når migreringen er tilendebragt, så burde datagrundlaget for NXRG og OpenText Registry være ens. De to registries burde derfor kunne svare nogenlunde sammenligneligt i efterfølgende requests.

Der udvikles derfor en "xds-registry-duplexer", der er i stand til at sende alle indkommende requests til det "nationale registry" til begge bagvedliggende registries.

Duplexeren venter på at begge registries (OpenText og NXRG) svarer og laver en "sammenligning" af svarene (som minimum om det er gået godt eller ej).

Forskelle i svarene logges og det ene svar (det giver mening at anvende OpenText Registry i en periode) sendes tilbage til den kaldende part.

Fordele: Længere vindue, hvor forskelle kan indentifieres (i prod) og rettes op uden at genere anvendene
Ulemper: Kompleks løsning, der kræver både udvikling (KIT/Arosii?) og idriftsættelse (Netic) af duplexeren samt opfølgning på, hvordan det så går. Fare for at introducere problemer i drift med duplexeren (svartider/fejl/opsætning)

Anvendertests

I stedet for "live" at sende requests til både OpenText og NXRG som foreslået i forgående afsnit, kan requests og responses opsamles ved processering af OpenText i produktion og afspilles mod en NXRG efterfølgende.

Igen kan svar sammenlignes (det skal defineres, hvad sammenligningen går ud på).

Fordele: Griber ikke ind i nuværende drift, simplere løsning at implementere (dog skal de defineres, hvordan "anvender tests" skal afvikles: Skal det være en anonymiseret udgave, som KIT skal køre som en del af udviklingen eller skal det være et "testtool", som kan afvikles af Arosii/Netic mod en NXRG i produktion (evt. efter migrering)?
Ulemper: Hvornår er udsnittet af tests "godt nok"? Muligvis en masse opgaver (manuelle?), opfølgning og koordinering.

Hurtig udrulning af NXRG på Test1

I dette forslag håber vi, at de requests, der rammer OpenText registry i NSP miljøet Test1 er sammenlignelige med dem, der senere rammer produktion.

Ved at rulle NXRG på test1 og lade anvenderne gå i gang med at bruge det nye registry, så bliver forskelle måske opdaget hurtigere.

Fordele: Kan bare lægges på. Ikke så farligt, da det "bare" er test.
Ulemper: Hvordan identificerer vi problemer og følger op? Hvad gør anvenderne, hvis det ikke virker? Måske rammes test1 også i dag af en masse skrald, som vi ikke skal kunne håndtere?