Swedish Healthcare Service - Health Condition Description
0.1.0 - CI Build Sweden

Swedish Healthcare Service - Health Condition Description - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Domain Overview

Domain Overview

Domain Identity

Domain URN: urn:riv:clinicalprocess:healthcond:description
Swedish Name: Vård- och omsorg kärnprocess: hantera hälsorelaterade tillstånd: tillståndsbeskrivning
Short Name: Tillståndsbeskrivning (Health Condition Description)
Version: 3.0.5

Purpose and Scope

This service domain handles information that describes a patient's health status. The domain serves two primary purposes:

  1. Healthcare Professional Access - Supporting the profession's need for direct access to patient care information (sammanhållen journalföring - coherent medical records)
  2. Patient Access - Enabling patient access to their own care information

Information Types

The domain encompasses four main categories of health status information:

Category Swedish Term Description
Care Documentation Vårdanteckningar Clinical notes, treatment plans, summaries
Diagnoses Diagnoser Registered medical diagnoses with codes
Alert Information Uppmärksamhetsinformation Allergies, serious conditions, warnings
Functional Status Funktionsstatus Disability and activity assessments

Service Contracts

GetCareDocumentation v3.0

Returns journal entries for a patient, including:

  • Investigation notes (utredning)
  • Treatment/intervention records (åtgärd/behandling)
  • Summary notes (sammanfattning)
  • Coordination notes (samordning)
  • Admission notes (inskrivning)
  • Discharge notes with epicrisis (slutanteckning)
  • Notes without physical encounter
  • Inpatient notes (slutenvårdsanteckning)
  • Visit notes (besöksanteckning)

Key Features:

  • DocBook v5.0 formatted text support
  • Binary attachments (embedded or referenced)
  • Dissenting opinions
  • Partial data retrieval for large datasets
  • JoL-header v2.2

GetDiagnosis v2.0

Returns registered diagnoses with one diagnosis code per diagnostic occasion.

Key Features:

  • Primary and secondary diagnosis types
  • Chronic diagnosis indication
  • Related diagnosis linking
  • ICD-10/SNOMED CT coding
  • Diagnosis time tracking

GetAlertInformation v2.0

Returns alert information requiring healthcare attention:

  • Medication hypersensitivity
  • Other hypersensitivities (food, animals, plants, chemicals)
  • Serious diseases
  • Ongoing treatments
  • Communicable diseases
  • Care restrictions
  • Historical alert information

Key Features:

  • Structured hypersensitivity information (ATC codes)
  • Severity and certainty grading
  • Validity time periods
  • Related alert information linking

GetFunctionalStatus v2.0

Returns documented functional status assessments:

  • Personal ADL (Activities of Daily Living) assessments
  • Disability assessments (ICF-based)

Key Features:

  • PADL assessments per ADL Taxonomy
  • ICF-coded disability assessments
  • Flexible text descriptions when codes unavailable

Architecture Pattern

Service Interaction Model

[Consumer] → [Aggregating Service] → [Engagement Index]
                      ↓
              [Source System 1]
              [Source System 2]
              [Source System N]

Or direct addressing:

[Consumer] → [Source System]

Aggregating Services

Aggregating services provide:

  • National view - Consolidates information across all care givers
  • Regional view - Consolidates information within region/authority
  • Engagement index consultation - Queries only relevant source systems
  • Parallel queries - Efficient multi-system retrieval

Source Systems

Source systems:

  • Store original patient information
  • Respond to direct queries
  • Update engagement index on data changes
  • Apply access controls per organizational policy

Engagement Index

The engagement index (EI) enables efficient queries by:

  • Maintaining registry of which systems have patient information
  • Categorizing information by type
  • Tracking most recent content timestamps
  • Supporting change notifications

Use Cases

Use Case 1: Healthcare Professional Review

Actors: Healthcare professional, EMR system, aggregating service, multiple source systems

Flow:

  1. Professional opens patient record in EMR
  2. EMR queries aggregating service for care documentation
  3. Aggregating service consults engagement index
  4. Parallel queries sent to relevant source systems
  5. Results aggregated and returned to EMR
  6. Professional reviews consolidated information

Security: Access control per PDL, blocking check, audit logging

Use Case 2: Patient Portal Access

Actors: Patient, patient portal, aggregating service, source systems

Flow:

  1. Patient logs into portal with strong authentication
  2. Portal queries for patient's approved information
  3. Aggregating service filters based on approvedForPatient flag
  4. Only approved information returned
  5. Patient views their health information

Security: Only information with approvedForPatient=true shown, audit logging

Use Case 3: Notification-Driven Update

Actors: EMR system, engagement index, source system

Flow:

  1. Source system updates patient diagnosis
  2. Source system updates engagement index
  3. Engagement index notifies subscribers (ProcessNotification)
  4. EMR receives notification with source system HSA-ID
  5. EMR directly queries source system for updated information

Benefit: Efficient updates, reduced unnecessary queries

Use Case 4: Partial Data Retrieval

Actors: Consumer, source system with large dataset

Flow:

  1. Consumer queries for all patient documentation
  2. Source system has 10,000 records
  3. Source system returns first 1,000 records plus hasMore element
  4. Consumer displays initial results
  5. On user request, consumer uses hasMoreReference for next batch
  6. Process repeats until all data retrieved or user stops

Benefit: Meets response time requirements, progressive loading

Integration Patterns

Pattern 1: National Coherent Medical Records

  • Consumer: National portal/service
  • Logical address: Inera HSA-ID (5565594230)
  • Aggregation: National aggregating service
  • Sources: All care givers nationally

Pattern 2: Regional Information Access

  • Consumer: Regional EMR system
  • Logical address: Regional authority HSA-ID
  • Aggregation: Regional aggregating service
  • Sources: Care givers within region

Pattern 3: Direct Source System Access

  • Consumer: Specialized application
  • Logical address: Source system HSA-ID
  • Aggregation: None (direct)
  • Sources: Single specified system

Information Model Principles

Metadata Structure

All information includes:

  • Identity - Unique, persistent record identifier
  • Provenance - Author, source system, organization
  • Timestamps - Creation, modification, signature times
  • Access control - Care giver, care unit, patient approval
  • Clinical context - Care contact, care process (where applicable)

Common Header Pattern (JoL-Header)

Version 2.2 of the JoL (Journal) header provides:

  1. Access Control Header
    • Information owner identification
    • Patient identity
    • Blocking comparison time
    • Patient approval flag
  2. Record Metadata
    • Unique identifier
    • Creation timestamp
  3. Authorship
    • Healthcare professional
    • Professional role
    • Organization unit
    • Timestamp
  4. Signature (when signed)
    • Signing person
    • Signature timestamp
    • Professional role at signing

Body Content

Each service contract defines specific body content:

  • GetCareDocumentation - Text content (plain or DocBook), multimedia
  • GetDiagnosis - Diagnosis code, type, chronicity
  • GetAlertInformation - Type-specific structured data
  • GetFunctionalStatus - Assessment category and structured evaluations

Standards Compliance

RIV Technical Framework

  • RIV 2.1 compliant
  • SOAP/XML messaging
  • WS-Security for authentication
  • HTTP transport

Healthcare Standards

  • NPÖ RIV 2.2.0 - National Patient Overview message formats (where applicable)
  • HL7 CDA v2 - Clinical Document Architecture compatibility (where applicable)
  • ICD-10 - Diagnosis coding
  • SNOMED CT - Clinical terminology
  • ICF - Functional status classification
  • ATC - Medication classification

Document Standards

  • DocBook v5.0 - Structured text formatting
  • ISO 8601 - Date and time formats

Swedish Healthcare Standards

  • HSA - Hälso- och sjukvårdens adressregister (Healthcare Address Registry)
  • KV Befattning - Professional role code system
  • KV Anteckningstyp - Document type code system
  • SOSFS 2016:40 - Journal keeping regulations

Data Quality Requirements

Mandatory Information

All responses must include:

  • Unique record identifier
  • Source system identifier
  • Patient identifier
  • Timestamp information
  • Result status

Services should provide when available:

  • Healthcare professional identification
  • Organization unit details
  • Professional role information
  • Care unit and care giver HSA-IDs

Data Consistency

  • Record identifiers must be persistent across queries
  • Same identifier across different service contracts where applicable
  • Timestamps in Swedish time zone (CET/CEST)
  • Date format consistency (YYYYMMDD)

Versioning Strategy

Major Version Changes

Major version increments indicate breaking changes:

  • GetCareDocumentation 2.x → 3.0 (breaking changes)

Minor Version Changes

Minor version increments maintain backward compatibility:

  • GetCareDocumentation 3.0 → 3.1 (if future compatible changes)

Domain Version

Domain version (3.0.5) indicates:

  • Major version of newest contract (3)
  • Minor revision level (0.5)

Governance

Specification Owner

Inera AB - Swedish national eHealth organization

Standards Body

RIV TA - RIV Technical Architecture board

Change Process

  1. Requirement identification
  2. Impact analysis
  3. Specification update
  4. Review and approval
  5. Publication
  6. Implementation window
  7. Mandatory upgrade (if breaking)

Support Resources

  • Technical specifications at rivta.se
  • Code systems at Inera's terminology service
  • Implementation guidance documents
  • Test suites and validators
  • Reference implementations

Scope Boundaries

In Scope

  • Reading patient health condition information
  • Structured and unstructured clinical data
  • Historical information retrieval
  • Cross-organizational information access

Out of Scope

  • Creating or updating patient information
  • Ordering services or treatments
  • Real-time monitoring data
  • Administrative/financial information
  • Medication dispensation (separate domain)
  • Laboratory results (separate domain)
  • Imaging studies (separate domain)

Other clinicalprocess domains provide:

  • medication - Medication information
  • activity - Activities and planning
  • logistics - Logistics and resource management
  • activityprescription - Activity prescriptions

Future Directions

Potential future enhancements:

  • Enhanced search capabilities
  • Subscription/notification patterns
  • FHIR-based alternatives
  • Real-time data streaming
  • Enhanced structured data models
  • International standard alignment