Scheduled Workflow 2.0 - Detailed Proposal - 2012-2013

From IHE Wiki
Jump to navigation Jump to search

1. Proposed Profile: Radiology Acquisition Workflow

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

Summary

Today, systems cannot comply with IHE without supporting V2.3 transactions that will never be used in a growing number of environments. Japan does not use V2.3. The U.S. is in the midst of migrating (e.g. DHHS specification of V2.5.1)

The V2.5.1 Option in SWF demonstrates that a V2.5 spec is feasible/reasonable.

A SWF2 Profile would allow countries/regions to baseline on V2.5 without the dilemma of either leaving IHE or burdening vendors with the development of unused code. SWF is still available for countries/regions that need to maintain V2.3 compatibility. SWF2 provides a path forward and with SWF backwards compatibility is not broken.

IHE facilitates migration by adding profiles for new methods and eventually retiring profiles for old methods.

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.

Tensions exist today. If the IHE Japan Connectathon passes systems for SWF without testing HL7 V2.3, or if companies publish IHE Integration Statements claiming SWF without implementing HL7 V2.3, then the meaning/validity of IHE Profiles is damaged.

On the other hand, V2.3 and SWF is already in use, we can not abandon it. Establishing SWF2/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.

"Ordinary" imaging request

  • A doctor places a new order (imaging request) on an Order Placer
  • [RAD-2] DSS/Order Filler receives the request and schedules it
  • [RAD-48] DSS/OF notifies the Order Placer
  • [RAD-4] DSS/OF notifies the Image Manager/Image Archive
  • [RAD-5] Modality and/or Evidence Creator query the DSS/OF for the worklist
  • [RAD-6,7] At study time Mod sends MPPS InProgress/Completed to the DSS/OF via PPS Manager
  • [RAD-20,21] EC sends Creator PPS InProgress/Completed to the DSS/OF via PPS Manager
  • [RAD-8,18] Modality/EC sends acquired/created images to Image Manager/Image Archive
  • [RAD-10] Modality/EC request/obtain Storage Commitment from IM/IA
  • [RAD-49] IM/IA notifies availability of the images to the DSS/OF
  • [RAD-35] DSS/OF notified Charge Processor of billing and material information


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

4. Standards & Systems

Affected Systems: RIS, PACS, (Modalities)

Standards: HL7 V2.5, (DICOM), IHE Scheduled Workflow Profile (and transactions)

5. Technical Approach

Some specific features in HL7 2.5.1 to leverage include:

  • Messaging for cancellation, modification, or abortion of (a part of) examination.
  • Expandability to cope with local situations:
    • Describing exam details in OBR
    • Instance availability notification such as for urgent reading
    • Specifying SOP Instance UID
    • Exceptional triggering is considered as Exception Management Workflow
    • Capacity of ORC for future extension

PAM Factoring

Omit the ADT Actor from SWF2 and drop the RAD-1 (Patient Registration) & RAD-12 (Patient Update) transactions.

The PAM Profile handles these.

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.

Specific field changes are proposed in the [V2.3and2.5SegmentDifferences] evaluation from IHE-J.

Instance Availability Notification

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

Instance Availability Notification is not adequate because <<...>>

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.

<<The above sentence needs clarification>>

Existing actors

The profile would affect:

  • Order Placer
  • Order Filler
  • Image Manager/Archive
  • PPS Manager (might be able to go away)

Although changes to DICOM transactions could be considered, no need is currently seen so Modality would be unaffected.

New actors

None

Existing transactions

  • [RAD-02] Placer Order Management : replace ORM with OMG (in a new transaction)
  • [RAD-03] Filler Order Management : replace ORM with OMG (in a new transaction)
  • [RAD-04] Procedure Scheduled : replace ORM with OMI (in a new transaction)
  • [RAD-13] Procedure Updated : replace ORM with OMI (in a new transaction)

New transactions (standards used)

  • see above
  • [RAD-xx]: notify data/resource availability using OMI

Impact on existing integration profiles

SWF would continue until it is appropriate to retire it.

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

New integration profiles needed

SWF2 would be available for regions that find HL7 2.3 implementation/testing to be additional overhead with no interoperability benefit.


Breakdown of tasks that need to be accomplished

  • Clone SWF text to SWF2/SWF.b
  • Add dependency on PAM; Drop references to ADT, RAD-1, RAD-12
  • Draft revised transactions for 4 procedure transactions
  • Draft new transaction for OMI-based data availability notification
  • Discuss/decide on other additions

6. Support & Resources

IHE Japan is very interested in seeing this move forward and will recruit editors and reviewers.

Other parties with an interest in V2.5.

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

Review discussion of IHE-J segment proposals.

Should we add Worklist Query for evidence creator? (Or is that PAWF)

Is there an issue with Instance Availability Notification?

  • "The Image Manager/Image Archive, after having received the last instance of the instance set referenced in the MPPS, shall send an Instance Availability Notification to the DSS/Order Filler that has also received the related MPPS."
  • "One Instance Availability Notification shall be sent for each MPPS that contains references to instances."
  • "[The Instance Availability Notification SOP Instance] shall include references to all instances that are referenced in the corresponding MPPS."
  • But DICOM expects all instances created to be listed in the MPPS even if they are not sent to PACS.

9. Tech Cmte Evaluation

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

  • XX% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA
Retrieved from "http://wiki.ihe.net/index.php?title=Scheduled_Workflow_2.0_-_Detailed_Proposal_-_2012-2013&oldid=63876"