Stream: implementers
Topic: Timing.repeat.durationUnits
Phuong Pedersen (Sep 04 2016 at 17:04):
Hi, we are in the process of implementing a care plan containg nurse service, but there are some durationUnits that are not supported or does not seem to be supported in the timing.repeat.durationunits. E.g. how do you spesifiy 3 times pr. duty or shift?
Lloyd McKenzie (Sep 05 2016 at 02:12):
@Phuong Pedersen That's not supported in the core specification - it would need to be an extension.
Phuong Pedersen (Sep 05 2016 at 06:58):
But is this not a quite normal case? What I mean that yes, we can add this as and extension, but as I understand extensions are not that easy to exchange with others. What is the process for elevating this to a be a part of the spec?
Grahame Grieve (Sep 05 2016 at 20:20):
you can propose a change by creating a task on gForge, but this doesn't sound like something easy to standardise at all
Lloyd McKenzie (Sep 06 2016 at 13:46):
@Phuong Pedersen The requirement isn't one we've seen come up in any of the previous HL7 standards, which suggests it's not terribly common - at least not in most parts of the world. If it's common in a particular country/region/organization, then defining an extension for use in that space and a profile setting expectations for the extension to be supported should be enough to drive interoperability.
Phuong Pedersen (Sep 06 2016 at 14:40):
Hi, that is does not occur in previous HL7 standard does not mean that it is not common, and improving standard must be a goal in it self :). I would think that most health care persons are working in shifts, since nobody can work 24x7. The duration of a shift can vary, e.g. the night shift longer than the day shift. I would also assume that working in shifts is not valid only in Norway, but is also common in Denmark and in Sweden to. I can talk with contacts in Spain, and most proplably they would answer me that working in shift is not uncommon.
@Grahame Grieve Grieve Why it is not easy to standardise? I would think that the 3 x day is even more difficult, because does that mean that it is 3 x when the pasient i awake or it is 3 x distributed over 24 hours. Our ERP system knows when a shift begins and ends because it contains some administrative part in it.
Lloyd McKenzie (Sep 06 2016 at 14:44):
@Phuong Pedersen Working in shifts is quite common. It's ordering a certain number of repetitions per shift that is the requirement we haven't seen before. (In part because shifts can be dynamic in length and typically the desired behavior can vary in different shifts. Given that we haven't encountered this as a requirement previously, the onus would be on the proposer to show that this is indeed a capability that ~80% of the systems that use the "Timing" element currently support. We're not looking for a specific numeric analysis, but would be looking for evidence that use of this concept is widespread in many systems in many countries.
Lloyd McKenzie (Sep 06 2016 at 14:45):
If the concept isn't widespread, we can certainly define it as a standard extension.
Lloyd McKenzie (Sep 06 2016 at 14:46):
In general, 3x/day means "roughly evenly spread out", though institutions may have policies. On the other hand "every 8 hours" means more precision in the timing.
Phuong Pedersen (Sep 06 2016 at 19:23):
And that is exactly my point also. The spec support 3xday and should support 3xshift, wich also mean "roughly evenly spread out" within a shift. What an insititusion configures as a shift is different yes, but this is a term that can be exchanged between institusjons and also understood. We are going to use this FHIR.Timing with the openehr instructions. This will give the health care personel an easy way of documenting what they are doing to/with the patient, but also give warnings or info if necessary. We can achieve this by in our case use extensions, but extensions should be used when something as you say is country/region/organization specific, but shift is as we already agreed widely commonly used :). I would therefore think that if it is available it would be used.
Grahame Grieve (Sep 06 2016 at 20:12):
what to the openEHR instructions say about this?
Grahame Grieve (Sep 06 2016 at 20:13):
and you can define your own code and define what it means in terms of how long your shifts are - e.g. if your shifts are 8 hours, then 2 * a shift is 6x a day
Phuong Pedersen (Sep 09 2016 at 17:33):
They are recommending to use the HL7 GTS, but since the FHIR is the newest version, we are going to use this. We have looked into it, and it covers all our timing spesifikasjon, but not shifts. Shift is a quite normal way of splitting up the day. We want to be able to specify: procedure should be done 2 x shift. Our local code for this i "v"(vakt =shift in Norwegian). Then we exchange this procedure information with a hospital in Sweden. They have a complete other code, for exactly the same. That means that some developer would write some code to convert this. The question is how many developers are going to do this? Also as @Lloyd McKenzie says: Shifts can be dynamic in length and typically the desired behavior can vary in different shifts. By using a code common for all, we abstract away the layer that should interpret the code.
Grahame Grieve (Sep 09 2016 at 23:14):
GTS won't help you. The Timing Data type is already way more capable than GTS
Grahame Grieve (Sep 09 2016 at 23:16):
I'nm going to guess that you'd only see 1/shift, 2/shift, and 3/shift. If so, one way to handle this with TIming now is:
Grahame Grieve (Sep 09 2016 at 23:17):
{
"code": {
"system" : "http://hl7.no/fhir/CodeSystem/TimingCodes",
"code" : "1/v"
}
}
Grahame Grieve (Sep 09 2016 at 23:18):
HL7 Norway can publish and curate your codes.
Grahame Grieve (Sep 09 2016 at 23:20):
This is not to say that we couldn't extend Timing to handle this more directly but there's several challenges:
- the periodUnit comes from UCUM, which has only concrete units.
- introducing an arbitary flexible unit makes interpretation of the data type much more relative
- adding arbitrary units will open a can of worms around what other arbitary units should be added ('ecnounter'?)
- no one else has expressed a requirement like this
Last updated: Apr 12 2022 at 19:14 UTC
