Versions Compared

Old Version 70

changes.mady.by.user Kristian Dorland

Saved on

compared with

New Version Current

changes.mady.by.user Joakim Schack Betzer

Saved on

Key

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

...

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.

...

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:

...

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)

...

Path for WSDL uden security headers

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

Hvor path er en af følgende:

  • brs?wsdlbrs20220314
  • 20250301/brs?wsdl
  • notification?wsdl
  • notification20210921?wsdl
  • notification20220314?wsdl

Eksempel:

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

...

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

Eksempel:

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

Anchor
_Toc477258564
_Toc477258564
Behandlingsrelationsservice

Versioner

Snitfladen til behandlingsrelationsservicen findes i to versioner, hver med sin egen version af treatmentRelation. Der er den oprindelige udgave, og den nye udgave fra 2025. I den nye udgave er ændringen at man får en liste af evidenskilder med tilbage i svaret.

Anchor
_Toc477258565
_Toc477258565
Endpoint

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

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

hvor den stiller operationen "treatmentRelation" til 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.

...

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). Bruges til logformål.

Ja

IncludeAllRelations

Hvis

...

Nej

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.

...

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

Eksempel

Code Block
languagexml
firstline1
titleBRS Request (oprindelig snitflade)
linenumberstrue
collapsetrue
<treatmentRelationRequestBody xmlns="httpshttp://nspopnsi.dk/nsp/behandlingsrelation/2022/03/14/fmki20110601/brs">
    <OrganisationIdentifier>
        <DoctorOrganisationIdentifier>561010<<HospitalOrganisationIdentifier>A12312</DoctorOrganisationIdentifier>HospitalOrganisationIdentifier>
    </OrganisationIdentifier>
    <PatientCpr>3112910017</PatientCpr>
    <HealthProfessionalCpr>1007707419</HealthProfessionalCpr>
    <RelationLookupTimeInterval>
        <start>2023-01-01T16:16:31+01:00</start>
        <end>2024-01-01T16:16:31+01:00</end>
    </RelationLookupTimeInterval>
    <MinimumAcceptableRelation>E</MinimumAcceptableRelation>
    <TimeLimit>2016-01-01T16:16:31+01<TimeLimit>2023-09-30T11:04:37+02:00</TimeLimit>
    <QueryableCvr>46837428</QueryableCvr>
    <AcceptableRelations>
        <Relation>A</Relation>
    <Followup>false</Followup> </AcceptableRelations>
    <FollowupRelations>
        <All>All</All>
    <AuthorisationIdentifier /> </FollowupRelations>
    <AuthorisationIdentifier>Aut</AuthorisationIdentifier>
    <ServiceProvider>
        <Name>myServiceProviderName</Name>
        <Version>snapshot<<Vendor>arosii</Version>Vendor>
        <Vendor>arosii<<Version>snapshot</Vendor>Version>
    </ServiceProvider>
	<IncludeAllRelations>true</IncludeAllRelations>
</treatmentRelationRequestBody>

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

 Code Block
languagexml
firstline1
 Code Block
languagexml
titleBRS Request (2025-udgave)
linenumberstrue
collapsetrue
<treatmentRelationRequestBody xmlns<brs:treatmentRelationRequestBody
    xmlns:brs="http://sundhedsdatastyrelsen.dk/behandlingsrelationer/2025/03/01/brs"
    xmlns:brs1="http://nsi.dk/fmki20110601/brs">
  <OrganisationIdentifier>  <brs:OrganisationIdentifier>
     <DoctorOrganisationIdentifier>132435</DoctorOrganisationIdentifier>
   <brs1:HospitalOrganisationIdentifier>561010</brs1:HospitalOrganisationIdentifier>
    </brs:OrganisationIdentifier>
  <PatientCpr>0101601951</  <brs:PatientCpr>3112910017</brs:PatientCpr>
  <HealthProfessionalCpr>0101601803</  <brs:HealthProfessionalCpr>1007707419</brs:HealthProfessionalCpr>
   <RelationLookupTimeInterval>
 <brs:RelationLookupTimeInterval>
       <start>2013-09-30T00:00:00+02 <brs1:start>2023-01-01T16:16:31+01:00</brs1:start>
    <end>2013-10-25T23:59:00+02    <brs1:end>2024-01-01T16:16:31+01:00</brs1:end>
    </brs:RelationLookupTimeInterval>
  <TimeLimit>2013-09-30T11:04:37+02:00</TimeLimit>
  <QueryableCvr>31908574</QueryableCvr>
  <AcceptableRelations>
    <Relation>A</  <brs:AcceptableRelations>
        <brs1:Relation>E</brs1:Relation>
    <Relation>B<</Relation>brs:AcceptableRelations>
  </AcceptableRelations>
  <FollowupRelations>  <brs:TimeLimit>2016-01-01T16:16:31+01:00</brs:TimeLimit>
    <All>All</All>
  </<brs:QueryableCvr>46837428</brs:QueryableCvr>
    <brs:FollowupRelations>
  <AuthorisationIdentifier>DM712</AuthorisationIdentifier>
  <ServiceProvider>
    <Name>SJ</Name><brs:All>All</brs:All>
    <Version>0.1</Version></brs:FollowupRelations>
    <Vendor>Sundhed.dk</Vendor>
  </ServiceProvider>
</<brs:AuthorisationIdentifier></brs:AuthorisationIdentifier>
    <brs:ServiceProvider>
        <brs1:Name>myServiceProviderName</brs1:Name>
        <brs1:Vendor>arosii</brs1:Vendor>
        <brs1:Version>snapshot</brs1:Version>
    </brs:ServiceProvider>
    <brs:IncludeAllRelations>true</brs:IncludeAllRelations>
</brs:treatmentRelationRequestBody>
...
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
Eksempel
Følgende er et eksempel eksempler på et response responses fra BRS:
 Code Block
firstlinelanguage1xml
titleResponse fra BRS (oprindelig snitflade)
linenumberstrue
collapsetrue
<ns6:treatmentRelationResponseBody xmlns:ns6="http://nsi.dk/fmki20110601/brs" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns5="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns7="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns8="http://rep.oio.dk/cvr.dk/xml/schemas/2005/03/22/">
	<ns6:SufficientRelation>true</ns6:SufficientRelation>
	<ns6:ActualRelations>
		<ns6:Relation>D</ns6:Relation>
	</ns6:ActualRelations>
	<ns6:RelationsBySources>
		<ns6:RelationBySource>
		FollowupOrdered>false</ns6:FollowupOrdered>
	<ns6:Source>LPR<UniqueReferenceId>744bb53a-3c67-4a91-a3c1-eb91b9bc9e3e</ns6:Source>UniqueReferenceId>
			<ns6:Relation>E<ExternalReferenceId>b1a35898-f699-4a76-a274-c005ee7d763a</ns6:Relation>ExternalReferenceId>
		</ns6:RelationBySource>
		<ns6:RelationBySource>
			<ns6:Source>SIKREDE</ns6:Source>
			<ns6:Relation>D</ns6:Relation>
		</ns6:RelationBySource>
		<ns6:RelationBySource>
			<ns6:Source>REFHOST</ns6:Source>
			<ns6:Relation>D</ns6:Relation>
		</ns6:RelationBySource>
		<ns6:RelationBySource>
			<ns6:Source>HENVISNING_SOR</ns6:Source>
			<ns6:Relation>E</ns6:Relation>
		</ns6:RelationBySource>
		<ns6:RelationBySource>
			<ns6:Source>SSR</ns6:Source>
			<ns6:Relation>D</ns6:Relation>
		</ns6:RelationBySource>
	</ns6:RelationsBySources>
	<ns6:FollowupOrdered>false</ns6:FollowupOrdered>
	<ns6:UniqueReferenceId>bd80bca9-5f30-4e4c-b30f-0ebceb16ec24</ns6:UniqueReferenceId>
	<ns6:ExternalReferenceId>040865cd-6a2e-40b9-a574-e9a88e25d5d7</ns6:ExternalReferenceId>
</ns6:treatmentRelationResponseBody>
 Code Block
languagexml
titleResponse fra BRS uden RelationBySource
collapsetrue
treatmentRelationResponseBody>
 Code Block
languagexml
firstline1
titleResponse fra BRS (2025-udgave)
linenumberstrue
collapsetrue
<ns6:treatmentRelationResponseBody xmlns:ns6="http://nsi.dk/fmki20110601/brs" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns4="http://docs.oasis-open.org/<ns6:treatmentRelationResponseBody xmlns:ns6="http://nsi.dk/fmki20110601/brs" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secextutility-1.0.xsd" xmlns:ns4ns5="http://docswww.oasis-openmedcom.orgdk/wssdgws/20042006/0104/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns5="http://www.medcom.dk/dgws/2006/04/dgws-1.0dgws-1.0.xsd" xmlns:ns7="http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/" xmlns:ns8="http://rep.oio.dk/cvr.dk/xml/schemas/2005/03/22/">
	<ns6:SufficientRelation>true</ns6:SufficientRelation>
	<ns6:ActualRelations>
		<ns6:Relation>D</ns6:Relation>
	</ns6:ActualRelations>
	<ns6:FollowupOrdered>false</ns6:FollowupOrdered>RelationsBySources>
		<ns6:RelationBySource>
			<ns6:UniqueReferenceId>744bb53a-3c67-4a91-a3c1-eb91b9bc9e3e<Source>LPR</ns6:UniqueReferenceId>Source>
			<ns6:ExternalReferenceId>b1a35898-f699-4a76-a274-c005ee7d763a<Relation>E</ns6:ExternalReferenceId>Relation>
		</ns6:treatmentRelationResponseBody>
...
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
Bemærk: NSP miljøernes loadbalancer router trafikken fra ovennævnte endpoint til brs-nsp/service/notification, idet dette er adressen i BRS.
Forespørgsel til Notifikationsservice
Notifikationsservicen kan forespørges på følgende to måder:
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
RelationBySource>
		<ns6:RelationBySource>
			<ns6:Source>SIKREDE</ns6:Source>
			<ns6:Relation>D</ns6:Relation>
		</ns6:RelationBySource>
		<ns6:RelationBySource>
			<ns6:Source>HENVISNINGER</ns6:Source>
			<ns6:Relation>E</ns6:Relation>
		</ns6:RelationBySource>
		<ns6:RelationBySource>
			<ns6:Source>SSR</ns6:Source>
			<ns6:Relation>D</ns6:Relation>
		</ns6:RelationBySource>
	</ns6:RelationsBySources>
	<ns6:FollowupOrdered>false</ns6:FollowupOrdered>
	<ns6:UniqueReferenceId>bd80bca9-5f30-4e4c-b30f-0ebceb16ec24</ns6:UniqueReferenceId>
	<ns6:ExternalReferenceId>040865cd-6a2e-40b9-a574-e9a88e25d5d7</ns6:ExternalReferenceId>
</ns6:treatmentRelationResponseBody>
 Anchor
_Toc265831725
_Toc265831725
 Anchor
_Toc477258569
_Toc477258569
Notifikationsservice
 Anchor
_Toc265831726
_Toc265831726
 Anchor
_Toc477258570
_Toc477258570
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
Bemærk: NSP miljøernes loadbalancer router trafikken fra ovennævnte endpoint til brs-nsp/service/notification, idet dette er adressen i BRS.
Forespørgsel til Notifikationsservice
Notifikationsservicen kan forespørges på følgende to måder:
Uden angivelse af ServiceProviderName
Hvis ServiceProviderName ikke er angivet skal man ramme det første 
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:
 Code Block
languagexml
titleRequest til Notifikationsservice
collapsetrue
<NotificationQueryRequestBody xmlns="http://nsi.dk/fmki20110601/notification">
  <Type>BRS</Type>
  <SerialNumber>1027</SerialNumber>
</NotificationQueryRequestBody>
Med angivelse af ServiceProviderName
Hvis ServiceProviderName er angivet skal man ramme det andet endpoint beskrevet i afsnit 2.4.1.
...
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.
...
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:
 Code Block
languagexml
titleRequest til Notifikationsservice
collapsetrue
<NotificationQueryRequestBody xmlns="http://nsi.dk/fmki20110601/notification">
  <Type>BRS</Type>
  <SerialNumber>1027</SerialNumber>
  <ServiceProviderName>LAR service</ServiceProviderName>
 </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:
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:
notificationQueryResponse
notificationQueryRequestBody
Elementer
Beskrivelse
Felt krævet
Type
Typen af notifikationen. Fra BRS version 2.0.1 vil dette altid For en behandlingsrelation vil værdien 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
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.
Eksempel
Følgende er et eksempel på et request til Notifikationsservice:
 Code Block
languagexml
titleRequest til Notifikationsservice
collapsetrue
<NotificationQueryRequestBody xmlns="http://nsi.dk/fmki20110601/notification">
  <Type>BRS</Type>
  <SerialNumber>1027</SerialNumber>
  <ServiceProviderName>LAR service</ServiceProviderName>
 </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:
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
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:
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:
treatmentRelationAlarmTreatmentRelationRelayerData
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
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
Eksempel
...
firstline1
titleResponse fra Notifikationservice 2022/03/14
linenumberstrue
collapsetrue
...
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
Eksempel
...
 Code Block
languagexml
titleResponse fra Notifikationsservice
linenumberstrue
collapsetrue
<?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>
...
Se feks: STS - Guide til anvendere samt SEAL.JAVA 2 - Guide til anvendere og SEAL.NET Guide til anvendere.