1 / 17

Product Experiences

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.

raine
Download Presentation

Product Experiences

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 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)

  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. Collect, organize and distribute clinical imaging data in- and outside the hospital MR Scanner Radiology CT Scanner Orthopedics Data acquisition by modalities UltraSound Results viewing & distribution NuclearMedicine Operating Room Storage & Archive X-ray Web Distribution EmergencyDepartment Film Digitizer Internet/Intranet WardReferring Physician Patient The product in the clinical environment

  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. DICOM import module Re-order Default Display Protocol Misinterpretation: Use of Image number to determine display order PACS

  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. SCU SCP A-Associate Request Association 1 A-Associate Accept N-Action- Request Archive N-Action- Response A-Release Request A-Release Response A-Associate Request Modality A-Associate Accept SCP SCU N-Event-Report-Request Association 2 N-Event-Report-Response A-Release Request A-Release Response Storage Commitment: Asynchronous

  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.

More Related