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
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
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. |
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. |
| 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. |
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. |
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 |
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. |
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 |