Version 0.8, 2019-07-12
Indhold
1 Formål
2 Arkitekturoverblik
2.1 BRS-Frontend
2.2 BRS-Backend
3 Logisk arkitektur
3.1 Webservices
3.2 Batchjobs i Backoffice
3.3 Fælles valideringsbibliotek
4 Flowchart
5 Fysisk datamodel
5.1 Datamodel for opfølgningsdatabaserne (followup)
5.1.1 Opfølgningstabel på dNSP og cNSP (brs2_followup)
5.1.2 Opfølgningstabel i Backoffice (brs2_treatmentrelationfollowup)
5.2 Datamodel for register- og notifikationsdatabasen (register_notifications)
5.2.1 Landspatientregister (LPR)
5.2.2 Sygesikringsregister (SSR)
5.2.3 Henvisningshotellet (Refhost)
5.2.4 Notifikationstabel (brs2_notification)
5.3 Datamodel for data hentet fra Stamdata
6 Valideringsregler for behandlingsrelationer
7 Teknologiarkitektur
8 Ændringslog
Dette dokument beskriver arkitekturen for Behandlignsrelationsservicen (BRS).
Der beskrives
Behandlingsrelationsservicen (BRS) udstillet på NSP er en service til kontrol af behandlingsrelationer. BRS tilbyder at løfte opgaven med at klassificere behandlingsrelationer imellem sundhedsfaglige personer og patienter, således at nationale serviceudbydere i sundhedsvæsenet lettere kan overholde lovkrav til kontrol af sundhedsfaglige personers adkomst til data og funktionalitet.
Da der ikke findes et decideret "behandlingsrelationsregister", er det nødvendigt at udlede viden om faktiske behandlingsrelationer ved opslag i nationale registre over handlinger, registreringer og relationer indenfor sundhedsvæsenet. Endvidere er der ofte en tidsmæssig forsinkelse i opsamling af de nødvendige informationer, og det er derfor nødvendigt at give adgang til funktionalitet og data på basis af ukomplette informationer, og efterfølgende foretage en opfølgende kontrol af den faktiske relation på et senere tidspunkt.
Opslag og opfølgninger varetages af BRS.
Hvis en serviceudbyder giver adgang til en bruger under forudsætning af at brugerens adkomst senere kan bekræftes, men det ikke sker, udsteder BRS en alarm, som serviceudbyderen kan agere på (en manuel opfølgning).
Systemet er opdelt i to dele "frontend" og "backend".
Frontend'en indeholder behandlingsrelationsservicen og notifikationsservicen, som er de webservices, der kaldes udefra, fra eksempelvis FMK. Herudover afvikles et job som løbende replikerer behandlingsrelationer, der er sat til opfølgning, til backend'en.
Frontend'en er installeret i dNSP-miljøerne (decentral National Service Platform), samt til i cNSP-miljøet (central National Service Platform).
Backend'en indeholder en webservice, som modtager de data, der replikeres fra frontend'en. Herudover afvikles der et batchjob, der foretager løbende opfølgning på, om der er opnået evidens for de behandlingsrelationer, der er sat til opfølgning, og opretter alarm-notifikationer i de tilfælde, hvor evidens ikke blev opnået indenfor tidsfristen. Endelig afvikles et andet bachjob, der løbende sletter gamle notifikationer.
Backend'en er installeret i NSP's Backoffice-miljø (tidligere benævnt DoDi).
I Backoffice opsamles data fra følgende kilderegistre:
Data indsættes i de samme MySQL databaser, som BRS anvender, men det foretages i praksis af separate stamdata-importere.
Disse data, samt de notifikationer, der er oprettet af opføgningsjobbet, replikeres løbende til NSP-miljøerne, så data er tilgængelige for frontend'en. Denne replikering foretages i praksis som MySQL-databasereplikering.
På NSP-miljøerne udstilles følgende webservices:
Behandlingsrelationservice (BRS):
Servicen modtager en forespørgsel på en behandler (identificeret som person+sted), samt en patient (identificeret ved CPR), og skal afgøre hvilke kategorier af relationer der er mellem behandleren og patienten.
Der angives ligeledes et succeskriterie i form af et sæt af kategorier, der antages at være acceptable behandlingsrelationer. Skulle der ikke være en acceptabel behandlingsrelation, kan det afføde en opfølgning. For at understøtte dette, kan kalderen angive et sæt af kategorier der skal afføde en opfølgning. Dette kan også være sat til alle relationer.
Notifikationsservice:
Servicen vil returnere alle notifikationer, som er adresseret til kalderen. Notifikationer er fortløbende nummererede, og kalderen kan angive et offset, der sikrer at kun de nyeste notifikationer returneres. Servicen sletter alarmer efter et centralt konfigurerbart tidsinterval. Hvis man ikke angiver offset kan man risikere at modtage de samme alarmer flere gange.
De ovennævnte services udstilles via Den Gode Webservice (DGWS 1.0.1), og kan kun kaldes af systemer der bruger et System-IDKort udstedt til forhåndsgodkendte CVR numre. IDKort skal være udstedt af SOSI-STS.
Backoffice indeholder to batchjobs der begge afvikles periodisk. Schedule for jobs kan konfigureres vha. en cron expression.
Relationsopfølgning:
De gemte opfølgninger kontrolleres op imod valideringsbiblioteket for at undersøge om der er opstået relationer der giver anledning til at slette en opfølgning. Hvis en opfølgning ikke har opnået den krævede relationskategori inden dens udløb oprettes en alarm i notifikationsdatabasen via GOS.
Oprydning:
Alarm-notifikationer replikeres til frontend i NSP-miljøerne, hvor de kan hentes med notifikationsservicen. Dette sletter dog ikke notifikationerne, så for at undgå at der blot bliver flere og flere, er der på et oprydningsjob, som løbende sletter notifikationer, som er blevet tilpas gamle.
Sletningen replikeres, så data også slettes fra de øvrige miljøer.
Valideringsbiblioteker har adgang til data fra en række databaser, deriblandt landspatientregisteret og sygesikringsregisteret, for at kunne udlede om en behandlingsrelation er til stede. Valideringsbiblioteket tilgås af behandlingsrelationservicen i dNSP/cNSP-miljøerne samt relationsopfølgningsjobbet i Backoffice miljøet.
Valideringsbiblioteket er implementeret som en fælles kodebase, der deles af front- og backend modulerne.
Nedenfor er der et flowchart, for det overordnede flow i systemet.
Der er to typer databaser i datamodellen:
Tabellerne på de to typer databaser er beskrevet i det følgende.
Opfølgningstabellen indeholder behandlingsrelationer, som er modtaget af behandlingsrelationsservicen, og som er sat til opfølgning, idet der ikke umiddelbart kunne opnås tilstrækkelig evidens for relationen i forhold til evidenskilderne.
Tabellen udgør en form for kø. Replikeringsjobbet læser fra denne og sender data til backend'en, hvorefter data slettes fra tabellen.
Navn | Type | Beskrivelse |
---|---|---|
Pk | bigint, auto_increment | Primær nøgle |
queryableCvr | char(8) | CVR-nummer |
externalReferenceId | varchar(50) | Id i kaldende system |
Uid | varchar(36) | Unik nøgle i systemet |
docorOrganisation | varchar(7) | Ydernummer for organisation |
hospitalOrganisation | varchar(7) | SKS kode for sygehus/afdeling |
ean | varchar(20) | EAN nummer for organisation |
sor | bigint | SOR nummer for organisation |
patientCpr | char(10) | Patientens CPR-nummer |
healthProfessionalCpr | char(10) | Behandlers CPR-nummer |
relationLookupStart | datetime | Starttidspunkt for relation til patient |
relationLookupEnd | datetime | Sluttidspunkt for relation til patient |
timeLimit | datetime | Tidsfrist for opnåelse af relation inden alarm genereres |
acceptableRelations | varchar(20) | Acceptable evidensniveauer, kommasepareret |
followupRelations | varchar(20) | Evidensniveauer, der giver anledning til opfølgning |
authorisationIdentifier | varchar(20) | Autorisations-id |
serviceProviderName | varchar(50) | Navn på kaldende system |
serviceProviderVersion | varchar(20) | Version på kaldende version |
serviceProviderVendor | varchar(50) | Leverandør for kaldende version |
created | datetime | Tidspunkt for oprettelse af record |
errorCount | int | Antal gange record er forsøgt replikeret til backend |
nextSync | datetime | Tidspunkt for næste forsøg på replikering |
CVR-nummeret bestemmer hvem der har adgang til eventuelle notifikationer. uid benyttes som identifikation af rækker over hele systemet, på tværs af NSP-miljøer. Grunden til at pk ikke kan benyttes er, at den ikke er unik på tværs af NSP'erne.
Opfølgningstabellen indeholder behandlingsrelationer, som er sat til opfølgning, og er blevet overført til backend'en. Data ligger i denne tabel så længe der ikke er opnået evidens for relationen, og tidsfristen ikke er overskredet.
Navn | Type | Beskrivelse |
---|---|---|
serialNumber | bigint, auto_increment | Primær nøgle |
nextCheck | datetime | Tidspunkt for næste opfølgning |
queryableCvr | char(8) | CVR-nummer |
externalReferenceId | varchar(50) | Id i kaldende system |
uid | varchar(36) | Unik nøgle i systemet |
docorOrganisation | varchar(7) | Ydernummer for organisation |
hospitalOrganisation | varchar(7) | SKS kode for sygehus/afdeling |
ean | varchar(20) | EAN nummer for organisation |
sor | bigint | SOR nummer for organisation |
patientCpr | char(10) | Patientens CPR-nummer |
healthProfessionalCpr | char(10) | Behandlers CPR-nummer |
relationLookupStart | datetime | Starttidspunkt for relation til patient |
relationLookupEnd | datetime | Sluttidspunkt for relation til patient |
timeLimit | datetime | Tidsfrist for opnåelse af relation inden alarm genereres |
acceptableRelations | varchar(20) | Acceptable evidensniveauer, kommasepareret |
followupRelations | varchar(20) | Evidensniveauer, der giver anledning til opfølgning |
authorisationIdentifier | varchar(20) | Autorisations-id |
serviceProviderName | varchar(50) | Navn på kaldende system |
serviceProviderVersion | varchar(20) | Version på kaldende version |
serviceProviderVendor | varchar(50) | Leverandør for kaldende version |
created | datetime | Tidspunkt for oprettelse af record |
Tidspunktet i nextCheck benyttes af opfølgningsjobbet til at vurdere om en opfølgning skal behandles på kørselstidspunktet.
Navn | Type | Beskrivelse |
---|---|---|
pk | bigint, auto_increment | Primære nøgle |
patientCpr | varchar(80) | SHA-1 hash |
admittedStart | datetime | |
admittedEnd | datetime | |
lprReference | varchar(40) | Fra inputdata – audit |
relationType | varchar(40) | Se kommentarer |
organisationIdentifier | varchar(7) | ydernummer eller SKS-kode |
Relationstypen kan antage værdierne "REFERRING_UNIT", "TREATMENT_UNIT" eller "DISCHARGED_TO_OWN_DOCTOR" svarende til om der er tale om en henvisende afdeling, en behandlingsafdeling eller om patienten er udskrevet til egen læge. Hvis patienten er udskrevet til egen læge skal feltet organisationIdentifier indeholde et ydernummer, ellers skal det indeholde et sks.
Følgende tabel benyttes til mapning fra input SKS-koder til SOR-koder:
Navn | Type | Beskrivelse |
---|---|---|
PID | bigint(20), auto_increment | Primær nøgle |
ValidFrom | datetime | Dato for hvornår rækken kan anvendes. Dette er en teknisk dato der benyttes i NSP Stamdatamodul og som ikke er relevant for anvendere. |
ValidTo | datetime | Dato for hvornår rækken bliver ugyldig at anvende. Dette er en teknisk dato der benyttes i NSP Stamdatamodul og som ikke er relevant for anvendere. |
ModifiedDate | datetime | Dette er en teknisk dato der benyttes i NSP Stamdatamodul og som ikke er relevant for anvendere. |
SorShakMapId | bigint(20) | Unik ID for mapningsrecord |
ShakId | varchar(7) | Shak-kode der mappes |
SorId | bigint(20) | SorId der mappes. Shak/Sor- Id'er medtages kun i gyldighedsperioder, med mapning. |
IsDirectSorShakMappning | tinyint(1) | True, hvis SHAK-koden er knyttet direkte til SOR-id I SOR. False, hvis SHAK-koden kommer fra en ovenliggende SOR-enhed. |
ShakIdsDirectSorId | bigint(20) | SOR-id for den enhed, som SHAK-koden er direkte knyttet til. Kun angivet, hvis der er en indirekte mappning mellem "ShakId" og "SorId". Indeholder null, hvis der er en direkte mappngin mellem "Shakid og SorId". |
FromDate | date | Mapping recorden er gældende fradato. Der er en ny record hver gang der enten er en ændring i SHAK eller SOR. Dvs, denne dato genereres ud fra SOR-fra-dato, SHAK-fra-dato eller nedarvede SOR-fra-datoer. |
ToDate | date | Mapping recorden gældende til-dato |
UpdatedAt | datetime | Tidspunkt for genereringen af mapnings recorden. |
SorType | varchar(2) | Tekstværdi for SORtype, enten IE, SI, OE |
SorEntityName | varchar(60) | SOR Enhedens navn |
SorEntityTypeId | bigint(20) | Teknisk nøgle for EntityType (SNOMED Concept Id) |
SorEntityTypeName | varchar(100) | Angiver hvilken type enheden har - fx privat, regional, tandlægepraksis, klinisk enhed, skadestue. Feltet kan indeholde enten en type af institutionsejer eller en type af sundhedsinstitution eller en type af organisatorisk enhed. |
SorFirstFromDate | date | Første dato hvorfra SOR enheden er gældende. |
SorFromDate | date | Fra dato for sidste ændring på SOR enheden. Hvis det er en ændring til en af attributterne på SOR enheden vil FromDate indeholde datoen for dagen efter ændringen til attributten. |
SorToDate | date | Situation 1: ændringer til SOR enhed og hvor SOR enhed ikke lukkes Dato for sidste dag hvor en række er aktiv, hvor der oprettes en ny række indeholdende SOR felter med nye værdier. ToDate i den nye række vil være null. Situation 2: SOR enhed lukkes Lukkedato for sidste dag hvor en SOR enhed er aktiv. Her findes der ikke nogen ny række, dvs. alle rækker tilknyttet SOR enhed har en dato i ToDate. |
SorUpdatedAt | datetime | Ændringstidspunkt for SORenhed |
SorParentSorId | bigint(20) | Sor-Id for hierarkisk forælder entitet. Null for SorType institutionsejer (IE) |
SorInstitutionOwnerSorId | bigint(20) | Sor-Id der angiver institutionsejer (IE), dvs. øverste niveau i SOR hierarkiet for den enhed |
SorInstitutionOwnerEntityName | varchar(60) | Angiver navnet på enhedens institutionsejer. Er altid udfyldt. |
SorInstitutionOwnerEntityTypeId | bigint(20) | Teknisk nøgle (SNOMED Concept Id) der angiver typen af institutionsejer. (OWNER_TYP E.SUNDTERM_ID i stedet for TYPE_CODE). |
SorInstitutionOwnerEntityTypeName | varchar(60) | Angiver hvilken type enheden har - enten privat, regional, kommunal, stat. |
SorHealthInstitutionSorId | bigint(20) | Sor-Id der angiver enhedens sundhedsinstitutio n, dvs. næstøverste niveau i SOR hierarkiet for den enhed. Er udfyldt for sortyperne SI og OE. Null hvis det er en IE sortype. |
SorHealthInstitutionEntityName | varchar(60) | Angiver navnet på enhedens sundhedsinstitution. Angives kun for organisatoriske enheder. |
SorHealthInstitutionEntityTypeId | bigint(20) | Teknisk Id (SNOMED Concept Id) der angiver typen af sundhedsinstitution. |
SorHealthInstitutionEntityTypeName | varchar(60) | Angiver typen af sundhedsinstitution fx tandlæge klinik, plejehjem, hospital |
SorEanLocationCodeState | varchar(20) | Angiver om lokationsnummer er nedarvet fra den hierarkiske mor. Kan være 'own', 'inherited' eller 'none'. Det er lige blevet ændret I SOR-opdaterwebservice, derfor denne ændring her. |
SorEanLocationCode | bigint(20) | SOR-enhedens lokationsnummer |
SorGeographicalLocalisationId | bigint(20) | Id for geografisk lokalitet til opslag i tabellen GeoLocalisation |
SorGeographicalLocalisationName | varchar(40) | Navn på den geografiske lokalitet |
SorVisitingAddressInheritanceIndicator | tinyint(1) | True hvis besøgsadressen er arvet via SORhierarkiet. Værdier: True/False. |
SorVisitingAddressStreetName | varchar(40) | Besøgsadressens vejnavn |
SorVisitingAddressStreetCode | varchar(4) | Besøgsadressens vejkode til vejregister i CPR |
SorVisitingAddressStreetBuildingId | varchar(4) | Besøgsadressens husnummer |
SorVisitingAddressFloorId | varchar(2) | Besøgsadressens etage |
SorVisitingAddressSuiteId | varchar(4) | Besøgsadressens dør eller til højre, til venstre eller midt for |
SorVisitingAddressAdditionalAddressInfo | varchar(40) | Besøgsadressens ekstra adresseinformation: Information der specificerer fysiske adresser. |
SorVisitingAddressPostCodeId | varchar(4) | Besøgsadressens postnummer |
SorVisitingAddressDistrictName | varchar(20) | Besøgsadressens postdistriktsnavn |
SorVisitingAddressMunicipalityCode | varchar(4) | Besøgsadressens kommunekode, der identificerer en kommune i myndighedstabellerne i Det Centrale Personregister |
SorVisitingAddressRegionCode | varchar(4) | Besøgsadressens regionskode |
SorVisitingAddressCountryIdCode | varchar(6) | Besøgsadressens landekode. Pt kun er muligt at oprette danske adresser |
SorVisitingAddressCoordETRS89z32NMeasure | decimal(10,3) | Besøgsadressens GPS-koordinater (ETRS89, north) |
SorVisitingAddressCoordETRS89z32EMeasure | decimal(10,3) | Besøgsadressens GPS-koordinater (ETRS89, east) |
SorPrioritizedEntitySpeciality1Id | bigint(20) | Teknisk (SNOMED Concept Id) nøgle til enhedens klinisk hovedspeciale |
SorPrioritizedEntitySpeciality1Name | varchar(254) | Angiver enhedens hovedspeciale |
SorPrioritizedEntitySpeciality2Id | bigint(20) | Teknisk (SNOMED Concept Id) nøgle til klinisk speciale |
SorPrioritizedEntitySpeciality2Name | varchar(254) | Angiver enhedens bispeciale |
SorPrioritizedEntitySpeciality3Id | bigint(20) | Teknisk (SNOMED Concept Id) nøgle til klinisk speciale |
SorPrioritizedEntitySpeciality3Name | varchar(254) | Angiver enhedens bispeciale |
SorPrioritizedEntitySpeciality4Id | bigint(20) | Teknisk (SNOMED Concept Id) nøgle til klinisk speciale |
SorPrioritizedEntitySpeciality4Name | varchar(254) | Angiver enhedens bispeciale |
SorPrioritizedEntitySpeciality5Id | bigint(20) | Teknisk (SNOMED Concept Id) nøgle til klinisk speciale |
SorPrioritizedEntitySpeciality5Name | varchar(254) | Angiver enhedens bispeciale |
SorPrioritizedEntitySpeciality6Id | bigint(20) | Teknisk (SNOMED Concept Id) nøgle til klinisk speciale |
SorPrioritizedEntitySpeciality6Name | varchar(254) | Angiver enhedens bispeciale |
SorPrioritizedEntitySpeciality7Id | bigint(20) | Teknisk (SNOMED Concept Id) nøgle til klinisk speciale |
SorPrioritizedEntitySpeciality7Name | varchar(254) | Angiver enhedens bispeciale |
SorPrioritizedEntitySpeciality8Id | bigint(20) | Teknisk (SNOMED Concept Id) nøgle til klinisk speciale |
SorPrioritizedEntitySpeciality8Name | varchar(254) | Angiver enhedens bispeciale |
ShakDateFrom | date | Gyldig fra dato for SHAK enhed |
ShakDateTo | date | Gyldig til dato for SHAK enhed |
ShakUpdatedAt | datetime | Ændringstid for SHAK enhed |
ShakName | varchar(60) | Shak Navn |
ShakInstitutionTypeId | varchar(3) | ID for SHAK institutiontype |
ShakInstitutionTypeName | varchar(254) | SHAK institutionstype fra "sygehusniveau" |
ShakOwnerTypeId | varchar(3) | ID for SHAK owner type |
ShakOwnerTypeName | varchar(254) | SHAK owner type, f.eks. regional, privat, statslig... |
ShakMainSpecialityId | bigint(20) | ID for SHAK hovedspeciale. |
ShakMainSpecialityName | varchar(254) | SHAK hovedspeciale |
ShakSpeciality1Id | bigint(20) | ID for Shak bispeciale 1 |
ShakSpeciality1Name | varchar(254) | SHAK bispeciale 1 |
ShakSpeciality2Id | bigint(20) | ID for Shak bispeciale 2 |
ShakSpeciality2Name | varchar(254) | SHAK bispeciale 2 |
ShakSpeciality3Id | bigint(20) | ID for Shak bispeciale 3 |
ShakSpeciality3Name | varchar(254) | SHAK bispeciale 3 |
UniqueCurrentKey | varchar(254) | Sammensat nøgle af ShakId og SorId |
Unreliable | varchar(2000) | Indikator for teknisk problem ifm. behandling |
Data fra LPR3 findes i en tabel med dette skema:
Navn | Type | Beskrivelse |
---|---|---|
pk | bigint, auto_increment | Primære nøgle |
patientCpr | varchar(80) | SHA-1 hash |
admittedStart | datetime | |
admittedEnd | datetime | |
lprReference | varchar(256) | Fra inputdata – audit |
relationType | varchar(40) | Se kommentarer |
sorKode | bigint(20) | SOR-kode |
Relationstypen kan antage følgende værdier:
Navn | Type | Beskrivelse |
---|---|---|
pk | bigint, auto_increment | Primære nøgle |
patientCpr | varchar(80) | SHA-1 hash |
doctorOrganisationIdentifier | varchar(6) | ydernummer |
admittedStart | datetime | |
admittedEnd | datetime | |
externalReference | varchar(40) | Fra inputdata - audit |
Navn | Type | Beskrivelse |
---|---|---|
pk | bigint, auto_increment | Primære nøgle |
healthProfessionCpr | varchar(80) | SHA-1 hash |
doctorOrganisationIdentifier | varchar(6) | ydernummer |
hospitalOrganisationIdentifier | varchar(7) | SKS-kode |
EAN | char(13) | EAN-nummer |
patientCpr | varchar(80) | SHA-1 hash |
referralStart | datetime | Henvisningens start |
referralEnd | datetime | |
refhostReference | varchar | Fra inputdata – audit |
Notifikationstabellen i Backoffice-miljøet indeholder alarm-notifikationer for behandlingsrelationer, som der ikke kunne findes evidens for indenfor tidsfristen.
Navn | Type | Beskrivelse |
---|---|---|
serialNumber | bigint, auto_increment | Primær nøgle |
externalReferenceId | varchar(50) | Id i kaldende system |
queryableCvr | char(8) | CVR-nummer |
creationTimestamp | datetime | Tidspunkt for oprettelse af record |
docorOrganisation | varchar(7) | Ydernummer for organisation |
hospitalOrganisation | varchar(7) | SKS kode for sygehus/afdeling |
ean | varchar(20) | EAN nummer for organisation |
sor | bigint | SOR nummer for organisation |
patientCpr | char(10) | Patientens CPR-nummer |
healthProfessionalCpr | char(10) | Behandlers CPR-nummer |
relationLookupStart | datetime | Starttidspunkt for relation til patient |
relationLookupEnd | datetime | Sluttidspunkt for relation til patient |
timeLimit | datetime | Tidsfrist for opnåelse af relation inden alarm genereres |
acceptableRelations | varchar(20) | Acceptable evidensniveauer, kommasepareret |
actualRelations | varchar(20) | Bedste relation opnået under opfølgning |
followupRelations | varchar(20) | Evidensniveauer, der giver anledning til opfølgning |
authorisationIdentifier | varchar(20) | Autorisations-id |
serviceProviderName | varchar(50) | Navn på kaldende system |
serviceProviderVersion | varchar(20) | Version på kaldende version |
serviceProviderVendor | varchar(50) | Leverandør for kaldende version |
uid | varchar(36) | Unik nøgle i systemet |
Det eksterne referenceid svarer til den id der blev modtaget i den oprindelige opsamlingsforespørgsel. CVR-nummeret bestemmer hvem der har adgang til notifikationen. Den unikke nøgle svarer til den unikke nøgle på opsamlingsforespørgselstabellen på NSP.
Behandlingsrelationsservicen benytter data udstillet af Stamdatamodulet. Det drejer sig om tabellen AssignedDoctor der dækker registret "Sikrede". Dokumentationen af denne tabel forefindes i dokumentationen for Stamdata.
I dokumentet "Behandlingsrelationsregler" findes en liste af valideringsregler for de enkelte kildedataregistre. Der henvises til dette dokument for yderligere detaljer.
Der henvises til NSP-dokumentationen for information vedrørende den overordnede arkitektur og omkringliggende komponenter.
Komponenter og services beskrevet her følger de overordnede retningslinier og krav udstukket af NSP-operatøren, herunder:
Version | Dato | Ændring | Ansvarlig |
---|---|---|---|
0.1 | 2011-06-15 | Initielt dokument | Trifork |
0.2 | 2011-07-27 | Ændringer jf. databaseskema indeholdende generelle notifikationer | Trifork |
0.3 | 2011-08-10 | Opsplitning af dokumentation jf. BRS og GOS opsplitning | Trifork |
0.4 | 2011-10-05 | Tilføjelse af information om eksternt "Sikrede" register fra Stamdata | Trifork |
0.5 | 2013-10-21 | Opdateret SVN link | Trifork |
0.6 | 2017-03-10 | Tilpasset til BRS2 | Trifork |
0.7 | 2017-03-14 | Rettet betegnelser på NSP-miljøer | Trifork |
0.8 | 2019-07-12 | Tilføjet mulighed for registrering med SOR kode | KvalitetsIT |