Versions Compared

Old Version 11

changes.mady.by.user Andreas Harfeld Jakobsen

Saved on

compared with

New Version 12

changes.mady.by.user Erik Nielsen

Saved on

Key

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

...

Info

Enforced constraints on duration of scheduled status with value ‘onhold’ onhold.

When setting scheduled status changes it is automatically enforced how long the EpisodeOfCare can be planned as paused (with status set to onhold). This is done to prevent patient plans being forgotten in paused state.

When setting EpisodeOfCare.ehealth-statusschedule:

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

  • Maximum duration of a planned ‘onhold’ onhold status is 30 days.

Info

EpisodeOfCare automatically maintains a status history EpiodeOfCare.statushistory:

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

    • A status.

    • The Period of time 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

CareTeam Handover and Unhandled Tasks

The CareTeams involved in an EpisodeOfCare have access to the EpisodeOfCare, all CarePlan related to it, and all measurements related to ServiceRequest related to the CarePlan and so on (provided the appropriate Role-based access privileges are present for a user using the CareTeam). For Task resources currently created automatically by the infrastructure, the set of CareTeam involved in an EpisodeOfCare are not designated as Task responsible.

There might, however, still exist Task created by other means, for instance Task created on user initiative in a solution. For these, it should be considered whether a change in the set of CareTeam involved in the EpisodeOfCare should also result in adjusting of Task.taskResponsible (by adding CareTeam added to the EpisodeOfCare).

Automatic Application of Planned Changes

This is handled by a regularly running job in the infrastructure, is the same for ServiceRequests and CarePlans, and is therefore explained here: https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2059763713/Maintaining+CarePlan+s+and+ServiceRequest+s#Automatic-Application-of-Planned-Changes-(ServiceRequest%2C-CarePlan-and-EpisodeOfCare)

Adjusting the Period

The period of time in which the EpisodeOfCare is applicable is reflected in EpisodeOfCare.period. Adjustment of EpisodeOfCare.period is performed through EpisodeOfCare Patch.

...