Page History
...
Excerpt | ||
---|---|---|
| ||
Behandlingsrelationsservicen tilvejebringer en enkel it-teknisk måde at verificere og dokumentere en behandlingsrelation, der har været anvendt til informationsadgangadgang til en borgers sundhedsdata. |
Confluencetable width | ||
---|---|---|
|
...
Offentlige og private dataansvarlige skal - under ansvar overfor over for Datatilsynet - træffe de fornødne tekniske og organisatoriske sikkerhedsforanstaltninger mod, at potentielt personhenførbare personhenførbare og fortrolige oplysninger hændeligt eller ulovligt tilintetgøres, fortabes eller forringes, samt mod at de kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med loven, jf. persondatalovens §41, stk. 3.
...
I praksis implementeres de påkrævede tekniske og organisatoriske foranstaltninger af de enkelte serviceudbydere.For at gøre det nemmere at verificere en aktuel behandlingsrelation, tilbyder Sundhedsdatastryrelsen en national behandlingsrelationsservice (efterfølgende ”BRS”), som alle udbydere af nationale sundheds-it tjenester kan anvende til at verificere eksistensen og kvaliteten af en behandlingsrelation. Servicen opsamler og anvender informationer om eksisterende behandlingsrelationer fra blandt andet nationale registreringer om aktiviteter i sundhedsvæsnet.
Formålet med BRS er at gøre det muligt for serviceudbydere at forbedre de eksisterende sikkerhedsforanstaltninger, herunder muligheden for at målrette og effektivisereeksisterende stikprøvetagninger.
Baggrund og formål
*Dokumentationen af NSP services og komponenter på NSPOP omfatter udelukkende NSP produktionsmiljøet og ikke NSP’s øvrige miljøer. Det er muligt at få information og indblik i tilstanden på et af de øvrige miljøer via de gængse kommunikationsveje.
--------------------
Behandlingsrelation betyder, Med behandlingsrelation menes, at sundhedspersonen har en aktuel kontakt til borgeren. Det er i sundhedsloven nærmere defineret som:
At patienten skal være »i behandling« påden på den behandlingsenhed, som sundhedspersonen er tilknyttet, dækker over enhver form for behandling, jf. sundhedslovens § 5, herunder ambulant behandling, indlæggelse, for-og efterundersøgelser m.v. (Sundhedsloven, Bemærkninger til §42a) |
---|
Informationen om, at en patient er ”i behandling”, er i princippet en afledt information, der kan søges bekræftetved bekræftes ved opslag i diverse forskellige registre , eksempelvisherunder:
- Den nationale Henvisningsformidling (Kilde: DNHF)
- Landspatientregistret (Kilde: LPR3)
- Sygesikringsregistrets ydelser
- Sygesikringsregistret - Ydelser/fx Speciallæger (Kilde: SSR)
- Sygesikringsregistret - Sikrede/Egen læge (Kilde: SSRSygesikringsregistrets "sikrede" (egen læge)
Nærværende produkt er en it-teknisk løsning (en service), der uddrager informationer af ovennævnte registrehenter informationer fra registrene ovenfor, og på forespørgsel returnerer svar på, hvor meget evidens, der er for en aktuel behandlingsrelation på forespørgselstidspunktet.
Deruodover Derudover består produktet af services til opsamling og notifikation. Disse to services er blevet anvendt til at etablere en NSP mekanisme til opfølgning på behandlingsrelationer. Opfølgning på behandlingsrelationer er nødvendig, fordi de nationale registre opdateres på bagkant af handlinger og behandlinger, og det derfor med den nuværende opdateringsfrekvens af nationale registre, ikke er muligt at garantere opdaterede svar i behandlingsøjeblikket.
It-løsningen vedrørende , som genererer en opfølgning på behandlingsrelation, gør det muligt for en serviceudbyder at bestille en verifikation af en behandlingsrelation, hvor opfølgningsservicen . Opfølgningsservicen modtager bestillingen og foretager efterfølgende foretager opslag i behandlingsrelationsregistreneregistrene, indtil enten det ønskede verifikationsniveau opnås, eller den af serviceudbyderen angivne tidsfrist udløber.
Resultatet af verifikationen stilles efterfølgende til rådighed på NSP for den pågældende serviceudbyder.
Opfølgning på behandlingsrelation løser problemet vedrørende ressourcekrævende evaluering af handlinger foretaget af sundhedsfaglige overfor nationale services, idet opfølgningsservicen løfter opgaven med at gennemføre verifikationen og klassificerer behandlingsrelationen til efterfølgende brug hos serviceudbyderen.
Forretningsmæssig motivation
Behandlingsrelationsservicen tilvejebringer en enkel it-teknisk måde at verificere og dokumentere en behandlingsrelation, der har været anvendt til informationsadgang. Servicen giver dermed mulighed for at etablere en kosteffektiv systemteknisk overholdelse af gældende lovgivning.
- Behandlingsrelationsservicen formulerer og tilbyder en ensartet klassifikation af behandlingsrelationer, der kan bruges på tværs af services og i en lang række anvendelsesscenarier, hvor der er krav til kvaliteten af en given behandlingsrelation. Servicen giver med andre ord en fælles fortolkning af begrebet behandlingsrelation.
- Behandlingsrelationsservicen giver mulighed for at optimere og effektivisere den opfølgende kontrol ved f.eks. foretage mere kvalificerede stikprøvekontroller.
- En bagudrettet, manuel opfølgning på baggrund af ikke-autoriseret eller utilsigtet informationsadgang er en omkostningstung og ressourcekrævende proces. Ikke mindst er arbejdet med at identificere sandsynlige overtrædelsermeget ressourcekrævende.
Nærværende produkt sigter mod at gøre det muligt og enkelt at lave en automatisk it-teknisk opsamling og opfølgning på kvaliteten af aktuelle behandlingsrelationer - uden at det afføder væsentligt merarbejde eller ressourcetræk hos serviceudbyderen.
Opfølgningsservicen sigter mod at levere gevinster i såvel kvalitet som kvantitet, da denne service kan automatisere dele af de eksisterende manuelle processer omkring (typisk stikprøvebaseret) opfølgning og dermed markant øge mulighed og omfang for struktureretopfølgning på sikkerhedsmæssigeforhold i forbindelse med aktuelle behandlingsrelationer.
- Den sikkerhedsmæssige opfølgningsservice giver en systemteknisk mulighed for automatisk at følge op på om de formelle regler og relevanskriterierfor adgang til sundhedsdata rent faktisk er opfyldt
- Opfølgningsservicen udstiller et ensartet workflow til at oprette, lagre og afvikle sikkerhedsmæssig hændelser ved brug af nationale services
- Servicen tilbyder en høj grad af automatisering af ovenstående workflow til erstatning for en stor bagudrettet, manuel opfølgning
Hvad er produktet?
Produktet består af en it-service, der anvender de ovenfor nævnte registre til at kvalificere en given behandlingsrelation.
Behandlingsrelationservice udbydes på NSP, så servicen er tilgængelig for alle sundhedsvæsenets parter under fælles og velkendte vilkår. Produktet giver mulighed for at serviceudbydere på en ensartet og veldefineret måde kan tilgå informationer fra en række relevante registre med henblik på at kunne vurdere, om der er tilstrækkelig evidens for en given behandlingsrelation.
BRS klassificerer behandlingsrelationer på en ordnet skala, arrangeret efter ”styrken” af behandlingsrelationsevidens, hvor ”A+” pt. er den kategori, der beskriver relationer med stærkest evidens for en aktuel behandlingsrelation. Skalaen for klassifikationerne er:
...
BRS erstatter ikke eksisterende sikkerhedsforanstaltninger, men kan indgå i foranstaltningerne og bidrage til at målrette sikkerhedsindsatsen og derigennem styrke verificeringen af en aktuel behandlingsrelation imellem patient og sundhedsperson.
BRS udbydes på NSP, så servicen er tilgængelig for alle sundhedsvæsenets parter under fælles og velkendte vilkår. BRS giver mulighed for at serviceudbydere på en ensartet og veldefineret måde kan tilgå informationer fra en række relevante registre med henblik på at kunne vurdere, om der er tilstrækkelig evidens for en given behandlingsrelation.
BRS udstilles på NSP (både dNSP og cNSP), og det er derfor teknisk muligt at få adgang til servicen både fra regionale it-systemer (dNSP) og fra it-systemer, der gør brug af den central NSP-instans (cNSP).
Til brug for at håndtere data er linket til SOR benyttes en intern NSP microservice SORES til SOR/SHAK mapning og opslag.
HTML |
---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/ea961ef8-7a3c-4cd1-b60b-1e2401a3c1a1.html" name="test" height="540" 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.
Forretningsmæssig motivation
Behandlingsrelationsservicen giver en enkel måde at verificere og dokumentere, at en sundhedspersons opslag på en borger er foretaget på baggrund af en behandlingsrelation. Servicen giver etablerer dermed en kosteffektiv, systemteknisk overholdelse af gældende lovgivning.
- BRS formulerer og tilbyder en ensartet klassifikation af behandlingsrelationer, der kan bruges på tværs af services og i en lang række anvendelsesscenarier, hvor der er krav til kvaliteten af en given behandlingsrelation. BRS giver således en fælles fortolkning af begrebet behandlingsrelation.
- BRS giver mulighed for at optimere og effektivisere den opfølgende kontrol ved for eksempel at foretage mere kvalificerede stikprøvekontroller.
- En bagudrettet, manuel opfølgning på baggrund af ikke-autoriseret eller utilsigtet informationsadgang er en omkostningstung og ressourcekrævende proces. Ikke mindst er arbejdet med at identificere sandsynlige overtrædelser meget ressourcekrævende.
BRS sigter mod at gøre det muligt og enkelt at lave en automatisk it-teknisk opsamling og opfølgning på kvaliteten af aktuelle behandlingsrelationer - uden at det afføder væsentligt merarbejde eller ressourcetræk hos serviceudbyderen.
Opfølgningsservicen sigter mod at levere gevinster i såvel kvalitet som kvantitet, fordi servicen kan automatisere dele af de eksisterende manuelle processer omkring (typisk stikprøvebaseret) opfølgning.
- Den sikkerhedsmæssige opfølgningsservice giver en systemteknisk mulighed for automatisk at følge op på, om de formelle regler og relevanskriterier for adgang til sundhedsdata rent faktisk er opfyldt.
- Opfølgningsservicen udstiller et ensartet workflow til at oprette, lagre og afvikle sikkerhedsmæssig hændelser ved brug af nationale services.
Servicen tilbyder en høj grad af automatisering af ovenstående workflow til erstatning for en omfangsrig, bagudrettet, manuel opfølgning.
Behandlingsrelationsregler
BRS klassificerer behandlingsrelationer på en ordnet skala, arrangeret efter ”styrken” af behandlingsrelationsevidens, hvor ”A+” pt. er den kategori, der beskriver relationer med stærkest evidens for en aktuel behandlingsrelation.
Skalaen for klassifikationerne er:
Kategori | Navn | Beskrivelse | Anbefalet tolkning |
---|---|---|---|
A+ | Direkte behandlingsrelation | Eksplicit relation (f.eks. henvisning) mellem navngiven behandler og navngiven patient på et kendt tidspunkt. | Behandlingsrelationer i denne kategori er for tiden de bedst dokumenterede, og det anbefales, derfor at betragte kategorien A+ relationer som værende verificerede og kræver ikke yderligere tiltag. |
A | Samme tid, samme behandlingssted | Patient og Behandler var på samme behandlingssted på samme tid. | Det anbefales at betragte kategori A relationer som værende verificerede og kræver ikke yderligere tiltag. |
B+ | Samme behandlingssted | Patient og Behandler var på samme behandlingssted (sygehus - gælder kun LPR3) på samme tid. | Med det nuværende datagrundlag anbefales det at lade opfølgningen pågå i 90 dage med en forventning om at opnå kategori A eller bedre. |
B | Generel behandlingsrelation | Generel behandlingsrelation, f.eks. at læge er patientens ”egen læge”. | Med det nuværende datagrundlag anbefales det at lade opfølgningen pågå i 90 dage med en forventning om at opnå kategori A eller bedre. |
C | Historisk betinget behandlingsrelation | Historisk betinget behandlingsrelation. Patient og behandler har været i kontakt tidligere. | Med det nuværende datagrundlag anbefales det at lade opfølgningen pågå i 90 dage med en forventning om at opnå kategori A eller bedre. |
D | Kan ikke afklares pt. | Ingen evidens for nuværende. | Med det nuværende datagrundlag anbefales det at lade opfølgningen pågå i 90 dage med en forventning om at opnå kategori A eller bedre. |
E | Kan ikke afklares | Ingen evidens hverken nu eller senere. | Behandlingsrelationer i denne kategori er ikke verificerede, og kan heller ikke blive det senere. |
Registre (Evidenskilder)
Sygesikringsregistret (også kendt som "ydelsesregistret"):
- Match på ydernummer, patient cpr og dato (interval bestående af start- og slutdato): Kategori A
- Match på ydernummer, patient cpr, men ikke dato: Kategori C
- Ingen af ovenstående, og testet interval er max 62 dage (konfigurerbart) siden: Kategori D
- Ingen af ovenstående: Kategori E
- Forespørgsler, hvor ydernummer ikke indgår: Kategori E
Anchor | ||||
---|---|---|---|---|
|
- Match på ydernummer, patient cpr og dato: Kategori B
- Match på ydernummer og patient cpr, men ikke dato: Kategori C
- Ingen af ovenstående, og testintervallet er max 10 dage siden: Kategori D
- Ingen af ovenstående: Kategori E
- Forespørgsler, hvor ydernummer ikke indgår: Kategori E
Henvisningshotellet (REFHOST):
Mulighed for intern BRS-mapning fra SOR-kode til SHAK inden opslag. REFHOST-kilden benytter SHAK som nøgle.
- Match på "STED", patient cpr, yder cpr og dato: Kategori A+
- Match på "STED", patient cpr og dato: Kategori A
- Match på "STED", patient cpr, men ikke dato: Kategori C
- Ingen af ovenstående, og testintervallet er max 2 dage siden: Kategori D
- Ingen af ovenstående: Kategori E
LPR:
Mulighed for intern BRS-mapning fra SOR-kode til SHAK inden opslag. LPR-kilden benytter SHAK som nøgle.
- Match på SKS afdelingskode, patient cpr og dato (Lookup overlapper med admitted): Kategori A
- Match på SKS sygehuskode, patient cpr og dato (Lookup overlapper med admitted): Kategori B
- Match på sks, patient cpr: Kategori C
- Ingen af ovenstående: Kategori E
LPR3:
Mulighed for intern BRS-mapning fra SHAK til SOR kode. LPR3-kilden benyttes SOR-kode som nøgle. LPR3-data forefindes med nedenstående typer, som benyttes af reglerne:
- F: FORLOEBSELEMENT
- K: KONTAKT
- P: PROCEDURE
- I: INITIEL_HENVISNING
- H: HENVISNING
- R: RESULTATINDBERETNING
- O: OPHOLDSADRESSE
Reglerne er således:
- Match på SOR afdelingskode eller underafdeling, patient cpr, dato (Lookup overlapper med admitted) og type F, K, P, I eller H: Kategori A
- Match på SOR sygehuskode, dato (Lookup overlapper med admitted) og type og type F, K, P, I eller H: Kategori B+
- Match på SOR afdelingskode eller underafdeling, patient cpr, dato (Lookup overlapper med admitted) og type R eller O: Kategori B
- Match på SOR afdelingskode eller underafdeling og patient cpr: Kategori C
- Ingen af ovenstående: Kategori E
Beregning af om der skal bestilles opfølgning
Følgende logik afgør om der skal bestilles opfølgning:
1. Der tjekkes om der skal laves follow up. Det sker på baggrund af parametrene acceptableRelations, followupRelations og worstRelation (altid E)
Logikken til dette er:
- Hvis worstRelation (E) er stærk nok i forhold til acceptableRelations returneres der falsk til at der skal laves follow up.
- Hvis followupRelations er ALL returneres der sandt til at der skal laves follow up.
- Hvis worstRelation (E) er stærk nok i forhold til followupRelations så returneres der falsk ellers returneres der sandt.
Hvis punkt 1 returnerer sandt: bestilles der opfølgning og der returneres E til brugeren.
Hvis punkt 1 returnerer falsk: udfør beregningen på baggrund af actual relations (se logikken punkt 2).
2. Der tjekkes om der skal laves follow up. Det sker på baggrund af parametrene acceptableRelations, followupRelations og actual relations.
Logikken til dette er:
- Hvis actualRelation er stærk nok i forhold til acceptableRelations returneres der falsk til at der skal laves follow up.
- Hvis followupRelations er ALL returneres der sandt til at der skal laves follow up.
- Hvis actualRelation er stærk nok i forhold til followupRelations så returneres der falsk ellers returneres der sandt.
Hvis punkt 2 returnerer sandt: bestilles der opfølgning og actual relations returneres til brugeren.
Hvis punkt 2 returnerer falsk: der bestilles ikke opfølgning
Logikken i punkt 1 udføres ikke hvis property dk.nsi.brs.extended.followup.enabled er sat til falsk
I nogle tilfælde vil der være forsinkelser i registreringen af informationerne i kilderegistrene, og dokumentationen for relationen bliver mere sikker over tid, som illustreret nedenfor:
Gliffy Diagram displayName brsdok-opfolgning-motivation name brsdok-opfolgning-motivation pagePin 6
Tjenesteudbyderen kan ”bestille” en opfølgning hos servicen (BRS opsamling), hvorefter opfølgningen jævnligt vil pågå indtil der enten er opnået den forventede ”styrke” af behandlingsrelationen, eller der er gået for lang tid siden bestillingen.
Hvor længe opfølgningen skal foregå og hvilken grad af evidens, der forventes at blive opnået, afgøres af bestilleren.
Opfølgning på behandlingsrelation gør det lettere at evaluere handlinger foretaget af sundhedsfaglige på nationale services, idet opfølgningsservicen gennemfører verifikationen og klassificerer behandlingsrelationen til efterfølgende brug hos serviceudbyderen.
En typisk logopfølgning består af et it-job, der gennemføres med jævne mellemrum, f.eks. hver måned. Jobbet løber loggen igennem og udtager relativt få stikprøver. Disse stikprøver efterprøves enten it-teknisk eller manuelt. Nedenfor er illustreret, hvordan udtagningen af stikprøver kan optimeres ved at udtage flere stikprøver blandt adgange, hvor behandlingsrelationerne har lav eller ingen evidens og færrest blandt relationer med god evidens. Dette bør sikre, at der udtages langt flere relevante prøver, og at opfølgningen – f.eks. i form af en dialog med den pågældende bruger – kan foretages med højere kvalitet.
Gliffy Diagram displayName brs stikprover name brs stikprover pagePin 2
Versioner | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Property "extended followup" er udgået og er blevet fjernet fra koden og dokumentationen.
Status-check af SORES-forbindelse.
BRS Unit-test fejler (platforms-afhængighed)
Ensretning af ydernummver-håndtering i BRS
|
I nogle tilfælde vil der være forsinkelser i registreringen af informationerne i kilderegistrene, og dokumentationen for relationen bliver mere sikker over tidsom illustreret nedenfor:
TODO figur
Service til opfølgning på behandlingsrelationerer, som navnet antyder, en it-service, der tilbyder sundhedsvæsenets parter (f.eks. andre nationale tjenesteudbydere som angivet i figuren nedenfor) at følge op på graden af evidens for en aktuel behandlingsrelation. Tjenesteudbyderen kan ”bestille” en opfølgning hos servicen (BRS opsamling), hvorefter opfølgningen jævnligt vil pågå indtil der enten er opnået den for-ventede ”styrke” af behandlingsrelationen, eller der er gået for lang tid siden bestillingen.
Hvor længe opfølgningen skal foregå og hvilken grad af evidens, der forventes at blive opnået, afgøres af bestilleren.
Tjenesteudbydere skal derfor overveje, hvorledes BRS bedst anvendes både i forhold til aktiv adgangskontrol og til opfølgende kontrol.
En generel vejledning i anvendelsesscenarier findes i [BRSVejledning????Hvor er den???].
BRS erstatter ikke eksisterende sikkerhedsforanstaltninger, men kan indgå i foranstaltningerne og bidrage til at målrette sikkerhedsindsatsen og derigennem styrke dokumentationen af en aktuel behandlingsrelation imellem patient og sundhedsperson.
Arkitekturen for BRS er illustreret på figuren nedenfor:
Gliffy Diagram displayName Forretningsdok BRS Arkitektur name Forretningsdok BRS Arkitektur pagePin 10
Produktet indeholder følgende:
- Integration med evidenskilderne: Integration med evidenskilderne sker i form af jævnlig opdatering af lokal database med data for disse.
- Behandlingsrelationsservice: Service til beregning af styrken af en behandlingsrelation. Beslutningsflowet for BRS for de forskellige evidenskilder er dokumenteret detaljeret i BRS - Design- og Arkitekturbeskrivelse.
- BRS Opsamlingsservice: Service til bestillinger af beregninger af behandlingsrelation
- BRS Notifikationsservice: Service til afhentning af evidensniveau for bestilte beregninger (via Opsamlingsservice)
- BRS Opfølgningsservice: Service til periodisk (gen)beregning af styrken af en behandlingsrelation for en bestilt opfølgning.
Anvendelsesscenarier
FJERNES - start
Kort introduktion til service | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Komponent og versioner | ||||||||||
BRS udstilles på NSP (både dNSP og cNSP) og det er derfor teknisk muligt at få adgang til servien både fra regionale it-systemer (dNSP) og fra it-systemer, der gør brug af den central NSP-instans (cNSP). Der henvises til den tekniske dokumentation for BRS via følgende link: NSP-komponenter. Ud over den tekniske dokumentation er der også følgende overordnede dokumentation tilgængelig: Behandlingsrelationsservicen - Guide til Anvendere Opsamlings og notifikationsservice - Guide til anvendere For anvender af BRS anvendes url for det valgte endpoint med tilføjelse: brs-nsp/service/brs -se Opsamlings og notifikationsservice - Guide til anvendere Eksempel på endpoint i testmiljøerne (dNSP i TEST2-miljøet): http://test2-dnsp.ekstern-test.nspop.dk:8080/brs-nsp/service/brs Følgende standarder og begreber bør være kendt hos udviklerne:
Se https://svn.nspop.dk/svn/components/brs/trunk/Changelog Release 2.0.10 Leverancen er tagget som: release-2.0.10 Releasen indeholder nedenstående JIRA. Jira | | |||||||||
server | NSI JIRA |
Jira | ||||||
---|---|---|---|---|---|---|
|
Leverancen er tagget som: brs-2.0.28
Releasen indeholder nedenstående Jira sager.
Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-4697 Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-
Der er tilføjet en status (lastSuccesfullBatch) på /brs-backend/status der signalerer hvornår sidste successfulde batch er håndteret (modsat alle batch er håndteret som eksisterende status (lastSuccesfullRun) signalerer )
5347
- Release 2.0.29
Leverancen er tagget som: brs-2.0.29
Releasen indeholder nedenstående Jira sager.Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-
Der er ændret således, at SOR data gælder hele den dag, som gyldighedsperioden indikerer og ikke bare først på dagen.
5307 Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3
Der er ændret således, at det nu er muligt at sende SOR kode ind som OrganisationIdentifier i BRS registeringen. Følgende dele af BRS er justeret til:
-001c-3439-bc53-f7a235a8cd61 key SDS-5393
Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-
5122
- Release 2.0.
- 30
Leverancen er tagget som:
- brs-2.0.
- 30
Releasen indeholder nedenstående
- Jira sager.
Jira server NSI JIRA
columnIds
issuekey,summary,
issuetype,created,updated,
duedate,assignee,reporter,priority,status,resolution
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53
Sikrede (AssignedDoctor) forsøger nu at mappe SOR til ydernummer vha SOR opslags servicen, hvis SOR sendes med istedet for ydernummer
Henvisningshotel (REFHOST) forsøger nu at mappe SOR til ydernummer/SHAK vha SOR opslags servicen, hvis SOR sendes med istedet for ydernummer/SHAK
Funktionaliteten kan slåes til og fra med property dk.nsi.brs.relayer.sorls.all.enabled. Propertien deles med andet logik også.
-f7a235a8cd61 key SDS-5525
- Release 2.0.31
Leverancen er tagget som: brs-2.0.31
Releasen indeholder nedenstående Jira sager.Jira server NSI JIRA serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-4697
- Release 2.0.32
Leverancen er tagget som: brs-2.0.32
Releasen indeholder nedenstående Jira sager.Jira server NSI JIRA
serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-
4697
- Release 2.0.23.2
Leverancen er findes her: https://svn.nspop.dk/svn/components/brs/tags/brs-2.0.23.2/ og indeholder følgendeJira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key
SDS-6047
- Release 2.0.23.3
Leverancen er findes her: https://svn.nspop.dk/svn/components/brs/tags/brs-2.0.23.3/ og indeholder følgendeJira server NSI JIRA
serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-
6362
- Release 2.0.
- 33
Leverancen er
Releasen indeholder nedenstående JIRA.
- 33/ og indeholder følgende
Jira server NSI JIRA
columnIds
issuekey,summary,
issuetype,created,updated,
duedate,assignee,reporter,priority,status,resolution
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-
6170
- Release 2.0.
- 34
Leverancen er
Releasen indeholder nedenstående JIRA.
- 34/ og indeholder følgende:
Jira server NSI JIRA
serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS
Fjernet fejl ved kald med SOR kode, da SDS-3926 og SDS-3656 tillader opslag med SOR
-4697
- Release 2.0.
- 35
Leverancen
Releasen indeholder nedenstående JIRA.
- 35/ og indeholder QA rettelser til følgende:
Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-
Leverancen er tagget som: release-2.0.15
Releasen indeholder nedenstående JIRA.
5525 Jira server NSI JIRA serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-4697 Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key
SDS-5307
Leverancen er tagget som: release-2.0.16
Releasen indeholder nedenstående JIRA.
Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61
Leverancen er tagget som: release-2.0.17
Releasen indeholder nedenstående JIRA.
key SDS-5393 Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key
Leverancen er tagget som: release-2.0.18
Releasen indeholder nedenstående JIRA.
SDS-5122 Jira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key
SDS-6170
- Release 2.0.1936
Leverancen er tagget som: releasefindes her: https://svn.nspop.dk/svn/components/brs/tags/brs-2.0.1936/ og indeholder rettelser til følgende:
Releasen indeholder nedenstående JIRA.
JIRAJira server NSI JIRA columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-4040
Status-check af SORES-forbindelse.
- Release 2.0.20
Leverancen er tagget som: release-2.0.20
Releasen indeholder nedenstående JIRA.Jira server NSI JIRA serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-4150
SDS-5307
BRS er udviklet, driftet og vedligeholdt af SDS, og alle henvendelser skal foregå gennem National Servicedesk: https://www.nspop.dk/display/resources/Indberetning+til+Service+Desk
BRS er deployeret i produktion og i de nationale testmiljøer.
Page properties | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||
|