Difference between revisions of "Rad Tech Minutes 08.07.15"
Jump to navigation
Jump to search
Chrisdcarr (talk | contribs) |
Chrisdcarr (talk | contribs) |
||
Line 55: | Line 55: | ||
'''4. Remove PPS Manager''' | '''4. Remove PPS Manager''' | ||
+ | ::* Move its functions to Order Filler, which becomes source of info on modality status | ||
+ | ::* CAD devices' needs have to be considered in working through this change: they also need modality status | ||
+ | ::* Image Manager currently uses MPPS for group case, PGP | ||
+ | ::* Require modalities to send information to OF; make other destinations optional | ||
+ | ::* Closes loop for Modality Worklist | ||
+ | |||
+ | 5. Common Personnel Identity | ||
+ | ::* Modality needs information about tech at console | ||
+ | ::* Currently only provided unstructured name field in MPPS | ||
+ | ::::* Possible to incorporate Personnel White Pages transactions? | ||
+ | ::::* Get DICOM to add coded value for personnel in MPPS? | ||
+ | ::* Need to meet differing requirements for personnel identification of large and small sites | ||
+ | ::* Do not want to require PWP, but rather coordinate with AWF transactions | ||
+ | ::* Make sure to add "all other attributes" value to MPPS code tables | ||
+ | ::* Request information from users: What is broken? Does selected approach address it? | ||
+ | |||
+ | '''6. Remove Options''' | ||
+ | ::* Make hard requirements where appropriate | ||
+ | ::* Basic functionality of profile should be available without options in place; options add supplementary features | ||
+ | ::* Replace some options with specific conditional requirements | ||
+ | |||
+ | '''7. Charge Posting''' | ||
+ | ::* How to address billing/materials management option in Rad AWF? | ||
+ | ::* Move the option/condition requirements to Charge Posting profile? | ||
+ | ::* Examine what information billing systems need to do their work (include MPPS status info?) | ||
+ | |||
+ | '''8. Fold PIR into Rad AWF''' | ||
+ | ::* Leads to bigger issue of how data gets updated with respect to PAM and Enterprise Information Systems | ||
+ | ::* Need to define how each actor responds to updates | ||
+ | |||
+ | |||
+ | |||
Revision as of 18:10, 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
- Move its functions to Order Filler, which becomes source of info on modality status
- CAD devices' needs have to be considered in working through this change: they also need modality status
- Image Manager currently uses MPPS for group case, PGP
- Require modalities to send information to OF; make other destinations optional
- Closes loop for Modality Worklist
5. Common Personnel Identity
- Modality needs information about tech at console
- Currently only provided unstructured name field in MPPS
- Possible to incorporate Personnel White Pages transactions?
- Get DICOM to add coded value for personnel in MPPS?
- Need to meet differing requirements for personnel identification of large and small sites
- Do not want to require PWP, but rather coordinate with AWF transactions
- Make sure to add "all other attributes" value to MPPS code tables
- Request information from users: What is broken? Does selected approach address it?
6. Remove Options
- Make hard requirements where appropriate
- Basic functionality of profile should be available without options in place; options add supplementary features
- Replace some options with specific conditional requirements
7. Charge Posting
- How to address billing/materials management option in Rad AWF?
- Move the option/condition requirements to Charge Posting profile?
- Examine what information billing systems need to do their work (include MPPS status info?)
8. Fold PIR into Rad AWF
- Leads to bigger issue of how data gets updated with respect to PAM and Enterprise Information Systems
- Need to define how each actor responds to updates