Summary

This page provides a detailed guide to managing telemedicine packages within the eHealth Infrastructure. It explains how to create, version, and structure key FHIR resources—such as PlanDefinition, ActivityDefinition, Questionnaire, and Library—that define the components and workflows of telemedicine plans. The page also covers custom operations like $create-clone, semantic versioning, and strategies for organising and linking resources to support patient-specific care plans.

Content

1 Summary
2 Content
3 Versioning of Telemedicine Package Resources
- 3.1 Concepts
- 3.2 Custom operations
- 3.3 Validation rules
- 3.4 Semantic versioning
- 3.5 Deep clone
  - 3.5.1 Questionnaire
  - 3.5.2 ActivityDefinition
  - 3.5.3 PlanDefinition
4 Managing PlanDefinition
- 4.1 Creating and Updating a PlanDefinition
- 4.2 Finding “own” and other PlanDefinition Resources
5 Managing ActivityDefinition
- 5.1 Creating and Updating an ActivityDefinition
- 5.2 Associating an ActivityDefinition with Library Resource(s)
  - 5.2.1 Finding appropriate Library resource(s)
    - 5.2.1.1 Example useContexts
6 Managing Material for Clinicians and Citizens

A telemedicine package comprises PlanDefinition and ActivityDefinition resources and their use of Questionnaire and Library resources. These resources define what shall be performed as part of a telemedicine plan, what questionnaires to use and what rules, typically automated ones, to perform. While they function as definitions and templates not bound to specific Patient resources, they can be applied to form a Patient-specific CarePlan (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661042729 ).

Versioning of Telemedicine Package Resources

Concepts

Concept	Description

Concept	Description
Telemedicine Package Resource, Resource	PlanDefinition, ActivityDefinition, and Questionnaire Resources
Business version	The semantic version of a Resource following a major.minor format. Examples: 1.0, 1.1 and 2.0. A user decides whether to create a business version of a Resource as a minor or major business version. The new business version is calculated by the infrastructure and is specified in the `version` element. New Resources are assigned `version` 1.0
Business Identifier	Unique for each Resource, and hence for each business version and copy. Business Identifier is automatically assigned by the infrastructure and specified in the `identifier` element. It is a UUID with `system`: `urn:ietf:rfc:3986`
Base identifier	All business versions of a Resource share the same Base Identifier. It is automatically assigned by the infrastructure when a new Resource is created and also automatically copied to new business versions of the Resource. The Base Identifier is specified in the `ehealth-base` element. It is a UUID with `system`: `urn:ietf:rfc:3986`
Predecessor	Identifies the previous business version of the Resource. It is automatically set by the infrastructure and is specified in the `ehealth-predecessor` element. If a Resource is copied, the predecessor identifies the original Resource that was copied.
Base Environment	The environment where this Resource was created. Examples: exttest, preprod and prod. It is automatically set by the infrastructure in the `ehealth-base-environment` element. Resources can be exported and imported to a different environment. In that case, they retained their base environment value.
Custom operation: `$create-clone`	This is a custom operation available on each Telemedicine Package Resource. It is used to create minor and major business versions of an existing Resource. In addition, it can be used to create a copy of an existing Resource. The `$create-clone` operation automatically assigns `version`, `identifier`, `ehealth-base`, `ehealth-predecessor` and `ehealth-base-environment` depending on the specified operation. It is also possible to specify an entire tree of resources to copy or create new business versions for.

Custom operations

For the Questionnaire, use Questionnaire instance operation $create-clone (see https://ehealth.sundhed.dk/fhir/OperationDefinition-Questionnaire-i-create-clone.html ).

For ActivityDefinition, use ActivityDefinition instance operation $create-clone (see https://ehealth.sundhed.dk/fhir/OperationDefinition-ActivityDefinitionPlanDefinition-i-create-clone.html ).

For PlanDefinition, use the PlanDefinition instance operation $create-clone. (see https://ehealth.sundhed.dk/fhir/OperationDefinition-Questionnaire-i-create-clone.html and https://ehealth.sundhed.dk/fhir/OperationDefinition-ActivityDefinitionPlanDefinition-i-create-clone.html )

Validation rules

When updating resources: base, business identifier, predecessor, base environment, and version must be unchanged
New business versions require that the user has a modifier-role: owner or co-author for the resource.
Only one Business version with a status draft can exist for a given Base identifier.
Read/search/create privileges are required for the resource types affected by $create-clone

Semantic versioning

New business version values are determined by the service (server-side) based on the currently highest existing business version for that Base, regardless of the business version of the Resource in which $create-clone is invoked.

A new minor version is determined as an increment of the minor version of the currently highest business version by 1. A new Major version is determined as an increment of the major version of the currently highest business version by 1, setting minor to 0.

Existing Versions of a Base	Highest Existing Version	New Minor Version	New Major Version

Existing Versions of a Base	Highest Existing Version	New Minor Version	New Major Version
1.0	1.0	1.1	2.0
1.9	1.9	1.10	2.0
1.1 + 2.0	2.0	2.1	3.0
1.0 + 2.0 + 2.1	2.1	2.2	3.0

Deep clone

$create-clone has two modes: Default and deep-clone. Deep-clone is a batch operation that makes it possible to create new versions or copy an entire tree of resources in a single operation.

Deep-clone functionality can be enabled by setting the Default-clone-behavior parameter to false and specifying a list of references to include in the operation in the Deep-clone-references parameter.

Questionnaire

The default behaviour for the Questionnaire is to create a new business version/copy of the Questionnaire and no other resources. $create-clone on Questionnaire does not have a deep-clone mode.

ActivityDefinition

The default behaviour for ActivityDefinition is to create a new business version/copy of the ActivityDefinition and no other resources.

In Deep-clone mode, it is possible to include DocumentReference and Questionnaire resources in the operation.

PlanDefinition

The default behaviour when creating a new business version of a PlanDefinition is to create a new business version of the PlanDefinition and no other resources.

The default behaviour when creating a new copy of a PlanDefinition is to create a new copy of the PlanDefinition, any sub-PlanDefinitions, and any ActivityDefinitions referenced from the PlanDefinition or sub-PlanDefinitions.

In Deep-clone mode, it is possible to specify which PlanDefinition, ActivityDefinition, DocumentReference and Questionnaire resources to include in the operation.

Managing PlanDefinition

See PlanDefinition for further introduction to its use and elements.

A Telemedicine package is defined by a PlanDefinition where the activities to be performed are stated as either sub-plans (PlanDefinition) or ActivityDefinition.

Creating and Updating a PlanDefinition

Later, finding appropriate PlanDefinition resources depends on the quality and granularity with which the PlanDefinition elements are populated when created/updated. Consequently, effort should be made to ensure these elements are populated.efforts

Filtering applied to finding an appropriate PlanDefinition could involve the following elements of PlanDefinition:

useContext
ehealth-intendedAudience
ehealth-recommendation
status
jurisdiction

Possibly, the following elements (and others) could be used as well:

title
version
publisher
identifier

Observe that the Organisation in the Security Token Context is referenced in PlanDefinition.ehealth-modifier-role. If this is not ensured, the user’s organization will not be able to modify the PlanDefinition. See organisationPlanDefinition for details.

The following diagram describes the status transition flow for a PlanDefinition resource which is supported by the plan definition component within the Common Workplace. The same rules are enforced by the FUT infrastructure, with the exception that a new PlanDefinition resource can be created with any status:

Releasing a PlanDefinition

Once a PlanDefinition contains the desired arrangement of ActivityDefinition resources and possibly sub-plans (PlanDefinition), it can be finalised and thereby made eligible for use in patient-specific CarePlan resources. Finalizing is performed by setting the PlanDefinition Finalisingstatus to value active through a PlanDefinition Update. The prerequisite is that the referenced ActivityDefinition and, in turn, Questionnaire all have the status set to active.

The PlanDefinition cannot be changed once having status is set to active, except for retiring it by changing the status to retired.

Retiring a PlanDefinition

Retire a PlanDefinition by setting the PlanDefinition status to value retired through a PlanDefinition Update.

Retiring a PlanDefinition does not impact current or past use in CarePlan resources referencing it. It signals that further use of new CarePlan resources should not happen.

Finding appropriate ActivityDefinition resources to add

While a PlanDefinition could be intended for Chronic Obstructive Pulmonary Disease (COPD) (defined through PlanDefinition.useContext), there is no restriction on what kind of ActivityDefinition it can be comprised of. Typically, the interesting ActivityDefinition would be either generic or intended for COPD as well. Also, there is no inherent requirement that comprising ActivityDefinition resources shall have the same maintaining Organisation as the PlanDefinition itself.

Consideration of the lifecycles of PlanDefinition and ActivityDefinition should be made, as active status is a prerequisite to actual use of the PlanDefinition (and referenced ActivityDefinition). See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027 for details.

Controlling the sequence of and dependencies between ActivityDefinition resources

Dependencies between ActivityDefinition resources are defined on PlanDefinition resources. One use case for this is to establish Situation Quality and Usage Quality before submitting Observations to the Infrastructure.

The example below shows how to do this.

PlanDefinition elements:

action - this array of actions points to the three steps (defined by ActivityDefinition resources) included in the PlanDefinition.
action.id the current action’s id, which is unique within the PlanDefintion.
action.definition references the particular ActivityDefinition
action.output defines the output that is expected when performing the action. In the example below, the first two actions output Situation and Usage qualities, respectively.
action.relatedAction.actionId, the action id of the other action to which the current action has a relationship
action.relatedAction.relationship states the relationship between the current and the other action
action.input states what is input to the action. For the last action - Oxygen Saturation Measuring - this element defines the input that is expected from the previous actions. In this case Situation and Usage qualities.

In the example below, this is used to make sure that the calculations of Situation Quality and Usage Quality are performed before performing the Oxygen Saturation Measuring.

An additional use of relatedAction is to group activities such that a PlanDefinition could contain multiple measurements with multiple calculations of Situation Quality and Usage Quality, each grouped such that each measurement activity is related to its calculations.

{
    "resourceType": "PlanDefinition",
    "meta": {
        "profile": [
            "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-plandefinition"
        ]
    },
    "extension": [
        {
            "url": "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-recommendation",
            "valueCodeableConcept": {
                "coding": [
                    {
                        "system": "http://ehealth.sundhed.dk/cs/plandefinition-recommendation",
                        "code": "Planned"
                    }
                ]
            }
        },
        {
            "url": "http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-modifier-role",
            "extension": [
                {
                    "url": "reference",
                    "valueReference": {
                        "reference": "http://exttest.organization.ehealth.sundhed.dk/fhir/Organization/58"
                    }
                },
                {
                    "url": "role",
                    "valueCodeableConcept": {
                        "coding": [
                            {
                                "system": "http://ehealth.sundhed.dk/cs/modifier-role",
                                "code": "owner"
                            }
                        ]
                    }
                }
            ]
        }
    ],
    "version": "1.0.0",
    "name": "copd-demo-plandefinition",
    "title": "COPD Plan Definition with ActivityDefinition dependencies",
    "status": "active",
    "topic": [
        {
            "coding": [
                {
                    "system": "http://hl7.org/fhir/definition-topic",
                    "code": "assessment",
                    "display": "Assessment"
                }
            ]
        }
    ],
    "action": [
        {
            "id": "oxy-measurement-situation-quality-assessment",
            "title": "Perform Oxygen Saturation Measuring readiness test for Situation Quality",
            "definition": {
                "reference": "http://exttest.plan.ehealth.sundhed.dk/fhir/ActivityDefinition/55"
            },
            "output": [
                {
                    "type": "Coding",
                    "codeFilter":[
                    {
                        "path" :".",
                        "valueSetString": "http://ehealth.sundhed.dk/vs/situation-quality"
                    }]
                }
            ],
            "relatedAction": [
                {
                    "actionId": "oxy-measurement",
                    "relationship": "before"
                }
            ]
        },
        {
            "id": "oxy-measurement-usage-quality-assessment",
            "title": "Perform Oxygen Saturation Measuring readiness test for Usage Quality",
            "definition": {
                "reference": "http://exttest.plan.ehealth.sundhed.dk/fhir/ActivityDefinition/55"
            },
            "output": [
                {
                    "type": "Coding",
                    "codeFilter":[
                    {
                        "path" :".",
                        "valueSetString": "http://ehealth.sundhed.dk/vs/usage-quality"
                    }]
                }
            ],
            "relatedAction": [
                {
                    "actionId": "oxy-measurement",
                    "relationship": "before"
                }
            ]
        },
        {
            "id": "oxy-measurement",
            "title": "Perform Oxygen Saturation Measuring",
            "definition": {
                "reference": "http://exttest.plan.ehealth.sundhed.dk/fhir/ActivityDefinition/54"
            },
            "relatedAction": [
                {
                    "actionId": "oxy-measurement-situation-quality-assessment",
                    "relationship": "after"
                },
                {
                    "actionId": "oxy-measurement-usage-quality-assessment",
                    "relationship": "after"
                }
            ],
            "input": [
                {
                    "type": "Coding",
                    "codeFilter":[
                    {
                        "path" :".",
                        "valueSetString": "http://ehealth.sundhed.dk/vs/situation-quality"
                    }]
                },
                {
                    "type": "Coding",
                    "codeFilter":[
                    {
                        "path" :".",
                        "valueSetString": "http://ehealth.sundhed.dk/vs/usage-quality"
                    }]
                }
            ]
        }
    ]
}
}

Setting up one or more actions as triggers for an action in PlanDefinition

By adding an actionTrigger to an action, it is possible to trigger said action based on other actions in the PlanDefinition. Beneath is a simplified example of a PlanDefinition with 3 actions where the third action, action[2], is triggered by the other two actions. The “trigger for” depicted below is logically provided for explanation only, that is, it is not a modelled relation.

To set up the conditional triggering of an action, the first step is to add the actionTrigger to the action intended to be triggered. The actionTrigger must then be set up with the following parameters:

actionTrigger
- triggerCondition contains a list of the triggerConditions needed to be fulfilled for the actionTrigger.action (for instance, activation) to be performed for the ActivityDefinition where the actionTrigger is defined (the virtual "trigger for" in the figure above). At least one triggerCondition is needed, but the list can contain several triggerConditions. Each triggerCondition must contain the following parameters:
  - actionID contains the actionID of an action in the same PlanDefinition, which is a triggering action.
  - count determines the number of measurements that have to be submitted to the ActivityDefinition before the triggerCondition is complete.
- triggerBehavior can be set to either “all“ or “any”. This specifies whether all or just any one of the triggerConditions must be completed before the action is triggered.
- offset is an optional parameter; it controls the offset applied to the timing bounds of the activated action.
- action specifies what action should be performed when the triggerCondition is triggered. For now, the only possible action is activation, that is, a change of status from “on-hold“ to “active“.

Action trigger is supported for non-group actions only. A group action in PlanDefinition.action has sub-actions (in the recursive construct PlanDefinition.action.action) while a non-group action does not. This applies to both the “trigger for” action and the triggering action(s).

The eHealth application used for creating PlanDefinition (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2063892483/eHealth+Applications#Clinical-Administration-Application-(Danish%3A-KAM-for-Klinisk-administrativ-modul)) possibly stores actionTrigger(s) on group actions as well but only as a convenience and indication that actionTriggers should be defined for all the sub-actions. The application ensures that actionTriggers are indeed defined on non-group sub-actions when this is the case.

Finding “own” and other PlanDefinition Resources

Managing a set of PlanDefinitions can be performed on behalf of own Organization or on behalf of others. In any case, finding such PlanDefinition resources can be performed by PlanDefinition Search with ehealth-modifier-role as a search parameter.

Whether to add further search parameters (or do post-search filtering) depends on the use case. The elements mentioned above would constitute candidate search parameters for this filtering.

Managing ActivityDefinition

See ActivityDefinition for further introduction to its use and elements.

Creating and Updating an ActivityDefinition

Later, finding appropriate ActivityDefinition resources to include in a PlanDefinition depends on the quality and granularity with which ActivityDefinition elements are populated when created/updated. Consequently, efforts should be made to ensure these elements are populated.

Filtering applied to finding an appropriate ActivityDefinition could involve the following elements of ActivityDefinition:

useContext
ehealth-intendedAudience
ehealth-recommendation
code
status
jurisdiction

Possibly, the following elements (and others) could be used as well:

title
version
publisher
identifier

Observe that the Organization in the Security Token Context is referenced in ActivityDefinition.ehealth-modifier-role. If this is not ensured, the user’s organization will not be able to modify the ActivityDefinition. See ActivityDefinition for details.

Defining measurement ranges

Please refer to the description of measurement ranges for details on how to define adjacent and possibly (but not typically) overlapping measurement ranges.

Measurement ranges are defined similarly to how they are defined for Patient-specific ServiceRequest described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1662025748 , except that they are added to ActivityDefinition.ehealth-referenceRange and not ServiceRequest.ehealth-referenceRange. When defined on ActivityDefinition, the measurement ranges can be considered as default ranges suitable in general. Once a PlanDefinition and its ActivityDefinition resources and their measurement ranges are applied to a particular Patient, the default measurement ranges are copied to the resulting CarePlan and its ServiceRequest. It is expected that Patient-specific adjustment of the measurement ranges is at least considered at this point.

Setting the document registration approval policy

The document registering approval policy set in ActivityDefinition.ehealth-sharingApprovalPolicy controls the default behaviour concerning approving submitted measurements for registering in the national document-sharing infrastructure. With the approval policy set to manual, a clinician must manually approve each submitted measurement. With the approval policy set to automatic, the eHealth Infrastructure automatically creates the approval.

The ActivityDefinition.ehealth-sharingApprovalPolicy is copied to a ServiceRequest as the initial value upon $apply where it can subsequently be adjusted.

Approval for document registration is not the only prerequisite for document registration to happen. See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2698903576 .

Creating an ActivityDefinition for Answering a Questionnaire

The table below shows an excerpt of elements in ActivityDefinition to specify an activity for answering a Questionnaire.

ActivityDefinition Element	Value	Description

ActivityDefinition Element

Value

Description

code

code=273586006

system=http://snomed.info/sct

The master questionnaire implicitly answers a questionnaire.

relatedArtifact.type

composed-of

relatedArtifact.resource

Reference to the Questionnaire Resource

Associating an ActivityDefinition with Library Resource(s)

One or more Library resource references can be added to ActivityDefinition.library. Their use depends on the Library type:

Library type set to logic-library is intended for calculation type rules, that is, direct call of $evaluate from Solutions
Library type set to automated-processing is for automated processing occurring upon submission of measurement(s).

In case no Library has been added to the ActivityDefinition.library, the Fallback Library is used in automated processing. The Fallback Library can be added explicitly, but this is not the intended use.

Finding appropriate Library resource(s)

Appropriate Library resources to consider for adding to an ActivityDefinition will differ depending on the use case. The relevant Library elements could be:

useContext (see the examples below)
- for the match against a Condition, say COPD, by condition code
- for a match against an Activity Code (likely from ActivityDefinition.code)
- for a match against what Activity Code to support, say a BMI measurement
ehealth-intendedAudience
ehealth-recommendation
type
status
jurisdiction
title
usage
relatedArtifact.resource, which could reference a Questionnaire with relatedArtifact.type set to depends-on

A Library that requires a QuestionnaireResponse as input can indicate the corresponding Questionnaire as a dependency. Having set up an ActivityDefinition (for answering a Questionnaire) that references the Questionnaire, the Library.relatedArtifact.resource can then be used as a filter to find which Library resources reference the Questionnaire. A single Library can work with several Questionnaire resources this way. The list of Questionnaire resources referenced through relatedArtifact should be interpreted as alternatives, not that all dependencies must be fulfilled.

Example useContexts

"useContext": [ {
  "code": {
    "system": "http://hl7.org/fhir/usage-context-type",
    "code": "focus"
  },
  "valueCodeableConcept": {
    "coding": [ {
      "system": "urn:oid:1.2.208.176.2.4",
      "code": "DJ44",
      "display": "Kronisk obstruktiv lungesygdom"
    } ]
  }
}

"useContext": [ {
    "code": {
      "system": "http://ehealth.sundhed.dk/cs/ehealth-usage-context-type",
      "code": "activity"
    },
    "valueCodeableConcept": {
      "coding": [ {
        "system": "urn:oid:1.2.208.176.2.1",
        "code": "NPU03794",
        "display": "Pt—Legeme; højde = ? m"
      } ]
    }
  }, {
    "code": {
      "system": "http://ehealth.sundhed.dk/cs/ehealth-usage-context-type",
      "code": "activity"
    },
    "valueCodeableConcept": {
      "coding": [ {
        "system": "urn:oid:1.2.208.176.2.1",
        "code": "NPU03804",
        "display": "Legeme vægt; Pt"
      } ]
    }
  }, {
    "code": {
      "system": "http://ehealth.sundhed.dk/cs/ehealth-usage-context-type",
      "code": "activity"
    },
    "valueCodeableConcept": {
      "coding": [ {
        "system": "urn:oid:1.2.208.176.2.1",
        "code": "NPU27281",
        "display": "Pt—Legeme; massekoefficient(masse/kvadreret højde) = ? kg/m²"
      } ]
    }
  }, {
    "code": {
      "system": "http://ehealth.sundhed.dk/cs/ehealth-usage-context-type",
      "code": "supports"
    },
    "valueCodeableConcept": {
      "coding": [ {
        "system": "urn:oid:1.2.208.176.2.1",
        "code": "NPU27281",
        "display": "Pt—Legeme; massekoefficient(masse/kvadreret højde) = ? kg/m²"
      } ]
    }
  } ],

Managing Material for Clinicians and Citizens

Through the DocumentReference resource available on the Plan Service, it is possible to provide material such as information material, instructions or other descriptions for use by clinicians and/or citizens in a variety of formats including PDF, XML and video. Additional details about the material are described through elements of DocumentReference while the material itself is in the element DocumentReference.content.attachment.data.

The size of the material should not exceed 10MB.

Once created as a DocumentReference, it can be linked from, say, PlanDefinition through the PlanDefinition.relatedArtifact.resource or, if about a particular activity in the PlanDefinition, through ActivityDefinition.relatedArtifact.resource.

Managing Telemedicine Packages