1. Cor Loef Philips Healthcare
Product Experiences
Cor Loef
Philips Healthcare

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

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

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

5. 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”

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

7. The product in the clinical environment

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

9. Software Design Rules: Be Flexible

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

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)

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

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

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

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

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

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.