...
| Expand |
|---|
| title | The functionality described here is supported from release 2025.1 |
|---|
|
How to interpret output from get-patient-procedures| Info |
|---|
Read “active” as “effective status active”. |
The output contains rows (encoded in parameters) for each matching (see get-patient-procedures) and active ServiceRequest with resolved timings overlapping with the requested period. CarePlan: Reference to the CarePlan that the ServiceRequest belongs to.
ServiceRequest: Reference to the ServiceRequest.
ServiceRequestVersionId: The version of the ServiceRequest (version specified at the time of submit-measurement or the current version (for expected activities)).
Activity: Description of the planned activity.
ResolvedTimingStart: A planned start time for the activity in the requested period.
ResolvedTimingEnd: A planned end time for the activity in the requested period. May be identical to the start if no duration is specified in the measurement regime.
TotalSubmitted: The number of measurements already submitted for this ServiceRequest and resolved timing.
SubmittedTimely: The number of measurements where the measurement time matches the resolved timing.
TimingType:
Resolved: a measurement regime that is supported by the infrastructure and where resolved timing and requested number of measurements can be calculated.
Unresolved: a measurement regime that the infrastructure cannot resolve to resolved timing. Resolved Timing Start, and end submitted timely and Occurrences requested will be empty.
Adhoc: A ServiceRequest without a measurement regime or a measurement regime stating ad-hoc.
Extra: The Patient may submit extra measurements for the ServiceRequest outside the resolved timing slots.
OccurencesRequested: Expected number of measurements.
TotalInvalidated: Number of measurements which are invalidated
| Note |
|---|
A Telemedicine Solution is expected to determine resulting time slots on their own in case the TimingType is unresolved. |
If measurements are submitted for older versions of a ServiceRequest, then a row will be added with the number of submitted measurements. Furthermore, for older versions of ServiceRequests, the occurrenceRequested-value is set based on that exact serviceRequestVersion. Example output: parameter[i] | item_% | CarePlan | ServiceRequest | ServiceRequestVersionId | Activity | Resolved Timing Start | ResolvedTimingEnd | TotalSubmitted | SubmittedTimely | TimingType | OccurencesRequested | TotalInvalidated | 0 | item_1 | ../CarePlan/1 | ../ServiceRequest/6 | 12 | Vægt | 20210121 12:00 | 20210121 12:00 | 0 | 0 | Resolved | 1 | | 1 | item_2 | ../CarePlan/1 | ../ServiceRequest/5 | 44 | Iltmætning | | | 1 | | Unresolved | | | … | item_3 | ../CarePlan/1 | ../ServiceRequest/5 | 45 | Iltmætning | 20210122 11:00 | 20210122 12:00 | 2 | 1 | Resolved | 2 | | | item_4 | ../CarePlan/1 | ../ServiceRequest/5 | 45 | Iltmætning | 20210122 13:00 | 20210122 14:00 | 0 | 0 | Resolved | 2 | | | item_5 | ../CarePlan/2 | ../ServiceRequest/17 | 1 | Højde | | | 1 | | Adhoc | | | | item_6 | ../CarePlan/3 | ../ServiceRequest/3 | 2 | Blodtryk | 20210322 08:00 | 20210322 09:00 | 1 | 0 | Resolved | 1 | | | item_7 | ../CarePlan/3 | ../ServiceRequest/3 | 2 | Blodtryk | 20210323 08:00 | 20210323 09:00 | 1 | 1 | Resolved | 1 | | | item_8 | ../CarePlan/3 | ../ServiceRequest/3 | 3 | Blodtryk | 20210324 11:00 | 20210324 12:00 | 1 | 0 | Resolved | 1 | | | item_9 | ../CarePlan/3 | ../ServiceRequest/3 | 1 | Blodtryk | | | | | Extra | | | | item_10 | ../CarePlan/3 | ../ServiceRequest/4 | 1 | IltmætningPuls | 20210122 1109:00 | 20210122 1210:00 | 1 | 0 | Resolved | 2 | 1 | | item_1011 | ../CarePlan/3 | ../ServiceRequest/4 | 1 | IltmætningPuls | 20210122 1114:00 | 20210122 1215:00 | 2 | 1 | Resolved | 2 | 1 |
Item_1: A weight ServiceRequest with a single resolved timing and 1 measurement planned. Currently, none submitted Item_2: An old version of an oxygen saturation ServiceRequest of type Unresolved. One measurement was submitted for this version, but the infrastructure cannot determine if it was timely or how many were requested. Item_3: Current version of an oxygen saturation ServiceRequest where the measurement regime has been updated so it can be resolved. 2 measurements were requested and already submitted, but one of them was not on time. Item_4: Same ServiceRequest as item_3, but a different resolved time. 2 measurements are requested but none submitted yet. Item_5: A height ServiceRequest with an ad-hoc measurement regime. One measurement was submitted. item_6: An old version of a blood pressure ServiceRequest of type Resolved. One measurement was requested and one measurement was submitted, however not timely according to the ResolvedTiming on the measurement itself. Item_7: An old version of a blood pressure ServiceRequest of type Resolved. One measurement was requested and one measurement was submitted timely according to the ResolvedTiming on the measurement itself. Item_8: Current version of a blood pressure ServiceRequest updated with new ResolvedTimingStart and ResolvedTimingEnd on the measurement regime. One measurement was submitted for this version, however not on time. Item_9: Row indicating that the Patient may submit extra measurements for the ServiceRequest outside the resolved timing slots. Item_10: Row indicating same as item_3, except the timely submitted measurement has been invalidated, and the decision for fulfillment was Two measurements have been submitted timely, but one of the measurements was invalidated with decision invalidated-is-not-fulfillment. The invalidated measurement will not count towards an actual submission and only be visible through the total invalidated count. Item_10: Row indicating same 11: Same scenario as item_10, except the decision for the invalidated measurement was invalidated-fulfills
|
...
See Preparing and Submitting Measurements .
Managing
...
Validity of Measurements
| Info |
|---|
The functionality described here is supported from release 2025.1 |
A measurement can be invalidated to acknowledge that a measurement is deemed erroneous or invalid. Additionally, invalidation of a measurement can be retracted in case of wrongful invalidation. Invalidation and invalidation retraction of measurements are both performed using the operation set-measurement-validity (see When submitted (see above), a measurement has status reflecting it being final and implicitly valid. If a employee or patient deems it erroneous or invalid, the measurement can be invalidated. To enable undoing in case of wrongful invalidation, retraction of invalidation is also supported.
Both measurement invalidation and retraction of invalidation are performed using the operation set-measurement-validity (see https://ehealth.sundhed.dk/fhir/OperationDefinition-ClinicalImpression-t-set-measurement-validity.html) .
The operation receives requires a ClinicalImpression resource as input, which specifies whether to invalidate or retract invalidation of the measurement is to be invalidated, or an invalidation is being retracted. referenced measurement (FHIR Observation, FHIR QuestionnaireResponse or FHIR Media).
As side effects, the infrastructure will update updates the status of the measurement being invalidated or having the invalidation retracted (: The status is set to entered-in-error for invalidation and final or completed for retraction of invalidation retraction). The infrastructure will also update the status to entered-in-error for the previous ClinicalImpression in the measurement validity flow, if any exists.
Measurement validity has impact on The ClinicalImpression.decision values invalidated-fulfills or invalidated-is-not-fulfillmentcontrol how the infrastructure behaves in operation $get-patient-procedures, reminder notifications reminders for submitting of measurements, and notifications for missing measurements. Details for the impact can be found here:
...