Der indgår en række headers i SOAP kaldene til FMK, hvoraf SecurityHeader og MedcomHeader er defineret i DGWS standarden. For at samle de øvrige FMK specifikke headers samt tilføje mulighed for at angive parametre på tværs af requests, er der indført et <FMKRequestHeader> element. Oversigt over header indhold:

<FMKRequestHeader  ... >
    <OnBehalfOfHeader>
    ...
    </OnBehalfOfHeader>
    <WhitelistingHeader>
    ...
    </WhitelistingHeader>
    <ConsentHeader>
    ...
    </ConsentHeader>
    <MinLogSessionId>...</MinLogSessionId>
    <Paging>
    ...
    </Paging>
    <ExtendedValidationHeader>
    ...
    </ExtendedValidationHeader>
    <PreflightOnly/>
    <PartOfBatchOperation/>
</FMKRequestHeader>

FMK specifik header med oplysninger om person, som der foretages en handling på vegne af. Se også Bemyndigelse.

Eksempel:

  <OnBehalfOfHeader>
    <HealthcareProfessionalIdentifier source="Autorisation">BR56T</HealthcareProfessionalIdentifier>
  </OnBehalfOfHeader>

FMK specifik header med oplysninger der anvendes til validering af FMK adgangen i henhold til aktive whitelistings, såsom systemnavn, -ejer og -version, OrgUsingId og -Name, se Systemautorisation

Eksempel:

  <WhitelistingHeader>
        <SystemOwnerName>Leverandør A</SystemOwnerName>
        <SystemName>System A</SystemName>
        <SystemVersion>1.0.2</SystemVersion>
        <OrgResponsibleName>ROS IT-afdeling</OrgResponsibleName>
        <OrgUsingName>Alb Plastikkirurgisk Dagafdeling</OrgUsingName>
        <OrgUsingID NameFormat="medcom:skscode">8001506</OrgUsingID>
        <RequestedRole>Læge</RequestedRole>
    </WhitelistingHeader>

FMK specifik header der angiver, om en handling er tilladt som følge af samtykke eller værdispring. Se Samtykke

Eksempel:

 <ConsentHeader>
        <Consent source="User">
            <FromDate>2023-03-24</FromDate>
            <ToDate>2023-03-30</ToDate>
            <ConsentType>PrivateDataConsentGiven</ConsentType>
            <Content>MedicineCard</Content>
        </Consent>
    </ConsentHeader>

I NSP's MinLog service er der på registreringstidspunktet mulighed for at angive et sessions id (også kaldet Correlation ID). Ideen er, at minlog registreringer der stammer fra den samme behandling, konsultation o.lign. tildeles samme session id, som derved giver de sites/apps der viser MinLog for borgeren, en bedre mulighed for at gruppere log linjer per session i visningen. FMK kan af gode grunde ikke selv konstatere, om et opslag eller en handling stammer fra samme behandling, men klientsystemerne vil i nogle tilfælde kunne det, og derfor er der blevet indført mulighed for, at FMK klientsystemerne kan sende en MinLogSessionID med i request-headeren, som videresendes til MinLog2 registreringsservicen, når opslaget/handlingen er blevet udført. Der er ingen særlige krav til indholdet af id'et, udover at det er en streng på max 40 tegn.

Eksempel:

<MinLogSessionId>FMK_Klient_X_288938787902</MinLogSessionId>

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.

I requestet skal angives hhv. PagingObject: hvilke objekter pagineres der henover (er ikke altid givet, hvis et svar kan indeholde flere under-objekter) PageSize: hvad er det største antal objekter man ønsker retur for “PagingObject” typen LastReceived: pegepind til de data man modtog i det seneste kald, så FMK i det efterfølgende kald returnerer paginerede data fra det sted. LastReceived kan findes i ResponseHeader fra det seneste kald. Angives LastReceived ikke, returneres side 1.

Eksempel:

Et kald til Hent udleveringer returnerer totalt 37 udleveringer, men der ønskes max 25 udleveringer returnerer pr. kald. Det er første kald, så LastReceived er ikke angivet:

<FMKRequestHeader>
...
  <Paging>
    <PagingObject>Handovers</PagingObject>
    <PageSize>25</PageSize>	
  </Paging>
...
</FMKRequestHeader>

Eksempel på response header fra ovenstående kald:

<FMKResponseHeader>
...
  <Paging>
    <PagingObject>Handover</PagingObject>
    <ParentObjectIdentifier type="Warrant">12321233</ParentObjectIdentifier>
    <PageSize>25</PageSize>
    <TotalSize>37</TotalSize>
    <LastReceived>
      <Field name="Identifier">983552773455</Field>
    </LastReceived>
  </Paging>
..
</FMKResponseHeader>

Ønsker klienten at hente de efterfølgende udleveringer, skal det næste kald indeholde et PagingElement hvor LastReceived er kopieret fra ovenstående svar, d.v.s.:

<FMKRequestHeader>
...
  <Paging>
    <PagingObject>Handovers</PagingObject>
    <PageSize>25</PageSize>
    <LastReceived>
      <Field name="Identifier">983552773455</Field>
    </LastReceived>
  </Paging>
...
</FMKRequestHeader>

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

Herunder et eksempel, hvor klienten har tilvalgt valideringerne 10801 og 10802, fravalgt 10100 og 10101 for den første DrugMedication i requestet, samt fravalgt 10100 og 10102 for den anden DrugMedication i kaldet:

<ExtendedValidationHeader>
  <ApplySelectedOptionalValidations>
    <ErrorCode>10801</ErrorCode>
    <ErrorCode>10802</ErrorCode>
  </ApplySelectedOptionalValidations>
  <SkipValidations>
    <ExtendedValidation>
      <ErrorCode>10100</ErrorCode>
      <ErrorCode>10101</ErrorCode>
      <ElementPath>DrugMedication[1]</ElementPath>
    </ExtendedValidation>
    <ExtendedValidation>
      <ErrorCode>10100</ErrorCode>
      <ErrorCode>10102</ErrorCode>
      <ElementPath>DrugMedication[2]</ElementPath>
    </ExtendedValidation>
  </SkipValidations>
</ExtendedValidationHeader>

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 FMKConfiguration elementet i response headeren, i tilfælde af at konfigurationen har ændret sig siden det tidsstempel der er angivet i FMKConfigurationLastUpdated elementet. Hvis elementet udelades, returnes ingen konfigurationsinformation.

Eksempel:

  <FMKConfigurationLastUpdated>2025-10-31T00:00:00</FMKConfigurationLastUpdated>

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.

TODO:!:: eksempel

UNDER UDVIKLING

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:

<FMKResponseHeader  xmlns="http://fmk-teknik.dk/160"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="http://fmk-teknik.dk/160 FMKResponseHeader.xsd">
 
    <KnownPersonIdentifiers>
    ...
    </KnownPersonIdentifiers>
    <MedicineCardInvalid />
    <VersionMismatchWarning />
    <HiddenData>
    ...
    </HiddenData>
    <Paging>
    ...
    </Paging>
    <Warnings>
       ...
    </Warnings>
    <FMKConfigurationList>
        ...
    </FMKConfigurationList>
    <Informations>
        ...
    </Informations>
</FMKResponseHeader>

Informationer omkring kendte PersonIdentifiers for den fremsøgte person, i tilfælde af patienten har skiftet CPR-nummer, eller eCPR som er blevet ændret)

    <KnownPersonIdentifiers>
        <KnownPersonIdentifier>
            <PersonIdentifier source="CPR">2512489996</PersonIdentifier>
            <Name>Nancy Berggren</Name>
            <ValidSince>1948-12-25</ValidSince>
        </KnownPersonIdentifier>
        <KnownPersonIdentifier>
            <PersonIdentifier source="X-eCPR">25124899Y6</PersonIdentifier>
            <Name>N. Berggren</Name>
            <ValidSince>2025-10-27</ValidSince>
        </KnownPersonIdentifier>
    </KnownPersonIdentifiers>

Response headeren kan indeholde en markering af at medicinkortet for den pågældende person er ugyldigt, vha. MedicineCardInvalid-elementet. Markeringen kan sættes og fjernes af den dataansvarlige (SDS), eventuelt på opfordring af en læge, og betyder at der er sket en fejl under opdatering af medicinkortet således at det ikke længere er retvisende.

Medicinkortet skal efterfølgende enten ignoreres eller bringes tilbage i korrekt stand. Af hensyn til sidstnævnte er det derfor muligt at hente og opdatere ugyldige medicinkort.

Se Ugyldig-markering og administrativ sletning af data

Markering af at opdatering er sket på baggrund af forkert medicinkort-version, svarende til den tidligere ‘VersionMismatchWarning’ som fandtes på en lang række 1.4.x responses fra FMK.

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:

<HiddenData>
  <PersonIdentifier source="CPR">2512489996</PersonIdentifier>
  <HasNegativeConsent/>
</HiddenData>

Paginering anvendes i tilfælde af, at der skal returneres et stort antal resultater i et svar. Klienten har i request headeren mulighed for at angive pagineringssidestørrelsen, d.v.s. antal svar der max returneres, men i visse tilfælde overtrumfer FMK's interne grænser for pagineringsstørrelser denne parameter, for at undgå problemer med at danne meget store svar. I svaret returneres information om resultatstørrelse, hvilket objekttype der pagineres over, samt hvilket parent object, d.v.s. “ejer” af objekterne der pagineres over, fx. “Warrant” hvis der pagineres over “Handover” objekter. Se Paging afsnittet herover vedr. request headeren, for et eksempel på anvendelse af paginering.

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.

TODO

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:

<FMKConfigurationList>
  <KeyValuePair>
    <Key>PausePeriodEnabled</Key>
    <Value>true</Value>
  </KeyValuePair>
</FMKConfigurationList>

Dette element er indtil videre reserveret til fremtidigt brug!

Det er tiltænkt som værende en måde dynamisk at kunne tilføje yderligere information til responses via response headeren, uden påkrævede snitfladeændringer.

Eksempel:

<Informations>
  <Information>
    <Text>AdditionalHeaderData</Text>
    <KeyValuePair>
      <Key>NewDrugMedicationState</Key>
      <Value>2190751217130</Value>
    </KeyValuePair>
    <KeyValuePair>
      <Key>State</Key>
      <Value>29</Value>
    </KeyValuePair>
  </Information>
  <Information>
    <Text>Some flag'ish type of information without KeyValuePair</Text>
  </Information>
</Informations>