Difference between revisions of "Foreign Exam Management - Detailed Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(19 intermediate revisions by 2 users not shown)
Line 10: Line 10:
 
The existing IRWF and SWF Profiles already deal with the exchange of imaging data. IRWF would need a new option to automate the order creation for the Scheduled Import option. SWF could possibly be extended with a new option to support the use cases and desired functionality for foreign study import over the network.  
 
The existing IRWF and SWF Profiles already deal with the exchange of imaging data. IRWF would need a new option to automate the order creation for the Scheduled Import option. SWF could possibly be extended with a new option to support the use cases and desired functionality for foreign study import over the network.  
  
The
+
A DICOM removable media importer using an automated process was deployed nation-wide at the Department of Veterans Affairs in September 2010. (A paper describing this work has been accepted by SIIM JDI - Streamlining Importation of Outside Prior DICOM Studies into an Imaging System - J Digit Imaging, August 2, 2011).
  
''<Summarize in a few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">''
+
Foreign study management has come up as a particular concern in the Canadian market where local PACS are integrated with centralized Diagnostic Imaging Repositories (DI-Rs) and a white paper has been created discussing this use case. There is a lot of interest from both customers and vendors to address this issue.  
  
''<Summarize in a line or two market interest & available resources.  E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking.  Individuals from SFR are willing to participate in Profile development.">''
+
The identified use cases are really just extensions to ones already addressed in existing IHE Radiology Profiles. The existing Profiles and transactions could be extended to cover these additional use cases. A lot of work has already gone into documenting the use cases and possible solutions so IHE can leverage this existing work.
 
 
''<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">''
 
  
 
==2. The Problem==
 
==2. The Problem==
Line 22: Line 20:
 
The current Import Reconciliation Workflow Profile does not cover many of the use cases or feature functionality desired by customers when handling foreign studies. By foreign study, we mean an imaging exam that was ordered, acquired, and reported on at some site external to the one where the study is currently being imported. Such foreign Studies could be imported via removable media or through network interchange.  
 
The current Import Reconciliation Workflow Profile does not cover many of the use cases or feature functionality desired by customers when handling foreign studies. By foreign study, we mean an imaging exam that was ordered, acquired, and reported on at some site external to the one where the study is currently being imported. Such foreign Studies could be imported via removable media or through network interchange.  
  
==2.1 Creation of the New Order for the IRWF Scheduled Import Option==
+
===2.1 Creation of the New Order for the IRWF Scheduled Import Option===
  
 
A patient has an imaging study performed at one facility and has the study exported to portable media.  Later, the patient takes the media to a different institution.  The study on that media may need to be imported into that new institution’s imaging system.  This would be done to avoid a repeat examination, or so that the study can be on file for reference purposes.  
 
A patient has an imaging study performed at one facility and has the study exported to portable media.  Later, the patient takes the media to a different institution.  The study on that media may need to be imported into that new institution’s imaging system.  This would be done to avoid a repeat examination, or so that the study can be on file for reference purposes.  
Line 34: Line 32:
 
The automated process is much more efficient for the user and prior studies are more likely to be imported.  This means that repeat examinations can be avoided and prior studies are on file for reference purposes.
 
The automated process is much more efficient for the user and prior studies are more likely to be imported.  This means that repeat examinations can be avoided and prior studies are on file for reference purposes.
  
==2.2  Handling Prior Study Imported Over the Network==
+
A DICOM importer using the automated process was deployed nation-wide at the Department of Veterans Affairs in September 2010.  (A paper describing this work has been accepted by SIIM JDI - Streamlining Importation of Outside Prior DICOM Studies into an Imaging System - J Digit Imaging, August 2, 2011).
 +
 
 +
Here is a link to a paper on the VA work:
 +
ftp://ftp.ihe.net/Radiology/iherad-2012/Plan_Cmte/ForeignStudyManagement/SIIM%20Importer%20Paper-published_original.pdf
 +
 
 +
One of the VA users recently reported the following about the new application:
 +
 
 +
"The new process is fantastic... Not manpower intensive or laborious.  We can import 80+ radiology studies <u>in less than 2 hours</u>... the old process we had would be <u>at least 15-18 hours for that many studies</u>." (The underlines in the original.)
 +
 
 +
This site treats polytrauma patients that are transferred from DoD to the VA for long term care.  Approximately 1100 prior studies from the DoD are imported at this VA Medical Center each month.
 +
 
 +
There was a real problem in the VA prior to the creation of this DICOM importer application - the amount of data that needed to be imported exceeded the available manpower.  So it wasn't being done.  As a result, the images were lost and radiology examinations were unnecessarily repeated.  Now they are able import all of the DICOM images and make them part of the VA patient record.
 +
 
 +
This work is important because is addresses one of the major unsolved problems with import reconciliation workflow: how to efficiently handle the importing of prior studies.
 +
 
 +
===2.2  Handling Prior Study Imported Over the Network===
  
 
All of the existing IRWF Use Cases (RAD TF-1 21.3.1.1.) assume importation of foreign studies from removable media. However, foreign studies can also be imported over the network. For example an external Image Manager/Archive could send foreign studies to another importing system, or the importing system could trigger the query-retrieval. Both of these scenarios could result from some automated 'push' or 'pull' pre-fetch mechanism.  
 
All of the existing IRWF Use Cases (RAD TF-1 21.3.1.1.) assume importation of foreign studies from removable media. However, foreign studies can also be imported over the network. For example an external Image Manager/Archive could send foreign studies to another importing system, or the importing system could trigger the query-retrieval. Both of these scenarios could result from some automated 'push' or 'pull' pre-fetch mechanism.  
Line 42: Line 55:
 
==3. Key Use Cases==
 
==3. Key Use Cases==
  
==3.1 Handling Prior Study Imported on Removable Media==
+
===3.1 Handling Prior Study Imported on Removable Media===
  
 
The classic problem is how to deal with the prior study that was performed while the patient was being treated at another facility.  The patient brings the CD containing the prior study when the patient went to the local institution for treatment.  The patient’s clinician (provider) determined that the outside images/studies are clinically significant and need to be included in the patient’s EHR as reference images.  The solution involves importing an outside study that is unknown to the local system.
 
The classic problem is how to deal with the prior study that was performed while the patient was being treated at another facility.  The patient brings the CD containing the prior study when the patient went to the local institution for treatment.  The patient’s clinician (provider) determined that the outside images/studies are clinically significant and need to be included in the patient’s EHR as reference images.  The solution involves importing an outside study that is unknown to the local system.
Line 56: Line 69:
 
All of the interactive item selection is done first and then is followed by an automatic database update commit transaction.  First the HIS/RIS patient and equivalent radiology procedure are manually identified for each prior study.  Then the DICOM importer process automatically places the order on the RIS for each the equivalent radiology study, uses the order information for import reconciliation, sends the images to the institution’s imaging system, and then updates the status of the study on the RIS to indicate that it was completed.
 
All of the interactive item selection is done first and then is followed by an automatic database update commit transaction.  First the HIS/RIS patient and equivalent radiology procedure are manually identified for each prior study.  Then the DICOM importer process automatically places the order on the RIS for each the equivalent radiology study, uses the order information for import reconciliation, sends the images to the institution’s imaging system, and then updates the status of the study on the RIS to indicate that it was completed.
  
==3.2 Handling Prior Study Pre-fetched Over the Network==
+
===3.2 Handling Prior Study Pre-fetched Over the Network===
  
 
A White Paper on foreign exam management had been circulated in the XDS Implementation Group.  
 
A White Paper on foreign exam management had been circulated in the XDS Implementation Group.  
 
Here is a link to that white paper:
 
Here is a link to that white paper:
ftp://ftp.ihe.net/Radiology/iherad-2011/Tech_Cmte/Foreign%20Study%20Management%20White%20Paper%20v0-06%20-%20Draft.pdf
+
 
 +
ftp://ftp.ihe.net/Radiology/iherad-2012/Plan_Cmte/ForeignStudyManagement/Foreign%20Study%20Management%20White%20Paper%20v0-06%20-%20Draft.pdf
  
 
This particular white paper specifically addresses a pre-fetch use case based on the Canada Infoway blueprint architecture, where there is always a shared DI-r (Diagnostic Imaging repository)that local PACS archive their images to:
 
This particular white paper specifically addresses a pre-fetch use case based on the Canada Infoway blueprint architecture, where there is always a shared DI-r (Diagnostic Imaging repository)that local PACS archive their images to:
Line 73: Line 87:
 
* The DI-r itself receives the exam order from Site B and pushes the study to PACS-B.
 
* The DI-r itself receives the exam order from Site B and pushes the study to PACS-B.
 
* There is no DI-r but the prior Study is query-retrieved from PACS-A using XDS-I or purely DICOM based mechanisms. The key thing being that PACS-B can trust PACS-A to store the long term copy of this Study so that it can be retrieved again later if necessary.
 
* There is no DI-r but the prior Study is query-retrieved from PACS-A using XDS-I or purely DICOM based mechanisms. The key thing being that PACS-B can trust PACS-A to store the long term copy of this Study so that it can be retrieved again later if necessary.
* The prior Study is pushed to PACS-B and PACS-B needs to maintain its own copy of the prior Study because it may not be able to retrieve the Study again if it is flushed.  
+
* The prior Study is pushed to PACS-B and PACS-B needs to maintain its own copy of the prior Study because it may not be able to retrieve the Study again if it is flushed.
 +
 
 +
There are a few issues that arise for this use case:
 +
Does the sending system need to support the capability of triggering the creation of an order corresponding to the prior Study? If so then how does a receiving system distinguish between a new order for which a new report must be created and a prior? What sort of behavior should the receiving system support regarding the archiving or flushing of foreign exams? Should the receiving system be capable of not only flushing the imaging objects but also the Study record itself from its database? If so under what circumstances?
  
 
==4. Standards and Systems==
 
==4. Standards and Systems==
  
==4.1 Handling Prior Study Imported on Removable Media==
+
===4.1 Handling Prior Study Imported on Removable Media===
 +
Addressing Use Case 3.1 would be an enhancement to Import Reconciliation Workflow (IRWF). This enhancement consists of two parts:
 +
* The first is the ability to identify the patient and the equivalent radiology procedure and modifiers for the prior study.
 +
* The second is the ability to place the order for the equivalent radiology procedure for the prior study, trigger the filling of the order, obtaining the study information for the order, performing the reconciliation, sending the reconciled DICOM objects to the imaging system, and updating the status of the created study afterwards.
 +
 
 +
===4.2 Handling Prior Study Pre-fetched Over the Network===
 +
Addressing this use could perhaps be added as a new SWF option, or even a new network exchange option for IRWF. All of the necessary transactions for the variants of this use case already exist. The necessary work is in defining what behavior shall be supported by the sending and receiving actors.
 +
 
 +
==5. Technical Approach==
 +
 
 +
Broadly requesting extension of IRWF Profile to add something like:
 +
* Request Order transaction
 +
** sent from the importer to the OF or OP
 +
** provides details like the locally matched patient id, the nature of the dataset (e.g. 2-phase liver), and the nature of the requested order (e.g. request to read, request to import as prior, etc.) and identify the data as "outside" data.
 +
** Q. should we address cases where the acquisition was outsourced (i.e. the scan was performed outside due to internal capacity limits) but should be incorporated into local EMR, perhaps also tied to a local accession?
 +
** Describe required behaviors on Order Placer and Order Filler
 +
*** If behavior is sophisticated enough, might require new transaction between the two
 +
* Review import use cases for central/XDS sources of imports in more detail and profile as needed
 +
* Review archive/access/retention use cases and policies for foreign exams and profile as needed
 +
 
 +
===5.1 Handling Prior Study Imported on Removable Media===
 
Addressing Use Case 3.1 would be an enhancement to Import Reconciliation Workflow (IRWF). This enhancement consists of two parts:
 
Addressing Use Case 3.1 would be an enhancement to Import Reconciliation Workflow (IRWF). This enhancement consists of two parts:
 
* The first is the ability to identify the patient and the equivalent radiology procedure and modifiers for the prior study.  
 
* The first is the ability to identify the patient and the equivalent radiology procedure and modifiers for the prior study.  
 
* The second is the ability to place the order for the equivalent radiology procedure for the prior study, trigger the filling of the order, obtaining the study information for the order, performing the reconciliation, sending the reconciled DICOM objects to the imaging system, and updating the status of the created study afterwards.
 
* The second is the ability to place the order for the equivalent radiology procedure for the prior study, trigger the filling of the order, obtaining the study information for the order, performing the reconciliation, sending the reconciled DICOM objects to the imaging system, and updating the status of the created study afterwards.
 
The key to this enhancement is the ability to remotely place to create the equivalent study on the RIS that the prior study can be associated with.  In order to do this the Importer actor has to function as the order placer and then trigger the order filler to create the study.  This is probably going to require a new transaction.
 
The key to this enhancement is the ability to remotely place to create the equivalent study on the RIS that the prior study can be associated with.  In order to do this the Importer actor has to function as the order placer and then trigger the order filler to create the study.  This is probably going to require a new transaction.
 +
 +
====Transactions====
  
 
<u>Part 1</u>
 
<u>Part 1</u>
Line 105: Line 144:
 
Updating the status of the created study - IRWF RAD-61 - MPPS Complete
 
Updating the status of the created study - IRWF RAD-61 - MPPS Complete
  
==4.2 Handling Prior Study Pre-fetched Over the Network==
+
====Breakdown of tasks that need to be accomplished====
Addressing this use could perhaps be added as a new network exchange option to IRWF. All of the necessary transactions for the variants of this use case already exist. The necessary work is in defining what behavior shall be supported by the sending and receiving actors.
+
This use case is already well defined, as well as its relation to the existing IRWF Profle.There would have to be an analysis of the proposed solution. If this is felt to really be the best way to address the use case then there would need to be the technical specification of the new transaction and the editing work to add the new option to IRWF.  
  
==5. Discussion==
+
===5.2 Handling Prior Study Pre-fetched Over the Network===
  
==5.1 Handling Prior Study Imported on Removable Media==
+
====Impact on existing integration profiles====
A DICOM importer using the automated process was deployed nation-wide at the Department of Veterans Affairs in September 2010. (A paper describing this work has been accepted by SIIM JDI - Streamlining Importation of Outside Prior DICOM Studies into an
+
All of the necessary transactions for the variants of this use case (image exchange, patient id lookup, etc.) already exist. However, the decision on exactly which transactions to use could be dependent upon whether this is a new option(s) added to SWF or IRWF. If the former then there is the question of whether or not it should leverage the Multiple Identity Resolution option transactions or just the mandatory SWF transactions. Beyond the actual transactional support, the behavior of the sending and receiving actors will need to be defined.  
Imaging System - J Digit Imaging, August 2, 2011).
 
  
One of our VA users recently reported the following about the new application:
+
====Existing actors====
 +
Image Manager/Image Archive
 +
Importer (if new options added to IRWF)
 +
DSS/Order Filler
 +
Patient Demographics Supplier
 +
PIX Manager
  
"The new process is fantastic... Not manpower intensive or laborious.  We can import 80+ radiology studies <u>in less than 2 hours</u>... the old process we had would be <u>at least 15-18 hours for that many studies</u>." (The underlines in the original.)
+
====Existing transactions====
 +
For network exchange of imaging objects
 +
* SWF Patient Identity Resolution option transactions: Image Manager Instances Stored [RAD-70], etc.
 +
or  
 +
* SWF transactions: Retrieve Images [RAD-16], etc.  
  
This site treats polytrauma patients that are transferred from DoD to the VA for long term care.  Approximately 1100 prior studies from the DoD are imported at this VA Medical Center each month.
+
For resolution of the patient identification:
 +
* PDQ Patient Demographics Query [ITI-21] transaction
 +
or
 +
* PIX Query [ITI-9]
  
We had a real problem in the VA prior to the creation of this DICOM importer application - the amount of data that needed to be imported exceeded the available manpower.  So it wasn't being done.  As a result, the images were lost and radiology examinations were unnecessarily repeated.  Now we are able import all of the DICOM images and make them part of the VA patient record.
+
====Breakdown of tasks that need to be accomplished====
 +
This use case is already well defined, as well as its relation to the existing IRWF Profle.There would have to be an analysis of the proposed solution. If this is felt to really be the best way to address the use case then there would need to be the technical specification of the new transaction and the editing work to add the new option to IRWF.
  
We think that this work is important because is addresses one of the major unsolved problems with import reconciliation workflow: how to efficiently handle the importing of prior studies.  Portable DICOM media will be around for a long time.  That's why I think IHE needs to take it on.
+
==6. Support & Resources==
 
+
A number of groups have expressed interest in this proposal and are able to provide resources. Among these are:
==5.2 Handling Prior Study Pre-fetched Over the Network==
+
* VA
Does the sending system need to support the capability of triggering the creation of an order corresponding to the prior Study? If so then how does a receiving system distinguish between a new order for which a new report must be created and a prior? What sort of behavior should the receiving system support regarding the archiving or flushing of foreign exams? Should the receiving system be capable of not only flushing the imaging objects but also the Study record itself from its database? If so under what circumstances?
+
* Canada Infoway SCWG5 DI members
 
+
* XDS Implementation Group members
 
 
==5. Technical Approach==
 
''<This section can be very short but include as much detail as you like.  The Technical Committee will flesh it out when doing the effort estimation.>''
 
 
 
''<Outline how the standards could be used/refined to solve the problems in the Use Cases.  The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>''
 
 
 
''<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>''
 
 
 
===Existing actors===
 
''<Indicate what existing actors could be used or might be affected by the profile.>''
 
 
 
===New actors===
 
''<List possible new actors>''
 
 
 
===Existing transactions===
 
''<Indicate how existing transactions might be used or might need to be extended.>''
 
 
 
===New transactions (standards used)===
 
''<Describe possible new transactions (indicating what standards would likely be used for each.  Transaction diagrams are very helpful here.  Feel free to go into as much detail as seems useful.>''
 
  
===Impact on existing integration profiles===
 
''<Indicate how existing profiles might need to be modified.>''
 
  
===New integration profiles needed===
+
Recent Aunt Minnie thread on site CD importation problems and practices [http://www.auntminnie.com/forum/tm.aspx?m=323266&wf=4616 here].
''<Indicate what new profile(s) might need to be created.>''
 
 
 
===Breakdown of tasks that need to be accomplished===
 
''<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>''
 
 
 
==6. Support & Resources==
 
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''
 
  
 
==7. Risks==
 
==7. Risks==
''<List technical or political risks that will need to be considered to successfully field the profile.>''
+
There is the risk that differences in opinion on how an importing system should behave could delay the completion of this work item, or result in such a multiplicity of options that it becomes confusing for both implementers and customers. For example, a number of issues have already been identified related to this:
 +
* Does the sending system need to support the capability of triggering the creation of an order corresponding to the prior Study? * What sort of behavior should the receiving system support regarding the archiving or flushing of foreign exams?
  
 
==8. Open Issues==
 
==8. Open Issues==
Line 166: Line 190:
  
 
==9. Tech Cmte Evaluation==
 
==9. Tech Cmte Evaluation==
 
''<The technical committee will use this area to record details of the effort estimation, etc.>''
 
  
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):
:* 35% for ...
+
:* 25%
 +
:* IRWF extensions are probably straight forward, but need to make sure we do good review of typical site policies for handling priors to make sure our architecture doesn't preclude reasonable policy choices.
  
 
Responses to Issues:
 
Responses to Issues:

Latest revision as of 20:17, 25 October 2011

1. Proposed Workitem: Foreign Exam Management Detailed Proposal

  • Proposal Editor: David Heaney and Peter Kuzmak
  • Editor: David Heaney or Peter Kuzmak
  • Domain: Radiology

Summary

The current Import Reconciliation Workflow Profile does not cover many of the use cases or feature functionality desired by customers when handling foreign studies. Such foreign Studies could be imported via removable media or through network interchange. For import of removable media there is the need to better automate the import of foreign studies. For handling prior studies over the network there is a need to better define what features should be supported by importing systems and what their behavior should be in handling the imported data.

The existing IRWF and SWF Profiles already deal with the exchange of imaging data. IRWF would need a new option to automate the order creation for the Scheduled Import option. SWF could possibly be extended with a new option to support the use cases and desired functionality for foreign study import over the network.

A DICOM removable media importer using an automated process was deployed nation-wide at the Department of Veterans Affairs in September 2010. (A paper describing this work has been accepted by SIIM JDI - Streamlining Importation of Outside Prior DICOM Studies into an Imaging System - J Digit Imaging, August 2, 2011).

Foreign study management has come up as a particular concern in the Canadian market where local PACS are integrated with centralized Diagnostic Imaging Repositories (DI-Rs) and a white paper has been created discussing this use case. There is a lot of interest from both customers and vendors to address this issue.

The identified use cases are really just extensions to ones already addressed in existing IHE Radiology Profiles. The existing Profiles and transactions could be extended to cover these additional use cases. A lot of work has already gone into documenting the use cases and possible solutions so IHE can leverage this existing work.

2. The Problem

The current Import Reconciliation Workflow Profile does not cover many of the use cases or feature functionality desired by customers when handling foreign studies. By foreign study, we mean an imaging exam that was ordered, acquired, and reported on at some site external to the one where the study is currently being imported. Such foreign Studies could be imported via removable media or through network interchange.

2.1 Creation of the New Order for the IRWF Scheduled Import Option

A patient has an imaging study performed at one facility and has the study exported to portable media. Later, the patient takes the media to a different institution. The study on that media may need to be imported into that new institution’s imaging system. This would be done to avoid a repeat examination, or so that the study can be on file for reference purposes.

Importing prior studies is best performed by creating a new order on the institution’s imaging system and then associating the DICOM objects from the prior study with it. In this way the prior study is actually inserted into the imaging system’s electronic health record (EHR) and is properly indexed so that it can be identified and later retrieved as needed.

This use case is currently handled by the IRWF Scheduled Import Option. However, importing prior DICOM studies into the institution’s systems is a very slow labor intensive process even when using this option. The user loads the media into the drive and then waits for the Importer actor product to read all the DICOM files. The user then has to work on one study at a time. First, the user has to review the study on the Importer actor. The user then has to go to the institution’s DSS/OF actor and place an order for an equivalent radiology study. Then, the user has to go back to the Importer actor and use DICOM Modality Worklist to retrieve the order, have the commercial importer update the DICOM images with the institution’s patient and order information, and have them sent to the institution’s Image Manager/Archive system. Finally, the user has to go back to the institution’s DSS/OF to update the study status to indicate that it is completed. Processing a single study this way takes anywhere from 10 to 30 minutes (estimate from Department of Veterans Affairs). And the user has to repeat this effort for each study on the portable media that needs to be imported. This is a rather overwhelming task, given the volume of studies that need to be imported. The result is that the prior studies are often not imported and examinations are unnecessarily repeated.

The process to import prior DICOM studies can be automated to eliminate many of the manual steps. The Importer actor application can place the order on the RIS for the equivalent radiology study, use the order information for import reconciliation, send the images to the institution’s Image Manager/Archive system, and then update the status of the study on the RIS to indicate that it was completed.

The automated process is much more efficient for the user and prior studies are more likely to be imported. This means that repeat examinations can be avoided and prior studies are on file for reference purposes.

A DICOM importer using the automated process was deployed nation-wide at the Department of Veterans Affairs in September 2010. (A paper describing this work has been accepted by SIIM JDI - Streamlining Importation of Outside Prior DICOM Studies into an Imaging System - J Digit Imaging, August 2, 2011).

Here is a link to a paper on the VA work: ftp://ftp.ihe.net/Radiology/iherad-2012/Plan_Cmte/ForeignStudyManagement/SIIM%20Importer%20Paper-published_original.pdf

One of the VA users recently reported the following about the new application:

"The new process is fantastic... Not manpower intensive or laborious. We can import 80+ radiology studies in less than 2 hours... the old process we had would be at least 15-18 hours for that many studies." (The underlines in the original.)

This site treats polytrauma patients that are transferred from DoD to the VA for long term care. Approximately 1100 prior studies from the DoD are imported at this VA Medical Center each month.

There was a real problem in the VA prior to the creation of this DICOM importer application - the amount of data that needed to be imported exceeded the available manpower. So it wasn't being done. As a result, the images were lost and radiology examinations were unnecessarily repeated. Now they are able import all of the DICOM images and make them part of the VA patient record.

This work is important because is addresses one of the major unsolved problems with import reconciliation workflow: how to efficiently handle the importing of prior studies.

2.2 Handling Prior Study Imported Over the Network

All of the existing IRWF Use Cases (RAD TF-1 21.3.1.1.) assume importation of foreign studies from removable media. However, foreign studies can also be imported over the network. For example an external Image Manager/Archive could send foreign studies to another importing system, or the importing system could trigger the query-retrieval. Both of these scenarios could result from some automated 'push' or 'pull' pre-fetch mechanism.

Users often want such prior foreign studies to be handled differently by an Image Manager/Archive than newly acquired studies. Radiologists do not want the foreign study to show up in their reading list as they do not need to create a new report for such a study. It is just being imported as a relevant prior for some new study. If they trust the source system as the long term storage location for the study, such as when a local PACS is integrated with some centralized archive, then users do not want a copy of this imported study to be archived (either in the local system or to the external system from which it was obtained). Typically, it is desired that there be some configurable behavior on the timing for this flushing that differs from normal workflow exams, such as a shortened time frame and even deletion of the study record from the local Image Manager/Archive's database.

3. Key Use Cases

3.1 Handling Prior Study Imported on Removable Media

The classic problem is how to deal with the prior study that was performed while the patient was being treated at another facility. The patient brings the CD containing the prior study when the patient went to the local institution for treatment. The patient’s clinician (provider) determined that the outside images/studies are clinically significant and need to be included in the patient’s EHR as reference images. The solution involves importing an outside study that is unknown to the local system.

Importing prior studies is performed by creating a new order on the institution’s imaging system and then associating the DICOM objects from the prior study with it.

Currently, the user loads the media into the drive and then waits for the commercial importer product to read all the DICOM files. The user then has to work on one study at a time. First, the user has to review the study on the commercial importer. The user then has to go to the institution’s RIS and place an order for an equivalent radiology study. Then, the user would has to go back to the commercial importer and use DICOM Modality Worklist to retrieve the order, have the commercial importer update the DICOM images with the institution’s patient and order information, and have them sent to the institution’s imaging system. Finally, the user has to go back to the institution’s RIS to update the study status to indicate that it is completed. The user has to repeat this effort for each study on the portable media that needs to be imported.

The process to import prior DICOM studies can be automated to eliminate many of the manual steps.

The workflow of the import process can be designed to operate like an online merchandise ordering application where the user adds items to a shopping cart and then proceeds to checkout.

All of the interactive item selection is done first and then is followed by an automatic database update commit transaction. First the HIS/RIS patient and equivalent radiology procedure are manually identified for each prior study. Then the DICOM importer process automatically places the order on the RIS for each the equivalent radiology study, uses the order information for import reconciliation, sends the images to the institution’s imaging system, and then updates the status of the study on the RIS to indicate that it was completed.

3.2 Handling Prior Study Pre-fetched Over the Network

A White Paper on foreign exam management had been circulated in the XDS Implementation Group. Here is a link to that white paper:

ftp://ftp.ihe.net/Radiology/iherad-2012/Plan_Cmte/ForeignStudyManagement/Foreign%20Study%20Management%20White%20Paper%20v0-06%20-%20Draft.pdf

This particular white paper specifically addresses a pre-fetch use case based on the Canada Infoway blueprint architecture, where there is always a shared DI-r (Diagnostic Imaging repository)that local PACS archive their images to:

  • Images are acquired at Site A within PACS-A
  • PACS-A publishes the DICOM instances to a DI-r
  • An exam is ordered at Site B for a patient and images are acquired within PACS-B
  • PACS-B pre-fetches relevant prior DICOM instances for the patient of interest from the DI-r
  • Within PACS-B the DICOM instances are linked and viewed in comparative display format following the users Default Display Protocol.
  • The DI-r maintains the long term copy of the images from PACS-A so there is no need for PACS-B to trigger the re-archival of this Study (i.e. such as under a locally generated order corresponding to the prior Study).

A few variants of this use case are:

  • The DI-r itself receives the exam order from Site B and pushes the study to PACS-B.
  • There is no DI-r but the prior Study is query-retrieved from PACS-A using XDS-I or purely DICOM based mechanisms. The key thing being that PACS-B can trust PACS-A to store the long term copy of this Study so that it can be retrieved again later if necessary.
  • The prior Study is pushed to PACS-B and PACS-B needs to maintain its own copy of the prior Study because it may not be able to retrieve the Study again if it is flushed.

There are a few issues that arise for this use case: Does the sending system need to support the capability of triggering the creation of an order corresponding to the prior Study? If so then how does a receiving system distinguish between a new order for which a new report must be created and a prior? What sort of behavior should the receiving system support regarding the archiving or flushing of foreign exams? Should the receiving system be capable of not only flushing the imaging objects but also the Study record itself from its database? If so under what circumstances?

4. Standards and Systems

4.1 Handling Prior Study Imported on Removable Media

Addressing Use Case 3.1 would be an enhancement to Import Reconciliation Workflow (IRWF). This enhancement consists of two parts:

  • The first is the ability to identify the patient and the equivalent radiology procedure and modifiers for the prior study.
  • The second is the ability to place the order for the equivalent radiology procedure for the prior study, trigger the filling of the order, obtaining the study information for the order, performing the reconciliation, sending the reconciled DICOM objects to the imaging system, and updating the status of the created study afterwards.

4.2 Handling Prior Study Pre-fetched Over the Network

Addressing this use could perhaps be added as a new SWF option, or even a new network exchange option for IRWF. All of the necessary transactions for the variants of this use case already exist. The necessary work is in defining what behavior shall be supported by the sending and receiving actors.

5. Technical Approach

Broadly requesting extension of IRWF Profile to add something like:

  • Request Order transaction
    • sent from the importer to the OF or OP
    • provides details like the locally matched patient id, the nature of the dataset (e.g. 2-phase liver), and the nature of the requested order (e.g. request to read, request to import as prior, etc.) and identify the data as "outside" data.
    • Q. should we address cases where the acquisition was outsourced (i.e. the scan was performed outside due to internal capacity limits) but should be incorporated into local EMR, perhaps also tied to a local accession?
    • Describe required behaviors on Order Placer and Order Filler
      • If behavior is sophisticated enough, might require new transaction between the two
  • Review import use cases for central/XDS sources of imports in more detail and profile as needed
  • Review archive/access/retention use cases and policies for foreign exams and profile as needed

5.1 Handling Prior Study Imported on Removable Media

Addressing Use Case 3.1 would be an enhancement to Import Reconciliation Workflow (IRWF). This enhancement consists of two parts:

  • The first is the ability to identify the patient and the equivalent radiology procedure and modifiers for the prior study.
  • The second is the ability to place the order for the equivalent radiology procedure for the prior study, trigger the filling of the order, obtaining the study information for the order, performing the reconciliation, sending the reconciled DICOM objects to the imaging system, and updating the status of the created study afterwards.

The key to this enhancement is the ability to remotely place to create the equivalent study on the RIS that the prior study can be associated with. In order to do this the Importer actor has to function as the order placer and then trigger the order filler to create the study. This is probably going to require a new transaction.

Transactions

Part 1

Identify the patient - Patient Data Query (IT-PDQ)

Identifying the equivalent RIS radiology procedure & modifier(s) - TBD (HL7 MFB ?)

Part 2

Placing the order for the equivalent radiology procedure for the prior study -

Scheduled Workflow RAD-3

Triggering the filling of the order - A new transaction is probably needed

Obtaining the study information - Scheduled Workflow RAD-4 (This might be part of the order filler trigger transaction.)

Performing the reconciliation - IRWF RAD-61

Sending the reconciled DICOM objects to the imaging system - IRWF RAD-61

Updating the status of the created study - IRWF RAD-61 - MPPS Complete

Breakdown of tasks that need to be accomplished

This use case is already well defined, as well as its relation to the existing IRWF Profle.There would have to be an analysis of the proposed solution. If this is felt to really be the best way to address the use case then there would need to be the technical specification of the new transaction and the editing work to add the new option to IRWF.

5.2 Handling Prior Study Pre-fetched Over the Network

Impact on existing integration profiles

All of the necessary transactions for the variants of this use case (image exchange, patient id lookup, etc.) already exist. However, the decision on exactly which transactions to use could be dependent upon whether this is a new option(s) added to SWF or IRWF. If the former then there is the question of whether or not it should leverage the Multiple Identity Resolution option transactions or just the mandatory SWF transactions. Beyond the actual transactional support, the behavior of the sending and receiving actors will need to be defined.

Existing actors

Image Manager/Image Archive Importer (if new options added to IRWF) DSS/Order Filler Patient Demographics Supplier PIX Manager

Existing transactions

For network exchange of imaging objects

  • SWF Patient Identity Resolution option transactions: Image Manager Instances Stored [RAD-70], etc.

or

  • SWF transactions: Retrieve Images [RAD-16], etc.

For resolution of the patient identification:

  • PDQ Patient Demographics Query [ITI-21] transaction

or

  • PIX Query [ITI-9]

Breakdown of tasks that need to be accomplished

This use case is already well defined, as well as its relation to the existing IRWF Profle.There would have to be an analysis of the proposed solution. If this is felt to really be the best way to address the use case then there would need to be the technical specification of the new transaction and the editing work to add the new option to IRWF.

6. Support & Resources

A number of groups have expressed interest in this proposal and are able to provide resources. Among these are:

  • VA
  • Canada Infoway SCWG5 DI members
  • XDS Implementation Group members


Recent Aunt Minnie thread on site CD importation problems and practices here.

7. Risks

There is the risk that differences in opinion on how an importing system should behave could delay the completion of this work item, or result in such a multiplicity of options that it becomes confusing for both implementers and customers. For example, a number of issues have already been identified related to this:

  • Does the sending system need to support the capability of triggering the creation of an order corresponding to the prior Study? * What sort of behavior should the receiving system support regarding the archiving or flushing of foreign exams?

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 25%
  • IRWF extensions are probably straight forward, but need to make sure we do good review of typical site policies for handling priors to make sure our architecture doesn't preclude reasonable policy choices.

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA