Cross-Enterprise Reporting for Imaging - Proposal

From IHE Wiki
Revision as of 13:53, 23 September 2015 by Lindop (Talk | contribs) (9. Tech Cmte Evaluation)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

1. Proposed Workitem: XRR-WD Cross-Enterprise Remote Reporting for Imaging Workflow Definition

  • Proposal Editors:
Chris Lindop, Cezary.Klimczak, Ben Macerola, Canada Health Infoway (IHE Canada)
Mauro Zanardini, Claudio Saccavini, Arsenal.IT
Roberto Silverio, IHE Italy
Jean-Charles Dron, IHE France/Interop Santé
  • Editors: Mauro Zanardini & Chris Lindop
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

Summary

This proposal introduces further flexibility in the deployment of having medical images interpreted (read) by a reading specialist who is not present at the site where the image study was acquired.

Cross-Enterprise or Community Diagnostic Image Sharing Services are increasingly part of the infrastructure landscape in the clinical community. Leading the way are IHE profiles and standards, such as XDS-I providing the infrastructure framework for cross-institutional access of the patient’s clinical images and associated reports. Many such deployments are in operation world-wide in countries such as Canada, Italy, France, England, China, Denmark, Netherlands, Germany, and Switzerland. These deployments have expanded or consider expanding in two major directions:

  • The support of an increasing variety of clinical contents besides imaging such as patient summaries, laboratory results, and cardiology reports content taking advantage of the ability of their XDS and XCA infrastructures to convey such breadth of content.
  • The ability to distribute the image diagnostics interpretation workload within a community of radiologists. Remote reading, has the capability to attain efficiencies and reduce cost at a macro-scale level.

While this proposal was originally accepted as part of the work scoped for 2015, the technical committee chose an approach for RRR-WF based on the DICOM UPS-RS standard (the TI version is not yet published. The intent of the present proposal is to complement the RRR-WF profile with a profile that leverages the existing XDS infrastructure for workflow management (XDW). The complementary nature of this proposal is further discussed below.

2. The Problem

2.1 The General Need

Cross-Enterprise or Community Diagnostic Image Sharing Repositories is a growing service internationally and has proven effective for sharing of previously acquired images and reports. The current IHE XDS-I.b infrastructure effectively supports this. However, there is a lack of standards for the remote read. Currently, to meet this need, HCIT suppliers have built proprietary systems with non-standard methods for managing this workflow. Proprietary methods limit the solution extensibility, in particular when larger scale regional and national deployment are targeted

Cross-enterprise image sharing, beyond the initial step, has the capability to attain efficiencies and reduce cost at a macro-scale level:

  • Improve throughput of radiology depts by allowing any radiologist in the community to read and report a study
  • Align the number of resources (staff, equipment) with the needs of the community as opposed to considering individual hospitals only
  • Facilitate assignment of studies to physicians that are best qualified to read them (e.g., a SPECT expert may be leveraged across the community)
  • Provide off-hours coverage by sharing radiologists' services off peak hours

The supporting use cases are further discussed in Section 3.

2.2 The Complementary Nature of this Proposal

IHE Radiology developed a remote read for imaging profile in 2015. However, RRR-WF leverages a central workflow task manager imposed by the UPS-RS standards. With the XDW/XDS based approach the workflow actors operate in a peer to peer mode by reusing an existing XDS infrastructure. This is one of the differences between the two approaches that makes the XDW/XDS approach complementary to the UPS-RS based one.

More specifically:

1. Reuse of Document Registry/Repository

The deployment of XDW reuses the same XDS Registry/Repositories than those used for the sharing of imaging and reports when XDS-I is already deployed. No additional task manager as a central server in the infrastructure is required to be deployed, as it would be the case of RR-RWF with a DICOM UPS-RS. In addition no new transactions beside the XDS transactions already supported by the organization sharing images and reports are needed for the support of an XDW based workflow. (versus the 10 new transactions for RRR-WF as specified by UPS-RS).

2. Common Patient Identity

A critical factor with community-based workflow is the proper reading community-wide patient identity management. As XDS/XDS-I deployments have a proven method for patient identity management across organizations sharing images and reports, not only the same protocol stack (PIX/PDQ transactions plus the associated policies) but the organizational integration are directly reused for the support of an XDW based workflow. A new integration in the context of UPS-RS, but more importantly the challenge to keep the new central UPS-RS task manager coordinated with the XDS Registry/Repository would be required and pose additional challenges.

3. Security and Privacy

The policies and their implementations with the ATNA, BPPC and XUA security and privacy profiles would require a significant additional deployment effort, when the remote read capability is deployed where an existing XDS Affinity domain exists. The communicating organizations may be provisioned more easily by reusing the existing node security certificates, addressing the privacy of XDW workflow information as would be addressed additional content. The attributes and references included in task items do require the specification of a distinct privacy implementation both in term of protocol stacks but also due to the provision of a UPS-RS task manager server.

4. Workflow Extensibility beyond Radiology

IHE ITI has developed an extensible framework for cross-institution workflow sharing (XDW). IHE PCC has leveraged this framework for developing many workflow definition profiles with success. In regional/national projects where radiology information and workflows are only a subset of the range of information and workflows to be supported among organizations, although functionally fit for the job, the use of an imaging specific base standard, DICOM UPS-RS, may pose some challenges. A more generic approach utilizing XDW/XDS workflow is critical for minimizing the risk with large scale implementation projects based on XDS. An approach to workflow that addresses the need of radiology remote read, but is consistent with other workflows already deployed (e.g. referrals) is important and may not have been full accounted for.

5. Linking of Workflows

In some cases, the output produced by a workflow triggers the initiation of another workflow. In XDW a workflow instance may use or trigger another XDW based workflow, this becoming linked by a cause / result relationship (e.g. The remote read workflow can be generated by another remote read workflow in case of a sequential consult read request triggered by the first radiologist).

6. Common Terminology

When a large scale image sharing deployment is in place, common vocabulary for imaging information sharing needs to be in pace (body parts, procedures, etc.). This involves an expansive amount of carefully mapped local terminology to a common global vocabulary set. When an XDS/XDS-I infrastructure is in place, the same value sets would be used both for acquired images, reading tasks and reports. Implementation consistency is easier to verify when all objects containing such value sets are under a single registry.

7. Alignment with Clinical and Administrative Use Cases of XDS-I

Specifically, the XDS-I use cases facilitated by the following XDS metadata attributes would be supported out of the box:
  1. XDS Practice Setting Code – used in XDS-I to differentiate between radiology, cardiology, breast screening, and other settings/specialties. Similarly, in the context of remote reads, this code would be used to distinguish radiology remote reading requests in one setting from those in other settings. One group of remote readers may be focused on interpreting general-purpose radiology exams, while other may be performing breast screening reads exclusively.
  2. XDS Healthcare Facility Type Code – used in XDS-I to distinguish hospital-generated exams from outpatient-facility (clinic) exams, etc. Similarly, in the context of remote reads, this code would allow, for example, separation of remote reading requests coming from hospitals in the region from those coming from the region’s clinics. Thus, various classes of remote readers could easily target different facility types in the region.
  3. XDS Confidentiality Code – often used in XDS-I to hide VIP exams (XDS Registry automatically filtering them out) from the ordinary radiologist user. In the context of remote reads, this code would be used to appropriately mark the confidentiality level of each reading request and thus allow different readers to see a different set of exams in their reading worklists, depending on the role of the reader.

8. Remote Reading Worklist

The remote read requesters and the remote read performers are enterprise-level systems such as RIS and PACS. These systems are designed to manage the local acquisition and reading workflow, in which that often have some form of local worklist presented to radiologists within their enterprise. How external remotely requested reading tasks will be presented merged into the product local worklist, or in a dedicated external worklist is an implementation choice that should be left to the site along with the system vendor. Because XDW addresses the cross-enterprise side of the remote read activities, no concept of worklist is presented, only that of task with status changes as the workflow progresses.

9. Dynamic Model of Tasks

Given the dynamic nature of reading tasks, the subject referenced is commonly known as 'activity data' which are data still in high fluency. To ensure that the dynamics of all integrated systems is respected and the potential of using information that may be outdated is avoided, a “task-centric” pub/sub model should be used. This is proposed with the joint use of XDS/XDW and of the DSUB Profile. A DSUB Notification Broker is grouped with the XDS Document Registry and a DSUB Notification Recipient grouped with the Requester and Performer. This ensures that the XDS methodology (publish/query) remains the robust foundation, but that the most up-to-date information (non-patient centric notifications) is always available to Task Performers and Requester that have a business role to assume.

It is important to recognize that the RRR-WF profile (based on DICOM UPS-RS) has been designed to operate in conjunction with three mechanisms to access the data used in the reading task and for the Task Requester to access the resulting report.

The RRR-WF profile (based on DICOM UPS-RS) appears well optimized for use in conjunction with the DICOM Web and DICOM classic as mechanism for the Task Performer to access the data used in the reading task and for the Task Requester to access the resulting report.

However, the above challenges demonstrate that when the Remote Read workflow is used in conjunction with the XDS/XDS-I as mechanism for the Task Performer to access the data used in the reading task and for the Task Requester to access the resulting report, a Remote Read Profile based on XDW/XDS has considerable advantages. It is the objective of this proposal to complement the RRR-WF profile with such a new “XRR-WD” profile.

3. Key Use Case

The primary use case is workload sharing read.

For a workload sharing example, the specialty read of SPECT images is described:

The community hospital has a NM acquisition system fully capable of acquiring SPECT Images, but lacks a credentialed NM Radiographer to read SPECT. Per the institutional business rules, all SPECT images will require a NM credentialed Radiologist to perform the read. The regional image sharing network has NM credentialed Radiologists. Based on the institutional business rules, this study meets the criteria for Remote Read.
Other examples may include MR Neuroradiology reading or a cardiac stroke consultation.
For consistency with RRR-WF, it is proposed to cover the following workflow variants:
  1. Assigned (Push) workflow with the following workflow steps:
    1. Remote Read Request: The Remote Read Requester initiates the Remote Read Request specifying the reading task to be performed and provide the references to images and relevant clinical documents to one or more Remote Read Performers of its choice.
    2. Perform Remote Read: The first Read Performer that claims the request is responsible to process the read request. Other Read Performer may be notified that the task has already been claimed. The Final/Intermediate Report and any evidence documents as output of this task are referenced and the Remote Read Requester notified.
    3. Read Complete: The Remote Read Requester retrieves the Report and completes the Workflow. The Read performer is notified.
  2. Self-selected (Pull) Workflow with the following workflow steps:
    1. Remote Read Request: The Remote Read Requester initiates the Remote Read Request specifying the reading task to be performed and provide the references to images and relevant clinical documents to a Remote Read Dispatcher of its choice.
    2. Dispatch Remote Read: Once the Remote Read Dispatcher receives the request, the Remote Read Dispatcher will dispatch the Remote Read Request to one or more Read Performer that can meet the business constraints.
    3. Perform Remote Read: The first Read Performer that claims the request is responsible to process the read request. It notifies the Remote Read Dispatcher and other Read Performers that the task has already been claimed. The Final/Intermediate Report and any evidence documents as output of this task are referenced and the Remote Read Requester and the Remote Read Dispatcher are notified.
    4. Read Complete: The Remote Read Requester retrieves the Report and completes the Workflow. The Read Performer and the Read Dispatcher are notified.
Other Considerations
Wf.png

Uses cases for Workload sharing may include:

  • Site Loading (time-to-read exceeds threshold example)
  • Off hours coverage
  • Double Read (mammography example)
  • Consult (inconclusive read example)

Read Request Linkage

  • All Output documents linked via Accession Number and Accession Assigning Authority

For Other 'ologies':

  • Remote Read Workflow shall be extensible to other 'ologies' beyond Radiology. For example, for vascular stroke support in existing XDS-I infrastructures:
    • use case from ANAP in France – highlighted in red in picture.
    • A similar use case is needed in the Veneto region in Italy.

Specifically out of scope:

  • unifying procedure codes across institutions
  • Cross institution Imaging Acquisition protocoling, (protocoling performed locally by the Imaging Acquisition Service)

Transaction Flow and Performance:

  • For an Assigned (Push) workflow, the XDW workflow document will be updated 5 times for a complete workflow.
  • For a Self-selected (Pull) Workflow, the XDW workflow document will be updated 6 times for a complete workflow.
  • Each step in the workflow may require a query or notification, retrieve, provide and register (updated document).

4. Standards and Systems

Systems

  • RIS
  • PACS
  • EMRs/HIS
  • VNA
  • Community Image Sharing Network and Regional/National HIEs
  • Patient Identification Management (e.g. MPI)

Standards

  • XDS-I for hosting Images and reports
  • XDW underlying workflow profile framework
    • Compatible with XDS/XDS-I and XCA/XCA-I architecture
  • XBeR-WD Workflow Definition
    • Sufficient for Image Referral
  • DSUB for Notifications
    • DSUB can act as a notification mechanism for XDW results available/completed -OR- could be a trigger to receptionist to call Dr. XXX

5. Technical Approach

Existing actors

  • See XDW, XDS-I and DSUB

New actors

  • Remote Read Requester
  • Remote Read Dispatcher
  • Remote Read Performer

Existing transactions

  • See XDW, XDS-I and DSUB

New transactions (standards used)

  • None

Impact on existing integration profiles

  • This new profile XRR-WD
  • None – New Profile is proposed.

New integration profiles needed

Cross-Enterprise Remote Read Workflow Definition (XRR-WD): A content profile based on the Workflow Definition Template. This content profile captures, in a document, the Imaging Read Workflow definition for remote reading. The document is intended for use by the XDW Cross-Enterprise Document Workflow profile. This profile will be the first Workflow Definition based on XDW that will provide a structured format for the workflow definition itself. This will be based on “Workflow Definition BPMN” guidelines (a White Paper drafted by the IHE PCC Domain). Such a structured representation supports automation of several important efforts, including:

  • Generation of workflow documentation from the structured definition,
  • Construction of conformance requirements for workflow participants,
  • Development of test tools and simulators,
  • Implementation of and integration with workflow participants.

Technical Details for an XDW Workflow Definition Profile:

1. Sharing Infrastructure:

A Workflow Definition Profile based on XDW, is a profile that identifies Tasks, Tasks Relationships and Participants involved in a specific workflow. XDW defines a multi-purpose tool (the Workflow Document) that enables Workflow Definition profile authors to specify additional rules applicable to specific workflows. General rules about the management/sharing of the Workflow Document itself are inherited fromby the XDW profile. XDW profile relies on well-established sharing infrastructures. These sharing infrastructures are of various types:

  • Registry based document Sharing: XDS.b, PIX, PDQ;
  • Point to Point Document Sharing: XDR
  • Cross-Community Document Sharing XCA, XCPD.

All the three environment share for security and privacy: ATNA, ATNA RESTful Query, BPPC, XUA, SeR. Each one of these types of infrastructure may support the XDW workflow management infrastructure to take advantage from the whole set of profile identified to empower/support the document sharing itself (Security, Privacy, Auditing, Notification).

The picture below describes the scenario in which the XDW Workflow is managed by a Registry based infrastructure and shows how transactions of XDS.b, XDW and DSUB profiles operate.

XDW with XDS DSU Infrastructure.png

Figure 1: XDW with a XDS/DSUB infrastructure

The DSUB profile provides a Notification Infrastructure that allows triggering notifications when a new document, characterized by specific metadata, is published. Workflow Participants can subscribe their participation to a specific instance of workflow, or they can be notified for any workflow document published that meets specific requirements.

The XDW approach simplifies the Actor requirements of workflow participant: those systems are required just to consume the content of a Workflow Document and update it in accordance to the workflow definition rules.

2. Task Definition:

In this section we will briefly describe main tasks identified by the Remote Read workflow. XDW profile is an integration profile that allows describing tasks across the border of enterprises, so it is out of scope for this Workflow Definition profile, the description to describe internal processes that allows to accomplish a task within an enterprise itself.

  • Remote Read Request: this task allows a Read Requester to provide needed information to the Read Performer.
    • Required Task performed by the Read Requester actor.
    • INPUT:
      • Desirable: The original Referral from a distinct workflow (e.g. from the XBeR-WD workflow)
      • Desirable: The Scheduled procedure information (e.g. [RAD-4], HL7 OMI message content)
      • Desirable: Event Notification indicating clinically preformed procedure on the modality acquiring images
      • Required: URI for the path to the Image Manifest hosted by the XDS-I.b Image Document Source
    • OUTPUT:
      • Required: a Read Request document
      • Required: URI for the path to the Image Manifest referencing the acquired images and post-acquisition images and evidence documents, if any.
      • Desirable: the original imaging order or request
      • Optional: other relevant clinical content
    • Allowed TaskStatus:
      • COMPLETED: the task “born” completed or stays in this status if the output are revised.
      • FAILED: the task turn into this status if the task does not need to be completed anymore.
      • IN_PROGRESS: the task turn into an IN_PROGRESS status if output needs to be revised before the reading is requested
  • Dispatch Remote Read: this task allows a Read Dispatcher actor to dispatch read requests to a set of selected Read Performer actors. It is out of scope in this profile for this task to define the rules on how Read Performers are selected.
    • Optional task performed by the remote read dispatcher actor.
    • INPUT:
      • Required: Read Request Document
    • OUTPUT:
      • none
    • Allowed taskStatus:
      • CREATED: if the request is available, but not assigned
      • READY: if the request has a Service Performer identified
      • COMPLETED: if the request is assigned, note that this task may be born completed
      • FAILED: if the Request can’t be assigned, cancelled, or changes the target for the dispatching.
  • Perform Remote Read: this task allows a Read Performer actor to execute the reading requested.
    • Required task performed by the Read Performer
    • INPUT:
      • Required: a Read Request document
      • Required: URI for the path to the Image Manifest referencing the acquired images and post-acquisition images and evidence documents, if any.
      • Desirable: the original imaging order or request
      • Optional: other relevant clinical content
    • OUTPUT:
      • Required: Final Report
      • Required: Evidence Documents and additional images created while READ was performed
      • Optional: Preliminary Report
      • Optional: Addendum or Replacement of the Final Report
    • Allowed taskStatus:
      • READY: if the Dispatcher has completed the Dispatch task,
      • IN_PROGRESS: this task is added in this status when the Read Performer takes in charge the Read process
      • COMPLETED: this task is turned into status COMPLETED when the Final Report is created
      • EXITED: this task is turned into status EXITED when the Read Performer cannot complete the Read, but the Read may still be completed by another Performer.
      • FAILED: this task is turned into this status when no Performer can complete the Read.
  • Read Result Acknowledged: this task allows a Read Requester to acknowledge and accept the receiving of the Final Report created by a Read Performer
    • Required task performed by the Read Requester
    • INPUT:
      • Required: Final Report
      • Required: Evidence Documents and additional images created while READ was performed
      • Optional: Preliminary Report
      • Optional: Addendum or Replacement of the Final Report
    • OUTPUT:
      • none required
    • Allowed taskStatus:
      • COMPLETED: this task is created COMPLETED when the Read Requester retrieves and processes the final Report.

6. Support & Resources

Several operational environments with XDS and XDS-I deployed including those of Canada Health Infoway have led the development of this proposal and intends to collaborate with IHE on the development of the Remote Read Workflow Definition (XRR-WD).

PCC has collaborated with IHE Rad and should continue to be involved.

US VA has an extensive remote read need and would be a good candidate for working with on this profile. France, Italy, UK, Austria, the Netherlands and other regions within Europe who have deployed XDS, XDS-I and XDW.

Breakdown of tasks that need to be accomplished

The development of this profile could proceed as follows:

  1. . Prior to F2F, provide a resolution on all open issues with committee members
  2. . December 7th-11th 2015 face to face meeting:, produce and review a complete draft (Vol. 1 and Vol. 3)
  3. . February 15th-19th 2015, joint review between RAD and PCC in Germany at PCC Meeting
  4. . March (?) 2015, review and deliver Public Comment version in IHE Radiology Technical Committee
  5. . May (?) 2015, resolve comments and deliver Trial Implementation version in IHE Radiology Technical Committee.

7. Risks

As this profile is based on an established IHE profile, risks are minimal.

It would be useful to engage the collaboration of IHE PCC, given their experience with XDW workflow definitions and the recent white paper they produced.

  • [Toshiba-Kevin O] During related work last year there was some confusion over publication calendar and participation of collaborators. How will that risk be resolved this time?
  • [Agfa-Kinson] It is not clear what the state of the document should be regarding the February joined review meeting between RAD and PCC. Should RAD have already had its internal review meeting of the document that it captures all the radiology remote reading workflow need? Then the joined meeting will review with PCC the technical details about the use of XDW and Workflow Definition document?
  • [Toshiba-Kevin O] BPMN is somewhat complex. Time will be needed to get everyone up to speed.
  • [Agfa-Kinson] Is BPMN even necessary? It is not only new for Radiology, but also new for PCC from a profile usage perspective.
  • [Agfa-Kinson] It is true that use of XDW does not introduce any new transactions on top of existing XDS / XDS-I infrastructure. However, throughout the proposal, it seems like there are a number of related profiles (DSUB, MPQ (not mentioned but required for non-patient centric work)) and technologies (BPMN) that are mandatory or highly desirable to satisfy the complete workflow. These additional profiles and technologies will introduce new transactions that are not necessary available today in XDS-I infrastructure.
  • [Agfa-Kinson] Today, most XDS / XDS-I deployments are used for sharing of existing documents. This means it is used as a 'secondary' infrastructure in the sense that the 'main activity' is done within its regular infrastructure and when the work is complete, share the result to XDS / XDS-I. For remote reading, because the reading task is now externalized, using XDW on top of an XDS / XDS-I infrastructure means that this 'secondary' infrastructure has to be promoted to become a part of the 'primary' infrastructure. This implies studies that are just received (instead of reported) have to be published as a manifest in order for Remote Read Performer to work on. This further implies that there is a higher chance of changes to the study that requires update to the manifest. IOCM and XDS Metadata Update can facilitate this, but they are not mentioned.
  • In addition, since the workflow is captured as a document using XDW, and the document will be updated frequently during a workflow, this means the XDS infrastructure, in particular the Registry and Repository, will receive 6x-8x more load to facilitate the workflow handling. This is on top of the potential higher frequency of source document update mentioned above. Is this workload anticipated by existing infrastructure?

8. Open Issues

  • [Toshiba-Kevin O] Breakdown of tasks section needed. Resources section includes a committee meeting calendar.

[Mauro]The template for a Workflow Definition profile was defined by the PCC domain. Breakdown of tasks is a specific section of the document "X.3 Tasks Specifications". This section defines rules for transition between tasks. In the detailed proposal we decided to focus just on the task-status evolution.

  • [Toshiba-Kevin O] Will XDW address Open Worklists too or just Assigned Worklists?

[Mauro] The XDW task can identify an expected owner of the task itself or can leave the task without owner until the workflow is taken in charge by someone. Both the solutions can be profiled in the Workflow Definition. The individuation of an owner can be done by a workflow Orchestrator or by the Read Requester, that could identify the radiologist that is intended to complete the Perform Read task.

  • [Toshiba-Kevin O] During original development of XDS, questions of race conditions were dismissed under the premise that XDS is designed to be a distributed archive, not used for realtime workflow. As that point is addressed, what performance will be required of registries and repositories to ensure acceptable workflow management?

[Mauro] Actually XDW can solve the problem of race condition in XDS.b via workflow definition: A workflow definition can require that, when a system takes in charge the workflow, it SHALL update the workflow document adding a new task in status = "CREATED" and identifying itself as the owner. This update need to be done before to start any clinical activity. When this is done, no other systems can take in charge the workflow.

  • [GEHCIT - Chris Lindop] Allocating workload based on business rules by making decisions (requester or dispatcher) to assign remote read requests to 1:n performer might be challenging at a larger/national scale, especially with requester-specific or performer-specific business rules for remote reading (urgency, specialty, off hours, availability, etc.).

[Mauro]You are right. So both the approaches need to be profiled.

  • [GEHCIT - Chris Lindop] Like a worklist-based pool concept for reading tasks in a local department, a pool concept for remote reading tasks to be picked-up at enterprise level might help to avoid rule-based workload allocation at an affinity-domain-level.
  • [Agfa-Kinson] The Self-Selected (Pull) Workflow, as described, seems to be a variation of a push workflow because the dispatcher (instead of the requester) is still assigning the performer. A true pull workflow should have the performer queries the dispatcher for workitems based on certain conditions.

[Mauro] Any request to do work still needs an acknowledgement in order to perform. The performer still needs to be assigned and cannot assume it will be allowed to do the task. For a variety of reasons defined by the collaboration model. The site may have exceeded the total quota allowed for it’s site. The reasons to not assign are collaboration-specific and should be considered out-of-scope.

[Kinson] Agree that the Performer still needs to be assigned. In this case, should the Performer query the Dispatcher for task and the Dispatcher can apply any business rules to return the tasks that the Performer has access to, then eventually the Performer will turnaround to claim the tasks that it wants to perform? This way the Dispatcher has no pre-assignment of tasks to any performer.

[Mauro] Actually the concept of dispatcher in the XRR is different, than the one you have in mind (probably is just a mis-wording issue, or we used the wrong name for this actor… we can clearly discuss it and revise it!). What you are defining as "dispatcher" for me is the XDS Registry. Following the discussion below, you could query the Registry using the MPQ approach (or going through pending notifications...) filtering on:

  • Type of workflow
  • State of the workflow (OPEN, CLOSED)
  • Some other details that can be profiled as a XDS metadata binding for the XRR-WD, for example using the eventCodeList metadata (I'm pretty new in the RAD domain, however the Requester could, for example, specify the type of images that it is attaching for the read, and so forth... ). This is exactly the details that we need to profile in the Workflow Definition.
  • [Agfa-Kinson] XDS is patient-centric in the sense that all transactions require the XAD PID. Given XDW is using the underlying XDS infrastructure, what additional profiles (e.g. MPQ) is necessary to support non-patient-centric remote reading workflow? Or does this profile only address patient-centric remote reading workflow?

[Mauro] XDW is patient centric. It is necessary to know: XAD PID or WorkflowInstance ID to be involved in the workflow. However, a non-patient-centric workflow could be approached using the DSUB notification infrastructure. Using DSUB it is possible to create non-patient-centric subscriptions. The Performer is notified for all the OPEN workflow documents related to ongoing remote read processes. Metadata does not provide more detailed information about workflow evolution, so it is anyway necessary to consume the workflow Document itself to understand the state of the process. Clearly this can be done automatically when a notification is received.

[Kinson] Agree. DSUB can provide this non-patient centric notification and it is very nice. During the discussion at Infoway that Chris also participated in, one thing we agreed is that no matter how good the notification method is, there are always cases that a fallback with on-demand query is necessary (e.g. unreliable network causes notification to be lost). In this case, what are the options? Or is notification the only available option?


[Mauro] No, we have some other robust ways to solve this: for example using the Pull Style Approach for notification retrieval. DSUB define additional functionalities to pull notification directly from a pull-point. There is an in-coming CP that suggest the possibility to group the broker (the actual system that send notification) with the pull-point (the actual system that can be queried for pending notifications) so that a Recipient (the actual system target for of notification produced) can query directly this gouged actor to request notifications. As you suggested, MPQ can be another approach that does not break the XDW concept of patient centricity. This was not discussed before, however we can analyze the needs within this work-item.

  • [Agfa-Kinson] Given that XDW can lay on top any ITI infrastructure profiles such as XDS, XDR, XDM, is this profile going to be used with XDS only or not?

[Mauro] Usually a Workflow Definition profile can restrict the application fuel of XDW. In this proposal we rely on DSUB we would require XDS as a sharing infrastructure for workflow documents.

[Kinson] Understood and agree.

  • [Agfa-Kisnon] Not sure I understand the comment about this profile being peer-to-peer and RRR-WF requires a central task manager. Doesn't this profile also requires a central Registry to manage all the workflow definition document transaction?

[Mauro] "With the XDW/XDS based approach the workflow actors operate in a peer to peer mode by reusing an existing XDS infrastructure" is probably a bad wording. We can fix that saying that the process is managed by the edges of the workflow itself. This is the basic concept of the XDW workflow management infrastructure, a centralized orchestrator that distributes tasks is not needed (however in some cases it can be useful…). For the second note, yes as we are using XDW in a XDS infrastructure, a centralized Registry is needed BUT one of the key point of the proposal is that we would be able to manage the Remote Read workflow in a environment where an XDS infrastructure is already established. So no addition behavior need to be added to the Registry system.

[Kinson] Agree. Given an XDS infrastructure is already established, then no additional behaviour is required for the Registry. The only implication is that there will be lots of small deprecated documents stored in the repository because of the workflow document update.

[Mauro] You are right. However as you know, document retention is domain specific, and specific rules can be applied for non-clinical documents (such as the Workflow Document). In our regional implementation of XDW workflows we planned to address this over load of documents in this way:

  1. Delete document Set transaction to delete document entry in the registry: we will delete deprecated WD with closure date > 2 years
  2. We will move off-line workflow documents from repositories with the same rule.

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Committee Bandwidth):

Responses to Issues:
40%
Candidate Editors:
Mauro Zanardini, Chris Lindop