Behandlingsrelationsservicen tilvejebringer en enkel it-teknisk måde at verificere og dokumentere en behandlingsrelation, der har været anvendt til adgang til en borgers sundhedsdata.

Introduktion til BRS

Offentlige og private dataansvarlige skal under ansvar over for Datatilsynet - træffe de fornødne tekniske og organisatoriske sikkerhedsforanstaltninger mod, at potentielt 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.

Specifikt for sundhedsfaglige offentlige registre og elektroniske patientjournaler gælder det, at den, der indhenter oplysninger, skal være en sundhedsperson, der deltager i patientbehandling. Det kræves eksplicit, at der findes en aktuel behandlingsrelation imellem patienten og vedkommende sundhedsperson (se betænkning over forslag til lov om ændring af sundhedsloven).

I praksis implementeres de påkrævede tekniske og organisatoriske foranstaltninger af de enkelte serviceudbydere.

*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, 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 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 bekræftes ved opslag i forskellige registre herunder:

Nærværende produkt er en it-teknisk løsning (en service), der henter informationer fra registrene ovenfor, og på forespørgsel returnerer svar på, hvor meget evidens, der er for en aktuel behandlingsrelation på forespørgselstidspunktet.

Derudover består produktet af services til opsamling og notifikation. Disse to services er blevet anvendt til at etablere en mekanisme til opfølgning på behandlingsrelationer. Opfølgning på behandlingsrelationer er nødvendig, fordi de nationale registre opdateres på bagkant af 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, som genererer en opfølgning på behandlingsrelation, gør det muligt for en serviceudbyder at bestille en verifikation af en behandlingsrelation. Opfølgningsservicen modtager bestillingen og foretager efterfølgende opslag i registrene, 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.

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.


<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 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. 

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:

KategoriNavnBeskrivelseAnbefalet tolkning
A+Direkte behandlingsrelationEksplicit 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.
ASamme tid, samme behandlingsstedPatient 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.
BGenerel behandlingsrelationGenerel 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.
CHistorisk betinget behandlingsrelationHistorisk 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.
DKan 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.
EKan ikke afklaresIngen 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"):

Sikrede/Egen læge/Sygesikringsregistret:

Henvisningshotellet (REFHOST):

Mulighed for intern BRS-mapning fra SOR-kode til SHAK inden opslag. REFHOST-kilden benytter SHAK som nøgle.

LPR:

Mulighed for intern BRS-mapning fra SOR-kode til SHAK inden opslag. LPR-kilden benytter SHAK som nøgle.

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:

Reglerne er således:

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:


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.



Versioner
  • Release 2.0.9 (og tidligere)
    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. 

    • BRS-Utilsigtede statusfejl fra opfølgningsjobbet hvis dette er presset.
      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 )

    • Falske positiver ved organisationsændringer i SOR.
      Der er ændret således, at SOR data gælder hele den dag, som gyldighedsperioden indikerer og ikke bare først på dagen.

    • SOR understøttelse i BRS
      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:
      • Henvisningshotel (REFHOST) evidenskilde med SOR/SHAK mapning
      • Landspatientregister (LPR2) evidenskilde med SOR/SHAK mapning
      • LPR3 evidenskilde fungerer også uden mapning via SHAK

    • BRS understøttelse af Audit API
  • Release 2.0.11
    Leverancen er tagget som: release-2.0.11
    Releasen indeholder nedenstående JIRA.

    • Rettelse efter QA findings

    • Håndtering af SOR-koder i input som repræsenterer en yder.
      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å.
  • Release 2.0.12
    Leverancen er tagget som: release-2.0.12
    Releasen indeholder nedenstående JIRA.

    • Ved opslag med SOR kode skal BRS svare med fejl.
  • Release 2.0.13
    Leverancen er tagget som: release-2.0.13
    Releasen indeholder nedenstående JIRA.

    • BRS benytter SORES til mapning af SOR koder
    • SDS-3679 er rullet tilbage
      Fjernet fejl ved kald med SOR kode, da SDS-3926 og SDS-3656 tillader opslag med SOR
  • Release 2.0.14
    Leverancen er tagget som: release-2.0.14
    Releasen indeholder nedenstående JIRA.

    • Tilføjelser til relation relayers, så alle beslutninger og tilhørende beslutningsgrundlag logges.
  • Release 2.0.15
    Leverancen er tagget som: release-2.0.15
    Releasen indeholder nedenstående JIRA.

    • Ændringer til docker-compose setup, rettelse af logning der kommer i server.log og rettelser til sql-filer.
  • Release 2.0.16
    Leverancen er tagget som: release-2.0.16
    Releasen indeholder nedenstående JIRA
    .

    • Ny version af SORUtils, som skal afhjælpe connection leaks ved kald til SORES.
  • Release 2.0.17
    Leverancen er tagget som: release-2.0.17
    Releasen indeholder nedenstående JIRA
    .

    • Ny version af SORUtils, løsning på afhængighedsproblem.
  • Release 2.0.18
    Leverancen er tagget som: release-2.0.18
    Releasen indeholder nedenstående JIRA
    .

Property "extended followup" er udgået og er blevet fjernet fra koden og dokumentationen.

  • Release 2.0.19
    Leverancen er tagget som: release-2.0.19
    Releasen indeholder nedenstående JIRA
    .

Status-check af SORES-forbindelse.

  • Release 2.0.20
    Leverancen er tagget som: release-2.0.20
    Releasen indeholder nedenstående JIRA
    .

BRS Unit-test fejler (platforms-afhængighed)

  • Release 2.0.21
    Leverancen er tagget som: release-2.0.21
    Releasen indeholder nedenstående JIRA
    .

Ensretning af ydernummver-håndtering i BRS

  • Release 2.0.22
    Leverancen er tagget som: release-2.0.22
    Releasen indeholder nedenstående JIRA
    .
    • (Fejlrettelse, håndtering af ydernummeret '000000')
  • Release 2.0.23
    Leverancen indeholder nedestående Jira
    • BRS log tilføjelser/ændringer
  • Release 2.0.24
    Leverancen indeholder nedestående Jira
    • BRS log tilføjelser/ændringer. Rettelser efter QA.
  • Release 2.0.25
    Leverancen er tagget som: brs-2.0.25
    Releasen indeholder nedenstående JIRA
    .
    • (Fejlrettelse, håndtering af ydernummeret '000000')
    • Håndtering af SOR-koder i refhost/DNHF-data i BRS
  • Release 2.0.23.1
    Leverancen er tagget som: brs-2.0.23.1
    Releasen indeholder nedenstående Jira sager.
  • Release 2.0.26
    Leverancen er tagget som: brs-2.0.26
    Releasen indeholder nedenstående Jira sager.
  • Release 2.0.27
    Leverancen er tagget som: brs-2.0.27
    Releasen indeholder nedenstående Jira sager.
  • Release 2.0.28
    Leverancen er tagget som: brs-2.0.28
    Releasen indeholder nedenstående Jira sager.
  • Release 2.0.29
    Leverancen er tagget som: brs-2.0.29
    Releasen indeholder nedenstående Jira sager.
  • Release 2.0.30
    Leverancen er tagget som: brs-2.0.30
    Releasen indeholder nedenstående Jira sager.
Kontaktoplysninger, servicebeskrivelse og testforhold

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.


Teknisk kompleksitet

Lav

Forretningsmæssig værdi

Høj

E2E regressionstest status

Anbefalet Testdybde

Nuværende Testdybde