1 / 16

IHE Rad evaluation: IHE Rad profiles vs. ITI XDS

IHE Rad evaluation: IHE Rad profiles vs. ITI XDS. Christoph Dickmann 2004-12-16. Cross enterprise: Problems & goals. Problems Share imaging data for widespread , general purpose use Non-DICOM environment DICOM environment (why not using DICOM?)

hans
Download Presentation

IHE Rad evaluation: IHE Rad profiles vs. ITI XDS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Image display (loc./tert. hospital) Rep. dictation(tertiary hospital) R. display(tert. hospital) Image display (quart. hospital) Orth. planning (quaternary hospital,local) Worklist mgmt. (quart. hospital,shared) Transcri- ptionist ER physician LCT staff Orthop. surgeon Radiologist (quart.) Radiologist (tert.) PACS-1 (tertiary hospital,shared) Doc. registry (shared) PACS-2 (quaternary hospital,local) Doc. repository (shared) Report storage(tertiary hospital,local) Report transcription(hospital? external?) IHE Canada use case: hip fracture • Conclusions: • acute care & „long-term“ • workflow • DICOM + ebXML

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

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

  7. Img. Display Report Reader (+ ARI MSO) Rep. dictation Report ReaderImg. Display (+ ARI MSO) Orth. planning DSS / OF ER physician LCT staff Radiologist (tert.) Orthop. surgeon Radiologist (quart.) IM/ IA PACS-2 IM/ IAPACS-1 Ext. Rep. Repos.Access Ext. Report Repository Use Case – „classical“ Rad approach • Conclusions: • add 1 existing actor • DICOM „clients“ & config.

  8. Gaps, open issues 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? 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“) ?

  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. Img. Display Report Reader ARI MSO ~ Doc. consumer Q/R Extend ARI MSOfor Ext.R.R.Access? 1:1 ... ... ~ Doc. Repository & Registry Report Repos. 1 ReportRepos. k IM/ IA 1 IM/ IA n Ext. Report Repos. Access 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 orseveral ones („query proxy“) • Extend ARI MSO for Q/R to Ext.R.R.Access

  11. Rep. Reader ARI MSO Report Creator Report Manager keep 1:1 ... ... Ext. Report Repos. Access Rep. Repos.(local) Rep. Repos.(central) IM/ IA 1(local) IM/ IA n(central) Copy to central? Copy to central? Rad actors producing shared data Acquisition Modality EvidenceCreator Img. Display ARI MSO • 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

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

  13. Img. Display Doc. con-sumer Doc. con-sumer RetrieveDoc. RetrieveDoc. Query Images Query Registry Query Registry Retrieve Images Doc. registry Doc. registry Register Doc. Set IM/ IA Creator ImagesStored IM/ IA IM/ IA Doc. source Doc. source Doc. re-pository Doc. re-pository Prov.&Reg. Doc. Set Possible combination: Rad & XDS actors Add Rad capabilities to XDS Add XDS capabilities to Rad • Similar for Rad Reports: • Report Issuing • Query Reports • Retrieve Reports 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

More Related