1. Formål

Denne guide har som formål at give et overblik over, hvordan behandlingsrelationsservicen (BRS) kaldes, samt hvorledes der hentes notifikationer fra opfølgninger med Notifikationsservicen.
Guiden indeholder beskrivelser af snitflader og forklaringer på de enkelte felter, eksempler på requests og responses.

Derudover indeholder guiden referencer til kodeeksempler (Java).

Når en anvender skifter certifikat kan dette have betydning for anvendelsen af BRS. Denne guide indeholder en beskrivelse af proceduren i forbindelse med udskiftning af anvendercertifikater.

1.1. Baggrund

Behandlingsrelationsservicen (BRS) er en service, der returnerer den bedst kendte behandlingsrelation imellem en borger og en sundhedsfaglig person på et givet tidspunkt. 

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.

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.

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

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

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

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

2.3. Behandlingsrelationsservice

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

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


https://wsdl.nspop.dk/brs-nsp/service/brs?wsdl

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

Disse notifikationer kan hentes med notifikationsservicen i det decentrale NSP-miljø.

Hvis der derimod indenfor det angivne tidsrum opnås tilstrækkelig evidens, så de angivne kriterier er opfyldt, bliver der ikke genereret notifikationer.

2.3.2.1. Eksempel

BRS Request 2022/03/14 
<treatmentRelationRequestBody xmlns="http://nsi.dk/fmki20110601/2022/03/14/brs">
    <OrganisationIdentifier>
        <DoctorOrganisationIdentifier>561010</DoctorOrganisationIdentifier>
    </OrganisationIdentifier>
    <PatientCpr>3112910017</PatientCpr>
    <HealthProfessionalCpr>1007707419</HealthProfessionalCpr>
    <RelationLookupTimeInterval>
        <start>2022-01-01T12:39:38+01:00</start>
        <end>2023-01-01T12:39:38+01:00</end>
    </RelationLookupTimeInterval>
    <TimeLimit>2016-01-01T12:39:38+01:00</TimeLimit>
    <QueryableCvr>46837428</QueryableCvr>
    <MinimumAcceptableRelation Relation="E"/>
    <FollowupRelations>
        <MinimumAcceptableRelation/>
    </FollowupRelations>
    <AuthorisationIdentifier/>
    <ServiceProvider>
        <Name>myServiceProviderName</Name>
        <Version>snapshot</Version>
        <Vendor>arosii</Vendor>
    </ServiceProvider>
</treatmentRelationRequestBody>


Følgende er et eksempel på et request til BRS:

BRS Request 
<treatmentRelationRequestBody xmlns="http://nsi.dk/fmki20110601/brs">
  <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>

2.3.3. Svar fra BRS

Operationen "treatmentRelation" returnerer et treatmentRelationResponse, der opfylder DGWS. Det vil sige, at det har en wsse og en medcom header. Selve svaret er defineret som et treatmentRelationResponseBody.  Betydningen af felterne er opsummeret i tabellen nedenfor:

treatmentRelationResponse

Elementer

Beskrivelse

Felt krævet

SufficientRelation

Om der var tilstrækkelig relation til at foretage opslaget ("beslutningen" foretages af BRS på basis af værdien i AcceptableRelations angivet i kaldet).

Nej

ActualRelation

Hvad de faktiske relationer er (på baggrund af kendt data fra eksterne registre).

Ja

RelationBySources

En liste over relationer efter kilder. Hver post er et par af datakilden, hvor relationen stammer fra, og den aktuelle relation fundet fra denne datakilde.

Ja

FollowupOrdered

Om en opfølgning er bestilt eller ej.

Nej

UniqueReferenceId

Et unikt referenceid, der kan bruges til at koble forespørgslen sammen med en eventuel senere notifikation.
Indholdet af dette felt styres af BRS.

Ja

ExternalReferenceId

Værdien af feltet ExternalReferenceId fra forespørgslen. Hvis et sådant ikke var specificeret returneres et nyt generet id, forskelligt fra UniqueReferenceId.

Ja

2.3.3.1. Eksempel

Følgende er et eksempel på et response fra BRS:

Response fra BRS 2022/03/14 
<?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>
Response fra BRS 
<?xml version='1.0' encoding='UTF-8'?>
<ns6:treatmentRelationResponseBody xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns6="http://nsi.dk/fmki20110601/brs" xmlns:ns7="http://rep.oio.dk/cvr.dk/xml/schemas/2005/03/22/" xmlns:ns8="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/">
  <ns6:SufficientRelation>false</ns6:SufficientRelation>
  <ns6:ActualRelations>
    <ns6:Relation>C</ns6:Relation>
  </ns6:ActualRelations>
  <ns6:FollowupOrdered>true</ns6:FollowupOrdered>
  <ns6:UniqueReferenceId>0044ba5a-8378-4d33-b128-03522ed26e85</ns6:UniqueReferenceId>
  <ns6:ExternalReferenceId>e4a4ab3f-3f7f-4e5d-a311-5942c14856b8</ns6:ExternalReferenceId>
</ns6:treatmentRelationResponseBody>


2.4. Notifikationsservice

2.4.1. Endpoint

Notifikationsservicen udstilles på NSP'erne under følgende to adresser:

1) *\[miljøurl\]gos/service/notification*

hvor den sætter operationen "notificationQuery" til rådighed.


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


2) *\[miljøurl\]gos/service/notification20210921*

hvor den sætter operationen "notificationQuery" til rådighed. Hvis ServiceProviderName er angivet her, så anvendes det i forespørgslen til databasen, så data filtreres på baggrund af værdien af ServiceProviderName.


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


https://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.


2.4.2. Forespørgsel til Notifikationsservice

Notifikationsservicen kan forespørges på følgende to måder:


2.4.2.1.  Uden angivelse af ServiceProviderName

Hvis ServiceProviderName ikke er angivet skal man ramme det første endpoint beskrevet i afsnit 2.4.1.

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

notificationQueryRequestBody

Elementer

Beskrivelse

Felt krævet

Type

Typen af notifikationen. For en behandlingsrelation vil værdien være "BRS".

Ja

SerialNumber

Et notifikationserienummer der bruges som afsæt i databasen. Kun notifikationer med et serienummer større end eller lig dette returneres.

Nej

Man kan hente notifikationer der er "udstedt" til ens eget CVR nummer – altså notifikationer, hvis QueryableCvr matcher CVR nummeret i headeren ved kaldet til Notifikationsservicen.

Bemærk at CVR nummeret ikke indgår som en eksplicit parameter, da det er indeholdt i SOSI idkortet, der optræder i SOAP headeren.

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.

2.4.2.1.1. Eksempel

Følgende er et eksempel på et request til Notifikationsservice:

Request til Notifikationsservice 
<NotificationQueryRequestBody xmlns="http://nsi.dk/fmki20110601/notification">
  <Type>BRS</Type>
  <SerialNumber>1027</SerialNumber>
</NotificationQueryRequestBody>

2.4.2.2.  Med angivelse af ServiceProviderName

Hvis ServiceProviderName er angivet skal man ramme det andet endpoint beskrevet i afsnit 2.4.1.

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

notificationQueryRequestBody

Elementer

Beskrivelse

Felt krævet

Type

Typen af notifikationen. For en behandlingsrelation vil værdien være "BRS".

Ja

SerialNumber

Et notifikationserienummer der bruges som afsæt i databasen. Kun notifikationer med et serienummer større end eller lig dette returneres.

Nej

ServiceProviderNameDer kan være overlap mellem CVR numre, så derfor kan man bruge ServiceProviderName til yderligere filtrering.Nej

Man kan hente notifikationer der er "udstedt" til ens eget CVR nummer – altså notifikationer, hvis QueryableCvr matcher CVR nummeret i headeren ved kaldet til Notifikationsservicen.

Bemærk at CVR nummeret ikke indgår som en eksplicit parameter, da det er indeholdt i SOSI idkortet, der optræder i SOAP headeren.

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.

2.4.2.2.1. Eksempel

Følgende er et eksempel på et request til Notifikationsservice:

Request til Notifikationsservice 
<NotificationQueryRequestBody xmlns="http://nsi.dk/fmki20110601/notification">
  <Type>BRS</Type>
  <SerialNumber>1027</SerialNumber>
  <ServiceProviderName>LAR service</ServiceProviderName>
 </NotificationQueryRequestBody>

2.4.3. Svar fra Notifikationsservice

Operationen "notificationQuery" returnerer et notificationQueryResponse der opfylder DGWS. Det vil bl.a. sige, at det har en wsse og en medcom header.  Svaret indeholder de første 100 notifikationer med serienummer højere end eller lig det der er angivet i forespørgslen.

Notifikationerne returneres i sorteret rækkefølge. Hver notifikation indeholder følgende informationer:

notificationQueryResponse

Elementer

Beskrivelse

Felt krævet

Type

Typen af notifikationen. Fra BRS version 2.0.1 vil dette altid være "BRS".

Ja

SerialNumber

Serienummer for notifikationen.

Nej

ExternalReferenceId

Det eksterne reference id. Værdien af dette felt hentes fra det oprindelige kald til behandlingsrelationsservice.

Ja

QueryableCvr

CVR-nummer på den instans der kan læse notifikationen. Matcher det fundet i headeren for notifikationsforespørgslen.

Ja

Payload

Et element der indeholder data for notifikationen. Fra BRS version 2.0.1 vil dette altid være en behandlingsrelation, dvs. typen treatmentRelationAlarm.

Ja


Notifikationers "payload" er af typen TreatmentRelationAlarm. Dette indeholder følgende elementer:

treatmentRelationAlarm

Elementer

Beskrivelse

Felt krævet

TreatmentRelationFollowup

Opfølgningen der gav anledning til notifikationen.

Ja

ActualRelation

De faktiske relationer fundet for den pågældende behandler og patient.

Ja

RelationsBySources

En liste over relationer efter datakilde. 

Ja


TreatmentRelationFollowup-elementet indeholder felterne:

treatmentRelationFollowup

Elementer

Beskrivelse

Felt krævet

TreatmentRelationFollowupSerialNumber

Serienummeret for den pågældende opfølgning.

Nej

TreatmentRelationRelayerData

Datastruktur med de nødvendige data for at udtrække gældende relationer, se tabellen nedenfor.

Ja

TimeLimit

Tidsgrænse for en relations opståelse. En eventuel notifikation oprettes hvis der efter denne tidsgrænse ikke er opstået en gyldig relation.

Ja

RequestSource

Det komplette kald (treatmentRelationRequestBody) der blev sendt til BRS da opfølgningen blev bestilt.

Ja

ExternalReferenceId

Samme værdi som i det oprindelige svar fra BRS.

Ja

UniqueId

Samme værdi som i det oprindelige svar fra BRS.

Ja

QueryableCvr

CVR-nummer på instansen der har ret til at læse eventuelle notifikationer.

Ja

MinimumAcceptableRelation

Relationer over og inklusive MinimumAcceptable Relation, der skal være til stede, for at opfølgningen kan slettes uden at give anledning til en meddelelse.

Ja


Elementet TreatmentRelationRelayerData indeholder følgende data, der er nok til at identificere de kendte relationer mellem en behandler og en patient:

TreatmentRelationRelayerData

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

Patientents CPR-nummer.

Ja

HealthProfessionalCpr

Den sundhedsfagliges CPR-nummer.

Ja

RelationLookupTimeInterval

Intervallet inden for hvilket relationen skal forefindes. Vil i første omgang være trukket ud fra id-kortet i den oprindelige treatmentRelationRequest (Intervallet sættes til id-kortets gyldighedsperiode).

Ja


2.4.3.1. Eksempel

Response fra Notifikationservice 2022/03/14 
<?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



Response fra Notifikationsservice 
<?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>

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

2.5.1. Udskiftning med overgangsperiode

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

  1. Det aftales med NSP-operatøren, hvornår det nye certifikat tages i brug. NSP-operatøren whitelister certifikatets CVR-nummer på dette tidspunkt.
  2. 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.
  3. Ved overgangsperiodens udløb fjerner NSP-operatøren det gamle CVR-nummer fra whitelisten.

2.5.2. Udskiftning uden overgangsperiode

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

  1. Anvenderen aftaler med NSP-operatøren, hvornår der udskiftes certifikat. NSP-operatøren whitelister det nye certifikat.
  2. 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.
  3. På det aftale tidspunkt ophører anvenderen med at kalde BRS.
  4. 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.
  5. NSP-operatøren melder klar til anvenderen.
  6. Anvenderen begynder at anvende BRS igen med det nye certifikat.


3. Eksempler på at kalde BRS services

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.

  • No labels