Integrating the Healthcare Enterprise

1. Integrating the Healthcare Enterprise Emmanuel Cordonnier, ETIAM (slides from Rita Noumeir) IHE-Europe IHE Technical and Planning Committees Cross-enterprise Document Sharing for Imaging (XDS-I)

2. Abstract / Scope • Sharing of Imaging Information across health enterprises • Imaging Information includes • extensive sets of DICOM instances including images, evidence documents and presentation states • diagnostic reports provided in a "for display" form • selection of diagnostically significant images associated with the report content

3. Sharing Radiology Reports and Imagesin a Regional Health Information Network Regional Health Information Network Radiology Enterprise B PACS B Radiology-to-radiology Radiology-to-Physicians PACS A Physician Office Radiology Enterprise A

4. Sharing Radiology Reports and Imagesin a Regional Health Information Network Regional Health Information Network Radiology Enterprise B PACS B Patient Id= 3547F45 • Report 5/21/1998 : CT Head B • Study 5/21/1998 : CT Head B • Report 2/18/2005 : Chest Xray A • Study 2/18/2005 : Chest Xray A Cross-Enterprise Registry PACS A Physician Office Radiology Enterprise A

5. Register Imaging Information for sharing Priorimaging Reports & Studies Register Imaging Information for sharing Query for Documents Physicians and Systems within a Regional Health Network - Routine Imaging Referral Regional Health Information Network Radiology Enterprise B Cross-Enterprise Registry Patient Id= 3547F45 • Report 5/21/1998 : CT Head B • Study 5/21/1998 : CT Head B Physician Office Radiology Enterprise A

6. Register Imaging Information for sharing Register Imaging Information for sharing Notification of Doc Availability Physicians and Systems within a Regional Health Network - Routine Imaging Referral Regional Health Information Network Radiology Enterprise B Cross-Enterprise Registry Physician Office Radiology Enterprise A

7. Prior Imaging Report & Study Query for documents Notification of Doc Availability Imaging Report & Study Physicians and Systems within a Regional Health Network for a Routine Imaging Referral Regional Health Information Network Radiology Enterprise B Patient Id= 3547F45 • Report 5/21/1998 : CT Head B • Study 5/21/1998 : CT Head B • Report 2/18/2005 : Chest Xray A • Study 2/18/2005 : Chest Xray A Cross-Enterprise Registry Physician Office Radiology Enterprise A

8. Value Proposition • Imaging component of the Electronic Health Record: Shared imaging Record, in a community, region, etc. • Effective means to contribute and access imaging documents across health enterprises. • Without XDS-I, access to the radiology report across health enterprises is difficult • Scalable sharing of imaging documents between radiology departments, private physicians, clinics, long term care, acute care with different clinical IT systems. • Easy access: Care providers are offered means to query and retrieve imaging documents (images and reports) of interest • with the same mechanisms used to query other documents

9. Value Proposition • Distributed: Each Care delivery organization “publishes” imaging information for others. Actual images remain in the source/Image Manager. • Cross-Enterprise: A Registry provides an index for published information to authorized care delivery organizations belonging to the same clinical affinity domain. • Document Centric: Published clinical data is organized into “clinical documents”. using agreed standard document types (DICOM KOS, PDF and/or text report) • Document Content Neutral: Document content is processed only by source and consumer IT systems. • Standardized Registry Attributes: Queries based on meaningful attributes ensure deterministic document searches.

10. XDS-I Dependencies • XDS-I depends on IT Infrastructure Cross-Enterprise Document Sharing (XDS) • Same Actors as in XDS • Document Source • Document Consumer • Document Registry • Document Repository • Added extension to support imaging data (images and reports)

11. XDS-I Actors and Transactions Retrieve Images Image Manager Image Archive Retrieve Presentation States Retrieve Key Image Note Retrieve Evidence Documents WADO Retrieve Patient Identity Source Patient Identity Feed Query Document Documents Document Consumer Registry Register Document Set Retrieve Provide & Register Document Document Set Document Document Repository Source

12. XDS-I New Transaction requirements • XDS Actors: • Document Consumer • at least one Retrieve (DICOM C-Move or WADO) • Document Source • Provide and Register Document Set • Radiology Actors • Image Manager / Image Archive • WADO Retrieve

13. XDS-I Profile Dependencies

14. XDS-I Profile Options (1) • Document Source must support at least one of the following options: • Extensive Set of DICOM Instances • PDF Report • Text Report • Multipart Text/PDF Report

15. XDS-I Profile Options (2)

16. XDS-I Profile Options (3)

17. Sharing of Extensive DICOM Instance Set

18. Register Manifest Query Registry DICOM Manifest DICOM Manifest Retrieve Manifest Reference to image 1 Reference to image 1 Reference to image 2 Reference to image 2 Reference to image 3 Reference to image 3 Retrieve Images Manifest Manifest Manifest Manifest Manifest Clinical IT System Clinical Encounter Document Registry Document Repository

19. Sharing of Extensive DICOM Instance Set • The shared Document is a manifest • a Key Object Selection DICOM Instance • Image Manager/Image Archive is required • to ensure that the referenced images from within a published manifest are available to be retrieved • Document Source is responsible • for replacing a previously submitted manifest Document when a change occurs to the manifest content (eg. Change of the DICOM SOP instances referenced within the manifest)

20. Sharing of Imaging Report

21. Radiology Report Header: Report Type: OB / Gyn BPD ….. ... Findings: ….. Gestational Impressions: Age ... Text Report PDF Report Text +PDF Report Radiology system Report Source

22. Register Report Query Registry Radiology Report Header: Report Type: OB / Gyn BPD Retrieve Report ….. ... Findings: ….. Gestational Impressions: Age Report Report Report ... Clinical IT System Clinical Encounter Document Registry Document Repository Radiology system Report Source

23. Sharing of Report • The shared Report Document format is • PDF, Text, or multipart PDF + Text • A report can • embed selected images in its PDF format • include fully resolved hyperlinks (interactively clickable) that point to the selected images • Document Source is responsible • for formatting the hyperlink to reference relevant images as a DICOM WADO URI or as IHE RID Request for Document • Document Source is required • to ensure that image references are valid links

24. XDS-I Actors / Grouping • Sharing of an Extensive DICOM set • Document Source shall be grouped with an Image Manager/Image Archive • Sharing of a report that references selected images • Document Source shall be grouped with an Image Manager/Image Archive • Sharing of a report that references selected images from previously published extensive DICOM set • Document Source can be grouped with a Document Consumer

25. SubmissionSet DocumentEntry DocumentEntry Study Manifest Report Linking Report to Complete Set of Images Document Registry Document Repository

26. SubmissionSet 1 SubmissionSet 2 DocumentEntry Report Study Manifest Linking Report to Complete Set of Images Document Registry DocumentEntry Document Repository

27. SubmissionSet 3 SubmissionSet 1 SubmissionSet 2 SubmissionSet 4 DocumentEntry DocumentEntry DocumentEntry Prior Study Manifest Prior Report Report Study Manifest Linking Report to Prior Images and Prior Report Document Registry DocumentEntry Document Repository

28. BPD ... ….. Linking Report to Selected Images Radiology Report Header: Report Type: OB / Gyn ….. Findings: Gestational WADO URI Link to image Age ... Relevant Image Radiology system Report Source

29. Examples of WADO implementation Web Client System Web Access to Dicom Persistent Objects Web Access to Dicom Persistent Objects DirectInterface Web Gateway Gateway DICOM Q/R DICOM Interface Web Interface DICOM Q/R DICOM Interface DICOM Objects Database DICOM Objects Database Flexibility for the client to be implemented either as new system or on existing system

30. WADO Interaction Diagram Web Client System Web Enabled DICOM Server Object(s) request (HTTP GET) Object(s) send (HTTP response header and body)

31. Syntax of the WADO HTTP GET method • Syntax defined by the RFC2396 (URI) • http://<authority><path>?<query> • e.g: • http://www.hosp.fr/dicom/wado.asp?studyUID=1… • The « Web Access to DICOM Persistent Object » standard defines only the <query> Path of the Web Enabled DICOM Server WADO Parameter(s)

32. WADO Selection Parameters • studyUID&seriesUID&objectUID[&frameNumber] • studyUID => UID of the study containing the object(s) • seriesUID=> UID of the series containing the object(s) • objectUID => UID of the single object (Service Object Pair SOP) • frameNumber => number of the selected frame (multiframe image objects) – if NOT retrieved as application/dicom

33. WADO MIME type of return object • The MIME type of the object contained in the contentType parameter, compatible the<accept>parameter of the GET method • application/dicomfor all objects, or a different MIME type for converting the DICOM object, depending of the nature of the object: • image/jpeg for still image object • text/html or text/plain for text object, or • other optional formats

34. WADO MIME type of a Structured Report • application/dicom • application/x-hl7-cda-level-one+xmlfor converting the SR into CDA (see HL7 Imaging SIG /DICOM WG20) • text/plain for « minimal » version of document • text/rtf for « Word » version of document • application/pdf for « stable » version of document, potentially containing images • text/html a priori without the images (to contained into only one file). The reference to the images can used the WADO syntax.

35. WADO Parameters when the object is return as application/dicom [transferSyntax][anonymize][charset] • transferSyntax => DICOM UID of the transferSyntax to be applied to the image (lossy/lossless compression). Implicit and Big Endian TS shall not be used. • anonymize => “=yes” for blanking all the personal healthcare information (patient name, study date…) as described in Sup. 55. Potentially the server can refuse to deliver an object if there are some risk the personal information is burned into the image (secondary capture…) • charset => for converting the text fields in a different character set (available also if object return as text/xxx)

36. Parameters when the object is return as image/xxx (1) [imageQuality] [presentationUID & presentationSeriesUID |[windowCenter & windowWidth]] • imageQuality => controls the level of compression (from 1 to 100) • presentation => UIDs of the Presentation State SOP and of its series to be applied on the image (P-values, and display size set to the original size if undefined) • windowCenter / windowWidth => controls the luminosity and the contrast of the B&W image

37. Parameters when the object is return as image/xxx (2) [region][rows][columns][annotation] • region=> part of the image to be displayed, in relative coordinates (top left hand corner and bottom right hand extent) • rows => maximum number of pixels (vertical) • columns => maximum number of pixels (horizontal) • annotation => text to be superimposed of the image (“patient” and / or “technique” for demographic information and technical information, respectively)

38. Security aspects • It is clear that the information contained within DICOM objects may be considered as protected healthcare information (PHI). The protocol used, that is HTTP, can be replaced by HTTPs, which is its secure extension, for that purpose. • Two optional parameters, anonymize and annotation, control respectively the absence of patient identification in a retrieved DICOM object and the presence of patient identification burned in to the pixel data of images.

39. Select the object studyUID&… presentationUID&…or windowCenter… Apply the presentation Select a region region Build the pixel area CT WC-800 WW200 rows…&columns… Burn the annotations annotation Content-Type: image/jpeg; name="Image.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Image.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wgARCABkAGQDASIA AhEBAxEB/8QAGwABAQEBAQEBAQAAAAAAAAAAAAUEAwECBgf/xAAYAQEAAwEAAAAAAAAAAAAAAAAA AQIDBP/aAAwDAQACEAMQAAAB/qgAAAAAAABNpnSTVc6Sbpm2lO6RG0a7gAcZWztzcORR8tef9+6a 09xdPZncOjtAfH3Opls+oOrHlq8+Eubfoc3LpfXRn4ZaZUtOTXr0BfVPoKZxud1lzRdFJN5PSklI 8sIjJrNegLXAAAAAAAAAAAAAA//EACEQAAMAAQQCAwEAAAAAAAAAAAECAwQREhMUACAQNFAk/9oA CAEBAAEFAvyksxxl7DILsYJ2GVSyIrXoJVbf6zoKeT+lPscTS48WUWM8lSMQHWSPTs+r42rcI4EG Generate the MIME type contentType DOE 2003-9-22 Providing a image as image/xxx

40. Client flexibility • The WADO functionality supports access to • Native (un-rendered) DICOM data • Associated rendering data e.g. Gray Scale Presentation State • “Rendered” information e.g. JPEG image • So client design can be • Simple, relying on basic features of the web browser • Complex, providing advanced functionalities by taking ‘raw’ DICOM data and deciding the processing and rendering to be applied

41. XDS-I Metadata • Radiology specific • Acquisition Modality (e.g. CT, MR) • Anatomic Region (e.g. Arm, Elbow, Hand) • Requested procedure (e.g. MRI Knee with contrast) • Query example • find all “CT of the Head” of patient John Doe for the last 2 years

42. IHE Web site: http://www.ihe.net http://www.himss.org/IHE http://www.rsna.org/IHE http://www.acc.org/quality/ihe.htm Technical Frameworks Technical Framework Supplements – Trial Implementation Non-Technical Brochures : Calls for Participation IHE Fact Sheet and FAQ IHE Integration Profiles: Guidelines for Buyers IHE Connect-a-thon Results Vendor Products Integration Statements More information…. Questions?

43. Extensive DICOM Instance Set

44. Imaging Report