Scheduled Workflow 2.0 - Brief Proposal: Difference between revisions
No edit summary |
|||
| (7 intermediate revisions by one other user not shown) | |||
| Line 2: | Line 2: | ||
=IHE Profile Proposal (Brief)= | =IHE Profile Proposal (Brief)= | ||
==1. Proposed Profile: Radiology Acquisition Workflow== | |||
* Proposal Editor: Norinari Honda | |||
* Editor: Makoto Suzuki | |||
* Proposal Editor: | |||
* | |||
* Domain: Radiology and Other Imaging Acquisition Domains | * Domain: Radiology and Other Imaging Acquisition Domains | ||
==2. The Problem== | ==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== | ==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== | ==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). | |||
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).