1. ttp2211xx [1] DICOM WG10 SEOUL – May 5, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com « Web access to DICOM objects » Preparation of the working proposal

2. ttp2211xx [2] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com Updates on the DICOM / web subject l « DICOM MIME (sub-)type » recorded by IETF as RFC3240 so re-balloted for little updates l Some T-cons for writing a project for Work Item definition: still open discussions, mainly because the subject is estimated as too broad l DICOM URL/URI has been introduced as a working item of the WG10 to ISO & HL7 people in San Diego l It will be studied by the common group created by DICOM/WG10 and ISO TC215/WG2, meeting at any HL7 « January » week l 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. ttp2211xx [3] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com Scope of the DICOM URL/URI l How can we reference DICOM images (and object, more generally) in non DICOM documents (i.e. HL7, HTML, XML)? l How can we put in a web server a mechanism to access to the DICOM archiving server without developing a specific DICOM Q&R plug-in or applet? How can we express the parameters for Retrieve, or, more, for Query? l 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? l 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. ttp2211xx [4] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com The distribution problem Electronic Patient Record Radiology PACS Cardiology PACS VL, US, NM PACS HIS RIS Other Clinical System Web Viewers Webserver Report Type: Findings: Conclusions: Ima g e R e f s. : : Header: Thorax ….. ….. ….. Mass ….. ….. Daim. Infiltr. ….. ….. (Poi n t e r ) URL/URI?

5. ttp2211xx [5] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com DICOM URL Definition DICOM « Entity » (station, server, modality, media) database Non-DICOM document or system DICOM URL / URI

6. ttp2211xx [6] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com Overall objectives l 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. l 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. l 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. ttp2211xx [7] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com Objectives of the recommendation l 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. l 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. ttp2211xx [8] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com Applications l 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). l Second opinion –reference defining the localization of the DICOM objects –reference independent of the localization l Other applications, linked to the growing role of documents as key components of medical database

9. ttp2211xx [9] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com Open issues l Name of the work item: « DICOM URL/URI » versus « Integration of DICOM images in EPR/EMR »? l Focus the functional objectives (eg retrieve structured document or presentation document) l 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. ttp2211xx [10] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com First Technical works to proceed l 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 l Check with other medical domains (i.e. Medical Devices, HL7…) what is their point of view l Analyze the existing mechanisms in the Internet standards to go in the « right direction » (i.e. URL, URI, Xlink, ebXML, Corba…)

11. ttp2211xx [11] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com 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. ttp2211xx [12] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com 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, -xlink:type – this attribute defines the element as being an XLINK simple link. It has a fixed value of 'simple', -xlink:href – 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. -xlink:role – 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. ttp2211xx [13] DICOM WG10 SEOUL – May 6, 2002 - 1/10/2016 Emmanuel.Cordonnier@Etiam.com 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 xlink:role. » => Should DICOM use this « frame » of external document reference as a basis of the « DICOM URL/URI » technical definition?