Difference between revisions of "Rad Tech Minutes 08.07.15"
Jump to navigation
Jump to search
Chrisdcarr (talk | contribs) |
Chrisdcarr (talk | contribs) |
||
Line 39: | Line 39: | ||
::* Work through HL7 Task Force to map radiology requirements to PAM; develop appendix to be shared by ITI and Rad TFs describing relationship | ::* Work through HL7 Task Force to map radiology requirements to PAM; develop appendix to be shared by ITI and Rad TFs describing relationship | ||
::* Exclude ADT from Rad AWF | ::* Exclude ADT from Rad AWF | ||
− | ::* | + | ::* Probably include Order Placer in Rad AWF |
+ | ::* PAM provides ID management (including merge function) and encounter management | ||
+ | ::* PAM does not provide order management capabilities | ||
+ | ::::* DSS can get order information directly from ADT for scheduling | ||
+ | ::* DSS/OF and OP actors would both have to be grouped with Receiver actor to get patient ID, demographics, etc. | ||
+ | ::* Possible to replace Patient Update transaction to Order Filler (RAD-12)with Patient Demographic Query transactions? | ||
+ | ::::* PAM messages to Order Placer | ||
+ | ::::* Legacy systems won't have PDQ capabilities | ||
+ | ::* Need to describe how OP and OF reconcile the information provided in order with information provided in PAM | ||
+ | ::* Identify "source of truth" for each class of data: for registration info, IDs and demographics, probably ADT | ||
+ | ::* OF has to manage patient ID info during course of task, but not maintain it persistently | ||
+ | ::::* Report Repository and Image Mgr/Archive should have mechanism to update: currently provided by Order Filler in PIR | ||
+ | ::* Reasons to refactor registration messages and reference PAM: don't diverge from model and benefit from updates made to PAM | ||
+ | ::* Reference PAM or just lift transactions into Rad AWF? | ||
+ | |||
+ | '''4. Remove PPS Manager''' | ||
+ | |||
+ | |||
Revision as of 17:55, 15 July 2008
Attendees
- Ruth Berge, GE
- Christoph Dickmann, Siemens
- Dick Donker, Philips
- Dave Heaney, McKesson
- Mike Henderson, Eastern Informatics
- Chris Lindop, GE
- Paul Seifert, Agfa
- Chris Carr, RSNA
Minutes
Scheduled Worflow II: Reviewed the open issues in Chris Lindop's draft document with comments from Christoph Dickmann to expand discussion in preparation for creating revised version of profile.
- Open Issues:
1. Image Manager/Image Archive Actor Grouping
- Radiology Acquisition Workflow may be a better name for a new profile than SWF II
- The question is whether to modify the way Image Manager and Image Archive are defined to either add transactions between them or possibly remove Image Archive from the profile
- Transactions between Image Manager and Image Archive might be extensions of current DICOM transactions or non-DICOM (eg, HL7 or SQL)
- Use Cases for Defining Behaviors Between Image Manager and Image Archive:
- 1. Enable "plug and play" interoperability so sites could easily add or replace archives
- 2. Allow replacement of Image Manager without migration/replacement of Archive
- 3. General purpose archive that could store reports and other medical documents as well as images
- 4. Federation of Archives: Does this use case belong in a workflow profile? Federation of Image Managers is probably not feasible.
- 5. Distance reading: single archive shared by multiple image managers
- 1. Enable "plug and play" interoperability so sites could easily add or replace archives
2. Define grouping and roles of Department System Scheduler and Order Filler
- Enable scheduling to be managed by enterprise scheduling systems
- Possibly define Department Workflow Manager with great scheduling capabilities than current DSS: ability to coordinate acquisition with post-processing and reporting, etc.
- Currently the text does not include a clear definition of the roles of the DSS and OF actors
- Perhaps rename current limited functionality as "procedure planning" rather than "scheduling"
- Clarify or remove sections that refer to DSS independently
3. Reconcile ADT transactions with PAM and/or refactor and replace with references to PAM
- Some required transactions in SWF are optional in PAM: possible to add Radiology-specific "extensions" (ie, constraints) to PAM?
- Work through HL7 Task Force to map radiology requirements to PAM; develop appendix to be shared by ITI and Rad TFs describing relationship
- Exclude ADT from Rad AWF
- Probably include Order Placer in Rad AWF
- PAM provides ID management (including merge function) and encounter management
- PAM does not provide order management capabilities
- DSS can get order information directly from ADT for scheduling
- DSS/OF and OP actors would both have to be grouped with Receiver actor to get patient ID, demographics, etc.
- Possible to replace Patient Update transaction to Order Filler (RAD-12)with Patient Demographic Query transactions?
- PAM messages to Order Placer
- Legacy systems won't have PDQ capabilities
- Need to describe how OP and OF reconcile the information provided in order with information provided in PAM
- Identify "source of truth" for each class of data: for registration info, IDs and demographics, probably ADT
- OF has to manage patient ID info during course of task, but not maintain it persistently
- Report Repository and Image Mgr/Archive should have mechanism to update: currently provided by Order Filler in PIR
- Reasons to refactor registration messages and reference PAM: don't diverge from model and benefit from updates made to PAM
- Reference PAM or just lift transactions into Rad AWF?
4. Remove PPS Manager