1.0.0 - release
CambioOpenServicesIG - 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.
The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.
| CapabilityStatement |
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.
| ObservationBPCore |
Cambio Core profile for communicating the vital sign, Blood pressure. The profile is not intended to be used as is. When implementing, use profiles that are derived from this one. |
These define constraints on FHIR resources for systems conforming to this implementation guide.
| AppointmentBookingSe |
IntroductionAppointmentBookingSe is a profile based on the FHIR resource Appointment. Intended UseAppointmentBookingSe is used for patients scheduling a new appointment. An appointment needs information about the patient, the healthcare service to be performed, as well as a slot for booking the appointment. AppointmentBookingSe is profiled for the Swedish market. Versions
Statuses
APIs & Supported Operations
Supported Queries
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| AppointmentCancellationSe |
IntroductionAppointmentCancellationSe is a profile based on the FHIR resource Appointment. Intended UseAppointmentCancellationSe is used when a patient cancels an appointment. AppointmentCancellationSe is profiled for the Swedish market. Versions
Statuses
APIs & Supported Operations
Supported Queries
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| AppointmentCoreSe | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| AppointmentRebookingSe |
IntroductionAppointmentRebookingSe is a profile on the FHIR resource Appointment. Intended UseAppointmentRebookingSe is used for rebooking a scheduled appointment. AppointmentRebookingSe is profiled for the Swedish market. Versions
Statuses
APIs & Supported Operations
Supported Queries
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| AppointmentSe |
IntroductionAppointmentSe is a profile based on the FHIR resource Appointment. Intended UseAppointmentSe is used for appointments. The profile can be used either to request all appointments for a patient, or request information for a single appointment. AppointmentSe is profiled for the Swedish market. The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API. A limitation to these APIs is that they are only applicable for appointments that are seen as web appointments in COSMIC. Web appointments are appointments that patients can see in an app or on a website outside of COSMIC. The appointment becomes a web appointment through configuration done in COSMIC, see requirements below. A web appointment must adhere to the following rules in COSMIC:
Specific Rules and Limitations
Versions
Extensions
Statuses
APIs & Supported Operations
Search Parameters
Supported Queries
Supported
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| BasicHospitalBedSituationSe |
IntroductionBasicHospitalBedSituationSe is created from the Basic resource in FHIR R4 edition. Intended UseFor the given hospital, return bed overview information including the following:
This information can be used to get an overview of the bed situation in a hospital. The intended users of the information provided in this API are healthcare professionals and administrators. Specific Rules and Limitations
Versions
Extensions
Supported Operations
Search Parameters
Supported Queries
Error Codes
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| BasicUnitBedSituationSe |
IntroductionBasicUnitBedSituationSe is created from the Basic resource in FHIR R4 edition. Intended UseFor the given unit, return bed overview information. The information can be used to find current and near future prognosis of the bed situation for the requested unit, used to overview the bed situation, finding free beds for patients who needs to be admitted, in cases of overcrowding act on changes in planned inflow or outflow from one or many units, etc. Specific Rules and Limitations
Versions
Extensions
Supported Operations
Search Parameters
Supported Queries
Error Codes
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| BasicUnitOutlierSituationSe |
IntroductionBasicUnitOutlierSituationSe is created from the Basic resource in FHIR R4 edition. Intended UseFind the number of patients of a given unit(s) outlying at another unit. E.g., A patient whose responsibility is with unit X is placed in ward Y. If ward Y is not a serving unit of unit X - For unit X, this patient will an outlying patient outlying at ward Y. Specific Rules and Limitations
Versions
Extensions
Supported Operations
Search Parameters
Supported Queries
Error Codes
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| BundleDoseDispensing |
IntroductionThe Medication Dispense Dose Dispensing FHIR API is used to receive Medication Dispense related data. This profile is based on the FHIR resource MedicationDispense. Intended UseThis profile is intended to be used for posting information related to the dispensing of medications for a patient by a dose dispensing machine. Versions
Statuses
APIs & Supported Operations
Query Parameters
Supported Queries
Supported _include paramsThe _include search parameter enables a FHIR client to fetch a particular clinical resource as well as any other resources that it references. The following _include parameters are supported:
Error CodesNo specific error codes for MedicationDispenseDoseDispensing. For common codes, refer to Error handling section. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| BundleNews2 |
IntroductionThe BundleNews2 profile may be used as a container for sending a NEWS2 and the vital signs used to calculate the NEWS2 to COSMIC. The bundle should contain all vital sign profiles used for calculating a NEWS2 and an observation profile for the NEWS2. The BundleNews2 profile is created from the Bundle resource in FHIR R4 edition. Intended UseIf the NEWS2 observation is sent in a Bundle where all resources related to the NEWS2 observation are included, the Mediator construct an observation with resources from the bundle as contained resources. When the Observation has been resolved, the Mediator calls the Clinical care module (CCM) to create the NEWS2 score in COSMIC. In COSMIC CCM, the related vital sign resources are used to calculate a NEWS2 total score. If no NEWS2 total score is included in the observation the calculated score is saved on the contact. If the NEWS2 observation includes a NEWS2 total score, this score is validated with the use of the calculated score. If they do not match, an error is sent back to the sending system. When a NEWS2 observation is created, the internal id of this observation (COSMIC care entry) is included in the content-location header in the response from Mediator. Specific Rules and Limitations
Versions
APIs & Supported Operations
Supported Queries
Error CodesSpecific error messages for Bundle are listed below.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| BundlePrehospitalNote |
IntroductionBundlePrehospitalNote is created from the Bundle resource in FHIR R4 edition. Intended UseThe BundlePrehospitalNote profile may be used as a container for sending a pre-hospital note from an ambulance system to COSMIC. The bundle contains a QuestionnaireResponse entry, but may also contain other resource entries referenced from the QuestionnaireResponse. Specific Rules and Limitations
Versions
APIs & Supported Operations
Supported Queries
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| BundleTriage |
IntroductionThe BundleTriage profile may be used as a container for sending the ClinicalImpressionRetts and the included vital signs in one data transfer. BundleTriage is created from the Bundle resource in FHIR R4 edition. Intended UseIf the ClinicalImpression is sent in a Bundle where all resources related to the ClinicalImpression are included, the COSMIC Mediator construct a ClinicalImpression with resources from the bundle as contained resources. When the ClinicalImpression has been resolved, the Mediator calls the COSMIC Triage module to create the triage. When a RETTS Triage is created, the internal id of this triage (COSMIC care entry) is included in the content-location header in the response from Mediator. This id can then be used for updating an existing RETTS triages. By including the id as an identifier in the request, the old triage with that id will be invalidated and a new one created. Specific Rules and Limitations
Versions
APIs & Supported Operations
Supported Queries
Error CodesSpecific error messages for Bundle are listed below.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CarePlanCore | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CarePlanSe |
IntroductionThe CarePlanSe profile is used to retrieve data about care plans in COSMIC. Intended UseThe intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API. Must SupportThe MustSupport-flag indicates which attributes are supported by Cambio, meaning that those can be returned as part of the care plan. Specific Rules and Limitations
Versions
APIs & Supported Operations
Search Parameters
Supported Queries
Supported
|
| Code | Description | Comment |
|---|---|---|
| 400 | Invalid payloads |
The CareplanCordinatedCareSe profile is used for retrieving data about Link care plans in COSMIC. This profile is based on the FHIR resource CarePlan. It includes information like referral date, requester, receiver and also references a QuestionaireResponse resource with care note data.
COSMIC Link supports processes and routines in terms of coordination between actors which provides healthcare and social services to ensure an uninterrupted chain of care.
The intended use for this API is to get information about a patient's coordinated careplans, both active and completed. The coordination plan may contain multiple care notes. List of literal IDs will be returned under the Supporting info so that consumers can fetch each note using the GET API for QuestionnaireResponse. Additionally the API consumer has the possibility to contain these care notes by specifying it in the include parameters.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Limitation | This API is bound to provide only the coordinated care plans created through the LINK module in COSMIC |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading coordinated careplans, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Careplan.contributer.PractitionerRoleLiteSe(PractitionerRoleLiteSe.OrganizationSEVendorLite). |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.2.0 | 1.0.0 | R8.3.05 | Apr 2022 | Initial version, Support for GET and search. |
| HTTP Method | Description |
|---|---|
| GET | Support for GET Coordination plan by specific patient ID, and also to search by period and Type. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
_profile |
string | Yes | |
subject |
reference | Yes | The subject that the coordination plan is about. |
category |
string | No | supported types :SPLPTLRV, SIP, SPU |
GET [baseURL]/CarePlan/?subject=[id]&_profile=[] (Search)GET [baseURL]/CarePlan/?subject=[id]&_profile=[]&category=[](Search)GET [baseURL]/CarePlan/?subject=[id]&_profile=[]&category=[]&_include=supportingInfo (Search)GET [baseURL]/CarePlan/?subject=[id]&_profile=[]&category=[]&_include=supportingInfo&_include=contributor (Search)GET [baseURL]/CarePlan/?subject=[id]&_profile=[]&category=[]&_include=contributor (Search)GET [baseURL]/CarePlan/?subject=[id]&_profile=[]&_include=contributor (Search)The following _include parameters are supported:
supportingInfocontributorPlease note that this version of the ChargeItemSe profile is deprecated and the recommended profile to use is ChargeItemSe(version 2).
ChargeItemSe is a profile intended to be used to enable the billing process and internal cost allocation. This profile is based on the FHIR resource ChargeItem.
| Type | Description |
|---|---|
| Rule | N/A |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| N/A | 1.0.0 | N/A | June 2021 | Deprecated version, latest version is ChargeItemSe(version 2) |
ChargeItemSe is a profile intended to be used to enable the billing process and internal cost allocation. This profile is based on the FHIR resource ChargeItem. The main difference of the version 2 of the profile is that ChargeItem.context refers to the version 2 of the profile EncounterSelfService
In the context of an invoice this resource is currently used only for linking the Encounter resource with the invoice. For more details, see InvoiceSe. The ChargeItemSe is used as a contained resource within InvoiceSe
| Type | Description |
|---|---|
| Rule | N/A |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.5.0 | 2.0.0 | R8.3.05 | Sep 2022 | In this version ChargeItem.context refers to the version 2 of the profile EncounterSelfService. |
Not applicable, this profile is just used as a contained resource and there is no API for ChargeItemSe.
Not applicable, this profile is just used as a contained resource and there is no API for ChargeItemSe.
Cambio Core profile for communicating triage data of a patient. Concerns triages calculated using different protocols. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
RETTS triage is a system that is widely used in emergency care in Sweden. The RETTS triage contains a reason for visit, a set of vital parameters and a 'colour' based on a calculataion of the included vital parameters. The colour indicates a priority based on the severity of the patient's condition. The colours included in a RETTS triage in the order of priority are:
The ClinicalImpressionTriageRetts profile is based on the FHIR resource ClinicalImpression.
The ClinicalImpressionTriageRetts profile is used to create a RETTS triage in COSMIC from an external ambulance system.
| Type | Description |
|---|---|
| Limitation | Reason for visit cannot be sent and stored as a structured reason for visit term in COSMIC. Instead, it can be sent as a free text priority note. |
| Limitation | Reason for visit term stored for the triage will always be "Prehospital bedömning". |
| Rule | The vital signs referenced in ClinicalImpression.investigation should be sent as contained resources. |
| Rule | The intended users of this API are healthcare professionals. |
| Rule | If triage data is changed (e.g. triage colour, reason for visit, or any vital sign), a new triage instance shall be created with a new triage time. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for PUT. |
| HTTP Method | Description |
|---|---|
| PUT | Create a RETTS triage in COSMIC from an external system. |
PUT [baseURL]/Bundle/external-ID (create/update)
In below table, a few error messages specific for ClinicalImpression are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | TriageDateTime=YYYY-MM-DDTHH:MM:SS.SSS >= YYYY-MM-DDTHH:MM:SS.SSS | The entered TriageDateTime cannot be in the future. It has to be the current time or in the past. |
| 400 | The Snomed Code for […] could not be translated | There is no mapping between the entered SNOMED code and the corresponding OpenEHR code on the FHIR server. |
The CompositionReferralClinicalInformation profile defines clinical information structured on sections with titles and values which can be sent together with a referral request, answer or assessment. E.g. the documentation done when sending a referral can include data like medical history, health issue, etc. This profile is based on the FHIR resource Composition.
Intended use of this profile is to communicate data about a documented clinical information that is connected to a referral request, assessment or answer. The user of the API should be restricted only to the patient to which the data belongs. CompositionReferralClinicalInformation can only be used as a bundled resource within the TaskReferral and ServiceRequestReferral APIs, refer to TaskReferral and ServiceRequestReferral sections to read more about complete Intended use for the API.
Additionally, CompositionReferralClinicalInformation includes the extension common-signDateTime to indicate the date & time the data was signed.
| Type | Description |
|---|---|
| Rule | External user should not be someone else than the patient of which record the referral data belongs. E.g. A healthcare professional is not the intended user of the API. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.5.0 | 1.0.0 | R8.3.05 | Apr 2021 | Initial version |
The ConditionDiagnosisSe profile handles information about diagnoses that are documented in a QuestionnaireResponseSe profile. In this profile, the diagnose code system that is handled is ICD10.
ConditionDiagnosisSe is currently only used as a contained resource within QuestionnaireResponse.
Intended user for this resource is only a healthcare professional. This professional should be the same as specified in QuestionnaireResponseSe. If Unit is specified, it should be with HSA id and has to be the same unit as was given in QuestionnaireResponseSe.
| Type | Description |
|---|---|
| Rule | The author of ConditionDiagnosisSe should not be a patient. |
| Rule | The API should not be used to send unsigned data to COSMIC. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.12.0 | 1.1.0 | 3.9.0 | Nov 2023 | Slice for ksh-97 codes removed |
| N/A | 1.0.0 | N/A | Aug 2021 | Initial version |
Not applicable, this profile is just used as a contained resource and there is no direct APIs related to this profile.
The ConditionHealthIssueSe profile serves as a data container for transmitting information about a health issue, detailing a patient's process through healthcare for one or multiple related conditions. This profile is derived from the Condition resource in FHIR R4 edition and tailored specifically for the Swedish healthcare market as the supported SNOMED CT code system is defined for the Swedish market.
This API is designed to retrieve basic information of a patient's active pregnancy, primarily for purposes like linking QuestionnaireResponses. It is advised against presenting this data directly to end-users, hence the specific condition names are not currently exposed and only the code name is returned. Furthermore, storing any fetched information in an external system is discouraged due to the temporary nature of identifier values, which may change (for instance, if a condition is merged with another condition). The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Limitation | It is only possible to fetch health issues in status 'Active'. |
| Limitation | It is only possible to request health issues with the code '118185001' (Pregnancy) of the SNOMED CT code system. |
| Rule | The data retrieved from this API must not be stored in the external system due to the temporary nature of identifier values. |
| Rule | The data retrieved from this API should be used exclusively for backend processing, such as linking QuestionnaireResponses by ID. The data must not be presented to end users. If the data is to be presented, the consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| FHIR status | Status in COSMIC |
|---|---|
| Active | Open |
Note that the other statuses are not mapped as they are not supported in the API.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.4.0 | 1.0.0 | 4.0.0 | July 2024 | Initial version, support for GET. |
| 4.9.0 | 1.1.0 | 4.0.0 | Feb 2025 | Added the 'participant' extension to the profile, along with the support for _include parameter Condition:extension:participant:extension:actor. |
| HTTP Method | Description | Scope |
|---|---|---|
| GET | Fetch conditions of type 'Pregnancy' in status 'Active' by patient. | user/Condition.read OR system/Condition.read OR patient/Condition.read |
| Query parameter | Format | Mandatory/Optional | Description |
|---|---|---|---|
subject.identifier Or, subject |
Reference | Mandatory | The identifier or the id of the patient with whom the condition is associated. |
code |
Token | Mandatory | The code and the system of the condition name. Currently, only the Code '118185001' (Pregnancy) from the CodeSystem http://snomed.info/sct/45991000052106 is supported. |
category |
Token | Mandatory | Only the Code 'problem-list-item' from the CodeSystem http://terminology.hl7.org/CodeSystem/condition-category is supported, as the endpoint supports fetching only the ConditionHealthIssueSe profiles or the Health Issues. |
_include |
String | Optional | The supported _include param Condition:subject |
_include |
String | Optional | The supported _include param Condition:extension:participant:extension:actor |
GET [baseURL]/Condition?subject.identifier=urn:oid:1.2.752.129.2.1.3.1|197305281904&code=http://snomed.info/sct/45991000052106|118185001&category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item
GET [baseURL]/Condition?subject.identifier=urn:oid:1.2.752.129.2.1.3.1|197305281904&code=http://snomed.info/sct/45991000052106|118185001&category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item&_include=Condition:subject
GET [baseURL]/Condition?subject=Patient/1071&code=http://snomed.info/sct/45991000052106|118185001&category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item
GET [baseURL]/Condition?subject=1071&code=http://snomed.info/sct/45991000052106|118185001&category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item
GET [baseURL]/Condition?subject.identifier=urn:oid:1.2.752.129.2.1.3.1|197305281904&code=http://snomed.info/sct/45991000052106|118185001&category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item&_include=Condition:subject&_include=Condition:extension:participant:extension:actor
Condition:subjectCondition:extension:participant:extension:actor| Scenario | Error code | Description |
|---|---|---|
| When a value is not supplied for the 'Subject.identifier' parameter. | 400 Bad Request | Invalid request: The FHIR endpoint on this server does not know how to handle GET operation[Condition] with parameters [[code, category]] |
| When a value is not supplied for the 'Code' parameter. | 400 Bad Request | Invalid request: The FHIR endpoint on this server does not know how to handle GET operation[Condition] with parameters [[subject, category]] |
| When a value is not supplied for the 'Category' parameter. | 400 Bad Request | Invalid request: The FHIR endpoint on this server does not know how to handle GET operation[Condition] with parameters [[code, subject]] |
| When the supplied 'Code.Code' value is not '118185001' and the 'Code.System' is not http://snomed.info/sct/45991000052106. | 400 Bad Request | Invalid search parameters: The acceptable value for 'Code.code' is '118185001', and the correct 'Code.system' is 'http://snomed.info/sct/45991000052106'. |
| When the supplied 'Category.Code' value is not 'problem-list-item' and the 'Category.System' is not http://terminology.hl7.org/CodeSystem/condition-category | 400 Bad Request | Invalid search parameters: The acceptable value for 'Category.code' is 'problem-list-item', and the correct 'Category.system' is 'http://terminology.hl7.org/CodeSystem/condition-category'. |
| If a patient doesn't exist in Cosmic for the supplied patient identification number. | 404 Not Found | Patient Not found for the given identifier. |
| If a scope other than the allowed minimum scopes: user/Condition.read OR system/Condition.read OR patient/Condition.read is supplied. | 403 Forbidden | Access is denied. |
The ConsentPatientSealProfile represents the consent of the patient for fully sealing their account in an external application and is a profile created from the resource Consent.
The ConsentPatient profile will contain the consent information of the patient to create a fully seal from the patient in direct access framework implemented for Cambio. When a full seal is implemented no information of that patient will be sent to the external application.
| Type | Description |
|---|---|
| Rule | The consent should come from a direct patient interaction with the app, should not be a system generated request. |
| Rule | The patient app should first search for available seals and then based on the response should update existing inactive seal rule or create new seal rule. |
| Limitation | The consent's status can only be 'active' or 'inactive'. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.5.0 | 1.0.0 | R8.3.05 | Feb 2023 | Initial version, support for POST and GET. |
| HTTP Method | Description |
|---|---|
| POST | Support for searching if there are any inactive patient seals and registering a new full seal for the given patient ID . |
| GET | Search for consents for a given patient. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
patient |
string | ID or identifier for patient |
POST [baseURL]/ConsentGET [baseURL]/Consent?patient=<patient id>GET [baseURL]/Consent?patient.identifier=<systemURI|identifier value>Core diagnostic report profile, this profile can be used to expose information of any report related resource
The DiagnosticReportMicrobiology profile is used for retrieving data about a complete microbiology report for a patient end to end starting from request. This profile is based on the FHIR resource DiagnosticReport.This profile is derived from a core profile created for DiagnosticReport named DiagnosticReportCore. The data available from COSMIC to this profile is only starting from R8.3.03 COSMIC release, information created before this release cannot be taken from this API.
This profile is created as the main profile for the exposing information related to Microbiology report.This profile is based on the core DiagnosticReport profile that is defined for exposing all types of report based resources.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Rule | External user should only be the patient that has the Microbiology report. E.g. A healthcare professional is not the intended user of the API. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading diagnostic reports, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from DiagnosticReport.performer.OrganizationSEVendorLite. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | initial version, support for GET |
| FHIR status | Status in COSMIC |
|---|---|
| PRELIMINARY | PRELIMINARY |
| ADDITIONAL | APPENDED |
| FINAL | FINAL |
| Other | UNKNOWN |
| HTTP Method | Description |
|---|---|
| GET | Support for retrieving DiagnosticReport by report ID. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
_profile |
string | No | |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well. Ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
date |
date (range) | Yes (to date is optional) | Date format YYYY-MM-DDThh:mm:ss+zz:zz |
GET [baseURL]/DiagnosticReport/[id] (Read)GET [baseURL]/DiagnosticReport/_search?patient=[]&date=[] (Search)GET [baseURL]/DiagnosticReport/_search?patient=[]&date=[]&_include=[] (Search)The following _include parameters are supported:
patientperformerbased-ondateThe DiagnosticReportRadiology profile is used for retrieving data about a complete radiology report for a patient end to end starting from request. This profile is based on the FHIR resource DiagnosticReport.
This profile is created as the main profile for the exposing information related to radiology report. This profile is based on the core DiagnosticReport profile that is defined for exposing all types of report based resources.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Rule | External user should only be the patient that has the radiology report. E.g. A healthcare professional is not the intended user of the API. |
| Rule | From date and patient are mandatory for search requests. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading diagnostic reports, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from DiagnosticReport.performer.OrganizationSEVendorLite. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.04 | Jan 2022 | Initial version, support for GET. |
| FHIR status | Status in COSMIC |
|---|---|
| PRELIMINARY | PRELIMINARY |
| ADDITIONAL | APPENDED |
| FINAL | FINAL |
| Other | UNKNOWN |
| HTTP Method | Description |
|---|---|
| GET | Support for retrieving DiagnosticReport by report ID. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
_profile |
string | No | |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
date |
date | Yes (to date is optional) |
GET [baseURL]/DiagnosticReport/[id] (Read)GET [baseURL]/DiagnosticReport/_search?patient=[]&date=[] (Search)GET [baseURL]/DiagnosticReport/_search?patient=[]&date=[]&_include=[] (Search)The following _include parameters are supported:
patientperformerbased-ondateThe EncounterCore is defined as an interaction between a patient and healtcare provider(s) for the purpose of providing healtcare service(s) or assessing the health status of a patient.
The Encounter Emergency is defined as an interaction between a patient and healthcare provider(s) that is not planned. (Not implemented yet)
The EncounterLite profile is created from the FHIR resource Encounter.
EncounterLite profile is created to fetch inpatient encounters at a given location.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API. Note that the security rules (i.e. PDL block) are not applied in particularly in this API and Consumer must handle the data carefully and with the awareness.
| Type | Description |
|---|---|
| Limitation | Encounter status: It is only possible to request encounters that are in status "In-progress" and "Onleave". |
| Limitation | Encounter class: It is only possible to request encounters that belong to inpatient class (IMP). |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading encounters, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Encounter.serviceProvider.OrganizationSEVendorLite. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.3.0 | 1.0.0 | COSMIC 3.12.0 | July 2024 | Initial version, support for GET and search. |
The table below shows what the statuses used in this FHIR profile are mapped to in Cosmic.
| FHIR status | Status in COSMIC |
|---|---|
| planned | New, Planned (Applicable for all contact types in COSMIC). |
| arrived | Arrived (Applicable only for outpatient contact types in COSMIC). |
| in-progress | Ongoing (Applicable for all outpatient contact types. Applicable for inpatient contacts which do not have absence in status "Ongoing"). |
| onleave | Ongoing (Applicable for inpatient contacts with absence that are in status "Ongoing"). |
| finished | Dishcarged (Applicable for all contact types in COSMIC). |
| cancelled | Missed (Applicable for all contact types in COSMIC). |
| entered-in-error | Canceled (Applicable for all contact types in COSMIC). |
| HTTP Method | Description |
|---|---|
| GET | Fetch inpatient encounters that are in statuses "in-progress" and "onleave" from COSMIC. |
| Parameter | Format | Mandatory/Optional | Description |
|---|---|---|---|
location |
Identifier | Mandatory | The identifier of the location which encounters should be fetched. |
statuses |
Code | Mandatory | The encounter statuses to be considered when fetching. Supported statuses: "In-progress" and "Onleave". |
classes |
Code | Mandatory | The encounter classes to be considered when fetching. Supported classes: IMP |
_profile |
String | Mandatory | Supported profile: https://fhir.cambio.se/StructureDefinition/EncounterLite/ |
_include |
String | Optional | Supported _include operations: Encounter:subject, Encounter:location, Encounter:serviceProvider |
Search [baseURL]/EncounterEncounter:subjectEncounter:locationEncounter:serviceProviderN/A
For common codes, refer to Error handling section.
| Code | Description |
|---|---|
| 400 | Invalid search parameter:Status is mandatory: Supported status are ( In Progress, On Leave ) |
| 400 | Invalid search parameter:Class is mandatory: Supported classes are (IMP) |
| 400 | Invalid search parameter:location is mandatory |
| 403 | Restricted access for the user to view the encounter information |
EncounterLite profile is a lightweight Cambio profile with the intended use of retrieving encounters.
It currently supports two operations, one for fetching ongoing inpatient encounters at a specific care unit (also supported previously in v1) and another one for fetching all types of encounters for a specific patient.
The MustSupport-flag indicates which attributes are supported by Cambio, meaning that those can be returned as part of the encounter.
| Type | Description |
|---|---|
| Limitation | Supported operation #1: It is only possible to request inpatient encounters with the status being "in-progress" or "onleave". |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.3.0 | 1.0.0 | 3.12.0 | Jul 2024 | Initial version, support for search inpatient encounters by location. |
| 4.20.0 | 2.0.0 | 5.0.0 | Apr 2026 | New less restrictive design and addition of mandatory attributes as well as the possibility to fetch encounters for a specific patient. |
| # | HTTP Method | Description |
|---|---|---|
| 1 | GET | Fetch ongoing inpatient encounters for a specific care unit (performing unit). |
| 2 | GET | Fetch encounters for a specific patient. |
| Parameter | Format | Mandatory | Description |
|---|---|---|---|
location |
Reference | Mandatory | Reference to the performing unit. |
statuses |
Code | Mandatory | Status of the encounter. Supported statuses: "in-progress" and "onleave". |
classes |
Code | Mandatory | The encounter class. Supported classes: inpatient (IMP) |
_profile |
String | Mandatory | Supported profile: https://fhir.cambio.se/StructureDefinition/EncounterLite/ |
_include |
String | Optional | Supported _include operations: Encounter:subject, Encounter:encounterPerformingUnit, Encounter:serviceProvider |
| Parameter | Format | Mandatory | Description |
|---|---|---|---|
subject |
Reference | Mandatory | Reference to the the patient. |
status |
Code | Optional | The encounter status. |
performingUnit |
Reference | Optional | Reference to the performing unit. |
_profile |
String | Mandatory | Supported profile: https://fhir.cambio.se/StructureDefinition/EncounterLite/v2 |
Encounter:subjectEncounter:encounterPerformingUnitEncounter:serviceProviderFor common codes, refer to Error handling section.
| Code | Description |
|---|---|
| 400 | Invalid search parameter:Status is mandatory: Supported status are ( In Progress, On Leave ) |
| 400 | Invalid search parameter:Class is mandatory: Supported classes are (IMP) |
| 400 | Invalid search parameter:location is mandatory |
| 403 | Restricted access for the user to view the encounter information |
The Encounter Outpatient is defined as an interaction between a patient and healthcare provider(s) that does not require an overnight stay in a hospital or medical facility. (Not implemented yet)
This is an Encounter profile to be used for outpatient encounters, in a Swedish context.
The EncounterOutpatientReadeSe profile is a Cambio profile with the intended use of reading outpatient encounters. This profile is derived from the EncounterOutpatientCoreSe profile.
The MustSupport-flag indicates which attributes are supported by Cambio, meaning that those can be returned as part of the encounter.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.11.0 | 1.0.0 | 3.12.0 | May 2025 | Initial version, support for GET. |
| Type | Description |
|---|---|
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end users. |
| Extension | Data type | Description |
|---|---|---|
| EncounterPerformingUnit | Reference | Organisational unit at which the encounter is performed. |
| HTTP Method | Description |
|---|---|
| GET | Search for outpatient encounters using search parameters. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
subject |
Identifier | Mandatory | The identifier of the patient. |
_id |
Identifier | Optional | The identifier of the encounter. |
_include |
String | Optional | See supported _include parameters listed below. |
_profile |
String | Mandatory | Supported profile: https://fhir.cambio.se/StructureDefinition/EncounterOutpatientReadSe/. |
GET[baseURL]/Encounter?subject.identifier=[patientIdentifier]&_profile=[profileURL]GET[baseURL]/Encounter?subject.identifier=[patientIdentifier]&_profile=[profileURL]&_include=Encounter:serviceProviderEncounter:encounterPerformingUnitEncounter:participantEncounter:serviceProviderEncounter:subjectThe EncounterOutpatientWriteSe profile is a Cambio profile with the intended use of creating outpatient encounters. This profile is derived from the EncounterOutpatientCoreSe profile.
Create an encounter in the context of an integration between an EHR and a dental care system
The MustSupport-flag indicates which attributes are supported by Cambio, meaning that they will be stored as part of the encounter in the Cambio system. If other attributes are included, as allowed by the profile, it will not throw an error but those will be discarded.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.11.0 | 1.0.0 | 3.12.0 | May 2025 | Initial version, support for POST. |
The table below shows what the statuses used in this FHIR profile are mapped to in Cosmic.
| FHIR encounter status | Cosmic encounter status |
|---|---|
| planned | new, planned |
| arrived | arrived |
| in-progress | ongoing |
| finished | discharged |
| cancelled | missed |
| entered-in-error | canceled |
| HTTP Method | Description |
|---|---|
| POST | Create an outpatient encounter for a patient. |
POST[baseURL]/EncounterThe EncounterPrehospital profile is created from the FHIR resource Encounter
EncounterPrehospital is used to create an ambulance contact in COSMIC from an external ambulance system when a patient is coming in to the hospital by ambulance.
If a certain type of resource is updated, but with the same (or older) lastUpdatedTime, the update will fail. The code which is returned is 200 OK. If the header prefer:return=OperationOutcome is added, a message will be received describing the error.
| Type | Description |
|---|---|
| Rule | If the patient is changed in the ambulance system, the contact should be invalidated in COSMIC and a new contact is created on the new patient. |
| Rule | The intended users of this API are healthcare professionals. |
| FHIR status | Status in COSMIC |
|---|---|
| In progress | Open |
| Finished | Performed |
| Cancelled | Cancelled |
| Entered in error | Invalidated |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | June 2020 | initial version, support for PUT |
| HTTP Method | Description |
|---|---|
| PUT | Create an ambulance contact in COSMIC |
N/A
PUT [baseURL]subscription/Bundle/external-IDN/A
N/A
No specific error codes for EncounterPrehospital. For common codes, refer to Error handling section.
Please note that this version of the EncounterSelfSevice profile is deprecated and the recommended profile to use is EncounterSelfService(version 2).
The EncounterSelfService profile is used for retriving the contact information needed for self-service workflow (arrival and payment registration). The profile is based on the Encounter in FHIR STU4 edition.
| Type | Description |
|---|---|
| Rule | N/A |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| N/A | 1.0.0 | N/A | June 2021 | Deprecated version, latest version is ChargeItemSe(version 2) |
The EncounterSelfService profile is used for retrieving the contact information needed for self-service workflow (arrival and payment registration). The profile is based on the Encounter resource in the FHIR R4 specification.
In the profile version 2, the extension RegisterPaymentPossible has been removed.
EncounterSelfService is currently only used as a contained resource within the InvoiceSe resource. It contains three extension to include additional details about the visit.
| Type | Description |
|---|---|
| Rule | N/A |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.5.0 | 2.0.0 | R8.3.05 | Sep 2022 | In this version the extension RegisterPaymentPossible has been removed. |
| Extension | Data type | Description |
|---|---|---|
| InformationToPatient | string | Optional extension element to send additional instruction to the patient about the visit. |
| ArrivalRegistrationPossible | boolean | Optional extension element to indicate the possibility of registering the arrival in COSMIC. |
| FHIR status | Status in COSMIC |
|---|---|
| planned | new, planned |
| arrived | arrived |
| in-progress | ongoing |
| finished | performed |
| on-leave | missed |
| cancelled | cancelled |
Not applicable, this profile is just used as a contained resource and there is no API for EncounterSelfService. For examples, refer to InvoiceSe.
Not applicable, this profile is just used as a contained resource and there is no API for EncounterSelfService.
HealthcareServiceLiteSe is a profile based on the FHIR resource HealthcareService.
HealthcareServiceLiteSe is used as part of the booking flow, where this profile searches for a list of healthcare services that may be used to book an appointment.
| Type | Description |
|---|---|
| Rule | The patient header 'Patient' must be included. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading healthcare services, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is in the OrganizationSEVendorLite profile referenced in HealthcareServiceLiteSe.providedBy. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for search. |
| Extension | Data type | Description |
|---|---|---|
| PermittedPatientActions | Coding | Describes what actions the patient have permission for. Never mapped on HealthcareServiceLiteSe. Only available on Appointment. |
| HTTP Method | Description |
|---|---|
| GET | Search for a list of healthcare services based on a search parameter. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
location |
Identifier | Yes | |
_profile |
URL | Yes |
GET [baseURL]/HealthcareService/_search?location=<reference>GET [baseURL]/HealthcareService/_search?location.identifier=<identifier reference>In the table below, a few error messages specific for HealthcareServices are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Request header 'patient' is required. | Mandatory for MVK flow. |
| 400 | Could not resolve location identifier. |
The ImmunizationSe profile is used to retrieve data about performed patient vaccinations in COSMIC. The profile is based on the FHIR resource Immunization.
The intended users of this API are patient apps and healthcare professionals.
| Type | Description |
|---|---|
| Limitation | The API only returns performed vaccinations. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading appointments, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from DiagnosticReport.performer.OrganizationSEVendorLite. |
| Limitation | In Read APIs, the body site is read from the prescription and not from the administered occasion. There can be different body sites in Prescription and Occasion if a different body site is chosen than the one mentioned in the Doctor's prescription when the vaccine is administered. |
| Limitation | The route is presented in the CodeableConcept.text instead of using a code since routes are not transformed in to a proper code system |
| Extension | Data type | Description |
|---|---|---|
| SiteQualifier | CodableConcept | More precise administration site. To be used only when combined with site.coding. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.11.0 | 1.0.0 | 3.9.0 | Nov 2023 | Initial version, Support for GET and search |
| 4.10.0 | 1.1.0 | 4.0.0 | April 2025 | Introduced site and encounter attributes. |
| 4.12.0 | 1.2.0 | xxx | June 2025 | Introduced extension SiteQualifier. |
| HTTP Method | Description |
|---|---|
| GET | Retrieve all performed vaccinations for patient using patient ID. |
| Parameter | Format | Comment |
|---|---|---|
patient |
string | ID or identifier for patient |
_profile |
string | Optional query parameter. Canonical url for the profile (https://fhir.cambio.se/StructureDefinition/ImmunizationSe) |
_include |
string | Can be Immunization:patient, Immunization:location, Immunization:performer.actor or all three |
GET [baseURL]/Immunization?patient={id}`GET [baseURL]/Immunization?patient.identifier={identifierSystemURI |
identifierValue}` |
GET [baseURL]/Immunization?patient.identifier={identifierSystemURI |
identifierValue}`&_include=Immunization:location |
GET [baseURL]/Immunization?patient.identifier={identifierSystemURI |
identifierValue}&_include=Immunization:performer.actor |
| Code | Description | Comment |
|---|---|---|
| 400 | Invalid payloads |
Please note that this version of the Invoice profile is deprecated and the recommended profile to use is InvoiceSe(version 2).
The Invoice resource contains the payment details related to a single patient visit. The profile is based on the Invoice in FHIR STU4 edition.
| Type | Description |
|---|---|
| Rule | N/A |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| N/A | 1.0.0 | N/A | Nov 2021 | Deprecated version, latest version is Invoice(version 2). |
The Invoice resource contains the payment details related to a single patient visit. The profile is based on the Invoice in FHIR STU4 edition.
The Invoice resource returns relevant cost for the patient visit. It contains three extensions to include additional details about the payments.
| Type | Description |
|---|---|
| Rule | N/A |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.3.0 | 2.0.0 | R8.3.04 | Oct 2022 | This version uses the latest version of the Payment options extension. |
| Extension | Data type | ValueSet | Description |
|---|---|---|---|
| Common-businessStatus | Fixedvalues | InvoiceBusinessStatus | Optional extension element to indicate the status of the payment status of the contact. |
| Invoice-paymentMethodOption (V2) | Complex | PaymentMethodOptions | Extension which keeps information about payment type and possibility of using it. When compared with the v1, the main difference is, the v2 is a complex extension and it has two sub extensions where one can keep the payment type and the other extension keeps a boolean value to show that payment type is possible or not |
| Invoice-registeredPaymentMethod | Fixedvalues | Registered_Payment_Method | Extension to indicate the payment method used for making the payment for the visit. |
| FHIR status | Status in COSMIC |
|---|---|
| base | patient |
| surcharge | invoice |
| discount | reduction |
| surcharge | other(amount >0) |
| discount | other(amount <0) |
| HTTP Method | Description |
|---|---|
| GET | Search for invoice using patient id and encounter id. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
subject |
string | true | The subject that the inovice is about (patient) |
encounter |
string | true | Contact id of the visit |
_profile |
string | false | Profile to be used when returning data |
GET [baseURL]/invoice_search?subject={}&encounter={}&_profile=https://fhir.cambio.se/StructureDefinition/InvoiceSe/v2 (search)Specific error messages for InvoiceSe are listed below.
| Code | Description | Comment |
|---|---|---|
| 400 | Occurs due to invalid query parameters | E.g. patientId and contactId are not related to the same patient, contact does not exist, contact is not in registered or in booked state, the profile canonical URL is unsupported |
A profile for Locations where each location is some type of "unit", it could be an OP unit, IP ward, hospital or similar.
Use other Location profiles for other location types such as Beds.
This is a Core profile, hence is open in its profiling. Consider using more specific profiles derived from this one.
LocationUnitSe is a profile based on the FHIR resource Location.
LocationUnitSe is used to communicate care units, where healthcare services for that unit can be found in order for a patient to be able to book appointments.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Limitation | Only outpatient facilities (OF) are allowed. |
| Rule | The element Location.address is read-only. |
| Rule | The element Location.telecom is read-only. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading locations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved from Location.identifier.hsaid. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| Extension | Data type | Description |
|---|---|---|
| hsaHierarchy | Complex | HSA hierarchy. |
| HTTP Method | Description |
|---|---|
| GET | Used to retrieve a location. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
type |
code | Yes | Only OF (Outpatient facility) is allowed. |
GET [baseUrl]/Location/[id] (GET)
The Medication Dispense Dose Dispensing FHIR API is used to receive Medication Dispense related data. This profile is based on the FHIR resource MedicationDispense.
This profile is intended to be used for posting information related to the dispensing of medications for a patient by a dose dispensing machine.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| COS 4.3.0 | 1.0.0 | COSMIC 3.12.0 | July 2024 | Initial version |
| FHIR status | Status Description |
|---|---|
| Active | FHIR status Active will be sent when it is a valid medication dispense. |
| Cancel | FHIR status Cancel will be sent when it is a invalid medication dispense. |
| HTTP Method | Description |
|---|---|
| POST | Create/Update MedicationDispenseDoseDispensing information for a patient. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
code |
token | Yes | Returns dispenses of this medicine code |
medication |
reference | Yes | Returns dispenses of this medicine resource |
prescription |
reference | Yes | The identity of a prescription to list dispenses from |
POST [baseURL]/MedicationDispenseThe Medication Request FHIR API is designed to enable the fetching of requested medications for a patient. This profile is based on the FHIR resource MedicationRequest.
This profile is intended to be used for communicating information related to prescribed medication data for a patient that is to be dispensed from a dose dispensing machine. This profile will communicate details of one prescription at a time.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| COS 4.3.0 | 1.0.0 | COSMIC 3.12.0 | July 2024 | Initial version. |
FHIR status Active will be sent always.
| HTTP Method | Description |
|---|---|
| GET | Retrieving MedicationRequestDoseDispensing data by patient ID. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
identifier |
identifier | Yes | Identifiers associated with this medication request that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. They are business identifiers assigned to this resource by the performer or other systems and remain constant as the resource is updated and propagates from server to server. |
authoredOn |
dateTime | Yes | The date and time when the prescription was initially written or authored on. |
subject |
Reference | Yes | A link to a resource representing the person or set of individuals to whom the medication will be given. |
_profile |
Reference | Yes | To use the MedicationRequestDoseDispensing profile one must include the profile parameter in the request as it is not the default implementation. |
GET [baseURL]/MedicationRequest?subject.identifier:urn:oid:[OID]|[id]&category=[]&_profile=[https://fhir.cambio.se/StructureDefinition/MedicationRequestDoseDispensing]GET [baseURL]/MedicationRequest?subject.identifier:urn:oid:[OID]|[id]&category=[]&_profile=[https://fhir.cambio.se/StructureDefinition/MedicationRequestDoseDispensing]&date=gt&date=ltGET [baseURL]/MedicationRequest?subject.identifier:urn:oid:[OID]|[id]&category=[]&_profile=[https://fhir.cambio.se/StructureDefinition/MedicationRequestDoseDispensing]&date=gt&date=lt&_include=MedicationRequest:subjectGET [baseURL]/MedicationRequest?subject.identifier:urn:oid:[OID]|[id]&category=[]&_profile=[https://fhir.cambio.se/StructureDefinition/MedicationRequestDoseDispensing]&date=gt&date=lt&_include=MedicationRequest:subject&_include=MedicationRequest:requesterThe following _include parameters are supported:
subjectpractitionerFHIR Blood Pressure Profile
FHIR Body Height Profile
FHIR Body Temperature Profile
FHIR Body Weight Profile
FHIR Head Circumference Profile
FHIR Heart Rate Profile
FHIR Oxygen Saturation Profile
FHIR Respiratory Rate Profile
Cambio Core profile for communicating the level of consciousness, ACVPU(Alert, Confusion, Voice, Pain, Unresponsive). For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationAcvpuLite profile represents the vital sign ACVPU and is a profile created from the resource Observation. The ACVPU is a scale for the awareness of a patient. The profile is derived from the standard FHIR profile Vital Signs which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The ObservationAcvpuLite profile is used for communicating the awareness of a patient. The level of awareness is communicated as a statement which is defined by a code in the profile.
The API can be used to create and read ACVPU information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported for POST. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| COS Feb 2021 | 1.0.0 | R8.2.08 | Feb 2021 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to search for ACVPU entries |
| POST | Used to create an ACVPU entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
_profile |
string | No | search on the profile url. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)Observation:performer
In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
Statuses preliminary, entered-in-error or cancelled are not supported |
Cambio Core profile for communicating the status of the patients air passage. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationAirpassageLite profile represents the vital sign air passage and is a profile created from the resource Observation. The vital sign air passage holds a status of the patients air passage. The profile is derived from the standard FHIR profile Vital Signs which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The ObservationAirPassageLite profile is used for communicating the status of the air passage of a patient. The status of the air passage is communicated as a statement which is defined by a code in the profile.
The API can be used to create and read air passage information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported for POST. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| COS Feb 2021 | 1.0.0 | R8.2.08 Feb 2021 | Initial version, support for GET and POST. . |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for air passage entries |
| POST | Used to create an air passage entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
_profile |
string | No | search on the profile url. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)_include=Observation:performer
In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
Statuses preliminary, entered-in-error or cancelled are not supported. |
Cambio Core profile for communicating the Arm Span. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationArmSpanLite profile represents the parameter Arm span and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Arm span is an observation where a measurement taken of the length from one end of an individual's arm (measured at the fingertips) to the other arm, when raised parallel to the ground with shoulder height at a 90° angle.
The profile ObservationArmSpanLite is used for communicating an entry of a patient's measurement of the length from one end of an individual's arm (measured at the fingertips) to the other arm, when raised parallel to the ground with shoulder height at a 90° angle, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| User action in COSMIC | FHIR status | Status in COSMIC |
|---|---|---|
| Saved by signer | preliminary | ReadyToSign |
| Signed by signer | final | SignedComplete |
| Signed with counter signer and/or attester | final | Sign |
| Saved by secretary | preliminary | NotReadyToSign |
| Ready to sign by secretary | preliminary | ReadyToSign |
| Entered by patient | final | CompleteNonSignable |
| Parameter from a device | final | CompleteNonSignable |
| Correcting a previously signed parameter | amended | Resign |
| Remove a not signed parameter | entered-in-error | Deleted/Removed |
| Invalidate a signed parameter | entered-in-error | InvalidateComplete |
| Invalidate a parameter from a device or patient | entered-in-error | InvalidateComplete |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Arm span |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type | |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
The ObservationBPComplex profile represents the vital sign blood pressure and additional information related to the observation such as how the patient's body was positioned at the time for instance.
Therefore in comparison to ObservationBPLite, this profile captures more information besides the systolic and diastolic blood pressure values.
The profile is derived from the standard FHIR profile ObservationVitalSigns and ObservationBP which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The must support flag indicates which attributes that will be stored as part of the observation in a Cambio system.
In COSMIC this observation is mapped to the internal archetype for complex blood pressure.
| Type | Description |
|---|---|
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | If either the systolic or diastolic blood pressure is not included, a value must be sent in component.dataAbsentReason. |
| Rule | The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | When creating a complex blood pressure observation, the status must be 'final'. |
| Rule | dateTime cannot be only date component, also time component will be needed. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.20.0 | 1.0.0 | 5.0.0 | May 2026 | Initial version of the profile. |
| HTTP Method | Description |
|---|---|
| POST | Used to create a blood pressure entry. If successful, the operation will return id in response. |
POST [baseURL]/ObservationFor integration with Cosmic the following concept maps are used for this profile:
The ObservationBPLite profile represents the vital sign Blood pressure and is a profile created from the resource Observation. The vital sign blood pressure can hold both the value of the diastolic and systolic blood pressure of the patient. The profile is derived from the standard FHIR profile Vital Signs which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The ObservationBPLite profile is used for communicating the value of the patient blood pressure in mm[Hg]. If either the systolic or diastolic blood pressure is not included, a value must be sent in Observation.component.dataAbsentReason. In COSMIC it is mapped to the internal archetype for blood pressure.
The API can be used to create and read patient blood pressure information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported for POST. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| COS Feb 2021 | 1.0.0 | R8.2.08 | Feb 2021 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for blood pressure entries |
| POST | Used to create an blood pressure entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
_profile |
string | No | search by the profile url. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)Observation:performer
In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
Cambio Core profile for communicating the Body Height. Also support the different types of body heights like, Target height, Mother height, father height, Sitting height, Birth length. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationBodyHeightLite profile represents the vital parameter body height and is a profile created from the resource Observation. Body height is an observation concerning body height of a person. The profile is derived from the standard FHIR profile Body height which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The profile ObservationBodyHeightLite is used for communicating an entry of a patients body height by sending a value in the element observation.value. The profile defines three different types of body height registrations: Body height, birth length and sitting height. The API can be used to create and read patient body height information from/to COSMIC.
The patient generated data is ordered by a care giver and there should be a responsible unit sent together with the data.
Should be done by a health care professional with a specified HSA ID. This professional should have their assignment (medarbetaruppdrag) and be connected to the specified unit. Unit should also be specified with HSA ID. Intended use is in first hand that the API is used within the same care giver. The user and specified unit should exist in COSMIC and be the same in the external system.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer:observation. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | POST: It is not supported to create body height entries with the Snomed CT concepts 169886007(Birth length) and 248335006(Sitting height). Only the concept 1153637007(Body height) is supported for POST. |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error, amended or cancelled. Only status final is supported for POST. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units | |
| 2.4.0 | 1.0.0 | R8.3.04 | Feb 2022 | Initial version, support for GET and POST. |
| HTTP Methods | Description |
|---|---|
| GET | Used to get or search for Body height registrations |
| POST | Used to create a Body height entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
dateTime (dd-mm-yyhh:mm:ss) | Yes Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. | |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
code |
token | No | SNOMED CT code of the observation type |
_profile |
string | No | search on the profile url. Either code or profile is needed as search parameter. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?code= (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?code=[code]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)Observation:performerObservation:performer.organizationObservation:performer.practitionerObservation:subjectIn the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
Statuses preliminary, entered-in-error or cancelled are not supported for POST. |
| 400 | "Only supported Snomed code is 1153637007 for Body height." | 169886007(Birth lentgh) and 248335006(Sitting height) are not supported for POST |
Cambio Core profile for communicating the vital sign, Body temperature. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationBodyTemperatureLite profile represents the vital sign body temperature and is a profile created from the resource Observation. The vital sign body temperature holds a value of the temperature of the patient body. The profile is derived from the standard FHIR profile Vital Signs which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The ObservationBodyTemperatureLite is used for communicating the value of the patients body temperature in celsius by sending a value in the element observation.value. The API can be used to create and read patient body temperature information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported for POST. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| COS Feb 2021 | 1.0.0 | R8.2.08 | Feb 2021 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for body temperature entries |
| POST | Used to create an body temperature entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a business identifier as well. ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
_profile |
string | No | search on the profile url. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
Statuses preliminary, entered-in-error or cancelled are not supported for POST. |
Cambio Core profile for communicating the Body weight. For Use case specific profiles, this profile can be derived for the use case profile to be compliant with the Cambio core profile.
The ObservationBodyWeightLite profile represents the vital parameter body weight and is a profile created from the resource Observation. Body weight is an observation concerning body weight of a person. The profile is derived from the standard FHIR profile Body weight which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The profile ObservationBodyWeightLite is used for communicating an entry of a patients body weight by sending a value in the element observation.value. The API can be used to create and read patient body weight information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | POST: It is not supported to create body weight entries with the Snomed CT concept 364589006(Birth weight). Only the concept 27113001(Body weight) is supported for POST. |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported for POST. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| 2.4.0 | 1.0.0 | R8.3.04 | Feb 2022 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for body weight registrations |
| POST | Used to create a body weight entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
code |
token | No | SNOMED CT code of the observation type |
_profile |
string | No | search on the profile url. Either code or profile is needed as search parameter. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?code= (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?code=[code]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
Statuses preliminary, entered-in-error or cancelled are not supported for POST. |
| 400 | "Only supported Snomed code is 27113001 for Body weight." | 364589006 (Birth weight) is not supported for POST |
Cambio Core profile for communicating the Bone age
The ObservationBoneAgeLite profile represents the parameter Bone age and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Bone age is an observation to indicate the degree of maturation of a child's bones.
This helps doctors estimate the maturity of a child's skeletal system. It's usually done by taking a single X-ray of the left wrist, hand, and fingers. Measured in years.
The profile ObservationBoneAgeLite is used for communicating an entry of degree of maturation of a child's bones, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Bone age |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
| code | token | No | SNOMED CT code of the observation type | |
| patient | reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
Cambio Core profile for communicating the stages of Breast development (female). For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationBreastFemaleLite profile represents the parameter Tanner girls breast stage and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Tanner girls breast stage is an observation to state the visible stages (tanner stage) of puberty by determining the degree of development of breasts.
The profile ObservationBreastFemaleLite is used for communicating the visible stages (tanner stage) of puberty by determining the degree of development of breasts, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Tanner girls breast stage |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|202001096078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
The ObservationClinicalSimple is referred from the QuestionnaireResponsPrehospitalNote. Both quantity and string values are supported. IMORTANT: This observation will not result in a structured observation in the system but will result in a free text in a final note keyword.
Cambio Core profile for communicating the Date of Menarche. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationDateOfMenarcheLite profile represents the parameter Date of menarche and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Date of menarche is an observation to state the year and the month when the first menstruation happened.
The profile ObservationDateOfMenarcheLite is used for communicating an entry of the year and the month when the first menstruation happened, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Date of menarche |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
| code | token | No | SNOMED CT code of the observation type | |
| patient | reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
Cambio Core profile for communicating the Foot Length. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationFootLengthLite profile represents the parameter Foot Length and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Foot Length is an observation where a measurement taken of the foot, from the longest toe to the back of the heel.
The profile ObservationFootLengthLite is used for communicating an entry of a patient's measurement taken of the foot, from the longest toe to the back of the heel, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Foot Length |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
| code | token | No | SNOMED CT code of the observation type | |
| patient | reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
Cambio Growth chart specific use case profile for communicating the vital parameters, Height of the biological father or height of biological mother, between an external system and COSMIC. The profile includes fields for the value of the height measurement, contextuel data and meta data. GET operation is supported. This profile should be used only for Growh chart related data communication.
Cambio Growth chart specific use case profile for communicating the vital parameters, weight of the biological father or weight of the biological mother, between an external system and COSMIC. The profile includes fields for the value of the weight measurement, contextuel data and meta data. GET operation is supported. This profile should be used only for Growh chart related data communication.
Cambio Core profile for communicating the Genital Stage (Male) For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationGenitalStageMaleLite profile represents the parameter Tanner boys genital stage and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Tanner boys genital stage is an observation to state the visible stages (tanner stage) of puberty by determining the development of testicle.
The profile Tanner boys genital stage is used for communicating the visible stages (tanner stage) of puberty by determining the development of testicle, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Tanner boys genital stage |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
| code | token | No | SNOMED CT code of the observation type | |
| patient | reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
Cambio Core profile for communicating the Head Circumference. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationHeadCircumference profile represents the vital parameter Head Circumference and is a profile created from the resource Observation. Head Circumference is an observation concerning the measurement around the patient's head. The profile is derived from the standard FHIR profile HeadCircumference which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The profile ObservationHeadCircumferenceLite is used for communicating an entry of a patient's Head Circumference, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Head Circumference |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (Search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
The ObservationHeadCircumferenceRelative profile represents the vital parameter Head Circumference and is a profile created from the resource Observation. Head Circumference relative is an observation concerning Head Circumference of a person's biological mother or father. Measuring this parameter helps doctors to predict the brain's growth and find any deviation. The profile is derived from the standard FHIR profile Head Circumference which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The profile ObservationHeadCircumferenceRelative is used for communicating an entry of a patient's relative's Head Circumference, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Head Circumference for relative |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (Search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
Cambio Core profile for communicating the vital sign, heart rate. Meant to be used as a base profile for more specific use case profiles.
| COS version | Profile version | Required COSMIC version | Date | Description |
| 4.15.0 | 1.1.0 | 4.0.0 | Oct 2025 | The extension 'heartRate-regularity' has been made optional, it was previously mandatory. |
The ObservationHeartRateLite profile represents the vital sign Heart rate and is a profile created from the resource Observation. The vital sign heart rate holds a value of the patient pulse. The profile is derived from the standard FHIR profile Vital Signs which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The ObservationHeartRateLite is used for communicating the value of the patient's heart rate in beats per minutes by sending a value in the element observation.value. If the heart rate of the patient is irregular it can also be communicated using the extension element.
The API can be used to create and read patient heart rate information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported in POST operation. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| Extension | Data type | Description |
|---|---|---|
| HeartRateRegularity | Coding | Heart rate regularity |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.15.0 | 1.2.0 | 4.0.0 | Oct 2025 | The extension 'heartRate-regularity' has been made optional, it was previously mandatory. |
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| COS Feb 2021 | 1.0.0 | R8.2.08 | Feb 2021 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for Heart rate entries |
| POST | Used to create a heart rate entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
_profile |
string | No | search on the profile url. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)Observation:performer
In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
The ObservationInspiredOxygenLite profile represents the inspired oxygen of the patient in relation to the saturation. The profile is created from the resource Observation.
The ObservationInspiredOxygenLite is used for communicating if the patient has received oxygen or not. It is only used in relation to the ObservationOxygenSaturationLite. The profile should therefore only be used as a contained resource.
If this profile is included in the payload of the Oxygen saturation, it should be interpreted as if the patient has received oxygen. The flow rate of the inspired oxygen is sent in the Observation.value element. It is optional.
ObservationInspiredOxygenLite is only used as a part of the Oxygen saturation API.
No supported operations since this profile is only used as a contained resource.
Cambio Core profile for communicating the LeftTesticularVolume. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationLeftTesticularVolumeLite profile represents the parameter Left testicular volume and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Left testicular volume is an observation to record the volume of the left testicle, measured in milliliters.
The profile Left testicular volume is used for communicating the volume of the left testicle, measured in milliliters, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Left testicular volume |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type | |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
Cambio Core profile for communicating the Length of getation at. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationLengthOfGestationAtBirthLite profile represents the parameter Length Of Gestation At Birth and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Length Of Gestation At Birth is an observation of estimated fetus gestational age at delivery, measured in weeks (eg. 36 weeks and 4 days)
The profile ObservationLengthOfGestationAtBirthLite is used for communicating an entry of a patient's estimated fetus gestational age at delivery, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Length Of Gestation At Birth |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type | |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
The ObservationMicrobiology profile represents the result information of a microbiology request and is a profile created from the resource Observation. The Resistance results will not be shown using this Observation profile, only the results of other microbiology examinations done on the sample of the patient. The data available from COSMIC to this profile is only starting from R8.3.03 COSMIC release, information created before this release cannot be taken from this API.
The profile ObservationMicrobiology is used for communicating an entry of a result of a microbiology test done by sending a value in the element observation.value. This profile is referenced in the basedOn field of DiagnosticReport FHIR profile. The API can be used to read result information for a specific microbiology test done as a part of a microbiology.
Organization profile used for performer supports requesting PDL hierarchy details as well, it will have the full hierarchy of units related to performer.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | initial version |
The ObservationMicrobiologyResistance profile represents the resistance results done for a microbiology sample and is a profile created from the resource Observation. Since there can be many resistance results for a result of a microbiology sample, this separate observation profile is used to record that information. The data available from COSMIC to this profile is only starting from R8.3.03 COSMIC release, information created before this release cannot be taken from this API.
The profile ObservationMicrobiologyResistance is used for communicating resistance test results done for a microbiology sample value in the element observation.value. The API can be used to read resistance results sent from a laboratory to COSMIC. This observation profile is linked to the ObservationMicrobiology profile using the hasMember field in the profile.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | initial version |
The ObservationNews2Lite profile represents the Assessment scale NEWS2 and is a profile created from the resource Observation. The NEWS2 is a scale for the severity of a patients condition. The NEWS2 score is calculated by the vital signs of a patient.
The ObservationNews2Lite is used for communicating the severity of a patients condition by sending the calculated score in observation.value. The score should be between 0 and 20. The News2 profile should also contain references for all vital signs used to calculate the score. It is mandatory to send all the vital signs. The score(observation.value) is optional. In COSMIC the NEWS2 score is mapped to the internal archetype for NEWS2.
The API can be used to create, invalidate/remove and read patient NEWS2 information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | For creating NEWS2 data the external user must not be the patient. E.g. A healthcare professional is the intended user to create vital sign data with this API. |
| Rule | All vital signs stated as target types in observation.derivedFrom must be referenced or included in query. One vital sign entry must only be referenced once in the same query. |
| Rule | It should not be possible for the patient to invalidate/delete the NEWS2 after sending it to COSMIC. If this happens, it should be managed manually outside the API. |
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | All vital signs stated as target types in element observation.derivedFrom must be included. |
| Rule | The same vital sign profile must not be referenced more than once. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| < 3.0.0 | 1.0.0 | R8.2.08 | Feb 2021 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for NEWS2 entries |
| POST | Used to create an NEWS2 entry. If successful, the operation will return id in response, can also be used for invalidate |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. | |
status |
token | No | The status of the observation. See supported statuses in #Statuses | |
_profile |
string | No | search by the profile url |
GET [baseURL]/Observation/_search?patient= (search)GET [baseURL]/Observation/_search?status= (search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (search)GET [baseURL]/Observation/_search?_profile= (search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[]GET [baseURL]/Observation/_search?_profile=[url]&_include=[]POST [baseURL]/ObservationObservation:performer
Observation.derivedFrom
In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
| 400 | Server supports only final status when posting Observations |
Statuses preliminary, entered-in-error, cancelled are not supported when posting a NEWS2. |
The ObservationONEWS2 profile represents the Assessment scale ONEWS2. ONEWS2 is a scale for the severity of a patients condition. The ONEWS2 score is calculated using the vital signs of a patient.
The intended use for ObservationONEWS2 is for communicating the severity of a patients condition by sending the calculated score in observation.value. The score should be between 0 and 24. The ONEWS2 profile should also contain references for all vital signs used to calculate the score. It is mandatory to send all the vital signs. The score (observation.value) is optional.
The API can be used to create and read ONEWS2 information to/from a Cambio system.
Note that invalidated observations will be returned as well (those with the status 'entered-in-error').
The MustSupport-flag indicates which attributes are supported by Cambio, meaning that those can be returned as part of the ONEWS2 Observation.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.21.0 | 1.0.0 | 6.0.0 | June 2026 | Initial version, Support for GET and POST |
| Type | Description |
|---|---|
| Rule | When creating ONEWS2, user must not be the patient. A healthcare professional is the intended user. |
| Rule | When creating ONEWS2, user should be a healthcare professional with a specified HSA ID. The healthcare professional should have their assignment and be connected to the specified care unit. The care unit should also be specified with a HSA ID. |
| Rule | Creating ONEWS2 only supports the final status. |
| Rule | All vital signs stated as target types in element observation.derivedFrom must be included. |
| Rule | The same vital sign must not be referenced more than once. |
| HTTP Method | Description |
|---|---|
| GET | Used to get ONEWS2 entry by id. |
| POST | Used to create an ONEWS2 entry. If successful, the operation will return id in response. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
id |
String | Yes | The Id of the Observation to fetch |
GET [baseURL]/Observation/[id]POST [baseURL]/ObservationIn the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The effective date must be the same for the ONEWS observation and all contained observations. | |
| 400 | Server supports only final status when posting Observations |
Statuses preliminary, entered-in-error, cancelled are not supported when posting a ONEWS. |
Cambio Core profile for communicating the vital sign, Saturation(SpO2). For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationOxygenSaturationLite profile represents the vital sign Oxygen Saturation and is a profile created from the resource Observation. The vital sign Oxygen Saturation holds a value of the blood saturation of the patient in percentage. It also contains a profile to state if the patient has received oxygen or not, and the flow rate of that potential oxygen (ObservationInspiredOxygenLite). The oxygen saturation profile is derived from the standard FHIR profile Vital Signs which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The ObservationOxygenSaturationLite is used for communicating the percentage of the patient blood saturation. The value is sent in the element observation.value. The profile can also hold information if the patient has a known hypercapnic respiratory failure. If the patient has received supplemental oxygen it can be communicated by including the contained profile for Inspired Oxygen in Observation.hasMember. If the InspiredOxygen profile is included it should be interpreted as if the patient has received oxygen.
The API can be used to create and read patient oxygen saturation information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported for POST. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | If the patient has not received oxygen the element Observation.hasMember should not include the contained profile observationInspiredOxygenLite |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| Extension | Data type | Description |
|---|---|---|
| HypercapnicRespiratoryFailure | Boolean | Communicates if the patient has a hypercapnic respiratory failure or not. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| COS Feb 2021 | 1.0.0 | R8.2.08 | Feb 2021 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for Oxygen Saturation entities |
| POST | Used to create an Oxygen saturation entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
_profile |
string | No | search on the profile url. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only FINAL status when posting Observations" | Statuses preliminary, entered-in-error or cancelled. Only status final are not supported for POST. |
Cambio Core profile for communicating the level of pain using NRS scale For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationPainNrsLite profile represents the vital parameter Pain NRS and is a profile created from the resource Observation. Pain NRS is an observation concerning pain level based on a Numeric Rating Scale (NRS). This scale is used in healthcare to help assess the extent of a patient's pain, rated from 0 (no pain) to 10 (Worst pain). The profile is derived from the standard FHIR profile Vital Signs which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The ObservationPainNrsLite is used for communicating an entry of a patient's Pain NRS by sending a value in the element observation.value. The API can be used to create and read patient Pain NRS information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported for POST. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| 2.4.4 | 1.0.0 | R8.3.04 | Feb 2022 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for Pain NRS registrations |
| POST | Used to create a Pain NRS entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. See supported statuses in #Statuses |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
_profile |
string | No | search on the profile url. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
Statuses preliminary, entered-in-error or cancelled are not supported for POST. |
Cambio Core profile for communicating the Pubic Hair Stage. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationPubicHairStageLite profile represents the parameter Pubic hair stage and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Pubic hair stage an observation to state the visible stages (tanner stage) of puberty by determining the degree of development of pubic hair.
The profile ObservationPubicHairStageLite is used for communicating the visible stages (tanner stage) of puberty by determining the degree of development of pubic hair, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Pubic hair stage |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type | |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
The ObservationRadiology profile represents results in a radiology report (represented by the DiagnosticReportRadiology profile) and is a profile created from the resource Observation.
The ObservationRadiology profile is used inside the results section of the diagnostic report for radiology. For a specific radiology request all the results related to that request will be sent using this profile as observations. Retrieving the results without the diagnostic report is not supported for now.
For more in-depth intended and non-intended use cases, see radiology in the section Use Cases.
| Type | Description |
|---|---|
| Rule | External user should not be someone else than the patient of which record the result data belongs. E.g. A healthcare professional is not the intended user of the API. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.04 | January 2022 | Initial version, support for GET. |
| Method | Description |
|---|---|
| GET | Support for retrieving ObservationRadiology by ID. |
Cambio Core profile for communicating the vital sign, Respiratory rate. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationRespiratoryRateLite profile represents the vital parameter respiratory rate and is a profile created from the resource Observation. The vital sign RespiratoryLite holds a value of the respiratory rate in breaths per minute. The profile is derived from the standard FHIR profile Vital Signs which makes the profile compliant with the FHIR standardized way of communicating vital sign data.
The ObservationRespiratoryRateLite is used for communicating the breaths per minute of the patient. The value is sent in the element observation.value.
The API can be used to create and read patient respiratory rate information from/to COSMIC.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | For reading vital sign observations, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from Observation.performer.organization (OrganizationSEVendorLite). |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| Rule | POST: The data should not be patient initiated. If patient generated, it should be ordered by a care giver and belong to a specific unit. |
| Rule | POST: It is not supported to create vital sign entries with statuses preliminary, entered-in-error or cancelled. Only status final is supported by POST operation. |
| Rule | POST: dateTime cannot be 1st of the month with the time 00:00:00.000+01:00 (See error messages described below) |
| Rule | POST: dateTime cannot be only date component, also time component will be needed (See error messages described below) |
| Rule | POST: COSMIC does not support displaying continuous values and hence the external product should not send values to COSMIC more often than every 15 minutes per patient. All values received in COSMIC will be saved and displayed but because it cannot be displayed in a proper way it should not be sent more often as standard |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Updates in target profile for performer.organization which makes it possible to retrieve PDL units |
| COS Feb 2021 | 1.0.0 | R8.2.08 | Feb 2021 | Initial version, support for GET and POST. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for Respiratory rate entities |
| POST | Used to create a Respiratory rate entry. If successful, the operation will return id in response |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
date |
date (ddmmyy) | Yes | Obtained date/time. The date is always a range, i.e. two dates are used as search parameters. |
status |
token | No | The status of the observation. |
patient |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
_profile |
string | No | search by the canonical url of the profile. |
GET [baseURL]/Observation/_search?patient= (Search)GET [baseURL]/Observation/_search?status= (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date] (Search)GET [baseURL]/Observation/_search?_profile= (Search)GET [baseURL]/Observation/_search?patient=&_include=Observation:performer (Search)GET [baseURL]/Observation/_search?status=[status]&_include=[] (Search)GET [baseURL]/Observation/_search?date=[gt_date]&date=[lt_date]&_include=[] (Search)GET [baseURL]/Observation/_search?_profile=[url]&_include=[] (Search)POST [baseURL]/Observation (Post)Observation:performer
In the table below, a few error messages specific for Observation are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Subject and Performer Patient references does not match." | |
| 400 | "The date time: < date > is invalid" | the dateTime must contain a time component |
| 400 | "Server supports only final status when posting Observations" |
POST operation with Statuses preliminary, entered-in-error or cancelled will receive this error |
Cambio Core profile for communicating the Right Testicular Volume. For Use case specific profiles, this profile can be derived for the use case profile to be compliant with the Cambio core profile.
The ObservationRightTesticularVolumeLite profile represents the parameter Right testicular volume and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Right testicular volume is an observation to record the volume of the right testicle, measured in milliliters.
The profile Right testicular volume is used for communicating the volume of the right testicle, measured in milliliters, by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Right testicular volume |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type | |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
Cambio Core profile for communicating the Waist Circumference. For Use case specific profiles, this profile can be derived for the use case profile to be complient with the Cambio core profile.
The ObservationWaistCircumferenceLite profile represents the parameter Waist circumference and is a profile created from the resource Observation which makes the profile compliant with the FHIR standardized way of communicating vital sign data. Waist circumference is an observation where a measurement taken around the abdomen at the level of the umbilicus (belly button).
The profile ObservationWaistCircumferenceLite is used for communicating an entry of a patient's measurement taken around the abdomen at the level of the umbilicus (belly button), by sending a value in the element observation.value.
| Type | Description |
|---|---|
| Rule | This API should not be used to transfer data between caregivers. |
| Rule | If the performer is Patient, the subject should be the same as given performer. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.1.0 | R8.3.05 | May 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Used to get or search for registrations of Waist circumference |
| Parameter | Format | Mandatory | Comment | |
|---|---|---|---|---|
code |
token | No | SNOMED CT code of the observation type | |
patient |
reference | No | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1 | 20200109-6078 |
GET [baseURL]/Observation/_search?patient=&code= (search)In the table below, a few error messages specific for observations are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Subject and Performer Patient references does not match. | |
| 400 | The date time: < date > is invalid | the dateTime must contain a time component |
The OncologyMedicationDispense FHIR API is used to receive Medication Dispense related data from external pharmacy system which is specialized in cancer related drug preparations.Each MedicationDispense resource represents a single medication administration occasion. This profile is based on the FHIR resource MedicationDispense.
This profile is intended to be used for the posting of data related to a dispensing occasion of cancer related drugs to a patient.
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.1.0 | 1.1.0 | COSMIC 3.12.0 | March 2024 | Initial version |
| FHIR status | Status Description |
| Preparation | FHIR status "Preparation" should be sent when drug preparation is planned but has not yet started. |
| In progress | FHIR status "In progress" should be sent when preparation has begun. |
| Stopped | FHIR status "Stopped" should be sent when preparation work being permanently stopped. |
| Completed | FHIR status "Completed" should be sent when preparation is done and and the prepared drug is ready to be shipped. |
| Entered-in-error | FHIR status "Entered-in-error" should be sent when previous MedicationDispense status was entered in error and therefore nullified. |
| HTTP Method | Description |
|---|---|
| POST | Posting a dispensing occasion for a patient with related information. |
POST [baseURL]/MedicationDispenseThe operation $linkToHealthIssue is an operation performed on the profile QuestionnaireResponseSe, which is based on the QuestionnaireResponse resource. This operation is used to link a ConditionHealthIssueSe to the QuestionnaireResponseSe.
The formal computable definition of the operation is specified by the OperationDefinitionLinkToHealthIssue profile, derived from the OperationDefinition resource in FHIR R4.
To pass information into the operation, the ParametersHealthIssueReferenceSe profile is used, which is based on the Parameters resource in FHIR R4.
The API is designed to link a ConditionHealthIssueSe to a QuestionnaireResponseSe belonging to the same patient. Only one ConditionHealthIssueSe can be linked to a QuestionnaireResponseSe at a time. Additionally, only ConditionHealthIssueSe resources with an active or closed status can be linked.
The literal ID (COSMIC resource ID) of the QuestionnaireResponseSe to be linked must be provided in the API path. This ensures that the QuestionnaireResponseSe referenced exists in COSMIC.
The literal ID (COSMIC resource ID) of the ConditionHealthIssueSe to be linked should be included in the API request body using the ParametersHealthIssueReferenceSe profile.
This API is recommended for use by healthcare professionals.
| Type | Description |
|---|---|
| Rule | Only the ConditionHealthIssueSe in status active or completed may be linked to the QuestionnaireResponseSe. |
| Limitation | Invalidating a link created in an erroneous situation is not supported. |
| Limitation | Only one ConditionHealthIssueSe can be linked at a time; linking multiple is not permitted. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.5.0 | 1.0.0 | 4.0.0 | Sep 2024 | Initial version, support for POST $linkToHealthIssue. |
| HTTP Method | Description | Scope |
|---|---|---|
| POST | Link a QuestionnaireResponseSe to a ConditionHealthIssueSe belonging to the same patient. | system/QuestionnaireResponse.write OR user/QuestionnaireResponse.write OR patient/QuestionnaireResponse.write |
POST [baseURL]/QuestionnaireResponse/{id}/$linkToHealthIssue| Scenario | Response code | Description |
|---|---|---|
| API request is a success. | 200 OK | - |
| Path parameter "id": Empty | 400 Bad Request | Invalid request: The FHIR endpoint on this server does not know how to handle POST operation[QuestionnaireResponse/$linkToHealthIssue] with parameters [[]] |
| Path parameter "id": Journal note doesn't exist in Cosmic | 404 Not Found | Invalid parameters: QuestionnaireResponseSe not found. |
| Path parameter "id": Invalid input type | 500 Internal Server Error | - |
| Body parameter "resourceType": Empty, NULL, or not supplied | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1838: Invalid JSON content detected, missing required element: 'resourceType' |
| Body parameter "resourceType": A different value than 'Parameters' | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1684: Unknown resource name "<supplied value>" (this name is not known in FHIR version "R4") |
| Body parameter "meta": Empty, NULL, or Not supplied | 400 Bad Request | Parameters must contain a valid meta profile |
| Body parameter "meta.profile": Empty | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1821: [element="profile"] Invalid attribute value "": Attribute value must not be empty ("") |
| Body parameter "meta.profile": NULL | 400 Bad Request | Parameters must contain a valid meta profile |
| Body parameter "meta.profile": Not supplied | 400 Bad Request | Parameters must contain a valid meta profile |
| Body parameter "meta.profile": Wrong profile url value | 422 Unprocessable Entity | Profile reference 'https://fhir.cambio.se/StructureDefinition/ParametersHealthIssueReferenceSee/v1' has not been checked because it is unknown |
| Body parameter "parameter": Empty, NULL, or Not supplied | 422 Unprocessable Entity | Parameters.parameter: minimum required = 1, but only found 0 (from https://fhir.cambio.se/StructureDefinition/ParametersHealthIssueReferenceSe/v1) |
| Body parameter "parameter.name": Empty | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1821: [element="name"] Invalid attribute value "": Attribute value must not be empty ("") |
| Body parameter "parameter.name": NULL, or Not supplied | 422 Unprocessable Entity | Parameters.parameter.name: minimum required = 1, but only found 0 (from https://fhir.cambio.se/StructureDefinition/ParametersHealthIssueReferenceSe/v1) |
| Body parameter "parameter.name": A different value other than "HealthIssueReference" | 422 Unprocessable Entity | Value is '<supplied value>' but must be 'HealthIssueReference' |
| Body parameter "parameter.valueReference": Empty, or Not supplied | 422 Unprocessable Entity | inv-1: 'A parameter must have one and only one of (value, resource, part)' Rule 'A parameter must have one and only one of (value, resource, part)' Failed |
| Body parameter "parameter.valueReference.reference": Empty | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1821: [element="reference"] Invalid attribute value "": Attribute value must not be empty ("") |
| Body parameter "parameter.valueReference.reference": NULL, or Not supplied | 422 Unprocessable Entity | inv-1: 'A parameter must have one and only one of (value, resource, part)' Rule 'A parameter must have one and only one of (value, resource, part)' Failed |
| Body parameter "parameter.valueReference.reference": Not in the format 'Codition/hi-< id >' | 400 Bad Request | Invalid request: The supplied condition ID is not supported |
| Body parameter "parameter.valueReference.reference": Invalid input type | 400 Bad Request | HealthIssueReference must contain a valid reference |
| Body parameter "parameter.valueReference.reference": Health issue doesn't exist in Cosmic | 400 Bad Request | Invalid parameters: ConditionHealthIssueSe not found |
| Body parameter "parameter.valueReference.reference": Health issue status is not Ongoing or Closed. | 400 Bad Request | Invalid parameters: The supplied ConditionHealthIssueSe is not in Ongoing or Closed status |
| If the supplied journal note and the health issue do not belong to the same patient. | 400 Bad Request | Invalid parameters: Supplied QuestionnaireResponseSe and ConditionHealthIssueSe do not belong to the same patient |
| If a link already exist for the supplied health issue and journal note. | 409 Conflict | The supplied QuestionnaireResponse & ConditionHealthIssue are already linked |
| If an unsupported scope is supplied. | 403 Forbidden | - |
The operation $unlinkFromHealthIssue is an operation performed on the profile QuestionnaireResponseSe, which is based on the QuestionnaireResponse resource. This operation is used to disconnect the link between a ConditionHealthIssueSe and a QuestionnaireResponseSe.
The formal computable definition of the operation is specified by the OperationDefinitionUnlinkFromHealthIssue profile, derived from the OperationDefinition resource in FHIR R4.
To pass information into the operation, the ParametersHealthIssueReferenceSe profile is used, which is based on the Parameters resource in FHIR R4.
The API is designed to disconnect the link between a ConditionHealthIssueSe and a QuestionnaireResponseSe belonging to the same patient. Only one ConditionHealthIssueSe can be unlinked from a QuestionnaireResponseSe at a time.
The literal ID (COSMIC resource ID) of the QuestionnaireResponseSe to be unlinked must be provided in the API path. This ensures that the QuestionnaireResponseSe referenced exists in COSMIC.
The literal ID (COSMIC resource ID) of the ConditionHealthIssueSe to be unlinked must be included in the API request body using the ParametersHealthIssueReferenceSe profile.
This API is recommended for use by healthcare professionals.
| Type | Description |
|---|---|
| Limitation | Only one ConditionHealthIssueSe can be unlinked at a time; unlinking multiple is not permitted. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| TBA | 1.0.0 | TBA | tba | Initial version, support for POST $unlinkFromHealthIssue. |
| HTTP Method | Description | Scope |
|---|---|---|
| POST | Disconnect the link between a QuestionnaireResponseSe and a ConditionHealthIssueSe belonging to the same patient. | system/QuestionnaireResponse.write OR user/QuestionnaireResponse.write OR patient/QuestionnaireResponse.write |
POST [baseURL]/QuestionnaireResponse/{id}/$unlinkFromHealthIssue| Scenario | Response code | Description |
|---|---|---|
| API request is a success. | 200 OK | - |
| Path parameter "id": Empty | 400 Bad Request | Invalid request: The FHIR endpoint on this server does not know how to handle POST operation[QuestionnaireResponse/$unlinkFromHealthIssue] with parameters [[]] |
| Path parameter "id": Journal note doesn't exist in Cosmic | 404 Not Found | Invalid parameters: QuestionnaireResponseSe not found. |
| Path parameter "id": Invalid input type | 500 Internal Server Error | - |
| Body parameter "resourceType": Empty, NULL, or not supplied | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1838: Invalid JSON content detected, missing required element: 'resourceType' |
| Body parameter "resourceType": A different value than 'Parameters' | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1684: Unknown resource name "<supplied value>" (this name is not known in FHIR version "R4") |
| Body parameter "meta": Empty, NULL, or Not supplied | 400 Bad Request | Parameters must contain a valid meta profile |
| Body parameter "meta.profile": Empty | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1821: [element="profile"] Invalid attribute value "": Attribute value must not be empty ("") |
| Body parameter "meta.profile": NULL | 400 Bad Request | Parameters must contain a valid meta profile |
| Body parameter "meta.profile": Not supplied | 400 Bad Request | Parameters must contain a valid meta profile |
| Body parameter "meta.profile": Wrong profile url value | 422 Unprocessable Entity | Profile reference 'https://fhir.cambio.se/StructureDefinition/ParametersHealthIssueReferenceSee/v1' has not been checked because it is unknown |
| Body parameter "parameter": Empty, NULL, or Not supplied | 422 Unprocessable Entity | Parameters.parameter: minimum required = 1, but only found 0 (from https://fhir.cambio.se/StructureDefinition/ParametersHealthIssueReferenceSe/v1) |
| Body parameter "parameter.name": Empty | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1821: [element="name"] Invalid attribute value "": Attribute value must not be empty ("") |
| Body parameter "parameter.name": NULL, or Not supplied | 422 Unprocessable Entity | Parameters.parameter.name: minimum required = 1, but only found 0 (from https://fhir.cambio.se/StructureDefinition/ParametersHealthIssueReferenceSe/v1) |
| Body parameter "parameter.name": A different value other than "HealthIssueReference" | 422 Unprocessable Entity | Value is '<supplied value>' but must be 'HealthIssueReference' |
| Body parameter "parameter.valueReference": Empty, or Not supplied | 422 Unprocessable Entity | inv-1: 'A parameter must have one and only one of (value, resource, part)' Rule 'A parameter must have one and only one of (value, resource, part)' Failed |
| Body parameter "parameter.valueReference.reference": Empty | 400 Bad Request | HAPI-0450: Failed to parse request body as JSON resource. Error was: HAPI-1821: [element="reference"] Invalid attribute value "": Attribute value must not be empty ("") |
| Body parameter "parameter.valueReference.reference": NULL, or Not supplied | 422 Unprocessable Entity | inv-1: 'A parameter must have one and only one of (value, resource, part)' Rule 'A parameter must have one and only one of (value, resource, part)' Failed |
| Body parameter "parameter.valueReference.reference": Not in the format 'Codition/hi-< id >' | 400 Bad Request | Invalid request: The supplied condition ID is not supported |
| Body parameter "parameter.valueReference.reference": Invalid input type | 400 Bad Request | HealthIssueReference must contain a valid reference |
| Body parameter "parameter.valueReference.reference": Health issue doesn't exist in Cosmic | 400 Bad Request | Invalid parameters: ConditionHealthIssueSe not found |
| If a link doesn't exist for the supplied health issue and journal note. | 400 Bad Request | The supplied QuestionnaireResponse & ConditionHealthIssue are not linked |
| If an unsupported scope is supplied. | 403 Forbidden | - |
The operation $invalidate is an operation performed on the profile EncounterOutpatientReadSe. This operation is used to invalidate an encounter that has been created in error.
An example scenario is if the encounter was created for the wrong patient, meaning it should never have been valid.
The formal computable definition of the operation is specified by this profile.
| HTTP Method | Description |
|---|---|
| POST | Invalidate a single outpatient encounter for a patient. |
For example of input parameters, see: InvalidateEncounterParametersExample
POST [baseURL]/Encounter/{id}/$invalidateThis is a light weight Swedish healthcare Organization profile. It can be used when Organizations have been referenced by other resources, such as Observation, ServiceRequest or Appointment. It can also be used for presenting a list of organizations with associated information.
Note that this profile is not maintained by Cambio, but is created in a Swedish vendor FHIR collaboration. Link to ImplementationGuide for the collaborative profiles will be added here shortly.
Intended use for this API is to get information about a healthcare organization, including units. The profile includes an extension which supports finding out the HSA care provider and HSA care unit for the specific organization. Following partOf reference can also be used to retrieve information about the whole organizational tree.
The profile is also referenced as target profile from many other resources enabling possibility to e.g. find PDL units connected to a certain resource, e.g. ServiceRequest or Organization. More information about this can be found on other resources in this ImplementationGuide.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Rule | Only one search parameter at a time can be used for Organization |
| Rule | The intended users of this API are healthcare professionals. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading organization information, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved in the profile. |
| Rule | The element Organization.address is read-only. |
| Rule | The element Organization.telecom is read-only. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | Sep 2022 | Initial version, support for GET, POST and PUT |
| HTTP Method | Description |
|---|---|
| GET | Used to search for organizations or retrieve a single one. |
| POST | Used to create an organization. |
| PUT | Used to update an organization. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
| '_id' | string | No | search on the id. |
| 'identifier' | token | No | An identifier of the organization, e.g. HSA id. |
| 'name' | string | No | name of the organization |
GET [baseURL]/Organization/[id] (get by id)GET [baseURL]/Organization/_search?identifier=[identifier] (Search)GET [baseURL]/Organization/_search?name[name]= (Search)GET [baseURL]/Organization/_search?_id=[id1],[id2],[id3] (Search)GET [baseURL]/Organization/_search?_profile=[url] (Search)POST [baseURL]/Organization (Post)PUT [baseURL]/Organization (Put)partOfThis profile is intended to support transfer of information into the operations '$linkToHealthIssue' and '$unlinkFromHealthIssue'. These operations are used to create links and remove links between a QuestionnaireResponse and a ConditionHealthIssue, respectively.
This is a Core profile, hence is open in its profiling. Consider using more specific profiles derived from this one.
PatientLiteSe is a profile based on the FHIR resource Patient.
The intended use for the PatientLiteSe profile is used to search for a list of patients based on a search parameter.
PatientLiteSe is defined for the Swedish market.
| Type | Description |
|---|---|
| Rule | The intended users of this API are healthcare professionals. |
| Rule | The element Patient.deceased[x] is read-only. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.1.0 | 1.1.0 | R8.3.05 | Feb 2024 | Unused attributes removed |
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for GET, POST and PUT. |
| HTTP Method | Description |
|---|---|
| GET | Search for a list of patients based on search parameters. |
| Parameter | Format | Comment |
|---|---|---|
family |
String | Name given in name.family |
given |
String | Name given in name.given |
GET [baseURL]/Patient/_search?given=testGET [baseURL]/Patient/_search?family=testIn below table, a few error messages specific for Patient are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Combination of parameters [name & identifier] are not supported" | |
| 400 | "Invalid/Unsupported Search parameters" |
PatientSe is a profile based on the FHIR resource Patient.
The PatientSe profile is used to retrieve demographic and administrative information about an individual receiving care or other health-related services. The PatientSe profile is profiled for the Swedish market.
| Type | Description |
|---|---|
| Rule | The intended users of this API are healthcare professionals. |
| Rule | The element Patient.deceased[x] is read-only. |
| Rule | The element Patient.address is read-only. |
| Rule | The element Patient.telecom is read-only. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.1.0 | 1.1.0 | R8.3.05 | Feb 2024 | Unused attributes removed |
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for GET, POST and PUT. |
| Extension | Data type | Description |
|---|---|---|
| County | Coding | The county the patient is registered in. |
| Municipality | Coding | The municipality the patient is registered in. |
| Parish | Coding | The parish the patient is registered in. |
| GenderIdentity | CodeableConcept | The patient's gender identity. |
| ReferMeAs | String | The patient's referred gender. |
| CareOf | String | The name of the party who will take receipt at the specified address, and will take on responsibility for ensuring delivery to the target recipient. |
| StreetAddressLine | String | A street address line is frequently used instead of breaking out building number, street name, street type, etc. An address generally has only a delivery address line or a street address line, but not both. |
| MiddleName | String | Defines the Swedish middle name as defined by legislation. |
| GivenNameQualifier | code | Used to indicate additional information about the name part and how it should be used. |
| HTTP Method | Description |
|---|---|
| GET | Used to retrieve a patient. |
| POST | Used to create a patient. |
| PUT | Used to update a patient. |
| Parameter | Format | Comment |
|---|---|---|
| 'identifier' | Token | identifier for patient.identifier |
| 'family' | String | Name given in name.family |
| 'given' | String | Name given in name.given |
GET [baseURL]/Patient/_search?given=testGET [baseURL]/Patient/_search?family=testGET [baseURL]/Patient/_search?identifier=urn:oid:1.2.752.129.2.1.3.1|191212121212In below table, a few error messages specific for Patient are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | "Combination of parameters [name & identifier] are not supported" | |
| 400 | "Invalid/Unsupported Search parameters" | |
| 422 | "Profile validation failure" |
This is a Core profile, hence is open in its profiling. Consider using more specific profiles derived from this one.
The PractitionerRoleLiteSe profile represents a practitioner and the connected organization and is a profile created from the resource PractitionerRole.
PractitionerRoleLiteSe is used for carrying the HSA ID of the staff and the unit related to the source profile referencing the PractitionerRoleLiteSe. PractitionerRoleLiteSe does not have a business identifier and is mapped to both a unit and a staff using the HSA ID:s. The profile can either be sent as a contained resources within a source profile, or included ein a bundle.
PractitionerRoleLiteSe can not be used to communicate PractitionerRoleLiteSe by itself. It must always be communicated in a context where it is referenced in as a contained resource or sent in a bundle.
ProcedureKVALite is a profile intended to be used by the Swedish market, and handles codes from the code system KVÅ. This profile is based on the FHIR resource Procedure. Additionally, it manages building hierarchies of procedures with the extension .
ProcedureKVALite is currently only used as a contained resource within QuestionnaireResponse.
Intended user for this resource is only a healthcare professional. The healthcare professional should be the same as specified in QuestionnaireResponseSe. If Unit is specified, it should be with HSA id and has to be the same unit as was given in QuestionnaireResponseSe.
| Type | Description |
|---|---|
| Rule | The author of ProcedureKVALite should not be a patient. |
| Rule | The API should not be used to send unsigned data to COSMIC. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.1.0 | 1.0.0 | R8.3.05 | Sep 2021 | Initial version |
| FHIR status | Interpretation |
|---|---|
| preparation | Considered a future/planned procedure. E.g. status cannot be preparation if performedDateTime is in the past. |
| completed | Considered a completed procedure. E.g. status cannot be completed if performedDateTime is in the future. |
Not applicable, this profile is just used as a contained resource and there is no API for Procedure. For examples, refer to Resources.QuestionnaireResponse.
The ProvenanceStatusSe profile is used to manipulate the status of other resources. This means that ProvenanceStatusSe does not represent an individual resource in the system.
If the external system is considered the master system of the information, ProvenanceStatusSe can be used to nullify (invalidate) the data in COSMIC if it is nullified (invalidated) in the master system. Intended user of the API is a healthcare professional with a specified HSA ID. The healthcare professional should have their assignment (medarbetaruppdrag) and be connected to the specified unit. The specified unit should also be identified with HSA ID.
| Type | Description |
|---|---|
| Rule | The API should not be used by patients who wishes to nullify (invalidate) a QuestionnaireResponse or Observation. This needs to be handled with business routines outside the API communication. |
| Rule | The API should not be used to transfer data between caregivers. |
| Rule | The API for nullifying (invalidating) should be implemented for real-time use by external system due to the patient risk with having wrong information in COSMIC. |
| Limitation | The only supported target is QuestionnaireResponse or Observation. |
| Limitation | The only supported activity code is NULLIFY. |
| Limitation | Reason.coding is not applicable for QuestionnaireResponse, only reason.text. |
| Limitation | The only supported reason.coding for Observation is EIE. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.1.0 | 1.0.0 | R8.3.05 | July 2021 | Initial version, support for POST |
| HTTP Method | Description |
|---|---|
| POST | Support to POST Provenance with target QuestionnaireResponse or Observation |
POST [baseURL]/ProvenanceIn the table below, a few error messages specific for Provenance are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Not supported target | Occurs when provenance.target is something else than QuestionnaireResponse or Observation |
| 400 | Not supported activity | Occurs when provenance.activity is something else than NULLIFY |
Cambio core profile for QuestionnaireResponse.
QuestionnaireResponsePrehospitalNote is based on the FHIR resource QuestionnaireResponse.
The QuestionnaireResponsePrehospitalNote profile is implemented to create a pre-hospital discharge summary/final note in COSMIC from an external ambulance system.
The pre-hospital note includes structured keywords as part of a medical record note template, as well as a PDF attachment. The pre-hospital note can also include a triage (ClinicalImpression) and observations (Observation).
| Type | Description |
|---|---|
| Limitation | Only one pre-hospital note can be created for a contact, if used more than once on the same contact the new note will replace the last one. |
| Rule | The intended users of this API are healthcare professionals. |
| FHIR status | Status in COSMIC |
|---|---|
| Completed | Signed |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for PUT. |
| HTTP Method | Description |
|---|---|
| PUT | Used to create a QuestionnaireResponsePrehospitalNote for a given patient. |
PUT [baseURL]/subscription/Bundle/external-ID (PUT)In below table, a few error messages specific for QuestionnaireResponse are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Invalid LinkId:< LinkId > | Medication QR item has sub items with unsupported LinkIds. The supported linkIds for medication attributes(QR.item.answer.item.linkId) are defined in the profile. |
| 400 | Only one answer is supported for Medication Sub Items | Only one answer can be provided for Medication sub items(QR.item.answer.item.answer) |
| 400 | Invalid DateTime in the Mediation | Validation error in the summary note |
| 400 | Invalid DrugName in the Mediation Item | Validation error in the summary note |
| 400 | Invalid DoseQuantity in the Mediation Item | Validation error in the summary note |
| 400 | Invalid Dose unit in the Mediation Item | Validation error in the summary note |
| 400 | Invalid Route in the Mediation Item | Validation error in the summary note |
| 400 | Multiple URL type answers are not supported | Validation error in the summary note. It is possible to include only one URL in the summary note |
The QuestionnaireResponseSe profile includes the answers to the questions in the QuestionnaireSe profile. The QuestionnaireSe profile also defines the logic which the QuestionnaireResponse should follow. QuestionnaireResponseSe is profiled for the Swedish market.
Intended user of the API is a healthcare professional with a specified HSA ID. The healthcare professional should have their assignment and be connected to the specified unit. Unit should also be specified with HSA ID. Intended use in is that the API is used within the same caregiver.
The user and specified unit should exist in COSMIC and be the same in the external system. Only signed notes should be sent from the external system.
It is recommended to implement the API for real time synchronization, due to the patient risk with not having the latest information in COSMIC.
In cases where the patient is the author, the extension common-hsaHierarchy is used to specify to which care provider and unit responsible care unit the QuestionnaireResponse belongs.
A QuestionnaireResponse sent through this API can only reference a Questionnaire which exists in COSMIC. This means that it is a prerequisite to also implement QuestionnaireSeLite and QuestionnaireSe to retrieve an applicable Questionnaire id.
Medical record notes created through this API will be read-only and cannot be updated in the external system. The reason is to avoid differences in documentation between different systems. If the external system has its own storage it should be considered the information owner and every change/update of the information should be done from the external system to guarantee the correctness of the information.
| Type | Description |
|---|---|
| Rule | The API should not be used to transfer data between care givers. |
| Rule | If a created QuestionnaireResponse is re-signed/updated in the external system it should invalidated and re-created through this API and Provenance API, as there is no support for updating in the current version of COS. |
| Rule | The API does not support scenarios concerning reviewing medical record notes, meaning that the healthcare professional (user) can sign themselves without needing review from others. |
| Rule | Caregivers who use this API must themselves develop routines for how imported information is to be paid attention to. |
| Rule | A date is required. Format for date should be YYYY-MM-DD. If the date is the 1st of respective month, time must also be provided. |
| Rule | Medical record notes created through this API will be read-only and cannot be updated in the external system. |
| Rule | The extension 'answerComment' will only be possible to use if the corresponding QuestionnaireSe resource allows for it. |
| Limitation | COSMIC only supports statuses 'completed', 'entered-in-error' and 'in-progress'. |
| Limitation | Only Condition, Procedure and Observation are supported as answer references. |
| FHIR status | Status in COSMIC |
|---|---|
| in-progress | Unsigned |
| completed | Signed (when author is a PractitionerRole), Complete Not Signable (when author is the patient) |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 2.4.0 | 1.0.0 | R8.3.04 | Feb 2022 | Initial version, support for POST. |
| 4.2.0 | 1.1.0 | 3.10.0 | Apr 2024 | Support for status 'in-progress'. |
| 4.5.0 | 1.2.0 | 3.10.0 | Sep 2024 | readOnly extension added. |
| 4.15.0 | 1.3.0 | 3.10.0 | Sep 2025 | Added the possibility to include Observations as answer references and added new extension answerComment. |
| 4.18.0 | 1.4.0 | 3.10.0 | Jan 2026 | Defined which Observation profiles that can be referenced in an answer. |
| 4.20.0 | 1.5.0 | 5.0.0 | May 2026 | Added ObservationBPComplex profile to the list of profiles than can be referenced in an answer. |
| HTTP Method | Description |
|---|---|
| POST | Used to create a QuestionnaireResponse for a given patient. If successful, the operation will return id in response. |
POST [baseURL]/QuestionnaireResponseIn below table, a few error messages specific for QuestionnaireResponse are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Invalid payloads |
QuestionnaireSe is created from the FHIR resource Questionnaire. The Questionnaire resource is tightly coupled with the QuestionnaireResponse resource, where the Questionnaire resource holds the logic that the QuestionnaireResponse resource should follow.
QuestionnaireSe is used to fetch Questionnaires (Medical record templates) from COSMIC. The retrieved Questionnaires should be used for filling a QuestionnaireResponse which can be sent back to COSMIC.
Questionnaires can be retrieved both for when a healthcare professional will be the author, or when a patient will be the author.
The MustSupport-flag indicates which attributes are supported by Cambio, meaning that those can be returned as part of the questionnaire.
| Type | Description |
|---|---|
| Rule | It is mandatory to provide one or several codings to be able to retrieve any Questionnaires through the API. |
| Rule | Only when the item.type is 'quantity' is it possible to include the unit in the extension 'quantityUnit'. |
| Rule | If your integrations is with COSMIC, then it is only possible to include the unit in the extension 'quantityUnit if COSMIC keywords are configured with UCUM codes in the journal note templates. |
| Rule | Only when the item.type is 'reference' is it possible to include the referenced resource type in the extension referenceResource'. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 2.4.0 | 1.0.0 | R8.3.04 | Feb 2022 | Initial version, support for GET. |
| 4.14.0 | 1.1.0 | R8.3.04 | Sep 2025 | Added extensions quantityUnit and referenceResource. |
| 4.15.0 | 1.2.0 | R8.3.04 | Oct 2025 | Added extension allowComment. |
| 4.17.0 | 1.3.0 | R8.3.04 | Jan 2026 | Added extension referenceProfile and removed the extension referenceResource. |
| x.x.x | 1.4.0 | R8.3.04 | Jan 2026 | Added extension maxValue and minValue and changed cardinality of the extension referenceProfile from 0..1 to 0..2. |
| HTTP Method | Description |
|---|---|
| GET | GET Questionnaire by id. |
GET [baseURL]/Questionnaire/[id]In the table below, a few error messages specific for Questionnaire are listed.
| Code | Description |
|---|---|
| 400 | Codes should be valid Tokens with system and value |
| 404 | Questionnaire not found for the codes |
QuestionnaireSeLite is created from the FHIR resource Questionnaire.
Intended use for the QuestionnaireSeLite profile is to apply for searching out a list of Questionnaires with limited contents (i.e. items are not included). This is done by providing one or several codes as the search parameter. The bundled list that is retrieved from the search should be used to get an overview of available Questionnaires, which complete contents can later be retrieved through QuestionnaireSe.
| Type | Description |
|---|---|
| Rule | It is mandatory to provide one or several codings to be able to retrieve any Questionnaires through the API. |
| Rule | It is mandatory for the Questionnaire to have a name (title) to be able to retrieve the Questionnaire. |
| Rule | It is mandatory to use the Snomed code for Patient (16154003) when retrieving questionnaires for patient use. If this code is not specified, the API will return healthcare professional templates. |
| Rule | To request healthcare professional templates, the Snomed code for Healthcare professional (223366009) is used. |
| Rule | The useContext for patient should only be used for this API. Only templates that have been agreed on should be used. |
| Limitation | Only one of the template contexts patient/healthcare professional can be requested at the time. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 2.4.0 | 1.0.0 | R8.3.04 | Feb 2022 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | GET Questionnaires by given codes. |
| Parameter | Format | Comment |
|---|---|---|
code |
token | Codes given in Questionnaire.code |
useContext |
token | Codes given in Questionnaire.useContext.PatientQuestionnaire |
GET [baseURL]/Questionnaire/?search?code=GET [baseURL]/Questionnaire/_search?code=http://snomed.info/sct|259008006&context=http://snomed.info/sct|116154003In the table below, a few error messages specific for Questionnaire are listed.
| Code | Description | Comment |
|---|---|---|
| 400 | Codes should be valid Tokens with system and value | |
| 400 | Unsupported Context is provided for context parameter | |
| 404 | Questionnaire not found for the codes |
ServiceRequestLabAnalysis is a profile based on the FHIR resource ServiceRequest.
ServiceRequestLabAnalysis is used for individual laboratory orders, for example to order an analysis of a specific analyte. The profile can be used either to request information for a single laboratory analysis. The intended use for reading data with this API is in first hand that the API is applied for direct access and to create service requests for laboratory analysis. This profile is recomended to be used in combination with the ServiceRequestLabOrder profile, where the ServiceRequestLabOrder profile is used to represent the order.
| Type | Description |
|---|---|
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading service requests, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment.PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from ServiceRequest.performer.organization (OrganizationSEVendorLite). |
| Limitation | Currently only chemistry orders are supported. |
| Limitation | If COSMIC is the back-end system, then all analyte/analysis included in an order need to have the same status. |
| Limitation | If COSMIC is the back-end system then the FHIR request priority STAT is not supported for chemistry orders. |
| Limitation | Service request priority is included in the order level not the analysis level, so all analyses included in the same order may have the same priority. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.19.0 | 1.0.0 | 5.1.0 | April 2026 | Initial version. |
ServiceRequestLabOrder is a profile based on the FHIR resource ServiceRequest.
ServiceRequestLabOrder is used for laboratory orders. The profile can be used either to request all laboratory orders for a patient, or request information for a single laboratory order. The intended use for reading data with this API is in first hand that the API is applied for direct access and to create service requests for laboratory orders.
| Type | Description |
|---|---|
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | Both lite references and business identifier references can be used but the same type of reference must be used in both the order and the analysis. |
| Rule | For reading service requests, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment.PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from ServiceRequest.performer.organization (OrganizationSEVendorLite). |
| Limitation | Currently only chemistry orders are supported. |
| Limitation | If COSMIC is the back-end system, then all analyte/analysis included in an order need to have the same status. |
| Limitation | The POST operation supports only draft status. But GET APIs supports active, revoked and completed statuses additionally |
| Limitation | If COSMIC is the back-end system then the FHIR priority STAT is not supported for chemistry orders. |
| Limitation | If COSMIC is the back-end system then multiple domains/specialties are not supported in a single order. |
| Limitation | If COSMIC is configured to expect an encounter, then COS API call with fail. |
| Limitation | If COSMIC is the back-end system, then the seconds provided in authoredOn attribute are ignored. |
| Limitation | The requisition attribute is read-only. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 4.19.0 | 1.0.0 | 5.1.0 | April 2026 | Initial version, support for POST and GET by id. |
| Extension | Data type | Description |
|---|---|---|
| PayingUnit | Reference | Organizational unit that is responsible for the payment. |
| CopyRecipientHealthcareUnit | Reference | Organizational unit that receives a copy of a healthcare related service (for example service request). |
| HTTP Method | Description |
|---|---|
| POST | Create service request for laboratory order. |
| GET | Search for a single service request for laboratory order by id. |
POST [baseURL]/ServiceRequestLabOrder (Post)GET [baseURL]/ServiceRequest/[id] (Read)The ServiceRequestMicrobiology profile is used for retrieving data about a microbiology request. This profile is based on the FHIR resource ServiceRequest. The profile includes information like requester, status of the request, category and the code of the requested microbiology report, etc.The data available from COSMIC to this profile is only starting from R8.3.03 COSMIC release, information created before this release cannot be taken from this API.
This profile is created as a referenced profile for the DiagnosticReport profile related to microbiology. The microbiology request is the starting point of the microbiology report, so the request information is added to this profile and referenced in the basedOn field of the DiagnosticReport FHIR profile.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Rule | External user should not be someone else than the patient of which record the referral data belongs. E.g. A healthcare professional is not the intended user of the API. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading microbiology requests, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from ServiceRequest.performer.organization (OrganizationSEVendorLite). |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | initial version, support for GET |
| FHIR status | Status in COSMIC |
|---|---|
| Preliminary | Unsigned |
| Active | Signed, Sent, Received, Booked, PreliminaryResultReceived |
| Completed | ResultReceived, AdditionalResultReceived |
| Revoked | Cancelled |
| HTTP Method | Description |
|---|---|
| GET | Support for retrieving ServiceRequestMicrobiology by ID |
GET [baseURL]/ServiceRequest/[id] (Read)No specific error codes for ServiceRequestMicrobiology.
The ServiceRequestRadiology profile is used for retrieving data about a radiology request. This profile is based on the FHIR resource ServiceRequest. It includes information like requester, status of the request, category and the code of the requested radiology report etc.
This profile is created as a referencing profile for the DiagnosticReport profile related to radiology. The radiology request is the starting point of the radiology report so the request information is added to this profile and referenced in the basedOn field of DiagnosticReport FHIR profile.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Rule | External user should not be someone else than the patient of which record the referral data belongs. E.g. A healthcare professional is not the intended user of the API. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading radiology requests, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from ServiceRequest.performer.organization (OrganizationSEVendorLite). |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.04 | January 2022 | Initial version, support for GET. |
| FHIR status | Status in COSMIC |
|---|---|
| Preliminary | Unsigned |
| Active | Signed, Sent, Received, Booked, PreliminaryResultReceived |
| Completed | ResultReceived, AdditionalResultReceived |
| Revoked | Cancelled |
| HTTP Method | Description |
|---|---|
| GET | Support for retrieving ServiceRequestRadiology by ID |
GET [baseURL]/ServiceRequest/[id] (Read)No specific error codes for ServiceRequest.
The ServiceRequestReferral profile is used for retrieving data about a referral request. This profile is based on the FHIR resource ServiceRequest. It includes information like referral date, requester, receiver and also references a Composition resource with referral record data.
The intended use for this API is to get information about a patient's referral requests, both ongoing and completed. The referrals with accompanied data such as assessments and answers can be retrieved when the external system user is the patient to which record the data belongs.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading referral information, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from ServiceRequest.performer.PractitionerRoleLiteSe (PractitionerRoleLiteSe.OrganizationSEVendorLite). |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 2.4.0 | 1.1.0 | R8.3.04 | Feb 2022 | Enhanced support for PDL. |
| 2.3.0 | 1.0.0 | R8.3.03 | Nov 2021 | Initial version, support for GET. |
| HTTP Method | Description |
|---|---|
| GET | Support for GET ServiceRequest by specific Id, and also to search by subject. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
_profile |
string | No | |
subject |
reference | Yes | The subject that the observation is about (if patient). The reference can be a literal reference ex: subject=1 or a Business identifier as well.ex: subject.identifier=urn:oid:1.2.752.129.2.1.3.1|20200109-6078 |
GET [baseURL]/ServiceRequest/[id] (Read)GET [baseURL]/ServiceRequest/subject= (Search)GET [baseURL]/ServiceRequest/subject=[id]&_include=ServiceRequest;subject (Search)GET [baseURL]/ServiceRequest/subject=[id]&_include=ServiceRequest;requester (Search)GET [baseURL]/ServiceRequest/subject=[id]&_include=ServiceRequest;requester.practitioner (Search)GET [baseURL]/ServiceRequest/subject=[id]&_include=ServiceRequest;requester.organization (Search)GET [baseURL]/ServiceRequest/subject=[id]&_include=ServiceRequest;performer (Search)GET [baseURL]/ServiceRequest/subject=[id]&_include=ServiceRequest;performer.practitioner (Search)GET [baseURL]/ServiceRequest/subject=[id]&_include=ServiceRequest;performer.organization (Search)GET [baseURL]/ServiceRequest/subject=[id]&_revinclude=Task;focus (Search)No specific error codes for ServiceRequest.
The ServiceRequestReferralCoreSwe profile is a core profile on a higher level for when using FHIR ServiceRequests in the referral area in a Swedish context. It is not an implementation profile but has derived profiles which are implemented in API:s.
ServiceRequestSelfReferralSEVendorLite is a sub profile created to support a self-referral. The original profile was created and published by Svenska Industri Profiler, which is a common FHIR profile vendor collaboration.
ServiceRequestSelfReferralSEVendorLite is based on the FHIR resource ServiceRequest.
This profile is used to create a private demand for care. Usually this will be done through a patient app by the patient. ServiceRequestSelfReferralSEVendorLite is profiled for the Swedish market.
| Type | Description |
|---|---|
| Rule | The intended users of this API are patients. |
| Limitation | This API only supports the POST method. To retrieve referral requests, including self referrals, the profile ServiceRequestReferral is used. |
| Limitation | Not all codes in the chiefComplaint value set are supported in COSMIC. The supported codes are defined here. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.7.0 | 1.0.0 | 3.9.0 | June 2023 | Initial version, support for POST. |
| HTTP Method | Description |
|---|---|
| POST | Used to create a self referral. |
POST [baseURL]/ServiceRequest| Code | Description | Comment |
|---|---|---|
| 400 | Invalid/Unsupported Search parameters | |
| 422 | Profile validation error | |
| 501 | Not implemented | When the COSMIC version is lower than 3.9.0. |
The SlotFreeTimeSlots profile is a Cambio profile, with the intended use of reading time slots that are available for bookings.
The MustSupport-flag indicates which attributes are supported by Cambio, meaning that those can be returned as part of the slot.
| Type | Description |
|---|---|
| Rule | The start and end date range should never exceed one full day. |
| HTTP Method | Description |
|---|---|
| GET | Get free time slots based on search parameters. |
| Parameter | Mandatory | Format | Comment |
|---|---|---|---|
healthcareService |
string | Yes | Internal id |
organization |
string | Yes | HSA ID |
start |
date | Yes | Is used to define start and end of the date range to be searched for. Can be passed multiple times, use operators gt(greater than) and lt(less than) to define the range. Both gt and lt operators must be used, see query example. |
GET [baseURL]/Slot/_search?start=gt<start date>&start=lt<end date>&organization=<organization Id>&healthcareService=<healthcare service Id>SlotLiteSe is a profile based on the FHIR resource Slot.
SlotLiteSe may be used for getting slots that can be used for booking an appointment.
| Type | Description |
|---|---|
| Rule | The patient header 'Patient' must be included. |
| Rule | The start and end date range should never exceed one full day |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | May 2022 | Initial version, support for search. |
| Extension | Data type | Description |
|---|---|---|
| permittedPatientActions | Coding | Describes what actions the patient have permission for. Never mapped on HealthcareServiceLiteSe. Only available on Appointment. |
| HTTP Method | Description |
|---|---|
| GET | Used to search for slots based on a search parameter. |
| Parameter | Type | Mandatory | Comment |
|---|---|---|---|
start |
date | Yes | Is used to define start and end of the date range to be searched for. Can be passed multiple times, use operators gt(greater than) and lt(less than) to define the range. Both gt and lt operators must be used, see query example. |
healthcareFacility |
string | Yes | HSA ID |
healthcareService |
string | Yes | Internal Id |
_profile |
URL | No | |
appointmentId |
string | No | Internal Id |
Note: healthcareFacility, healthcareService and appointmentId are not standard search parameters and cannot be found in the profile.
GET [baseURL]/Slot/_search?start=gt<start date>&start=lt<end date>&healthcareFacility=<healthcare unit Id>&healthcareService=<Healthcare Service Id>&appointmentId=<appointment Id>
Slot:scheduleSlot:schedule.practitionerThe TaskReferral profile represents the task to be performed as a result of a referral request. This profile is based on the FHIR resource Task.
TaskReferral is intended to be used for communicating referral statuses and referral outputs, e.g. assessments and answers. The output section refers to composition resources which can be contained within the Task. For the intended use of Composition, refer to CompositionReferralClinicalInformation section.
The intended use for reading data with this API is in first hand that the API is applied for direct access and should not be used to transfer data between caregivers. If it should be used for "data copying" between care providers, patient consent must be handled outside the API.
| Type | Description |
|---|---|
| Rule | External user should not be someone else than the patient of which record the referral data belongs. E.g. A healthcare professional is not the intended user of the API. |
| Rule | The consumer of the API is responsible for making sure data retrieved is filtered in compliance with laws and regulations prior to presenting it to any end-users. |
| Rule | For reading referral information, the external system needs to be able to evaluate PDL. This means whether the information can be displayed for a healthcare professional with a specific assignment. PDL data needed (HSA care unit and HSA care provider) is retrieved by including the organization referenced from ServiceRequest.performer.PractitionerRoleLiteSe (PractitionerRoleLiteSe.OrganizationSEVendorLite). For more information, see supported Queries. |
| COS version | Profile version | Required COSMIC version | Date | Description |
|---|---|---|---|---|
| 3.0.0 | 1.0.0 | R8.3.05 | Mar 2021 | Initial version, support for GET. |
TaskReferral supports GET queries. It supports a _include operation which makes it possible to read both the referral request(ServiceRequest) and the included referenced referral documentation, answers and assessments (Composition).
| HTTP Method | Description |
|---|---|
| GET | Support for GET Task by specific Id, and also to search by subject. |
| Parameter | Format | Mandatory | Comment |
|---|---|---|---|
_profile |
string | No | |
focus |
reference | Yes |
GET [baseURL]/Task/focus= (Search)GET [baseURL]/Task/focus=[]&_include=[] (Search)The following _include parameters are supported:
forfocusownerowner.practitionerowner.organizationrequesterrequester.practitionerrequester.organizationTask:focus -
This will return all tasks which reference this ServiceRequest.
No specific error codes for Task, for common codes, refer to the Error Handling section.
The TaskRegisterPayment profile represents the task of registering a successful payment performed by a patient for their encounter.
This API and profile is used to register a patient's payment in COSMIC. The result of this API call being that the patient's encounter in COSMIC changes its payment status from 'unpaid' to 'paid'.
A limitation to this API is that it is only applicable for encounters that are scheduled by web appointments in COSMIC. Web appointments are appointments that patients can see in an app or on a website outside of COSMIC. The appointment becomes a web appointment through configuration done in COSMIC, see requirements below.
A web appointment must adhere to the following rules in COSMIC:
| Type | Description |
|---|---|
| Limitation | The referenced encounter must be scheduled by a web appointment (see definition under Intended use) in Cosmic. |
| Rule | If the encounter is free of charge, the input:paymentMethod code must be set to 'CC' due to limitations in Cosmic. |
| HTTP Method | Description |
|---|---|
| POST | Register a payment that has been successfully performed for a patient encounter. |
POST[baseURL]/TaskFHIR Vital Signs Profile
These define constraints on FHIR data types for systems conforming to this implementation guide.
| AppointmentEncounterClass |
Used for describing the contact type similar to encounter class. |
| AppointmentMessage |
This extension can be used for free text messages given when rebooking och cancelling an appointment. |
| AppointmentNavigationInstruction | |
| AppointmentPatientGivenPhoneNumber | |
| AppointmentPurposeForVisit | |
| AppointmentUrl | |
| AppointmentUrlLabel | |
| AppointmentUrlNotAvailableMessage | |
| CommonBusinessStatus | |
| CommonHsaHierarchy |
Intended UseThis extension is used to describe a unit's (Location or Organization) place in the Swedish HSA hierarchy. There are two important levels in the hierarchy:
All official healthcare units in Sweden will have a representation in the national HSA catalogue, and all will have a relationship to a parent HSA Vårdenhet (lower level) and/or HSA Vårdgivare (highest level). This can among other things be used to evaluate PDL (Patientdatalagen, eng Patient Data Law) rules. Current Use Cases
|
| CommonParticipant |
This extension identifies the participants involved in activities related to a Condition or other contexts. Currently, it only supports defining care units as participants and does not allow for specifying the type of involvement of those participants. |
| CommonPermittedPatientActions |
Use to describe what a patient is permitted to do in the area of booking, re-booking and cancellations. |
| CommonReadOnly |
Intended UseThis resource is used to indicate if a resource is read only. Current Use Cases
|
| CommonScheduleColor |
Use for color representation of a healthcare service and/or slot. Mainly for usability purposes. |
| CommonServiceProvider |
Organizational service provider for e.g an appointment, this could also be called Responsible unit for the service provided. |
| CommonSignDateTime |
Intended UseUsed to indicate the date and time a specific set of information was signed. Current Use Cases
|
| CommonSubProcedure |
Intended UseThis extension express the sub-procedure of a certain other Procedure or Condition. This enables building hierarchies of conditions and procedures or procedures and procedures relating to each other. For more information on profiles for Procedure and Condition, refer to ProcedureKVALite section and ConditionDiagnosisSe section. Current Use Cases
|
| ConditionChronic |
This extension indicates whether a diagnosis is chronic or not. |
| ConditionSubCondition |
Extension for indicating that a condition has a related sub-condition. This extension is referred from the ConditionDiagnosisSe profile. |
| ConditionTypeOfDiagnosis |
This extension indicates whether a diagnosis is a main or bi diagnosis. |
| CopyRecipientHealthcareUnit |
The healthcare unit that receives a copy of a healthcare related service (for example service request). |
| DeliveredOxygen | |
| EncounterArrivalRegistrationPossible | |
| EncounterDestinationArrivalTime |
Extension to describe the estimated or actual arrival time at a destination. |
| EncounterInformationToPatient | |
| EncounterPerformingUnit |
Identification of the organisational unit at which an encounter is performed. |
| EncounterRegisterPaymentPossible | |
| HospitalBedSituationEmergencySituation |
Current number of patients for each responsible unit at emergency units located in the hospital. |
| HospitalBedSituationLikelyAdmission |
Current number of patients whom are likely to be admitted to inpatient care from an emergency unit in the hospital. A patient is considered having a likely admission if they have a planned transfer of type: admission from emergency. |
| HospitalBedSituationSpecificPrognosis |
For a responsible unit, that has care units located in the hospital, the prognosis of number of patients and available beds for a specific date and time for those care units. |
| HospitalBedSituationTransferToOtherHospital |
Current number of patients whom are planned to be transferred from one hospital to another hospital. A patient is included in the count if they have a planned transfer of type: other hospital. |
| HumanNameMiddleName | |
| HypercapnicRespiratoryFailure | |
| InvoicePaymentMethodOption |
Please note that this extension is deprecated. |
| InvoiceRegisteredPaymentMethod | |
| PatientPopulationRegistrationCounty |
A code describing the county in wich patient is registered in. This comes from the Swedish's Tax Agency (Skatteverket). |
| PatientPopulationRegistrationMunicipality |
A code describing the municipality in wich patient is registered in. This comes from the Swedish's Tax Agency (Skatteverket). |
| PatientReferMeAs | |
| PayingUnit |
The paying unit for a healthcare related service (for example service request). |
| PpatientPpopulationRegistrationParish |
A code describing the parish in wich patient is registered in. This comes from the Swedish's Tax Agency (Skatteverket). |
| QuestionnaireAllowComment |
Extension to indicate if an item (in this case, a question) in a Questionnaire allows for a comment to be included when answered. |
| QuestionnaireResponseAnswerComment |
Extension to add comments to answers in QuestionnaireResponse. |
| QuestionnaireResponseUnsupportedAnswer | |
| Regularity | |
| SiteQualifier |
More precise administration site. To be used only when combined with Immunization.site.coding. For example if the site is 'upper arm' then site qualifier could be 'left'. |
| UnitBedSituationAbsences |
Statistics of the patients who are absent. |
| UnitBedSituationAtTechnicalUnit |
The number of patients, currently at each technical unit. |
| UnitBedSituationAvailableBedsPeriod |
An available bed is a bed with physical design, equipment and staffing that ensures patient safety and a good work environment. Available beds are the total number of available beds at a unit at any given point of time. The number of Available beds can vary over time and is defined by one or many schedules. Available beds will use the combinations of regular and temporary schedules and provide the number of available beds for the current period and next upcoming period. An available bed period is a cohesive time with a start-date-and-time and an end-date-and-time during which a specified number of available beds is defined. Different periods will not overlap, but gaps between periods can exist. |
| UnitBedSituationBedSituationComment |
Latest created comment describing the current bed situation at the care unit. |
| UnitBedSituationContagionComment |
Latest created comment to raise awareness regarding any known contagions at the unit. |
| UnitBedSituationFreeBeds |
The current number of free beds at the care unit. The number of free beds can be a negative number when the number of patients is greater than the number of available beds. |
| UnitBedSituationNumberOfPatients |
The number of patients currently at the care unit. |
| UnitBedSituationOutliers |
An outlier is a patient placed on ward that is not the serving unit of the medical responsible unit of the patient. A reason for outlying patients can be that the wards that serves a specific medical responsibility is full or crowded.E.g., A patient whose responsibility is with unit X is placed in ward Y. If ward Y is not a serving unit of unit X then; The patient is outlying from the unit X The patient is outlying to (inlier to) the ward Y. |
| UnitBedSituationProbableDischarge |
The number of patients whom are currently likely to be discharged from the care unit. |
| UnitBedSituationPrognosis |
A prognosis of free beds for a specified time into the future. |
| UnitBedSituationReadyForDischarge |
The number of patients ready to be discharged. |
| UnitBedSituationTransferable |
Statistics of the transferable patients. |
| invoice-paymentMethodOption(Version 2) |
These define sets of codes used by systems conforming to this implementation guide.
| ACVPU |
Value set defined from openEHR for sending ACVPU information. Codes published by Snomed CT is used. |
| AirPassage |
Value set for describing the air passage flow for a patient |
| Blood Pressure Body Position |
Body positions that the patient can have when having its blood pressure observed. |
| Blood Pressure Body Site |
Body sites for blood pressure observations |
| BodyHeightRelative |
Snomed CT codes for communicating the height of the biological father and mother |
| BodyWeightRelative |
Snomed CT codes for communicating the weight of the biological father and mother |
| BodyWeightUnits |
Subset of the ValueSet http://hl7.org/fhir/ValueSet/ucum-bodyweight for communicating body weight units. Code system is http://unitsofmeasure.org. |
| BoneAgeMeasuringMethod |
Snomed code value set for different Bone age measuring methods |
| CarePlanCategories |
Codes for different category of care plans |
| CarePlanCategory |
Codes for different category of care plans |
| CompositionContext |
Valueset for usage context in which a Questionnaire is used. For example "Doctor's visit". |
| CosmicUnitContactPointSystems |
The telecom types supported for COSMIC units |
| CosmicUnitFunctions |
The supported role codes for Locations units in COSMIC. This does not include role codes for e.g. bed locations or other such non-unit locations. |
| CostTypes |
Cost types available for invoices |
| DeliveredOxygen |
For communicating if a patient has received oxygen or not in addition to the saturation data for the patient.Codes from Snomed CT |
| Encounter Class Code | |
| Encounter Status Refined Value Set |
This value set contains a set of codes from the value set Encounter Status which are to be used when creating encounters in a Cambio system. |
| Encounter Types Refined Value Set |
This value set containsa set of codes from the value set Encounter Types which are to be used when creating encounters in a Cambio system. |
| Encounter Types Value Set |
Codes used to identify the outpatient encounter type. |
| Head Circumference RelativeValueSet |
Allowed values for Head circumference Relative profile |
| HeartRateBodySite |
Value set defined by openEHR archetype for Pulse/Heart beat element Body site. Using Snomed CT. |
| InvoiceBusinessStatus | |
| Laboratory Request Status (allowed) |
This value set includes the allowed status codes for laboratory requests. |
| Laboratory service Request Category Value Set |
Codes used to identify the category of the laboratory service request. |
| PainNumericRatingScale |
Cambio internal Value set to communicate the result of the numeric rating scale of pain. Value set of codes from internal cambio code system. |
| PaymentMethodOptions | |
| Permitted Patient Appointment Actions | |
| PubicHairStageValueSet |
Different values of Pubic Hair Stage and their SNOMED codes |
| Referral Documentation Types |
Codes for different types of referral documentation |
| ReferralBusinessStatus |
The business statuses of a referral |
| ReferralRequestTypes |
Codes for different types of referrals |
| Registered Payment Method | |
| Regularity |
Value set for describing the regularity of the pulse for a patient |
| RettsTriageLevel |
Value set to define RETTS standardized triage level when posting a triage for a patient. |
| TannerBoysGenitalDevelopmentStageValueSet |
Tanner Boys Genital Development Stage and their respective SNOMED codes |
| TannerGirlsBreastDevelopmentStageValueSet |
Value set of Tanner Girls Breast Development Stage and their SNOMED codes |
| TypeOfDiagnosis |
Valueset for specifying type of diagnosis (either main or bi). |
| VitalSignStatus |
A subset of the FHIR valueset observation status https://www.hl7.org/fhir/valueset-observation-status.html |
These define new code systems used by systems conforming to this implementation guide.
| CarePlanCategories |
Code system for different category of care plans |
| CarePlanCategory |
Code system for different category of care plans |
| CodeSystemReferralBusinessStatus |
The business statuses of a referral |
| CodeSystemReferralDocumentationTypes |
Code system for different documentation types in referral context |
| CodeSystemRettsTriageLevel |
Code system to define RETTS based priority levels when posting a triage for a patient. |
| CostTypes | |
| EncounterTypes |
Codes used to identify the outpatient encounter type. |
| Invoice Business Status Code System |
This CodeSystem defines the set of codes that can be used to represent the business status of an invoice. |
| ObservationStatus |
Codes providing the status of an observation. |
| PainNumericRatingScale |
Code system to define RETTS based priority levels when posting a triage for a patient. |
| Payment Method Types Code System |
This CodeSystem defines the set of codes that can be used to represent different payment methods. |
| Permitted Patient Appointment Actions Code System |
This CodeSystem defines the set of codes that can be used to represent actions that patients are permitted to take regarding their appointments. |
| ServiceRequestPriority |
Codes used to mark the service request priority in COSMIC. |
| UsageContextTypes |
Code system for usage contexts in which a specific questionnaire is used. |
These define transformations to convert between codes by systems conforming with this implementation guide.
| ACVPU to Snomed CT |
Maps Cosmic-specific ACVPU codes to SNOMED CT concepts. The ACVPU scale represents a rapid method of assessing a patient's level of consciousness. Example of where it is used: ObservationAcvpuLite |
| Air passage to SNOMED CT |
Maps Cosmic-specific air passage codes to SNOMED CT concepts. Example of where it is used: ObservationAirPassageLite |
| Body position to SNOMED CT |
Maps Cosmic-specific body position codes to SNOMED CT concepts. Body position represents the position the patient was in when their blood pressure was observed. Example of where it is used: ObservationBPComplex |
| Body site to SNOMED CT |
Maps Cosmic-specific body site codes to SNOMED CT concepts. The body site represent where on the body the blood pressure was observed. Example of where it is used: ObservationBPComplex |
| Care Plan Status to FHIR Status |
Maps Cosmic-specific care plan statuses to FHIR codes for care plan status. Example of where it is used: CarePlanSe |
| Clinical Procedure to SNOMED CT |
Maps Cosmic-specific clinical procedure cosed to corresponding SNOMED CT concepts. |
| Delivered Oxygen to SNOMED CT |
Maps Cosmic-specific codes for indicating if a patient has been given oxygen or not, to SNOMED CT concepts. Example of where it is used: ObservationInspiredOxygenLite |
| Invalidation Reasons to HL7 Terminology | |
| Observable Entity To SNOMED CT |
Maps Cosmic-specific observable entity codes to SNOMED CT concepts. |
| Patient Identifier Use to FHIR |
Maps Cosmic-specific codes for patient identifier use to FHIR codes for patient identifier use. |
| Referral Request Type to SNOMED CT |
Maps Cosmic-specific referral request types to SNOMED CT concepts. |
| Tanner Scale to SNOMED CT |
Maps Cosmic-specific Tanner Scale codes to SNOMED CT concepts. Examples of where it is used: |
| Unit Type to HL7 terminology |
Maps Cosmic-specific unit type codes to corresponding role codes in HL7 terminology. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| 234567 | ||||
| 25462 |
Example: Link a ConditionHealthIssueSe to the QuestionnaireResponseSeThe following is an example of a POST request where a ConditionHealthIssueSe is linked to a QuestionnaireResponse. The literal ID of the QuestionnaireResponseSe is sent in the path, and the literal ID of the ConditionHealthIssueSe is sent in the body. Example Request URL:
Example Response: The following is returned with the status OK/200 code in a success scenario:
|
|||
| 456 |
This example depicts the closing of an ambulance encounter. |
|||
| AppointmentBookingSe Example | ||||
| AppointmentCancellationSe Example | ||||
| AppointmentRebookingSe Example | ||||
| AppointmentSe Example | ||||
| Assessment |
Example of a QuestionnaireSe instance. |
|||
| CareplanCordinatedCareSe Example | ||||
| ClinicalImpressionTriageRetts Example |
An example of an ClinicalImpression |
|||
| ConditionHealthIssueSe Example | ||||
| ConsentPatientSealProfile Example | ||||
| DiagnosticReportMicrobiology Example | ||||
| DiagnosticReportRadiology Example | ||||
| EncounterLite V2 Example |
Example of an in-progress inpatient encounter at a given care unit. |
|||
| EncounterOutpatientReadSeExample |
An example of a planned outpatient encounter that will be performed via telephone. |
|||
| EncounterOutpatientWriteSeExample |
An example of a newly created ongoing outpatient encounter done via telephone. |
|||
| Example PractitionerSe |
An example instance of PractitionerSe with all relevant attributes. |
|||
| Example: Creating a Body Weight Observation |
Example: Creating a Body Weight Observation
Request
|
|||
| Example: Creating a Patient Generated Body Height Observation |
Example: Creating a Patient Generated Body Height ObservationThe following is an example of a POST request where a body height observation is created by the patient. For patient generated observations, it is required to also include an Organization (unit) in Observation.performer. Here, the organization is specified with HSA id. The date and time given for the body height is 2022-01-10, 15:33:48.583Z. Request
|
|||
| Example: Searching a Body Weight of the Patient's Relative Registrations by Specifying Required Code and the Patient ID |
Example: Searching a Body Weight of the Patient's Relative Registrations by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Father's body height. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Body Weight of the Patient's Relative Registrations by Specifying Required Code and the Patient ID |
Example: Searching a Body Weight of the Patient's Relative Registrations by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Father's body weight. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Blood Pressure Registrations by Specifying Required Profile & Including performer.organization |
Example: Searching a Patient's Blood Pressure Registrations by Specifying Required Profile & Including performer.organizationThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only blood pressure observations, the profile is specified in the query. Given date interval in the search is 2018-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Body Height Registrations by Specifying Required Profile |
Example: Searching a Patient's Body Height Registrations by Specifying Required ProfileThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only body height observations, the profile is specified in the query. Given date interval in the search is 2021-10-01T15:33:48.583Z to 2021-12-01T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Body Height Registrations by Specifying Required Profile & Including performer.organization |
Example: Searching a Patient's Body Height Registrations by Specifying Required Profile & Including performer.organizationThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only body height observations, the profile is specified in the query. Given date interval in the search is 2018-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Body Weight Registrations by Specifying Required Profile |
Example: Searching a Patient's Body Weight Registrations by Specifying Required ProfileThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only body weight observations, the profile is specified in the query. Given date interval in the search is 2021-10-01T15:33:48.583Z to 2021-12-01T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Body Weight Registrations by Specifying Required Profile & Including performer.organization |
Example: Searching a Patient's Body Weight Registrations by Specifying Required Profile & Including performer.organizationThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only body weight observations, the profile is specified in the query. Given date interval in the search is 2018-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Heart Rate Registrations by Specifying Required Profile & Including performer.organization |
Example: Searching a Patient's Heart Rate Registrations by Specifying Required Profile & Including performer.organizationThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only heart rate observations, the profile is specified in the query. Given date interval in the search is 2018-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Pain NRS Registrations by Specifying Required Profile |
Example: Searching a Patient's Pain NRS Registrations by Specifying Required ProfileThe following is an example of a GET request in which the search is based on patient ID and profile. Given date interval in the search is 2020-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, one Pain NRS observation is included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Pain NRS Registrations by Specifying Required Profile & Including performer.organization |
Example: Searching a Patient's Pain NRS Registrations by Specifying Required Profile & Including performer.organizationThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only pain NRS observations, the profile is specified in the query. Given date interval in the search is 2018-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Example: Searching a Patient's Respiratory Rate Registrations by Specifying Required Profile & Including performer.organization |
Example: Searching a Patient's Respiratory Rate Registrations by Specifying Required Profile & Including performer.organizationThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only respiratory rate observations, the profile is specified in the query. Given date interval in the search is 2018-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| HealthcareServiceLiteSe Example | ||||
| ImmunizationSeExample |
An example of a performed rabies vaccination for a patient in their right upper arm. |
|||
| InvalidateEncounterParametersExample |
An example of input parameters to the $invalidate operation performed on an outpatient encounter. |
|||
| InvoiceSeV2 Example | ||||
| LocationUnitSe Example | ||||
| ObservationAcvpuLite Example |
Example: Searching a Patient's ACVPU Registrations by Specifying Required Profile & Including performer.organizationThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only ACVPU observations, the profile is specified in the query. Given date interval in the search is 2018-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| ObservationAcvpuLiteExampleForONEWS | ||||
| ObservationAirPassageLite Example |
An example of an ObservationAirPassageLite |
|||
| ObservationArmSpanLite | ||||
| ObservationBPComplexExample |
An example payload for a POST operation. |
|||
| ObservationBPLite Example 1 |
An example payload for a POST operation or response to a GET operation. |
|||
| ObservationBPLite General Example |
An example of an ObservationBPLite |
|||
| ObservationBPLiteExampleForONEWS |
An example payload for a POST operation or response to a GET operation. |
|||
| ObservationBodyHeightLite General Example |
A general example of an ObservationBodyHeightLite |
|||
| ObservationBodyTemperatureLite Example 1 |
An example of an ObservationBodyTemperatureLite |
|||
| ObservationBodyTemperatureLite Example 2 |
An example of an ObservationBodyTemperatureLite |
|||
| ObservationBodyTemperatureLite Example 3 |
Example: Searching a Patient's Body Temperature Registrations by Specifying Required Profile & Including performer.organizationThe following is an example of a GET request in which the search is based on patient ID. To narrow the search to only body temperature observations, the profile is specified in the query. Given date interval in the search is 2018-11-20T15:33:48.583Z to 2022-12-20T15:33:48.583Z As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| ObservationBodyTemperatureLiteExampleForONEWS | ||||
| ObservationBodyWeightLite General Example |
An example of an ObservationBodyWeightLite |
|||
| ObservationBreastStageFemaleLite | ||||
| ObservationClinicalSimple Example |
An example of an ObservationClinicalSimple |
|||
| ObservationDateOfMenarcheLite | ||||
| ObservationFootLengthLite | ||||
| ObservationGenitalStageMaleLite | ||||
| ObservationHeadCircumferenceLite Example |
Example: Searching a Patient's Head Circumference Registrations by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of patient's head circumference. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| ObservationHeadCircumferenceRelative Example |
Example: Searching a Head Circumference of the Patient's Relative Registrations by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Father's head circumference. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| ObservationHeartRateLite Example 1 |
An example payload for a POST operation or response to a GET operation. |
|||
| ObservationHeartRateLite General Example |
An example of an ObservationHeartRateLite |
|||
| ObservationHeartRateLiteExampleForONEWS |
An example payload for a POST operation or response to a GET operation. |
|||
| ObservationInspiredOxygenLite Example |
An example of an ObservationInspiredOxygenLite |
|||
| ObservationLeftTesticularVolumeLite | ||||
| ObservationLengthOfGestationAtBirthLite | ||||
| ObservationMicrobiology Example |
An example of an ObservationMicrobiology |
|||
| ObservationMicrobiologyResistance Example |
An example of an ObservationMicrobiologyResistance |
|||
| ObservationNews2Lite |
An example payload for a POST operation or response to a GET operation. |
|||
| ObservationONEWS2Example |
An example ONEWS2 instance payload for a POST operation or response to a GET operation. |
|||
| ObservationOxygenSaturationLite Example |
An example of an ObservationOxygenSaturationLite |
|||
| ObservationOxygenSaturationLiteExampleForONEWS | ||||
| ObservationPainNrsLite General Example |
An example of an ObservationPainNrsLite |
|||
| ObservationPubicHairStageLite | ||||
| ObservationRadiology Example |
An example of an ObservationRadiology |
|||
| ObservationRespiratoryRateLite Example |
An example payload for a POST operation or response to a GET operation. |
|||
| ObservationRespiratoryRateLite General Example |
An example of an ObservationRespiratoryRateLite |
|||
| ObservationRespiratoryRateLiteExampleForONEWS |
An example payload for a POST operation or response to a GET operation. |
|||
| ObservationRightTesticularVolumeLite | ||||
| ObservationWaistCircumferenceLite | ||||
| OrganizationSEVendorLite Example | ||||
| PatientLiteSe Example | ||||
| PatientSe Example | ||||
| ProvenanceStatusSe Example | ||||
| QuestionnaireResponseSe Example | ||||
| QuestionnaireSeLite Example | ||||
| Searching a Patient's Waist Circumference Registrations by Specifying Required Code and the Patient ID |
Example: Searching a Patient's Waist Circumference Registrations by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of waist circumference. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Searching a Registration of Female Patient's Breast development stage by Specifying Required Code and the Patient ID |
Example: Searching a Registration of Female Patient's Breast development stage by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Breast development stage. Search Query
|
|||
| Searching a Registration of Gestational Age of the Patient by Specifying Required Code and the Patient ID |
Example: Searching a Registration of Gestational Age of the Patient by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Father's head circumference. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Searching a Registration of Patient's Bone Age by Specifying Required Code and the Patient ID |
Example: Searching a Registration of Patient's Date of Menarche by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Date of Menarche. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Searching a Registration of Patient's Bone Age by Specifying Required Code and the Patient ID |
Example: Searching a Registration of Patient's Bone Age by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Bone age. |
|||
| Searching a Registration of Patient's Foot Length by Specifying Required Code and the Patient ID |
Example: Searching a Registration of Patient's Foot Length by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Foot Length. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Searching a Registration of Patient's Left Testicular Volume by Specifying Required Code and the Patient ID |
Example: Searching a Registration of Patient's Left Testicular Volume by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Left testicular volume. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Searching a Registration of Patient's Pubic Hair Stage by Specifying Required Code and the Patient ID |
Example: Searching a Registration of Patient's Pubic Hair Stage by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Pubic Hair Stage. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Searching a Registration of Patient's Right Testicular Volume by Specifying Required Code and the Patient ID |
Example: Searching a Registration of Patient's Right Testicular Volume by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Right testicular volume. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| Searching a Registration of a Patient's Genital Stage by Specifying Required Code and the Patient ID |
Example: Searching a Registration of a Patient's Genital Stage by Specifying Required Code and the Patient IDThe following is an example of a GET request in which the search is based on patient ID and SNOMED CT code of Genital Stage. As a response, the Observations are included in a Bundle resource. Search Query
|
|||
| ServiceRequestLabAnalysis Example |
Example of a ServiceRequestLabAnalysis instance. |
|||
| ServiceRequestLabOrder Example |
Example of a ServiceRequestLabOrder instance. |
|||
| ServiceRequestMicrobiology Example | ||||
| ServiceRequestRadiology Example | ||||
| ServiceRequestReferral Example | ||||
| SlotLiteSe Example | ||||
| TaskReferral Example | ||||
| TaskRegisterPaymentExample |
An example of a credit card payment done by a patient for a specific encounter. |