Page History
...
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. | Ja | ||
QueryableCvr | CVR nummer der skal have adgang til en eventuel efterfølgende notifikation. | Ja | ||
MiinimumAcceptableRelation | Et enkelt minimum acceptabelt forhold. Ud fra dette opbygges en | AcceptableRelations | En liste af acceptable relationer (f.eks. "A+, A, B") over alle relationer ovenfor og inklusive den mindst acceptable relation. | 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 | ||
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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> |
...
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 |
ActualRelationsActualRelation | 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. | 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 |
...
Følgende er et eksempel på et response fra BRS:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version='"1.0'" encoding='"UTF-8'" ?> <ns6:treatmentRelationResponseBody<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-utilitysecext-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 følgende to adresser:
1) *\[miljøurl\]gos/service/notification*
hvor den sætter operationen "notificationQuery" til rådighed.
...
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.
...
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 | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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 | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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
...
ActualRelations
...
De faktiske relationer fundet for den pågældende behandler og patient.
...
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
...
AcceptableRelations
...
Relationer der skal være til stede for at opfølgningen slettes uden at give anledning til en notifikation.
...
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
>
<ns5:SufficientRelation>true</ns5:SufficientRelation>
<ns5:ActualRelation Relation="D"/>
<ns5:RelationsBySources>
<ns5:RelationBySource>
<ns5:Source>HENVISNING_SOR</ns5:Source>
<ns5:Relation>E</ns5:Relation>
</ns5:RelationBySource>
<ns5:RelationBySource>
<ns5:Source>LPR</ns5:Source>
<ns5:Relation>E</ns5:Relation>
</ns5:RelationBySource>
<ns5:RelationBySource>
<ns5:Source>SSR</ns5:Source>
<ns5:Relation>D</ns5:Relation>
</ns5:RelationBySource>
<ns5:RelationBySource>
<ns5:Source>SIKREDE</ns5:Source>
<ns5:Relation>D</ns5:Relation>
</ns5:RelationBySource>
<ns5:RelationBySource>
<ns5:Source>REFHOST</ns5:Source>
<ns5:Relation>D</ns5:Relation>
</ns5:RelationBySource>
</ns5:RelationsBySources>
<ns5:FollowupOrdered>false</ns5:FollowupOrdered>
<ns5:UniqueReferenceId>452eff59-6ef3-46b3-98e2-07df9c7ff50d</ns5:UniqueReferenceId>
<ns5:ExternalReferenceId>97825e04-c6db-4894-bc8a-ee67070d4453</ns5:ExternalReferenceId>
</ns5:treatmentRelationResponseBody> |
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?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 | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
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 | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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 |
| ServiceProviderName | Der 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 | ||||||
|---|---|---|---|---|---|---|
| ||||||
<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 | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8" ?>
<ns6:NotificationQueryResponseBody xmlns:ns6="http://nsi.dk/nsp/behandlingsrelationer/2022/03/14/notification"
xmlns="http://www.w3.org/2000/09/xmldsig#">
<ns6:Notifications>
<ns6:Type>BRS</ns6:Type>
<ns6:SerialNumber>1</ns6:SerialNumber>
<ns6:ExternalReferenceId>efa4a5f4-2216-4f17-9010-be6eeeb36d0b</ns6:ExternalReferenceId>
<ns6:QueryableCvr>46837428</ns6:QueryableCvr>
<ns8:TreatmentRelationAlarmType xmlns:ns8="http://nsi.dk/fmki20110601/2022/03/14/brs"
xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<ns8:TreatmentRelationFollowup>
<ns8:TreatmentRelationRelayerData>
<ns8:OrganisationIdentifier>
<ns8:SORIdentifier>12345678</ns8:SORIdentifier>
</ns8:OrganisationIdentifier>
<ns8:PatientCpr>3112910017</ns8:PatientCpr>
<ns8:HealthProfessionalCpr>1007707419</ns8:HealthProfessionalCpr>
<ns8:RelationLookupTimeInterval>
<ns8:start>2022-01-01T11:05:34+01:00</ns8:start>
<ns8:end>2023-01-01T11:05:34+01:00</ns8:end>
</ns8:RelationLookupTimeInterval>
</ns8:TreatmentRelationRelayerData>
<ns8:TimeLimit>2016-01-01T11:05:34+01:00</ns8:TimeLimit>
<ns8:ExternalReferenceId>efa4a5f4-2216-4f17-9010-be6eeeb36d0b</ns8:ExternalReferenceId>
<ns8:QueryableCvr>46837428</ns8:QueryableCvr>
<ns8:MinimumAcceptableRelation xmlns=""
Relation="E"/>
<ns8:RequestSource>
<ns8:TreatmentRelationRequestBody>
<ns8:OrganisationIdentifier>
<ns8:SORIdentifier>12345678</ns8:SORIdentifier>
</ns8:OrganisationIdentifier>
<ns8:PatientCpr>3112910017</ns8:PatientCpr>
<ns8:HealthProfessionalCpr>1007707419</ns8:HealthProfessionalCpr>
<ns8:RelationLookupTimeInterval>
<ns8:start>2022-01-01T11:05:34+01:00</ns8:start>
<ns8:end>2023-01-01T11:05:34+01:00</ns8:end>
</ns8:RelationLookupTimeInterval>
<ns8:TimeLimit>2016-01-01T11:05:34+01:00</ns8:TimeLimit>
<ns8:ExternalReferenceId>efa4a5f4-2216-4f17-9010-be6eeeb36d0b</ns8:ExternalReferenceId>
<ns8:MinimumAcceptableRelation xmlns=""
Relation="E"/>
<ns8:FollowupRelations>
<ns8:All>All</ns8:All>
</ns8:FollowupRelations>
<ns8:AuthorisationIdentifier/>
<ns8:ServiceProvider>
<ns8:Name>myServiceProviderName</ns8:Name>
<ns8:Version>snapshot</ns8:Version>
<ns8:Vendor>arosii</ns8:Vendor>
</ns8:ServiceProvider>
</ns8:TreatmentRelationRequestBody>
</ns8:RequestSource>
<ns8:TreatmentRelationFollowupSerialNumber>0</ns8:TreatmentRelationFollowupSerialNumber>
<ns8:UniqueId>85baa673-dd6b-420e-acbf-fc41a25ce611</ns8:UniqueId>
</ns8:TreatmentRelationFollowup>
<ns8:ActualRelation xmlns=""
Relation="E"/>
<ns8:RelationsBySources>
<ns8:RelationBySource>
<ns8:Source>HENVISNING_SOR</ns8:Source>
<ns8:Relation>E</ns8:Relation>
</ns8:RelationBySource>
<ns8:RelationBySource>
<ns8:Source>REFHOST</ns8:Source>
<ns8:Relation>E</ns8:Relation>
</ns8:RelationBySource>
<ns8:RelationBySource>
<ns8:Source>LPR3</ns8:Source>
<ns8:Relation>E</ns8:Relation>
</ns8:RelationBySource>
<ns8:RelationBySource>
<ns8:Source>LPR</ns8:Source>
<ns8:Relation>E</ns8:Relation>
</ns8:RelationBySource>
</ns8:RelationsBySources>
</ns8:TreatmentRelationAlarmType>
</ns6:Notifications>
</ns6:NotificationQueryResponseBody |
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?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> |
...