Latest revision as of 20:31, 17 August 2012

IHE Profile Proposal (Brief)

1. Proposed Profile: Radiology Acquisition Workflow

Proposal Editor: Norinari Honda
Editor: Makoto Suzuki
Domain: Radiology and Other Imaging Acquisition Domains

2. The Problem

Some countries have adopted HL7 V2.5.1 as a national standard. For vendors deploying systems in such countries, implementing HL7 V2.3 is development overhead with no market value. Although a V2.5 option has been added to the Scheduled Workflow Profile, it still requires implementing HL7 2.3.

On the other hand, V2.3 and SWF is already in use, we can not abandon it. Establishing SWF.b with V2.5 as a baseline would resolve the issue.

SWF also duplicates functionality described in PAM. SWF.b could factor it out.

3. Key Use Case

The primary use cases would be the same as SWF.

The key discussion will be selecting/scoping additional features (e.g. Exam start/"complete" signals, protocol selection, )

Some specific features in HL7 2.5.1 to leverage include:

Explicit trigger that initiates action of Evidence Creator helps interoperability of systems within the enterprise. <Suzuki-san, can you clarify?>
Messaging for cancellation, modification, or abortion of (a part of) examination.
Expandability to cope with local situations:
- Describing exam details in OBR
- Data availability notification such as for urgent reading
- Specifying Study Instance UID
- Exception Management Workflow
- Capacity of ORC for future extension

4. Standards & Systems

Affected Systems: RIS, PACS, Modalities

Standards: DICOM, HL7 V2.5

5. Discussion

ORM vs OMG/OMI

ORM should be replaced with OMG. OMG is more robust and capable of handling coded data.

OMI will also reduce the number of messaging/processing burden.

Data Availabilty Notification

There is no simple method to signal data and/or resource availability to scheduler. Subscription Request in DICOM UPS may be a solution.

PPS to include imaging protocol

Imaging/post-processing protocol should be independent UPS or DICOM objects, and they should be defined in DICOM first. And it should be outside of SWF/SWF2.

Possible Transaction Changes

[RAD-02]: replace ORM with OMG
[RAD-03]: replace ORM with OMG
[RAD-04]: replace ORM with OMI
[RAD-13]: replace ORM with OMI
[RAD-xx]: add new transaction to notify data/resource availability using OMI

SWF vs SWF.b

Recommend maintaining both profiles separately rather than more CPs to SWF to keep conformance to SWF2

HL7 2.5.1 has been defined as standard by the US Department of Health and Human Services in several domains. (http://www.gpo.gov/fdsys/pkg/FR-2010-10-13/pdf/2010-25683.pdf).

@@ Line 2: / Line 2: @@
 =IHE Profile Proposal (Brief)=
-==1. Proposed Profile: Imaging Acquisition Workflow - Radiology==
+==1. Proposed Profile: Radiology Acquisition Workflow==
-* Proposal Editor: Chris Lindop/Tony Palmer/Herve Hoehn
+* Proposal Editor: Norinari Honda
-* Date:    N/A (Wiki keeps history)
+* Editor: Makoto Suzuki
-* Version: N/A (Wiki keeps history)
 * Domain: Radiology and Other Imaging Acquisition Domains
 ==2. The Problem==
-The Scheduled Workflow Integration Profile pioneered the use cases for integrating Systems which specialized in Order Placement/Department Scheduling Image Management and Image Acquisition Systems (i.e. CT, MR, US, etc)  with DICOM MPPS.  At this time, it was the current “state of integration” for integration order placers with order fillers.  While with Image Managers, the value proposition is clear.  PPS provides a mechanism for Image Managers to associate images acquired by modalities with procedures scheduled by Radiology Information Systems.  The value for Radiology Information Systems is less clear.  The value provided is minimal and insufficient for a RIS to fully automate workflow based solely on a MPPS message coming from a RIS.
+Some countries have adopted HL7 V2.5.1 as a national standard.  For vendors deploying systems in such countries, implementing HL7 V2.3 is development overhead with no market value.  Although a V2.5 option has been added to the Scheduled Workflow Profile, it still requires implementing HL7 2.3.
+On the other hand, V2.3 and SWF is already in use, we can not abandon it.  Establishing SWF.b with V2.5 as a baseline would resolve the issue.
+SWF also duplicates functionality described in PAM.  SWF.b could factor it out.
 ==3. Key Use Case==
-This Integration profile leverages the same use cases as scheduled workflow at a high level.  Some of the key information not addressed by MPPS includes some basics; exam Start, Exam Complete, Technologist performing the acquisition to name a few.  The current workflow in SWF is only focused on the acquisition of the images only and not the clinical elements of the image acquisition.
+The primary use cases would be the same as SWF.
-Also missing is key feedback with actionable items for a tech to perform while the study is in session.  This would include re-takes, additional protocols, etc.  The current use cases cover this level of interoperability in a generic sense (i.e append). But they do not address the specific needs and is not clearly defined.
-Error conditions are not handled effectively and are in most cases optional.  This revision of scheduled workflow needs to be an upgrade to the existing transactions, making the interfaces truly interoperable.
+The key discussion will be selecting/scoping additional features (e.g. Exam start/"complete" signals, protocol selection, )
+Some specific features in HL7 2.5.1 to leverage include:
+* Explicit trigger that initiates action of Evidence Creator helps interoperability of systems within the enterprise. <Suzuki-san, can you clarify?>
+* Messaging for cancellation, modification, or abortion of (a part of) examination.
+* Expandability to cope with local situations:
+** Describing exam details in OBR
+** Data availability notification such as for urgent reading
+** Specifying Study Instance UID
+** Exception Management Workflow
+** Capacity of ORC for future extension
 ==4. Standards & Systems==
-The existing systems include Radiology Information Systems, Diagnostic Imaging Devices and PACS.
+Affected Systems: RIS, PACS, Modalities
-Standards: DICOM
+Standards: DICOM, HL7 V2.5
 ==5. Discussion==
-Uptake of SWF Order Filler actor is low or in-effective due to the missing capabilities described above.  The goal of this Integration Profile is to focus on the interoperability of RIS and Modalities.  To make this interface robust and, most important, effectively usable by Order fillers.
+===ORM vs OMG/OMI===
-It will also need to be decoupled with the order filler.  In many cases, order fillers in an out-patient setting receive referrals or include the order filler and ADT role embedded in their application.  By decoupling the Order filler role from the order placer role, the implementing system can focus on only transactions associated with managing the fulfillment of an order and not necessarily how the order was received.
+ORM should be replaced with OMG. OMG is more robust and capable of handling coded data.
+OMI will also reduce the number of messaging/processing burden.
+===Data Availabilty Notification===
+There is no simple method to signal data and/or resource availability to scheduler. Subscription Request in DICOM UPS may be a solution.
+===PPS to include imaging protocol===
+Imaging/post-processing protocol should be independent UPS or DICOM objects, and they should be defined in DICOM first. And it should be outside of SWF/SWF2.
+===Possible Transaction Changes===
+* [RAD-02]: replace ORM with OMG
+* [RAD-03]: replace ORM with OMG
+* [RAD-04]: replace ORM with OMI
+* [RAD-13]: replace ORM with OMI
+* [RAD-xx]: add new transaction to notify data/resource availability using OMI
+===SWF vs SWF.b===
+Recommend maintaining both profiles separately rather than more CPs to SWF to keep conformance to SWF2
+HL7 2.5.1 has been defined as standard by the US Department of Health and Human Services in several domains. (http://www.gpo.gov/fdsys/pkg/FR-2010-10-13/pdf/2010-25683.pdf).

Difference between revisions of "Scheduled Workflow 2.0 - Brief Proposal"