How to interpret output from get-patient-procedures

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

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:

• 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 invalidated-is-not-fulfillment

• Item_10: Row indicating same as item_10, except the decision for the invalidated measurement was invalidated-fulfills