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

Business Rules and Requirements

Business Rules and Requirements

This page documents the common business rules and requirements that apply across all service contracts in the domain.

Engagement Index Management

All source systems must update the engagement index. Updates must occur as soon as an event occurs that affects index entries.

Update Method

All engagement index updates use the contract:

urn:riv:itintegration:engagementindex:UpdateResponder:1

(Known as "index-push")

Index Entry Fields

Attribute Cardinality Description Value for This Domain
RegisteredResidentIdentification 1..1 Patient personal/coordination number (12 chars) From source data
ServiceDomain 1..1 Service domain URN riv:clinicalprocess:healthcond:description
Categorization 1..1 Information type code See table below
LogicalAddress 1..1 Source system address Same as SourceSystem
BusinessObjectInstanceIdentifier 1..1 Event object identifier "NA" (not used)
ClinicalProcessInterestId 1..1 Care process GUID "NA" (not yet used)
MostRecentContent 1..1 Latest update timestamp Timestamp of latest relevant event
CreationTime 1..1 Index entry creation Auto-generated by EI
UpdateTime 0..1 Index entry last update Auto-generated by EI
SourceSystem 1..1 Source system HSA-ID System HSA-ID
DataController 1..1 Data controller Care giver org number or HSA-ID

Categorization Values

Service Contract Categorization Value
GetCareDocumentation voo
GetDiagnosis dia
GetAlertInformation upp
GetFunctionalStatus - Disability fun-fun
GetFunctionalStatus - PADL pad-pad

Note: GetFunctionalStatus producers must use the same categorization value in Update as in the assessmentCategory element of responses.

Date and Time Formats

Date Format

Dates are always specified as: YYYYMMDD

  • ISO 8601 compatible
  • Example: 20241127

Timestamp Format

Timestamps are always specified as: YYYYMMDDhhmmss

  • ISO 8601 compatible
  • Example: 20241127143052

Time Zone

No time zone is specified in message formats. All dates and timestamps must use:

  • CET (Central European Time) - Swedish standard time
  • CEST (Central European Summer Time) - Swedish daylight saving time

Both producers and consumers must assume information is in the appropriate Swedish time zone.

HSA-ID Usage

When HSA-ID Required

HSA-ID (Hälso- och sjukvårdens adressregister identitet) should be used when available from the HSA catalog.

When HSA-ID Unavailable

If HSA-ID is not available in the source system:

  • For organization units (OrgUnitType): A locally unique ID may be used
  • Local IDs must be unique within the source system
  • Document in implementation agreements which approach is used

Organization Number Alternative

For care givers (vårdgivare), organization number may be used as alternative to HSA-ID:

  • Format: "SE"<organizationsnummer>
  • Example: "SE5565594230"
  • OID: 1.2.752.29.4.3

Patient Identity

Supported Identifier Types

Type OID Format Usage with EI
Personal Number 1.2.752.129.2.1.3.1 12 digits ✓ Supported
Coordination Number 1.2.752.129.2.1.3.3 12 digits ✓ Supported
Local Reserve Number Local OID (e.g., 1.2.752.97.3.1.3) System-specific ✗ Not supported

Reserve Number Limitations

Local reserve numbers:

  • Cannot be used with engagement index
  • Cannot be used with aggregating services
  • Require direct system addressing using sourceSystemHSAId
  • No engagement index updates should be sent for reserve numbers

Cross-Identity Retrieval

Service producers must return all patient information when queried with any of the patient's identity designations. For example, if a patient has both a coordination number and later receives a personal number, queries using either identifier must return all information.

Addressing and Routing

Addressing Models

Access Pattern Logical Address Use Case
National aggregation Inera HSA-ID: 5565594230 Access across all care givers
Regional aggregation Regional HSA-ID Access within region/authority
Direct system Source system HSA-ID Direct access to specific system

Source System Addressing Rules

When sourceSystemHSAId is specified in a request:

  1. Value must match logicalAddress in SOAP header
  2. Aggregating services are NOT used
  3. Response is limited to data from specified system only

Rule: LogicalAddress Filtering

Producers must filter responses to only include information from the source system specified by the logicalAddress in the request header.

Non-Functional Requirements

Duplicate Handling

When the same patient data exists in multiple source systems:

  • It is the information-producing care giver's responsibility to ensure only one source system provides the data via read services and engagement index
  • Consumers connected to multiple major versions of the same contract must perform deduplication by comparing record-level identities
  • Keep only one instance of records with identical identifiers

Performance Requirements

Requirement Specification
Response time Max 30 seconds per request
Availability 99.5% uptime, 24×7
Load capacity Handle minimum 2× daily journal update rate
Currency Target < 60 minute delay for data and EI updates
Concurrency Support minimum 10 simultaneous requests
Partial responses Allowed if time interval unspecified and needed for response time compliance

Engagement Index Updates

  • Must occur as soon as event happens
  • Index entry must reference data immediately available via service contract
  • Update both data and engagement index with minimal delay

Error Handling

Logical Errors

Service contracts return logical errors in the result structure:

result:
  resultCode: ERROR
  errorCode: INVALID_REQUEST
  message: "Human-readable description"
  logId: "UUID"

The message should be:

  • Logged by systems
  • Displayable to users when applicable
  • Descriptive of the rule violation

Technical Errors

Technical errors return SOAP Fault with:

  • Generic exception (not personal information)
  • Log-id (UUID) for troubleshooting
  • No patient-traceable information

Producer Requirements

Producers must:

  • Return appropriate error codes
  • Provide log-id for troubleshooting
  • Not expose personal data in errors
  • Document error codes in implementation agreements

Consumer Requirements

Consumers should:

  • Handle both logical and technical errors
  • Log errors appropriately
  • Display user-friendly messages
  • Use log-id when reporting issues

Access Control

Producers are responsible for:

  • Ensuring information released only to approved consumers
  • Filtering responses per information owner policies
  • Implementing technical access controls
  • Not using consumer identity for purposes other than access control

PDL Compliance

Requirements per Patientdatalagen (Patient Data Law):

  • Blocking control capability
  • Consent management
  • Audit logging
  • Strong authentication in shared networks
  • Care unit selection at authentication

Patient Access Approval

The approvedForPatient flag indicates whether:

  • Information may be shared with patient
  • Based on responsible professional's decision
  • Or based on organizational policy/rules
  • May change over time (e.g., after confidentiality period)
  • Source system must update EI when flag changes

Code System Guidelines

CVType Usage Rules

For Coded Value (CVType) elements:

  1. Code availability:
    • Provide code and/or originalText
    • If code provided, also provide codeSystem
    • If codeSystem provided, also provide code
  2. Code system identification:
    • codeSystem must be UUID, OID, or URI
    • Should be globally unique identifier
  3. Display name:
    • Should match code system's defined display name
    • If not available from code system, use same value as code
    • Optional but recommended
  4. Original text usage:
    • Use when local code system lacks OID
    • Use when code entirely absent
    • Represents user-entered text or value without code
    • If provided, represents the value; code provides additional structure

Professional Role Coding

Preferred code system: KV Befattning (OID: 1.2.752.129.2.2.1.4)

If KV Befattning cannot be used:

  • Care giver must provide OID for their internal code system
  • Information available must not be omitted due to inability to map to KV Befattning
  • Use originalText if no structured code available

Compatibility

Version Compatibility

Contract Consumer Version Producer Version Compatible
GetCareDocumentation 2.1 2.0 ✓ Yes
GetCareDocumentation 2.0 2.1 ✗ No
GetCareDocumentation 2.x 3.0 ✗ No
GetCareDocumentation 3.0 2.x ✗ No
Other contracts 2.0 2.0 ✓ Yes

Backward Compatibility Notes

  • GetCareDocumentation 3.0 is not backward compatible with 2.x
  • All other contracts maintain compatibility within major version 2.0
  • Producers must declare which versions they support

References

  • RIV Technical Framework 2.1
  • SOSFS 2016:40 (Swedish journal keeping regulations)
  • PDL (Patientdatalagen) - Patient Data Law
  • ISO 8601 Date and time format