1.0.0 - ci-build

CoreServicesIG - Local Development build (v1.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Structures: Abstract Profiles

These are profiles on resources or data types that describe patterns used by other profiles, but cannot be instantiated directly. I.e. instances can conform to profiles based on these abstract profiles, but do not declare conformance to the abstract profiles themselves.

BaseAuditEventLogging - Base profile for audit event logging

This is an AuditEvent profile used for logging. The mustSupport-flag indicates that a producer of resources conforming to this profile SHALL include this data if it is known to them.

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide

ActivityDefinition (Care Plan context)

A custom profile for ActivityDefinition is designed to be used in the Care plan context. This profile supports the standardized definition of clinical and administrative activities as part of structured care planning processes, such as those represented in vårdplaner (care plans). It includes metadata, participants, and an abbreviation extension to support the concise representation of activity titles in user interfaces. The mustSupport flag indicates which attributes are supported by Cambio, meaning that these elements will be stored and interpreted as part of the ActivityDefinition instance. The profile is intended for use in regional EHR systems and decision support applications where consistent activity definitions are essential for care coordination, task automation, and interoperability across systems.

AuditEventLoggingFhirServiceSe

This is an AuditEvent profile used for logging interactions with the Cambio Platform Core Service’s APIs. The mustSupport-flag indicates that a producer of resources conforming to this profile SHALL include this data if it is known to them.
This profile is following the IHE Basic Audit Log Patterns (BALP) for logging API requests. However, some minor adjustments have been made in regards to how entities are coded in order for it to function when having only one profile.In comparison to IHE BALP that has multiple profiles, one for each type of request.

AuditEventLoggingSe - profile used for logging

This is an AuditEvent profile used for logging. The mustSupport-flag indicates that a producer of resources conforming to this profile SHALL include this data if it is known to them.

AuditEventLoggingServiceAccount

This is an AuditEvent profile used for logging when a service account is making the API requests. The mustSupport-flag indicates that a producer of resources conforming to this profile SHALL include this data if it is known to them.

AuditEventLoggingServiceAccount - profile used for logging

This is an AuditEvent profile used for logging when a service account is making the API requests. The mustSupport-flag indicates that a producer of resources conforming to this profile SHALL include this data if it is known to them.

ConsentBlockSe - Consent profile used for representing blocks

Profile to represent a patient block to accessing their personal health information among care units and care providers in Sweden.

ConsentBlockSE_1_0_0

Profile to represent a patient block to accessing their personal health information among care units and care providers in Sweden.

ConsentBlockSE_2_0_2

Profile to represent a patient block to accessing their personal health information among care units and care providers in Sweden.

ConsentSharedElectronicHealthRecordSe - Consent profile for PDL/SVOD consents

Profile to represent a consent given to a clinician or a care unit to access a patient’s electronic health record.

ConsentSharedElectronicHealthRecordSe_1_0_0

Profile to represent a consent given to a clinician or a care unit to access a patient’s electronic health record .

ConsentSharedElectronicHealthRecordSe_1_1_2

Profile to represent a consent given to a clinician or a care unit to access a patient’s electronic health record .

ConsentTemporaryRevocationSe - Consent profile for temporary revokations of consents

Profile to represent a temporary revocation of an inner block set by a patient.

ConsentTemporaryRevocationSE_1_0_2

Profile to represent a temporary revocation of an inner block set by a patient.

PatientEhrIdSupportSe - Patient profile supporting openEHR EHR ids

Patient profile with support to represent an openEHR ehr_id in a Swedish context.

Task (Care Plan context)

A custom profile for Task is designed to be used in the Care plan context. This profile supports the representation of actionable clinical or administrative tasks within structured care planning workflows, such as those found in vårdplaner (care plans). It includes metadata, participants, and task status elements essential for tracking the responsibility and progress of planned activities. The profile facilitates coordination across care teams and systems by enabling a standardized way to assign, manage, and monitor tasks. The mustSupport flag indicates which attributes are supported by Cambio, meaning these elements will be stored and utilized as part of the Task resource in clinical and administrative processes.

Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide

AbbreviationExtension

A short name or abbreviation for the ActivityDefinition title.

ActivityDefinitionTypeExtension

A classification of the type of clinical or administrative activity represented by the ActivityDefinition.

Editor HSA-ID

Adds a Swedish HSA-ID (Identifier) to ActivityDefinition.editor (ContactDetail).

Reviewer HSA-ID

Adds a Swedish HSA-ID (Identifier) to ActivityDefinition.reviewer (ContactDetail).

Task Performer

Backport of R5 Task.performer for R4. Enables recording one or more actual performers of a Task using explicit sub-extensions for PractitionerRole, CareTeam, and Device. Emphasizes Swedish role-based accountability (PractitionerRole with HSA-id), collaborative multidisciplinary execution (CareTeam), and automation or assisted actions (Device). Supports analytics and traceability without binding to deprecated R4 patterns. Ordering of sub-extensions is not significant. Record each performer once per type. If both CareTeam and constituent PractitionerRoles are included, ensure this reflects a deliberate analytics need (aggregate + granular); otherwise prefer the most specific representation only.

Task Requested Performer (Reference)

Identifies the requested performer(s) of a Task using role-based references (PractitionerRole only). Focuses on planned assignment at the professional role level without binding to individual Practitioner or Organization resources.

Task Requested Period

Planned time window for when the task should be performed.

Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide

Activity Definition Type Value Set

This value set contains the allowed codes from the Activity Definition Type code system.

Audit Event Agent Types Value Set

This value set contains all codes from the code system Audit Event Agent Types and also codes from the extensible FHIR value set Participation Role Type.

Consent Categories Value Set

This value set contains consent categories that are relevant for consents and blocks in the context of Swedish legislations.

Consent Categories Value Set SE

Consent Categories Value Set SE

Consent Purpose Types Value Set

This value set contains all codes from the code system Consent Purpose Types

Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide

Activity Definition Type

Codes that classify the type of clinical or administrative activity represented by an ActivityDefinition.

AuditEventAgentTypes

This codesystem specifies different types of agents involved in an event, in a Sweden specific context.

AuditEventEntityTypes

Specifies the type codes used for entities that play a part in an audit event. Does not include codes already definied elsewhere by well-renowned actors.

Consent Purpose Types

This codesystem contains purpose types that are relevant in a Sweden specific context.

Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like

AuditEventLoggingFhirServiceSeExample

AuditEvent example for a successful read.

CreateCompositionExample

This is an example of following scenarios, 1: Create composition successfully

CreateCompositionInternalExample

This is an example of following scenarios, 1: Create composition successfully

CreateConsentExample

Example of consent to access shared EHR given by a patient or a representative of the patient

InnerBlockExample

Example instance of an inner block

OrganizationSEVendorLiteExample

An example of an organization

OuterBlockExample

Example Instance for Outer block

OuterBlockWithExceptionsExample

Example instance of an outer block with exceptions for prescribed medications and attention signal information.

Pain assessment

Example of an ActivityDefinitionSe for pain assessment using an inhabitant form completed by the patient.

PatientSEVendorLiteExample

An example of a patient

PatientWithEhrIdAndPersonnummerExample

This is an example of a patient who has a personnummer and an ehr_id as identifiers.

PatientWithEhrIdAndReservnummerExample

This is an example of a patient who has a reservnummer and an ehr_id but in different identifiers.

PatientWithEhrIdAndSamordningsnummerExample

This is an example of a patient who has a samordningsnummer and an ehr_id but in different identifiers.

PatientWithEhrIdExample

This is an example of a patient who has an ehr_id as identifier.

PatientWithPersonnummerExample

This is an example of a patient who has only a personal number as identifier.

PatientWithReservnummerExample

This is an example of a patient who has only a reservnummer as identifier.

PatientWithSamordningsnummerExample

This is an example of a patient who has only a samordningsnummer as identifier.

PractitionerSEVendorLiteExample

Simple example of PractitionerSEVendorLite profile.

ReadCompositionExample

This is an example of following scenarios, 1: Read composition that is returned 2: Read composition that doesn’t exist

ReadCompositionInternalExample

This is an example of following scenarios, 1: Read composition that is returned 2: Read composition that doesn’t exist

StoredQueryExecutionExample

This is an example of following scenarios, 1: Stored query execution that went well and returned data

StoredQueryExecutionInternalExample

This is an example of following scenarios, 1: Stored query execution that went well and returned data

TaskIsolationStartStopExample

The TaskCarePlan profile is used to represent actionable clinical and administrative tasks within structured care planning workflows in COSMIC. The profile is based on the FHIR resource Task. A custom profile for Task designed for use in care plan contexts, supporting vårdplaner (care plans) workflows. This profile facilitates coordination across care teams and systems by enabling standardized task assignment, management, and monitoring. It includes metadata, participants, and task status elements essential for tracking responsibility and progress of planned activities. This example demonstrates a Start/Stop type isolation management task in Swedish healthcare context. The task involves initiating contact isolation precautions for a patient with suspected MRSA and later discontinuing isolation after negative culture results, requiring coordination across infection control team and ward staff.

TaskPatientIdentityVerificationExample

The TaskCarePlan profile is used to represent actionable clinical and administrative tasks within structured care planning workflows in COSMIC. The profile is based on the FHIR resource Task. A custom profile for Task designed for use in care plan contexts, supporting vårdplaner (care plans) workflows. This profile facilitates coordination across care teams and systems by enabling standardized task assignment, management, and monitoring. It includes metadata, participants, and task status elements essential for tracking responsibility and progress of planned activities. The mustSupport flag indicates which attributes are supported by Cambio, meaning these elements will be stored and utilized as part of the Task resource in clinical and administrative processes. This example demonstrates a critical safety checklist item for patient identity verification in Swedish healthcare context that must be completed before any medical procedure or intervention, ensuring patient safety and regulatory compliance.

TemporaryRevocationExample

Example instance of a temporary revocation.

UpdateCompositionExample

This is an example of following scenarios, 1: Update composition successfully

UpdateCompositionInternalExample

This is an example of following scenarios, 1: Update composition successfully