Import and Display of External Priors- Proposal

1. Proposed Workitem: Import and Display of External Priors (IDEP)

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

This proposal was previously called "Foreign Exam Management (FEM)".

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 for direct comparison, 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, and on different monitors
web-based viewers - are not integrated into the diagnostic workstation so they don't permit side-by side image comparison 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 has been demonstrated to also reduce re-scanned patients (with cost and radiation implications) due to poor access to studies performed at other institutions. (Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)

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 PIX to get appropriate PIDs for searching

The PIM uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)
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 <Out of Scope: 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)

The Profile will 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 of the Clinical Use Case

Dr. Smith, a radiologist at a busy Cancer Center, 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. Smith 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 Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.

Dr. Smth 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. Smith 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. Smith 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. Smith 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 or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source)
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 additional system).

Standards:

IRWF.b - useful importation logic and data mappings (but that IRWF.b 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)
Out of scope MEU: HL7 v2.x ORU (RD:RAD-Y1) - store report locally (default)
Out of scope MEU: XDS.b retrieve - report retrieval
DICOM SR query - alternate report retrieval
(NEW work) Out of scope MUE: 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 case and one of two back-end architectures (all-DICOM and XDS.b):

Workflow steps to be addressed:

patient identification and PID reconciliation
receipt of new orders
relevancy logic meta data identification
image retrieval
DICOM attribute mapping
imported image storage
Out of scope MUE: report retrieval
Out of scope MUE: HL7 v2 ORU report attribute mapping
Out of scope MUE:imported report storage
Out of scope MUE: purging of images

Scope/assumptions:

Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.

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. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.
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)
Out of scope: The current scope to access prior reports would default to HL7 v2 ORU, but have XDS-I as an Option.
Out of scope: The current scope would limit required prior reports import transactions to HL7 v2 ORU text 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.

5. Technical Approach

Populate <specific data element>, but stay away from terminology mapping.
Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)
No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.
Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."

Minimum Use Effort:

1.) Select only XDS or DICOM environment
2.) Leave purging out of scope

Existing actors

"Local" DSS/OF
"Local" Image Manager
Out of scope: "' "Local" Report Manager
PIX Manager
"Remote" Image Manager
Out of scope: "' "Remote" Report Manager
XDS.b Registry
Out of scope: "' XDS.b Repository
XDS.b-I Imaging Document Source

New actors

PIM Manager

Existing transactions

Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.

See IDEP transaction diagram.

New transactions (standards used)

It is not clear that any new transactions will be necessary. Additional behaviour may be required on existing actors in existing transactions in the Expected Actions section. Out of scope: Additional data mappings will be required, especially for report conversions, if we decide to include that within scope.

Impact on existing integration profiles

Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.

New integration profiles needed

None.

Breakdown of tasks

The IHE TF Volume 1 material for the one use case in two environments (XDS and DICOM), with a couple hours of clean up by the editor, is effectively ready for the Nov F2F IHE RAD TC meeting today.

Assuming proposed scope is agreed to:

single use case "import and display of external priors within affiliated institutions"

Steps:

1.) Agree to scope (one use case, two environments)
2.) Agree to basic transaction diagram (provided)
3.) Update second environment transactions, based on agreement of first environment
4.) Out of scope: Determine number of report format meta data conversions (HL7 ORU)
5.) Determine need to move Purging to option based on legal requirements
6.) Update volume 1 w/ any changes to transaction diagram
7.) Add Expected Actions section to appropriate transactions to include "If this Actor is an Actor in the IDEP profile, also ...."
8.) Out of scope: Add report meta data mapping sections to transactions of RAD-Y1 (Sending Imaging Results) and also DICOM SR transaction

See section 4 (Standards and Systems) for detailed list of transactions.

6. Support & Resources

Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.

HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.

7. Risks

Scope creep to closely related clinical issues such as ED transfer
Out of scope: Selecting too many report meta data formats to incorporate
Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms
Legal differences across jurisdictions

8. Open Issues

See Risks.

9. Tech Cmte Evaluation

Technical Evaluation:

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

40% for Maximum/Full Effort (imaging and only reports as HL7 ORU text)
25% for Minimum Useful Effort

1.) Select only XDS or DICOM environment
2.) Leave purging out of scope
3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)

Candidate Editor:

Teri Sippel Schmidt