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: Jonathan Whitby (previously 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.
radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing

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
The Importer actor searches for prior images <MinUE out of scope: and reports> for that patient, both locally and beyond

The Importer uses PIX/PDQ to get appropriate PIDs for searching

The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)
The Importer retrieves matching prior images <MinUE out of scope: and reports> executes import logic to map/fix codes and attribute values
The Importer stores the imported priors to the local PACS <MinUE Out of Scope: and Report Manager>
The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools
Post-interpretation rules (e.g. purging prior images and reports) occur locally

The Profile supports 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 Importer and Report Converter actors 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, Report Manager, Report Reader)
VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)
PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)
Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1

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/OMI (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)
MinUE Out of scope: Mobile Health Documents (MHD) -FHIR query documents
MinUE Out of scope: XDS.b retrieve - report retrieval
MinUE Out of scope: HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF

A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).

5. Discussion

The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:

Minimum Useful Effort (MinUE) Baseline scope: Complete the current IDEP supplement, but do NOT include:

Reports, in any format, not even TEXT or PDF
WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)
Retain Importer actor, but remove Report Converter actor and transactions
Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)
Complete the IHE Public Comment and Trial Implementation processes
(NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).

Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:

Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)
Only address TEXT and PDF report formats in direct scope in MaxUE
Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE

SEE THIS SUMMARY FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.

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 (XDS.b as named option)):

Workflow steps to be addressed:

patient identification and PID reconciliation
receipt of new orders
relevancy logic meta data identification
image retrieval
DICOM attribute mapping
storage of imported image
MinUE Out of scope: report retrieval
MinUE Out of scope: HL7 v2 ORU report attribute mapping
MinUE Out of scope:storage of imported reports
local purging of foreign images and foreign reports as defined Option

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 image access using DICOM web services, or storage of reports using FHIR, etc)
Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)
EMPI (PIX/PDQ) already in place between facilities.
Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.
Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)
Other image types such as Raw JPEG, PDF, etc., are out of scope.
MinUE Out of scope: Report formats are limited to TEXT and PDF.
MinUE Out of scope: Access of prior reports is limited to FHIR query for reports.
MinUE Out of scope: Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.
MinUE Out of scope: Report semantic content is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.

5. Technical Approach

Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.
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."
Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.

Existing actors

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

New actors

Importer (same actor as IRWF.b, but additional behaviors)
Report Converter

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. (ie., many transactions)

New transactions (standards used)

A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies". New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.

Impact on existing integration profiles

IOCM is "out of sync" with IDEP in terms of versions of standards used. IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now. IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.

New integration profiles needed

None.

Breakdown of tasks

The high level breakdown of tasks is:

1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.

2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)

3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.

4.) Public comment period

5.) Public comment review by TC and incorporation by Editor

6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.

The specific status of each section is listed in this document:

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 Emergency Department transfer
Scope creep related to incorporating additional report formats beyond TEXT and PDF.
Scope creep related to incorporating semantic meaning of reports.
Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.
Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms
Legal differences across jurisdictions

8. Open Issues

Scope creeped. Need to rein it back in, especially in the area of report formats. While report formats and transmission is undeniably a mess, the goal of the IDEP profile was never to fix report interoperability, but rather to access at least some of the prior reports. Complete report interoperability should be its own profile.

May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.

9. Tech Cmte Evaluation

Technical Evaluation:

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

% for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)
% for Minimum Useful Effort

1.) Focus strictly on external prior IMAGE access, coercion, and storage
2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes

Candidate Editor:

Jonathan Whitby/Vital