Foreign Exam Management Direct Import- Proposal

1. Proposed Workitem: Enterprise Priors

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

2. The Problem

Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist.

Unfortunately, with the mobility of modern healthcare, it is very common for priors to be located outside the reading institution.

Although there have been many improvements to the ability to exchange images between enterprises (or between departments within an enterprise), the ability to locate, access, and view priors (particularly during the short time frame required for them to be relevant to reading) is still not reliable.

• patient portals - are unwieldy, slow to access
• web-based viewers - are not integrated into the diagnostic workstation so they don't permit direct comparison viewing and use of local hanging protocols or viewing tools
• CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"
• all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b.

A solution for this priors problem will likely also reduce re-scanned patients (with cost and radiation implications) due to poor access to studies performed at other institutions.

3. Key Use Case

Order-driven priors:

• A physician orders a radiology study for a patient
• A Prior Imaging Manager (PIM - new actor) searches for priors (images and reports) for that patient, both locally and beyond
• The PIM uses order details and local rules to determine which priors are potentially relevant
• The PIM retrieves matching priors and executes import logic to map/fix codes and attribute values
• The PIM stores the imported priors to the local PACS (and Report Manager)
• The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools
• The PIM executes any post-interpretation rules (e.g. purging priors that were not viewed)

The Profile should flexibly support a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.

The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the PIM actor rather than distributed to every sending or receiving system.

Human Version

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 Problem Case Today

Dr. X. has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. X has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images.

Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. X. has to ask the remote site to print a CD/DVD with the images. He then asks 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 delays 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 Systems:

• EMPI (IHE: PIX/PDQ Manager)
• RIS/EMRs (IHE: SWF.b DSS/OF)
• VNA (IHE: Image Manager, XDS.b Registry)
• PACS (IHE: Image Manager/Archive)
• PIM (new actor which might be integrated into the EMR, the VNA, the workflow management system, an IRWF.b Importer, or possibly stand alone system).

Standards:

• IRWF.b - useful importation logic and data mappings (but that profile is passive and doesn't specify pre and post steps)
• PIX/PDQ - patient identification
• MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation
• HL7 v2.x ORM (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site
• DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images
• DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images
• DICOM C-Store - store images locally (default)
• HL7 v2.x ORU (RD:RAD-Y1) - store report locally (default)
• XDS.b retrieve - report retrieval
• DICOM SR query - alternate report retrieval
• HL7 v2.x ORU (Triggered?) - alternate report retrieval
• (NEW work) report attribute mapping consistent with intent to IRWF.b for DICOM attributes

The proposed standards and actors have already been sketched out in a supplement draft (Volume 1 and part of Volume 2).

A Profile Concepts section may discuss how FHIR and DICOMweb services could be integrated in the future. Recommend limiting the required transactions to the real-world installed base (ie., HL7 v2.x, DICOM, XDS.b).

5. Discussion

This is intended to be a Workflow profile with one primary use cases within one of two architectures (all-DICOM and XDS.b):

TODO Rework as list of tasks/topics:

• patient identification - PIX/PDQ as a client (reference PIX/PDQ profiles/transactions and include MIMA Vol 2 Appendix J for fully qualified Patient ID reconciliation)
• orders - access to orders for new studies at the local site - HL7 v2.x ORM (RAD-4 + IRWF.b data mappings )
• image retrieval - methods to retrieve DICOM objects are DICOM Q/R/C-Store and XDS.b-I. (RAD-5 and ITI-18))
• DICOM attribute mapping - references to IRWF.b, group with IRWF.b Importer Actor with local Image Manager
• image storage - DICOM C-Store to Image Manager would be the default method to send the study to the local PACS
• report retrieval - options to retrieve a report depend on the installed base source,specifically: receive an HL7 v2.x ORU, query DICOM SR, or XDS.b retrieve
• report attribute mapping - consistent with intent to IRWF.b for DICOM attributes (NEW work)
• report storage - HL7 v2.x ORU as a default (RD:RAD-Y1)

While FEM-DI may initially seem overlapping with existing IHE Radiology profiles, it is not. Specifically, the profile would:

• Illustrate specific "Priors" use cases (Volume 1 of TF)
• Add a new FEM Manager actor (Volume 1 of TF)
• Allow for workflow testing of named actors at the Connectathons and in RFPs
• Add additional minor data mappings (Message Semantics) to three existing Transactions (HL7: RAD-4 (Procedure Scheduled), RD RAD-Y1 (Send Report); DICOM: RAD-x (Store Images) (Volume 2 of TF)
• Add Expected Actions in those same existing Transactions for the FEM Actor in the FEM Profile (Volume 2 of TF)

Scope/assumptions:

Goal is to enable automated and integrated VIEWING of foreign radiology priors at the local system in the context of the study about to be read.

• 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.

Two specific use cases were determined to be "Local policy, out of scope for this profile." 1.) A new object (SR, GSPS, etc) is created by the radiologist at the Local site on the Prior study. It is out of scope for this profile, and considered to be local policy, whether or not that new object is replicated back up to the VNA/DI-r and/or originating PACS system. 2.) The radiologist is reviewing a prior study and discovers an anomaly, e.g., a missed critical finding. It is out of scope for this profile, and considered local policy, as to how the radiologist notifies the referring physician, original radiologist, patient, and/how the original report is amended. Most likely it will be a manual process, and is out of scope.

More detailed requirements 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 an FEM Manager which acts as a 'broker' between the source and consumer, hiding all the complex coercion logic. This minimizing the impact on existing systems, requiring very few changes if any.

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

STOP HERE FOR SHORT PROFILE PROPOSAL TEMPLATE AND DESCRIPTION

DETAILED PROFILE PROPOSAL additional sections below:

Technical Approach

With the intent of accurately identifying risk and This work was performed in advance to accurately identify risks and level of effort. Please note that under the direction of Canada Health Infoway, a solid initial version of Volume 1 of the supplement template has been completed and is available for the IHE Rad TC review immediately. A initial version of data requirements and mapping, as well as affected transaction analysis, has been completed for Volume 2 of the supplement. In other words, this proposal is almost ready for the February (second) IHE Rad TC meeting.

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-

Look at IOCM CP for data retention policies language.

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.

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.>

To write the profile from the template, the following items need to be completed:

• Determine if PIX/PDQ is sufficient (only PIX/PDQ?) for patient identification.
• Determine how far to address reports, specifically, since reports cannot be queried v. HL7 v2
• Draft two specific use case details (pre- and post-)
  • Post will probably be a Named Option, but still needs a use case
• Review IRWF.b and determine the best way to reuse the data mappings (identify if it is entire transactions or only tables)
• Determine if a new actor is needed (probably)
• Determine if ORM from SWF.b can be reused without changes (it certainly appears so)
• Determine if security section of IRWF.b can be directly reused/referenced
• Determine if the Named Option for the post- case can be text only (is that sufficient?) for instructions

there may even be an EMPI, but the studies have different PIDs, Accession numbers, or procedure codes.

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

• Because the IHE template has been completed for Volume 1 material and part of Volume 2, the risks are very well identified.
• The FUNC Profile RAD-Y1 must be completed prior to this supplement.

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):

• xx%

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Teri Sippel Schmidt, with input and review by David Koff, MD, and Canada Health Infoway members

Web Sequence Diagram

saving for posterity:

instructions for https://www.websequencediagrams.com/

title Automated Discovery and Retrieval of Relevant Priors Local DSS/OF->Local IM/IA: 1. Procedure Scheduled [RAD-4] Local DSS/OF->FEM/IRWF Importer: 2. Procedure Scheduled [RAD-4] FEM/IRWF Importer->PIX Mgr: 3. PIX Query [ITI-9] for other PIDs FEM/IRWF Importer->Remote IM/IA: 4. Query for Studies [RAD-76] DICOM C-Find FEM/IRWF Importer->XDS Registry: 5. XDS Query [ITI-] FEM/IRWF Importer->FEM/IRWF Importer: 6. aggregate results and determine relevance FEM/IRWF Importer->Remote IM/IA: 7. Obtain prior study data (DICOM C-Move) FEM/IRWF Importer->FEM/IRWF Importer: 8. map PIDs and study data (IRWF.b) FEM/IRWF Importer->Local IM/IA: 9. Store prior study (DICOM C-Store) FEM/IRWF Importer->Local IM/IA: 10. Store prior report (HL7 ORU)