Cor Loef Philips Healthcare Product Experiences Cor Loef Philips Healthcare

Contents The challenge of implementing DICOM The product in the clinical environment Software design rules Examples of typical misinterpretations Verification and validation of products Conclusion

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

The product in the clinical environment Patient Centric Workflow and Dataflow

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 knowledge1. 1. “Draft Recommendation of the Commission on Union-wide interoperability of Electronic Health Record Systems”

The product in the clinical environment 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/Intranet Ward Referring Physician Patient Collect, organize and distribute clinical imaging data in- and outside the hospital

The product in the clinical environment

Software design rules 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 private extended SOP class Be efficient in protocol resource utilization Always remember: DICOM is enabler for interoperability, but no guarantee

Software Design Rules: Be Flexible

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

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)

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 Image number, Study ID, Series ID and Instance ID and its use for display order

Use of Image number to determine display order Misinterpretation: Use of Image number to determine display order PACS DICOM import module Default Display Protocol Re-order

Examples of typical misinterpretations Overlooking consequences of changing Series and Study 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

N-Event-Report-Request N-Event-Report-Response Storage Commitment: Asynchronous 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 Association 2 Association 1

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

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.