Page History
...
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. |
2.1.3 treatmentRelationResponse
...
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
...
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
...
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. |
...
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:
https://svn.softwareborsen.dk/Behandlingsrelation/
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 |
...