Page History

Versions Compared

Old Version 50

changes.mady.by.user Unknown User (rrv@kvalitetsit.dk)

Saved on 22-08-2022

compared with

New Version Current

changes.mady.by.user Henrik Eidnes Nielsen

Saved on 11-09-2023

Key

This line was added.
This line was removed.
Formatting was changed.

Comment: SDS-5307 Ret småfejl

...

Behandlingsrelationsservicen (BRS) er en service, der returnerer den bedst kendte behandlingsrelation imellem en borger og en sundhedsfaglig person på et givet tidspunkt. Læs Behandlingsrelationsservice (BRS) - Leverancebeskrivelse for at få et overblik over formålet og tankerne bag BRS.

De konkrete registre og algoritmer, der anvendes i BRS til at bestemme den aktuelle behandlingsrelation er beskrevet i BRS - Design- og Arkitekturbeskrivelse.

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. Se Behandlingsrelationsservice (BRS) - Leverancebeskrivelse for en forretningsmæssig beskrivelse af 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.

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)

BRS 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 samt til bestilling af beregneringer af behandlingsrelation.
BRS Notifikationsservice: Service til afhentning af evidensniveau for bestilte beregninger (via Behandlingsrelationsservice)
BRS Opfølgningsservice: Service til periodisk (gen)beregning af styrken af en behandlingsrelation for en bestilt opfølgning.

Desuden benyttes en intern NSP microservice SORES til SOR/SHAK mapning og opslag.

BRS benytter sin egen whitelist: register_notifications.whitelist i BRS databasen "register_notifications" og BRS kan kun kaldes af systemer der bruger et System-IDKort udstedt til forhåndsgodkendte CVR numre.

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

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.

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

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

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

...

Behandlingsrelationsservicen kan tilgås i de decentrale NSP-miljøer (dNSP) under adressen

*\[miljøurl\]/brs-nsp/service/brs*

hvor den stiller operationen "treatmentRelation" til rådighed.

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/brs

Forespørgsel til 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

Anchor
_Toc477258564
_Toc477258564
Behandlingsrelationsservice

Anchor
_Toc477258565
_Toc477258565
Endpoint

Behandlingsrelationsservicen kan tilgås i de decentrale NSP-miljøer (dNSP) under adressen

*\[miljøurl\]/brs-nsp/service/brs*

hvor den stiller operationen "treatmentRelation" til rådighed.

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

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.	Ja
AuthorisationIdentifier	Autorisationskode for den behandleren.	Ja
ServiceProvider	Tekststreng indeholdende navnet på serviceudbyderen (f.eks. FMK).
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. 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
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

Hvis der i kaldet til behandlingsrelationsservicen er angivet at der skal bestilles opfølgninger i opfølgningsservicen, vil der komme alarm-notifikationer, hvis de angivne kriterier ikke er opfyldt indenfor det i kaldet angivne tidsrum.

...

Code Block

firstline	1
title	BRS Request 2022/03/14
linenumbers	true
collapse	true

<treatmentRelationRequestBody xmlns="httphttps://nsinspop.dk/fmki20110601nsp/behandlingsrelation/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>

...

Code Block

firstline	1
title	Response fra BRS 2022/03/14
linenumbers	true
collapse	true

<?xml version="1.0" encoding="UTF-8" ?>
<ns5:treatmentRelationResponseBody xmlns:ns5="http://nsi.dk/fmki20110601/2022/03/14/brs"
                                   xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>
    <ns5:SufficientRelation>true</ns5:SufficientRelation>
    <ns5:ActualRelation Relation="D"/>
    <ns5:RelationsBySources>
        <ns5:RelationBySource>
            <ns5:Source>HENVISNING_SOR</ns5:Source>
            <ns5:Relation>E</ns5:Relation>
        </ns5:RelationBySource>
        <ns5:RelationBySource>
            <ns5:Source>LPR</ns5:Source>
            <ns5:Relation>E</ns5:Relation>
        </ns5:RelationBySource>
        <ns5:RelationBySource>
            <ns5:Source>SSR</ns5:Source>
            <ns5:Relation>D</ns5:Relation>
        </ns5:RelationBySource>
        <ns5:RelationBySource>
            <ns5:Source>SIKREDE</ns5:Source>
            <ns5:Relation>D</ns5:Relation>
        </ns5:RelationBySource>
        <ns5:RelationBySource>
            <ns5:Source>REFHOST</ns5:Source>
            <ns5:Relation>D</ns5:Relation>
        </ns5:RelationBySource>
    </ns5:RelationsBySources>
    <ns5:FollowupOrdered>false</ns5:FollowupOrdered>
    <ns5:UniqueReferenceId>452eff59-6ef3-46b3-98e2-07df9c7ff50d</ns5:UniqueReferenceId>
    <ns5:ExternalReferenceId>97825e04-c6db-4894-bc8a-ee67070d4453</ns5:ExternalReferenceId>
</ns5:treatmentRelationResponseBody>

...

Code Block

firstline	1
title	Response fra Notifikationservice 2022/03/14
linenumbers	true
collapse	true

<?xml version="1.0" encoding="UTF-8" ?>
<ns6:NotificationQueryResponseBody xmlns:ns6="http://nsi.dk/nsp/behandlingsrelationer/2022/03/14/notification"
                                   xmlns="http://www.w3.org/2000/09/xmldsig#">
    <ns6:Notifications>
        <ns6:Type>BRS</ns6:Type>
        <ns6:SerialNumber>1</ns6:SerialNumber>
        <ns6:ExternalReferenceId>efa4a5f4-2216-4f17-9010-be6eeeb36d0b</ns6:ExternalReferenceId>
        <ns6:QueryableCvr>46837428</ns6:QueryableCvr>
        <ns8:TreatmentRelationAlarmType xmlns:ns8="http://nsi.dk/fmki20110601/2022/03/14/brs"
                                        xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <ns8:TreatmentRelationFollowup>
                <ns8:TreatmentRelationRelayerData>
                    <ns8:OrganisationIdentifier>
                        <ns8:SORIdentifier>12345678</ns8:SORIdentifier>
                    </ns8:OrganisationIdentifier>
                    <ns8:PatientCpr>3112910017</ns8:PatientCpr>
                    <ns8:HealthProfessionalCpr>1007707419</ns8:HealthProfessionalCpr>
                    <ns8:RelationLookupTimeInterval>
                        <ns8:start>2022-01-01T11:05:34+01:00</ns8:start>
                        <ns8:end>2023-01-01T11:05:34+01:00</ns8:end>
                    </ns8:RelationLookupTimeInterval>
                </ns8:TreatmentRelationRelayerData>
                <ns8:TimeLimit>2016-01-01T11:05:34+01:00</ns8:TimeLimit>
                <ns8:ExternalReferenceId>efa4a5f4-2216-4f17-9010-be6eeeb36d0b</ns8:ExternalReferenceId>
                <ns8:QueryableCvr>46837428</ns8:QueryableCvr>
                <ns8:MinimumAcceptableRelation xmlns=""
                                               Relation="E"/>
                <ns8:RequestSource>
                    <ns8:TreatmentRelationRequestBody>
                        <ns8:OrganisationIdentifier>
                            <ns8:SORIdentifier>12345678</ns8:SORIdentifier>
                        </ns8:OrganisationIdentifier>
                        <ns8:PatientCpr>3112910017</ns8:PatientCpr>
                        <ns8:HealthProfessionalCpr>1007707419</ns8:HealthProfessionalCpr>
                        <ns8:RelationLookupTimeInterval>
                            <ns8:start>2022-01-01T11:05:34+01:00</ns8:start>
                            <ns8:end>2023-01-01T11:05:34+01:00</ns8:end>
                        </ns8:RelationLookupTimeInterval>
                        <ns8:TimeLimit>2016-01-01T11:05:34+01:00</ns8:TimeLimit>
                        <ns8:ExternalReferenceId>efa4a5f4-2216-4f17-9010-be6eeeb36d0b</ns8:ExternalReferenceId>
                        <ns8:MinimumAcceptableRelation xmlns=""
                                                       Relation="E"/>
                        <ns8:FollowupRelations>
                            <ns8:All>All</ns8:All>
                        </ns8:FollowupRelations>
                        <ns8:AuthorisationIdentifier/>
                        <ns8:ServiceProvider>
                            <ns8:Name>myServiceProviderName</ns8:Name>
                            <ns8:Version>snapshot</ns8:Version>
                            <ns8:Vendor>arosii</ns8:Vendor>
                        </ns8:ServiceProvider>
                    </ns8:TreatmentRelationRequestBody>
                </ns8:RequestSource>
                <ns8:TreatmentRelationFollowupSerialNumber>0</ns8:TreatmentRelationFollowupSerialNumber>
                <ns8:UniqueId>85baa673-dd6b-420e-acbf-fc41a25ce611</ns8:UniqueId>
            </ns8:TreatmentRelationFollowup>
            <ns8:ActualRelation xmlns=""
                                Relation="E"/>
            <ns8:RelationsBySources>
                <ns8:RelationBySource>
                    <ns8:Source>HENVISNING_SOR</ns8:Source>
                    <ns8:Relation>E</ns8:Relation>
                </ns8:RelationBySource>
                <ns8:RelationBySource>
                    <ns8:Source>REFHOST</ns8:Source>
                    <ns8:Relation>E</ns8:Relation>
                </ns8:RelationBySource>
                <ns8:RelationBySource>
                    <ns8:Source>LPR3</ns8:Source>
                    <ns8:Relation>E</ns8:Relation>
                </ns8:RelationBySource>
                <ns8:RelationBySource>
                    <ns8:Source>LPR</ns8:Source>
                    <ns8:Relation>E</ns8:Relation>
                </ns8:RelationBySource>
            </ns8:RelationsBySources>
        </ns8:TreatmentRelationAlarmType>
    </ns6:Notifications>
</ns6:NotificationQueryResponseBody

...

Code Block

language	xml
title	Response fra Notifikationsservice
collapse	true

<?xml version='1.0' encoding='UTF-8'?>
<ns5:NotificationQueryResponseBody xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="http://nsi.dk/fmki20110601/notification" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
  <ns5:Notifications>
    <ns5:Type>BRS</ns5:Type>
    <ns5:SerialNumber>1027</ns5:SerialNumber>
    <ns5:ExternalReferenceId>e4a4ab3f-3f7f-4e5d-a311-5942c14856b8</ns5:ExternalReferenceId>
    <ns5:QueryableCvr>31908574</ns5:QueryableCvr>
    <TreatmentRelationAlarmType:TreatmentRelationAlarmType xmlns:TreatmentRelationAlarmType="http://nsi.dk/fmki20110601/brs" xmlns="http://nsi.dk/fmki20110601/brs">
      <TreatmentRelationFollowup>
        <TreatmentRelationRelayerData>
          <OrganisationIdentifier>
            <DoctorOrganisationIdentifier>132435</DoctorOrganisationIdentifier>
          </OrganisationIdentifier>
          <PatientCpr>0101601951</PatientCpr>
          <HealthProfessionalCpr>0101601803</HealthProfessionalCpr>
          <RelationLookupTimeInterval>
            <start>2013-09-30T00:00:00+02:00</start>
            <end>2013-10-25T23:59:00+02:00</end>
          </RelationLookupTimeInterval>
        </TreatmentRelationRelayerData>
        <TimeLimit>2013-09-30T11:04:37+02:00</TimeLimit>
        <ExternalReferenceId>e4a4ab3f-3f7f-4e5d-a311-5942c14856b8</ExternalReferenceId>
        <QueryableCvr>31908574</QueryableCvr>
        <AcceptableRelations>
          <Relation>A</Relation>
          <Relation>B</Relation>
        </AcceptableRelations>
        <RequestSource>
          <TreatmentRelationRequestBody>
            <OrganisationIdentifier>
              <DoctorOrganisationIdentifier>132435</DoctorOrganisationIdentifier>
            </OrganisationIdentifier>
            <PatientCpr>0101601951</PatientCpr>
            <HealthProfessionalCpr>0101601803</HealthProfessionalCpr>
            <RelationLookupTimeInterval>
              <start>2013-09-30T00:00:00+02:00</start>
              <end>2013-10-25T23:59:00+02:00</end>
            </RelationLookupTimeInterval>
            <TimeLimit>2013-09-30T11:04:37+02:00</TimeLimit>
            <QueryableCvr>31908574</QueryableCvr>
            <AcceptableRelations>
              <Relation>A</Relation>
              <Relation>B</Relation>
            </AcceptableRelations>
            <FollowupRelations>
              <All>All</All>
            </FollowupRelations>
            <AuthorisationIdentifier>DM712</AuthorisationIdentifier>
            <ServiceProvider>
              <Name>SJ</Name>
              <Version>0.1</Version>
              <Vendor>Sundhed.dk</Vendor>
            </ServiceProvider>
          </TreatmentRelationRequestBody>
        </RequestSource>
        <TreatmentRelationFollowupSerialNumber>1123</TreatmentRelationFollowupSerialNumber>
        <UniqueId>0044ba5a-8378-4d33-b128-03522ed26e85</UniqueId>
      </TreatmentRelationFollowup>
      <ActualRelations>
        <Relation>C</Relation>
      </ActualRelations>
    </TreatmentRelationAlarmType:TreatmentRelationAlarmType>
  </ns5:Notifications>
</ns5:NotificationQueryResponseBody>

Procedure for udskiftning af certifikat

I dette afsnit beskrives hvad der skal ske, når en anvender skal udskifte sit certifikat, og det nye certifikat er udstedt til et andet CVR-nummer end det gamle certifikat. Hvis CVR-nummeret ikke er ændret, aftales blot at NSP-operatøren whitelister det nye certifikat, og fjerner det gamle fra whitelisten når der er meldt OK fra anvenderen.

Nogle anvendere er i stand til at benytte to certifikater i en overgangsperiode, andre er ikke, og derfor beskrives disse to tilfælde særskilt. Overgangsperioden er på 90 dage.

Udskiftning med overgangsperiode

Hvis det gamle og nye certifikat kan anvendes samtidigt i en periode, er proceduren for udskiftning som følger:

Det aftales med NSP-operatøren, hvornår det nye certifikat tages i brug. NSP-operatøren whitelister certifikatets CVR-nummer på dette tidspunkt.
Anvenderen sørger for, inden for overgangsperioden, at ophøre med at bruge det gamle certifikat. Hvis andre anvendere genererer alarmer til det gamle CVR-nummer, orienteres de om at de fremefter skal generere alarmer på det nye CVR-nummer.
Ved overgangsperiodens udløb fjerner NSP-operatøren det gamle CVR-nummer fra whitelisten.

Udskiftning uden overgangsperiode

Notifications>
</ns5:NotificationQueryResponseBody>

Procedure for udskiftning af certifikat

Nogle anvendere er i stand til at benytte to certifikater i en overgangsperiode, andre er ikke, og derfor beskrives disse to tilfælde særskilt. Overgangsperioden er på 90 dage.

Udskiftning med overgangsperiode

Hvis det gamle og nye certifikat kan anvendes samtidigt Hvis det ikke er muligt for anvenderen at anvende to certifikater i en periode, er proceduren for udskiftning som følger:

Anvenderen aftaler Det aftales med NSP-operatøren, hvornår der udskiftes certifikatdet nye certifikat tages i brug. NSP-operatøren whitelister det nye certifikat.Eventuelle andre anvendere, der genererer alarmer eller notifikationer til certifikatets CVR-nummeret på det gamle certifikat, orienteres om det forestående skift, og at de skal anvende det nye CVR-nummer.
På det aftale tidspunkt ophører anvenderen med at kalde BRS.
nummer på dette tidspunkt.
Anvenderen sørger for, inden for overgangsperioden, at ophøre med at bruge det gamle certifikat. Hvis andre anvendere genererer alarmer NSP-operatøren duplikerer alle alarmer og notifikationer hørende til det gamle CVR-nummer, således at kopien hører til orienteres de om at de fremefter skal generere alarmer på det nye CVR-nummer (beskrevet i driftsvejledningen, afsnit 4.2.
Ved overgangsperiodens udløb fjerner NSP-operatøren melder klar til anvenderen.
Anvenderen begynder at anvende BRS igen med det nye certifikat.

...

Request og response-eksemplerne ovenfor kan bruges som inspiration. Mange programmeringssprog har understøttelse for at danne kode udfra en snitfladebeskrivelse (WSDL). Det er op til anvenderen at finde en passende udviklingsstak og passende biblioteker, der kan hjælpe med denne proces.

Udover behovet for at kunne generere klientkode udfra en WSDL, så vil succesfuld anvendelse af BRS services kræve, at der medsendes gyldige akkreditiver (gyldigt SOSI Idkort) i kaldet.

Se feks: STS - Guide til anvendere samt SEAL.JAVA - Guide til anvendere og SEAL.NET Guide til anvendere.

...

Version

...

Dato

...

Ændring

...

Ansvarlig

...

0.1

...

2011-06-15

...

Initielt Dokument

...

Trifork

...

0.2

...

2011-07-27

...

Ændringer jf. skift til generel notifikationsservice indført.

...

Trifork

...

0.3

...

2011-08-10

...

Opsplitning jf. opsplitning af BRS og GOS

...

Trifork

...

0.9

...

2013-03-14

...

Grundig bearbejdning i samarbejde mellem sundhed.dk og NSI.

...

NSI/CHE
Sundhed.dk/HESO

...

1.0

...

2013-10-23

...

Rettet SVN links og xsd link der pegede forkert

...

Trifork

...

1.1

...

2017-03-08

...

Tilrettet BRS2

...

Trifork

...

1.2

...

2017-03-14

...

Konkretiseret afsnit om notifikationer

...

Trifork

...

det gamle CVR-nummer fra whitelisten.

Udskiftning uden overgangsperiode

Hvis det ikke er muligt for anvenderen at anvende to certifikater i en periode, er proceduren for udskiftning som følger:

Anvenderen aftaler med NSP-operatøren, hvornår der udskiftes certifikat. NSP-operatøren whitelister det nye certifikat.
Eventuelle andre anvendere, der genererer alarmer eller notifikationer til CVR-nummeret på det gamle certifikat, orienteres om det forestående skift, og at de skal anvende det nye CVR-nummer.
På det aftale tidspunkt ophører anvenderen med at kalde BRS.
NSP-operatøren duplikerer alle alarmer og notifikationer hørende til det gamle CVR-nummer, således at kopien hører til det nye CVR-nummer (beskrevet i driftsvejledningen, afsnit 4.2.
NSP-operatøren melder klar til anvenderen.
Anvenderen begynder at anvende BRS igen med det nye certifikat.

Anchor
_Toc477258579
_Toc477258579
Eksempler på at kalde BRS services

Udover behovet for at kunne generere klientkode udfra en WSDL, så vil succesfuld anvendelse af BRS services kræve, at der medsendes gyldige akkreditiver (gyldigt SOSI Idkort) i kaldet.

Se feks: STS - Guide til anvendere samt SEAL.JAVA - Guide til anvendere og SEAL.NET Guide til anvendere.

...

Content

Space Tools

Versions Compared

Old Version 50

New Version Current

Key

Format for tidsstempler

Fejlkoder

Anchor
_Toc477258562
_Toc477258562
Målgruppe og forudsætninger

Anchor
_Toc477258563
_Toc477258563
Snitfladebeskrivelse

Format for tidsstempler

Fejlkoder

WSDL endpoints

Forespørgsel til BRS

Anchor
_Toc477258564
_Toc477258564
Behandlingsrelationsservice

Anchor
_Toc477258565
_Toc477258565
Endpoint

Forespørgsel til BRS

Procedure for udskiftning af certifikat

Udskiftning med overgangsperiode

Udskiftning uden overgangsperiode

Procedure for udskiftning af certifikat

Udskiftning med overgangsperiode

Udskiftning uden overgangsperiode

Anchor
_Toc477258579
_Toc477258579
Eksempler på at kalde BRS services

Content

Space Tools

Page History

Versions Compared

Old Version 50

New Version Current

Key

Format for tidsstempler

Fejlkoder

Anchor_Toc477258562_Toc477258562Målgruppe og forudsætninger

Anchor_Toc477258563_Toc477258563Snitfladebeskrivelse

Format for tidsstempler

Fejlkoder

WSDL endpoints

Forespørgsel til BRS

Anchor_Toc477258564_Toc477258564Behandlingsrelationsservice

Anchor_Toc477258565_Toc477258565Endpoint

Forespørgsel til BRS

Procedure for udskiftning af certifikat

Udskiftning med overgangsperiode

Udskiftning uden overgangsperiode

Procedure for udskiftning af certifikat

Udskiftning med overgangsperiode

Udskiftning uden overgangsperiode

Anchor_Toc477258579_Toc477258579Eksempler på at kalde BRS services

Anchor
_Toc477258562
_Toc477258562
Målgruppe og forudsætninger

Anchor
_Toc477258563
_Toc477258563
Snitfladebeskrivelse

Anchor
_Toc477258564
_Toc477258564
Behandlingsrelationsservice

Anchor
_Toc477258565
_Toc477258565
Endpoint

Anchor
_Toc477258579
_Toc477258579
Eksempler på at kalde BRS services