Foreign Exam Management Direct Import- Proposal

1. Proposed Workitem: Foreign Exam Management - Direct Import

Proposal Editor: Teri Sippel Schmidt
Proposal Contributors: David Koff, MD
Editor: Teri Sippel Schmidt
Contributors: David Koff, MD; Canada Health Infoway
Domain: Radiology

2. The Problem

Proposed Profile change of name to: Automated Discovery and Retrieval of Relevant Priors

Definition: "Foreign Exam Management- Direct Import" (FEM-DI) - Foreign Exam Management Direct Import is the automation of the process of locating relevant prior radiologic studies performed elsewhere (with network access) and properly and directly integrating those relevant prior studies into the "local PACS" at a different site or institution such that a the studies appear as a "proper prior study" in the same patient folder and direct comparisons may be made by the radiologist in a timely manner using the same hanging protocols.

FEM-DI is effectively a wrapper around IRWF.b transactions. In IRWF.b, it is assumed that the studies "arrive", either via a CD/DVD transported somehow (mail, patient carried, etc.) or over a network. The trigger for the "arrival" is not specified, nor is the long term storage of the study. IRWF.b does not specify these two steps:

1.) pre: if a study is ordered, actively go out and search for relevant priors (IRWF.b is passive)
-use IRWF.b use case to import studies and map data here -
2.) post: IRWF.b does not specify what to do with the imported "prior studies" data after the study has been read

Taking a step back, overview of the broader relevant priors clinical problem:

Over time, patients may receive radiology and/or other studies at many various sites which may or may not be part of the same IDN or "affinity domain". However, these other studies are often "locked away" and inaccessible on a PACS system at a different institution, or even just a different site within the same institution. In other words, radiologic prior studies created at a foreign site should appear seamlessly for the radiologist in the local PACS for participating institutions, without the use of CD/DVDs.

Often, these previous studies, called "priors", have significant/irreplacable clinical value. The reading radiologist may change a diagnosis or recommendation based on this historical information.

"The redistribution of medical care into centers of excellence providing centralized specialized care to larger service areas has improved patient outcomes and standardized treatments leading to better patient outcomes. (Stitzenberg et al. 2009) One consequence of this redistribution of care has been the increased flow of patients from peripheral clinics and hospitals to larger tertiary and quaternary care centers with referrals for specialist assessment. " (quoted from SPIE paper)

Today, these prior imaging studies may be shared via:

patient portals
web-based viewers
CD/DVD imports/viewers
other methods

Issues with these methods include login/display time, access issues, direct comparison viewing (e.g., different Patient ID/patient folders), inappropriate hanging protocols (time issue), CD/DVD import issues, inappropriate display tools or hanging protocols, etc. The patient may also be re-imaged as a result.

3. Key Use Case

This is intended to be a Workflow profile with one primary use cases:

1. New radiology order drives search for relevant priors across integrated healthcare delivery network to be imported directly into local PACS for comparisons

Note that there is a second primary use case:

2. Radiologist becomes aware of relevant prior, possibly through patient or family member, and initiates search (federated or ad hoc query on demand) for relevant priors across integrated healthcare delivery network to be brought directly into local PACS for comparisons

It is hoped that this federated ad hoc query use case is handled by the profile proposal:

I. Federated DICOM Query Retrieve - Proposal -presented by David Clunie

For this proposal, however, the ad hoc federated query is considered out of scope.

Detailed example - order driven priors clinical use case:

Assumption: A regional or Integrated Delivery Network (IDN) has implemented a Diagnostic Imaging Repository (DI-r) or Vendor Neutral Archive (VNA) for the storage and archiving of images. This DI-r/VNA stores studies as they are received (without DICOM or other attribute modifications). Alternatively, the studies may not be centrally archived, but there may be direct and secure access to any PACS system on the network via DICOM DIMSE Services.

Dr. X., a radiologist at a busy Cancer Centre, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote, but secure network connected, sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.

Dr. X. needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr X has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.

Dr. X. wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution.

The last thing Dr. X. wants is to have to access a separate website even if it was to use a single sign-on. He doesn’t want to have to search a separate database, he doesn’t want to wait for images to load as it will slow him down too much through his very busy work day. To make things worse, Dr. X may have to open two separate web interfaces, one for the images, another one for the report, as the DI-r/VNA may not be able to move the report with the images.

Today and in the past, even if all studies are all stored on a central DI-r/VNA or there is access to other DICOM PACS systems, Dr. X. will have to ask the remote site to print a CD/DVD with the images. He will then ask his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it will defer the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.

4. Standards and Systems

Real World Affected Systems (IHE Actor Name):

EMPI (Patient Identification -PIX/PDQ Manager)
RIS/EMRs - an system which creates orders (DSS/OF)
VNA or DIr (Image Archives)
PACS (Image Managers/Image Archives)
new actor - FEM Manager which may or may not be integrated into another real world system (ie., part of the EMR, part of the VNA, part of a workflow management system, or possibly stand alone system). The FEM Manager may be grouped with the IRWF.b Importer actor.

Standards to be used:

Existing profiles referenced-although the following profiles will be referenced, these profiles would not be directly affected (ie., no changes anticipated to existing profiles) These interactions may also be discussed in the Cross Profile Considerations section:

PIX/PDQ (other patient cross-referencing considerations?)
SWF.b (for orders)
XDS.b/XDS.b-I
IRWF.b

More specifically, the profiles will be referred to for:

patient identification - PIX/PDQ as a client (reference PIX/PDQ profiles/transactions) (other PIX-like standards?)
orders - access to orders for new studies at the local site - HL7 v2.x ORM (as defined in SWF.b, pointer)
image retrieval - various methods including DICOM Q/R/C-Store and XDS.b-I. (pointers to various IHE Rad transactions)
DICOM attribute mapping - references to IRWF.b, possibly group with IRWF.b Importer Actor
image storage - DICOM C-Store to Image Manager would be the default method to send the study to the local PACS
report retrieval - various options to retrieve a report depending on the source,specifically receive an HL7 v2.x ORU or use XDS.b as an option
report attribute mapping - consistent with intent to IRWF.b for DICOM attributes
report storage - HL7 v2.x ORU as a default

We recommend a discussion of how FHIR and DICOM web services could be integrated in the future, but limit the required transactions to the majority of the real-world installed base (ie., HL7 v2.x and DICOM).

5. Discussion

Scope/assumptions:

Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not DICOM web services, FHIR, etc)
Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)
EMPI (PIX/PDQ) already in place between facilities.
The current scope to access prior imaging studies would default to DICOM, but have XDS-I as an Option.
The current scope would limit required imaging study import transactions to DICOM to the local PACS. (ie., not direct XDS import to the local PACS)
The current scope to access prior reports would default to HL7 v2 ORU, but have XDS-I as an Option.
The current scope would limit required prior reports import transactions to HL7 v2 ORU to the local PACS.
Other image types such as Raw JPEG, PDF, etc., are out of scope.
Report content is out of scope, i.e., structured or unstructured, text or xml, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.

Definition required in this profile:

The foreign exam must appear as historic prior during the reporting session (same patient folder). This means reconciliation of different patient identifiers, standardization of procedures and terminology in HL7 and DICOM. See IRWF.b for information.
The local PACS must have enough data to be able to present the foreign exam(s) using the local hanging protocols to be displayed seamlessly side by side with the current exam.
The local PACS must not re-archive a foreign exam to the Diagnostic Imaging repository/VNA and no change or alteration (new measurements or post processing) to the foreign exam will be stored.
The local PACS should only store the foreign exam temporarily in the cache

Contrary to IRWF.b or MIMA which puts the requirement on either the consumer side or the source side, this profile introduces FEM Manager who acts as a 'broker' between the source and consumer, hide all the complex coercion logic. This minimize the impact on existing systems.

More background here:

Investigation into the need for ingesting foreign imaging exams into local systems and evaluation of the design challenges of Foreign Exam Management (FEM); SPIE, Milovanovic, et al
Canada Health Infoway XDS Implementation Guide - Foreign Exam Management, 2013
IHE Radiology IRWF.b - for data mappings specifically

Technical Approach

Existing actors

See diagram below for basic transaction sequence of these actors.

ITI Patient Identifier (PIX) Manager
ITI Patient Demographics Query (PDQ) Supplier
Rad Department System Scheduler/Order Filler (DSS/OF)
Rad Image Manager/Image Archive
ITI Cross Enterprise Document Sharing (XDS) Registry
ITI Cross Enterprise Document Sharing (XDS) Repository
Rad Import Reconciliation Workflow (IRWF.b) Importer (or just use IRWF.b transactions)

New actors

Foreign Exam Manager (FEM) Actor (may need name change)

Existing transactions

The following transactions will be used:

Procedure Scheduled RAD-4 (HL7 ORM)
PIX Query ITI-9
Query for Studies RAD-76 (DICOM C-Find)
XDS Query ITI-48 (check this number)
XDS Retrieve ITI-

New transactions (standards used)

Need to determine report transport methods which will be included, but could be:

HL7 v2.x ORU send with or without wrapped CDA (doesn't this exist anywhere yet?!?)

Impact on existing integration profiles

Compliments existing profiles, not intended to change them.

New integration profiles needed

This would be a new profile.

Support & Resources

Contributors/reviewers who have already agreed to assist and allot time for clinical and technical reviews:

David Koff, MD
Canada Health Infoway resource/review possible

Risks

It may be that PIX/PDQ may not be sufficient for cross enterprise patient identification.
PIX/PDQ may not be as common in existing install base
HL7 ORU transactions may not be sufficient. May require to store reports in another system for sharing.

Open Issues

Name of profile - consider change recommended above.
For the "post IRWF.b" use case it is not apparent that a transaction can fulfill this need. Basically, it says "you must delete these imported studies and not re-archive". It may just be self-assertion on an IHE Conformance Statement with basic guidelines (e.g., within x weeks) in the profile.

The rationale to specify 'not re-archive' is so that the original study is not being modified by the foreign PACS.

What is the expectation if the foreign PACS, in the process of reviewing the foreign study, creates new markup and captured as GSPS for example? Should the foreign PACS archive the GSPS or keep it local because there is no re-archive of the study?

To be discussed. It may be desirable to have the GSPS archived back to the central archive. The objects may be marked so that it is known to be not part of the original study. Need to discuss if the central archive / FEM Manager is required to send these evidence objects back to the original PACS.

Source of reports (storage of reports) is not clear. There is no HL7 v2 query mechanism for reports. This may require the FEM Actor to store copies of all reports, which is not pretty.
For the local PACS to notify a VNA or DI-r that prior studies have been purged would require IOCM. Very few PACS support IOCM today and this would not be in the vein of "keep it simple and old-school". If we were to include this, it should be as a named option and not required.

What is the expectation on notification for the source system? For example, when the destination system receives the study, finished reviewing the study, generate new objects, etc.

This profile focus on the ingestion of foreign exams to the destination PACS. It focuses on distribution of priors. Notification to the source system is out of scope, left as local policy. Should be documented in the profile in the consideration section.

Tech Cmte Evaluation

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

25%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Teri Sippel Schmidt, with input and review by David Koff