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


Abstract / Scope :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


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


Sharing Radiology Reports and Imagesin a Regional Health Information Network :4 Sharing Radiology Reports and Imagesin a Regional Health Information Network Radiology Enterprise A Radiology Enterprise B Physician Office Regional Health Information Network Cross-Enterprise Registry 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 PACS B PACS A


Physicians and Systems within a Regional Health Network - Routine Imaging Referral :5 Physicians and Systems within a Regional Health Network - Routine Imaging Referral Radiology Enterprise A Radiology Enterprise B Physician Office Regional Health Information Network Cross-Enterprise Registry Patient Id= 3547F45 Report 5/21/1998 : CT Head ?B Study 5/21/1998 : CT Head ?B


Physicians and Systems within a Regional Health Network - Routine Imaging Referral :6 Physicians and Systems within a Regional Health Network - Routine Imaging Referral Radiology Enterprise A Radiology Enterprise B Physician Office Regional Health Information Network Cross-Enterprise Registry


Physicians and Systems within a Regional Health Network for a Routine Imaging Referral :7 Physicians and Systems within a Regional Health Network for a Routine Imaging Referral Radiology Enterprise A Radiology Enterprise B Physician Office Regional Health Information Network Cross-Enterprise Registry 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


Value Proposition :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


Value Proposition :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.


XDS-I Dependencies :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)


XDS-I Actors and Transactions :11 Document Consumer Retrieve Document Query Documents Patient Identity Source Patient Identity Feed Document Source Document Registry Document Repository Provide & Register Document Set Register Document Set XDS-I Actors and Transactions


XDS-I New Transaction requirements :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


XDS-I Profile Dependencies :13 XDS-I Profile Dependencies


XDS-I Profile Options (1) :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


XDS-I Profile Options (2) :15 XDS-I Profile Options (2)


XDS-I Profile Options (3) :16 XDS-I Profile Options (3)


Sharing of Extensive DICOM Instance Set :17 Sharing of Extensive DICOM Instance Set


Slide 18:18 Document Registry Document Repository


Sharing of Extensive DICOM Instance Set :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)


Sharing of Imaging Report :20 Sharing of Imaging Report


Slide 21:21 Radiology system Report Source Text Report PDF Report Text +PDF Report


Slide 22:22 Radiology system Report Source Document Registry Document Repository


Sharing of Report :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


XDS-I Actors / Grouping :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


Linking Report to Complete Set of Images :25 Linking Report to Complete Set of Images Document Repository Document Registry


Linking Report to Complete Set of Images :26 Linking Report to Complete Set of Images Document Repository Document Registry DocumentEntry


Linking Report to Prior Images and Prior Report :27 Linking Report to Prior Images and Prior Report Document Repository Document Registry DocumentEntry


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


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


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


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


WADO Selection Parameters :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


WADO MIME type of return object :33 WADO MIME type of return object The MIME type of the object contained in the contentType parameter, compatible the parameter of the GET method application/dicom for 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


WADO MIME type of a Structured Report :34 WADO MIME type of a Structured Report application/dicom application/x-hl7-cda-level-one+xml for 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.


WADO Parameters when the object is return as application/dicom :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)


Parameters when the object is return as image/xxx (1) :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


Parameters when the object is return as image/xxx (2) :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)


Security aspects :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.


Providing a image as image/xxx :39 Providing a image as image/xxx


Client flexibility :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


XDS-I Metadata :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


More information…. :42 More information…. 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 Questions?


Extensive DICOM Instance Set :43 Extensive DICOM Instance Set


Imaging Report :44 Imaging Report