Web access to DICOM objects

1
 Web access to DICOM objects 

• Preparation of the working proposal

2
Updates on the DICOM / web subject

•  DICOM MIME (sub-)type  recorded by IETF as
  RFC3240 so re-balloted for little updates
• Some T-cons for writing a project for Work Item
  definition still open discussions, mainly
  because the subject is estimated as too broad
• DICOM URL/URI has been introduced as a working
  item of the WG10 to ISO HL7 people in San Diego
• It will be studied by the common group created by
  DICOM/WG10 and ISO TC215/WG2, meeting at any HL7
   January  week
• The definition of the work Item must be submitted
  (ad formally approved) at the June DSC meeting ad
  submitted at the ISO August meeting

3
Scope of the DICOM URL/URI

• How can we reference DICOM images (and object,
  more generally) in non DICOM documents (i.e. HL7,
  HTML, XML)?
• How can we put in a web server a mechanism to
  access to the DICOM archiving server without
  developing a specific DICOM QR plug-in or
  applet? How can we express the parameters for
  Retrieve, or, more, for Query?
• How can we archive in electronic medical/patient
  record "permanent" reference to DICOM images
  enabling the systems to retrieve the image many
  years later, even if the DICOM system from one
  vendor has been replaced by an other one?
• How can we have a reference to a DICOM object
  expressed in a meaningful sequence of characters?
  I want to use DICOM media (CD) for archiving the
  images of my electronic patient record system, so
  how to reference such images into it?

4
The distribution problem
HIS
Other Clinical System
RIS
Cardiology PACS
VL, US, NM PACS
Electronic Patient Record
URL/URI?
Webserver
Web Viewers
5
DICOM URL Definition
Non-DICOM document or system
DICOM URL / URI
DICOM  Entity  (station, server, modality,
media)
database
6
Overall objectives

• to encourage users and application developers
  integrating images into their system to maintain
  the images in DICOM format and systems and not to
  convert them into a "commonplace" where all the
  richness of the information stored into DICOM is
  lost.
• to develop and maintain a good independency
  between information/communication systems and
  medical imaging systems enabling a better
  flexibility for the evolution of such systems and
  avoiding duplication of work necessary for the
  integration of the different systems.
• to pursue the work initiated with "DICOM MIME
  type" recommendation contributing to popularize
  the DICOM standard (to be considered by the
  healthcare users as so usable but more powerful
  than JPEG, for example).

7
Objectives of the recommendation

• unique way for referencing DICOM  persistent
  documents" (TBD what are "things", images,
  composite objects, fields) into non-DICOM
  systems which are already using "Internet like"
  mechanisms for referencing other information.
• provides an alternative to existing
  Retrieve/Store services, over HTTP. The URL/URI
  is transmitted by the non-DICOM system to a DICOM
  compatible "system" (plug-in, applet,
  application, equipment, server) which is
  "mapping" the URL/URI to the parameters necessary
  for the DICOM service (C-MOVE, C-FIND, N-GET) to
  access/retrieve the information.

8
Applications

• Extension of electronic medical/patient records
  servers to images. Three kinds of requirements
  are expressed
• store a "permanent" UID for the image referenced
  into their database
• "query" the DICOM server to obtain the list of
  such UID's corresponding to a specific request
  (PatientID, Name)
• "enrich" the information database by an
  information stored into a referenced DICOM image
  (Modality for example).
• Second opinion
• reference defining the localization of the DICOM
  objects
• reference independent of the localization
• Other applications, linked to the growing role of
  documents as key components of medical database

9
Open issues

• Name of the work item  DICOM URL/URI  versus
   Integration of DICOM images in EPR/EMR ?
• Focus the functional objectives (eg retrieve
  structured document or presentation document)
• Technical issues
• How to express the  location independent  UID?
  Using  Namespaces  mechanisms?
• How to express selection by criteria? CGI?
• How to express the way of presentation of the
  result (for example  return a JPEG lossy image
  with progressive compression )?
• Is the result of retrieving SR is structured
  (XML?) or not (HTML)? Or both through style sheet
  associated with the document? Address also the
  process to be applied to the document?

10
First Technical works to proceed

• Identify and describe precisely some scenarios we
  want to be able to implement through the DICOM
  URL
• Analyze how it is done now without DICOM URL
• And what are the advantages of DICOM URL
• Check with other medical domains (i.e. Medical
  Devices, HL7) what is their point of view
• Analyze the existing mechanisms in the Internet
  standards to go in the  right direction  (i.e.
  URL, URI, Xlink, ebXML, Corba)

11
ebML MS 2.0 Reference Element (1)

•  The Reference element is a composite element
  consisting of the following subordinate elements
• zero or more Schema elements information about
  the schema(s) that define the instance document
  identified in the parent Reference element
• zero or more Description elements a textual
  description of the payload object referenced by
  the parent Reference element
• The Reference element itself is a simple link
  XLINK. It should be noted that the use of XLINK
  in this context is chosen solely for the purpose
  of providing a concise vocabulary for describing
  an association. Use of an XLINK processor or
  engine is NOT REQUIRED, but may prove useful in
  certain implementations . . . 

12
ebML MS 2.0 Reference Element (2)

•  The Reference element has the following
  attribute content in addition to the element
  content described above
• id an XML ID for the Reference element,
• xlinktype this attribute defines the element
  as being an XLINK simple link. It has a fixed
  value of 'simple',
• xlinkhref this REQUIRED attribute has a value
  that is the URI of the payload object referenced.
  It SHALL conform to the XLINK XLINK
  specification criteria for a simple link.
• xlinkrole this attribute identifies some
  resource that describes the payload object or its
  purpose. If present, then it SHALL have a value
  that is a valid URI in accordance with the
  XLINK specification,
• Any other namespace-qualified attribute MAY be
  present. A Receiving MSH MAY choose to ignore any
  foreign namespace attributes other than those
  defined above. 

13
ebML MS 2.0 Reference Element (3)

•  The designer of the business process or
  information exchange using ebXML Messaging
  decides what payload data is referenced by the
  Manifest and the values to be used for
  xlinkrole. 
• gt Should DICOM use this  frame  of external
  document reference as a basis of the  DICOM
  URL/URI  technical definition?