IHE Rad evaluation: IHE Rad profiles vs. ITI XDS Christoph Dickmann

Cross enterprise: Problems & goals Problems –Share imaging data for widespread, general purpose use Non-DICOM environment DICOM environment (why not using DICOM?) –Publish selected data („view“) for a reading receiver –Unclear: acute care (EHR-CR) vs. longitudinal (EHR-LR) Goals –Central access/ query point (retrieve may be separate) –„Point-to-point“ transfer (exact destination not known) –Leverage DICOM capabilities for DICOM environment –Common, simple mechanism for non-DICOM env.

Fundamental questions Competition between similar profiles –Same IHE domain: ARI vs. XDS –Other IHE domain: ARI vs. RID vs. XDS Clarify when to use what approach –„high tech“ & „workflow“ – DICOM (ARI) –„low tech“ & distribution, e.g. web technology (RID, XDS) –Specific/ acute care (ARI) vs. general/ „archive“ (XDS)? –Direct (peer) vs. non-directed communication Restrictions of the scope: important to do first! (avoid: one profile fits all)

IHE Canada use case: hip fracture PACS-1 (tertiary hospital, shared) Worklist mgmt. (tert. hospital, shared) Img. portal (loc./tert. hospital) Report transcription (hospital? external?) Transcrip- tionist ER physicianLTC staffRadiologist (tert.)Orthop. surgeon (quart.) Radiologist (quart.) Display (quart. hospital) Doc. registry (shared) Doc. repository (shared) Conclusions: acute care & „long-term“ workflow DICOM + ebXML PACS-2 (quarternary hospital, local) Image display (quart. hospital) Orth. planning (quarternary hospital, local) Doc. consumer Rep. dictation (tertiary hospital) Report storage (tertiary hospital, local) Note: no acquisition, no complete workflow shown

Use Case – XDS approach Image display PACS-1 Doc. source Worklist mgmt. ER physicianLTC staffRadiologist (tert.)Orthop. surgeonRadiologist (quart.) Rep. dictation Report storage Doc. source Doc. repository Doc. registry Doc. con- sumer Conclusions: add new functions / actors duplicate storage? select/ convert/ link to original? DICOM + ebXML Notation: - orange: XDS, http - blue: Rad, DICOM Orth. planning Doc. source PACS-2 Image display R. display

Use case - combined Rad & XDS capability ER physicianLTC staffRadiologist (tert.)Orthop. surgeonRadiologist (quart.) Orth. planning Conclusions: grouped actors increased configuration effort on „Display actors“ DICOM + ebXML (link to original!) DICOM obj. needs IHE Rad actor R. display Notation: - orange: XDS, http - blue: Rad, DICOM Image display PACS-1 Doc. repository & source DSS/ OF Doc. registry Doc. con- sumer PACS-2 Image display Doc. con- sumer Doc. repository & source Rep. dictation Report storage Doc. repository & source

Use Case – „classical“ Rad approach ER physicianLCT staffRadiologist (tert.)Orthop. surgeonRadiologist (quart.) Img. Display Report Reader (+ ARI MSO) IM/ IA PACS-1 DSS / OF Rep. dictation Ext. Report Repository Orth. planning Conclusions: add 1 existing actor IM/IA transfer needed? DICOM „clients“ & config. Transfer/ caching ? Ext. Rep. Repos. Access Report Reader Img. Display (+ ARI MSO) IM/ IA PACS-2

Gaps, open issues XDS approach Add XDS capabilities to Rad actors? Convert DICOM objects to XDS Documents Static longitudinal XDS document vs. dynamic acute care objects ebXML in the DICOM world? Registry as central bottleneck How to avoid redundant data and system parts (storage)? More systems, more to administer! Add Rad capabilites to XDS actors? Workflow/ process aspects („telemedicine“) ? Classical Rad approach Simplify report handling (RM) ? Use ARI MSO also for –access to Ext.R.Repository? –storage to multiple IM/ IA? „low-tech“ distribution: –„DICOM viewer“ / slim Image Display – Report Reader –ITI RID Configuration management?

Opportunities XDS Single mechanism to access a variety of „objects“ – aligned with ARI & RID Add DICOM-“compatible“ transaction options for provide/ register/ query (no ebXML) Classical Rad Faster/ easier implementation in DICOM environments Identify improvement opportunities for the Rad TF (e.g. Report Management, ARI MSO) Workflow (DWF) aspects

Rad actors consuming shared data often, grouping Img.Display & Rep.Reader is reality Q/R from >1 IM/IA often is a need other RAD profiles fit: SWF, PWF, RWF, PIR, CPI ARI MSO can serve one Img.Displ./Rep.Reader or several ones („query proxy“) Extend ARI MSO for Q/R to Ext.R.R.Access Img. Display Report Reader ARI MSO IM/ IA 1IM/ IA n Report Repos. 1 Report Repos. k... Q/R Ext. Report Repos. Access ~ Doc. Repository & Registry ~ Doc. consumer 1:1 Extend ARI MSO for Ext.R.R.Access?

Rad actors producing shared data Img. Display ARI MSO Evidence Creator Acquisition Modality golden rule: do not duplicate data (especially, if worked on)  storing to 1 IM/IA or Rep.Repos. is o.k. if copies of data needed (local & central), IM/IA should copy  extend IM/IA with (configurable) transactions „Img. Stored“, „Storage Commit“ („central archive option“) same for Report Repository IM/ IA 1 (local) keep 1:1 Rep. Repos. (central)... Copy to central? IM/ IA n (central)... Copy to central? Rep. Repos. (local) Ext. Report Repos. Access Report Creator Rep. Reader ARI MSO Report Manager

Possible combination: Rad & XDS actors XDS Registry Add DICOM Register option –Rad Img.Store of repres. object –Rad Rep.Issue –XDS Registry derives metadata from repres. DICOM object –Add these transactions to IM/IA & R.Repository as well Add DICOM Query option –Rad Img.Display & R.Reader do a normal DICOM query –Rad ID/RR decides how to use Study/ Series/ Instance level data Rad IM/IA & Rep. Reposit. Act as XDS Source –Is already described... Act as XDS Source & Reposit. –Internally generate meta-data –XDS Register Doc. Set already described

Possible combination: Rad & XDS actors Retrieve Images Img. Display Query Images Add Rad capabilities to XDS Similar for Rad Reports: Report Issuing Query Reports Retrieve Reports Add XDS capabilities to Rad IM/ IA Doc. source Doc. re- pository Doc. con- sumer Query Registry Retrieve Doc. Register Doc. Set IM/ IA Doc. source Doc. registry Doc. re- pository Prov.&Reg. Doc. Set Similar for reports IM/ IA Doc. registry Creator Images Stored Doc. con- sumer Query Registry Retrieve Images XDS actors with DICOM capability. Rad actors connect to XDS actors via DICOM.

Possible combination: RID & XDS actors Connect RID Display to XDS environment (RID planned to handle dynamic queries!) Let XDS Registry act like an Information Source for the transaction „Retrieve Specific Information for Display“ Let the XDS Repository act like an Information Source for the transaction „Retrieve Document for Display“

Conclusions, proposals „Client“ read-only combinations: –DICOM only: Img.Displ., Rep.Reader, ARI MSO –DICOM + HIS: (ID, RR, ARI MSO) + RID (dynamic!) „Server“ combinations: –Avoid copy: Rad storage & ARI MSO –Intend copy: Rad storage local & central (extend Rad storage) –Transform: Rad storage = XDS Source & Repository Restrict actor combinations – usage recommendations –Longitud. & cross-tech: „transform“ into XDS repository –Acute care & same-tech: reference from XDS registry

Conclusions, proposals Add proposed Rad extensions to XDS Registry –Support Rad actors to easily participate in XDS environment –XDS Registry to behave like a virtual IM/IA or Report Repository for queries –IM/IA & Rep.Repos. not required to act as an XDS source or repository –Add DICOM power to XDS environments Rad actors can be extended with XDS actors anyway Step-wise approach –Rad capabilities in XDS –Imaging to XDS –Reports to XDS