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

Information Security

Information Security and Legal Requirements

This page documents the information security and legal compliance requirements for the Health Condition Description service domain.

Patientdatalagen (PDL) - Patient Data Law

The Swedish Patient Data Law governs access to patient information:

Key Principles:

  • Vårdrelation (Care Relationship) - Required for access
  • Ändamålsbegränsning (Purpose Limitation) - Only for specified purposes
  • Spärr (Blocking) - Patient can block access
  • Samtycke (Consent) - May be required in some cases
  • Loggning (Logging) - All access must be logged

Reference: Patientdatalagen (2008:355)

SOSFS 2016:40

Socialstyrelsen's regulations on journal keeping and personal data processing:

Key Requirements:

  • Digital signature required for locking journal entries
  • Strong authentication in shared networks
  • Care unit selection at authentication
  • Specific logging requirements
  • Information security measures

Reference: SOSFS 2016:40 - Journalföring och behandling av personuppgifter i hälso- och sjukvården

GDPR Compliance

EU General Data Protection Regulation applies:

  • Lawful basis - PDL provides basis for processing
  • Data minimization - Only necessary data
  • Purpose limitation - Specified purposes only
  • Storage limitation - Retention policies
  • Rights of data subjects - Access, rectification, erasure

Security Roles and Responsibilities

Consumer Responsibilities

Authentication:

  • Authenticate end users (healthcare professionals or patients)
  • Strong authentication (two-factor) when required
  • Maintain user sessions securely

Authorization:

  • Verify care relationship (vårdrelation)
  • Check blocking status before displaying
  • Respect consent requirements
  • Apply organizational policies

Logging:

  • Log all access to patient information
  • Include: who, what, when, where, why
  • Secure log storage
  • Log retention per regulations

Data Handling:

  • Protect data in transit and at rest
  • Limit data exposure to authorized users
  • Secure data disposal

Producer Responsibilities

Access Control:

  • Verify consumer authorization
  • Filter responses per organizational policy
  • Respect patient blocking
  • Apply security classifications

Data Quality:

  • Maintain accurate, complete information
  • Update engagement index promptly
  • Set approvedForPatient flag appropriately
  • Provide required metadata

System Security:

  • Secure system infrastructure
  • Protect against unauthorized access
  • Monitor for security events
  • Incident response capability

Platform Responsibilities

Transport Security:

  • TLS/HTTPS for all communications
  • Certificate management
  • Secure key storage

Routing:

  • Correct message routing
  • Prevention of unauthorized access
  • Monitoring and alerting

Technical Security Implementation

Transport Layer Security (TLS)

Requirements:

  • TLS Version: Minimum TLS 1.2, TLS 1.3 recommended
  • Cipher Suites: Strong ciphers only
    • ECDHE-RSA-AES256-GCM-SHA384
    • ECDHE-RSA-AES128-GCM-SHA256
    • TLS_AES_256_GCM_SHA384 (TLS 1.3)
  • Certificate Validation: Full chain validation required
  • Certificate Revocation: OCSP or CRL checking

Configuration Example (Java):

SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
sslContext.init(keyManagers, trustManagers, secureRandom);

SSLParameters sslParams = new SSLParameters();
sslParams.setProtocols(new String[]{"TLSv1.2", "TLSv1.3"});
sslParams.setCipherSuites(new String[]{
    "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
    "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
});

WS-Security Headers

All SOAP requests must include WS-Security headers for authentication:

<soap:Header>
  <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                 xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <wsse:BinarySecurityToken 
        EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
        ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
        wsu:Id="X509Token">
      MIIDXTCCAkWgAwIBAgIJALx... (Base64-encoded certificate)
    </wsse:BinarySecurityToken>
    
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <ds:Reference URI="#MsgId-123">
          <ds:Transforms>
            <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          </ds:Transforms>
          <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          <ds:DigestValue>abc123... (Base64 digest)</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>xyz789... (Base64 signature)</ds:SignatureValue>
      <ds:KeyInfo>
        <wsse:SecurityTokenReference>
          <wsse:Reference URI="#X509Token"/>
        </wsse:SecurityTokenReference>
      </ds:KeyInfo>
    </ds:Signature>
    
    <wsu:Timestamp wsu:Id="TS-1">
      <wsu:Created>2024-11-27T14:30:00Z</wsu:Created>
      <wsu:Expires>2024-11-27T14:35:00Z</wsu:Expires>
    </wsu:Timestamp>
  </wsse:Security>
  
  <!-- Additional WS-Addressing headers -->
  <wsa:To>https://services.inera.se/...</wsa:To>
  <wsa:Action>urn:riv:clinicalprocess:healthcond:description:...</wsa:Action>
  <wsa:MessageID wsu:Id="MsgId-123">urn:uuid:12345678-...</wsa:MessageID>
</soap:Header>

SITHS Certificates

SITHS (Säker IT i Hälso- och Sjukvården) - Secure IT in Healthcare:

Certificate Types:

  1. Organizational Certificates: For system-to-system authentication
  2. Personal Certificates: For healthcare professional authentication
  3. Function Certificates: For specific system functions

Certificate Content:

  • Subject DN: Distinguished Name with organization info
  • HSA-ID: In certificate extension or subject
  • Valid Period: Typically 1-3 years
  • Key Usage: Digital Signature, Key Encipherment
  • Extended Key Usage: Client Authentication, Server Authentication

Example Certificate Subject:

CN=Vårdgivare AB Tjänstekonsument
OU=IT Department
O=Vårdgivare AB
C=SE
serialNumber=SE2321000016-1234 (HSA-ID)

Java KeyStore Configuration:

KeyStore keyStore = KeyStore.getInstance("JKS");
keyStore.load(new FileInputStream("siths-cert.jks"), "password".toCharArray());

KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
kmf.init(keyStore, "keypassword".toCharArray());

TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(new FileInputStream("siths-trust.jks"), "trustpassword".toCharArray());
tmf.init(trustStore);

SAML Assertions

For authentication propagation, SAML 2.0 assertions may be included:

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                ID="_a1b2c3d4e5f6" 
                IssueInstant="2024-11-27T14:30:00Z"
                Version="2.0">
  <saml:Issuer>https://idp.example.se</saml:Issuer>
  
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <!-- Digital signature of assertion -->
  </ds:Signature>
  
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
      SE2321000016-A123 (HSA-ID of professional)
    </saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData
          NotOnOrAfter="2024-11-27T15:30:00Z"
          Recipient="https://services.inera.se/..."/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  
  <saml:Conditions
      NotBefore="2024-11-27T14:30:00Z"
      NotOnOrAfter="2024-11-27T15:30:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://services.inera.se</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  
  <saml:AuthnStatement AuthnInstant="2024-11-27T14:25:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  
  <saml:AttributeStatement>
    <saml:Attribute Name="urn:sambi:names:attribute:hsaIdentity">
      <saml:AttributeValue>SE2321000016-A123</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="urn:sambi:names:attribute:displayName">
      <saml:AttributeValue>Dr. Anna Andersson</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="urn:sambi:names:attribute:assignmentHsaId">
      <saml:AttributeValue>SE2321000016-5678</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="urn:sambi:names:attribute:purposeOfUse">
      <saml:AttributeValue>urn:sambi:names:attribute:purposeOfUse:CARE</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Key SAML Attributes:

  • hsaIdentity: HSA-ID of healthcare professional
  • displayName: Professional's name
  • assignmentHsaId: Care unit HSA-ID (uppdragsval)
  • purposeOfUse: Access purpose (CARE, RESEARCH, QUALITY, ADMIN)

Access Control Models

Healthcare Professional Access

Direct Access (Direktåtkomst)

For healthcare professionals accessing across organizational boundaries:

Requirements:

  1. Strong Authentication
    • Two-factor authentication
    • Certificate-based or equivalent
    • In networks shared between care givers
  2. Care Unit Selection
    • Select care unit (uppdragsval) at login
    • Unit determines access rights
    • Logged with access
  3. Care Relationship
    • Must have vårdrelation with patient
    • Or access for coordination/continuity
    • Documented reason for access
  4. Blocking Control
    • Check for patient blocks
    • Outer block (between care givers)
    • Inner block (within care giver)
    • blockComparisonTime used for check

Implementation:

1. User authenticates with strong credentials
2. User selects care unit
3. System fetches patient information
4. For each record:
   a. Check blockComparisonTime against blocks
   b. If blocked: do not display
   c. If not blocked: check approvedForPatient
   d. Display if approved
5. Log access (who, what, when, where, why)

Spärr (Blocking)

Outer Block (Yttre spärr):

  • Patient blocks access between care givers
  • Checked using blockComparisonTime
  • accountableHealthcareProvider identifies owner

Inner Block (Inre spärr):

  • Patient blocks access within care giver
  • Between different care units
  • accountableCareUnit identifies owner

Emergency Override:

  • Access despite block in emergency (nödfall)
  • Must be documented and justified
  • Extra scrutiny in audit logs

Patient Access

For patients accessing their own information:

Requirements:

  1. Strong Authentication
    • BankID or equivalent
    • Personal identification verified
  2. ApprovedForPatient Flag
    • Only show information where flag = true
    • Respect rådrum (reflection period)
    • Respect menprövning (appropriateness review)
  3. No Blocking Check
    • Patients cannot block themselves
    • Blocking only applies to professional access
  4. Logging
    • Log patient access
    • Less detailed than professional access
    • Privacy considerations

Implementation:

1. Patient authenticates with BankID
2. System fetches patient information
3. Filter: approvedForPatient = true
4. Display approved information
5. Log access

Rådrum (Reflection Period)

Healthcare providers may withhold information from patients temporarily:

Purpose:

  • Allow professional to inform patient personally
  • Prepare patient for difficult information
  • Clinical judgment

Duration:

  • Typically 14 days
  • Can be extended with justification
  • Eventually must be released

Implementation:

  • approvedForPatient = false during rådrum
  • Updated to true when period expires
  • Engagement index updated

Menprövning (Appropriateness Review)

Assessment of whether information is appropriate for patient:

Criteria:

  • Patient's best interest
  • Risk of misunderstanding
  • Sensitive content
  • Mental health considerations

Decision:

  • Made by responsible professional
  • Documented reason
  • Can be appealed by patient

Security Controls

Transport Layer Security

TLS Configuration:

Minimum Version: TLS 1.2
Cipher Suites: Strong ciphers only
Certificate Validation: Required
Certificate Revocation: OCSP/CRL

Message Level Security

WS-Security:

SAML Token: User identity and attributes
X.509 Certificate: System identity
Signature: Message integrity
Timestamp: Replay prevention

Authentication Methods

User Type Method Standard
Healthcare Professional SITHS card Swedish eID
Healthcare Professional Soft certificate Alternative
Patient BankID Swedish eID
Patient Other strong eID EU notified
System X.509 certificate PKI

Authorization Model

Attribute-Based Access Control (ABAC):

Attributes considered:

  • User role (profession, befattning)
  • User organization (care giver, care unit)
  • Patient relationship (vårdrelation)
  • Purpose of access (ändamål)
  • Information classification
  • Patient preferences (blocks, consent)
  • Time of access

Decision:

PERMIT if:
  - Valid authentication AND
  - Care relationship OR emergency override AND
  - Not blocked OR emergency override AND
  - Organizational policy permits AND
  - Information approved for access type
DENY otherwise

Audit Logging

Required Log Information

Per SOSFS 2016:40 and PDL:

Access Log Entry:

{
  "timestamp": "20241127143052",
  "user": {
    "id": "HSA-ID or personal number",
    "name": "User name",
    "role": "Profession/role",
    "organization": "Care giver/unit"
  },
  "patient": {
    "id": "Patient personal number"
  },
  "access": {
    "type": "Read/Search",
    "resource": "Care documentation/Diagnosis/etc",
    "purpose": "Direct care/Coordination/etc",
    "care_unit": "Selected care unit",
    "emergency": false
  },
  "system": {
    "ip_address": "Source IP",
    "user_agent": "System identifier"
  },
  "result": "Success/Denied"
}

Log Retention

  • Minimum: 3 years from last access
  • Longer if clinical relevance
  • Secure storage required
  • Access restricted to authorized audit personnel

Log Review

Regular Review:

  • Random sampling
  • Pattern detection
  • Anomaly identification

Event-Triggered Review:

  • Patient complaint
  • Security incident
  • Suspected misuse

Handling Violations:

  • Investigation procedure
  • Disciplinary action
  • Legal proceedings if warranted

Data Protection

Data Classification

Level Description Example Controls
Highly Sensitive Severe impact if disclosed HIV status, psychiatric care Strongest controls
Sensitive Significant impact General medical info Standard controls
Internal Limited impact Aggregated statistics Basic controls
Public No impact General health information Minimal controls

Encryption

Data in Transit:

  • TLS 1.2+ for all communications
  • Strong cipher suites
  • Certificate pinning where applicable

Data at Rest:

  • Disk encryption for databases
  • File encryption for backups
  • Key management procedures

Data Minimization

Principle:

  • Request only necessary data
  • Use appropriate filters
  • Limit time periods
  • Delete/archive when no longer needed

Implementation:

  • Use specific search criteria
  • Don't cache unnecessarily
  • Clear session data
  • Regular cleanup procedures

Privacy by Design

Principles Applied

  1. Proactive not Reactive
    • Security built in from start
    • Anticipate privacy risks
  2. Privacy as Default
    • approvedForPatient defaults carefully
    • Opt-in rather than opt-out
  3. Privacy Embedded
    • Part of system design
    • Not add-on
  4. Positive-Sum
    • Privacy AND functionality
    • Not trade-offs
  5. End-to-End Security
    • Full lifecycle protection
    • All components secure
  6. Visibility and Transparency
    • Clear policies
    • User awareness
  7. Respect for User Privacy
    • User-centric design
    • Rights respected

Incident Response

Security Incident

Detection:

  • System monitoring
  • User reports
  • Audit log analysis
  • Third-party notification

Response:

  1. Contain - Limit damage
  2. Investigate - Determine scope
  3. Remediate - Fix vulnerability
  4. Notify - Inform affected parties
  5. Document - Record incident
  6. Learn - Improve processes

Data Breach

Definition:

  • Unauthorized access to personal data
  • Loss or destruction of data
  • Unauthorized disclosure

Notification:

  • Datainspektionen (Swedish DPA) within 72 hours
  • Affected individuals without undue delay
  • Healthcare regulator if relevant

Documentation:

  • Facts of breach
  • Effects
  • Remedial action taken

Security Testing

Types of Testing

Vulnerability Scanning:

  • Automated tools
  • Regular schedule
  • Prioritized remediation

Penetration Testing:

  • Simulated attacks
  • Annual or after major changes
  • Third-party testing

Security Audits:

  • Code review
  • Configuration review
  • Process compliance

Security Metrics

Tracked Metrics:

  • Vulnerabilities found/fixed
  • Time to patch
  • Security incidents
  • Audit findings
  • Compliance status

Compliance Monitoring

Regular Assessments

Internal Audits:

  • Quarterly reviews
  • Compliance checklists
  • Remediation tracking

External Audits:

  • Annual third-party assessment
  • Regulatory inspections
  • Certification maintenance

Compliance Documentation

Required Documentation:

  • Security policies
  • Risk assessments
  • Procedures and guidelines
  • Audit logs
  • Incident reports
  • Training records

User Training

Healthcare Professionals

Topics:

  • PDL requirements
  • Access control procedures
  • Blocking and consent
  • Logging requirements
  • Secure handling of patient data
  • Incident reporting

Frequency:

  • Initial training
  • Annual refresher
  • After major changes

System Administrators

Topics:

  • System security configuration
  • Monitoring and alerting
  • Incident response
  • Backup and recovery
  • Vulnerability management

References