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 Search 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 query use case is handled by the profile proposal:

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

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
• XDS.b/XDS.b-I
• MDH/MDH-I
• IRWF.b
• IOCM

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, possibly expand beyond the default option
• report retrieval - various options to retrieve a report depending on the source,specifically receive an HL7 v2.x ORU or use MHD or 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, but consider expanding to MHD and XDS.b as options

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:

• 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. Possibly QIDO/STOW as options also.
• 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. Possibly FHIR as an option? not yet.
• 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.

Sequence of Order Driven Workflow - Overview:

• An order is created (HL7 v2.x ORM) with a specific procedure code, date, time, location
• The FEM actor receives a copy of that order (timing to be discussed in profile) and queries EMPI for additional PIDs (PIX query)
• The FEM actor queries all other pre-configured storage systems (PACS, VNAs, DI-r, RIS, etc.) for studies, including the report(s), for other patient IDs
• The FEM actor receives image and report query responses and determines relevance of the other existing studies
• The FEM actor queries remote storage system and obtains relevant studies
• The FEM actor maps image and report attributes appropriately for "local PACS" (see IRWF.b)
• The FEM actor stores the "locally mapped DICOM study and report" to the local PACS to ensure that these studies appear appropriately as priors in the local PACS

I will clean up this diagram later, was on vacation:

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 and will notify the DI-r/VNA when the foreign exam is purged.

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

Report communication

Select one mechanism among the several options listed above or another option. The main discussion would be which mechanism is preferred. The specific mechanism is quite well understood.

Report content

CDA Content based on DICOM/HL7 Part 20.

Specifically, see DICOM Part 20 section 7 for the high level list of CDA Sections. These include:

• • Clinical Information (history and clinical information) - may be text-only section (optional section)
  • Current imaging Procedure Description (information about the study which was just performed) - requires Study Inst UIDS, (section required)
  • Comparison Studies - may be text section only (optional section)
  • Findings - may be text-only section (optional section)
  • Impressions - may be text-only section (section required); would include a named Option for Communication of Actionable Findings in this section
  • Addendum - may be text-only section (optional section)

Specifically, see DICOM Part 20 section 9.8.10 for the "Communication of Actionable Findings" section which would be a named Option within this profile.

Existing actors

Report Repository Report Reader

Content Creator Content Consumer

New actors

No new actors, but depends on transport mechanisms possibly.

Existing transactions

Intent is to reuse existing transport transactions wherever possible.

New transactions (standards used)

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

• HL7 v2.x ORU wrapped CDA
• DICOM Encapsulated CDA, PDF or SR
• XDS.b encapsulated CDA (exists already)
• FHIR Diagnostic Report Resource

Impact on existing integration profiles

Compliments existing profiles, not intended to change them.

New integration profiles needed

This would be a new profile. The exact name could either mirror Part 20, or close.

Support & Resources

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

• Chuck Kahn, MD, HUP
• Paul Nagy, Johns Hopkins
• Eliot Siegel, MD, UMD
• Justin Cramer, MD, Nebraska
• Marta Heilbrun, MD, U of Utah

Risks

• CDA might be new to the IHE TC members.
• FHIR might be new to IHE TC members if FHIR is chosen as the transport mechanism and/or the DiagnosticReport resource is chosen as the content specification.
• Someone may consider this as competing with XDS / XDS-I

Open Issues

• IHE Rad TC may not be very familiar with CDA description or FHIR transaction.
• This profile has some overlap with Foreign Study Management - Direct Import proposal.

Tech Cmte Evaluation

White Paper including a section with two examples on how we could profile using part 20 Effort Evaluation (as a % of Tech Cmte Bandwidth):

• xx%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Teri Sippel and Kinson Ho

Open Issues:

• Maybe the name of this proposed profile is way off? Perhaps "Automated Search and Retrieval of Relevant Priors" would be less confusing to everyone?
• Determine which PIX query methods to be supported. Should be consistent with Federated Query profile is that is also accepted
• Determine what possible source transactions are for images (QIDO, or just DICOM and XDS.b-I)
• Determine what possible source transactions are for reports
• Didn't SWF.b CP-222 also affect IRWF.b? need to check into this. Need Enterprise Identity Option mappings also.

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Teri Sippel Schmidt