ServiceRequest Due date

Clinical
1

We have recently spent some time on digging into the different types of dates (timestamps) that are needed for planning various types of services, e.g. surgical procedures.

An area of confusion is around what in the ServiceRequest archetype is called Service Due. If we look at its definition, it says:

Description = The date/time, or acceptable interval of date/time, for provision of the service
Comment = This data element allows for recording of the timing for a single service, either as a date and time, a date ranges or a text descriptor which can allow for 'next available. In practice, clinicians will often think in terms of ordering services as approximate timing, for example: review in 3 months, 6 months or 12 months. As clinical systems need more exact parameters to operate on, this ‘3 months’ will usually be converted to an exact date 3 months from the date of recording and stored using this data element. If complex timing or sequences of timings are required, use the CLUSTER.service_direction archetype within the ‘Complex timing’ SLOT and this data element becomes redundant

We have a corresponding national definition in Sweden which translates to something like: “Medical Target Date”, and defined something like “The date for which healthcare activities should commence”.
https://termbank.socialstyrelsen.se/?TermId=376&SrcLang=sv

What we have realized is that there seems to be at least two different concepts mixed in the Swedish national definition, and also seems to be mixed up in the openEHR ServiceRequest. The naming here could likely be improved, but you have these two types at least:

Latest target date
A date which indicates that the start of the treatment should not happen after this date, but the patient is benefited from it being started sooner. Resource constraints are the likely reason for not delivering the service sooner. Example use cases are:

  • Activities associated with waiting time targets where the patient should not wait longer than x time for a first visit or treatment start
  • Activities that are critical to the patients health where the services should not be delivered later than x time due to health risk reasons

Approximate target date
A date that indicates that the service should be delivered x time in the future based on some rough period (1 day, 1 week, 1 month, 6 months…). Even if there are resources available before x time from now, it is not sure that the service should be planned sooner. There is an intent of the wait itself. The time passing has a value. It is not intended to be performed on this exact time, it is seen as approximate. Example use cases could be:

  • Follow up appointments and activities associated with them
  • Recurring treatments and checkups for chronic patients

When I read the description of Service due it sounds to be like what I refer to as an “approximate target date”. But that is not the only use case.

When digging into it more there are potentially other dates as well. Sometimes you want an Explicit target date, e.g. when coordinating multiple services at once. Lets say that the patient has a surgery planned already for a certain date. And you want to also perform a second procedure at the same time to avoid forcing the patient to be admitted at two different occasions, not performing the anesthetic twice etc. That I do not see as either a “Latest” or an “Approximate” date.

I guess my question is:

How should we distinguish these different timing concepts in the ServiceRequest?

2

Hi Martin,

Planning a service or a sequence of services can be nightmarishly complex. We can’t manage it purely in a single archetype, but there are layers related to UI, business logic etc that need to be considered in implementation.

The current published archetype contains what we feel are the most common dates, those most universally useful.

The ‘Service due’ will likely be the date most used. As stated in the data element’s comment: “In practice, clinicians will often think in terms of ordering services as approximate timing, for example: review in 3 months, 6 months or 12 months. As clinical systems need more exact parameters to operate on, this ‘3 months’ will usually be converted to an exact date 3 months from the date of recording and stored using this data element.” So this could be used as an exact date, but more likely it will be the computable form of the date resulting from ‘review in 3/12’ - a rough ballpark timing indicating when review should be carried out. This reflects the messiness of the bulk of medical practice, especially if the scheduling is carried out by a different person to who is doing the ordering.

The other dates:

  • Service period start - identifies the ‘hard start’ date and the service can’t be carried out before it has passed, eg 2 weeks post-operative so that the surgery has healed
  • Service period expiry - identifies the ‘hard stop’ date by which the service must have been carried out eg 2 days prior to surgery so that the results are available. This would be the same as your ‘latest target date’, I think. The archetype implies it can be done any time in the period prior, then the order is effectively no longer valid or useful. It is deliberately intended that this is more precise than a target date, which you could potentially either ‘hit or miss.’

Remember that this is an order. More often than not, the actual scheduling is done by a different party, maybe even at a different time, so the actual scheduled date/time is not often likely to be part of an order. In reality , the actual date on which the service is scheduled will be carried by the ‘scheduled date’ in an ACTION.

Reality is we don’t want too many dates, because while it may provide some temporary semantic satisfaction, it will also add difficulty with consistent data storage and querying. So the ‘service due’ is intended as the ‘messy bucket’ of exact or rough dates in combination with, or separate to, the additional constraints of “don’t do it before…” and “don’t do it after…”

In the Use, we are pointed to another archetype that might help us solve a sequence of the same service activities: “The default assumption for this archetype is that it’s a request for a single service. If a series of services are required, use the CLUSTER.service_direction archetype within the ‘Complex timing’ SLOT.”

If you are trying to coordinate multiple services, then this is outside of scope for a single archetype. You can set the hard stop for each service here, but the prioritisation, timing and scheduling could be ridiculously complex and may need to use any or all of task planning, GDL, querying, business logic, UI components to make it work together.

Happy to have new requirements identified about the single service. Also if you can identify suggestions for clarifying the descriptions. Please record as a change request in CKM

Hope this helps

Regards

Heather