Differences

This shows you the differences between two versions of the page.

--- fmk:1.6.0:xml-elementer:alternativ_request_response_header [2026-08-14 12:42] – [Request headers] andm
+++ fmk:1.6.0:xml-elementer:alternativ_request_response_header [2026-10-09 11:51] (current) – [FMKConfigurationLastUpdated] andm
@@ Line 1: / Line 1: @@
-======= Alternativt bud på request/response headers =======
+======= FMKRequest/response headers i body=======
 Som følge af klienternes ønske om en ændret udformning af request/Response headeren i 1.6.0 følger her en beskrivelse af et alternativt bud.
-**OBS. Nedenstående afventer høring, og er dermed ikke endeligt vedtaget.**
 SecurityHeader og MedcomHeader er stadigvæk defineret uændret i DGWS standarden.
@@ Line 16: / Line 14: @@
     <ConsentHeader> ... </ConsentHeader>
     <MinLogSessionId>...</MinLogSessionId>
+    <FMKConfigurationLastUpdated>...</FMKConfigurationLastUpdated>
     <PreflightOnly/>
     <PartOfBatchOperation/>
@@ Line 88: / Line 87: @@
 ==== FMKConfigurationLastUpdated ====
-Der er mulighed for at få oplysninger om specifikke dele af FMK's konfiguration, i tilfælde af at det er nødvendigt at udstille information om ændringen, så klienter kan indrette sig efter hvilken konfiguration, FMK er i. Sædvanligvis foretages der ikke større ændringer i FMK uden at det indgår som en del af en ny FMK snitflade/extension, men i enkelte tilfælde foretages også semantiske ændringer der kan styres vha. disse konfigurationsoplysninger. Hvis FMKConfigurationLastUpdated sendes med i et kald til FMK, returneres FMKConfigurationUpdatedWarning elementet i response headeren, i tilfælde af at konfigurationen har ændret sig siden det tidsstempel der er angivet i FMKConfigurationLastUpdated elementet. Herefter kan klienten kalde [[fmk:1.6.0:services:hent_fmk_konfiguration|GetFMKConfiguration]] servicen og indhente detaljerede oplysninger om konfiguration. Hvis elementet udelades, returnes ingen konfigurationsinformation.
+Der er mulighed for at få oplysninger om specifikke dele af FMK's konfiguration, hvis det er nødvendigt at udstille information om ændringen.
+På den måde kan klienter indrette sig efter hvilken konfiguration, FMK er i.
+Sædvanligvis foretages der ikke større ændringer i FMK uden at det indgår som en del af en ny FMK snitflade/extension. I enkelte tilfælde foretages semantiske ændringer, der kan styres vha. disse konfigurationsoplysninger.
+FMKConfigurationLastUpdated er et tidsstempel, der kan sendes med i et kald til FMK.
+Hvis konfigurationen har ændret sig siden tidsstempelet, så returneres FMKConfigurationUpdatedWarning elementet i responset. Det er et tidsstempel, der indikerer, hvornår den sidste konfigurationsændring er trådt i kraft.
+Der bliver altså ikke returneret //hvilke// ændringer, der er trådt i kraft, men kun en implicit notifikation om, at der er sket ændringer efter klientens sidste opdatering.
+Klienten kan efterfølgende kalde [[fmk:1.6.0:services:hent_fmk_konfiguration|GetFMKConfiguration]] servicen og indhente detaljerede oplysninger om den specifikke konfiguration. Hvis elementet udelades, returnes ingen konfigurationsinformation.
 Eksempel:
@@ Line 229: / Line 236: @@
 <code xml>
     <soap:Header>
+        <!-- Tidligere en del af "FMKResponseHeader", men er nu enkeltelementer -->
         <KnownPersonIdentifier> ... </KnownPersonIdentifier>
         <FMKConfigurationUpdatedWarning>...</FMKConfigurationUpdatedWarning>
@@ Line 235: / Line 243: @@
     <soap:Body>
         <Response>
+            <!-- Flyttet fra header -->
             <FMKResponseHeader>
                 <MedicinecardInvalid> ...</MedicinecardInvalid>
@@ Line 290: / Line 299: @@
 ==== HiddenData ====
-Information omkring privatmarkering eller af andre årsager skjulte data. Dette felt er generaliseret i forhold til tidligere af hensyn til en evt. kommende MinSpærring integration. I tilfælde af udeladte data angives nu et element ''<HiddenData>'' med yderligere underelement der beskriver årsagen. P.t. vil kun ''<NegativeConsent>'' være implementeret, men altså med mulighed for udvidelser. Eksempel:
+Information omkring privatmarkering eller af andre årsager skjulte data.
+I tilfælde af udeladte data angives elementet ''<HiddenData>'' med yderligere underelement der beskriver årsagen.
+Det inkluderer identifikation på klienten, årsag til udeladelse samt en liste af de udeladte elementer
+OBS! Dette felt er generaliseret i forhold til tidligere af hensyn til en evt. kommende MinSpærring integration. P.t. vil kun ''<HasNegativeConsent>'' være implementeret som grundlag, men altså med mulighed for udvidelser.
+Eksempel:
 <code xml>
@@ Line 296: / Line 312: @@
   <PersonIdentifier source="CPR">2512489996</PersonIdentifier>
   <HasNegativeConsent/>
+  <DrugMedicationsWithNegativeConsentList>
+    <DrugMedicationsWithNegativeConsent>
+      <Identifier> 123 </Identifier>
+      <Version> 1 </Version>
+    </DrugMedicationWithNegativeConsent>
+    <DrugMedicationsWithNegativeConsent>
+    ...
+    </DrugMedicationsWithNegativeConsent>
+  <DrugMedicationsWithNegativeConsentList>
 </HiddenData>
 </code>