1. IHE Rad evaluation: IHE Rad profiles vs. ITI XDS Christoph Dickmann 2004-12-16

2. 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) –Leverage DICOM capabilities for DICOM environment –Common, simple mechanism for non-DICOM env.

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

4. IHE Canada use case: hip fracture PACS-1 (tertiary hospital, shared) Worklist mgmt. (quart. hospital, shared) Image display (loc./tert. hospital) Doc. registry (shared) Report transcription (hospital? external?) Transcri- ptionist Rep. dictation (tertiary hospital) Report storage (tertiary hospital, local) ER physicianLCT staffRadiologist (tert.)Orthop. surgeonRadiologist (quart.) R. display (tert. hospital) PACS-2 (quaternary hospital, local) Image display (quart. hospital) Orth. planning (quaternary hospital, local) Doc. repository (shared) Conclusions: acute care & „long-term“ workflow DICOM + ebXML

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

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

7. 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 Ext. Rep. Repos. Access Report Reader Img. Display (+ ARI MSO) IM/ IA PACS-2 Orth. planning Conclusions: add 1 existing actor DICOM „clients“ & config.

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

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

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

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

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

13. Possible combination: Rad & XDS actors IM/ IA Doc. registry Creator Images Stored Doc. con- sumer Query Registry Retrieve Doc. 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

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

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

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