Versions Compared

Old Version 37

changes.mady.by.user John Schneider

Saved on

compared with

New Version Current

changes.mady.by.user Erik Nielsen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Over the lifecycle of a CarePlan, its status might change. Adjustment of CarePlan.status can be performed through CarePlan Update by:

...

Info

Enforced constraints on the duration of scheduled status with value ‘on-hold’.

When setting scheduled status changes it is automatically enforced how long the CarePlan can be planned as paused. This is done to prevent patient plans from being forgotten in a paused state.

When setting CarePlan.ehealth-statusschedule:

  • If no further status changes are planned by the user, then the infrastructure will automatically insert a planned change back to ‘active’ 7 days after the start of ‘on-hold’

  • Maximum The maximum duration of a planned ‘on-hold’ status is 30 days.

Info

CarePlan automatically maintains a status history CarePlan.statushistory:

  • The status history is maintained as a list of ehealth-statusHistory objects each containing:

    • A status.

    • The Period of time period the status was set.

  • The history is automatically updated when the status is (regardless of whether the status is set manually or is a scheduled change):

    • A new entry is added with the new status and an open-ended period that started at the time of the status change.

    • The Period.end in the entry for the previous status is updated to be the same as the start of the new entry.

      • One should consider the period to be exclusive-end to avoid confusion as the Period.end of one historic status and the Period.start of the next have the same timestamp.

...

Over the lifecycle of a CarePlan, the set of CareTeam involved might change. Adjustment of CareTeam involved can be performed in a number of several ways:

Note

CareTeam Handover and Unhandled Tasks

When adjusting the involved CareTeams, consideration should be made as to the handling of Task resources pertaining to about the CarePlan, its measurements or other resources related to the CarePlan. For employees, being part of a CareTeam involved in the CarePlan (and/or EpisodeOfCare) is a prerequisite to accessing the CarePlan, related measurements and so forth. Access to Task on the other hand is governed by being identified in the Task explicitly. Therefore, hand over handover from one set of CareTeam to another could entail:

  • A period where both sets of CareTeam are involved in the CarePlan. In this period, both sets of CareTeam will be able to access CarePlan, measurements and so on as well as the related Task resources. The set of CareTeam parting involvement should handle Task resources created prior to before the period.

  • Adjusting the CareTeam(s) designated as Task.taskResponsible on for existing Task resources to include the set of CareTeam joining the CarePlan.

...

  • Sharing policy in ServiceRequest.ehealth-sharingPolicy

  • Sharing Approval Policy in ServiceRequest.ehealth-sharingApprovalPolicy

  • Reuse criteria in ServiceRequest.ehealth-reuseCriteria

...

  • The CareTeam(s) involved in daily monitoring etc. in ServiceRequest.careTeam

  • Measurement ranges in ServiceRequest.ehealth-referenceRange

  • Any reference value needed for triaging based on relative measurement range(s)

Setting the ServiceRequest

...

Sharing Approval Policy

The measurement regime Sharing Approval Policy of a ServiceRequest expresses when the activity described in the ServiceRequest is supposed to take place. The measurement regime whether the approval for registering documents is automated or done manually. It is defined in ServiceRequest.occurrence[x] by use of one of the alternatives:

...

.ehealth-sharingApprovalPolicy.

This extension is Optional. If set, it can have one of two values:

  • automatic - used when the activity should be performed at a specific point in time, that is date and time.occurrencePeriod approval of registering documents is wanted to be done automatically.

  • manual - used when the activity approval of registering documents should be performed once during a period of time. The period may be open, that is, without the period end being specified.

  • occurrenceTiming - used when the activity should be performed in a recurring manner, for instance, each week or at specific days or times of day.

The initial measurement regime in ServiceRequest.occurrence[x] is a copy from the PlanDefinition/ActivityDefintion made at the time of creation (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027/Creating+Care+Plans#Applying-the-PlanDefinition) and typically, it contains no starting date/time.

Info

The initial measurement regime can express “at any time” also known as ad-hoc by means of a Timing. When no additional constraints are set (for instance elements count and possibly countMax), “at any time” can be an empty Timing construct. To prevent removal during persisting, Timing.id may contain a random value.

...

  • done manually.

The initial ServiceRequest.ehealth-sharingApprovalPolicy is a copy from the ActivityDefinition, made at the time of creation.

The sharing Approval Policy is set using a conceptMap

The ConceptMap http://ehealth.sundhed.dk/ConceptMap/activitydefinition-code-to-perform-sharing is used to determine if the Sharing Approval Policy should be set based on the ServiceRequests code: http://ehealth.sundhed.dk/vs/activitydefinition-code

...

The column “Activitydefinition-code-to-perform-sharing” is used to decide whether the Sharing Approval Policy should be set for the given activitydefinition code, by use of the ConceptMap.

Setting the ServiceRequest Measurement Regime

The measurement regime of a ServiceRequest expresses when the activity described in the ServiceRequest is supposed to take place. The measurement regime is defined in ServiceRequest.occurrence[x] by use of one of the alternatives:

  • occurrenceDateTime - used when the activity should be performed at a specific point in time, that is date and time.

  • occurrencePeriod - used when the activity should be performed once during a period. The period may be open, that is, without the period end being specified.

  • occurrenceTiming - used when the activity should be performed in a recurring manner, for instance, each week or at specific days or times of day.

The initial measurement regime in ServiceRequest.occurrence[x] is a copy from the PlanDefinition/ActivityDefintion made at the time of creation (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/

...

1661141027/

...

Creating+Care+

...

A Plans#Applying-the-PlanDefinition) and typically, it contains no starting date/time is required when ServiceRequest.status is all but draft, revoked, or entered-in-error. The starting date/time can be provided as:

  • ServiceRequest.occurrenceDateTime - here the starting date/time is also the ending date/time.

  • ServiceRequest.occurrencePeriod.start

  • ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start

Timing expression copied from PlanDefinition/ActivityDefinition created in KAM

If recurring timing expression is copied from PlanDefinition/ActivityDefinition created in KAM the following transformation is needed for the infrastructure to resolve the timing:

For periodUnit: WK and period greater than 1.

...

If PlanDefinition.action[].timingTiming.repeat.periodUnit is “WK” (Week) and PlanDefinition.action[].timingTiming.repeat.period is greater than 1. The following changes are needed for the expression to be resolvable in the infrastructure:

dayOfWeek

...

.

Info

The initial measurement regime can express “at any time” also known as ad-hoc using a Timing. When no additional constraints are set (for instance elements count and possibly countMax), “at any time” can be an empty Timing construct. To prevent removal during persisting, Timing.id may contain a random value.

Note

It is expected that a Telemedicine Solution sets the hours part of the measurement regime starting date/time to Timing.timeOfDay in case of a frequency-based Timing (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661665301/Adhering+to+Care+Plans+and+Measurement+Regimes#When-an-Activity-is-Supposed-to-Happen---The-Notion-of-Resolved-Timing) that has Timing.timeOfDay.

Expand
title🛈 Expandable section for status change requirements prior release FUT-I 2024.4

A starting date/time is required when ServiceRequest.status is all but draft, revoked, or entered-in-error. The starting date/time can be provided as:

  • ServiceRequest.occurrenceDateTime - here the starting date/time is also the ending date/time.

  • ServiceRequest.occurrencePeriod.start

  • ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start

...

The value in dayOfWeek must be removed from ServiceRequest.occurrenceTiming.repeat.dayOfWeek.

...

timeOfDay

  • timeOfDay is ignored for frequency-based timing but should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start

  • For clarity it is advised to remove the value in timeOfDay as it is not used for frequency-based timing.

boundsDuration

...

...

Expand
title🛈 Expandable section for status change requirements after release FUT-I 2024.4

  • A valid occurrence, with a starting date/time is required when ServiceRequest.status is all but draft, revoked, or entered-in-error. The starting date/time can be provided as:

    • ServiceRequest.occurrenceDateTime - here the starting date/time is also the ending date/time.

    • ServiceRequest.occurrencePeriod.start

    • ServiceRequest.occurrenceTiming.repeat.boundsPeriod.

...

boundsDuration must be removed

Example

Expression from PlanDefinition.action[].timingTiming.repeat created in KAM. (Intention from KAM: Every second Monday at 10 AM, for 2 months)

Code Block
languagejson
"repeat": {
  "frequency": 1,
  "period": 2,
  "periodUnit": "wk",
  "dayOfWeek": [ "mon" ],
  "timeOfDay": [ "10:00:00" ],
  "boundsDuration": {
    "unit": "mo",
    "value": "2"
  }
}

Must be transformed to:

Code Block
languagejson
"repeat": {
  "frequency": 1,
  "period": 2,
  "periodUnit": "wk",
  "boundsPeriod": {
    "start": "2023-09-04T10:00:00.000+02:00" <-- Starting from a Monday at 10 AM
    "end": "2023-11-04T10:00:00.000+02:00" <-- ending after 2 months
  }
}

For periodUnit: other than WK(weekly)

...

timeOfDay

...

    • start

See validation requirements applied to ServiceRequest.occurrence[x] on https://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-servicerequest.html

Timing expression copied from PlanDefinition/ActivityDefinition created in KAM

If recurring timing expression is copied from PlanDefinition/ActivityDefinition created in KAM the following transformation is needed for the infrastructure to resolve the timing:

For periodUnit wk (weekly)

...

If PlanDefinition.action[].timingTiming.repeat.periodUnit is wk (Week), apart from ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start being mandatory, the following changes are required for the expression to be resolvable by the infrastructure:

Expand
title🛈 Expandable section for changes of Timing prior release FUT-I 2024.4

  • dayOfWeek

    • dayOfWeek should used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start.

    • The value in dayOfWeek must be removed from ServiceRequest.occurrenceTiming.repeat.dayOfWeek.

  • timeOfDay

    • timeOfDay is ignored for frequency-based timing but should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start

    • For clarity, it is advised to remove the value in timeOfDay as it is not used for frequency-based timing.

  • boundsDuration

    • If “Angiv varighed” is filled out, boundsDuration should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.end

    • boundsDuration must be removed

...

Expand
title🛈 Expandable section for changes of Timing after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported

  • boundsDuration

    • If “Angiv varighed” is filled out, boundsDuration should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.end

    • boundsDuration must be removed

Info

TimeOfDayand DayOfWeek do not need to align with BoundsPeriod.start, as Infrastructure will handle the timing adjustments accordingly.

Example

Expression from PlanDefinition.action[].timingTiming.repeat created in KAM. (Intention from KAM: Every third day second Monday at 10 AM, for 2 months)

Code Block
languagejson
"repeat": {
     "frequency": 1,
  "durationperiod": 2,
        "durationUnit"periodUnit": "hwk",
     
  "frequencydayOfWeek": 1,
        "period": 3[ "mon" ],
        "periodUnit": "d",
        "timeOfDay": [ "10:00:00" ],
        "boundsDuration": {
    
     "unit": "mo",
   
      "value": "2"
        }
      }}
}

Must be transformed to:

Expand
title🛈 Expandable section for transformations prior release FUT-I 2024.4
Code Block
languagejson
"repeat": {
"duration
"frequency":
2
1,
"durationUnit
"period":
"h", 
2,
  
"
frequency
periodUnit":
1, 
"wk",
  
"
period
boundsPeriod":
3, 
{
    
"
periodUnit
start": "
d", "boundsPeriod": { "start
2023-09-04T10:00:00.000+02:00" <-- Starting from a Monday at 10 AM
    "end": "2023-
08
11-
28T10
04T10:00:00.000+02:00" <--
Starting
ending
from
after
a
2
Monday
months
at
10
AM "end": "2023-10-28T10:00:00.000+02:00" <-- ending after 2 months } }
}
}

...

Expand
title🛈 Expandable section for transformations after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported
Code Block
languagejson
"repeat": {
  "frequency": 1,
  "period": 2,
  "periodUnit": "wk",
  "dayOfWeek": [ "mon" ],
  "timeOfDay": [ "10:00:00" ],
  "boundsPeriod": {
    "start": "2023-09-01T08:00:00.000+02:00" <-- always required, can occur on any day of the week at any time of day
    "end": "2023-11-01T08:00:00.000+02:00" <-- ending after 2 months
  }
}

For periodUnit other than wk (weekly)

...

Expand
title🛈 Expandable section for changes of Timing prior release FUT-I 2024.4

  • timeOfDay

    • timeOfDay is ignored for frequency-based timing but should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start

    • For clarity, it is advised to remove the value in timeOfDay as it is not used for frequency-based timing.

  • boundsDuration

    • If “Angiv varighed” is filled out, boundsDuration should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.end

    • boundsDuration must be removed

...

Expand
title🛈 Expandable section for changes of Timing after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported

  • boundsDuration

    • If “Angiv varighed” is filled out, boundsDuration should be used to set ServiceRequest.occurrenceTiming.repeat.boundsPeriod.end

    • boundsDuration must be removed

Info

TimeOfDayand DayOfWeek do not need to align with BoundsPeriod.start, as Infrastructure will handle the timing adjustments accordingly.

Expression from PlanDefinition.action[].timingTiming.repeat created in KAM. (Intention from KAM: Every third day at 10 AM, for 2 months)

Code Block
languagejson
"repeat": {
        "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "timeOfDay": [ "10:00:00" ],
        "boundsDuration": {
        "unit": "mo",
        "value": "2"
        }
      }

Must be transformed to:

Expand
title🛈 Expandable section for transformations prior release FUT-I 2024.4
Code Block
languagejson
"repeat": {
        "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "boundsPeriod": {
          "start": "2023-08-28T10:00:00.000+02:00" <-- Starting from a Monday at 10 AM
          "end": "2023-10-28T10:00:00.000+02:00" <-- ending after 2 months
        }
}

...

Expand
title🛈 Expandable section for transformations after release FUT-I 2024.4, as a consequence of CCR0212: Ensure that timing expressions that can be created in KAM are supported
Code Block
languagejson
"repeat": {
       "duration": 2,
        "durationUnit": "h",
        "frequency": 1,
        "period": 3,
        "periodUnit": "d",
        "timeOfDay": [ "10:00:00" ],
        "boundsPeriod": {
          "start": "2023-08-28T06:00:00.000+02:00" <-- always required, can occur on any day of the week at any time of day
          "end": "2023-10-28T06:00:00.000+02:00" <-- ending after 2 months
        }
}

Managing offering ServiceRequest as extra activities

The extension includeAsExtra on ServiceRequest, is used to determine whether the ServiceRequest should be provided as an extra activity in the $get-patient-procedures result. The value for includeAsExtra is copied from the corresponding PlanDefinition.action during creation of the ServiceRequest ($apply operation), and the value can be updated on any individual ServiceRequest.

The value for includeAsExtra can be set through the TimingPicker. The default value for includeAsExtra is false when not scheduled or adhoc, and true when a schedule has been configured.

...

Maintaining ServiceRequest Status

Over the lifecycle of a ServiceRequest, its status might change. Adjustment of ServiceRequest.status can be performed through ServiceRequest Update by:

...

Info

Enforced constraints on the duration of scheduled status with the value ‘on-hold’ is are the same as for the CarePlan.status.

When setting scheduled status changes it is automatically enforced how long the ServiceRequest can be planned as paused. This is done to prevent patient plans from being forgotten in a paused state.

When setting ServiceRequest.ehealth-statusschedule:

  • If no further status changes are planned by the user, then the infrastructure will automatically insert a planned change back to ‘active’ 7 days after the start of ‘on-hold’

  • Maximum The maximum duration of a planned ‘on-hold’ status is 30 days.

Info

ServiceRequest, like EpisodeOfCare and CarePlan, automatically maintains a status history ServiceRequest.statushistory:

  • The status history is maintained as a list of ehealth-statusHistory objects each containing:

    • A status.

    • The Period of time period the status was set.

  • The history is automatically updated when the status is (regardless of whether the status is set manually or is a scheduled change):

    • A new entry is added with the new status and an open-ended period that started at the time of the status change.

    • The Period.end in the entry for the previous status is updated to be the same as the start of the new entry.

      • One should consider the period to be exclusive-end to avoid confusion as the Period.end of one historic status and the Period.start of the next have the same timestamp.

Note

It is expected that a Telemedicine Solution warns the user in case the status is set to revoked or completed for a triggering ServiceRequest which another (depending) ServiceRequest is relying on for trigger conditions (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1696137281/Managing+Telemedicine+Packages#Setting-up-one-or-more-actions-as-trigger-for-an-action-in-PlanDefinition) when the depending ServiceRequest has ServiceRequest.triggerEnablement set to TRIGGER_ENABLED. A triggering ServiceRequest can be recognized by having a ServiceRequest.meta.tag value trigger (see https://docs.ehealth.sundhed.dk/latest-released/igfhir/CodeSystem-ehealth-action-type.html ).

Note

It is expected that a Telemedicine Solution warns the user in case the status is set to revoked or completed for a ServiceRequest where a submitted measurement is used as input for another ServiceRequest (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1717436538/Preparing+and+Submitting+Measurements#Preparing-an-Observation-for-a-Value-Entered-or-Calculated-in-a-QuestionnaireResponse).

The ways to determine whether a ServiceRequest needs a measurement from another ServiceRequest as input are:

  • PlanDefinition.action.participant.type is set to the device (found by doing a ServiceRequest Search reverse include “CarePlan:activity-reference” (see https://docs.ehealth.sundhed.dk/latest-released/igfhir/CapabilityStatement-careplan.json.html ) giving CarePlan which can be traversed through CarePlan.instantiatesCanonical to PlanDefinition), and/or

  • ActivityDefinition.participant.type is set to the device (found by traversing ServiceRequest.instantiatesCanonical)

...

Situation

FHIR ServiceRequest

FHIR ActivityDefinition (referenced by ServiceRequest)

FHIR Goal

Absolute The absolute triaging rule used, no absolute measurement range defined in ServiceRequest

No ServiceRequest.ehealth-referenceRange with type = RAL or GAL

User The user should define an absolute measurement range (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1706229761/Measurement+Ranges#Absolute-Measurement-Ranges).

ActivityDefinition.library references a Library with Library.type = automated-processing.

The Library.identifier is:

  • Identifier.value = urn:uuid:63f0b086-f94d-4cbc-ab0e-f01eb6c27f43

  • Identifier.system = urn:ietf:rfc:3986

Not used (but can co-exist with the use of relative triaging rule/relative measurement range).

Relative The relative triaging rule used, no relative measurement range defined in ServiceRequest

No ServiceRequest.ehealth-referenceRange with type = RELRAL or RELGAL

User The user should define a relative measurement range (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1662025748/Creating+and+Maintaining+Measurement+Ranges#Setting-up-Relative-Reference-Ranges-and-a-Reference-Base).

ActivityDefinition.library references a Library with Library.type = automated-processing.

The Library.identifier is:

  • Identifier.value = urn:uuid:85b7fc91-edaf-48e8-8688-d743e9ebc899

  • Identifier.system = urn:ietf:rfc:3986

Possibly defined, otherwise see the row below.

Relative triaging rule used, no reference base defined

At least one ServiceRequest.ehealth-referenceRange with type = RELRAL or RELGAL exits

User The user should define a reference base (see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1662025748/Creating+and+Maintaining+Measurement+Ranges#Setting-up-Relative-Reference-Ranges-and-a-Reference-Base)

...

In a PlanDefinition, action triggers can be added for the comprised activities as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1696137281/Managing+Telemedicine+Packages#Setting-up-one-or-more-actions-as-trigger-for-an-action-in-PlanDefinition. When the PlanDefinition is $apply'ed to a CarePlan, it is reflected in -PlanDefinition. When the PlanDefinition is $apply'ed to a CarePlan, it is reflected in each of the resulting ServiceRequest whether it is depending on trigger conditions to be met, see each of the resulting ServiceRequest whether it is depending on trigger conditions to be met, see https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027/Creating+Care+Plans#Action-Triggers-and-Trigger-Conditions. It is reflected in the ServiceRequest element triggerEnablement whether it is dependent or not. By default (at the time of $apply):

  • ServiceRequest.triggerEnablement is set to NO_TRIGGER when the ServiceRequest is not depending on trigger conditions. It may trigger other ServiceRequest, though.

  • ServiceRequest.triggerEnablement is set to TRIGGER_ENABLED if it depends on trigger conditions. The ServiceRequest.status is set to on-hold.

When trigger conditions are fulfilled, a triggerEnablement of TRIGGER_ENABLED changes to TRIGGER_DONE automatically as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1661141027538935313/CreatingBehind+Care+Plans#Actionthe+Scenes#Automated-Processing-of-Action-Triggers-and-Trigger-Conditions. It is reflected in the ServiceRequest element triggerEnablement whether it is dependent or not. By default (at the time of $apply):

  • ServiceRequest.triggerEnablement is set to NO_TRIGGER when the ServiceRequest is not depending on trigger conditions. It may trigger other ServiceRequest, though.

  • ServiceRequest.triggerEnablement is set to TRIGGER_ENABLED if it is depending on trigger conditions. The ServiceRequest.status is set to on-hold.

When trigger conditions are fulfilled, a triggerEnablement of TRIGGER_ENABLED changes to TRIGGER_DONE automatically as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/538935313/Behind+the+Scenes#Automated-Processing-of-Action-Triggers-and-Trigger-Conditions. At this point, even if the trigger conditions are fulfilled again, there will be no change.

It is possible to control, per ServiceRequest, whether it shall react to action triggers. The following manual changes of triggerEnablement are possible by ServiceRequest Update:

  • TRIGGER_ENABLED change to TRIGGER_DISABLED - to disable triggering of the depending ServiceRequest, for instance, if the citizen is on vacation.

  • TRIGGER_DISABLED change to TRIGGER_ENABLED - to re-enable triggering of a depending ServiceRequest, for instance, if the citizen has returned from vacation.

  • TRIGGER_DONE change to TRIGGER_ENABLED - to re-enable triggering of a depending ServiceRequest even though it has been triggered already.

When re-enabling, it should be considered what is the appropriate status of the ServiceRequest. For a triggering behaviour such as activation, the ServiceRequest status should manually be set to on-hold.

...

At this point, even if the trigger conditions are fulfilled again, there will be no change.

It is possible to control, per ServiceRequest, whether it shall react to action triggers. The following manual changes of triggerEnablement are possible by ServiceRequest Update:

  • TRIGGER_ENABLED change to TRIGGER_DISABLED - to disable triggering of the depending ServiceRequest, for instance, if the citizen is on vacation.

  • TRIGGER_DISABLED change to TRIGGER_ENABLED - to re-enable triggering of a depending ServiceRequest, for instance, if the citizen has returned from vacation.

  • TRIGGER_DONE change to TRIGGER_ENABLED - to re-enable triggering of a depending ServiceRequest even though it has been triggered already.

When re-enabling, it should be considered what is the appropriate status of the ServiceRequest. For a triggering behaviour such as activation, the ServiceRequest status should manually be set to on-hold.

Info

The current reaction (selected in PlanDefinition.action.ehealth-actionTrigger.action) to the action trigger's trigger conditions being met is to change the ServiceRequest status from on-hold to active. There is no reaction to cause ServiceRequest.status changes to other values, e.g. completed.

Setting the Document Sharing Approval Policy

The document registering approval policy of a ServiceRequest set in ServiceRequest.ehealth-sharingApprovalPolicy expresses whether submitted measurement data (for instance measurements or questionnaire responses) for the activity shall be automatically approved for document sharing or whether manual approval is required.

When set, the value of ServiceRequest.ehealth-sharingApprovalPolicy controls how approval for document registering is handled per submitted measurement:

  • manual, a clinician must manually approve each submitted measurement for document registering

  • automatic, the eHealth Infrastructure automatically creates the approval for document registering

If not set, the default behaviour is manual.

Info

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

Info

Approval for document registering is not the only prerequisite for document registering to happen. See Sharing through Registering Documents in National Document Sharing Infrastructure .