Page History
Navitabs | ||
---|---|---|
| ||
Table of Contents
Introduktion
Formål
Formålet med dette dokument er at beskrive systemarkitekturen for NXRG.
Læsevejledning
Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i NXRG og dens opbygning.
Definitioner og referencer
NSP | National Service Platform |
NXRG | NXP XDS Registry (kendt som SDS patientindeks) |
IHE | Integrating the Healthcare Enterprise (se https://www.ihe.net/) |
Overblik over NXRG
I det følgende gives et overblik over NXRG. Først beskrives NXRG i forhold til dennes samarbejdende services og interne arkitektur (modulopdeling etc.)
Efterfølgende beskrives og begrundes den underliggende datamodel.
Løsningsoverblik
I nedenstående dokument vises overblik over NXRG. Diagrammet viser både løsningens snitflader og eksterne services, som denne samarbejder med. Derudover vises den NXRGs intern lagdelte opbygning (herunder specificering af ansvarsfordelingen i de forskellige lag i applikation).
Samarbejdende services
NXRG samarbejder med følgende komponenter i NSP infrastrukturen:
XDS er baseret på, at dokumentkilder i et index registrerer metadata om dokumenter, de kan stille til rådighed. En dokumentanvender kan herefter foretage opslag på indexet og ud fra returnerede metadata, foretage indhentning af dokumenter til efterfølgende visning og/eller udtræk af informationer.
Implementeringen af XDS i NXRG er illustreret i nedenstående model.
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/f20ddf81-adf5-4779-b33c-348af5706030.html" name="test" height="420" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
Samarbejdende services
NXRG samarbejder med følgende komponenter i NSP infrastrukturen:
- Dokumentdelingsservice : DDS anvender den af NXRG udbudte ITI-18 snitflade til at udføre søgninger efter data registreret i NXRG.
- OpenXDS Repository: OpenXDS Repository opbevarer de konkrete dokumenter, der registreres på NSP XDS. OpenXDS anvender NXRGs udbudte ITI-42 snitflade for at få indexeret det metadata, som følger med de konkrete dokumentregistreringer.
- DROS: DROS udbyder registrerings- og opdaterings snitflader ud mod anvendersystemerne. DROS proxy'er kald af ITI-42, ITI-57 og ITI-61 videre til NXRG på de udbudte snitflader.
- Driftsskeduleret oprydning (XDSCleanup): Da dokumentregistreringer kun
- Dokumentdelingsservice : DDS anvender den af NXRG udbudte ITI-18 snitflade til at udføre søgninger efter data registreret i NXRG.
- OpenXDS Repository: OpenXDS Repository opbevarer de konkrete dokumenter, der registreres på NSP XDS. OpenXDS anvender NXRGs udbudte ITI-42 snitflade for at få indexeret det metadata, som følger med de konkrete dokumentregistreringer.
- DROS: DROS udbyder registrerings- og opdaterings snitflader ud mod anvendersystemerne. DROS proxy'er kald af ITI-42, ITI-57 og ITI-61 videre til NXRG på de udbudte snitflader.
- Driftsskeduleret oprydning (RegJob): Da dokumentregistreringer kun skal leve i NXRG i begrænset tid (de konkrete regler for opbevaring besluttes af de tilsluttede projekter), skal driften have mulighed for at rydde op (slette) gamle dokumentregistreringer, som ikke længere skal opbevares i NXRG. Der udbydes snitflader til oprydning af NXRG.
- National Adviserings Service (NAS): I forbindelse med opdateringer via ITI-42, ITI-61 og ITI-57 tjekkes det, om der skal sendes udsendes notifikationer for dokumentet.
Diagrammet nedenfor viser både løsningens snitflader og eksterne services, som denne samarbejder med. Derudover vises den NXRGs intern lagdelte opbygning (herunder specificering af ansvarsfordelingen i de forskellige lag i applikation).
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
Gliffy Diagram | ||||||||
|
NXRG er opbygge opbygget i en lagdelt arkitektur. I ovenstående diagram er pakkenavne specificeret og giver en kobling til den konkrete sourcekode, der realiserer NXRG (se i øvrigt NXRG/SDS Patientindex - Guide til Udviklere).
Snitflader
De udbudte snitflader er realiseret som SOAP webservices (dk.nsp.nxrg.ws). ITI-XX snitfladerne er specificeret i IHE XDS revision 17 fra juli 2020.
...
- ITI TF-1: IHE IT Infrastructure Technical Framework Volume 1 (ITI TF-1) Integration Profiles (Revision 17.0 – Final Text)
- ITI TF-2a: IHE IT Infrastructure Technical Framework Volume 2a (ITI TF-2a) Transactions Part A (Revision 17.0 – Final Text)
- ITI TF-2b: IHE IT Infrastructure Technical Framework Volume 2b (ITI TF-2b) Transactions Part B (Revision 17.0 – Final Text)
- ITI TF-3: IHE IT Infrastructure Technical Framework Volume 3 (ITI TF-3) Cross-Transaction Specifications and Content Specifications (Revision 17.0 – Final Text)
- IHE IT ITI TF-Metadata: IHE IT Infrastructure Technical Framework Supplement XDS Metadata Update Rev. 1.11 – Trial Implementation July 12, 2019
Til at realisere disse ITI-XX snitflader anvendes tredjeparts biblioteker fra IPF Open eHealth Integration Platform til implementations- og hjælpeklasser (herunder mapning af XML baseret model til domænemodel).
Forretningslag
Forretningsregler i relation til de udbudte ITI-XX services er implementeret udfra specifikationen af IHE XDS (dk.nsp.nxrg.service). For ITI-18 er det besluttet ikke at understøtte samtlige querytyper, der fremgår af specifikationen, men at nøjes med følende:
- FindDocuments
- FindDocumentsByReferenceId
- GetDocuments
Kald af ITI-18 med andre querytyper vil resultere i en fejlkode fra NXRG (se NXRG/SDS Patientindex - Guide til Anvendere).
Validering af forespørgler og svar
Forespørgsler og svar valideres efter reglerne beskrevet i IHE XDS specifikationen. Mere præcist udføres validering som beskrevet i følgende afsnit:
- ITI-18: ??? (endnu ikke implementeret)Afsnit 3.18.4 (Se ITI TF-2b).
- ITI-42: Afsnit 3.42.4 (Se ITI TF-2b).
- ITI-57: ??? (endnu ikke implementeret)Afsnit 3.57.4 (Se ITI TF-Metadata).
- ITI-61: ??? (endnu ikke implementeret)
Sammenligning af patientId'er
Ved validering af forespørgsler skal der sammenlignes patientId'er. Ifølge specifikationen skal denne sammenligning tage højde for sammensmeltning af patientId'er (This comparison shall take into consideration patient identity merges as described in ITI TF-2a: 3.8.4.2.4.). I NXRG er det antaget, at denne form for sammensmeltning ikke forekommer, og sammenligning af patientId'er er derfor implementeret ved simpel strengsammenligning.
Databaselag
NXRG har behov for at persistere data i en database. NXRGs datamodel er realiseret udfra følgende principper:
- Muligt at udvide med nye querytyper, hvis dette skulle ønskes senere
- Muligt at implementere en passende migreringsstrategi for data i det gamle NSP XDS Registry uden tab eller forvansking af data
For en detaljeret beskrivelse af databasemodellen se afsnittet nedenfor.
Eksterne services
Der er i dag eksterne services, der tilgår OpenText Registry direkte (dvs udenom de i forgående afsnit skitserede NSP services).
Det drejer sig om følgende:
- KIH Repository
De fleste andre eksterne services (f.eks. PLSP, Bookplan, Laboratoriesvarportalen) udbyder data ved selv at udstille XDS Registry+XDS Repository snitflader, som Dokumentdelingsservicen så integrerer med. Ændringer i det nationale registry vil ikke berøre disse typer.
KIH Repository
KIH databasen (repository) indeholder dokumenter af typerne PHMR og QRD dvs hjemmemålinger og spørgeskemabesvarelser. KIH Repository anvender det nationale registry til at få indexeret disse dokumenter og gøre dem søgbare via Dokumentdelingsservicen.
KIH databasen kalder således ITI-42 på det nationale registry. Der er to muligheder i fremtiden:
- KIH kalder direkte på NXRG ITI-42: Denne løsning er tilsvarende det, der sker i dag
- KIH kalder DROS ITI-42: DROS ventes at komme til at indeholde valideringer, der vil øge kvaliteten af de metadata, der i sidste ende havner i det nationale registry. Ved at lade KIH anvende denne snitflade vil KIH metadata blive underlagt samme valideringer. NB ITI-42 på DROS findes både i en DGWS og en ikke-DGWS (IP whitelisting eller SDN aftale) udgave. For KIHs vedkommende vil det være relevant at kalde ikke-DGWS snitfladen for at undgå snitfladeændringer.
Inden driftsstart for NXRG skal det afklares, hvilket af de to punkter ovenfor, der ønskes.
Derudover skal der udarbejdes en plan i samarbejde med Medcom om, hvordan det skal foregå.
Afvigelser fra IHE XDS standarden
I forhold til NXRG, så er det ikke hele IHE XDS specifikationen, der implementeres. I de følgende afsnit dokumenteres evt. fravalg og beslutninger ved de enkelte services.
ITI-18: Registry Stored Query
I forhold til fremsøgning, så er det besluttet, at følgende query typer skal understøttes:
- FindDocuments
- FindDocumentsByReferenceId
ITI-57: Update Document Set
Specifikationen beskriver i afsnit "3.57.4.1.3.4 Patient ID Reconciliation", hvordan det skal håndteres, hvis patient-id opdateres som en del af et kald til ITI-57. I forhold til NXRG, så har vi valgt, at denne ikke skal understøtte dette, hvorfor et forsøg på ITI-57 kald, hvor patient id opdateres vil resultere i en fejl til anvenderen.
Patient ID Reconciliation vil resultere i øget kompleksitet i NXRG, og anvendere vil kunne opnå det samme ved f.eks. at deprecate eksisterende data på en patient, og dernæst oprette data på en anden.
Derudover vil anvendelsen af NXRGs ITI-57 service ikke foregå direkte men via DROS - Guide til anvendere. I forhold til auditlogning og diverse tjek, så er de fleste NSP anvender services tænkt til en brug, hvor der er netop én patient i kontekst ad gangen.
Vi vurderer, at skift af patient ID vil skabe øget unødvendig kompleksitet i de anvenderrettede services.
Andet væsentlige at notere for design af NXRG
ITI-57 Update metadata
Dette kald tillades ikke for OnDemand dokumenter. Det anvendte biblioteks fra Open eHealth afviser typen OnDemand i forbindelse med opdatering af metadata. Det fungerer sådan for både Open Text registry og NXRG.
ITI-61 replace document
Dette kald opfører forskelligt for Stable og OnDemand dokumenter. Ved replace af Stable dokument deprecates de gamle dokument. Dette sker ikke for onDemand dokumenter. Der er i ovenstående specifikationen ikke nævnt noget med status ændring for OnDemand Det fungerer sådan for både Open Text registry og NXRG.
Databasemodel
Følgende overblik viser, hvorledes datamodellen i NXGR er opbygget. Datamodellen er opbygget med udgangspunkt i følgende overordnede principper:
- Understøtte MVP: NXRG er startet som et Minimal Viable Product med intentionen om senere at kunne skifte til et andet mere modent produkt. Dette betyder, at modellen ikke skal være mere kompliceret, end højst nødvendigt.
- Kunne understøtte udvidelser af NXRG: Selvom kravene (MVP) fra starten er begrænsede, så giver det mening at overveje, at det skal være muligt at udvide NXRG f.eks. med flere ITI-18 query typer. Datamodellen skal i denne sammenhæng være robust over for denne slags ændringer (dvs det skal være velforstået, hvad sådanne udvidelser betyder i forhold til databasemodellen).
- Understøtte migrering: Da en væsentlig del af MVP indeholder migrering af data fra OpenText Registry til NXRG, så skal databasemodellen være lavet på en måde, således at migreringen er understøttet.
- Driftsvenlig: Det skal være muligt for driften at foretage opgaver i forbindelse med support og drift (f.eks. oprydningsjob)
I det følgende beskriver vi datamodellen for NXRG og beskriver, hvorledes ovenstående principper er respekteret. Datamodellen præsenteres først i overbliksform i nedenstående E/R-diagram, og de enkelte tabeller beskrives derefter.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Hver entitet i diagrammet svarer til en tabel.
De vigtigste entiteter er Association, DocumentEntry, Folder og SubmissionSet, som er NXRG's repræsentation af de tilsvarende begreber fra IHE-specifikationen. I det følgende kaldes disse fire tabeller for objekttabeller. En række i en objekttabel svarer til et tilsvarende objekt, f.eks. svarer en række i Association-tabellen til et Association-objekt, en række i DocumentEntry-tabellen til et DocumentEntry-objekt, osv. Disse tabeller indeholder de attributter som der er brug for, for at NXRG kan realisere sine snitflader. Tabellerne er dog ikke fulstændige modeller af de objekter, de repræsenterer, da det er ganske omfattende at udarbejde og vedligeholde en sådan datamodel. De fulde objekter gemmes i stedet som xml i en tilhørende *Content-tabel (i det følgende kaldet en indholdstabel).
Objekttabellerne indeholder de attributter der er nødvendige for at understøtte søgning gennem ITI18-snitfladen, samt for at tjekke forretningsregler i ITI42-, ITI57- og ITI61-snitfladerne. Indholdstabellerne indeholder selve objekterne i et xml-format, der er nemt at parse og serialisere, men besværligt at søge i.
Association
...
AssociationContent
...
Author (documententry_author)
...
Code (documententry_eventcode og documententry_confidentialitycode)
...
DocumentEntryContent
...
DocumentEntries
...
- Afsnit 3.61.4 (Se ITI TF-2b).
Validerings opsætning
Open eHealth frameworket, der anvendes af både OpenText og NXRG, stiller muligheden for validering af request og responses til rådighed. Det er denne validering, som i stor udstrækning anvendes som validerings mekanisme i NXRG.
Både NXRG og Open Text har det som konfiguration, om sådanne valideringer skal udføres i forbindelse med forespørgsel og svar (request/response) og for de forskellige typer kald (ITI-42, ITI-61, ITI-57 og ITI-18).
Følgende tabel viser, hvordan denne konfiguration af validering er sat op for nuværende NXRG og tidligere anvendte Open Text:
NXRG generelt | Open Text - Test 1 | Open Text - Test 2 | Open Text - Produktion | |||||
---|---|---|---|---|---|---|---|---|
Request | Response | Request | Response | Request | Response | Request | Response | |
ITI-42 | Disabled | Disabled | Disabled | |||||
ITI-61 | Disabled | Disabled | Disabled | |||||
ITI-57 | ||||||||
ITI-18 | Disabled | Disabled | Disabled | Disabled |
Sammenligning af patientId'er
Ved validering af forespørgsler skal der sammenlignes patientId'er. Ifølge specifikationen skal denne sammenligning tage højde for sammensmeltning af patientId'er (This comparison shall take into consideration patient identity merges as described in ITI TF-2a: 3.8.4.2.4.). I NXRG er det antaget, at denne form for sammensmeltning ikke forekommer, og sammenligning af patientId'er er derfor implementeret ved simpel strengsammenligning.
Validering af ITI-18 fremsøgning response
Da Open Text var registry, var der ikke request (input) validering på oprettelses kalende (ITI-42 og ITI-61). Derfor er der herfra fejlbehæftet metadata, som ikke overholder IHE standarden. Når der laves en fremsøgning (ITI-18), og bare eet af disse dokumenter er imellem, vil kaldet gå i fejl, og ingen af dokumenterne blive returneret.
For at undgå denne situation er, er der i NXRG lavet sådan, at hvert dokuments metadata, der returneres fra fremsøgningen, valideres for sig selv. De dokumenter, som fejler i valideringen, returneres ikke i resultatsættet. Der indsættes istedet for disse en fejl linie i svaret, ligesom dokumentet logges til applikations loggen. Dokumentet identificeres her ved entryUuid. Er der sådanne frasorteringer i fremsøgning sættes status til Partial success, og hvis alle fremsøgte dokumenter frasorteres sættes status til Failure.
Databaselag
NXRG har behov for at persistere data i en database. NXRGs datamodel er realiseret udfra følgende principper:
- Muligt at udvide med nye querytyper, hvis dette skulle ønskes senere
- Muligt at implementere en passende migreringsstrategi for data i det gamle NSP XDS Registry uden tab eller forvansking af data
For en detaljeret beskrivelse af databasemodellen se afsnittet nedenfor.
XDSCleanup service
De data, der opbevares i NXRG, skal slettes efter noget tid. Hvor lang tid der er tale om, kommer an på typen af data. Til at afgøre denne klassifikation anvendes metadata-attributten typeCode (den består af to komponenter: en typeCode-kode og en typeCode-scheme) på DocumentEntry.
Foreløbigt gælder følgende regler:
- Aftaledokument (Typekode: 56446-8): Skal slettes efter 2 år
Sletning varetages af den separate service XDSCleanup. Der henvises til dokumentationen for denne service for en beskrivelse af reglerne for, hvordan og hvornår sletning af dokumentmetadata finder sted.
Eksterne services
Der er i dag eksterne services, der tilgår OpenText Registry direkte (dvs udenom de i forgående afsnit skitserede NSP services).
Det drejer sig om følgende:
- KIH Repository
De fleste andre eksterne services (f.eks. PLSP, Bookplan, Laboratoriesvarportalen) udbyder data ved selv at udstille XDS Registry+XDS Repository snitflader, som Dokumentdelingsservicen så integrerer med. Ændringer i det nationale registry vil ikke berøre disse typer.
KIH Repository
KIH databasen (repository) indeholder dokumenter af typerne PHMR og QRD dvs hjemmemålinger og spørgeskemabesvarelser. KIH Repository anvender det nationale registry til at få indexeret disse dokumenter og gøre dem søgbare via Dokumentdelingsservicen.
KIH databasen kalder således ITI-42 på det nationale registry. Der er to muligheder i fremtiden:
- KIH kalder direkte på NXRG ITI-42: Denne løsning er tilsvarende det, der sker i dag
- KIH kalder DROS ITI-42: DROS ventes at komme til at indeholde valideringer, der vil øge kvaliteten af de metadata, der i sidste ende havner i det nationale registry. Ved at lade KIH anvende denne snitflade vil KIH metadata blive underlagt samme valideringer. NB ITI-42 på DROS findes både i en DGWS og en ikke-DGWS (IP whitelisting eller SDN aftale) udgave. For KIHs vedkommende vil det være relevant at kalde ikke-DGWS snitfladen for at undgå snitfladeændringer.
Inden driftsstart for NXRG skal det afklares, hvilket af de to punkter ovenfor, der ønskes.
Derudover skal der udarbejdes en plan i samarbejde med Medcom om, hvordan det skal foregå.
Afvigelser fra IHE XDS standarden
I forhold til NXRG, så er det ikke hele IHE XDS specifikationen, der implementeres. I de følgende afsnit dokumenteres evt. fravalg og beslutninger ved de enkelte services.
ITI-18: Registry Stored Query
I forhold til fremsøgning, så er det besluttet, at følgende query typer skal understøttes:
- FindDocuments
- FindDocumentsByReferenceId
- GetDocuments
Dog forholder det sig sådan, at "FindDocumentsByReferenceId" ikke understøttes af DDS'en og dermed kan den i praksis ikke kaldes. Der anses ikke for nuværende behov for at ændre dette.
Når man laver en fremsøgning med ITI-18, kan man få to typer af objekter tilbage, baseret på den retur type man sætter i kaldet.
- LeafClass: her returnes en liste af matchende documentEntry med fuld metadata
- ObjectRef: her returnes en liste af objekt referencer, som entryuuid
En måde at fremsøge meget store datamængder på, kan derfor laves med først en fremsøgning retur type ObjektRef og efterfølgende anvende disse værdier til at lave en GetDocuments med retur typen LeafClass.
DDS'en understøtter dog ikke "ObjectRef" retur typen, og der anses ikke for nuværende behov for at ændre dette. En detalje ved returnering af objekt referencer er, at man ikke vil kunne lave spærringer på dokumenter alene på disse. Men det vil kunne ske efterfølgende når id'erne anvendes i en GetDocuments og metadata faktisk hentes frem.
ITI-57: Update Document Set
Specifikationen beskriver i afsnit "3.57.4.1.3.4 Patient ID Reconciliation", hvordan det skal håndteres, hvis patient-id opdateres som en del af et kald til ITI-57. I forhold til NXRG, så har vi valgt, at denne ikke skal understøtte dette, hvorfor et forsøg på ITI-57 kald, hvor patient id opdateres vil resultere i en fejl til anvenderen.
Patient ID Reconciliation vil resultere i øget kompleksitet i NXRG, og anvendere vil kunne opnå det samme ved f.eks. at deprecate eksisterende data på en patient, og dernæst oprette data på en anden.
Derudover vil anvendelsen af NXRGs ITI-57 service ikke foregå direkte men via DROS - Guide til anvendere. I forhold til auditlogning og diverse tjek, så er de fleste NSP anvender services tænkt til en brug, hvor der er netop én patient i kontekst ad gangen.
Vi vurderer, at skift af patient ID vil skabe øget unødvendig kompleksitet i de anvenderrettede services.
Andet væsentlige at notere for design af NXRG
ITI-57 Update metadata
Dette kald tillades ikke for OnDemand dokumenter. Det anvendte biblioteks fra Open eHealth afviser typen OnDemand i forbindelse med opdatering af metadata. Det fungerer sådan for både Open Text registry og NXRG.
ITI-61 replace document
Dette kald opfører forskelligt for Stable og OnDemand dokumenter. Ved replace af Stable dokument deprecates de gamle dokument. Dette sker ikke for onDemand dokumenter. Der er i ovenstående specifikationen ikke nævnt noget med status ændring for OnDemand Det fungerer sådan for både Open Text registry og NXRG.
ITI-42 Register document set
For dette kald, tillades 'replay' requests. Dvs. hvis servicen modtager to gyldige identiske requests, vil den i begge tilfælde give succes svar, selvom dataen kune gemmes første gang.
To requests anses dog kun som identiske hvis alle elementer har et gyldigt entry uuid. Hvis ikke, genererer servicen nye entry uuid'er, og de to requests bliver dermed forskellige.
Håndterede type koder (type codes)
NXRG kan konfigureres med en liste af type codes, sådan at en instans håndtere en eller flere type koder. Dette resulterer i følgende opførsel
- ITI-18 Registry Stored Query: hvis typecode indgår i søge parametrene og ingen af dem håndteres, returneres et tomt kald. Ellers udføres søgningen.
- ITI-42 Register document set: hvis typecode indgår i dokumentets metadata (documententry) og den ikke håndteres afvises kaldet med en fejl.
- ITI-61 Register on demand document: hvis typecode indgår i dokumentets metadata (documententry) og den ikke håndteres afvises kaldet med en fejl.
- ITI-57 Update metadata: hvis typecode indgår i dokumentets metadata (documententry) og den ikke håndteres afvises kaldet med en fejl.
Databasemodel
Modellen nedenfor viser to databaser: Metadata, som er den database der vedligeholdes og ejes af NXRG, og Dokumenter, som er den database der vedligeholdes og ejes af OpenXDS.
xDB indeholder således metadata for det centrale registry, hvorimod mariaDB indeholder dokumenterne i repository.
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/ab7ca898-d965-4204-82ce-0add06c9e2b3.html" name="test" height="310" width="800">You need a Frames Capable browser to view this content.</iframe> |
* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.
Datamodellen er opbygget med udgangspunkt i følgende overordnede principper:
- Understøtte MVP: NXRG er startet som et Minimal Viable Product med intentionen om senere at kunne skifte til et andet mere modent produkt. Dette betyder, at modellen ikke skal være mere kompliceret, end højst nødvendigt.
- Kunne understøtte udvidelser af NXRG: Selvom kravene (MVP) fra starten er begrænsede, så giver det mening at overveje, at det skal være muligt at udvide NXRG f.eks. med flere ITI-18 query typer. Datamodellen skal i denne sammenhæng være robust over for denne slags ændringer (dvs det skal være velforstået, hvad sådanne udvidelser betyder i forhold til databasemodellen).
- Understøtte migrering: Da en væsentlig del af MVP indeholder migrering af data fra OpenText Registry til NXRG, så skal databasemodellen være lavet på en måde, således at migreringen er understøttet.
- Driftsvenlig: Det skal være muligt for driften at foretage opgaver i forbindelse med support og drift (f.eks. oprydningsjob)
I det følgende beskriver vi datamodellen for NXRG og beskriver, hvorledes ovenstående principper er respekteret. Datamodellen præsenteres først i overbliksform i nedenstående E/R-diagram, og de enkelte tabeller beskrives derefter.
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Hver entitet i diagrammet svarer til en tabel.
De vigtigste entiteter er Association, DocumentEntry, Folder og SubmissionSet, som er NXRG's repræsentation af de tilsvarende begreber fra IHE-specifikationen. I det følgende kaldes disse fire tabeller for objekttabeller. En række i en objekttabel svarer til et tilsvarende objekt, f.eks. svarer en række i Association-tabellen til et Association-objekt, en række i DocumentEntry-tabellen til et DocumentEntry-objekt, osv. Disse tabeller indeholder de attributter som der er brug for, for at NXRG kan realisere sine snitflader. Tabellerne er dog ikke fulstændige modeller af de objekter, de repræsenterer, da det er ganske omfattende at udarbejde og vedligeholde en sådan datamodel. De fulde objekter gemmes i stedet som xml i en tilhørende *Content-tabel (i det følgende kaldet en indholdstabel).
Objekttabellerne indeholder de attributter der er nødvendige for at understøtte søgning gennem ITI18-snitfladen, samt for at tjekke forretningsregler i ITI42-, ITI57- og ITI61-snitfladerne. Indholdstabellerne indeholder selve objekterne i et xml-format, der er nemt at parse og serialisere, men besværligt at søge i.
Alle tabellerne har felterne creation_time og last_update_time, der indeholder tidspuntk for oprettelse henholdsvis ændring.
Tabellen fieldmigrationstatus indeholder ikke registry relateret data, men er en "arbejdstabel", der anvendes til at holde styr på, hvor langt potentielle felt migreringer er (se afsnit "felt migrering" nedenfor).
Association
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
entryuuid | Uuid, der identificerer Association-objektet. | nej | varchar(64) | |
association_type | nej | varchar(32) | ||
source_association | id på source, hvis denne er en Association. | int(11) | ||
sourceuuid_documententry | Entryuuid på source, hvis denne er et DocumentEntry. | varchar(64) | ||
sourceuuid_folder | Entryuuid på source, hvis denne er en Folder. | varchar(64) | ||
sourceuuid_submissionset | Entryuuid på source, hvis denne er et SubmissionSet. | varchar(64) | ||
target_association | id på target, hvis denne er en Association. | int(11) | ||
targetuuid_documententry | Entryuuid på target, hvis denne er et DocumentEntry. | varchar(64) | ||
targetuuid_folder | Entryuuid på target, hvis denne er en Folder. | varchar(64) | ||
targetuuid_submissionset | Entryuuid på target, hvis denne er et SubmissionSet. | varchar(64) | ||
associationcontentid | Reference til række i associationcontent-tabellen. | nej | x | int(11) |
migration_pid | Link til oprindelig migreringsdata - default 0 | nej | int(11) |
AssociationContent
...
LogicalUuid på DocumentEntry-objektet. Identificerer DocumentEntry-objektet på tværs af versioner.
For version 1 er EntryUuid og LogicalUuid identiske, for andre versioner er de forskellige.
...
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
LogicalUuid på Folder-objektet. Identificerer Folder-objektet på tværs af versioner.
For version 1 er EntryUuid og LogicalUuid identiske, for andre versioner er de forskellige.
xml | Det rå objekt i ebxml 3.0-format. | blob |
Author (documententry_author)
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
documententry_entryuuid | Reference til række i documententry-tabellen. | nej | int( |
64) |
family_name | Efternavn fra Author-strukturen. | nej | varchar( |
64) |
given_ |
name |
Fornavn fra Author-strukturen. |
varchar( |
64) |
further_given_ |
names | Øvrige fornavne fra Author- |
strukturen. |
varchar( |
64) |
...
Code (documententry_eventcode og documententry_confidentialitycode)
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
documententry_entryuuid | Reference til række i documententry-tabellen. | nej | int(64) | |
codename | Name-delen af Code-strukturen. | nej | varchar(64) | |
schemename | Scheme-delen af Code-strukturen. | nej | varchar(64) |
DocumentEntryContent
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
xml | Det rå objekt i ebxml 3.0-format. | blob |
...
DocumentEntries
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) | documententry_id | |||||||||
entryuuid | EntryUuid på DocumentEntry-objektet. Unik identifikation af den versionen af objektet | Reference til række i documententry-tabellen. | nej | x | intvarchar( | 1164) | reference_id | Nøgle på ReferenceId|||||||
logicaluuid | LogicalUuid på DocumentEntry-objektet. Identificerer DocumentEntry-objektet på tværs af versioner. For version 1 er EntryUuid og LogicalUuid identiske, for andre versioner er de forskellige | 'et. | nej | varchar(64) | assigningauthority_id | Id fra AssigningAuthority-strukturen. | varchar(64) | assigningauthority_type | Type fra AssigningAuthority-strukturen. | varchar(64) | assigningauthority_namespace_id | Namespaceid fra AssigningAuthority-strukturen. | typecode | TypeCode på ReferenceId'et|
version | Versionsnummer på DocumentEntry-objektet. Antager værdierne 1, 2, 3, ... | nej | int(11) | |||||||||||
patientid | Id-delen af PatientId-strukturen. | nej | varchar( | 6432) | ||||||||||
patientid_ | idId fra HomeCommunityIdassigningauthorityid | AssigningAuthorityId-delen af PatientId-strukturen. | nej | varchar( | 6432) | homecommunityid|||||||||
patientid_ | typeassigningauthoritytype | AssigningAuthorityType-delen af PatientId | Type fra HomeCommunityId-strukturen. | nej | varchar( | 64)
OpenEHealth frameworket er blevet opgraderet fra version 3.0.4 til 3.6.2. I den forbindelse er referenceId entiteten ændret. De 2 homecommunityid felter id og type er fjernet, og et nyt assigningauthority felt "namespaceid" er kommet til.
Da migrationen modulet kører på den gamle version af frameworket, fjernes felterne ikke fra databasen pt. Efter produktionsmigrering skal databasen tjekkes for data i de 2 homecommunity felter. Er der ikke data kan de fjernes.
SubmissionSet
16) | ||||
availabilitystatus | Objektets status (Approved, Deprecated, etc.) | nej | varchar(64) | |
documententrytype | Objektets typpe (Stable eller OnDemand) | nej | varchar(64) | |
uniqueid | UniqueId på objektet (NB: ikke nødvendigvis unik for DocumentEntries). | nej | varchar(128) | |
classcode_codename | Navn for ClassCode. | nej | varchar(64) | |
classcode_schemename | Scheme for ClassCode |
. | nej | varchar( |
64) |
typecode_ |
codename | Navn for TypeCode |
. | nej | varchar( |
64) |
typecode_ |
schemename | Scheme for TypeCode |
. | nej | varchar( |
64) |
practicesettingcode_codename | Navn for PracticeSettingCode. | nej |
varchar(64) |
practicesettingcode_ |
schemename | Scheme for PracticeSettingCode. | nej |
varchar( |
64) |
SubmissionSetContent
...
Migrering
Migrering af data fra OpenText Registry til NXRG skal sikre, at al data, der ligger i OpenText Registry overføres til NXRG på en måde, så data bevares: Det vil sige, at de data, der kan udsøges gennem NXRGs snitflader svarer 1:1 til det data, der kan udsøges gennem OpenText Registrys snitflader.
Den interne datarepræsentation vil ændre sig fra OpenText Registry til NXRG, men det logiske data skal bevares.
Valg af migreringsstrategi
Der har i forbindelsen med migreringen været arbejdet med nedenstående diagram for at komme frem til en migreringsstrategi.
Diagrammet viser de forskellige niveauer, som data kan eksporteres henholdsvis importeres på. De forskellige muligheder er blevet diskuteret på workshops, og fravalg og tilvalg er dokumenteret på diagrammet.
Konklusionen på analysearbejdet er således, at:
- Data eksporteres fra OpenText Registry på xDB niveau: Driften kan trække en liste over alle objekter i xDB og hvornår disse senest er ændret. Listen kan anvendes til at lave eksport af de (ændrede) objekter til en relationel database (MariaDB).
- Data importeres i NXRG fra kommandolinje tool: Importen af data skal operere på den relationelle migreringsdatabase, som blev nævnt under eksport. Ved at køre et kommandolinje tool er det muligt at transformere data i migreringsdatabasen til SQL scripts under hensyntagen til NXRGs datamodel. Disse scripts kan derefter (bulk) indlæses i NXRGs database (også MariaDB)
Der har været et ønske om at kunne lave løbende (delta)migreringer af OpenText data til NXRG. Dette ønske bunder i, at der i produktion i dag er ca 11 mio XDS objekter (submissionsets med associations samt document entries) i OpenText Registry databasen.
Selv med et effektitivt migreringstool, så vil det tage tid (< 5 dage) at migrere al data. Hvis en migreringsstrategi kræver et servicevindue, så vil dokumentdeling på NSP være utilgængeligt i flere dage, hvilket er blevet vurderet til problematisk.
Da driften kan trække liste over nye/opdaterede data i OpenText Registry (se pkt 1 ovenfor) er det muligt at lave en trinvis migrering. Dette betyder yderligere, at det bliver muligt at komme i gang med migreringen på et tidligere tidspunkt (da det kan foretages uden at der skal meldes servicevinduer ud).
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Migreringsprocessen er markeret med blå i diagrammet ovenfor. Det er tanken at bevare Migreringsdatabasen efterfølgende som en backup for OpenText Registry data. Når licensen udløber for xDB databasen, så vil migreringsdatabasen være masterdata (i tilfælde af, at man skulle opdage fejl i import til NXRG efterfølgende).
Der skal laves verifikation af migreringsprocessen - både en kvantitativ verifikation og en kvalitativ verifikation. Denne del af processen er beskrevet nedenfor.
Tabelformat for migreringsdata
Dataene fra OpenText registry'et i en MariaDB-database, som deles mellem eksport- og import-jobbet. Databasen indeholder to tabeller, contents og status. Tabellernes indhold beskrives nedenfor. Man kan hente et eksempel-datasæt på
Jira | ||||||
---|---|---|---|---|---|---|
|
Contents
...
Status
...
XML-format
OpenText registry'et eksporterer sine data i et xml-format, som der ind til videre ikke er tilvejebragt noget schema for. Nedenfor kan man se et eksempel på et submissionset og et tilhørende document i dette format.
Code Block |
---|
<?xml version="1.0"?>
<submissionSet id="urn:uuid:255d0bef-db11-482d-b2bd-dca0053d8045">
<xds:submissionSet xmlns:xds="http://www.openehealth.org/ipf/xds">
<entryUuid>urn:uuid:255d0bef-db11-482d-b2bd-dca0053d8045</entryUuid>
<logicalUuid>urn:uuid:255d0bef-db11-482d-b2bd-dca0053d8045</logicalUuid>
<version>
<versionName>1</versionName>
</version>
<uniqueId>7020798514690154282.7024117544796833076.1568187071790</uniqueId>
<patientId extension="2606481234" root="1.2.208.176.1.2"/>
<availabilityStatus>Approved</availabilityStatus>
<title language="en-US">769a1dbf-2c73-4cca-98b9-9c045231f309</title>
<limitedMetadata>false</limitedMetadata>
<sourceId>7020798514690154282.7024117544796833076.1568187071790</sourceId>
<submissionTime>2013-02-17T08:15:00Z</submissionTime>
<author>
<authorPerson>
<id/>
<name>
<given>M</given>
<family>Madsen</family>
</name>
</authorPerson>
<authorInstitution>
<idNumber>77668685</idNumber>
<assigningAuthority universalId="1.2.208.176.1.2" universalIdType="ISO"/>
<name>Odense Universitetshospital, Odense</name>
</authorInstitution>
</author>
<contentTypeCode code="NscContentType" codeSystemName="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" displayName="NscContentType"/>
</xds:submissionSet>
<xds:associations xmlns:xds="http://www.openehealth.org/ipf/xds">
<xds:association>
<entryUuid>urn:uuid:1b1d1134-c1d9-4a88-add6-3d580aadfed7</entryUuid>
<sourceUuid>urn:uuid:255d0bef-db11-482d-b2bd-dca0053d8045</sourceUuid>
<targetUuid>urn:uuid:5e6ac9ef-4633-46ea-96b1-786a948e7bb6</targetUuid>
<associationType>HasMember</associationType>
<label>Original</label>
<originalStatus>Approved</originalStatus>
<newStatus>Approved</newStatus>
<availabilityStatus>Approved</availabilityStatus>
</xds:association>
</xds:associations>
</submissionSet> |
Code Block |
---|
<?xml version="1.0"?>
<document id="urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906">
<xds:documentEntry xmlns:xds="http://www.openehealth.org/ipf/xds">
<entryUuid>urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906</entryUuid>
<logicalUuid>urn:uuid:da51d7ce-1a18-48ca-ba5f-03b0be78b906</logicalUuid>
<version>
<versionName>1</versionName>
</version>
<uniqueId>437f8b60-9563-11e3-a5e2-0800200c7020^1.2.208.184</uniqueId>
<patientId extension="2606481234" root="1.2.208.176.1.2"/>
<availabilityStatus>Approved</availabilityStatus>
<title language="en-US">Hjemmemonitorering for 2606481234</title>
<limitedMetadata>false</limitedMetadata>
<sourcePatientId extension="2606481234" root="1.2.208.176.1.2"/>
<sourcePatientInfo>
<name>
<given>Janus</given>
<family>Berggren</family>
</name>
<gender>M</gender>
<birthTime>1948-06-26T00:00:00Z</birthTime>
</sourcePatientInfo>
<creationTime>2013-02-17T08:15:00Z</creationTime>
<author>
<authorPerson>
<id/>
<name>
<given>M</given>
<family>Madsen</family>
</name>
</authorPerson>
<authorInstitution>
<idNumber>77668685</idNumber>
<assigningAuthority universalId="1.2.208.176.1.2" universalIdType="ISO"/>
<name>Odense Universitetshospital, Odense</name>
</authorInstitution>
</author>
<legalAuthenticator>
<id/>
<name>
<given>Lars</given>
<family>Olsen</family>
</name>
</legalAuthenticator>
<serviceStartTime>2013-02-11T08:11:00Z</serviceStartTime>
<serviceStopTime>2013-02-16T10:14:00Z</serviceStopTime>
<classCode code="001" codeSystemName="1.2.208.184.100.9" displayName="Clinical report"/>
<confidentialityCode code="N" codeSystemName="2.16.840.1.113883.5.25" displayName="N"/>
<eventCode code="NPU03011" codeSystemName="1.2.208.176.2.1" displayName="O2 sat.;Hb(aB)"/>
<eventCode code="MCS88016" codeSystemName="1.2.208.184.100.8" displayName="FVC"/>
<formatCode code="urn:ad:dk:medcom:appointmentsummary:full" codeSystemName="1.2.208.184.100.10" displayName="DK Appointment Summary Document schema"/>
<healthcareFacilityTypeCode code="550621000005101" codeSystemName="2.16.840.1.113883.6.96" displayName="hjemmesygepleje"/>
<languageCode>da-DK</languageCode>
<practiceSettingCode code="419192003" codeSystemName="2.16.840.1.113883.6.96" displayName="intern medicin"/>
<typeCode code="53576-5" codeSystemName="2.16.840.1.113883.6.1" displayName="Personal Health Monitoring Report"/>
<repositoryUniqueId>1.2.208.176.43210.8.10.11</repositoryUniqueId>
<mimeType>text/xml</mimeType>
<size>27302</size>
<hash>da39a3ee5e6b4b0d3255bfef95601890afd80709</hash>
<type>stable</type>
</xds:documentEntry>
</document>
|
Overordnet struktur
Migreringen består af to faser:
1. Overførsel af data fra opentext-databasen SQL scripts.
2. Indlæsning af SQL scripts i nxrg-databasen.
Denne stuktur er valgt af følgende grunde:
- Mulighed for at få den endelige indlæsning til at køre hurtigt.
- Mulighed for håndtering af deltaer: Hvis f.eks. et allerede konverteret DocumentEntry bliver deprecated, så skal migreringen kunne håndtere dette.
Fase 1 er implementeret som en java kommandolinje-applikation. Fase 2 består af indlæsning af genererede scripts i navngivne rækkefølge.
Findinds i løbet af migreringsprocessen
uniqueIds er ikke unikke på SubmissionSets fra opentext-databasen
Det er blevet fundet, at der optræder dubletter i uniqueid på submissionsets i data trukket ud fra test1 (se detaljer på
Jira | ||||||
---|---|---|---|---|---|---|
|
- Tillader migrering af ikke unikke unique-ids for submissionsets
- Fortsat kræver at submissionsets modtaget gennem ITI-42, ITI-57 og ITI-62 har et unikt unique id.
Det er ikke helt klart, om de sammenfaldende id'er er en egenskab, som udelukkende begrænser sig til testsystemet. Følgende SQL kan fremfinde de række, hvor der er problemer med ikke-unikke uniqueids:
Code Block | ||||
---|---|---|---|---|
| ||||
select * from submissionsets where migration_uniqueid_fix > 0; |
Hvis problemet ikke eksisterer i produktion, så kan kolonnen 'migration_uniqueid_fix' fjernes efterfølgende (de testdata på testsystemerne, der giver problemer kan så enten slettes eller id'et kan opdateres til noget andet).
Fase 1
Migreringen fra OpenText til staging-databasen foregår ved at behandle hver række i status-tabellen i opentext-databasen, og gøre følgende:
- Validere at xml-strukturen ser ud som forventet.
- Parse xml-strukturen, og mappe den til objekter i Openehealth core-modellen.
- Serialisere objekterne, og persistere dem sammen emd søgbare felter. Til dette formål genbruges datalaget fra NXRG.
Fejl logges til migreringsloggen til senere analyse. Efter endt behandling skrives til DocImportState-feltet i opentext-databasen, om behandlingen lykkedes eller ej.
Fase 2
Overførslen af data fra staging-databasen til nxrg-databasen foregår ved brug af select into/load data-metoden, som er beskrevet i mariadb-dokumentationen: https://mariadb.com/kb/en/how-to-quickly-insert-data-into-mariadb/.
Verifikation/validering af migreringen
I forbindelse med migreringen vil det give mening at definere et sæt af validerings- og verifikationsmekanismer, som vil kunne øge tilliden til, at migreringen er forløbet korrekt. I de kommende afsnit beskrives de validerings- og verifikationsmekanismer, som anvendes i NXRG migreringen.
Det er tanken, at verifikation kan køres både efter initiel load og efterfølgende efter hver deltamigrering, så vi får løbende overblik overblik over korrektheden.
Validering
Efter migreringen er tilendebragt kan der trækkes en række metrikker ud af hhv xDB og NXRGs mariadb baserede databasesetup.
De følgende metrikker foreslås. Det skal afklares, om det kan lade sig gøre at trække disse ud af både xDB og NXRG.
...
creationtime | Oprettelsestidspunkt som angivet af anvenderen. | datetime(6) | ||
servicestarttime | Starttidspunkt som angivet af anvenderen. | datetime(6) | ||
servicestoptime | Sluttidspunkt som angivet af anvenderen. | datetime(6) | ||
healthcarefacilitytypecode_codename | Navn for HealthcareFacilityTypeCode. | nej | varchar(64) | |
healthcarefacilitytypecode_schemename | Scheme for HealthcareFacilityTypeCode. | nej | varchar(64) | |
formatcode_codename | Navn for FormatCode. | nej | varchar(64) | |
formatcode_schemename | Scheme for FormatCode. | nej | varchar(64) | |
documententrycontentid | Reference til række i documententrycontent-tabellen. | nej | x | int(11) |
migration_pid | Link til oprindelig migreringsdata - default 0 | nej | int(11) | |
creation_time | Teknisk timestamp, hvornår rækken blev oprettet i databasen | nej | date(6) | |
last_update_time | Teknisk timestamp, hvornår rækken blev opdateret i databasen | nej | date(6) | |
deletetrigger_time | Persistent timestamp, der fremkommer som COALESCE(servicestarttime, creation_time) og anvendes af slettejobbet til at afgøre, hvor "gammelt" et dokument er | nej | date(6) |
Folder
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
entryuuid | EntryUuid på Folder-objektet. Unik identifikation af den versionen af objektet. | nej | x | varchar(64) |
logicaluuid | LogicalUuid på Folder-objektet. Identificerer Folder-objektet på tværs af versioner. For version 1 er EntryUuid og LogicalUuid identiske, for andre versioner er de forskellige. | nej | varchar(64) | |
version | Versionsnummer på Folder-objektet. Antager værdierne 1, 2, 3, ... | nej | int(11) | |
patientid | Id-delen af PatientId-strukturen. | nej | varchar(32) | |
patientid_assigningauthorityid | AssigningAuthorityId-delen af PatientId-strukturen. | nej | varchar(32) | |
patientid_assigningauthoritytype | AssigningAuthorityType-delen af PatientId-strukturen. | nej | varchar(16) | |
availabilitystatus | Objektets status (Approved, Deprecated, etc.) | nej | varchar(64) | |
uniqueid | UniqueId på objektet (NB: ikke nødvendigvis unik for DocumentEntries). | nej | varchar(64) | |
lastupdatetime | Seneste opdateringstidspunkt for Folder-objektet. | nej | datetime(6) | |
foldercontentid | Reference til række i foldercontent-tabellen. | nej | x | int(11) |
FolderContent
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
xml | Det rå objekt i ebxml 3.0-format. | blob |
ReferenceId (documententry_referenceid)
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
documententry_entryuuid | Reference til række i documententry-tabellen. | nej | int(64) | |
reference_id | Nøgle på ReferenceId'et. | nej | varchar(64) | |
assigningauthority_id | Id fra AssigningAuthority-strukturen. | varchar(64) | ||
assigningauthority_type | Type fra AssigningAuthority-strukturen. | varchar(64) | ||
typecode | TypeCode på ReferenceId'et. | nej | varchar(64) | |
homecommunityid_id | Id fra HomeCommunityId-strukturen. | varchar(64) | ||
homecommunityid_type | Type fra HomeCommunityId-strukturen. | varchar(64) |
SubmissionSet
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
entryuuid | Uuid, der identificerer SubmissionSet-objektet. | nej | x | varchar(64) |
patientid | Id-delen af PatientId-strukturen. | nej | varchar(32) | |
patientid_assigningauthorityid | AssigningAuthorityId-delen af PatientId-strukturen. | nej | varchar(32) | |
patientid_assigningauthoritytype | AssigningAuthorityType-delen af PatientId-strukturen. | nej | varchar(16) | |
uniqueid | UniqueId på objektet. | nej | x | varchar(64) |
migration_uniqueid_fix | Sikring af uniqueness på migreringstidspunktet. Se afsnit nedenfor med findings. Default 0 | nej | int(11) | |
submissionsetcontentid | Reference til række i submissionsetcontent-tabellen. | nej | x | int(11) |
SubmissionSetContent
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
xml | Det rå objekt i ebxml 3.0-format. | blob |
Deleted_Documententries
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
entryuuid | EntryUuid på slettet DocumentEntry. | nej | varchar(64) | |
uniqueid | UniqueId på slettet DocumentEntry. | nej | varchar(64) | |
deletion_status | Status på sletningen. Kan være DELETED_FROM_REGISTRY, DELETED_FROM_REPOSITORY, DELETION_FROM_REPOSITORY_FAILED. | nej | varchar(64) | |
deletion_attempts | Antal gange hvor sletning fra repository er gået galt. | nej | int(11) | |
creation_time | Tidspunkt for indsættelse af rækken. | nej | datetime(6) |
Fieldmigrationstatus
Denne tabel, skal indeholde en række for hver type felt migrering, som skal laves. Rækkes indsættes i forbindelse med at database scriptene bliver kørt i forbindelse med opgraderinger. Og opdateres af "felt migrerings servicen".
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
migrationid | en logisk nøgle, der siger noget om hvad der migreres. F.eks. 'documententry-repositoryid-add'. | nej | varchar(64) | |
progressid | peger på et id i documentEntries. Er 0 sålænge migreringen ikke er startet. Når en migrering er kørt, vil progressid pege på den sidste documentEntries, der er migreret i kørslen. Når progressid = targetid, er der ikke mere at migrere. | nej | int(11) | |
targetid | peger på det sidste id i documentEntries der skal migreres. Denne værdi sættes når rækken indsættes og ændres ikke efterfølgende. | nej | int(11) | |
migration_start_time | tidspunkt for, hvornår den første kørsel af migreringen er startet | datetime(6) | ||
migration_end_time | tidspunkt for, hvornår migreringen er afsluttet (da progressid ramte targetid) | datetime(6) | ||
last_update_time | tidspunkt for, hvornår rækken senest er opdateret | datetime(6) |
Alle tider er tider er databasens tidszone.
Documententries_status90_deletion
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
status90_deletion_date | Dato for sletning af dokumenter for personer med status 90 | nej | datetime(6) | |
deletion_count | Antal dokumenter der er slettet den pågældende dato | nej | int(11) | |
creation_time | Tidspunkt for indsættelse af rækken. | nej | datetime(6) | |
last_update_time | tidspunkt for, hvornår rækken senest er opdateret | datetime(6) |
Nas integration tabeller
Integrationen til NAS har 2 tabeller i databasen:
notification_configuration:
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
classcode_codename | Navn for ClassCode. | nej | varchar(64) | |
classcode_schemename | Scheme for ClassCode. | nej | varchar(64) | |
typecode_codename | Navn for TypeCode. | nej | varchar(64) | |
typecode_schemename | Scheme for TypeCode. | nej | varchar(64) | |
formatcode_codename | Navn for FormatCode. | nej | varchar(64) | |
formatcode_schemename | Scheme for Formatcode. | nej | varchar(64) | |
topic | Den topic, som der sendes til på NAS | nej | varchar(128) | |
notification_type | Notifikationens type. Skal være defineret i NXRG logik, sådan at den kendes i respektiv dao klasse og Notifications jobbet. | nej | varchar(128) | |
creation_time | Tidspunkt for indsættelse af rækken. | datetime(6) |
unsent_notifications:
Feltnavn | Beskrivelse | Optional | Unik nøgle | Datatype |
---|---|---|---|---|
id | Intern, unik nøgle. | nej | x | int(11) |
uuid | Unik nøgle | nej | x | varchar(64) |
patient_id | CPR nummer som notifikationen drejer sig om | nej | varchar(64) | |
created_date | Dato og tid for hvornår notifikationen blev skabt | nej | VARCHAR(50) | |
topic | Den topic, som der sendes til på NAS | nej | varchar(128) | |
notification_type | Notifikationens type. Skal være defineret i NXRG logik, sådan at den kendes i respektiv dao klasse og Notifications jobbet. | nej | varchar(128) |
Migrering af data
Den oprindelige data migrering fra openText registry er ikke længere aktuel, og indholdet er flyttet til "Yderligere dokumentation - Migration"
Felt migrering
På tidspunktet for NXRG tilblivelse blev der udvalgt en række felter fra kaldets metadata (XMl baseret RIM format), som var interessante som søgbare felter. Disse felter, gemmes som selvstændige felter i tabeller som documententries og referenceid. Der opstår siden behov for at få flere af disse felter trukket ud af XML formatet. Dvs. der i princippet skal køres en migrering af eksisterende metadata for at trække disse felter ud. Dette er lavet som en selvstændig service. Source koden ligger sammen med resten af NXRG, men servicen starter op selvstændig og aktiveres ved at tilgå et specifik endpoint. Detaljerne er beskrevet i "NXRG - driftvejledning til felt migrering".
Gliffy Diagram | ||||
---|---|---|---|---|
|
Som ovenstående figur viser, består felt migreringen af 3 trin:
- udvidelse af databasemodel. Her tilføjes det søgbare felt databasen og NXRG justeres sådan at nye dokumentregistreringer vil gemme feltet, som et søgbart felt.
- migrering af data. Denne kan foregå af flere omgange (batch) da kørslen kan være tidskrævende. Servicen konfigureres med en batch størrelse, som det antal dokumenter, der håndteres i en enkelt kørsel.
- anvendelse af det søgbare felt. Når alt data er migreret kan det nye felt tages i anvendelse. Dvs først her kan ny funktionatlitet, der gør brug af feltet, udvikles
...
Der er et issue omkring, hvornår valideringen kører, hvis der tikker ny data ind i xDB. Vi antager, at vi kan køre migrering-validering/verifikation-cyklen, uden at det eksisterende OpenText slettejob fjerner data fra xDB (det skal være slået fra). I udtrækket fra xDB er der styr på en skæringsdato, som kan anvendes til at begrænse tælle-queries mod xDB opadtil, hvorfor resultaterne mellem NXRG og xDB ventes at være ens - både efter første migrering og efterfølgende efter deltaerne.
Vi forventer at antallene i 7, 9 og 5 er ens.
Yderligere burde summen over tallene i hhv 2, 3, 4, 4.5 summerere til 1.
9.2 forventes af være 0, tjekkes for at sikre ugyldige associations
Verifikation
Udover valideringskontrollerne beskrevet ovenfor giver det mening, at det undersøges, om NXRG svarer "det samme" som OpenText registry givet at de mødes af de samme input (søgninger).
Det foreslås derfor, at der foretages en ITI-18 søgning (søger på alle documententries på en række af cprnumre). Der kan tages udgangspunkt i det, der allerede er udviklet i NXRG i forbindelse med integrationstesten.
Verifikationstoolet laver den samme forespørgsel mod NXRG hhv OpenText Registry og sammenligner derefter svaret på følgende måde:
- Antallet af documententries og disses id'er skal være ens, hvis den samme query udføres mod NXRG og OpenText Registry
- De enkelte documententries i de to responses skal være ens (men der er ikke krav til, at de kommer ud i samme rækkefølge).
...
- .