...
Retrieving a CarePlan and the referenced ServiceRequest activities can be performed by a CarePlan Search on CarePlan id ID with the include of ServiceRequest.
...
occurrenceDateTime: An activity that takes place once on a specified date and time.occurencePeriod: An activity that takes place once in a specified period.occurenceTiming: This is for recurring activities. For example, a measurement that should be performed each Monday at 10:00.
The Timing structure can express recurrence in several different ways. There are no hard restrictions on how fields can be used and combined. However, there is a recommended subset that the infrastructure understands and can help Patients and Clinicians to follow with reminders, alarms and an overview of expected and received measurements.
...
A recurring regime can be resolved to a number of several specific times where when the activity should be performed. Each of these is referred to as a resolved timing.
...
Week-based measurement regimes consist of a combination of dayOfWeek, timeOfDay, duration, and frequency:
timeOfDay is optional. If it is not specified then the time component of boundPeriod.start is used instead.
duration is optional. If not specifed specified then the regime expects activities to be performed at a specific time.
frequency is mandatory and specifies the number of times the activity should be performed for each resolved timing.
Frequency-based measurement regimes
This type of regime is recommended for activities that happen less frequently than once per week. It can be used to specify more frequent activities, but it is recommended to use the week-based regimes instead in these cases.
...
Once every 2 weeks
Once every 10 days
Frequency-based measurement regimes consist of: frequency, period, periodUnit, boundsperiod.start, duration.
period, periodUnit are is mandatory and specify specifies the period between each resolved timing.
frequency is mandatory and specifies the number of times the activity should be performed for each resolved timing.
Each resolved timing will match the pattern: boundsperiod.start + n * period * periodUnit
There are a number of some pitfalls to be aware of for the frequency-based measurement regime. Especially if the periodUnit is specified in days or hours.
...
In a given time period, this recurring regime will result in a number of several resolved timings. For example, looking at April 2021 this will result in four resolved timings
...
The operation get-patient-procedures can be used to see what is planned in the future. For example during the next week. It can also be used to see what was submitted in the past, and if it matches what was planned and if any measurements are still missing. The operation can evaluate past submissions for the last 30 days. Setting the start date to earlier than 30 days ago will result in an error.
...
The operation get-patient-procedures is based on an examination of the following resources:
Examined EpisodeOfCare:
EpisodeOfCare.patientmust match the Patient reference given as a parameterEither the
EpisodeOfCare.idis included in the list of EpisodeOfCare references given as a possible parameter, orEpisodeOfCare.diagnosis.condition.code(at least one if multiple Coding provided) is included in the list of condition Coding given as a possible parameter
Examined CarePlan:
CarePlan.workflow-episodeOfCaremust reference one of the examined EpisodeOfCare
Examined ServiceRequest:
Must be referenced from examined CarePlan
...
get-patient-procedures produces output for each resolved timing of the ServiceRequest, where the ServiceRequest is determined to have effective statusactive during the resolved timing. The period for which the ServiceRequest has effective statusactive shall have at least partial overlap, that is, it does not have to completely overlap the resolved timing. Resolved timings which originate from the same ServiceRequest are evaluated separately in regards to regarding the effective status of the ServiceRequest.
...
An ‘extra’ row will be returned if there is an overlap between the search period and the measurement regime period. Resolved/unresolved measurement regimes can result in returned ‘extra’ rows while Ad hoc measurement regimes cannot (since the Patient may already submit at any time for this type).
...
In addition to the above-mentioned criteria, the ServiceRequest must also have effective status which is either active or on-hold at any given time during the search period, in order to be added to the output as extra. Unlike the usual way of determining effective status, the EpisodeOfCare, CarePlan and ServiceRequest are not required to have the same status at the same time as long as the status is either active or on-hold. An output row for extra measurement can occur even if the ServiceRequest did not result in any Resolved/unresolved measurement row.
...
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.
...
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.
...