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

Testing and Validation

Testing and Validation

This page provides guidance for testing implementations of the Health Condition Description services.

Test Environments

Development (DEV)

• Purpose: Rapid iteration and development
• Stability: Frequent changes expected
• Data: Synthetic test data
• Availability: Best effort

Test (TEST)

• Purpose: Integration and system testing
• Stability: Stable environment
• Data: Controlled test datasets
• Availability: 08:00-18:00 weekdays

Acceptance (ACC)

• Purpose: User acceptance testing and pre-production validation
• Stability: Production-like
• Data: Production-like synthetic data
• Availability: 24/7

Production (PROD)

• Purpose: Live environment
• Data: Real patient data
• Availability: 24/7 with SLA

Test Patient Identifiers

Synthetic Personnummer

Test patient numbers follow the pattern 19YYYYMMDD-NNNN where:

• Year: 1900-2099
• Month: 01-12 or 61-72 (samordningsnummer)
• Day: 01-31 or 61-91 (samordningsnummer)

Common Test Patients:

Synthetic Samordningsnummer

Reserve Numbers

Local reserve numbers for testing (SLL example):

• OID: 1.2.752.97.3.1.3
• Format: 920000001234

Note: Reserve numbers only work with direct system addressing, not via aggregating services.

Test Scenarios by Service

GetCareDocumentation

Scenario 1: Basic Retrieval

Objective: Verify basic patient journal retrieval

Request:

<patientId>
  <id>197001011234</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>
<timePeriod>
  <start>20240101</start>
  <end>20241231</end>
</timePeriod>

Expected Result:

• Result code: OK
• At least 5 care documentation entries
• Entries sorted by documentTime descending
• All required fields present

Scenario 2: Care Unit Filtering

Objective: Filter by specific care unit

Request:

<patientId>
  <id>198503169876</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>
<careUnitHSAId>SE2321000016-1234</careUnitHSAId>

Expected Result:

• Only documents from specified care unit
• All documents have accountableCareUnit = SE2321000016-1234

Scenario 3: Invalid Date Period

Objective: Test validation

Request:

<timePeriod>
  <start>20241231</start>
  <end>20240101</end>
</timePeriod>

Expected Result:

• Result code: INVALID_REQUEST
• Error message about date period ordering

Scenario 4: Partial Data Retrieval

Objective: Test pagination

Request 1:

<patientId>
  <id>196006061234</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>

Expected Result 1:

• Result code: OK
• hasMore element present with:
  • logicalAddress
  • reference

Request 2:

<hasMoreReference>[reference from response 1]</hasMoreReference>

Expected Result 2:

• Next batch of records
• No duplicate records

Scenario 5: Patient Blocking

Objective: Test access control

Setup: Patient 197001011234 blocks access from test system

Request:

<patientId>
  <id>197001011234</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>

Expected Result:

• Result code: BLOCKED
• No patient data returned

GetDiagnosis

Scenario 1: Basic Diagnosis Retrieval

Request:

<patientId>
  <id>197001011234</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>
<timePeriod>
  <start>20240501</start>
  <end>20241031</end>
</timePeriod>

Expected Result:

• At least 3 diagnosis entries
• Each with diagnosis code (ICD-10)
• Sorted by registration time

Scenario 2: Care Contact Filter

Request:

<patientId>
  <id>198812189090</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>
<careContactId>CONTACT-2024-001</careContactId>

Expected Result:

• Only diagnoses from specified care contact

GetAlertInformation

Scenario 1: All Alerts

Request:

<patientId>
  <id>197505051234</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>

Expected Result:

• At least 2 alert entries
• Types may include: allergies, warnings, restrictions

Scenario 2: Time-Limited Alerts

Request:

<patientId>
  <id>196712122345</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>
<timePeriod>
  <start>20241101</start>
  <end>20241130</end>
</timePeriod>

Expected Result:

• Only alerts valid during specified period

GetFunctionalStatus

Scenario 1: All Assessments

Request:

<patientId>
  <id>193010101234</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>

Expected Result:

• ADL and/or PADL assessments
• Assessment details present

Scenario 2: Multiple Care Units

Request:

<patientId>
  <id>194002021234</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>
<careUnitHSAId>SE2321000016-NEURO</careUnitHSAId>
<careUnitHSAId>SE2321000016-REHAB</careUnitHSAId>

Expected Result:

• Assessments from both care units

Aggregating Service Tests

Scenario: Multi-Source Aggregation

Objective: Verify data from multiple source systems is combined

Setup:

• Configure test patient data in System A and System B
• Use aggregator logical address

Request:

<LogicalAddress>5565594230</LogicalAddress>
<patientId>
  <id>197001011234</id>
  <type>1.2.752.129.2.1.3.1</type>
</patientId>

Expected Result:

• Data from both systems in response
• No duplicates
• Proper source system attribution

Scenario: Partial Failure Handling

Objective: Verify behavior when some systems fail

Setup:

• System A available
• System B temporarily unavailable

Expected Result:

• Result code: OK
• partial flag = true
• Data from System A present
• Failed source listed

Performance Testing

Response Time Targets

Load Testing

Test Cases:

1. Sustained Load
   • 10 concurrent users per source system
   • Duration: 1 hour
   • Expected: No errors, response time within targets
2. Peak Load
   • 50 concurrent users
   • Duration: 15 minutes
   • Expected: < 1% error rate, degraded but acceptable response time
3. Stress Test
   • Increase load until failure
   • Identify breaking point
   • Verify graceful degradation

Security Testing

Authentication Tests

1. Valid Certificate
   • Expected: Request accepted
2. Invalid Certificate
   • Expected: Request rejected at transport level
3. Expired Certificate
   • Expected: Request rejected

Authorization Tests

1. Authorized User
   • User with PDL permissions
   • Expected: Access granted
2. Unauthorized User
   • User without PDL permissions
   • Expected: ACCESS_DENIED
3. System Authorization
   • Verify system-to-system authorization

Troubleshooting Common Issues

Issue: CONNECTION_REFUSED

Cause: Service endpoint not reachable
Check:

• Network connectivity
• Firewall rules
• Service is running
• Correct endpoint URL

Issue: CERTIFICATE_ERROR

Cause: SSL/TLS certificate problem
Check:

• Certificate validity
• Certificate chain
• Hostname matches
• Certificate in truststore

Issue: TIMEOUT

Cause: Request took too long
Check:

• Reduce query scope (date range)
• Check source system performance
• Network latency

Issue: NO_DATA_FOUND

Cause: No data matches query
Check:

• Patient ID correct
• Date range appropriate
• Patient has data in source system
• EI is updated

Test Data Management

Creating Test Data

Guidelines:

• Use allocated test personnummer
• Mark data as test data
• Include variety of scenarios
• Document test data setup

Test Data Lifecycle

1. Create - Set up test scenarios
2. Use - Run tests
3. Verify - Check results
4. Clean - Remove after testing (if not persistent)

Test Data Reset

Some test environments support data reset:

• Scheduled resets (e.g., nightly)
• On-demand reset via API
• Per-patient reset

Validation Checklist

Before Production

• All test scenarios pass
• Performance meets targets
• Error handling verified
• Security tests pass
• Logging configured
• Monitoring set up
• Documentation complete
• Operations team trained

Integration Checklist

• Endpoint configuration correct
• Certificates installed
• Trust relationships established
• Error handling implemented
• Retry logic configured
• Audit logging active
• User permissions configured
• Test patient queries successful

References

• Errors - Error codes and handling
• Security - Security requirements
• Business Rules - Validation rules
• Deployment - Configuration and setup