...

Denne guide har som formål at give et overblik over, hvordan behandlingsrelationsservicen (BRS) kaldes, samt hvorledes der hentes notifikationer fra opfølgninger ed notifikationsservicenmed Notifikationsservicen.
Guiden indeholder beskrivelser af snitflader og forklaringer på de enkelte felter, eksempler på requests og responses. Derudover indeholder guiden referencer til kodeeksempler og snitfladebeskrivelser for kald til behandlingsrelationsservicen og notifikationsservicen(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.

Anchor
_Toc477258561 _Toc477258561

Baggrund

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.

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

...

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.

Bemærk at der refereres til teknisk dokumentation af snitfladeelementerne i afsnittene nedenfor med referencer sat i anførselstegn. Disse referencer peger på BRS-projektet på nspop, og det følgende præfiks er underforstået i referencerne: https://svn.nspop.dk/svn/components/brs/

...

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

...

treatmentRelationRequestBody

...

Elementer

...

Beskrivelse

...

OrganisationIdentifier

...

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

...

PatientCpr

...

Patientens cpr-nummer.

...

HealthProfessionalCpr

...

Behandlers cpr-nummer.

...

RelationLookupTimeInterval

...

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

...

TimeLimit

...

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

...

ExternalReferenceId

...

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

...

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.

...

AcceptableRelations

...

En liste af acceptable relationer (f.eks. "A+, A, B").
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).

...

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

...

AuthorisationIdentifier

...

Autorisationskode for den behandleren.

...

ServiceProvider

...

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

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.

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.

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

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.

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.

Eksempel

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

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

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:

Eksempel

Følgende er et eksempel på et 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>

Anchor
_Toc265831725 _Toc265831725

Anchor
_Toc477258569 _Toc477258569

Notifikationsservice

Anchor
_Toc265831726 _Toc265831726

Anchor
_Toc477258570 _Toc477258570

Endpoint

Notifikationsservicen udstilles på NSP'erne under adressen

*\[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

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

Forespørgsel til Notifikationsservice

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:

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.

Eksempel

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

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

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

...

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

...

ActualRelations

...

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

...

FollowupOrdered

...

Om en opfølgning er bestilt eller ej.

...

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.

...

ExternalReferenceId

...

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

Eksempel

Følgende er et eksempel på et 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>

...

Notifikationsservicen udstilles på NSP'erne under adressen

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

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

...

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

Forespørgsel til Notifikationsservice

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

...

Type

...

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

...

SerialNumber

...

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

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.

Eksempel

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

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

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:

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

...

treatmentRelationAlarm

...

Elementer

...

Beskrivelse

...

ActualRelations

...

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

...

TreatmentRelationFollowup

...

Opfølgningen der gav anledning til notifikationen.

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.

Eksempel

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

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

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:

TreatmentRelationFollowup-elementet indeholder felterne:

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

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

Eksempel

TreatmentRelationFollowup-elementet indeholder felterne:

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

Eksempel

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

<?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/brsnotification" xmlns:ns6="http://nsiwww.medcom.dk/fmki20110601/brsdgws/2006/04/dgws-1.0.xsd">
  <ns5:Notifications>
    <TreatmentRelationFollowup><ns5:Type>BRS</ns5:Type>
        <TreatmentRelationRelayerData><ns5:SerialNumber>1027</ns5:SerialNumber>
      <ns5:ExternalReferenceId>e4a4ab3f-3f7f-4e5d-a311-5942c14856b8</ns5:ExternalReferenceId>
    <OrganisationIdentifier><ns5:QueryableCvr>31908574</ns5:QueryableCvr>
    <TreatmentRelationAlarmType:TreatmentRelationAlarmType xmlns:TreatmentRelationAlarmType="http://nsi.dk/fmki20110601/brs" xmlns="http://nsi.dk/fmki20110601/brs">
      <DoctorOrganisationIdentifier>132435</DoctorOrganisationIdentifier><TreatmentRelationFollowup>
        <TreatmentRelationRelayerData>
  </OrganisationIdentifier>
        <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>

Bemærkninger til begge services

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)

/Relation>
      </ActualRelations>
    </TreatmentRelationAlarmType:TreatmentRelationAlarmType>
  </ns5:Notifications>
</ns5:NotificationQueryResponseBody>

Procedure for udskiftning af certifikat

...

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.

Anchor
_Toc477258579 _Toc477258579

Eksempler på at kalde BRS services

Anchor
_Toc477258580 _Toc477258580

Java frameworks

...