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
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
Radiology Enterprise A
Physician Office
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
Radiology Enterprise A
Physician Office
5
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

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

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
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
Text Report
PDF Report
Text PDF Report
Radiology system Report Source
22
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
Linking Report to Complete Set of Images
Document Registry
Document Repository
26
Linking Report to Complete Set of Images
Document Registry
DocumentEntry
Document Repository
27
Linking Report to Prior Images and Prior Report
Document Registry
DocumentEntry
Document Repository
28
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 Enabled DICOM Server
Web Client System
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//ltauthoritygtltpathgt?ltquerygt
• e.g
• http//www.hosp.fr/dicom/wado.asp?studyUID1
• The  Web Access to DICOM Persistent Object 
  standard defines only the ltquerygt

Path of the Web Enabled DICOM Server
WADO Parameter(s)
32
WADO Selection Parameters

• studyUIDseriesUIDobjectUIDframeNumber
• studyUID gt UID of the study containing the
  object(s)
• seriesUID gt UID of the series containing the
  object(s)
• objectUID gt UID of the single object (Service
  Object Pair SOP)
• frameNumber gt 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 ltacceptgt
  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

34
WADO MIME type of a Structured Report

• application/dicom
• application/x-hl7-cda-level-onexml 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.

35
WADO Parameters when the object is return as
application/dicom

• transferSyntaxanonymizecharset
• transferSyntax gt DICOM UID of the transferSyntax
  to be applied to the image (lossy/lossless
  compression). Implicit and Big Endian TS shall
  not be used.
• anonymize gt 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 gt 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 gt controls the level of compression
  (from 1 to 100)
• presentation gt 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 gt controls the
  luminosity and the contrast of the BW image

37
Parameters when the object is return as image/xxx
(2)

• regionrowscolumnsannotation
• region gt part of the image to be displayed, in
  relative coordinates (top left hand corner and
  bottom right hand extent)
• rows gt maximum number of pixels (vertical)
• columns gt maximum number of pixels (horizontal)
• annotation gt 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
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
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?
43
Extensive DICOM Instance Set
44
Imaging Report