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

Common Components

Common Components

This page documents the common data types and structures used across multiple service contracts in the domain.

Common Data Types

IIType - Instance Identifier

A numeric or alphanumeric string traceable to a single object or entity within a known system.

​View IIType logical model

Structure:

• root (1..1) - Universal identifier or namespace identifier
• extension (0..1) - Identifier value within the namespace

Cardinality:

• root: Required (1..1)
• extension: Optional (0..1)

Data Types:

• root: string (OID, UUID, or URI)
• extension: string (alphanumeric)

Validation Rules:

1. root must be a valid:
   • OID (e.g., 1.2.752.129.2.1.3.1)
   • UUID (e.g., 550e8400-e29b-41d4-a716-446655440000)
   • URI (e.g., urn:ietf:rfc:3986)
2. If extension is provided, root identifies the namespace
3. If extension is omitted, root must be universally unique (prefer UUID format)
4. extension format depends on namespace defined by root
5. Combined root+extension must uniquely identify the entity

Usage Examples:

Personal Number:
  root: 1.2.752.129.2.1.3.1
  extension: 197001011234

HSA-ID:
  root: 1.2.752.129.2.1.4.1
  extension: SE2321000016-1234

Document UUID (no extension):
  root: 550e8400-e29b-41d4-a716-446655440000
  extension: (empty)
  
Organization Number:
  root: 1.2.752.29.4.3
  extension: 2321000016

Rules:

• Use appropriate OID for identifier type
• Maintain consistency across contracts
• Document IDs should use UUID in root for global uniqueness
• Person IDs must use Swedish OIDs (personnummer, samordningsnummer)

CVType - Coded Value

A reference to a concept defined in an external code system (terminology, classification, or ontology).

​View CVType logical model

Structure:

• code (0..1) - Code or expression as defined by code system
• codeSystem (0..1) - Globally unique identifier (OID/UUID/URI) for code system
• codeSystemName (0..1) - Human-readable name of code system
• codeSystemVersion (0..1) - Version identifier
• displayName (0..1) - Human-readable representation
• originalText (0..1) - Text when code unavailable or user-entered

Cardinality Rules:

1. At least one of code or originalText must be provided (1..1 combined)
2. If code provided → codeSystem required (1..1)
3. If code provided → displayName required (1..1)
4. If codeSystem provided → code required (1..1)
5. codeSystemName optional (0..1)
6. codeSystemVersion optional (0..1)
7. originalText optional (0..1)

Validation Rules:

1. code: String matching code system's format requirements
   • No leading/trailing whitespace
   • Case-sensitive per code system
   • Format varies by system (e.g., "E11.9", "204010", "J01C")
2. codeSystem: Must be valid OID, UUID, or URI
   • OID format: 1.2.752.129.2.2.1.4
   • UUID format: 550e8400-e29b-41d4-a716-446655440000
   • URI format: http://snomed.info/sct
3. displayName: Human-readable text (1-200 characters typical)
   • Should match official term from code system
   • May use Swedish translation if available
   • Must accurately represent the coded concept
4. originalText: Free text (1-1000 characters typical)
   • Used when no suitable code exists
   • Preserves user-entered terminology
   • May supplement coded data

Usage Rules:

1. Preferred: Code with display name

   code: E11.9
   codeSystem: 1.2.752.116.1.1.1.1.3
   codeSystemName: ICD-10-SE
   displayName: Diabetes mellitus typ 2 utan komplikationer
   

2. Code unavailable: Use original text

   originalText: Vårdplanerare (lokal roll utan nationell kod)
   

3. Both code and original text (supplementing)

   code: 204010
   codeSystem: 1.2.752.129.2.2.1.4
   displayName: Distriktsläkare
   originalText: Distriktsläkare, primärvård
   

4. Code system version (when relevant)

   code: 73211009
   codeSystem: 2.16.840.1.113883.6.96
   codeSystemName: SNOMED CT
   codeSystemVersion: 20230901
   displayName: Diabetes mellitus
   

Examples:

ICD-10 Diagnosis:
  code: E11.9
  codeSystem: 1.2.752.116.1.1.1.1.3
  codeSystemName: ICD-10-SE
  displayName: Diabetes mellitus typ 2 utan komplikationer

Professional Role:
  code: 204010
  codeSystem: 1.2.752.129.2.2.1.4
  codeSystemName: KV Befattning
  displayName: Distriktsläkare

ATC Medication Code:
  code: J01C
  codeSystem: 1.2.752.129.2.2.3.1.1
  codeSystemName: ATC
  displayName: Betalaktamantibiotika, penicilliner

Local Code Without OID:
  originalText: Vårdplanerare

Alert Type:
  code: UPP04
  codeSystem: 1.2.752.129.2.2.1.87
  codeSystemName: KV Uppmärksamhetstyp
  displayName: Läkemedelsöverkänslighet

Common Code Systems:

DatePeriodType - Date Period

Date interval specification. Open intervals allowed.

​View DatePeriodType logical model

Structure:

• start (0..1) - Period start date (format YYYYMMDD)
• end (0..1) - Period end date (format YYYYMMDD)

Cardinality:

• At least one of start or end must be specified (1..1 combined)
• Both start and end may be specified (closed interval)
• Only start specified: open-ended interval (from date onwards)
• Only end specified: open-ended interval (up to date)

Data Format:

• Format: YYYYMMDD (ISO 8601 basic format)
• No separators (dashes/slashes)
• No time component
• No timezone specification (assumed Swedish local time)
• Gregorian calendar

Validation Rules:

1. start must match regex: ^\d{8}$
   • Year: 4 digits (1900-2099)
   • Month: 2 digits (01-12)
   • Day: 2 digits (01-31, validated for month)
2. end must match regex: ^\d{8}$
3. If both specified: end must be ≥ start
4. Date must be valid (e.g., 20240231 invalid, 20240229 valid in leap year)
5. Future dates allowed (for planning/scheduling)

Endpoint Semantics:

• Inclusive or exclusive endpoints: Documented per service contract
• GetCareDocumentation: Inclusive endpoints (documents created on start/end dates included)
• GetDiagnosis: Overlapping semantics (diagnoses with validity periods overlapping search interval)

Examples:

Specific period (closed interval):
  start: 20240101
  end: 20241231
  → January 1, 2024 through December 31, 2024

Open-ended from date:
  start: 20240601
  end: (empty)
  → June 1, 2024 onwards

Open-ended until date:
  start: (empty)
  end: 20241231
  → All dates up to December 31, 2024

Single day:
  start: 20241127
  end: 20241127
  → November 27, 2024 only
  
Last year:
  start: 20230101
  end: 20231231

Last 12 months (calculated):
  start: 20231201
  end: 20241130

Usage Patterns:

1. Historical data retrieval

   start: 20200101
   end: 20201231
   

2. Current year to date

   start: 20240101
   end: (today's date)
   

3. Future planning

   start: (today's date)
   end: 20250630
   

4. All available data

   start: (empty)
   end: (empty)
   Note: Some services may require at least one endpoint
   

TimePeriodType - Time Period

Timestamp interval specification with precision to seconds.

​View TimePeriodType logical model

Structure:

• start (1..1) - Period start timestamp (format YYYYMMDDhhmmss)
• end (0..1) - Period end timestamp (format YYYYMMDDhhmmss)

Cardinality:

• start: Required (1..1)
• end: Optional (0..1) for open-ended periods

Data Format:

• Format: YYYYMMDDhhmmss (ISO 8601 basic format)
• Year: 4 digits (YYYY)
• Month: 2 digits (MM: 01-12)
• Day: 2 digits (DD: 01-31)
• Hour: 2 digits (hh: 00-23)
• Minute: 2 digits (mm: 00-59)
• Second: 2 digits (ss: 00-59)
• No separators, no timezone (Swedish local time)
• 24-hour clock

Validation Rules:

1. start must match regex: ^\d{14}$
2. end (if provided) must match regex: ^\d{14}$
3. If end specified: end must be > start
4. Date-time must be valid (e.g., 20240229143052 valid, 20240230143052 invalid)
5. Hour must be 00-23 (24-hour format)
6. Minute and second must be 00-59
7. No leap seconds (59 max for seconds)

Precision:

• Full timestamp required (cannot omit seconds)
• For date-only semantics, use DatePeriodType instead
• Seconds should be set to 00 if not significant

Examples:

Specific time range:
  start: 20241127090000
  end: 20241127170000
  → Nov 27, 2024 9:00 AM to 5:00 PM

Open-ended from timestamp:
  start: 20240615120000
  end: (empty)
  → June 15, 2024 12:00 PM onwards

Precise moment (same start/end):
  start: 20241127143052
  end: 20241127143052
  → Nov 27, 2024 2:30:52 PM exactly

Last 24 hours:
  start: 20241126143052
  end: 20241127143052

Business hours today:
  start: 20241127080000
  end: 20241127170000

Usage Patterns:

1. Document creation time

   documentTime: 20241015132547
   

2. Alert validity period

   start: 20230518093000
   end: (empty - still valid)
   

3. Care contact time range

   start: 20241127090000
   end: 20241127103000
   

Timezone Handling:

• No explicit timezone in format
• Assumed Swedish local time (CET/CEST)
• Systems must handle DST transitions
• For UTC storage, convert at system boundaries

HSAIdType - HSA Identifier

HSA-ID according to Inera AB definition. String value.

Rules:

• Should be HSA-ID when available
• For OrgUnitType only: local unique ID acceptable if HSA-ID unavailable
• Format: System-specific string identifier

PersonIdType - Person Identifier

Person identification using personal number, coordination number, or reserve number.

Structure:

• id (1..1) - Identifier value (12 characters without separator)
• type (1..1) - OID for identifier type

Cardinality:

• Both fields required (1..1)

Identifier Types:

Validation Rules:

1. Personal Number (1.2.752.129.2.1.3.1)
   • Length: Exactly 12 digits
   • Format: YYYYMMDDNNNN
   • Year: 4 digits (1800-2099 typically)
   • Month: 2 digits (01-12)
   • Day: 2 digits (01-31, validated for month)
   • Control digits: 4 digits (NNNN, includes Luhn checksum)
   • No separators (-, +, spaces)
   • Regex: ^(19|20)\d{10}$
   • Must pass Luhn algorithm validation (10th digit is check digit)
2. Coordination Number (1.2.752.129.2.1.3.3)
   • Length: Exactly 12 digits
   • Format: YYYYMMDDNNNN
   • Day component: +60 (e.g., 61-91 instead of 01-31)
   • Example: 19700161 means born 1970-01-01 (01+60=61)
   • Regex: ^(19|20)\d{2}(0[1-9]|1[0-2])(6[1-9]|[78]\d|9[01])\d{4}$
   • Must pass modified Luhn algorithm
3. Reserve Numbers
   • Format varies by region/system
   • Used when personnummer not yet assigned
   • Consult local documentation

Usage Examples:

Swedish Citizen:
  id: 197001011234
  type: 1.2.752.129.2.1.3.1

Non-resident with Coordination Number:
  id: 197061611234
  type: 1.2.752.129.2.1.3.3

Newborn (temporary):
  id: 202411271234
  type: 1.2.752.129.2.1.3.1

Implementation Notes:

1. Historical Formats
   • Some legacy systems use 10-digit format (YYMMDDNNNN)
   • Must normalize to 12-digit format before transmission
   • Add century prefix: 00-18 → 20, 19-99 → 19
2. Validation in Code

   // Personnummer validation
   boolean isValid = value.matches("^(19|20)\\d{10}$") 
                     && luhnCheck(value.substring(2));
      
   // Samordningsnummer validation  
   boolean isValid = value.matches("^(19|20)\\d{2}(0[1-9]|1[0-2])(6[1-9]|[78]\\d|9[01])\\d{4}$")
                     && luhnCheck(value.substring(2));
   

3. Privacy Considerations
   • Personal numbers are sensitive data (GDPR)
   • Log only when required for audit
   • Mask in user interfaces when appropriate
   • Encrypt in transit and at rest
4. Test Data
   • Use synthetic test numbers (see Testing documentation)
   • Never use real personal numbers in test environments
   • Test ranges: 197001011234, 196006061234, etc.

OrgUnitType - Organization Unit

Information about an organization unit (healthcare facility, department, etc.)

​View OrgUnitType logical model

Structure:

• orgUnitHSAId (0..1) - HSA-ID or local unique ID
• orgUnitName (0..1) - Organization name
• orgUnitTelecom (0..1) - Telephone number
• orgUnitEmail (0..1) - Email address
• orgUnitAddress (0..1) - Postal address (natural format)
• orgUnitLocation (0..1) - Place name or locality

Example:

orgUnitHSAId: SE2321000016-1234
orgUnitName: Medicinkliniken
orgUnitTelecom: 08-123456
orgUnitEmail: medicin@example.se
orgUnitAddress: Vårdvägen 1, 123 45 Stad
orgUnitLocation: Huvudsjukhuset

MultimediaType - Multimedia Object

Multimedia object embedded or referenced.

​View MultimediaType logical model

Structure:

• id (0..1) - Identifier for internal references
• mediaType (1..1) - MIME type (e.g., "image/jpeg", "application/pdf")
• value (0..1) - Base64-encoded binary data
• reference (0..1) - External URL reference

Rules:

• Exactly one of value or reference must be specified
• mediaType must be valid MIME type
• See interaction agreements for:
  • Supported media types
  • Size limitations
  • External reference policies

Examples:

Embedded Image:
  mediaType: image/jpeg
  value: /9j/4AAQSkZJRgABAQEAYABgAAD...

External PDF:
  mediaType: application/pdf
  reference: https://example.se/documents/12345.pdf

ResultType - Operation Result

Result of a service operation.

​View ResultType logical model

Structure:

• resultCode (1..1) - Operation result: OK

  INFO

  ERROR

• resultText (0..1) - Descriptive message

Result Codes:

Examples:

Success:
  resultCode: OK

Success with info:
  resultCode: INFO
  resultText: "Resultat från 3 av 4 tillfrågade system. Ett system svarade inte inom tidsgräns."

Logical error:
  resultCode: ERROR
  resultText: "Referensen som skickats i hasMoreReference är ogiltig"

JoL-Header (Journal Header)

The JoL-header is a common header structure used for reading journal information.

Version: 2.2

Purpose

The header provides:

1. Information for access control decisions
2. Metadata common to patient journal information
3. Authorship and signature information

Structure Overview

Header
├── AccessControlHeader
│   ├── accountableHealthcareProvider (0..1)
│   ├── accountableCareUnit (0..1)
│   ├── patientId (1..1)
│   ├── careProcessId (0..1)
│   ├── blockComparisonTime (1..1)
│   └── approvedForPatient (1..1)
├── sourceSystemId (1..1)
├── record (1..1)
│   ├── id (1..1)
│   └── timestamp (1..1)
├── author (0..1)
│   ├── id (0..1)
│   ├── name (0..1)
│   ├── timestamp (1..1)
│   ├── byRole (0..1)
│   └── orgUnit (0..1)
└── signature (0..1)
    ├── id (0..1)
    ├── name (0..1)
    ├── timestamp (0..1)
    └── byRole (0..1)

AccessControlHeader

Contains information needed by consumer to determine if user has access rights.

Key Fields:

• accountableHealthcareProvider - Information-owning care giver (HSA-ID or org number)
• accountableCareUnit - Information-owning care unit (HSA-ID)
• patientId - Patient identifier as stored when data created
• blockComparisonTime - Timestamp for blocking control check
• approvedForPatient - Whether info may be shared with patient

Purpose:

• PDL blocking control
• Access logging
• Patient access filtering

Record Metadata

record.id - Unique, persistent identifier (UUID in root, extension empty)

• Must be consistent across versions and contracts
• Used for deduplication

record.timestamp - First creation time at producer

Author

Healthcare professional responsible for the information.

Key Fields:

• id - HSA-ID
• name - Professional name
• timestamp - Creation or last update time
• byRole - Professional role (KV Befattning preferred)
• orgUnit - Organization unit details

Signature

Digital signature information (when signed).

Key Fields:

• id - Signing person HSA-ID
• name - Signing person name
• timestamp - Signature timestamp
• byRole - Role at time of signing

Note: Per SOSFS 2016:40, unsigned journal entries can no longer be locked. Signature required for locking.

Code Systems

National Code Systems

International Code Systems

Identifier Systems

Usage Across Contracts

Legend: GCD=GetCareDocumentation, GD=GetDiagnosis, GAI=GetAlertInformation, GFS=GetFunctionalStatus

References

• Common Data Types specification version 7, 17, 19 (varies by contract)
• RIV Technical Framework documentation
• National code system documentation at Inera
• ISO 8601 Date and time formats