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

Determining Which Device(s) to Use

When a ServiceRequest referenced from a citizen’s CarePlan has a status set to active, it is expected that the required measurement device(s) has been provided to the individual performing the measurement. Typically (but not necessarily) this individual is 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

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

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

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 before or during measuring. These possible texts/pictures reside in ActivityDefinition.relatedArtifact with:

• RelatedArtifact.type = documentation

• RelatedArtifact.label = automatic or manual for use with automatic and manual entry collection of data, respectively.

• RelatedArtifact.document can contain a contained Attachment with text to display. Currently, the Clinical Administrative Application produces a contained Attachment where Attachment.data contains markdown format (with markdown specified in Attachment.contentType).

• RelatedArtifact.resource can refer to a DocumentReference resource containing a picture to display. Picture data is captured in DocumentReference.content.attachment.data with the format specified in DocumentReference.content.attachment.contentType.

Presenting Offsets between Activities and Duration of Activity

The offset between activities has different meanings depending on where used. The citizen’s CarePlan refers to a PlanDefinition in which offset can be defined between its comprised activities through PlanDefinition.action.relatedAction.offset. In the following, it is assumed that the Patient-specific adjustments of measurement regimes (in ServiceRequest.timing) have not veered off significantly from the intention for offset and/or measurement regimes described in sub-elements of PlanDefinition.action, at least for the same-group activities.

• When defined between activities within the same activity group, the PlanDefinition.action.relatedAction.offset (typically in the variant offsetDuration) defines a pause between the activities often specified in minutes or seconds.

• When defined between activities no in the same activity group, the same offset defines different measurement regimes, for instance, that one activity starts a month after another activity ends. The offset is often specified in months or days.

An activity may be described with a duration for actually performing the activity, beside a measurement regime. When this is the case, the:

• PlanDefinition.action.timing[x] describes its measurement regime, while

• ActivityDefinition.timingRange or, typically, ActivityDefinition.timingDuration describes the duration of actually performing the activity

Ensuring the Use of Proper Units

A measurement submitted as an Observation shall conform to the measurement unit expected by the eHealth infrastructure. See Interactions with the Terminology Service | Determining the proper code, system and unit for Quantity.

Preparing Measurements for Submission

Determining Resolved Timing to Use

When submitting measurements, it is mandatory to specify the resolved timing (see 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:

• serviceRequestVersionId which must specify the current technical version of the ServiceRequest referenced in basedOn element of Observation, QuestionnaireResponse and Media.

• start - start datetime of resolved timing period. This is mandatory when the type is Resolved.

• end - end datetime of resolved timing period. This is mandatory when the type is Resolved.

• type

  • Resolved if the ServiceRequest has a measurement regime supported by the infrastructure

  • Unresolved if the ServiceRequest has a measurement regime not supported by the infrastructure

  • Adhoc, if the ServiceRequest has a measurement regime, is specified as ad-hoc or the measurement was collected as per request from a Practitioner.

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

Determining Qualities

Setting the involved Patient and/or Practitioner

Both patients and practitioners can submit measurements (see the section below).

How to designate who has been involved differs with the measurement types as follows:

Preparing a QuestionnaireResponse for a Questionnaire with Embedded, Simple Calculation(s)

As described in Managing Questionnaires | Preparing a Questionnaire with Embedded, Simple Calculations, a Questionnaire defined with the eHealth profile ehealth-questionnaire-advanced (see https://ehealth.sundhed.dk/fhir/StructureDefinition-ehealth-questionnaire-advanced.html ) can contain variables and expressions.

The application used for filling in answers to a Questionnaire in a QuestionnaireResponse of this profile has the responsibility to evaluate embedded expressions and capture the results in the corresponding placeholders in the QuestionnaireResponse.

Saving a Draft QuestionnaireResponse

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 Telemedicine Solution should refrain from calling QuestionnaireResponse Update unless actual changes have been made to the QuestionnaireResponse. Calling QuestionnaireResponse Update without actual change leads to unnecessary load and will not result in a change of the QuestionnaireResponse in the database anyway.

When creating/updating a draft QuestionnaireResponse, make sure the following elements are set:

• status is in-progress

• basedOn references the ServiceRequest stating that answering of the questionnaire should be performed as an activity

• resolvedTiming reflects the resolved timing with which the QuestionnaireResponse is intended to be submitted (as final).

Preparing an Observation for a Value Entered or Calculated in a QuestionnaireResponse

A Patient’s CarePlan can be based on a PlanDefinition (and one or more ActivityDefinition referenced from it) where:

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

One such use is a PlanDefinition with an activity for answering a COPD Assessment Test (CAT) Questionnaire followed by an activity for a CAT score “measurement”.

Preparing Media and a derived Observation

A CarePlan can be based on a PlanDefinition (with its ActivityDefinition) where activities encompass taking a clinical image and deriving one or more dimensions from the image.

Consider the example scenario shown in the figure below where the PlanDefinition has:

• an activity for generating the image (taking a photo) of a wound

  • The ActivityDefinition has code set to Coding with code=446080005, system=http://snomed.info/sct and display=Photography of wound (procedure)

• an activity for collecting dimensions based on the image in the so-called Wound Size Panel

  • The ActivityDefinition has code set to Coding with code=72287-6, system=http://loinc.org and display=Wound size panel

A CarePlan can be applied from the PlanDefinition, producing the usual CarePlan and ServiceRequest resources.

Open

When preparing measurements to submit according to the CarePlan, it can be done in a number of ways.

Typical scenario

Measurements are prepared as:

• A FHIR Media with a clinical image of the wound - Media.usageMode is raw

• A FHIR Media with an overlay produced by the Telemedicine Solution showing the wound edge - Media.usageMode is overlay

• A FHIR Observation with wound dimensions derived from the overlay such as length, width, depth, area and/or volume

The FHIR Observation is prepared as a Wound Size Panel which is supported by the profile ehealth-observation-wound-dimensions based on the infrastructure’s FHIR Observation profile ehealth-observation.

As shown in the figure, the Media are grouped together using the Media.relatedTo element. The Observation.derivedFrom is referencing the Media containing the overlay, to indicate that the values in the Observation have been derived from the overlay.

In the typical scenario, the two FHIR Media and the FHIR Observation are submitted together.

Piecemeal scenario

The Telemedicine Solution may choose to submit the FHIR Media with the clinical image of the wound initially. Subsequently, for instance later same day, the Telemedicine may retrieve the FHIR Media, and prepare the Media with the overlay and derived Observation with dimension for subsequent submission.

Minimal scenario

The Telemedicine Solution prepares a minimal FHIR Media with simply the metadata (Media.usageMode is metadata), that is, no image. Subsequent to submitting of the Media, the Telemedicine Solution prepares an Observation with dimensions and submits that.

Regardless of the order in which FHIR Media resources are submitted, the measurement FHIR service ensures that Media connected through Media.relatedTo have a shared Media.series value.

Submitting Measurements

A Telemedicine Solution submits measurements using the $submit-measurement operation.

Use of $submit-measurement requires:

• a privilege named $submit-measurement (see Role to Privilege mapping for system roles that have this privilege)

• adherence to access control requirements for submit-measurement

• that all submitted measurements reference the same Patient and EpisodeOfCare

• that all submitted measurements have have status completed or final (completed in case of QuestionnaireResponse/Media and final in case of Observation)

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

• Submitting each measurement in a separate call to $submit-measurement.

• Submitting all measurements from a wider measurement period in a single call to $submit-measurement.

Updates to Media after Submission

In general, measurements are immutable after submission, with a few exceptions.

Previously submitted Media can be updated in the following cases:

• Grouping Media by setting the Media.relatedTo. The referenced Media shall be based on the same ServiceRequest.

• Updating metadata in elements modality, view, and bodySite in a Media where Media.usageMode is metadata.

• Updating Media.content if the Media.usageMode is overlay.

• Updating Media status to stopped to indicate that the activity has been terminated prior to full completion.