Versions Compared

Old Version 73

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)

...

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

Hvor path er en af følgende:

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

Eksempel:

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

...

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

Eksempel:

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

...

Code Block
languagexml
firstline1
titleBRS Request (oprindelig snitflade)
linenumberstrue
collapsetrue
<treatmentRelationRequestBody xmlns="httpshttp://nspopnsi.dk/nsp/behandlingsrelation/2022/03/14fmki20110601/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>
    <Followup>false</Followup><AcceptableRelations>
    <AuthorisationIdentifier    <Relation>A</>Relation>
    <ServiceProvider></AcceptableRelations>
    <FollowupRelations>
        <All>All</All>
    </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>

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

 Code Block
languagexml
firstline1
titleBRS Request (2025-udgave)
linenumberstrue
collapsetrue
<brs:treatmentRelationRequestBody
    xmlns:brs="http://sundhedsdatastyrelsen.dk/behandlingsrelationer/2025/03/01/brs"
    xmlns:brs1="http://nsi.dk/fmki20110601/brs">
    <brs:OrganisationIdentifier>
        <brs1:HospitalOrganisationIdentifier>561010</brs1:HospitalOrganisationIdentifier>
    </brs:OrganisationIdentifier>
    <brs:PatientCpr>3112910017</brs:PatientCpr>
    <brs:HealthProfessionalCpr>1007707419</brs:HealthProfessionalCpr>
    <brs:RelationLookupTimeInterval>
        <brs1:start>2023-01-01T16:16:31+01:00</brs1:start>
        <brs1:end>2024-01-01T16:16:31+01:00</brs1:end>
    </brs:RelationLookupTimeInterval>
    <brs:AcceptableRelations>
        <brs1:Relation>E</brs1:Relation>
    </brs:AcceptableRelations>
    <brs:TimeLimit>2016-01-01T16:16:31+01:00</brs:TimeLimit>
    <brs:QueryableCvr>46837428</brs:QueryableCvr>
    <brs:FollowupRelations>
        <brs:All>All</brs:All>
    </brs:FollowupRelations>
    <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>
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
Eksempel
Følgende er eksempler på et responses fra BRS:
 Code Block
languagexml
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
Eksempel
Følgende er eksempler på et responses fra BRS:
 Code Block
languagexml
titleResponse fra BRS (oprindelig snitflade)
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:FollowupOrdered>false</ns6:FollowupOrdered>
	<ns6:UniqueReferenceId>744bb53a-3c67-4a91-a3c1-eb91b9bc9e3e</ns6:UniqueReferenceId>
	<ns6:ExternalReferenceId>b1a35898-f699-4a76-a274-c005ee7d763a</ns6:ExternalReferenceId>
</ns6: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/wss/2004/01/oasis-200401-wss-wssecurity-utilitysecext-1.0.xsd" xmlns:ns5ns4="http://wwwdocs.medcomoasis-open.dkorg/dgwswss/20062004/0401/dgws-1.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>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>
...
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
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.
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.
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.
...
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
Eksempel
...
firstline1
titleResponse fra Notifikationservice 2022/03/14
linenumberstrue
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/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>
			<ns6:Source>LPR</ns6:Source>
			<ns6:Relation>E</ns6:Relation>
		</ns6: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 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.
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.
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.
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.
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
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.