Page Status: updated 2023-11-23

HTTP Header and Authorization

Page index

• Authorization
• HTTP Request Header
  • Detailed Information and Examples
• HTTP Response Header

Authorization

Access to the Swedish National Medications List consists of three parts:

• Required access token in authorization parameter
• Purpose and access defined in the x-purpose and x-access parameters (required for most read interactions, see required information in each use case)
• A provenance structure describing information related to who authored and who entered the request as well as why, which relates to the value in the x-povenance request header.

Authorization
Access to the Swedish National Medication List is based on OAuth2 or SAML and requires a valid bearer token. More information is enclosed in the Ansluta till E-hälsomyndighetens tjänster.

Purpose and access type
The information in the purpose and access parameters will, along with the role of the person (in the security token) determine which information will be filtered in the response. This information will be available to the patient in the audit log. See Ändamål, åtkomsttyper, resurser och behörigheter for more information.

Provenance
In most create and update requests, a provenance resource will need to be added as a base64 encoded JSON to the HTTP request header x-provenance. The provenance holds information about who makes the request, the intention of the request and other event related information. Read more about the Provenance resource in the Provenance section.

A complete list of all header parameters can be seen in the table HTTP Headers below

HTTP Request Header

The table below shows HTTP header fields used in a request containing FHIR or NLL specific information. Other fields may be included as well in accordance with the HTTP specification. Mandatory fields are indicated in the column Mandatory

*UUIDs generated by the Swedish National Medication List follows RFC 4122 type 4, with a few exceptions when type 3 is used, and the FHIR 4 specification. RFC 4122 allows UUIDs to be in both upper and lower case but FHIR states that UUID IDs shall be in lower case. UUIDs in the Swedish National Medication List are therefor allways in lower case and alla UUIDs sent to the Medication List should be in lower case.

**Operations involving ValueSet, ConcepMap and $ping are currently working without specifying Request-Id and User Agent. This is not in line with the intended design why a blocking check will be added after consultation with systems already using NLL FHIR. It is therefore recommended all new systems to include Request-Id and User Agent also for these operations too.

Detailed Information and Examples

x-org-info

x-org-info is part of the security mechanism and is used in scenarios when there is a need to provide additional security information which is not included in the security token.

Health Care Providers:

Health care providers (sv. hälso- och sjukvårdspersonal) are required to provide the city name (sv. postort för vårdenhet) in addition to the organization information that is provided by the Identity Provider (IdP).

Example:

{
    "orgenhetsOrt" : "Kalmar"
}

Web pharmacy services:

Web pharmacy services (sv. apoteks e-handel) use the patient's security certificate, or a related person's security certificate, and must therefore provide the web pharmacy's GLN number.

Example:

{
    "orgenhetsId" : "7350045511996",
    "orgenhetsIdTyp" : "GLN",
}

Health care providers with simplified security pattern:

Health care providers (sv. hälso- och sjukvårdspersonal) who connects with simplified security pattern (model 2) are required to provide organization information.

Example:

{ 
  "orgenhetsOrt" : "Stockholm" 
  "orgenhetsId" : "SE2321000016-70HZ" 
  "orgenhetsIdTyp" : "HSA" 
  "orgenhetsNamn" : "Capio vårdcentralen Slussen" 
}

x-user-agent

The structure in x-user-agent contains the following elements:

• 'name' should contain the product name of the user agent making the call.
• 'info' may contain additional information about the user agent for example a module name or name of a customer specific extension.
• 'version' should contain the version number of the user agent. Preferable a technical version string rather than a marketing version name.
• 'moduleVersion' may contain an additional version number indicating the version of a module or extension.

Example:

{
  "name" : "Pascal",          // mandatory and max 20 characters
  "info" : "Module Z1",       // optional and max 99 characters
  "version" : "4.3.1",        // mandatory and max 20 characters
  "moduleVersion" : "1.0.2"   // optional and max 19 characters
}

HTTP Response Header

The table below shows HTTP header fields used in a response containing FHIR or NLL specific information. Other fields may be included as well in accordance with the HTTP specification. For more information about FHIR and headers, please read https://www.hl7.org/fhir/http.html