Difference between revisions of "Rad Tech Minutes 08.07.15"

From IHE Wiki
Jump to navigation Jump to search
 
(8 intermediate revisions by one other user not shown)
Line 14: Line 14:
 
'''Scheduled Worflow II:''' ''Reviewed the open issues in [ftp://ftp.ihe.net/Radiology/iheyr10-2008/Technical_Cmte/2008-07-15_tc_tcon/ihe_supp_SWFII_vol1_2008-06-03_draft__commentsToTC_CDi.doc Chris Lindop's draft document with comments from Christoph Dickmann] to expand discussion in preparation for creating revised version of profile.''
 
'''Scheduled Worflow II:''' ''Reviewed the open issues in [ftp://ftp.ihe.net/Radiology/iheyr10-2008/Technical_Cmte/2008-07-15_tc_tcon/ihe_supp_SWFII_vol1_2008-06-03_draft__commentsToTC_CDi.doc Chris Lindop's draft document with comments from Christoph Dickmann] to expand discussion in preparation for creating revised version of profile.''
  
* Open Issues:
+
===Review of Open Issues===
 +
* '''Radiology Acquisition Workflow''' may be a better name for a new profile than SWF II
  
 
'''1. Image Manager/Image Archive Actor Grouping'''
 
'''1. Image Manager/Image Archive Actor Grouping'''
* 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
+
 
* Use Cases for Defining Behaviors Between Image Manager and Image Archive:
+
* In practical terms, the current framework defines interactions with the Image Manager (even Q/R should go through the Image Manager so it can update the demographics as needed).  It is left as a task for the Image Manager vendor to either embed an Image Archive in the Image Manager, or if they want to use a separate box as the Image Archive, they handle that integration themself.
::1. Enable "plug and play" interoperability so sites could easily add or replace archives
+
** One could argue we should simply remove the Image Archive actor from the profile, or make it a dashed-line actor to more clearly indicate we really don't address it.
::2. Allow replacement of Image Manager without migration/replacement of Archive
+
* Extracting the Image Archive would require defining the interface by which the Image Manager drives the Image Archive.
::3. General purpose archive that could store reports and other medical documents as well as images
+
** Transactions between Image Manager and Image Archive might be extensions of current DICOM transactions or non-DICOM (eg, HL7 or SQL)
::4. Federation of Archives
+
** They would have to address deletion of data
 +
** Our current approach of having the Image Manager handle PIR might require prohibiting the Image Archive from interacting directly with clients which might be a problem
 +
 
 +
* '''Use Cases for Breaking Out the Image Archive:'''
 +
::1. "Plug and play" interoperability so sites could choose/replace the Image Archive independant of the Image Manager
 +
::2. Replacement of Image Manager while avoiding migration/replacement of Archive
 +
::3. Use a General Purpose archive that could store reports and other medical documents as well as images (e.g. XDS Repository, Enterprise Datastore, etc)
 +
::4. Access multiple Federated Archives from a single Image Manager (The Multi-Source option was a bit of a kludge).
 +
:::* Federated Image Managers doens't really make sense.  One manages departmental workflow.  Different departments federate via the Order Placer/Order Filler level.
 +
::5. Distance reading: single archive shared by multiple image managers
 +
 
 +
 
 +
'''2. Define grouping and roles of Department System Scheduler and Order Filler'''
 +
 
 +
::* The DSS/Order Filler is really just an Order Filler.  It manages a worklist.  It records when things get done.  There are attributes in the worklist for date/time/equipment but IHE mandates very little "scheduling".
 +
:::* The current mapping to procedure steps is more about "procedure planning" than "scheduling"
 +
::* We could introduce a Scheduler actor and think about more sophisticated enterprise scheduling (but that may be more of an ITI piece of work)
 +
::* We could introduce a Department Workflow Manager actor to do more sophisticated workflow coordination across acquisition, post-processing and reporting, as described in the whitepaper.
 +
::* Currently the text does not include a clear definition of the roles of the DSS and OF actors
 +
::* 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
 +
 
 +
 
 +
* '''Next Tcon: Thursday, August 14, 11:30am-1:30pm CDT'''
 +
 
  
  

Latest revision as of 20:45, 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.

Review of Open Issues

  • Radiology Acquisition Workflow may be a better name for a new profile than SWF II

1. Image Manager/Image Archive Actor Grouping

  • In practical terms, the current framework defines interactions with the Image Manager (even Q/R should go through the Image Manager so it can update the demographics as needed). It is left as a task for the Image Manager vendor to either embed an Image Archive in the Image Manager, or if they want to use a separate box as the Image Archive, they handle that integration themself.
    • One could argue we should simply remove the Image Archive actor from the profile, or make it a dashed-line actor to more clearly indicate we really don't address it.
  • Extracting the Image Archive would require defining the interface by which the Image Manager drives the Image Archive.
    • Transactions between Image Manager and Image Archive might be extensions of current DICOM transactions or non-DICOM (eg, HL7 or SQL)
    • They would have to address deletion of data
    • Our current approach of having the Image Manager handle PIR might require prohibiting the Image Archive from interacting directly with clients which might be a problem
  • Use Cases for Breaking Out the Image Archive:
1. "Plug and play" interoperability so sites could choose/replace the Image Archive independant of the Image Manager
2. Replacement of Image Manager while avoiding migration/replacement of Archive
3. Use a General Purpose archive that could store reports and other medical documents as well as images (e.g. XDS Repository, Enterprise Datastore, etc)
4. Access multiple Federated Archives from a single Image Manager (The Multi-Source option was a bit of a kludge).
  • Federated Image Managers doens't really make sense. One manages departmental workflow. Different departments federate via the Order Placer/Order Filler level.
5. Distance reading: single archive shared by multiple image managers


2. Define grouping and roles of Department System Scheduler and Order Filler

  • The DSS/Order Filler is really just an Order Filler. It manages a worklist. It records when things get done. There are attributes in the worklist for date/time/equipment but IHE mandates very little "scheduling".
  • The current mapping to procedure steps is more about "procedure planning" than "scheduling"
  • We could introduce a Scheduler actor and think about more sophisticated enterprise scheduling (but that may be more of an ITI piece of work)
  • We could introduce a Department Workflow Manager actor to do more sophisticated workflow coordination across acquisition, post-processing and reporting, as described in the whitepaper.
  • Currently the text does not include a clear definition of the roles of the DSS and OF actors
  • 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


  • Next Tcon: Thursday, August 14, 11:30am-1:30pm CDT



Radiology Technical Committee