Managing Telemedicine Packages
- 1 Versioning of Telemedicine Package Resources
- 1.1 Concepts
- 1.2 Custom operations
- 1.3 Validation rules
- 1.4 Semantic versioning
- 1.5 Deep clone
- 1.5.1 Questionnaire
- 1.5.2 ActivityDefinition
- 1.5.3 PlanDefinition
- 2 Managing PlanDefinition
- 3 Managing ActivityDefinition
- 4 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 Preparing, Starting and Maintaining Episodes of Care and Care Plans ).
Versioning of Telemedicine Package Resources
Concepts
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 |
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 |
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 |
Predecessor | Identifies the previous business version of the Resource. It is automatically set by the infrastructure and is specified in the |
Base Environment | The environment where this Resource was created. Examples: exttest, preprod and prod. It is automatically set by the infrastructure in the |
Custom operation: | 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 |
Custom operations
For 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 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 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 |
---|---|---|---|
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.
Filtering applied to finding 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 Organization 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 PlanDefinition 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 finalized and thereby made eligible for use in patient-specific CarePlan resources. Finalizing is performed by setting the PlanDefinition status
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
.
Retiring a PlanDefinition
Retire a PlanDefinition by setting the PlanDefinition status
to value retired
through a PlanDefinition Update.
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 Organization as the PlanDefinition itself.
Controlling 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 PlanDefintionaction.definition
references the particular ActivityDefinitionaction.output
defines the output that is expected when performing the action. In the example below the two first actions output Situation and Usage qualities, respectively.action.relatedAction.actionId
the action id of the other action to which the current has a relationshipaction.relatedAction.relationship
states the relationship between the current and the other actionaction.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.
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 theactionTrigger.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 having 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“.
Finding “own” and other PlanDefinition Resources
Managing a set of PlanDefinition can be performed on behalf of own Organization or 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 alternatively, do post-search filtering) depends on the use case. The elements mentioned above would constitute candidate search parameters for this filtering.
Adding a Reference to a Device Package
In the Service, Support & Logistics Domain, there is an SSL Device Package (See Create a Package) concept comprising a set of devices and business services (for instance, training). An association between a PlanDefinition and an SSL Device Package can be made through:
PlanDefinition.relatedArtifact
containing a RelatedArtifact with:type
set todepends-on
display
set toUdstyrspakke
(Danish for Device Package)document.title
set to<name of SSL Device Package>
, for instance,KOL udstyrspakke
(Danish forCOPD Device Package
)document.url
set to the SSL Device Package resource location, for instance,https://ssl-catalogue.ehealth.sundhed.dk/v1/package/694e363e-88c3-458a-95b1-d3bf4978de81
Managing ActivityDefinition
Creating and Updating an ActivityDefinition
Defining measurement ranges
Measurement ranges are defined similarly to how they are defined for Patient-specific ServiceRequest described in Creating and Maintaining Measurement Ranges , 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 registering 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.
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 |
---|---|---|
|
| The master questionnaire, implicitly answers a questionnaire. |
|
|
|
| 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 tologic-library
is intended for calculation type rules, that is, direct call of $evaluate from SolutionsLibrary
type
set toautomated-processing
is for automated processing occurring upon submission of measurement(s).
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 match against an Activity Code (likely from
ActivityDefinition.code
)for 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 withrelatedArtifact.type
set todepends-on
Example useContexts
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 element DocumentReference.content.attachment.data
.
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
.