Differences

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

--- fmk:1.6.0:xml-elementer:request_response_headers [2025-10-31 13:51] – [ExtendedValidationHeader] chj
+++ fmk:1.6.0:xml-elementer:request_response_headers [2026-03-06 08:53] (current) – external edit 127.0.0.1
@@ Line 48: / Line 48: @@
         <OrgResponsibleName>ROS IT-afdeling</OrgResponsibleName>
         <OrgUsingName>Alb Plastikkirurgisk Dagafdeling</OrgUsingName>
-        <OrgUsingID NameFormat="medcom:skscode">8001506</OrgUsingID>
+        <OrgUsingID NameFormat="medcom:sor">621491000016008</OrgUsingID>
         <RequestedRole>Læge</RequestedRole>
     </WhitelistingHeader>
@@ Line 81: / Line 81: @@
 ==== Paging ====
-Hvis der i et svar returneres en stor mængde elementer, er der mulighed for at der i kaldet kan angives parametre til brug for paginering, således at de returnede svar ikke blive unødigt store. FMK vil selv i visse tilfælde gøre det uden klienten har bedt om det, igen for at undgå, at svarene bliver så store så svartiderne risikerer at blive påvirkede. Hvis paginering er anvendt returneres information herom i response headeren (link :!: ) som klienten herefter kan kopiere ind i request headeren for at hente næste "page" af data hvis det måtte være relevant.
+Hvis der i et svar returneres en stor mængde elementer, er der mulighed for at der i kaldet kan angives parametre til brug for paginering, således at de returnede svar ikke blive unødigt store. FMK vil selv i visse tilfælde gøre det uden klienten har bedt om det, igen for at undgå, at svarene bliver så store så svartiderne risikerer at blive påvirkede. Hvis paginering er anvendt returneres information herom i [[fmk:1.6.0:xml-elementer:request_response_headers##paging|response headeren]] som klienten herefter kan kopiere ind i request headeren for at hente næste "page" af data hvis det måtte være relevant.
 I requestet skal angives hhv.
@@ Line 137: / Line 137: @@
 </FMKRequestHeader>
 </code>
+Ikke alle kald eller delementer af svar supporterer paging. Der vil senere blive tilføjet information om hvilke services og delelementer hvorpå dette supporteres.
 ==== ExtendedValidationHeader ====
 Herunder angives de fejlkoder vedr. udvidet validering, som der hhv. ønskes foretaget udvidet validering for, og som der ønskes ignoreret. Der findes 2 typer udvidet validering:
-* forud valgte udvidede valideringer, som vil blive anvendt med mindre de er angivet i SkipValidations elementet (eller fravalgt i system whitelistingen)
+  * forud valgte udvidede valideringer, som vil blive anvendt med mindre de er angivet i SkipValidations elementet (eller fravalgt i system whitelistingen)
-* udvidede valideringer som klienten eksplicit kan bede om at få udført, ved at angive dem i ApplySelectedOptionalValidations elementet i request headeren.
+  * udvidede valideringer som klienten eksplicit kan bede om at få udført, ved at angive dem i ApplySelectedOptionalValidations elementet i request headeren.
 Ud over listen af fejlkoder kan der angives en ElementPath der referer til det element i requestet, som den pågældende valideringer til/fra-valgt for. Udelades ElementPath gælder fra/tilvalgtet hele requestet.
@@ Line 167: / Line 169: @@
 </code>
 ==== 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.
+Eksempel:
+<code xml>
+  <FMKConfigurationLastUpdated>2025-10-31T00:00:00</FMKConfigurationLastUpdated>
+</code>
+Se [[fmk:1.6.0:xml-elementer:request_response_headers#fmkconfigurations|FMKConfigurations]] vedr. det returnerede svar.
 ==== PreflightOnly ====
+Anmodning der kan anvendes i request headeren for at angive, at en opdaterende handling ikke skal foretages, men i stedet kun valideres så langt som det er teknisk muligt.
+<code xml>
+<FMKRequestHeader>
+..
+<PreflightOnly/>
+...
+</FMKRequestHeader>
+</code>
 ==== PartOfBatchOperation ====
-TODO:!:: eksempel
+Flag der kan anvendes for at angive, at en operation skal ses som en del af en batch operation (UpdateMedicineCard), og derved skal udvidede valideringer ikke længere foretages. Dette element er foreløbigt reserveret til fremtidig brug, og vil p.t. ikke have nogen betydning for kald til FMK.
-====== Generel response header ======
-UNDER UDVIKLING :!:
+<code xml>
+<FMKRequestHeader>
+   ...
+   <PartOfBatchOperation/>
+   ...
+</FMKRequestHeader>
+</code>
+====== Generel response header ======
 Elementer af ikke-kliniske data, der er relevante på tværs af svar fra mange services, er samlet i en response header. Derved holdes kliniske og rent snitflade tekniske data bedre adskilt, og giver en større fleksibilitet mht. ændringer af ren teknisk karakter, samt bedre muligheder for FMK klienter. Oversigt over indhold:
@@ Line 196: / Line 222: @@
        ...
     </Warnings>
-    <FMKConfigurationList>
+    <FMKConfigurationUpdatedWarning>
         ...
-    </FMKConfigurationList>
+    </FMKConfigurationUpdatedWarning>
     <Informations>
         ...
@@ Line 252: / Line 278: @@
 ==== Warnings =====
-Advarsler vedrørende potentielle problemer eller andet, som brugeren bør være opmærksom på, i lighed med de eksisterende advarsler på dosisdispenserings-kortet. Bemærk dog, at det ikke har været vurderet som hensigtsmæssigt at flytte DD advarslerne til headeren, idet de typisk knytter sig til et specifikt element i selve DD kortet. Et eksempel på dette er advarslen til lægen om en igangværende ekspedition, ifm annullering af recepten.
+Advarsler vedrørende potentielle problemer eller andet, som brugeren bør være opmærksom på, i lighed med de eksisterende advarsler på dosisdispenserings-kortet.  Advarslerne er på samme form som fejlkoder og udvidede valideringer, d.v.s. med en fejlkode, -tekst og detaljer, hvorunder ElementPath til det element i request'et som advarslen vedrører, er angivet. Der vil senere blive publiceret en liste over hvilke advarsler FMK vil kunne returnere i et svar.
-TODO :!:
+Bemærk i øvrigt, at det ikke har været vurderet som hensigtsmæssigt at flytte DD advarslerne til headeren, idet de typisk knytter sig til et specifikt element i selve DD kortet. Et eksempel på dette er advarslen til lægen om en igangværende ekspedition, ifm annullering af recepten.
-==== FMKConfigurations ====
-Der returneres information om FMK's aktuelle konfiguration, hvis den har ændret sig siden den i request headeren angivne FMKConfigurationLastUpdated dato. Med "konfiguration" menes her egenskaber som gør, at FMK's semantik vedr. en eller flere services ændrer sig. Det kunne eksempelvis være ny funktionalitet, som kun er delvis implementeret og på vej mod en endelig implementationsfase (fx overgang fra 1.6.0 fase 1 til fase 2).
 Eksempel:
 <code xml>
-<FMKConfigurationList>
+<Warnings>
-  <KeyValuePair>
+  <Warning>
-    <Key>PausePeriodEnabled</Key>
+    <FaultCode>10800</FaultCode>
-    <Value>true</Value>
+    <FaultText>Advarselstekst vedr. klausuleret tilskud</FaultText>
-  </KeyValuePair>
+    <FaultDetails>
-</FMKConfigurationList>
+      <KeyValueSet>
+      <Key>DrugMedicationIdentifier[1]</Key>
+        <Value>2190751217130</Value>
+      </KeyValueSet>
+    </FaultDetails>
+  </Warning>
+</Warnings>
+</code>
+==== FMKConfigurationUpdatedWarning ====
+Der returneres information om FMK's senest ændrede konfigurationsdato, hvis den har ændret sig siden den i request headeren angivne [[fmk:1.6.0:xml-elementer:request_response_headers#fmkconfigurationlastupdated|FMKConfigurationLastUpdated]] dato. Med "konfiguration" menes her egenskaber som gør, at FMK's semantik vedr. en eller flere services ændrer sig. Det kunne eksempelvis være ny funktionalitet, som kun er delvis implementeret og på vej mod en endelig implementationsfase (fx overgang fra 1.6.0 fase 1 til fase 2).
+Eksempel:
+<code xml><FMKConfigurationUpdatedWarning>2026-01-12T17:14:00</FMKConfigurationUpdatedWarning>
 </code>