DICOM INTERNATIONAL CONFERENCE SEMINAR April 8 10 2008

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

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

Product Experiences The challenge of implementing DICOM 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) 3

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

Product Experiences The product in the clinical environment "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 1. “Draft Recommendation of the Commission on Union-wide interoperability of Electronic Health Record Systems” 5

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

Product Experiences The product in the clinical environment 7

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

Product Experiences Software Design Rules: Be Flexible 9

Product Experiences 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 10

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

Product Experiences 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 12

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

Product Experiences 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 (7 FE 0, 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 14

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

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

Product Experiences 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. 17

Product Experiences 18

Product Experiences 19

Product Experiences 20

Product Experiences 21

Product Experiences 22