Inera Core Implementation Guide - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Must Support

Must Support

This page defines the expectations for Must Support elements in the Inera Core Implementation Guide.

Definition of Must Support

In the context of this Implementation Guide, Must Support elements have the following requirements:

For Server Systems (EHR Systems)

Servers SHALL:

1. Populate: Include the element in the resource when the data exists in the source system
   • If the data element has a value in the EHR database, it SHALL be included in the FHIR resource
   • If the data does not exist, the element MAY be omitted (unless the cardinality requires it)
2. Return: Include Must Support elements in search results and read operations
   • When a resource is returned, all available Must Support elements SHALL be populated
3. Store: Accept and persist the element when received from clients
   • Systems SHALL be capable of storing data for Must Support elements
   • Systems SHALL NOT reject resources solely because a Must Support element is present

For Client Systems

Clients SHALL:

1. Process: Be able to meaningfully process Must Support elements
   • Display the information to users when appropriate
   • Use the data in clinical decision support or other processing logic
   • Store the data if maintaining a local copy of the resource
2. Handle: Gracefully handle missing Must Support elements
   • Systems SHALL NOT fail when a Must Support element is absent
   • Systems SHOULD provide appropriate defaults or user notifications when expected data is missing

Swedish Context Considerations

Must Support in this IG takes into account Swedish healthcare data requirements:

TKB Logical Model Mappings

Elements marked as Must Support often correspond to mandatory fields in Swedish TKB (Tjänstekontrakt Beskrivning) service contract specifications:

• Elements with cardinality 1..1 or 1..* in TKB models are typically Must Support
• Swedish legal requirements (Patientdatalagen) may require certain elements to be Must Support
• Regional service contracts (Tjänstekontrakt) may impose additional requirements

Swedish Identifiers

The following identifier types are Must Support in applicable profiles:

• Personnummer (Swedish national ID) - Must Support in Patient profile
• Samordningsnummer (Coordination number) - Must Support in Patient profile
• HSA-ID (Healthcare Staff Application ID) - Must Support in Practitioner and Organization profiles

Swedish Terminology

When terminology bindings are Must Support:

• Servers SHALL support the specified Swedish code systems (ICD-10-SE, NPL, ATC, KV codes)
• Servers SHOULD provide display text in Swedish
• Clients SHALL be prepared to receive codes from Swedish code systems

Handling Missing Must Support Elements

Server Behavior

If a Must Support element is missing from the source system:

• Optional elements (0..1, 0..*): MAY be omitted from the resource
• Required elements (1..1, 1..*):
  • If truly required by cardinality, use data-absent-reason extension
  • If there is a default value, use the default

Client Behavior

When processing resources with missing Must Support elements:

• Display: Show appropriate messaging (e.g., "Information not available")
• Processing: Handle null/missing values without errors
• Validation: Do not treat missing optional Must Support elements as errors

Examples

Example 1: Must Support String Element

{
  "resourceType": "Practitioner",
  "identifier": [{
    "system": "https://terminology.hl7.se/sid/se-hsa-personalid",
    "value": "SE2321000016-123456"  // Must Support - SHALL populate if known
  }],
  "name": [{
    "family": "Andersson",  // Must Support - SHALL populate if known
    "given": ["Anna"]       // Must Support - SHALL populate if known
  }]
}

Server: SHALL include family and given names if available in the source system.

Client: SHALL be able to display or process practitioner names.

Example 2: Must Support CodeableConcept

{
  "resourceType": "AllergyIntolerance",
  "code": {  // Must Support
    "coding": [{
      "system": "http://snomed.info/sct",
      "code": "227493005",
      "display": "Cashew nuts"
    }]
  },
  "clinicalStatus": {  // Must Support
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical",
      "code": "active"
    }]
  }
}

Server: SHALL include allergy code and clinical status if known.

Client: SHALL process and display allergy information including status.

Conformance Testing

Systems claiming conformance to this IG:

• Servers: SHALL pass Must Support validation using the FHIR Validator
  • All populated resources SHALL include available Must Support elements
  • Test data SHOULD cover scenarios with both present and missing optional Must Support elements
• Clients: SHALL demonstrate ability to process all Must Support elements
  • Test scenarios SHOULD verify handling of missing optional elements
  • User interfaces SHOULD properly display all Must Support data

Summary