Versions Compared

Old Version 57

changes.mady.by.user Unknown User (dsbk@sundhedsdata.dk)

Saved on

compared with

New Version 66

changes.mady.by.user Henrik Eidnes Nielsen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: SDS-5307 Ret småfejl

...

Ceritfikatoplysninger (Virksomheds-OCES) skal anvendes for at benytte behandlingsrelationsservice og organisationen bag anvendersystemet skal indgå en serviceaftale med Sundhedsdatastyrelsen, via NSP Operatøren.

Arkitekturen for BRS og samspillet mellem de konkrete BRS services er illustreret på figuren nedenfor:

HTML
<iframe src="https://www.nspop.dk/rest/gliffy/1.0/embeddedDiagrams/638d065d-faf9-4af5-a3d0-93fd2d3cb224.png" name="test" height="500" width="1200">You need a Frames Capable browser to view this content.</iframe>

I sundhedssektoren findes der ikke et register over behandlingsrelationer, og BRS gør derfor brug af afledt viden fra en række nationale registre for at bestemme den aktuelle behandlingsrelation.

Da den gængse registreringspraksis tillader opdateringer af registrene i et relativt stort tidsrum efter en handling, kan gentagne kald til BRS med samme input give forskelligt resultat over tid, idet datagrundlaget med stor sikkerhed vil ændre sig i dagene og ugerne efter en sundhedsfaglig hændelse, f.eks. en lægekonsultation eller et indlæggelsesforløb på et sygehus.

Man kan i kaldet til BRS vælge at lade servicen håndtere denne kompleksitet, idet man gennem en række parametre kan konfigurere BRS-håndteringen og styre hvordan – og hvornår – der skal leveres et endeligt svar til kaldet.

...

Slutbrugerne er i denne sammenhæng f.eks. udviklere og arkitekter hos leverandører, som ønsker at integrere til BRS.

Det forudsættes at læseren kender til Den Gode Webservice (DGWS) og den nationale serviceplatform (NSP).

...

Behandlingsrelationsservicen giver mulighed for at bestille opfølgninger gennem brug af notifikationsservicen. Da det forventes at denne option vil blive brugt af de fleste anvendere, er begge snitflader dokumenteret nedenfor.

Notifikation Applikationen 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. Hvis man ikke angiver offset kan man risikere at modtage de samme alarmer flere gange. Servicen sletter alarmer efter et centralt konfigurerbart tidsinterval.

Følgende punkter gælder for begge services:

Format for tidsstempler

Bemærk at formatet på alle tidsstempler (f.eks. TimeLimit og RelationLookupTimeInterval) er som følger: YYYY-MM-DD'T'HH:MM:SS'+'forskydning fra GMT', f.eks. "2013-01-31T22:59:40+02:00"

Fejlkoder

Nedenfor ses en liste af typiske fejl der kan forekomme når en service kaldes. Fejl der returneres indeholder en fejlkode samt en fejltekst med yderligere detaljer. Teksten er ikke medtaget i tabellen nedenfor da den kan variere afhængig af hvad der gav anledning til fejlen.

...

Kode

...

Betydning

...

processing_problem

...

Som oftest validerings fejl, kan dog også opstå ved en generel fejl i servicen.
Fault message vil indeholde yderligere beskrivelse af årsagen.

...

missing_required_header

...

En sikkerheds eller medcom header mangler i requestet

...

security_level_failed

...

Authentification level som angivet i headeren er ikke tilstrækkelig til at tilgå servicen.

...

invalid_idcard

...

Ugyldigt id-kort.

...

expired_idcard

...

Id-kortet er udløbet.


I sundhedssektoren findes der ikke et register over behandlingsrelationer, og BRS gør derfor brug af afledt viden fra en række nationale registre for at bestemme den aktuelle behandlingsrelation.

Da den gængse registreringspraksis tillader opdateringer af registrene i et relativt stort tidsrum efter en handling, kan gentagne kald til BRS med samme input give forskelligt resultat over tid, idet datagrundlaget med stor sikkerhed vil ændre sig i dagene og ugerne efter en sundhedsfaglig hændelse, f.eks. en lægekonsultation eller et indlæggelsesforløb på et sygehus.

Man kan i kaldet til BRS vælge at lade servicen håndtere denne kompleksitet, idet man gennem en række parametre kan konfigurere BRS-håndteringen og styre hvordan – og hvornår – der skal leveres et endeligt svar til kaldet.

Anchor
_Toc477258562
_Toc477258562
Målgruppe og forudsætninger

Slutbrugerne er i denne sammenhæng f.eks. udviklere og arkitekter hos leverandører, som ønsker at integrere til BRS.

Det forudsættes at læseren kender til Den Gode Webservice (DGWS) og den nationale serviceplatform (NSP).

Anchor
_Toc477258563
_Toc477258563
Snitfladebeskrivelse

Behandlingsrelationsservicen giver mulighed for at bestille opfølgninger gennem brug af notifikationsservicen. Da det forventes at denne option vil blive brugt af de fleste anvendere, er begge snitflader dokumenteret nedenfor.

Notifikation Applikationen 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. Hvis man ikke angiver offset kan man risikere at modtage de samme alarmer flere gange. Servicen sletter alarmer efter et centralt konfigurerbart tidsinterval.

Følgende punkter gælder for begge services:

Format for tidsstempler

Bemærk at formatet på alle tidsstempler (f.eks. TimeLimit og RelationLookupTimeInterval) er som følger: YYYY-MM-DD'T'HH:MM:SS'+'forskydning fra GMT', f.eks. "2013-01-31T22:59:40+02:00"

Fejlkoder

Nedenfor ses en liste af typiske fejl der kan forekomme når en service kaldes. Fejl der returneres indeholder en fejlkode samt en fejltekst med yderligere detaljer. Teksten er ikke medtaget i tabellen nedenfor da den kan variere afhængig af hvad der gav anledning til fejlen.

Kode

Betydning

processing_problem

Som oftest validerings fejl, kan dog også opstå ved en generel fejl i servicen.
Fault message vil indeholde yderligere beskrivelse af årsagen.

missing_required_header

En sikkerheds eller medcom header mangler i requestet

security_level_failed

Authentification level som angivet i headeren er ikke tilstrækkelig til at tilgå servicen.

invalid_idcard

Ugyldigt id-kort.

expired_idcard

Id-kortet er udløbet.

not_authorized

Manglende whitelisting (kontakt nsp operatøren for at blive whitelistet)

WSDL endpoints


Path for WSDL uden security headers

[server-URL]/brs-nsp/service/[path]


Hvor path er en af følgende:

  • brs?wsdl
  • brs20220314?wsdl
  • notification?wsdl
  • notification20210921?wsdl
  • notification20220314?wsdl


Eksempel:

http://localhost:8080/brs-nsp/service/brs?wsdl


Path for WSDL med security headers

[server-URL]/brs-nsp/[path]


Hvor path er en af følgende

  • secure-wsdl/brs
  • secure-wsdl/brs20220314
  • secure-wsdl/notification
  • secure-wsdl/notification20210921
  • secure-wsdl/notification20220314


Eksempel:

http://localhost:8080/brs-nsp/secure-wsdl/brs.wsdl

...

not_authorized

...


Anchor
_Toc477258564
_Toc477258564
Behandlingsrelationsservice

...

Denne operation tager en soap besked som input, indeholdende en header og en body. Headeren indeholder en WSSE header samt en Medcom header som specificeret i Den Gode Webservice (DGWS) version 1.0.1. SOSI idkortet i headeren skal være på niveau 3 og udstedt af SOSI-STS.

WSDL findes ved at tilføje "?wsdl"-postfix til adressen.

Eksempel på endpoint i testmiljøerne (cNSP i TEST2-miljøet):
http://test2-cnsp.ekstern-test.nspop.dk:8080/brs-nsp/service/brshttps://wsdl):
http://test2-cnsp.ekstern-test.nspop.dk:8080/brs-nsp/service/brs?wsdl

Forespørgsel til BRS

Body er defineret som et element af typen treatmentRelationRequestBody, der er en complexType indeholdende en række felter. Betydningen og anvendelsen af felterne er opsummeret i tabellen nedenfor.

treatmentRelationRequestBody

Elementer

Beskrivelse

Felt krævet

OrganisationIdentifier

Organisationen inden for hvilken relationen skal findes. Feltet er struktureret og kan indeholde et sks, ydernummer, sor kode eller EAN-nummer.

Ja

PatientCpr

Patientens cpr-nummer.

Ja

HealthProfessionalCpr

Behandlers cpr-nummer.

Ja

RelationLookupTimeInterval

Tidsinterval inden for hvilket behandleren har foretaget opslaget. Kan f.eks. være validetsperioden for behandlerens ID-kort.

Ja

TimeLimit

Udløbstidspunkt for opfølgningen efter hvilket der skal oprettes en notifikation, hvis de angivne kriterier ikke er opfyldt (se AcceptableRelations nedenfor).

Ja

ExternalReferenceId

Et id der vil blive brugt ved returnering af en eventuel notifikation.
Hvis ikke feltet udfyldes, genererer BRS automatisk en værdi i svaret (se tabellen nedenfor).
Formålet med feltet er at give det kaldende system mulighed for at lave egne referencer til eventuelle afklaringer af hændelsesforløb på et senere tidspunkt.

Ja

QueryableCvr

CVR nummer der skal have adgang til en eventuel efterfølgende notifikation.
Kan være det samme som den kaldende service, men det behøver det ikke være.
Eventuelle notifikationer kan alene hentes af organisationer, hvor det angivne CVR nummer i dette felt matcher CVR nummeret i den anvendte digitale signatur.

Ja

MiinimumAcceptableRelation

Et enkelt minimum acceptabelt forhold. Ud fra dette opbygges en liste af acceptable relationer (f.eks. "A+, A, B") over alle relationer ovenfor og inklusive den mindst acceptable relation.  Er alle relationer acceptable, angives værdien "ANY".
Hvis den fundne kategori for en given behandlingsrelation ikke optræder i listen, bestiller BRS en opfølgning afhængigt af værdien i FollowupRelations (se næste række).

Ja

Followup

Skal der laves en opfølgning, hvis MinimumAcceptableRelation ikke blev nået.

FollowupRelations

En liste af relationer der, i tilfælde af at ingen acceptable relationer forefindes (se ovenfor), vil give anledning til en opfølgning, f.eks. "D, E". Ønskes der opfølgning på alle kategorier udover dem der er angivet i AcceptableRelations sættes værdien til "ALL".

Ja

AuthorisationIdentifier

Autorisationskode for den behandleren.

Ja

ServiceProvider

Tekststreng indeholdende navnet på serviceudbyderen (f.eks. FMK). Bruges til logformål.

Ja

...

Code Block
firstline1
titleBRS Request 2022/03/14
linenumberstrue
collapsetrue
<treatmentRelationRequestBody xmlns="httphttps://nsinspop.dk/nsp/fmki20110601behandlingsrelation/2022/03/14/brs">
    <OrganisationIdentifier>
        <DoctorOrganisationIdentifier>561010</DoctorOrganisationIdentifier>
    </OrganisationIdentifier>
    <PatientCpr>3112910017</PatientCpr>
    <HealthProfessionalCpr>1007707419</HealthProfessionalCpr>
    <RelationLookupTimeInterval>
        <start>2022<start>2023-01-01T1201T16:3916:3831+01:00</start>
        <end>2023<end>2024-01-01T1201T16:3916:3831+01:00</end>
    </RelationLookupTimeInterval>
    <MinimumAcceptableRelation>E</MinimumAcceptableRelation>
    <TimeLimit>2016-01-01T1201T16:3916:3831+01:00</TimeLimit>
    <QueryableCvr>46837428</QueryableCvr>
    <MinimumAcceptableRelation Relation="E"/><Followup>false</Followup>
    <FollowupRelations>
        <MinimumAcceptableRelation/>
    </FollowupRelations>
    <AuthorisationIdentifier<AuthorisationIdentifier />
    <ServiceProvider>
        <Name>myServiceProviderName</Name>
        <Version>snapshot</Version>
        <Vendor>arosii</Vendor>
    </ServiceProvider>
</treatmentRelationRequestBody>

...


Eksempel på endpoint i testmiljøerne (cNSP i TEST2-miljøet):
http://test2-cnsp.ekstern-test.nspop.dk:8080/gos/service/notification20210921https://wsdl.nspop.dk/brs-nsp/service/notification?wsdl


Bemærk: NSP miljøernes loadbalancer router trafikken fra ovennævnte endpoint til brs-nsp/service/notification, idet dette er adressen i BRS.

...