Versions Compared

Old Version 38

changes.mady.by.user John Schneider

Saved on

compared with

New Version 39

changes.mady.by.user Erik Nielsen

Saved on

Key

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

...

  • 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 wheter the activity described in the ServiceRequest is supposed to take place. The measurement regime the approval for registrering 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 registrering documents 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+Plans#Applying-the-PlanDefinition) and typically, it contains no starting date/time.

...

  • done manually.

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

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 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 wheter 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+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 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.

...

Situation

FHIR ServiceRequest

FHIR ActivityDefinition (referenced by ServiceRequest)

FHIR Goal

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

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

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).

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

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

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

The user should define a reference base (see 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)

Controlling the Trigger Enablement

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+

...

Controlling the Trigger Enablement

In a PlanDefinition, action triggers can be added for the comprised activities as described in 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 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/16961372811661141027/ManagingCreating+TelemedicineCare+Packages#SettingPlans#Action-Triggers-upand-one-or-more-actions-as-trigger-for-an-action-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 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. At this point, even if the trigger conditions are fulfilled again, there will be no change.

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/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.

...

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 behavior 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 .