DICOM INTERNATIONAL DICOM INTERNATIONAL CONFERENCE & SEMINAR April 8-10, 2008 Chengdu, China Product Experiences Cor Loef Philips Healthcare

Product Experiences 2 Contents 1.The challenge of implementing DICOM 2.The product in the clinical environment 3.Software design rules 4.Examples of typical misinterpretations 5.Verification and validation of products 6.Conclusion

Product Experiences 3 Part 1 - Introduction and Overview Part 2 - Conformance Part 3 - Information Object Definitions Part 4 - Service Class Definitions Part 5 - Data Structures & Semantics Part 6 - Data Element Listing and Typing Part 7 - Message Exchange Protocol Part 8 - Network Support for Message Exchange Part 10: Media Storage and File Format for Media Interchange Part 11: Media Storage Application Profiles Part 12: Media Formats and Physical Media for Media Interchange Part 14: Grayscale Standard Display Function Part 15: Security and System Management Profiles Part 16: Content Mapping Resource Part 17: Explanatory Information Part 18: Web Access to DICOM Persistent Objects (WADO) The challenge of implementing DICOM

Product Experiences 4 Patient Centric Workflow and Dataflow The product in the clinical environment

Product Experiences 5 "Interoperability" means the ability of ICT systems, and of the business processes they support, to exchange data and to enable the sharing of information and knowledge “Draft Recommendation of the Commission on Union-wide interoperability of Electronic Health Record Systems” The product in the clinical environment

Product Experiences 6 MR Scanner CT Scanner X-ray Radiology Web Distribution Orthopedics Emergency Department Operating Room Nuclear Medicine Film Digitizer UltraSound Results viewing & distribution Data acquisition by modalities Storage & Archive Internet/Intran et Ward Referring Physician Patient Collect, organize and distribute clinical imaging data in- and outside the hospital The product in the clinical environment

Product Experiences 7 The product in the clinical environment

Product Experiences 8 Software design rules 1.Be tolerant and robust on received input, and correct, flexible and comprehensive on produced output 2.Consider the receiving application’s needs when filling optional DICOM fields (Application Profiles) 3.Create a fall-back scenario when implementing new SOP Classes 4.Consider the consequences for the receiver when using standard extended SOP class (extra private attributes) 5.Be efficient in protocol resource utilization 6.Always remember: DICOM is enabler for interoperability, but no guarantee

Product Experiences 9 Software Design Rules: Be Flexible

Product Experiences 10 Software Design Rules: Fall-Back Scenario  Create multiple rendered images with Overlays when Presentation State is not supported by receiving system  Use multiple instances of the existing MR SOP Class when Enhanced multi-frame MR SOP Class is not supported by the receiving system

Product Experiences 11 Software Design Rules: Be Tolerant  Accept leading zeros in de components of an UID  Handle PN attribute values with more than 5 components (HL7 syntax)

Product Experiences 12 Examples of typical misinterpretations  Misunderstanding meaning of PDU size = 0 (unlimited)  Overlooking that a Modality Worklist SCP has to include all requested type 1 and type 2 attributes, and is prohibited to provide any additional not requested attributes  Overlooking requirement to include and/or use correct values for Specific Character Set attribute  Too limited implementation: Study description field not exported  Incorrect assumptions on use of Instance Number, Study ID, Series Number and SOP Instance UID for display order

Product Experiences 13 DICOM import module Re-order Default Display Protocol PACS Misinterpretation: Use of Instance Number to determine display order

Product Experiences 14 Examples of typical misinterpretations  Overlooking consequences of changing Series and Study Instance UID, this will break references from GSPS and SR  Incorrect assumptions about maximum attribute tag being the Pixel Data (7FE0,0010), some implementation ignore the remainder  Overlooking consequences of queries with key such as Patient Name having wildcards  Overlooking the reverse role in the Storage Commitment Association

Product Experiences 15 SCP SCU A-Associate Request A-Associate Accept N-Action- Request N-Action- Response N-Event-Report-Request N-Event-Report-Response A-Release Request A-Release Response Modality Archive A-Associate Request A-Associate Accept A-Release Request A-Release Response Association 2 Association 1 SCP SCU Storage Commitment: Asynchronous

Product Experiences 16  Audited Quality Assurance Procedure  Published Conformance Claims Published Conformance Claims  Tools Tools  In-house conformance testing of products In-house conformance testing of products  Cross-vendor interoperability testing  Bilateral vendor agreements and activities  IHE connectathon process and tools IHE connectathon tools  Feedback to DICOM Standards Committee when common issues arise in the field Verification and validation of products

Product Experiences 17 Conclusion A viable common sense approach exists that vendors should use for the creation of healthcare products that use the DICOM Standard for the communication of medical information. This will achieve interoperability for the connected products in the healthcare enterprise.

Product Experiences 18

Product Experiences 19

Product Experiences 20

Product Experiences 21

Product Experiences 22