Stream: implementers
Topic: Allow Multiple Flags in List.entry
Alexander Kiel (Jul 14 2020 at 11:31):
We believe to have a use-case for multiple flags on List entries. One flag would be workflow information around a distributed transaction like pending, final because we put things on the list which have to be acted upon in another system. The other flag would be a status flag which encodes the status of the referenced item at the time of list addition. We have to encode the status directly in the FHIR List because the other system has no history. So we couldn't use something linke versioned references.
Currently List.entry.flag is 0..1 to CodeableConcept. Would it be possible to that that to 0..* in future versions? Are there other use-cases which require multiple flags? If my use-case is somewhat special, I can just use an extension.
Vassil Peytchev (Jul 14 2020 at 14:33):
"Workflow information" and "distributed transaction" seem to indicate a use case that is pushing the limits on List. Can you provide more details?
Jose Costa Teixeira (Jul 14 2020 at 17:38):
One case that requires multiple "tags" like you have @Alexander Kiel is indeed in workflows: we can have different statuses for workflows: e.g. "performed" and "not billed" can co-exist.
Jose Costa Teixeira (Jul 14 2020 at 17:40):
..and I could swear that task.businessStatus was 0..* because of that, but it isn't... @Lloyd McKenzie was that a decision or something missed?
Lloyd McKenzie (Jul 14 2020 at 17:52):
I don't think a use-case for 0..* was ever raised. And I'm not sure I understand that in this context. How could a single Task have multiple business states simultaneously? If we were talking about sub-tasks, then each would have their own independent status.
Jose Costa Teixeira (Jul 14 2020 at 17:56):
Say a Task holds information about the overall procedure (mother of all tasks for that workflow)
Jose Costa Teixeira (Jul 14 2020 at 17:58):
from a clinical perspective, the status can be "done". From a hospitalizationperspective, the status is "done" but from the billing perspective can be "hold on a minute..."
Jose Costa Teixeira (Jul 14 2020 at 18:01):
Even for simple/simplified workflows the number of combinations "dispensed" "administration started" and "change requested" explodes. And those statuses are orthogonal.
Jose Costa Teixeira (Jul 14 2020 at 18:02):
I had this very clearly impacting our BI system a few years ago: something as simple as "how long the patient is waiting" depends if you consider the status waiting when the patient arrives, or when the procedure was supposed to start.
Lloyd McKenzie (Jul 14 2020 at 18:08):
The Task being 'done' is driven by who's doing the performing
Lloyd McKenzie (Jul 14 2020 at 18:08):
If the filler has completed what they intended to do, then it's "complete" - whether the filler thinks it is or not
Jose Costa Teixeira (Jul 14 2020 at 18:18):
I have always assumed in our discussion that some tasks may not have a performer but may be split into sub-tasks, those having a performer (or split into sub-sub-tasks)
Jose Costa Teixeira (Jul 14 2020 at 18:20):
As I delegate a task into 2 sub-tasks, I need to keep a state for my parent task
Lloyd McKenzie (Jul 14 2020 at 18:27):
The state on the parent task represents the overall state. It doesn't aggregate up the states of sub-tasks
Jose Costa Teixeira (Jul 14 2020 at 19:20):
I don't understand the meaning of aggregate in this case.
Jose Costa Teixeira (Jul 14 2020 at 19:22):
simple scenario: if for some reason you need to report "status of a prescription" or better "status of a treatment triggered by a prescription",
and that status is composed of "billing status" or "distribution status" or "administration/clinical status".
Jose Costa Teixeira (Jul 14 2020 at 19:23):
that is the scenario I would see a businessStatus 0..*:
status 1 is for billing, 2 for distribution, 3 for clinical
Jose Costa Teixeira (Jul 14 2020 at 19:24):
the overall status I agree (that is our premise) cannot be calculated. But there are conclusions you can take from different perspectives, and those matter to be kept somewhere.
Jose Costa Teixeira (Jul 14 2020 at 19:55):
This a good topic for a monday workflow call?
Lloyd McKenzie (Jul 14 2020 at 20:15):
Task doesn't reflect "status of a prescription". It reflects "status of fulfillment of prescription". So if sent to a pharmacy, it would reflect whether it's been dispensed. Whether they've billed for it isn't really relevant.
Jose Costa Teixeira (Jul 14 2020 at 20:26):
one level higher or lower: what is the status of "dispensed" when the dispenser needs to create different tasks like supply, unpack, mix, repack, label, deliver?
Jose Costa Teixeira (Jul 14 2020 at 20:27):
I expect to have a placeholder for things like "in progress, pending external delivery"
Jose Costa Teixeira (Jul 14 2020 at 20:42):
(i mean, this can be handled by an extension, but the notion that a task can be split in subtasks seems core, and I think this is a good way to fulfill the requirement of capturing the different perspectives of the status of performing an activity when that activity is subtasked)
Lloyd McKenzie (Jul 15 2020 at 02:55):
That would be fine text for the business status. But that's still a single status.
Jose Costa Teixeira (Jul 15 2020 at 06:30):
the problem with that is that from one perspective we need "in progress, pending external delivery", but others will need "in progress" - and those are orthogonal
Lloyd McKenzie (Jul 15 2020 at 17:18):
"in progress" is the base Task.status. "pending external delivery" would be the business status.
Alexander Kiel (Jul 15 2020 at 19:02):
Vassil Peytchev said:
"Workflow information" and "distributed transaction" seem to indicate a use case that is pushing the limits on List. Can you provide more details?
Sorry for the late answer.
We have a biobank management system holding specimen and containers were specimen are located. For a use case of tracking the relocation of specimen, we decided not to enhance the original system. Instead we decided to use List resources stored on a FHIR server.
In case the user starts such a relocation process, a new List resource is created. If the user decides to relocate a specimen, we have to do two things. First we have to remove the specimen from the container in the original system and second, we have to put the specimen on the List. That's a distributed transaction. To handle it, we first put the specimen on the list with a flag with a concept of pending, second we remove the specimen from the container and lastly we update the flag to final.
The second flag we need is that of a missing information. A specimen not found during the relocation process should be put onto the List with an additional information that it was actually missing in the process.
Lloyd McKenzie (Jul 15 2020 at 19:07):
Is there any reason you don't just track the location of the Specimen on the Specimen instance itself? That would seem simpler...
Vassil Peytchev (Jul 15 2020 at 19:12):
And if you need to track the "steps" of the process, why not use Task, with a focus referencing the Specimen?
Alexander Kiel (Jul 16 2020 at 11:01):
Lloyd McKenzie said:
Is there any reason you don't just track the location of the Specimen on the Specimen instance itself? That would seem simpler...
The Specimen doesn't exist as a resource in the FHIR server. I use a reference with identifier to reference it in the original system.
Jose Costa Teixeira (Jul 16 2020 at 11:03):
if this is about transporting items, don't you want to use the Supply... stuff? that is what it was designed for.
Jose Costa Teixeira (Jul 16 2020 at 11:04):
the whereabouts of the items - that is inventory status, and we started looking at that recently
Last updated: Apr 12 2022 at 19:14 UTC
