Difference between revisions of "Rad Tech Minutes 2009.01.27-30"
Jump to navigation
Jump to search
Chrisdcarr (talk | contribs) |
Chrisdcarr (talk | contribs) |
||
Line 17: | Line 17: | ||
::* Remote reading model employed frequently requires access by radiologist to multiple image sources | ::* Remote reading model employed frequently requires access by radiologist to multiple image sources | ||
− | + | * '''Moving Radiology to shared model of ITI XDS for Web services''' | |
− | : | + | :1. '''Retrieve Transactions''': Radiology should replace DICOM/Wado transport mechanisms with Web Services image retrieve transaction as compatible as possible with document retrieve method in XDS.b |
:::* DICOM WG27 will help with specification of those transactions; ITI needs to coordinate with DWG27 to review divergences between the transactions defined for radiology and the general XDS retrieve model (retrieve document set) | :::* DICOM WG27 will help with specification of those transactions; ITI needs to coordinate with DWG27 to review divergences between the transactions defined for radiology and the general XDS retrieve model (retrieve document set) | ||
:::* Need to consider responsiveness needs of the use case (synch/asynch; pipeline/non-pipeline queries and responses) | :::* Need to consider responsiveness needs of the use case (synch/asynch; pipeline/non-pipeline queries and responses) | ||
Line 29: | Line 29: | ||
::::* Intra model has more precise query requirements | ::::* Intra model has more precise query requirements | ||
− | : | + | :2. '''Query Issues''' |
::* Can Radiology simplify the "three-layer" model of XDS-I: query to registry/reference to repository (with manifest only)/image source by enabling storage of images themselves in the repository layer | ::* Can Radiology simplify the "three-layer" model of XDS-I: query to registry/reference to repository (with manifest only)/image source by enabling storage of images themselves in the repository layer | ||
::* Need new queries based on Web services (using their query engine) to address specific issues of discovering and retrieving imaging studies: DICOM WG 20 is working on new query standards | ::* Need new queries based on Web services (using their query engine) to address specific issues of discovering and retrieving imaging studies: DICOM WG 20 is working on new query standards | ||
Line 39: | Line 39: | ||
:::* Event code is expandable attribute/value list that could be used for Radiology specific keys (body part, procedure code); IHE Rad will propose list of extensions to ITI | :::* Event code is expandable attribute/value list that could be used for Radiology specific keys (body part, procedure code); IHE Rad will propose list of extensions to ITI | ||
:::* CP 228 in ITI that specifies "and/or" requirement for query response | :::* CP 228 in ITI that specifies "and/or" requirement for query response | ||
− | : | + | |
+ | :3. '''Point-to-point push of images/reports''' | ||
:::* Does XDR enable pushing large image studies site to site (adheres to "provide and register" model) | :::* Does XDR enable pushing large image studies site to site (adheres to "provide and register" model) | ||
::::* Push manifest and require receiver to retrieve | ::::* Push manifest and require receiver to retrieve | ||
::::* Could include images (mime type) in provide and register transaction (convert DICOM metadata into XDS metadata) | ::::* Could include images (mime type) in provide and register transaction (convert DICOM metadata into XDS metadata) | ||
− | : | + | :4. '''Distributed updates and image management functions''' (change in reason for study, etc) |
:::* Metadata versioning profile in ITI allows you to inform registry | :::* Metadata versioning profile in ITI allows you to inform registry | ||
:::* Under Pub/Sub, if new payload is sent, it is designated as a replace transaction | :::* Under Pub/Sub, if new payload is sent, it is designated as a replace transaction | ||
::::* Radiology to review Pub/Sub white paper | ::::* Radiology to review Pub/Sub white paper | ||
− | : | + | :5. '''Security mechanisms: role-based access control and authentication''' |
:::* ITI has Authorization White Paper under development: general architecture (defined) to support different policies (not defined in white paper) | :::* ITI has Authorization White Paper under development: general architecture (defined) to support different policies (not defined in white paper) | ||
+ | |||
+ | :6. '''Notification of availability''' | ||
::* '''Next Joint ITI/Rad Tech/DICOM WG27''' | ::* '''Next Joint ITI/Rad Tech/DICOM WG27''' | ||
Line 56: | Line 59: | ||
:::* Feb. 13, 10:30am-12:00pm CT | :::* Feb. 13, 10:30am-12:00pm CT | ||
− | + | ||
[[Radiology Technical Committee]] | [[Radiology Technical Committee]] | ||
[[Category: Minutes]] | [[Category: Minutes]] | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 13:14, 27 January 2009
Participants
Minutes
1. HL7 2.5 Refactoring
2. Joint ITI/WG 26 DICOM Webservices Review and Discussion
- Radiology presented an update on its current relevant activities and its use cases for image sharing
- Currently revising XDS-I profile to use XDS.b only
- Tracking progress of supplemental profiles in ITI needed to support Web services model--such as XUA for role-based access control--but not currently confident that these solutions are ready for implementation
- Radiology Use Cases for Image Sharing
- Access to prior images and reports
- Access to diagnostic images and reports for referring physicians
- Point-to-point transfer of images and reports from site to site or from a site to an outside provider of longitudinal patient record, such as a Personal Health Record system vendor
- Remote reading model employed frequently requires access by radiologist to multiple image sources
- Moving Radiology to shared model of ITI XDS for Web services
- 1. Retrieve Transactions: Radiology should replace DICOM/Wado transport mechanisms with Web Services image retrieve transaction as compatible as possible with document retrieve method in XDS.b
- DICOM WG27 will help with specification of those transactions; ITI needs to coordinate with DWG27 to review divergences between the transactions defined for radiology and the general XDS retrieve model (retrieve document set)
- Need to consider responsiveness needs of the use case (synch/asynch; pipeline/non-pipeline queries and responses)
- DICOM WG27 needs to review "Appendix V" being developed by ITI to make sure that the Web services profiled "fit" imaging model; perform "gap" analysis and provide feedback to ITI
- Timing issue: need to have transactions specified before issuing XDS.b; standards would have to be specified by August 2009 in order to be implemented in 2009-2010 IHE Rad development cycle
- Should DICOM WG 27 own this activity or ITI? Need a teleconference to settle ownership
- Same model likely to be used for inter- and intraenterprise access
- Intra model has higher performance requirements
- Intra model has more precise query requirements
- 2. Query Issues
- Can Radiology simplify the "three-layer" model of XDS-I: query to registry/reference to repository (with manifest only)/image source by enabling storage of images themselves in the repository layer
- Need new queries based on Web services (using their query engine) to address specific issues of discovering and retrieving imaging studies: DICOM WG 20 is working on new query standards
- Images need to be indexed (via manifest) so that large studies don't appear as multiple query entries
- XDS-I adds two query keys to basic XDS: body part and procedure code
- Manifest provides useful information about imaging study
- Currently not all general query keys are included in the radiology manifest to fit into optimized XDS.b model
- Extend in conformance with pattern for extensions developed by ITI
- Event code is expandable attribute/value list that could be used for Radiology specific keys (body part, procedure code); IHE Rad will propose list of extensions to ITI
- CP 228 in ITI that specifies "and/or" requirement for query response
- 3. Point-to-point push of images/reports
- Does XDR enable pushing large image studies site to site (adheres to "provide and register" model)
- Push manifest and require receiver to retrieve
- Could include images (mime type) in provide and register transaction (convert DICOM metadata into XDS metadata)
- 4. Distributed updates and image management functions (change in reason for study, etc)
- Metadata versioning profile in ITI allows you to inform registry
- Under Pub/Sub, if new payload is sent, it is designated as a replace transaction
- Radiology to review Pub/Sub white paper
- 5. Security mechanisms: role-based access control and authentication
- ITI has Authorization White Paper under development: general architecture (defined) to support different policies (not defined in white paper)
- 6. Notification of availability
- Next Joint ITI/Rad Tech/DICOM WG27
- Feb. 5, 10-11:30am CT
- Feb. 13, 10:30am-12:00pm CT