Difference between revisions of "Import and Display of External Priors- Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(144 intermediate revisions by 3 users not shown)
Line 3: Line 3:
  
 
* Proposal Editor: Teri Sippel Schmidt
 
* Proposal Editor: Teri Sippel Schmidt
−
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell
+
* Proposal Contributors: David Koff MD; Canada Health Infoway; Kevin O'Donnell
−
* Editor: Teri Sippel Schmidt
+
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)
−
* Contributors: David Koff, MD; Canada Health Infoway
+
* Contributors: David Koff MD; Canada Health Infoway; Teri Sippel Schmidt
 
* Domain: Radiology
 
* Domain: Radiology
  
−
This proposal was previously called "Foreign Exam Management (FEM)".
+
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".
  
 
==2. The Problem==
 
==2. The Problem==
Line 14: Line 14:
 
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.  
 
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.
+
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'''.
 
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'''.
−
* side-by-side image comparison with the same hanging protocols is often required for proper review and analysis
 
 
* patient portals - are unwieldy, slow to access, and on different monitors
 
* 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 direct comparison viewing and use of local hanging protocols or viewing tools
+
* 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"
 
* 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.     
 
* 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.
 
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.
−
<NEED JASON's REFERENCE>
+
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)
  
 
==3. Key Use Case==
 
==3. Key Use Case==
  
−
'''Order-driven priors:'''
+
===Use Case 1: Reviewing current imaging study along with external priors===
  
 +
This scenario is widely supported when restricted to locally-acquired imaging studies. The goal of this supplement is to ensure that it is consistently supported between institutions and to work in conjunction with the existing install base of PACS systems without necessitating changes or upgrades.
 +
 +
The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.
 +
 +
 +
====User Scenario====
 
:* A physician orders a radiology study for a patient
 
:* 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 radiologist wants to review the new study along with any relevant priors ('''MaxUE''': and their associated reports)
−
::* PIM may need to use PIX/PDQ to get appropriate PIDs for searching
+
::* Acquired locally
−
:* The PIM uses order details and local rules to determine which priors are potentially relevant
+
::* Acquired at affiliated institutions
−
:* The PIM retrieves matching priors and executes import logic to map/fix codes and attribute values
+
:* The radiologist wants all prior studies ('''MaxUE''': and reports) to work correctly with all their normal reading tools
−
:* The PIM stores the imported priors to the local PACS and Report Manager
+
::* Consistent patient identifiers
 +
::* Consistent procedure codes
 +
::* Consistent body parts
 +
::* Etc.
 +
:* The import system finds, localizes and imports all relevant prior imaging studies ('''MaxUE''': and reports)
 
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools
 
:* 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.'''
+
====Supporting Data Flow====
 +
:* The import system receives the radiology order and extracts key metadata
 +
::* Patient identifiers
 +
::* Procedure codes
 +
::* Modality
 +
:* The import system queries the EMPI to determine appropriate patient identifiers for each affiliated site
 +
:* The import system searches each affiliated site for prior imaging studies for the patient, retrieving key metadata for each study
 +
::* Modality
 +
::* Procedure codes
 +
::* Study dates
 +
:* '''MaxUE''': The import system searches each affiliated site for diagnostic imaging reports for the patient, retrieving key metadata for each report
 +
::* Report domain (if repository not radiology-specific)
 +
::* Report codes
 +
::* Report dates
 +
:* The import system filters prior imaging studies based on order metadata, query results and configured relevancy rules
 +
:* '''MaxUE''': The import system filters prior diagnostic imaging reports based on order metadata, query results and configured relevancy rules
 +
:* The Importer retrieves prior imaging studies that match the filter
 +
:* '''MaxUE''': The Importer retrieves prior diagnostic imaging reports that match the filter
 +
:* The import system executes import logic to localize import imaging studies ('''MaxUE''': and diagnostic imaging reports)
 +
::* Replacing existing patient identifiers and demographics with local values
 +
::* Etc.
 +
:* The import system stores the imported imaging studies to the local PACS
 +
:* '''MaxUE''': The import system stores the imported diagnostic imaging reports to the local report repository
 +
:* After radiological interpretation of the current study, external data is purged according to local policies
 +
::* Triggers on current study report being finalized
  
  
−
'''Human Version of the Clinical Use Case'''
+
====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, 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.
Line 53: Line 85:
 
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.  
 
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'''
+
 
 +
====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.   
 
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.   
Line 59: Line 92:
 
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.
 
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:'''
+
====Workflow steps to be addressed====
−
:* 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 possibly stand alone system).
 
  
 +
:* patient identification and PID reconciliation
 +
:* receipt of new orders
 +
:* metadata that can be applied to the relevancy logic
 +
:* imaging study retrieval 
 +
:* DICOM attribute mapping / localization
 +
:* storage of imported imaging studies
 +
:* '''MaxUE:''' diagnostic imaging report retrieval
 +
:* '''MaxUE:''' HL7 v2 ORU diagnostic imaging report attribute mapping
 +
:* '''MaxUE:''' storage of imported diagnostic imaging reports
 +
:*  local purging of foreign imaging studies and foreign diagnostic imaging reports as defined Option
  
−
'''Standards:'''
+
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)).
−
:* 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).
+
====Assumptions====
  
−
==5. Discussion==
+
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.
  
−
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): 
+
:* 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 
 +
::* XDS-I Pption would include hybrid DICOM/XDS.b environment
 +
:* Storage of imaging study limited to DIMSE DICOM to the local PACS
 +
::* i.e. no direct XDS import to the local PACS
 +
:* Other image types such as Raw JPEG, PDF, etc. out of scope
 +
:* '''MaxUE:''' Report formats are limited to TEXT and PDF
 +
:* '''MaxUE:''' Access of prior reports is limited to FHIR query for reports
 +
:* '''MaxUE:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content
 +
:* '''MaxUE:''' 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'''
  
−
'''Sub-Topics to be addressed:'''
+
==4. Standards and Systems==
−
:* patient identification and ID reconciliation
 
−
:* access to new orders
 
−
:* relevancy logic and associated attributes
 
−
:* image retrieval 
 
−
:* DICOM attribute mapping
 
−
:* imported image storage
 
−
:* report retrieval
 
−
:* report attribute mapping
 
−
:* imported report storage
 
  
−
'''Scope/assumptions:'''  
+
===Real World Systems===
 +
:* EMPI (IHE: PIX/PDQ Manager)
 +
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)
 +
:* VNA, Enterprise Imaging Repository or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry, XDS.b Document Repository, XDS.b 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
  
−
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)
+
===Standards===
−
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)
+
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)
−
:* EMPI (PIX/PDQ) already in place between facilities.  
+
:* PIX/PDQ - patient identification
−
:* The current scope to access prior imaging studies would default to DICOM, but have XDS-I as an Option. 
+
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation
−
:* 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)
+
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site
−
:*  The current scope to access prior reports would default to HL7 v2 ORU, but have XDS-I as an Option. 
+
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images  
−
:* The current scope would limit required prior reports import transactions to HL7 v2 ORU to the local PACS.
+
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images
−
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.
+
:* DICOM C-Store - store images locally (default)
−
:* 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.
+
:* '''MaxUE:''' Mobile Health Documents (MHD) -FHIR query documents
 +
:* '''MaxUE:''' XDS.b retrieve - report retrieval
 +
:* '''MaxUE:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF
  
−
The following are likely "Local policy and out of scope for this profile":
+
Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).
−
# If the radiologist creates a new object (SR, GSPS, etc) on a Prior study, should it be replicated back to the original source of the prior.
+
:* A Cross Profile Consideration should discuss how DICOMweb services could be integrated in the future for image access and retrieval.
−
# If the radiologist finds an anomaly in a Prior, e.g., a missed critical finding, how is the referring physician, original radiologist, and patient notified, and how is the original report amended. Most likely it will be a manual process.
 
  
−
'''More detailed requirements:'''
+
==5. Technical Approach==
  
−
:* 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.
+
:* Assign most "intelligence" and mapping to new IDEP actors (Importer and Report Converter).  This limits changes to ancillary systems.
−
:* 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.
+
:* Require certain specific data elements be populated, but avoid defining specific terminology mappings.
−
:* The retrieval filter may need to be quite broad since radiologists may want a fairly "focused" set of priors presented initially but may want to expand their horizon to look at priors initially deemed less relevant (and don't want to wait for them to be retrieved now).
+
:* No intention to map procedure codes, study description, etc.  Discuss in X.4 Concepts sections.
−
:* 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.
+
:* Communicate metadata to be able to determine relevancy, but do not define relevancy rules.  Server side v. client side filtering. (although IDEP would specify client side filtering.)
−
:* The local PACS should only store the foreign exam temporarily in the cache
+
:* Do not over-specify display requirements; e.g., "Shall indicate on the display that it is an external study."
−
:* 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.
+
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not make it a requirement.
  
−
'''More background:'''
 
−
:* [http://spie.org/Publications/Proceedings/Paper/10.1117/12.2082879 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
 
  
−
 
−
'''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===
 
===Existing actors===
  
−
See diagram below for basic transaction sequence of these actors.
+
:* "Local" DSS/OF
−
* ITI Patient Identifier (PIX) Manager
+
:* "Local" Image Manager
−
* ITI Patient Demographics Query (PDQ) Supplier
+
:* "Remote" Image Manager
−
* Rad Department System Scheduler/Order Filler (DSS/OF)
+
:* '''MaxUE:''' "Local" Report Manager
−
* Rad Image Manager/Image Archive
+
:* '''MaxUE:''' "Remote" Report Manager  
−
* ITI Cross Enterprise Document Sharing (XDS) Registry
+
:* PIX/PDQ Manager
−
* ITI Cross Enterprise Document Sharing (XDS) Repository
+
:* XDS.b Registry
−
* Rad Import Reconciliation Workflow (IRWF.b) Importer  (or just use IRWF.b transactions)
+
:* XDS.b Repository
−
 
+
:* XDS.b-I Imaging Document Source
  
  
 +
===New actors===
  
−
===New actors===
+
:* Importer (same actor as IRWF.b, but additional behaviors)
 +
:* '''MaxUE''': Report Converter
  
−
* Foreign Exam Manager (FEM) Actor (may need name change)
 
  
 
===Existing transactions===
 
===Existing transactions===
  
−
The following transactions will be used:
+
:* HL7 v2, DICOM DIMSE, XDS.b and FHIR transactions (i.e. focus on improving the functionality of the existing installed base)
−
* Procedure Scheduled RAD-4 (HL7 ORM)
+
::* See IDEP transaction diagram
−
* 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)===
 
===New transactions (standards used)===
  
 +
:* "Query for Patient Studies": new DICOM query
 +
:* New mapping tables
 +
::* Order (OMI) message data for relevancy
 +
::* Coercion of MHD data for External Prior Reports
 +
::* HL7 v2 ORU for External Prior Reports Mapping
  
−
Need to determine report transport methods which will be included, but could be:
+
===Impact on existing integration profiles===
−
:* HL7 v2.x ORU send with or without wrapped CDA  (doesn't this exist anywhere yet?!?)
 
  
−
===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
 +
::* SWF.b not being integrated into main standard makes it hard to put all of the pieces together.
  
−
Compliments existing profiles, not intended to change them.
 
  
 
===New integration profiles needed===
 
===New integration profiles needed===
  
−
This would be a new profile.
+
:* IDEP
 +
 
 +
 
 +
===Breakdown of tasks===
  
−
===Breakdown of tasks that need to be accomplished===
+
Significant work has already been completed:
−
''<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.>''
+
* IDEP draft is currently ~80 pages
 +
* Draft includes all transactions / mapping tables
 +
* at the IHE Rad TC Apr F2F 52 pages were reviewed in detail, including the most difficult/controversial sections
 +
* at the IHE Rad TC Feb F2F 25 pages were discussed in detail, but not reviewed, but much of this is informative and mapping tables
 +
* the status of each section is here: https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing
  
−
To write the profile from the template, the following items need to be completed:
+
'''Transactions'''
−
* Determine if PIX/PDQ is sufficient (only PIX/PDQ?) for patient identification.
+
* Query for Patient Studies - get study metadata from local/remote PACS using pre-mapped Patient ID
−
* Determine how far to address reports, specifically, since reports cannot be queried v. HL7 v2
+
:* returned information needs to be adequate for relevancy filtering
−
* Draft two specific use case details (pre- and post-)
+
:* draft transaction exists based on C-FIND; cloned Query Images?
−
**Post will probably be a Named Option, but still needs a use case
+
:* SP 1 effort
−
* Review IRWF.b and determine the best way to reuse the data mappings (identify if it is entire transactions or only tables)
+
* Review appropriateness of existing transactions
−
* Determine if a new actor is needed (probably)
+
:* SP 1 effort (mostly work for editor)
−
* 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
 
−
* Add 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)
 
−
there may even be an EMPI, but the studies have different PIDs, Accession numbers, or procedure codes.
 
  
−
==Support & Resources==
+
'''Profile'''
 +
* Profile body - draft exists (68 pages); much is committee reviewed; not public commented
 +
:* SP 2 effort
 +
* Use Case: IDEP with DIMSE Q/R mechanisms (baseline)
 +
:* 14 existing transactions, 1 new transaction
 +
:* confirm no gaps that would require change to any of the 14 existing
 +
:* draft exists; much is committee reviewed; not public commented
 +
:* SP 1 effort
 +
:* SP 1 complexity
 +
* Use Case: IDEP with XDS-I Q/R mechanisms (option)
 +
:* ~15 existing transactions, no new transaction?
 +
:* draft exists; much is committee reviewed; not public commented
 +
:* SP 1 effort
 +
:* SP 1 complexity
 +
* Use Case: IDEP with Reports (option) (MaxUE)
 +
:* adds ~6 transactions for finding/transporting Text/PDF reports using DIMSE, HL7v2 & MHD mechanisms
 +
:* SP 1 effort
 +
:* SP 1 complexity
 +
* Add new report transcoding specification for different wrappers and metadata mapping
 +
:* SP 1 effort
 +
:* SP 1 complexity
 +
* Remove all references to reports & Report Converter (40% of document) - If MinUE
 +
:* SP 0 effort (work on editor)
 +
* Confirm different deployment models
 +
:* draft exists; much is committee reviewed; not public commented
 +
:* SP 1 effort
 +
:* SP 1 complexity
 +
* Confirm IRWF image import mapping requirements meet all the needs of IDEP
 +
:* SP 1 complexity
 +
* Confirm key relevancy metadata and availability via query mechanisms
 +
:* DICOM
 +
:* XDS
 +
:* SP 1 complexity
 +
* Confirm key hanging protocol metadata and proper import mapping
 +
:* SP 1 complexity
 +
* Mapping Table - DICOM Header of Prior to Local HL7v2 OMI
 +
:* draft exists
 +
:* SP 1 effort
 +
* Mapping Table - MHD DocumentManifest Resource to HL7v2 ORU (MaxUE)
 +
:* draft exists
 +
:* SP 1 effort
 +
:* SP 1 complexity
 +
* Mapping Table - Object for Import MHD DocumentReference and HL7v2 OMI to local report Resultant Document Manifest (MaxUE)
 +
:* draft exists
 +
:* SP 1 effort
 +
:* SP 1 complexity
  
−
Contributors/reviewers who have already agreed to assist and allot time for clinical and technical reviews:
+
'''Topics/Debates'''
 +
* '''MaxUE''': Debate scope details (then fix profile details to match)
 +
:* SP 1 uncertainty
 +
:* SP 1 effort
 +
:* Defensive mantra: Reporting is another profile
 +
* Consider detection of duplicates/versions of the same data to avoid replication cascade; interaction with IOCM
 +
:* some text exists in Concepts X.4.1.8 + Purge Options
 +
:* SP 1 uncertainty
 +
:* SP 1 complexity
 +
* Which report transports/wrappers for text/PDF are in scope?
 +
:* DIMSE C-MOVE, C-STORE, HL7v2 ORU, OMI, FHIR, ...
 +
:* ASCII/binary blob, CDA1, CDA2, DICOM PDF, DICOM SR, DICOM SC, DICOM SD, ...
 +
:* Note: payload is ONLY text or PDF; other report payload types might be mentioned in Informative annex
 +
:* SP 1 uncertainty
  
−
:* David Koff, MD
+
'''Proposed Minimum Useful Effort (MinUE) Scope'''
−
:* Canada Health Infoway resource/review possible
+
:*  Complete the current IDEP supplement
 +
:*  Do not include reports in any format -- not even TEXT or PDF
 +
:*  Do not include 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 but remove Report Purge as Named Option
 +
:*  (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).
  
−
==Risks==
+
'''Proposed Maximum Useful Effort (MaxUE) Scope'''
 +
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)
 +
:* Retain Report Converter actor and transactions
 +
::* Address TEXT and PDF report formats
 +
::* Retain all other report formats as Volume 1 Informative Appendix with no normative requirements
 +
:* Retain Report Purge Named Option
  
−
:* Because the IHE template has been completed for Volume 1 material and part of Volume 2, the risks are very well identified.
+
==6. Support & Resources==
−
:* The FUNC Profile RAD-Y1 must be completed prior to this supplement.
 
  
−
==Open Issues==
+
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.
  
−
:* Name of profile - consider change recommended above.
+
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.
−
:* 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.
 
  
 +
==7. Risks==
  
−
:* 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.
+
:* Scope creep to closely related clinical issues such as Emergency Department transfer
−
:* For the local PACS to notify a VNA or enterprise repository 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.
+
:* 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 "relevancy"
 +
::* consider it as vendor/product differentiation; IHE would define:
 +
:::* mechanisms
 +
:::* minimum set of metadata to be supported
 +
:* Attempting to rigorously define code table mapping could get messy
 +
:* Legal differences across jurisdictions
 +
:* MHD is in the process of being updated making dependencies on it subject to change
 +
:* Competing FHIR resources: MHD and DiagnosticReport
 +
::* May get feedback in PC leading to late change
  
−
:* 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==
+
==8. Open Issues==
  
−
Effort Evaluation (as a % of Tech Cmte Bandwidth):
+
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.
−
:* xx%
 
  
−
Responses to Issues:
+
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.
−
:''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==
+
==9. Tech Cmte Evaluation==
  
−
saving for posterity:
+
Technical Evaluation:
  
−
instructions for https://www.websequencediagrams.com/
+
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 +
* MaxUE: 27 SP / 40%
 +
* MinUE: 16 SP / 25%
  
−
title Automated Discovery and Retrieval of Relevant Priors
+
Candidate Editor:
−
Local DSS/OF->Local IM/IA: 1. Procedure Scheduled [RAD-4]
+
:*  Jonathan Whitby/Vital, with Teri Sippel Schmidt consulting for historical purposes
−
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)
 

Latest revision as of 13:02, 18 September 2018

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; Teri Sippel Schmidt
  • 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

Use Case 1: Reviewing current imaging study along with external priors

This scenario is widely supported when restricted to locally-acquired imaging studies. The goal of this supplement is to ensure that it is consistently supported between institutions and to work in conjunction with the existing install base of PACS systems without necessitating changes or upgrades.

The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.


User Scenario

  • A physician orders a radiology study for a patient
  • The radiologist wants to review the new study along with any relevant priors (MaxUE: and their associated reports)
  • Acquired locally
  • Acquired at affiliated institutions
  • The radiologist wants all prior studies (MaxUE: and reports) to work correctly with all their normal reading tools
  • Consistent patient identifiers
  • Consistent procedure codes
  • Consistent body parts
  • Etc.
  • The import system finds, localizes and imports all relevant prior imaging studies (MaxUE: and reports)
  • The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools


Supporting Data Flow

  • The import system receives the radiology order and extracts key metadata
  • Patient identifiers
  • Procedure codes
  • Modality
  • The import system queries the EMPI to determine appropriate patient identifiers for each affiliated site
  • The import system searches each affiliated site for prior imaging studies for the patient, retrieving key metadata for each study
  • Modality
  • Procedure codes
  • Study dates
  • MaxUE: The import system searches each affiliated site for diagnostic imaging reports for the patient, retrieving key metadata for each report
  • Report domain (if repository not radiology-specific)
  • Report codes
  • Report dates
  • The import system filters prior imaging studies based on order metadata, query results and configured relevancy rules
  • MaxUE: The import system filters prior diagnostic imaging reports based on order metadata, query results and configured relevancy rules
  • The Importer retrieves prior imaging studies that match the filter
  • MaxUE: The Importer retrieves prior diagnostic imaging reports that match the filter
  • The import system executes import logic to localize import imaging studies (MaxUE: and diagnostic imaging reports)
  • Replacing existing patient identifiers and demographics with local values
  • Etc.
  • The import system stores the imported imaging studies to the local PACS
  • MaxUE: The import system stores the imported diagnostic imaging reports to the local report repository
  • After radiological interpretation of the current study, external data is purged according to local policies
  • Triggers on current study report being finalized


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.


Workflow steps to be addressed

  • patient identification and PID reconciliation
  • receipt of new orders
  • metadata that can be applied to the relevancy logic
  • imaging study retrieval
  • DICOM attribute mapping / localization
  • storage of imported imaging studies
  • MaxUE: diagnostic imaging report retrieval
  • MaxUE: HL7 v2 ORU diagnostic imaging report attribute mapping
  • MaxUE: storage of imported diagnostic imaging reports
  • local purging of foreign imaging studies and foreign diagnostic imaging reports as defined Option

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


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
  • XDS-I Pption would include hybrid DICOM/XDS.b environment
  • Storage of imaging study limited to DIMSE DICOM to the local PACS
  • i.e. no direct XDS import to the local PACS
  • Other image types such as Raw JPEG, PDF, etc. out of scope
  • MaxUE: Report formats are limited to TEXT and PDF
  • MaxUE: Access of prior reports is limited to FHIR query for reports
  • MaxUE: Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content
  • MaxUE: 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

4. Standards and Systems

Real World Systems

  • EMPI (IHE: PIX/PDQ Manager)
  • RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)
  • VNA, Enterprise Imaging Repository or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry, XDS.b Document Repository, XDS.b 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)
  • MaxUE: Mobile Health Documents (MHD) -FHIR query documents
  • MaxUE: XDS.b retrieve - report retrieval
  • MaxUE: HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF

Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).

  • A Cross Profile Consideration should discuss how DICOMweb services could be integrated in the future for image access and retrieval.

5. Technical Approach

  • Assign most "intelligence" and mapping to new IDEP actors (Importer and Report Converter). This limits changes to ancillary systems.
  • Require certain specific data elements be populated, but avoid defining specific terminology mappings.
  • No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.
  • Communicate metadata to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (although IDEP would specify client side filtering.)
  • Do not over-specify display requirements; e.g., "Shall indicate on the display that it is an external study."
  • Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not make it a requirement.


Existing actors

  • "Local" DSS/OF
  • "Local" Image Manager
  • "Remote" Image Manager
  • MaxUE: "Local" Report Manager
  • MaxUE: "Remote" Report Manager
  • PIX/PDQ Manager
  • XDS.b Registry
  • XDS.b Repository
  • XDS.b-I Imaging Document Source


New actors

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


Existing transactions

  • HL7 v2, DICOM DIMSE, XDS.b and FHIR transactions (i.e. focus on improving the functionality of the existing installed base)
  • See IDEP transaction diagram


New transactions (standards used)

  • "Query for Patient Studies": new DICOM query
  • New mapping tables
  • Order (OMI) message data for relevancy
  • Coercion of MHD data for External Prior Reports
  • 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
  • SWF.b not being integrated into main standard makes it hard to put all of the pieces together.


New integration profiles needed

  • IDEP


Breakdown of tasks

Significant work has already been completed:

Transactions

  • Query for Patient Studies - get study metadata from local/remote PACS using pre-mapped Patient ID
  • returned information needs to be adequate for relevancy filtering
  • draft transaction exists based on C-FIND; cloned Query Images?
  • SP 1 effort
  • Review appropriateness of existing transactions
  • SP 1 effort (mostly work for editor)

Profile

  • Profile body - draft exists (68 pages); much is committee reviewed; not public commented
  • SP 2 effort
  • Use Case: IDEP with DIMSE Q/R mechanisms (baseline)
  • 14 existing transactions, 1 new transaction
  • confirm no gaps that would require change to any of the 14 existing
  • draft exists; much is committee reviewed; not public commented
  • SP 1 effort
  • SP 1 complexity
  • Use Case: IDEP with XDS-I Q/R mechanisms (option)
  • ~15 existing transactions, no new transaction?
  • draft exists; much is committee reviewed; not public commented
  • SP 1 effort
  • SP 1 complexity
  • Use Case: IDEP with Reports (option) (MaxUE)
  • adds ~6 transactions for finding/transporting Text/PDF reports using DIMSE, HL7v2 & MHD mechanisms
  • SP 1 effort
  • SP 1 complexity
  • Add new report transcoding specification for different wrappers and metadata mapping
  • SP 1 effort
  • SP 1 complexity
  • Remove all references to reports & Report Converter (40% of document) - If MinUE
  • SP 0 effort (work on editor)
  • Confirm different deployment models
  • draft exists; much is committee reviewed; not public commented
  • SP 1 effort
  • SP 1 complexity
  • Confirm IRWF image import mapping requirements meet all the needs of IDEP
  • SP 1 complexity
  • Confirm key relevancy metadata and availability via query mechanisms
  • DICOM
  • XDS
  • SP 1 complexity
  • Confirm key hanging protocol metadata and proper import mapping
  • SP 1 complexity
  • Mapping Table - DICOM Header of Prior to Local HL7v2 OMI
  • draft exists
  • SP 1 effort
  • Mapping Table - MHD DocumentManifest Resource to HL7v2 ORU (MaxUE)
  • draft exists
  • SP 1 effort
  • SP 1 complexity
  • Mapping Table - Object for Import MHD DocumentReference and HL7v2 OMI to local report Resultant Document Manifest (MaxUE)
  • draft exists
  • SP 1 effort
  • SP 1 complexity

Topics/Debates

  • MaxUE: Debate scope details (then fix profile details to match)
  • SP 1 uncertainty
  • SP 1 effort
  • Defensive mantra: Reporting is another profile
  • Consider detection of duplicates/versions of the same data to avoid replication cascade; interaction with IOCM
  • some text exists in Concepts X.4.1.8 + Purge Options
  • SP 1 uncertainty
  • SP 1 complexity
  • Which report transports/wrappers for text/PDF are in scope?
  • DIMSE C-MOVE, C-STORE, HL7v2 ORU, OMI, FHIR, ...
  • ASCII/binary blob, CDA1, CDA2, DICOM PDF, DICOM SR, DICOM SC, DICOM SD, ...
  • Note: payload is ONLY text or PDF; other report payload types might be mentioned in Informative annex
  • SP 1 uncertainty

Proposed Minimum Useful Effort (MinUE) Scope

  • Complete the current IDEP supplement
  • Do not include reports in any format -- not even TEXT or PDF
  • Do not include 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 but remove Report Purge as Named Option
  • (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).

Proposed Maximum Useful Effort (MaxUE) Scope

  • Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)
  • Retain Report Converter actor and transactions
  • Address TEXT and PDF report formats
  • Retain all other report formats as Volume 1 Informative Appendix with no normative requirements
  • Retain Report Purge Named Option

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 "relevancy"
  • consider it as vendor/product differentiation; IHE would define:
  • mechanisms
  • minimum set of metadata to be supported
  • Attempting to rigorously define code table mapping could get messy
  • Legal differences across jurisdictions
  • MHD is in the process of being updated making dependencies on it subject to change
  • Competing FHIR resources: MHD and DiagnosticReport
  • May get feedback in PC leading to late change


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

  • MaxUE: 27 SP / 40%
  • MinUE: 16 SP / 25%

Candidate Editor:

  • Jonathan Whitby/Vital, with Teri Sippel Schmidt consulting for historical purposes
Retrieved from "http://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&oldid=111500"