Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
stylenone

Overview

The overall steps involved in telemedicine solutions when submitting measurements are as follows:

  1. Telemedicine Solution displays instructions for measurement methods from the ActivityDefinitions to the end-users.

  2. Users perform the measurement.

  3. Telemedicine Solution collects measurement data from devices

  4. Telemedicine Solution shall ensure measurement units conform to expected standards, and perform any necessary conversions.

  5. Telemedicine Solution shall submit Measurements using $submit-measurement, with multiple measurements partitioned by similar resolved timing for efficient processing.

Collecting Measurement Data from Devices

...

When a ServiceRequest referenced from a citizen’s CarePlan has a status set to active, it is expected that any the required measurement device(s) has been provided to the individual expected to perform performing the measuringmeasurement. Typically (but not necessarily) this individual is the a citizen.

Once the devices are provided, the following FHIR resources are created or, for the first two, reused:

  • FHIR Device representing the particular device instance

  • FHIR DeviceMetric represents the state and details of the particular device instance

  • FHIR DeviceUseStatement which establishes relationships between the Device, Patient, and CarePlan.

Determining when to use the same

...

device for multiple measurements

When In some cases, the same Device is expected to be used for multiple, different measurements. Whether that is the case, the Telemedicine solution can determine this by looked at the PlanDefintion. This is done by the citizen’s CarePlan references a PlanDefinition where an activity group in the PlanDefinition (or its possible sub-PlanDefinition(s)) has the code SDG (Same Device Group).

An activity group is represented as a PlanDefinition.action which has with sub-activities defined as PlanDefinition.action.action. As per the recursive construct of PlanDefinition.action.action, an activity group can be nested, in principle at any nesting level. A Same Device Group is a PlanDefinition.action or PlanDefinition.action.action with code set to Coding with code = SDG, system = http://ehealth.sundhed.dk/cs/activitydefinition-code.

Info

See the ValueSet https://docs.ehealth.sundhed.dk/latest-released/igfhir/ValueSet-ehealth-activitydefinition-code.html for details on the concept SDG.

Note

The https://docs.ehealth.sundhed.dk/latest-released/ig/ValueSet-ehealth-activitydefinition-code.html currently does not contain the concept SDG but this will be fixed with the next IG release.

For now, please refer to the continuous build of the eHealth Implementation Guide (IG): https://docs.ehealth.sundhed.dk/latest/ig/ValueSet-ehealth-activitydefinition-code.html.

of SDG.

All the sub-activities of a Same Device Group are expected to be measured using the same device simultaneously.

Presenting Instructions for Measuring Method

The citizen’s CarePlan refers to several ServiceRequest for activities to perform. Each ServiceRequest refers to an ActivityDefinition containing definitional details. Such details can be text and/or pictures to display to the individual performing the measurement just prior to before or during measuring. These possible texts/pictures reside in ActivityDefinition.relatedArtifact with:

...

When submitting measurements, it is mandatory to specify the resolved 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 ) information in the ehealth-resolved-timing element of Observation, QuestionnaireResponse and Media. The structure of ehealth-resolved-timing contains:

...

One way to determine what resolved time to used is to invoke the get-patient-procedures operation.

Determining Qualities

Info

The approach for determining measurement qualities is still under refinement. Neither the required Questionnaire nor the Library is available in the eHealth Infrastructure at the time of writing.

...

As described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1716060177/Managing+Questionnaires#Preparing-a-Questionnaire-with-Embedded%2C-Simple-Calculations, a Questionnaire defined with the eHealth profile ehealth-questionnaire-advanced (see https://docs.ehealth.sundhed.dk/latest-releasedfhir/ig/StructureDefinition-ehealth-questionnaire-advanced.html ) can contain variables and expressions.

...

A draft QuestionnaireResponse can be saved by creating a new QuestionnaireResponse with status in-progress and subsequently updating it. This is performed through QuestionnaireResponse Create and Update, respectively, which is enabled for status in-progress only. Whether it is used for autosave or manually initiated, the client should refrain from calling QuestionnaireResponse Update unless actual changes have been made to the QuestionnaireResponse. Calling QuestionnaireResponse Update without actual change leads to unneccesary unnecessary load and will not result in a change of the QuestionnaireResponse in the database anyway.

...

Info

Cleanup of draft QuestionnaireResponse

When the final version of the QuestionnaireResponse is submitted with $submit-measurement, any corresponding draft QuestionnaireResponse is automatically deleted. The criteria involved in finding corresponding draft(s) are QuestionnaireResponse with:

  • status set to in-progress

  • basedOn is the same as that of the submitted QuestionnaireResponse

  • resolvedTiming is the same as that of the submitted QuestionnaireResponse

There is no guarantee that a draft QuestionnaireResponse is ever submitted. Therefore, a periodic and automatic Infrastructure job performs the deletion of QuestionnaireResponse with the:

  • status is in-progress

  • lastUpdated is older than a configurable retention period, currently set to 30 days.

...

  • PlanDefinition.action.participant.type is set to device, and/or

  • ActivityDefinition.participant.type is set to the device

This participant type signifies that the activity must be carried out by a solution, typically the Citizen Solution.

...

Note

It is expected that a Telemedicine Solution detects the use of participant.type set to device and prepares submission of a measurement based on a value extracted from sibling activities rather than involving the Patient. Typically, this scenario involves the Telemedicine Solution preparing an Observation with value based on or extracted from a QuestionnaireResponse.

Submitting Measurements

Measurements are submitted using Telemedicine Solution submits measurements using the $submit-measurement operation. Technically, it is possible to

The access control for submit-measurement is described here: Access Control for submit-measurement and the roles her Role to Privilege mapping

Technically, Telemedicine Solution can submit multiple measurements in different ways, ranging from:

  • Each Submit each measurement is submitted in an individual a separate call to $submit-measurement.

  • All Submit all measurements from a wider measurement period submitted in a single invocationcall to $submit-measurement.

As noted, all measurements must pertain to the same Patient and EpisodeOfCare.

Note

It is expected that a Telemedicine Solution (typically a Citizen Solution) places multiple measurements into partitions each with measurements sharing the same or similar resolve timing, and , furthermore, submits each partition as an individual invocation of $submit-measurement.

Practitioners submit measurement

A practitioner with the role having the $submit-measurement privilege can call $submit-measurement, and thereby practitioner to submit measurement data (measurements, questionnaire responses, and/or images).

In that case the Observation.performed shall refer to a Practitioner (instead of the typical scenario where it refers to a Patient). It can thereby be indicated that the measurement was carried out by an employee on behalf of the citizen.