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.

Ændringer fra originalt oplæg: Paginering og ExtendedValidationHeader er flyttet ud af headeren og ind i request elementet.

<FMKRequestHeader  ... >
    <OnBehalfOfHeader>
    ...
    </OnBehalfOfHeader>
    <WhitelistingHeader>
    ...
    </WhitelistingHeader>
    <ConsentHeader>
    ...
    </ConsentHeader>
    <MinLogSessionId>...</MinLogSessionId>
    <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:sor">621491000016008</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>

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 GetFMKConfiguration servicen og indhente detaljerede oplysninger om konfiguration. Hvis elementet udelades, returnes ingen konfigurationsinformation.

Eksempel:

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

Se FMKConfigurations vedr. det returnerede svar.

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.

<FMKRequestHeader>
..
<PreflightOnly/>
...
</FMKRequestHeader>

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.

<FMKRequestHeader>
   ...
   <PartOfBatchOperation/>
   ...
</FMKRequestHeader>

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.

Ændringer fra originalt oplæg: Følgende elementer er flyttet ud:

• MedicineCardInvalid
• VersionMismatchWarning
• HiddenData (privatmarkering)
• Paging
• Warnings
• Informations

<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>
    <FMKConfigurationUpdatedWarning>
        ...
    </FMKConfigurationUpdatedWarning>
</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>

Der returneres information om FMK's senest ændrede konfigurationsdato, 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:

<FMKConfigurationUpdatedWarning>2026-01-12T17:14:00</FMKConfigurationUpdatedWarning>