Standards Compliant PACS XDS-I Source & XDS/XDS-I Consumer. Ronan Kirby 25 th March 2011

Transcription

1 Ronan Kirby 25 th March 2011

2 Standards Compliance on Image Sharing - Why? Support for Clinical Pathways A patients healthcare journey may involve different hospitals / trusts depending on where specific diagnostic tests and treatments are available. Support for Multiple disciplines Not all clinical images are generated in Radiology. Support Beyond Secondary Care What about Outreach Clinics / GP s? What about Specialist Tertiary Centres? Page 2

3 Standards Compliance on Image Sharing Why? Addition of new technologies Standards compliant technologies require minimal effort to integrate into pre-existing standard based architectures. Greater efficiencies and faster opinions / treatments Less repetition having the right image at the right time in the right place! Less risk Manual intervention leads to mistakes. E.g. CD import Moving image from site to site to site to site, updates? Page 3

4 Standards Compliance on Image Sharing Why? Standard compliance allows all of the above to be achieved Page 4

5 What are XDS and XDS-I? And how do they work. Both XDS and XDS-I are IHE standards or profiles used internationally to define methodologies of sharing document objects. XDS Cross-enterprise Document Sharing XDS-I Cross-enterprise Document Sharing for Imaging Page 5

6 XDS / XDS-I domain setup Common IHE Integration profile actors Imaging Document Source Document Source Imaging document Consumer Document Consumer Document repository Document registry Patient Identity Source Page 6

7 First things First Some Terminology WADO Web Access for DICOM persistent Objects ATNA Audit Trail and Node Authentication PIX Patient Identity Cross-referencing PDQ Patient Demographics Query XCA Cross Community Access KOS Key Object Selection CDA Clinical Document Architecture Page 7

8 First things First XDS Core Components Affinity Domain ATNA PIX / PDQ XDS Registry XDS Repository Page 8

9 First things First Edge Components Affinity Domain ATNA PIX / PDQ XDS Registry XDS Repository Document Source Document Consumer Page 9

10 First things First XDS Adapters (Optional used where legacy non XDS compliant systems are involved) Affinity Domain ATNA PIX / PDQ XDS Registry Unique in one Domain Document Source Adapter Document Source XDS Repository Document Consumer Adapter Document Consumer Multiple instances possible in one Domain Page 10

11 First things First Multiple Affinity Domains XCA Gateway XCA Gateway XCA Gateway XCA Gateway Page 11

12 XDS-I a short recap.workflow steps Object Registration 1. Image object is generated at document source 2. Image object is sent to source adapter (DICOM) PIX / PDQ 3. Source adapter extracts metadata from image object and creates KOS 6 4. KOS ONLY is sent to XDS-I repository (main difference between XDS and XDS-I) 5. XDS repository registers KOS object in registry 6. Registry interacts with PIX/PDQ and updates if necessary 3 Document Source Adapter 2 4 XDS Registry 5 XDS Repository Document Source 1 Page 12

13 XDS-I a short recap.workflow steps Object Viewing (using adapter if necessary) 1. Document consumer launches Document Consumer Adapter Application (DCAA) and passes local patient ID 2. DCAA queries PIX / PDQ for patients domain PIX / PDQ ID 3. DCAA uses domain ID to query XDS Registry for any registered objects and displays results 4. User selects required object and queries XDS repository for KOS metadata XDS Registry DCAA uses KOS metadata and WADO to request image (thumbnail of full size) from XDS Repository 4 Document Consumer Adapter document source s WADO server WADO server responds with image 7. DCAA WADO client is used to view image. Note: DCAA and WADO client may be embedded Document Source (WADO Server) 6 7 Document Consumer in PACS workstation software or external. Page 13

14 XDS / XDS-I domain setup What needs to be done? Mandatory Metadata e.g. Minimum Patient Demographics, Exam coding, Reference lists Document type codes e.g. Discharge letters, radiology reports Standard coding within domains for different document types, XCA can handle translation between different domains if necessary. Standardisation is crucial to efficient use Page 14

15 XDS / XDS-I domain setup What needs to be done? Security Policies must be standardised nationally. Who has permissions access to what data? Who is accessing (Password security / PKI authentication etc). Audit trails Who has accessed what data? Patients permission Who s decision is it to allow access to data Page 15

16 XDS and Image repository V. XDS I Duplication of storage Why have 2 different copies of the data when one will do? Data Maintenance / auditing Do you know that the copy on the Image repository is the latest version? How to monitor / check? Page 16

17 Existing solutions for sharing Most existing solutions are labour intensive and involve manual steps. Automatic solutions are almost always vendor (and discipline) specific. Page 17

18 Summary Consolidating the patients record in a standards based system allows one portal of access to the entire patients record across multiple trusts and multiple feeder systems. Imaging is a crucial part of the patients record so logically all imaging should be available to all personnel with a clinical responsibility. Access beyond radiology into primary and tertiary care. RI-RP-RT Vendor agnostic. Vendor endorsed Issues: Standardisation Standardisation - Standardisation Security access to patient info, authentication, reason to access / audit etc. Page 18