1、BRITISH STANDARD BS ISO 17432:2004 Health informatics Messages and communication Web access to DICOM persistent objects ICS 35.240.80 BS ISO 17432:2004 This British Standard was published under the authority of the Standards Policy and Strategy Committee on 3 October 2005 BSI 3 October 2005 ISBN 0 5
2、80 46653 1 National foreword This British Standard reproduces verbatim ISO 17432:2004 and implements it as the UK national standard. The UK participation in its preparation was entrusted to Technical Committee IST/35, Health informatics, which has the responsibility to: A list of organizations repre
3、sented on this committee can be obtained on request to its secretary. Cross-references The British Standards which implement international publications referred to in this document may be found in the BSI Catalogue under the section entitled “International Standards Correspondence Index”, or by usin
4、g the “Search” facility of the BSI Electronic Catalogue or of British Standards Online. This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application. Compliance with a British Standard does not of itself confer immunity fr
5、om legal obligations. aid enquirers to understand the text; present to the responsible international/European committee any enquiries on the interpretation, or proposals for change, and keep UK interests informed; monitor related international and European developments and promulgate them in the UK.
6、 Summary of pages This document comprises a front cover, an inside front cover, the ISO title page, pages ii to v, a blank page, pages 1 to 17 and a back cover. The BSI copyright notice displayed in this document indicates when the document was last issued. Amendments issued since publication Amd. N
7、o. Date Comments Reference number ISO 17432:2004(E)INTERNATIONAL STANDARD ISO 17432 First edition 2004-12-15 Health informatics Messages and communication Web access to DICOM persistent objects Informatique de sant Messages et communication Accs au web pour les objets persistants DICOM BS ISO 17432:
8、2004 ii iii Contents Page Foreword iv Introduction v 1 Scope 1 2 Normative references . 1 3 Terms and definitions. 2 4 Symbols and abbreviated terms 2 5 Data communication Requirements 3 5.1 Interaction 3 5.2 HTTP request. 3 5.3 HTTP Response. 4 6 Persistent object types. 5 6.1 General. 5 6.2 Single
9、 frame image objects 5 6.3 Multi-frame image objects 5 6.4 Text objects . 6 6.5 Other objects . 6 7 Parameters. 7 7.1 Parameters available for all DICOM persistent objects 7 7.2 Parameters for DICOM single frame and multi-frame image persistent objects only . 9 Annex A (informative) URL/URI transfer
10、 syntax 13 Annex B (informative) Examples. 15 Annex C (informative) Applications 16 Annex D (informative) IANA Mapping. 17 BS ISO 17432:2004 BS ISO 17432:2004 iv Foreword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodie
11、s). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and n
12、on-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Pa
13、rt 2. The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies castin
14、g a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO 17432 was prepared by Technical Committee ISO/TC 215, Health informatics in liaison wit
15、h DICOM and is equivalent to DICOM Part 18, Supplement 85. BS ISO 17432:2004 v Introduction The DICOM standard is well accepted in the medical imaging area, including radiology, cardiology, pathology, radiotherapy as well as specialities using visible light imaging equipment (e.g. endoscopes, micros
16、copes). The requesters of medical imaging studies and care providers require rapid and reliable access to reports and images. Within computerized environments such access is increasingly based on web technologies. Access to relevant DICOM persistent objects is required without the need for duplicati
17、on of such data objects. Clinicians need to have access either to the original data in native DICOM format that allows extensive manipulation using specialized software which makes use of the detailed DICOM meta-data, or rendered into a generic format (e.g. JPEG, PDF) that can be presented with off-
18、the-shelf applications. This International Standard specifies the means whereby a request for access to a DICOM persistent object is to be expressed as an HTTP URL/URI (see IETF RFC2396) request which includes a pointer to a specific DICOM persistent object in the form of its instance UID. The reque
19、st also specifies the format of the result to be returned in response to the request. Examples include: a) (MIME) content-type (e.g. application/dicom or image/jpeg for images, application/dicom or application/rtf or xml for reports); b) content-encodings; c) reports as HL7/CDA Level 1. The paramete
20、rs of the query URL as defined within this International Standard are sufficient for the HTTP server to act as a DICOM SCU (Service Class User) to retrieve the requested object from an appropriate DICOM SCP (Service Class Provider) using baseline DICOM functionality as defined in DICOM PS 3.4 and DI
21、COM PS 3.7. Specifications of requirements for additional DICOM persistent objects and formats for the responses from the server will be produced in the future as required. blank 1Health informatics Messages and communication Web access to DICOM persistent objects 1 Scope This International Standard
22、 specifies a web-based service for accessing and presenting DICOM (Digital Imaging and Communications in Medicine) persistent objects (e.g. images, medical imaging reports). This is intended for distribution of results and images to healthcare professionals. It provides a simple mechanism for access
23、ing a DICOM persistent object from HTML pages or XML documents, through HTTP/HTTPs protocol, using DICOM UIDs (Unique Identifiers). Data may be retrieved either in a presentation-ready form as specified by the requester (e.g. JPEG or GIF) or in a native DICOM format. This International Standard does
24、 not support facilities for web searching of DICOM images. It relates only to DICOM persistent objects (not to other DICOM objects or to non-DICOM objects). Access control beyond the security mechanisms generally available to web applications is outside the scope of this International Standard. NOTE
25、 Systems claiming conformance to this International Standard shall function in accordance with all its mandatory clauses. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undate
26、d references, the latest edition of the referenced document (including any amendments) applies. ISO/IEC 10918-2:1995, Information technology Digital compression and coding of continuous-tone still images: Compliance testing DICOM PS 3.3, Digital Imaging and Communications in Medicine, Information Ob
27、ject Definitions DICOM PS 3.4, Digital Imaging and Communications in Medicine, Service Class Specifications DICOM PS 3.5, Digital Imaging and Communications in Medicine, Data Structures and Encoding DICOM PS 3.6, Digital Imaging and Communications in Medicine, Data Dictionary DICOM PS 3.7, Digital I
28、maging and Communications in Medicine, Message Exchange DICOM PS 3.10, Digital Imaging and Communications in Medicine, Media Storage and File Format for Data Interchange DICOM PS 3.11, Digital Imaging and Communications in Medicine, Media Storage Application Profiles DICOM PS 3.14, Digital Imaging a
29、nd Communications in Medicine, Grayscale Standard Display Function DICOM PS 3.15, Digital Imaging and Communications in Medicine, Security Profiles HL7 CDA, Health Level Seven, Clinical Document Architecture (CDA) BS ISO 17432:2004 2 IETF RFC2045 et seq., MIME Multipurpose Internet Mail Extension IE
30、TF RFC2396, Uniform Resource Identifiers (URI): Generic Syntax IETF RFC2616, Hypertext Transfer Protocol HTTP/1.1 IETF RFC3240, Application/dicom MIME Sub-type Registration 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 DICOM persistent obje
31、ct instance of a data object as defined by DICOM PS 3.3, which has been allocated a unique identifier in the format specified for SOP Instance UID in DICOM PS 3.3 and has been chosen as an object to be saved securely for some period of time NOTE Within the DICOM Standard, a DICOM Persistent Object i
32、s referred to as a Composite Service Object Pair (SOP) Instance. 3.2 web client system system using internet technologies (web, e-mail) interested in retrieving DICOM persistent objects from a web enabled DICOM server, through HTTP/HTTPs protocol 3.3 web enabled DICOM server system managing DICOM pe
33、rsistent objects and able to transmit them on request to the web client system 3.4 web access to DICOM persistent objects service enabling the web client system to retrieve DICOM persistent objects managed by a web enabled DICOM server, through HTTP/HTTPs protocol 4 Symbols and abbreviated terms DIC
34、OM Digital Imaging and Communications in Medicine HL7 Health Level Seven HTML HyperText Markup Language HTTP HyperText Transfer Protocol HTTPs HyperText Transfer Protocol, secured MIME Multipurpose Internet Mail Extensions SOP Service Object Pair UID Unique (DICOM) Identifier URL/URI Uniform Resourc
35、e Locator/Identifier XML eXtensible Markup Language BS ISO 17432:2004 35 Data communication requirements 5.1 Interaction The interaction shall be as shown in Figure 1. Figure 1 Interaction diagram 5.2 HTTP request 5.2.1 Method The HTTP request shall use the GET method as defined in IETF RFC2616. 5.2
36、.2 Parameters of the HTTP request The parameters of the component of the request-URI to be sent to the web server through the HTTP GET method request shall be represented as defined in IETF RFC2396. NOTE 1 Other components of the request-URI depend on the configuration, e.g. location and script lang
37、uage of the web enabled DICOM server. NOTE 2 The means by which the web client system obtains the value of the necessary parameters for web accessing of DICOM objects is out of the scope of this International Standard. 5.2.3 List of media types supported in the response The “Accept” field of the GET
38、 method request shall specify the media type(s) acceptable to the web client system. The(se) media type(s) shall include at least the items of the list of MIME (see IETF RFC2045) types specified in Clause 6 devoted to the DICOM persistent object types. NOTE Typically the “Accept” field will be sent
39、by a web client as “*/*”. An optional parameter specifies the MIME type(s) preferred by the web client, as a subset of those specified in the “Accept” field. BS ISO 17432:2004 4 5.2.4 List of character sets supported in the response The “Accept-charset” field of the GET method request shall specify
40、the character set of the object to be retrieved. If the “Accept-charset” field of the GET method is not present, or the web enabled DICOM server does not support the specified character set, the character set of the response will be at the discretion of the web enabled DICOM server. NOTE Typically,
41、the user of a web client does not have control over the “Accept-charset” field. An optional parameter specifies the character set to be used in the returned object. 5.3 HTTP Response 5.3.1 General The response shall be an HTTP response message as specified in IETF RFC2616. NOTE The content of the me
42、ssage-body varies according to the MEDIA type as defined in 5.3.2.2 and 5.3.4.2. 5.3.2 Body of single DICOM MIME sub-type part response 5.3.2.1 MIME Type The MIME type shall be “application/dicom”, as specified in IETF RFC3240 and DICOM PS 3.11. 5.3.2.2 Content The body content shall be a “Part 10 F
43、ile” which includes a meta-header as defined in DICOM PS 3.10. 5.3.3 Transfer syntax The returned DICOM object shall be encoded using one of the transfer syntaxes specified in the transfer syntax query parameter as defined in 7.2.12. By default, the transfer syntax shall be “Explicit VR Little Endia
44、n”. NOTE This implies that retrieved images are sent un-compressed by default. 5.3.4 Body of non-DICOM MIME type response 5.3.4.1 MIME Type The MIME type shall be one of the MIME types defined in the contentType parameter, preferably the most desired by the web client, and shall be in any case compa
45、tible with the “Accept” field of the GET method. NOTE The HTTP behaviour is that an error (406 not acceptable) is returned if the required content type cannot be served. 5.3.4.2 Content The content shall be a single MIME part containing the object to be retrieved. NOTE Multiple objects in a response
46、 are not supported by this International Standard. The parameters select only a single object to retrieve. Most current web clients are able to retrieve single objects, within a “non-multipart” MIME body, and are not able to support multipart/related or multipart/mixed responses. BS ISO 17432:2004 5
47、6 Persistent object types 6.1 General The provisions for some specific object types shall be as defined in 6.2 to 6.5. In all cases the categorization depends on the SOP class of the objects, enabling a client or application building an HTML page for the client, to determine in advance of the reques
48、t what the requirements will be. 6.2 Single frame image objects 6.2.1 Objects accessed In this category are all object instances of SOP classes defined in DICOM PS 3.3, which consist of a single image frame, instances of multi-frame SOP classes that contain only one frame, or object instances that c
49、onsist of a single frame accessed from instances of multi-frame SOP classes using the “frameNumber” parameter. 6.2.2 MIME type constraints The server shall be able to send a response in each of the following MIME types: application/dicom; image/jpeg. If the contentType parameter is not present in the request, the response shall contain an image/jpeg MIME type, if compatible with the “Accept” field of the GET method. When an image/jpeg MIME type is returned, the image
