Collecting Measurement Data from Devices

Determining which Device(s) to Use

When a ServiceRequest referenced from a citizen’s CarePlan has status set to active, it is expected that any required measurement device has been provided to the individual expected to perform measuring. Typically but not necessarily this individual is the citizen. Once provided, the following FHIR resources are created or, for the first two, reused:

FHIR Device representing the particular device instance
FHIR DeviceMetric representing state and details about the particular device instance
FHIR DeviceUseStatement which establishes relationships between the Device, Patient, and CarePlan.

Determining when to use the same Device simultaneously for multiple measurements

When the same Device is expected to be used for multiple, different measurements, the citizen’s CarePlan references a PlanDefinition where an activity group in the PlanDefinition (or its possible sub-PlanDefinition(s)) has code SDG (Same Device Group).

An activity group is represented as a PlanDefinition.action which has 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.

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

The https://docs.ehealth.sundhed.dk/latest-released/ig/ValueSet-ehealth-activitydefinition-code.html current does not contain the concept SDG but this will be fixed with 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.

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 a number of ServiceRequest for activities to perform. Each ServiceRequest refers an ActivityDefinition containing definitional details. Such details can be text and/or pictures to display to the individual performing the measurement just prior 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.

It is expected that a Telemedicine Solution detects whether measuring is performed automatically or by manual entry and examines whether corresponding ActivityDefinition.relatedArtifact (as defined above) is present. If so, the Telemedicine Solution is expected to display the text and/or picture to the user.

Presenting Offsets between Activities and Duration of Activity

Offset between activities has different meaning depending on where used. The citizen’s CarePlan refers 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 a one activity starts a month after another ends. The offset is often specified in months or days.

It is expected that a Telemedicine Solution treats offset between activities in the same activity group as a pause for which countdown or count up should be presented to the user (typically the individual following the plan). In case it is not specified whether to perform countdown or count up (this is currently not modelled), the Telemedicine Solution shall perform countdown.

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

It is expected that a Telemedicine Solution treats activity duration as situation where countdown or count up should be presented to the user (typically the individual following the plan). In case it is not specified whether to perform countdown or count up (this is currently not modelled), the Telemedicine Solution shall perform countdown.

Ensuring Use of Proper Units

A measurement submitted as an Observation shall conform to the measurement unit expected by the eHealth infrastructure. See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1034354702/Technical+Interactions+with+Services#Determining-the-proper-code%2C-system-and-unit-for-Quantity.

It is expected that a Telemedicine Solution ensures that measurement data conforms to the expected measurement unit. Correctness (and verification hereof) of any required conversion in that regard is the responsibility of the Telemedicine Solution.

Preparing Measurements for Submission

Determining Resolved Timing to Use

The functionality described below is provided with eHealth Infrastructure Release 7 and after.

When submitting measurements, it is mandatory to specify 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:

serviceRequestVersionId which must specify the current FHIR technical version of the ServiceRequestreferenced in basedOn element of Observation, QuestionnaireResponse and Media.
start - start datetime of resolved timing period. This is mandatory when type is Resolved.
end - end datetime of resolved timing period. This is mandatory when 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

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

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

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-released/ig/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 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 load and will not result in 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 questionnaire should be performed as activity
resolvedTiming reflects the resolved timing with which the QuestionnaireResponse intended to be submitted (as final).

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 same as that of submitted QuestionnaireResponse
resolvedTiming is same as that of submitted QuestionnaireResponse

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

status is in-progress
lastUpdated is older than a configurable retention period, currently set to 30 days.

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 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 activity for answering a COPD Assessment Test (CAT) Questionnaire followed by an activity for a CAT score “measurement”.

Example: A PlanDefinition with activity for answering a COPD Assessment Test (CAT) Questionnaire followed by an activity for a CAT score “measurement”, which is calculated by a simple rule in the CAT Questionnaire.

In this scenario, the CAT score measurement is an ActivityDefinition with:

code set to Coding code="MCS88137", system="urn:oid:1.2.208.184.100.8", display="CAT score;pt"
participant.type set to device

In the Questionnaire, the above Coding for CAT score is present in Questionnaire.item.code for a calculated element prepared such that a QuestionnaireResponse can contain the calculated CAT score.

On detecting the participant.type set to device, an Observation shall be prepared with a value derived from the CAT score contained in the QuestionnaireResponse.

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 $submit-measurement. Technically, it is possible to submit multiple measurements in different ways, ranging from:

Each measurement submitted with individual invocation of $submit-measurement
All measurements from a wider measurement period submitted in a single invocation

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

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

Preparing and Submitting Measurements