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
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.
...
* 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:
...
NXRG er 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.
...
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:
...
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: Afsnit 3.18.4 (Se ITI TF-2b).
- ITI-42: Afsnit 3.42.4 (Se ITI TF-2b).
- ITI-57: Afsnit 3.57.4 (Se ITI TF-Metadata).
- ITI-61: 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.
...
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:
...
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.
...
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).
...
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.
...
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:
...
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.
...
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.
...
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
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 |
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) |
entryuuid | EntryUuid på DocumentEntry-objektet. Unik identifikation af den versionen af objektet. | nej | x | varchar(64) |
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. | nej | varchar(64) | |
version | Versionsnummer på DocumentEntry-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) | |
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) | |
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".
...
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) |
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".
...