Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Navitabs
rootBRS - Leverancebeskrivelse
includeroottrue

...


Version 1.2, 2017-03-14

Anchor
_Toc477258559
_Toc477258559
Indholdsfortegnelse
Anchor
_GoBack
_GoBack

...

Slutbrugerne er i denne sammenhæng f.eks. udviklere og arkitekter hos leverandører, som ønsker at integrere til BRS.
Det forudsættes at læseren kender til Den Gode Webservice (DGWS) og den nationale serviceplatform (NSP).

Anchor
_Toc477258563
_Toc477258563
Snitfladebeskrivelse

Behandlingsrelationsservicen giver mulighed for at bestille opfølgninger gennem brug af notifikationsservicen. Da det forventes at denne option vil blive brugt af de fleste anvendere, er begge snitflader dokumenteret nedenfor.
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/public/components/brs/latest/code/+*

Anchor
_Toc477258564
_Toc477258564
Behandlingsrelationsservice

Anchor
_Toc477258565
_Toc477258565
Endpoint

Wiki Markup
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. 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 (dNSP i TEST2-miljøet):
*http://test2-dnsp.ekstern-test.nspop.dk:8080/brs-nsp/service/brs*

Anchor
_Toc477258566
_Toc477258566
treatmentRelationRequestBody

Body er defineret som et element af typen treatmentRelationRequestBody, der er en complexType indeholdende en række felter, er specificeret i
"common/src/main/resources/xsd/"
Frem for at læse disse foreslås det at studere eksemplet på en korrekt forespørgsel i
"doc/brs/bilag/requests-and-responses/"
En korrekt forespørgsel skal indeholde informationer om følgende:

treatmentRelationRequestBody

 


Elementer

Beskrivelse

OrganisationIdentifier

Organisationen inden for hvilken relationen skal findes. Feltet er struktureret og kan indeholde et sks, ydernummer 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.


Anchor
_Toc477258567
_Toc477258567
treatmentRelationResponse

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 som defineret i
"common/src/main/resources/xsd/"
Svaret indeholder information om:

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.


Et eksempel på et svar fra servicen kan findes i
"bilag/requests-and-responses/"
Den komplette wsdl for servicen kan findes i
"common/src/main/resources/wsdl"

...

Anchor
_Toc265831726
_Toc265831726
Anchor
_Toc477258570
_Toc477258570
Endpoint

Wiki Markup
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 (dNSP i TEST2-miljøet):
*http://test2-dnsp.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._

Anchor
_Toc265831727
_Toc265831727
Anchor
_Toc477258571
_Toc477258571
Betingelser for kald

...

Body er defineret som et element af typen notificationQueryRequestBody, der er en complexType indeholdende en række felter, der er specificeret i
"common/src/main/resources/xsd/notification/"
Frem for at læse denne foreslås det at studere eksemplet på en korrekt forespørgsel i
"doc/bilag/requests-and-responses/"
En korrekt forespørgsel skal indeholde informationer om følgende:

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.


Anchor
_Toc477258573
_Toc477258573
notificationQueryResponse

Operationen "notificationQuery" returnerer et notificationQueryResponse der opfylder DGWS. Det vil bl.a. sige, at det har en wsse og en medcom header. Selve svaret er defineret som et notificationQueryResponseBody som defineret i
"common/src/main/resources/xsd/notification/"
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

Type

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

SerialNumber

Serienummer for notifikationen.

ExternalReferenceId

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

QueryableCvr

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

Payload

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


Et eksempel på et svar fra servicen kan findes i
"doc/bilag/requests-and-responses/"
Den komplette wsdl for servicen kan findes i
"common/src/main/resources/wsdl"
Notifikationers "payload" er af typen TreatmentRelationAlarm. Skema for dette findes her:
"common/src/main/resources/xsd/brs/treatmentRelationAlarm.xsd"
Dette indeholder følgende elementer:

Anchor
_Toc477258574
_Toc477258574
TreatmentRelationAlarm

treatmentRelationAlarm

 


Elementer

Beskrivelse

ActualRelations

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

TreatmentRelationFollowup

Opfølgningen der gav anledning til notifikationen.

Anchor
_Toc477258575
_Toc477258575
TreatmentRelationFollowup

TreatmentRelationFollowup-elementet er af typen beskrevet i
"common/src/main/resources/xsd/brs/treatmentRelationFollowup.xsd"
Denne indeholder felterne:

treatmentRelationFollowup

 


Elementer

Beskrivelse

TreatmentRelationFollowupSerialNumber

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

TreatmentRelationRelayerData

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

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.

RequestSource

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

ExternalReferenceId

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

UniqueId

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

QueryableCvr

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

AcceptableRelations

Relationer der skal være til stede for at opfølgningen slettes uden at give anledning til en notifikation.


Anchor
_Toc477258576
_Toc477258576
TreatmentRelationRelayerData

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

TreatmentRelationRelayerData

 


Elementer

Beskrivelse

OrganisationIdentifier

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

PatientCpr

Patientents CPR-nummer.

HealthProfessionalCpr

Den sundhedsfagliges CPR-nummer.

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

Anchor
_Toc477258577
_Toc477258577
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"

Anchor
_Toc265831730
_Toc265831730
Anchor
_Toc477258578
_Toc477258578
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)


Anchor
_Toc477258579
_Toc477258579
Eksempler på at kalde services

...

Kilden til dette dokument kan findes på nspop:
{+}https://svn.nspop.dk/svn/trifork/brs/trunk/doc/brs/+

Version

Dato

Ændring

Ansvarlig

0.1

2011-06-15

Initielt Dokument

Trifork

0.2

2011-07-27

Ændringer jf. skift til generel notifikationsservice indført.

Trifork

0.3

2011-08-10

Opsplitning jf. opsplitning af BRS og GOS

Trifork

0.9

2013-03-14

Grundig bearbejdning i samarbejde mellem sundhed.dk og NSI.

NSI/CHE
Sundhed.dk/HESO

1.0

2013-10-23

Rettet SVN links og xsd link der pegede forkert

Trifork

1.1

2017-03-08

Tilrettet BRS2

Trifork

1.2

2017-03-14

Konkretiseret afsnit om notifikationer

Trifork