Stream: workflow
Topic: Scope/Purpose of FHIR Workflow
Thomas Schwere (Jun 30 2021 at 09:51):
(I'm completely new to FHIR workflow topics.)
I'm member of the Technical Committee of the IHE-RO (Radiation Oncology domain of IHE). I’m also chair of the IHE-RO DPDW (Discrete Positioning and Delivery Workflow) subgroup dealing with interoperability between devices from different vendors participating in a single radiotherapy treatment session.
The IHR-RO group mainly focused on DICOM integrating profiles so far. This year, we started working on a first profile using FHIR (XRTS – Exchange of Radiotherapy Summary between a treatment management system and an OIS/HIS).
Since FHIR got a lot of traction in the last couple of years (everybody/everything seems to move to FHIR), I was wondering about the intended scope or purpose of the FHIR workflow aspects. There is also a new IHE proposal for Orders-Based Imaging Workflow for Mobile OBIWm. At the very end there is an open question about what protocol the acquisition modalities (like CT, MR, or PET) prefer to get the scheduled activity from the Radiology Management System (FHIR Task vs. DICOM UPS-RS). The question is indeed why to transcode from FHIR to Modality Worklist and not use FHIR from the very beginning to the very end (at least in terms of the workflow aspect, the acquired data will remain in DICOM of course).
Now looking at a radiotherapy treatment session in the IHE-RO DPDW context:
"Nowadays radiation therapy treatment sessions performed at a delivery device can become rather complex. It's not only about the actual delivery of treatment but it also includes other procedures such as patient positioning, patient position monitoring or even real-time tracking of the tumor or its surrogates. In many cases there is no single vendor providing a solution for each of these very specialized disciplines. Therefore the devices involved in delivery of the treatment may come from different vendors. For example the treatment delivery system comes from vendor A, the patient positioning (or table top) system comes from vendor B and the registration system comes from vendor C. To allow a seamless integration of these components the Discrete Positioning and Delivery Workflow (DPWD) profile was introduced.
The profile specifies the workflow to transfer the procedures scheduled for a particular treatment session from the Treatment Management System (TMS) to the performing delivery device(s). Furthermore, it specifies how the treatment session is controlled and orchestrated by the so-called Treatment Session Manager (TSM) actor and how the procedures are distributed from the TSM to the actual performing device(s).
The DPDW profile makes use of the «Unified Worklist and Procedure Step» as defined in the DICOM standard and the DICOM Supplement 160 «Patient Positioning and Workflow». Supplement 160 is available in draft version only and is being worked out in close collaboration with the DPDW profile and 2nd generation DICOM RT."
I was wondering if this type of “micro-workflows” at a treatment device could be managed with FHIR Tasks and the like as well. Would be great to get other opinions about this.
Elliot Silver (Jun 30 2021 at 14:52):
@Jonathan Whitby, @Christopher Lindop thoughts?
Lloyd McKenzie (Jun 30 2021 at 14:54):
I'm the lead for the FHIR workflow project and my answer is "Maybe?". Real-time device control is not a use-case we've talked about. Almost all of the use of Task has focused on asynchronous processes that might take minutes or hours, while I presume this use-case requires actions to be taken in fractions of a second. If you had time synchronization across the devices, I think you'd probably have the data elements needed. My only concern would be whether the transmission overhead of a more complex syntax like FHIR would be too much for the timing requirements. I expect you'd need some experimentation to find out for sure.
Thomas Schwere (Jun 30 2021 at 15:16):
The orchestration of the workflow would happen on a rather high-level only. If a certain activity requires real-time interactions between the devices, this would go through dedicated HW interfaces. For example a system observing the patient position during radiation delivery would issue a beam-hold on a dedicated HW line if the patient position is not within tolerance anymore. Still the activities to be performed could be orchestrated using FHIR Tasks.
Lloyd McKenzie (Jun 30 2021 at 15:54):
Ok, then that should be feasible.
Elliot Silver (Jun 30 2021 at 22:07):
Thomas Schwere said:
At the very end there is an open question about what protocol the acquisition modalities (like CT, MR, or PET) prefer to get the scheduled activity from the Radiology Management System (FHIR Task vs. DICOM UPS-RS).
In my discussions with modality vendors, they don't want to implement FHIR (or V2) on their devices because it opens up a whole new technology stack on a regulated device. From my understanding their preference for this sort of thing is DICOM modality worklist, or (much further down the preference list, but still above FHIR, UPS-RS). Also, some consider FHIR too unstable at this point for a device with a 20+ year usable life (although many devices with a shorter lifespan--like a camera used for derm photos--may have a different position on this). On the other hand, no one seems to object to adding FHIR to the PACS/VNA.
Yes, @Lloyd McKenzie , I don't think we're talking about fine grained device control, but more about multiple systems all contributing various input into how the procedure is done. The actual dose delivery would be inside the control of a single device. FHIR Task is probably feasible, but unless there is a need for it, why introduce another protocol stack onto the device when DICOM should be able to handle it?
Thomas Schwere (Jul 01 2021 at 13:40):
@Elliot Silver What if the imaging modality has to pull in more information (e.g. pacemaker or allergies) about the patient to be scanned and DICOM modality worklist does not support this type of information (assuming that structured content is preferred over free-text fields)? FHIR would provide a much broader bandwidth of data. On the other hand, there might be a dedicated companion device (like a RIS client) next to the modality workstation where this additional information could be looked up.
I don't think we're talking about fine grained device control, but more about multiple systems all contributing various input into how the procedure is done.
Exactly!
Christopher Lindop (Jul 01 2021 at 13:53):
DICOM workflow protocol stack is either UPS (UPS-RS for REST) or Modality Performed Procedure Step (MPPS). Modality Worklist(MWL) is a separate service which I would argue is not workflow management, but the query of Scheduled Procedures Steps. These Scheduled Procedure Steps could be in any state of the actual workflow. They could be performed, cancelled in-progress, etc. UPS brings the two potentially separate services, MWL and MPPS, into a common service.
In practice, the majority of imaging devices have incorporated both MWL and MPPS, using the IHE Integration Profile, "Scheduled Workflow". However RIS and other clinical information systems, while supporting MWL, have used other means to manage the imaging procedure workflow. Adoption of MPPS by the IT systems is low to practically non-existent. This is what needs to be addressed. If it is workflow management through FHIR that will address the IT systems need, then I am all for it.
As we go forward in this new world of REST, we have an opportunity to address the shortcomings of the old technology, but we also must maintain the continuity and interoperability of the existing environment. Those 20+ year old devices aren't going too far. We will need to support a hybrid environment that may be with us for years to come.
The Imaging Integration WG is in the process of submitting a profile proposal to IHE Radiology for an Orders-Based Imaging Workflow for mobile imaging devices. I would expect most of the heavy work will need to be done in collaboration with other HL7 WGs in order to be successful.
Parnesh Raniga (Jul 28 2021 at 04:52):
Sorry to interject the conversation. We have been doing some work around how FHIR workflows can be implemented to facilitate clinical workflows. One particular area we have done a bit of work on is in radiology and integration of post processing steps into the workflow.
Unfortunately, our lab is more academic/applied science so I was not keenly aware of what was happening in the community. I would be keen to get involved, as an observer in some of these activities. The Orders-Based Imaging workflow sounds like what we have implemented as a prototype.
Lloyd McKenzie (Jul 28 2021 at 13:56):
Hi Parnesh,
We have weekly calls at 2 Eastern. We're more focused on how workflow functions in general than specific workflows, but you're certainly welcome to join. Details are here: https://confluence.hl7.org/display/FHIRI/FHIR+Workflow
Parnesh Raniga (Jul 28 2021 at 22:24):
Thanks Lloyd,
I'll try and sit in on a few. I will also try to make it to the Imaging Integration working group meetings that @Christopher Lindop mentioned (I think I just missed one) as that might be most directly relevant for me atm.
Last updated: Apr 12 2022 at 19:14 UTC
