Inera Core Implementation Guide
0.2.0 - ci-build Sweden

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

Capability Statements

Capability Statements

This page contains reccomendations for FHIR server capabilities expected for Swedish EHR systems and lists the formal Capability Statements defined in this Implementation Guide. The conformance requirements below is for meeting the criteria of being an IPA conformant system also implementing support for the Inera Core profiles and Swedish Base profiles.

Systems that provide other acces methods than IPA would only need to conform on a resource basis to the Inera Core profiles, see section Core Resource Support

EHR Server Capabilities

Swedish Electronic Health Record (EHR) systems acting as IPA conformant FHIR servers SHALL implement the following core capabilities:

Required RESTful Operations

EHR systems SHALL support the following FHIR RESTful interactions:

Operation Scope Requirement
read All supported resources SHALL
search-type All supported resources SHALL
vread Clinical resources SHOULD
history-instance Clinical resources SHOULD
create Write-enabled resources MAY
update Write-enabled resources MAY

Core Resource Support

EHR systems SHALL support the following resources with Swedish profiles:

Patient Demographics

  • Patient (SE Base Patient profile)
    • SHALL support search by identifier (personnummer/samordningsnummer)
    • SHALL support search by name, birthdate, gender
    • SHALL support _include=Patient:general-practitioner,Patient:organization

Healthcare Providers

  • Practitioner (SE Base Practitioner profile)
    • SHALL support search by identifier (HSA-ID)
    • SHALL support search by name
  • Organization (SE Base Organization profile)
    • SHALL support search by identifier (HSA-ID)
    • SHALL support search by name, type

Clinical Content

For detailed clinical resource support requirements, see the Conformance page.

Key clinical resources include AllergyIntolerance, Condition, MedicationStatement, Observation, and Procedure with Swedish profile support.

Search Parameters

EHR systems SHALL support the following search parameter combinations:

GET [base]/Patient?identifier=https://terminology.hl7.se/sid/se-personnummer|191212121212
GET [base]/AllergyIntolerance?patient=Patient/123&clinical-status=active
GET [base]/Condition?patient=Patient/123&code=http://terminology.hl7.se/CodeSystem/icd-10-se|E11
GET [base]/MedicationStatement?patient=Patient/123&_include=MedicationStatement:medication
GET [base]/Observation?patient=Patient/123&category=vital-signs&date=ge2024-01-01
GET [base]/Procedure?patient=Patient/123&date=ge2023-01-01&date=le2023-12-31

For detailed search parameter mappings from TKB services, see Search Parameters.

Swedish-Specific Requirements

EHR systems SHALL support Swedish national identifier systems and terminology bindings as specified in the Conformance page.

Provenance

EHR systems SHALL record and provide Provenance resources for clinical data to support:

  • Patientdatalagen (PDL) compliance
  • Clinical accountability and traceability
  • Audit trail requirements

Security and Privacy

EHR systems SHALL implement:

  1. Authentication & Authorization
    • SMART on FHIR for user authentication
    • OAuth 2.0 / OpenID Connect
    • Role-based access control (RBAC)
  2. PDL Compliance
    • Access logging for all patient data access
    • Break-the-glass emergency access with audit trail
    • Patient consent enforcement where applicable
  3. Transport Security
    • TLS 1.2 or higher for all communications
    • Certificate validation
  4. Data Security
    • Security labels on sensitive resources
    • Appropriate access controls based on Swedish privacy regulations

Performance Requirements

EHR systems SHOULD:

  • Respond to read operations within 1 second
  • Return search results (first page) within 2 seconds
  • Support paging for large result sets (_count, _offset)
  • Support _summary and _elements for partial resource retrieval

Format Support

EHR systems SHALL support:

  • JSON representation (application/fhir+json)
  • UTF-8 encoding

EHR systems SHOULD support:

  • XML representation (application/fhir+xml)

Formal Capability Statements

The following formal CapabilityStatement resources define detailed conformance requirements:

Declaring Conformance

EHR systems SHALL publish a CapabilityStatement resource at the /metadata endpoint that:

  • Declares the FHIR version (R4)
  • Lists all supported resources and profiles
  • Specifies supported interactions and search parameters
  • References this Implementation Guide in CapabilityStatement.implementationGuide

Example

GET [base]/metadata

Returns a CapabilityStatement declaring support for Inera Core IG:

{
  "resourceType": "CapabilityStatement",
  "status": "active",
  "date": "2024-01-15",
  "kind": "instance",
  "fhirVersion": "4.0.1",
  "format": ["json", "xml"],
  "implementationGuide": [
    "http://inera.se/fhir/ImplementationGuide/inera-core"
  ],
  "rest": [{
    "mode": "server",
    "resource": [{
      "type": "Patient",
      "profile": "http://hl7.se/fhir/StructureDefinition/se-base-patient",
      "interaction": [
        {"code": "read"},
        {"code": "search-type"}
      ],
      "searchParam": [
        {
          "name": "identifier",
          "type": "token"
        },
        {
          "name": "name",
          "type": "string"
        }
      ]
    }]
  }]
}