Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Navitabs
rootBRS - Leverancebeskrivelse
firsttabBehandlingsrelationsservice (BRS)
includeroottrue


1      Formål

Denne guide har som formål at give et overblik over hvordan behandlings­relationsservicen (BRS) kaldes. Guiden indeholder referencer til kodeeksempler og snitfladebeskrivelser for både BRS og opfølgningsservicen.


Table of Contents

1.1     Baggrund

Behandlingsrelationsservicen (BRS) er en service, der returnerer den bedst kendte behandlingsrelation imellem en borger og en sundhedsfaglig person på et givet tidspunkt.

...

Man kan i kaldet til BRS vælge at lade servicen håndtere denne kompleksitet, idet man gennem en række parametre kan konfigurere BRS-håndteringen og styre hvordan – og hvornår – der skal leveres et svar til kaldet.

1.2     Målgruppe og forudsætninger

Slutbrugerne er i denne sammenhæng f.eks. udviklere og arkitekter hos leverandører, som ønsker at integrere til/med komponenten eller anvende den i deres systemer.

Det forudsættes, at læseren kender til Den Gode Webservice (DGWS) og den nationale serviceplatform (NSP).

2      Snitfladebeskrivelse

Behandlingsrelationsservicen giver mulighed for automatisk at bestille opfølgninger gennem brug af notifikations­servicen, og da det forventes at denne option vil blive taget i brug 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å softwarebørsen, og det følgende præfiks er underforstået i referencerne:

https://svn.softwareborsen.dk/Behandlingsrelation/

2.1     Behandlingsrelationsservice

2.1.1      Endpoint

Behandlingsrelationsservicen kører på NSP'erne under adressen:

...

http://test2-dnsp.ekstern-test.nspop.dk:8080/brs-nsp/service/brs

2.1.2      treatmentRelationRequestBody

Body er defineret som et element af typen treatmentRelationRequestBody, der er en complexType indeholdende en række felter, er specificeret i:

...

treatmentRelationRequestBody
ElementerBeskrivelse
OrganisationIdentifierOrganisationen inden for hvilken relationen skal findes. Feltet er struktureret og kan indeholde et sks, ydernummer eller EAN-nummer.
PatientCprPatientens cpr-nummer.
HealthProfessionalCprBehandlers 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).

FollowupRelationsEn 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”.
AuthorisationIdentifierAutorisationskode for den behandleren.
ServiceProviderTekststreng indeholdende navnet på serviceudbyderen (f.eks. FMK). Bruges til logformål.

2.1.3      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/wsdl”

2.2     BRS-notifikationer via Notifikationsservicen

Hvis der i kaldet til behandlingsrelationsservicen er angivet at der skal bestilles opfølgninger i opfølgningsservicen, vil der komme notifikationer, hvis de angivne kriterier ikke er opfyldt indenfor det i kaldet angivne tidsrum.

...

Dette inde­holder følgende elementer:

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

2.2.2      TreatmentRelationFollowup

TreatmentRelationFollowup-elementet er af typen beskrevet i

...

treatmentRelationFollowup
ElementerBeskrivelse
TreatmentRelationFollowupSerialNumberSerienummeret for den pågældende opfølgning.
TreatmentRelationRelayerDataDatastruktur 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.

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

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

3      Eksempler på at kalde services

3.1     Java frameworks

JAVA SEAL er et open source bibliotek, der kan håndtere SOSI IDKort, DGWS og integration til SOSI-STS. Biblioteket er dokumenteret på digitaliser.dk:

http://digitaliser.dk/group/374971

3.1.1      Eksempelkode i Java

Der er udviklet testkode, der gør brug af JAVA SEAL biblioteket, sammen med JAXWS webservicestakken til at kalde de to services. Eksemplet kan bruges til at teste de forskellige service-håndtag fra ydersiden. Man kan med fordel tage udgangspunkt i eksemplet, når der implementeres en javabaseret webserviceklient, der gør brug af BRS og opfølgningsservicen.

...

Code Block
production/src/main/java/dk/nsi/behandlingsrelationservice/BRSQueries.java

3.2     .NET frameworks

Seal.NET er et open source framework, der kan håndtere SOSI IDKort, DGWS og integration til SOSI-STS. Seal.NET er dokumenteret på digitaliser.dk:

...

Der er pt. ikke skrevet eksempelkode på at kalde de to services fra et .NET projekt, men der er WSDL’er til rådighed, som man kan anvende i Visual Studio’s webservice wizard, kombineret med Seal.NET.

4      Ændringslog

Kilden til dette dokument kan findes på softwarebørsen:

...