Scope



Supplement 183: Part 18 Re-DocumentationEditor: Jim PhilbinVersion: 0.2Date: 13 January 2015TODO:All message templates should use ABNF except target URI should be URI templateDICOM Media Type Annex Rendered Media Type AnnexOther Media Types AnnexVerify Status Code Sections are similarly formattedSuccess responseMost common success codesError responseMost common success codesall status code tables should have the same formatall status code sections should reference the larger status table in either 6.2 or 9.2 or bothAdd Media Type Table or References to all media type sectionsMake sure there are references to the appropriate Section or Annex Make sure the Annexes are in the form of a Media Type registration followed by format detailsMake sure all resource sections in chapters 7, 9, 10 - 12 have the same format including tables.Make sure all URI Templates are correct (Whitby help)Update Open / Closed issuesUpdate Section 3 with all references in Part 18Update Section 4Update Section 5Have Larry Tarbox review chapter 8.Add WS Retrieve Rendered Presentation State transaction to chapter 9.Make sure bullets and numbering are correct.Verify that all sections that should be structurally equivalent are.TODO finalFinish all TODOs in documentAdd links to all references in document (most are highlighted in yellow)Make sure all section, table, and figure numbering is correct.Correction CPs NeededAdd media type application/dicom+jsonChange the application/dicom+json encoding to have “Value” goes to “value” in tag structure.Adding Status Details to Error or Warning response payloadsMedia Type text/xml is required for all three protocols.Closed General Issues#IssuesOpen General Issues#IssuesStatusCan a rendered presentation state be rendered in a different media type than its transfer syntax?Yes, but only if the origin server supports the media type.You get what you get.Transfer syntax should not be specified in the rendered media types.ClosedShould Error responses payloads require a Status Details payload? Leaning toward Yes for RS – No for URI, WS. Needs a CP.Editorial Questions#IssuesStatusWhat is the proper way to refer to Part 18 of the DICOM Standard? The DICOMweb Standard? This Part of the Standard? PS3.18? All three?Decision: PS3.18What is the best way to handle status codes sections?Proposal: Only include the most relevant status codes for the particular transaction and a reference to the general status code section.How should we handle hyperlinks?Include the reference and hyperlink it?Just add a hyperlink to the word or phraseDecision: Include the reference in a hyperlink.ClosedShould we define suggested or required DICOM reason phrases?Should hyperlinks point to our References section or to the standard itself?Proposal: They should point to the referenced standard, i.e. RFC xxxEditorial Decisions#IssuesStatusSince URI template varspecs are case insensitive all template variable are lowercase with word separated by ‘_’Yes.{attributeID} -> {attribute}, because templates are case insensitive.ClosedClosedShould “user agent” and “Origin server” be lowercase without the hyphen, i.e. “user agent” and “origin server”? Yes, That is the way they are written in the standard.Closed“Bulkdata” or “Bulk Data”: leaning toward “Bulkdata”, which denotes a DICOM object, whereas, “Bulk Data” is generic large data.Decision: Bulkdata.ClosedShould we replace {+svc} with “/” (the relative URL that is the root of the service?Yes. This makes it simpler, shorter, and clearerClosedEditor’s NotesTerminology and StructureThroughout this document I have endeavored to use the following terminology to structure the document:ProtocolA protocol defines a set of related services and resources, typically on top of a technology framework, such as WS* web services or Restful web services.ServiceA service defines a set of related transactions on a resource or resource groupTransactionA transaction is a request/response message pair using a specific HTTP method on a resource or resource groupResourceA resource is an concept that refers to a thing. The thing might be abstract like an idea. In the DICOMweb Standard it typically refers to a DICOM Information Object. Resources can more than one representation.Resource GroupA collection of related resources.Target ResourceA target resource is the resource that is the focus of the transaction. It is referenced by a target URI in the request message of a transaction.Target URIThe URI in the first line of a request message. It references the target resource.RepresentationA data format that contains an encoding of a resource. The format of a representation is identified by it media type.Media TypeThe name, possibly parameterized, of a specific encoding of a representation.2.Document Structurea.3 Protocols: URI, WS, RSb.URI has one service, Retrieve, with three Transactions:DICOM InstanceRendered InstanceRendered Presentation State Instancec.WS has one service, Retrieve, with four transactionsDocument SetRendered Document SetRendered Presentation StateDocument Set Metadatad.RS protocol has two services:The Storage service which has X transactions:Retrieve DICOMRetrieve Rendered Retrieve Rendered Presentation StatesStore DICOMSearchCapabilitiesThe Worklist service has 12 transactionsCreate Work ItemRetrieve Work ItemUpdate Work ItemChange Work Item StateRequest Work Item CancellationSearch for Work ItemCreate SubscriptionDelete SubscriptionOpen Event ChannelClose Event ChannelSend Event ReportCapabilities****All Content Above this line is editorial and should be deleted before Final Text****PS3.18DICOM PS3.182015x – Web ServicesPS3.18: DICOM PS3.18 2015x – DICOMwebCopyright 2015 NEMAContents TOC \o "1-5" \h \z \u 1Scope PAGEREF _Toc408909723 \h 192Conformance PAGEREF _Toc408909724 \h 203Normative References PAGEREF _Toc408909725 \h 224Terms and Definitions PAGEREF _Toc408909726 \h 234.1DICOM Terms PAGEREF _Toc408909727 \h 234.2DICOMweb Terms and Definitions PAGEREF _Toc408909728 \h 234.3HTTP Terms and Definitions PAGEREF _Toc408909729 \h 244.4Other Terms PAGEREF _Toc408909730 \h 265Symbols and Abbreviated Terms PAGEREF _Toc408909731 \h 276DICOMweb Overview PAGEREF _Toc408909732 \h 286.1DICOMweb Protocols, Services, and Transactions PAGEREF _Toc408909733 \h 286.2DICOMweb Uses HTTP (Informative) PAGEREF _Toc408909734 \h 296.3Resources PAGEREF _Toc408909735 \h 296.4DICOMweb Transactions PAGEREF _Toc408909736 \h 306.4.1Message Syntax PAGEREF _Toc408909737 \h 306.4.1.1Target Resource Syntax PAGEREF _Toc408909738 \h 306.4.1.2Target Resource Syntax PAGEREF _Toc408909739 \h 306.4.1.3SOP Instances PAGEREF _Toc408909740 \h 306.4.1.4Metadata, and Bulkdata Resources PAGEREF _Toc408909741 \h 306.4.1.5Studies and Series Resources PAGEREF _Toc408909742 \h 316.4.2DICOMweb Message Format Syntax PAGEREF _Toc408909743 \h 316.4.2.1Standard Syntax Variable Names PAGEREF _Toc408909744 \h 316.4.2.2Standard URI Template Variable Names PAGEREF _Toc408909745 \h 326.4.3Request Message Format PAGEREF _Toc408909746 \h 326.4.3.1Methods PAGEREF _Toc408909747 \h 326.4.3.2Target Resources PAGEREF _Toc408909748 \h 346.4.3.3Query Parameters (Normative) PAGEREF _Toc408909749 \h 346.4.3.3.1Syntax of Query Parameters PAGEREF _Toc408909750 \h 346.4.3.3.2Query Parameter Specifications PAGEREF _Toc408909751 \h 356.4.3.4Request Header Fields (Informative) PAGEREF _Toc408909752 \h 366.4.3.4.1Content Negotiation Header Fields PAGEREF _Toc408909753 \h 366.4.3.4.2Content Representation PAGEREF _Toc408909754 \h 376.4.3.4.3Transfer Syntax Parameters for Content Negotiation and -Representation Header Fields PAGEREF _Toc408909755 \h 386.4.3.5Request Payload PAGEREF _Toc408909756 \h 386.4.4Behavior PAGEREF _Toc408909757 \h 386.4.5Response Message Format PAGEREF _Toc408909758 \h 386.4.5.1Status Codes (Informative) PAGEREF _Toc408909759 \h 396.4.5.2Response Header Fields PAGEREF _Toc408909760 \h 436.4.5.3Response Payload PAGEREF _Toc408909761 \h 436.4.5.3.1Status Details Payload for Responses with Issues PAGEREF _Toc408909762 \h 436.4.6Payloads PAGEREF _Toc408909763 \h 446.4.6.1Payload Header Fields PAGEREF _Toc408909764 \h 446.4.6.2Payload Format PAGEREF _Toc408909765 \h 446.4.6.2.1Single Part Payload PAGEREF _Toc408909766 \h 446.4.6.2.2Multi-Part Payload PAGEREF _Toc408909767 \h 446.4.7Representations and Media Types PAGEREF _Toc408909768 \h 466.4.7.1Representation Categories PAGEREF _Toc408909769 \h 466.4.7.2Media Type Syntax PAGEREF _Toc408909770 \h 476.5Security PAGEREF _Toc408909771 \h 486.6DICOMweb Service Descriptions PAGEREF _Toc408909772 \h 487URI Protocol (WADO-URI) PAGEREF _Toc408909773 \h 497.1URI Service PAGEREF _Toc408909774 \h 507.1.1Request PAGEREF _Toc408909775 \h 507.1.1.1Object Identification Parameters PAGEREF _Toc408909776 \h 517.1.1.1.1Request Type PAGEREF _Toc408909777 \h 517.1.1.1.2Unique Identifier of the Study PAGEREF _Toc408909778 \h 517.1.1.1.3Unique Identifier of the Series PAGEREF _Toc408909779 \h 517.1.1.1.4Unique Identifier of the Instance PAGEREF _Toc408909780 \h 527.1.1.2Other Query Parameters PAGEREF _Toc408909781 \h 527.1.1.2.1Unique Identifier of the Presentation Series PAGEREF _Toc408909782 \h 527.1.1.2.2Unique Identifier of the Presentation Object PAGEREF _Toc408909783 \h 527.1.1.2.3MIME Type of the Response (Retired) PAGEREF _Toc408909784 \h 527.1.1.2.4Transfer Syntax UID (Retired) PAGEREF _Toc408909785 \h 527.1.1.2.5Charset of the Response (Retired) PAGEREF _Toc408909786 \h 527.1.1.3Header Fields PAGEREF _Toc408909787 \h 527.1.1.4Request Payload PAGEREF _Toc408909788 \h 527.1.2Behavior PAGEREF _Toc408909789 \h 527.1.3Response PAGEREF _Toc408909790 \h 527.1.3.1Status Codes PAGEREF _Toc408909791 \h 537.1.3.2Header Fields PAGEREF _Toc408909792 \h 537.1.3.3Payload PAGEREF _Toc408909793 \h 537.1.4Media Types PAGEREF _Toc408909794 \h 537.1.4.1Acceptable Media Type PAGEREF _Toc408909795 \h 547.2Retrieve DICOM Instance Transaction PAGEREF _Toc408909796 \h 547.2.1Request PAGEREF _Toc408909797 \h 547.2.1.1Resource PAGEREF _Toc408909798 \h 547.2.1.2Query Parameters PAGEREF _Toc408909799 \h 547.2.1.2.1Anonymize PAGEREF _Toc408909800 \h 547.2.1.3Header Fields PAGEREF _Toc408909801 \h 557.2.1.4Payload PAGEREF _Toc408909802 \h 557.2.2Behavior PAGEREF _Toc408909803 \h 557.2.3Response PAGEREF _Toc408909804 \h 557.2.3.1Status Codes PAGEREF _Toc408909805 \h 557.2.3.2Header Fields PAGEREF _Toc408909806 \h 557.2.3.3Payload PAGEREF _Toc408909807 \h 557.2.4Media Type PAGEREF _Toc408909808 \h 557.3URI Retrieve Rendered Instance Transaction PAGEREF _Toc408909809 \h 567.3.1Request PAGEREF _Toc408909810 \h 567.3.1.1Target Resource PAGEREF _Toc408909811 \h 567.3.1.2Query Parameters PAGEREF _Toc408909812 \h 567.3.1.2.1Annotation on the Object PAGEREF _Toc408909813 \h 577.3.1.2.2Frame Number PAGEREF _Toc408909814 \h 577.3.1.2.3Image Quality PAGEREF _Toc408909815 \h 577.3.1.2.4Pixel Rows in Rendered Image PAGEREF _Toc408909816 \h 577.3.1.2.5Pixel Columns in Rendered Image PAGEREF _Toc408909817 \h 577.3.1.2.6Region of Target Resource PAGEREF _Toc408909818 \h 577.3.1.2.7Window Center of the Rendered Image PAGEREF _Toc408909819 \h 587.3.1.2.8Window Width of the Rendered Image PAGEREF _Toc408909820 \h 587.3.1.3Header Fields PAGEREF _Toc408909821 \h 587.3.1.4Payload PAGEREF _Toc408909822 \h 587.3.2Behavior PAGEREF _Toc408909823 \h 587.3.3Response PAGEREF _Toc408909824 \h 587.3.3.1Status Codes PAGEREF _Toc408909825 \h 597.3.3.2Header Fields PAGEREF _Toc408909826 \h 597.3.3.3Payload PAGEREF _Toc408909827 \h 597.3.4Media Types PAGEREF _Toc408909828 \h 597.4URI Retrieve Rendered Presentation State Transaction PAGEREF _Toc408909829 \h 597.4.1Request PAGEREF _Toc408909830 \h 597.4.1.1Query Parameters PAGEREF _Toc408909831 \h 597.4.1.1.1Pixel Rows in Rendered Image PAGEREF _Toc408909832 \h 607.4.1.1.2Pixel Columns in Rendered Image PAGEREF _Toc408909833 \h 607.4.1.1.3Image Annotation PAGEREF _Toc408909834 \h 607.4.1.1.4Image Quality PAGEREF _Toc408909835 \h 607.4.1.2Header Fields PAGEREF _Toc408909836 \h 607.4.1.3Payload PAGEREF _Toc408909837 \h 607.4.2Behavior PAGEREF _Toc408909838 \h 607.4.3Response PAGEREF _Toc408909839 \h 617.4.3.1Status Code PAGEREF _Toc408909840 \h 617.4.3.2Header Fields PAGEREF _Toc408909841 \h 617.4.3.3Payload PAGEREF _Toc408909842 \h 618WS* Web Services Protocol (WS) PAGEREF _Toc408909843 \h 618.1Transactions PAGEREF _Toc408909844 \h 628.1.1Acceptable Media Type PAGEREF _Toc408909845 \h 638.2Retrieve Imaging Document Set PAGEREF _Toc408909846 \h 638.2.1Request PAGEREF _Toc408909847 \h 638.2.2Response PAGEREF _Toc408909848 \h 648.2.2.1Form of the Response PAGEREF _Toc408909849 \h 648.2.2.2JPIP PAGEREF _Toc408909850 \h 668.3Retrieve Rendered Imaging Document Set PAGEREF _Toc408909851 \h 668.3.1Request PAGEREF _Toc408909852 \h 668.3.1.1Parameters PAGEREF _Toc408909853 \h 678.3.1.1.1Pixel Rows in Rendered Image PAGEREF _Toc408909854 \h 688.3.1.1.2Pixel Columns in Rendered Image PAGEREF _Toc408909855 \h 688.3.1.1.3Region Rendered PAGEREF _Toc408909856 \h 688.3.1.1.4Window Center of the Rendered Image PAGEREF _Toc408909857 \h 698.3.1.1.5Window Width of the Rendered Image PAGEREF _Toc408909858 \h 698.3.1.1.6Frame Number PAGEREF _Toc408909859 \h 698.3.1.1.7Image Quality PAGEREF _Toc408909860 \h 698.3.2Response PAGEREF _Toc408909861 \h 698.4Retrieve Rendered Presentation State Request PAGEREF _Toc408909862 \h 718.5Retrieve Imaging Document Set Metadata Request PAGEREF _Toc408909863 \h 718.5.1Request PAGEREF _Toc408909864 \h 718.5.2Response PAGEREF _Toc408909865 \h 728.6WS Media Types PAGEREF _Toc408909866 \h 748.7Error Codes PAGEREF _Toc408909867 \h 749Restful Web Services Protocol (RS) PAGEREF _Toc408909868 \h 759.1RS Services Overview PAGEREF _Toc408909869 \h 769.2Target Resources PAGEREF _Toc408909870 \h 779.3Transaction Overview PAGEREF _Toc408909871 \h 779.3.1Request Message Format PAGEREF _Toc408909872 \h 779.3.1.1Resources PAGEREF _Toc408909873 \h 789.3.1.2Query Parameters PAGEREF _Toc408909874 \h 789.3.1.3Header Fields PAGEREF _Toc408909875 \h 789.3.1.4Payload PAGEREF _Toc408909876 \h 789.3.2Behavior PAGEREF _Toc408909877 \h 789.3.3Response PAGEREF _Toc408909878 \h 789.3.3.1Status Codes PAGEREF _Toc408909879 \h 789.3.3.2Header Fields PAGEREF _Toc408909880 \h 809.3.4Response Payload PAGEREF _Toc408909881 \h 819.3.5Payload PAGEREF _Toc408909882 \h 819.3.6RS Media Types PAGEREF _Toc408909883 \h 819.3.6.1Acceptable Media Type PAGEREF _Toc408909884 \h 829.3.6.2Multipart Related Media Type PAGEREF _Toc408909885 \h 829.3.6.3Imaging Media Types and Transfer Syntax PAGEREF _Toc408909886 \h 829.4Retrieve Capabilities Transaction PAGEREF _Toc408909887 \h 839.4.1Request PAGEREF _Toc408909888 \h 839.4.1.1Resources PAGEREF _Toc408909889 \h 839.4.1.2Query Parameters PAGEREF _Toc408909890 \h 839.4.1.3Header Fields PAGEREF _Toc408909891 \h 839.4.1.4Payload PAGEREF _Toc408909892 \h 839.4.2Behavior PAGEREF _Toc408909893 \h 839.4.3Response PAGEREF _Toc408909894 \h 839.4.3.1Status Codes PAGEREF _Toc408909895 \h 849.4.3.2Header Fields PAGEREF _Toc408909896 \h 849.4.3.3Payload PAGEREF _Toc408909897 \h 849.4.4Media Types PAGEREF _Toc408909898 \h 849.5Notification Subservice PAGEREF _Toc408909899 \h 849.5.1Deletion Locks PAGEREF _Toc408909900 \h 849.5.2Filters PAGEREF _Toc408909901 \h 849.5.3Resources PAGEREF _Toc408909902 \h 849.5.3.1Service Events PAGEREF _Toc408909903 \h 859.5.4Transactions PAGEREF _Toc408909904 \h 859.5.5Open Event Channel Transaction PAGEREF _Toc408909905 \h 859.5.5.1Request PAGEREF _Toc408909906 \h 859.5.5.1.1Query Parameters PAGEREF _Toc408909907 \h 859.5.5.1.2Header Fields PAGEREF _Toc408909908 \h 869.5.5.1.3Payload PAGEREF _Toc408909909 \h 869.5.5.2Behavior PAGEREF _Toc408909910 \h 869.5.5.3Response PAGEREF _Toc408909911 \h 869.5.5.3.1Status Codes PAGEREF _Toc408909912 \h 869.5.5.3.2Header Fields PAGEREF _Toc408909913 \h 869.5.5.3.3Payload PAGEREF _Toc408909914 \h 879.5.5.4Media Types PAGEREF _Toc408909915 \h 879.5.6Send Event Report Transaction PAGEREF _Toc408909916 \h 879.5.6.1Request PAGEREF _Toc408909917 \h 879.5.6.1.1Payload PAGEREF _Toc408909918 \h 879.5.6.2Behavior PAGEREF _Toc408909919 \h 879.5.6.3Response PAGEREF _Toc408909920 \h 879.5.7Create Subscription Transaction PAGEREF _Toc408909921 \h 879.5.7.1Request PAGEREF _Toc408909922 \h 889.5.7.1.1Header Fields PAGEREF _Toc408909923 \h 889.5.7.1.2Payload PAGEREF _Toc408909924 \h 889.5.7.2Behavior PAGEREF _Toc408909925 \h 889.5.7.3Response PAGEREF _Toc408909926 \h 889.5.7.3.1Status Codes PAGEREF _Toc408909927 \h 899.5.7.3.2Header Fields PAGEREF _Toc408909928 \h 899.5.7.3.3Payload PAGEREF _Toc408909929 \h 899.5.7.4Media Types PAGEREF _Toc408909930 \h 899.5.8Delete Subscription PAGEREF _Toc408909931 \h 899.5.8.1Request PAGEREF _Toc408909932 \h 899.5.8.1.1Query Parameters PAGEREF _Toc408909933 \h 899.5.8.1.2Header Fields PAGEREF _Toc408909934 \h 899.5.8.1.3Payload PAGEREF _Toc408909935 \h 909.5.8.2Behavior PAGEREF _Toc408909936 \h 909.5.8.3Response PAGEREF _Toc408909937 \h 909.5.8.3.1Status Codes PAGEREF _Toc408909938 \h 909.5.8.3.2Header Fields PAGEREF _Toc408909939 \h 909.5.8.4Payload PAGEREF _Toc408909940 \h 909.5.9Media Types PAGEREF _Toc408909941 \h 9010Restful Studies Service PAGEREF _Toc408909942 \h 9010.1Resources PAGEREF _Toc408909943 \h 9110.2Transactions PAGEREF _Toc408909944 \h 9310.3Retrieve DICOM Transaction PAGEREF _Toc408909945 \h 9410.3.1Request PAGEREF _Toc408909946 \h 9410.3.1.1Resources PAGEREF _Toc408909947 \h 9410.3.1.2Query Parameters PAGEREF _Toc408909948 \h 9510.3.1.2.1De-Identification PAGEREF _Toc408909949 \h 9510.3.1.3Header Fields PAGEREF _Toc408909950 \h 9510.3.1.4Payload PAGEREF _Toc408909951 \h 9510.3.2Behavior PAGEREF _Toc408909952 \h 9510.3.3Response PAGEREF _Toc408909953 \h 9510.3.3.1Status Codes PAGEREF _Toc408909954 \h 9510.3.3.2Header Fields PAGEREF _Toc408909955 \h 9610.3.3.3Payload PAGEREF _Toc408909956 \h 9610.3.4Media Types PAGEREF _Toc408909957 \h 9610.4RS Retrieve Rendered Transaction PAGEREF _Toc408909958 \h 10210.4.1Request PAGEREF _Toc408909959 \h 10210.4.1.1Target Resources PAGEREF _Toc408909960 \h 10210.4.1.2Query Parameters PAGEREF _Toc408909961 \h 10210.4.1.2.1Annotation on the Image PAGEREF _Toc408909962 \h 10310.4.1.2.2De-Identification PAGEREF _Toc408909963 \h 10410.4.1.2.3Flip Image PAGEREF _Toc408909964 \h 10410.4.1.2.4Order of Rendered Images PAGEREF _Toc408909965 \h 10410.4.1.2.5Quality of the Image PAGEREF _Toc408909966 \h 10510.4.1.2.6Region of the Image PAGEREF _Toc408909967 \h 10510.4.1.2.7Rotate the Image PAGEREF _Toc408909968 \h 10510.4.1.2.8Window Level Image PAGEREF _Toc408909969 \h 10510.4.1.2.9View Port on the User Agent PAGEREF _Toc408909970 \h 10610.4.1.3Header Fields PAGEREF _Toc408909971 \h 10610.4.1.4Payload PAGEREF _Toc408909972 \h 10610.4.2Behavior PAGEREF _Toc408909973 \h 10610.4.3Response PAGEREF _Toc408909974 \h 10610.4.3.1Status Codes PAGEREF _Toc408909975 \h 10610.4.3.2Header Fields PAGEREF _Toc408909976 \h 10710.4.3.3Payload PAGEREF _Toc408909977 \h 10710.4.4Media Types PAGEREF _Toc408909978 \h 10710.5Retrieve Rendered Presentation States Instance Transaction PAGEREF _Toc408909979 \h 10710.5.1Request PAGEREF _Toc408909980 \h 10710.5.1.1Target Resource PAGEREF _Toc408909981 \h 10710.5.1.2Query Parameters PAGEREF _Toc408909982 \h 10710.5.1.2.1Annotations on the Image PAGEREF _Toc408909983 \h 10810.5.1.2.2De-Identification PAGEREF _Toc408909984 \h 10810.5.1.2.3Volume of Interest Lookup Table (VOI LUT) PAGEREF _Toc408909985 \h 10810.5.1.2.4Quality of the Image PAGEREF _Toc408909986 \h 10810.5.1.2.5View Port on the User Agent PAGEREF _Toc408909987 \h 10810.5.1.3Header Fields PAGEREF _Toc408909988 \h 10810.5.1.4Payload PAGEREF _Toc408909989 \h 10810.5.2Behavior PAGEREF _Toc408909990 \h 10810.5.3Response PAGEREF _Toc408909991 \h 10910.5.3.1Status Codes PAGEREF _Toc408909992 \h 10910.5.3.2Header Fields PAGEREF _Toc408909993 \h 10910.5.3.3Payload PAGEREF _Toc408909994 \h 10910.5.4Media Types PAGEREF _Toc408909995 \h 10910.6Store Service PAGEREF _Toc408909996 \h 10910.6.1Request PAGEREF _Toc408909997 \h 11010.6.1.1Resources PAGEREF _Toc408909998 \h 11010.6.1.2Query Parameters PAGEREF _Toc408909999 \h 11010.6.1.3Header Fields PAGEREF _Toc408910000 \h 11010.6.1.4Payload PAGEREF _Toc408910001 \h 11010.6.2Behavior PAGEREF _Toc408910002 \h 11110.6.3Response PAGEREF _Toc408910003 \h 11110.6.3.1Status Codes PAGEREF _Toc408910004 \h 11110.6.3.2Header Fields PAGEREF _Toc408910005 \h 11210.6.3.3Payload PAGEREF _Toc408910006 \h 11210.6.3.3.1Failure Reason PAGEREF _Toc408910007 \h 11310.6.3.3.2Warning Reason PAGEREF _Toc408910008 \h 11410.6.4Media Types PAGEREF _Toc408910009 \h 11410.7Search Transaction PAGEREF _Toc408910010 \h 11510.7.1Request PAGEREF _Toc408910011 \h 11510.7.1.1Resources PAGEREF _Toc408910012 \h 11510.7.1.2Search Query Parameters PAGEREF _Toc408910013 \h 11510.7.1.2.1Encoding Rules for {attribute} and {value} PAGEREF _Toc408910014 \h 11710.7.1.2.2ABNF Grammar for Search Query Parameters PAGEREF _Toc408910015 \h 11710.7.1.2.3Fuzzy Matching PAGEREF _Toc408910016 \h 11810.7.1.2.4Offset, Limit and Number of Results Returned PAGEREF _Toc408910017 \h 11810.7.1.3Header Fields PAGEREF _Toc408910018 \h 11810.7.1.4Payload PAGEREF _Toc408910019 \h 11810.7.2Behavior PAGEREF _Toc408910020 \h 11810.7.2.1Matching PAGEREF _Toc408910021 \h 11810.7.2.1.1Required Query Parameters PAGEREF _Toc408910022 \h 11810.7.2.1.2Fuzzy Matching PAGEREF _Toc408910023 \h 11910.7.2.2Pagination using Offset and Limit PAGEREF _Toc408910024 \h 11910.7.3Response PAGEREF _Toc408910025 \h 12010.7.3.1Status Codes PAGEREF _Toc408910026 \h 12010.7.3.2Header Fields PAGEREF _Toc408910027 \h 12010.7.3.3Payload PAGEREF _Toc408910028 \h 12010.7.3.3.1Response Payload of Search for Study PAGEREF _Toc408910029 \h 12010.7.3.3.2Response Payload of Search for Series PAGEREF _Toc408910030 \h 12110.7.3.3.3Response Payload of Search for Instance PAGEREF _Toc408910031 \h 12210.7.4Media Types PAGEREF _Toc408910032 \h 12311Retrieve Capabilities Transaction PAGEREF _Toc408910033 \h 12311.1.1WADL Document Format PAGEREF _Toc408910046 \h 12311.1.1.1Methods PAGEREF _Toc408910047 \h 12411.1.1.1.1Retrieve Methods PAGEREF _Toc408910048 \h 12411.1.1.1.2Store Methods PAGEREF _Toc408910049 \h 12511.1.1.1.3Search Methods PAGEREF _Toc408910050 \h 12611.1.1.1.4Update Methods PAGEREF _Toc408910051 \h 12811.1.1.1.5Subscribe Methods PAGEREF _Toc408910052 \h 12812Unified Workflow and Procedure Step (UPS Worklist) Service PAGEREF _Toc408910053 \h 12912.1Overview PAGEREF _Toc408910054 \h 13012.1.1Transactions PAGEREF _Toc408910055 \h 13012.1.2UPS Requests Overview PAGEREF _Toc408910056 \h 13112.1.2.1Resources PAGEREF _Toc408910057 \h 13212.1.2.2Query Parameters PAGEREF _Toc408910058 \h 13212.1.2.3Header Fields PAGEREF _Toc408910059 \h 13212.1.2.4Payload PAGEREF _Toc408910060 \h 13212.1.3Behavior Overview PAGEREF _Toc408910061 \h 13212.1.4Response Overview PAGEREF _Toc408910062 \h 13312.1.4.1Status Codes PAGEREF _Toc408910063 \h 13312.1.5Media Types PAGEREF _Toc408910064 \h 13312.2Basic Transactions PAGEREF _Toc408910065 \h 13312.2.1Create Work Item Transaction PAGEREF _Toc408910066 \h 13312.2.1.1Request PAGEREF _Toc408910067 \h 13312.2.1.2Resources PAGEREF _Toc408910068 \h 13412.2.1.3Query Parameters PAGEREF _Toc408910069 \h 13412.2.1.4Header Fields PAGEREF _Toc408910070 \h 13412.2.1.5Payload PAGEREF _Toc408910071 \h 13412.2.1.6Behavior PAGEREF _Toc408910072 \h 13412.2.1.7Response PAGEREF _Toc408910073 \h 13412.2.1.8Status Codes PAGEREF _Toc408910074 \h 13412.2.1.9Header Fields PAGEREF _Toc408910075 \h 13412.2.1.10Payload PAGEREF _Toc408910076 \h 13512.2.2Retrieve Work Item PAGEREF _Toc408910077 \h 13512.2.2.1Request PAGEREF _Toc408910078 \h 13512.2.2.2Header Fields PAGEREF _Toc408910079 \h 13512.2.2.3Payload PAGEREF _Toc408910080 \h 13512.2.2.4Behavior PAGEREF _Toc408910081 \h 13512.2.2.5Response PAGEREF _Toc408910082 \h 13512.2.2.6Status Codes PAGEREF _Toc408910083 \h 13612.2.2.7Header Fields PAGEREF _Toc408910084 \h 13612.2.2.8Payload PAGEREF _Toc408910085 \h 13612.2.2.9Media Types PAGEREF _Toc408910086 \h 13612.2.3Update Work Item Transaction PAGEREF _Toc408910087 \h 13612.2.3.1Request PAGEREF _Toc408910088 \h 13612.2.3.2Query Parameters PAGEREF _Toc408910089 \h 13612.2.3.3Header Fields PAGEREF _Toc408910090 \h 13712.2.3.4Payload PAGEREF _Toc408910091 \h 13712.2.3.5Behavior PAGEREF _Toc408910092 \h 13712.2.3.6Response PAGEREF _Toc408910093 \h 13712.2.3.7Status Codes PAGEREF _Toc408910094 \h 13712.2.3.8Header Fields PAGEREF _Toc408910095 \h 13712.2.3.9Payload PAGEREF _Toc408910096 \h 13712.2.4Change Work Item State Transaction PAGEREF _Toc408910097 \h 13712.2.4.1Request PAGEREF _Toc408910098 \h 13712.2.4.2Header Fields PAGEREF _Toc408910099 \h 13812.2.4.3Payload PAGEREF _Toc408910100 \h 13812.2.4.4Behavior PAGEREF _Toc408910101 \h 13812.2.4.5Response PAGEREF _Toc408910102 \h 13812.2.4.6Status Codes PAGEREF _Toc408910103 \h 13812.2.4.7Header Fields PAGEREF _Toc408910104 \h 13812.2.4.8Payload PAGEREF _Toc408910105 \h 13912.2.4.9Media Types PAGEREF _Toc408910106 \h 13912.2.5Request Cancellation PAGEREF _Toc408910107 \h 13912.2.5.1Request PAGEREF _Toc408910108 \h 13912.2.5.2Header Fields PAGEREF _Toc408910109 \h 13912.2.5.3Payload PAGEREF _Toc408910110 \h 13912.2.5.4Behavior PAGEREF _Toc408910111 \h 13912.2.5.5Response PAGEREF _Toc408910112 \h 13912.2.5.6Status Codes PAGEREF _Toc408910113 \h 14012.2.5.7Header Fields PAGEREF _Toc408910114 \h 14012.2.5.8Payload PAGEREF _Toc408910115 \h 14012.2.5.9Media Types PAGEREF _Toc408910116 \h 14012.2.6Search for Work Items Transaction PAGEREF _Toc408910117 \h 14012.2.6.1Request PAGEREF _Toc408910118 \h 14012.2.6.2Query Parameters PAGEREF _Toc408910119 \h 14012.2.6.3Header Fields PAGEREF _Toc408910120 \h 14112.2.6.4Payload PAGEREF _Toc408910121 \h 14112.2.6.5Behavior PAGEREF _Toc408910122 \h 14112.2.6.6Response PAGEREF _Toc408910123 \h 14112.2.6.7Status Codes PAGEREF _Toc408910124 \h 14112.2.6.8Header Fields PAGEREF _Toc408910125 \h 14112.2.6.9Payload PAGEREF _Toc408910126 \h 14212.2.6.10Media Types PAGEREF _Toc408910127 \h 14212.3Subscriptions PAGEREF _Toc408910128 \h 14212.3.1Deletion Locks PAGEREF _Toc408910129 \h 14212.3.2Filters PAGEREF _Toc408910130 \h 14212.3.3Resources PAGEREF _Toc408910131 \h 14212.3.4Create Subscription Transaction PAGEREF _Toc408910132 \h 14312.3.4.1Request PAGEREF _Toc408910133 \h 14312.3.4.2Header Fields PAGEREF _Toc408910134 \h 14412.3.4.3Payload PAGEREF _Toc408910135 \h 14412.3.4.4Behavior PAGEREF _Toc408910136 \h 14412.3.4.5Response PAGEREF _Toc408910137 \h 14412.3.4.6Status Codes PAGEREF _Toc408910138 \h 14412.3.4.7Header Fields PAGEREF _Toc408910139 \h 14512.3.4.8Payload PAGEREF _Toc408910140 \h 14512.3.4.9Media Types PAGEREF _Toc408910141 \h 14512.3.5Delete Subscription PAGEREF _Toc408910142 \h 14512.3.5.1Request PAGEREF _Toc408910143 \h 14512.3.5.2Header Fields PAGEREF _Toc408910144 \h 14612.3.5.3Payload PAGEREF _Toc408910145 \h 14612.3.5.4Behavior PAGEREF _Toc408910146 \h 14612.3.5.5Response PAGEREF _Toc408910147 \h 14612.3.5.6Status Codes PAGEREF _Toc408910148 \h 14612.3.5.7Header Fields PAGEREF _Toc408910149 \h 14612.3.5.8Payload PAGEREF _Toc408910150 \h 14612.3.5.9Media Types PAGEREF _Toc408910151 \h 14612.3.6Open Event Channel Transaction PAGEREF _Toc408910152 \h 14712.3.6.1Request PAGEREF _Toc408910153 \h 14712.3.6.2Header Fields PAGEREF _Toc408910154 \h 14712.3.6.3Payload PAGEREF _Toc408910155 \h 14712.3.6.4Behavior PAGEREF _Toc408910156 \h 14812.3.6.5Response PAGEREF _Toc408910157 \h 14812.3.6.6Status Codes PAGEREF _Toc408910158 \h 14812.3.6.7Header Fields PAGEREF _Toc408910159 \h 14812.3.6.8Payload PAGEREF _Toc408910160 \h 14812.3.6.9Media Types PAGEREF _Toc408910161 \h 14812.3.7Send Event Report PAGEREF _Toc408910162 \h 14912.3.7.1Request PAGEREF _Toc408910163 \h 14912.3.7.2Payload PAGEREF _Toc408910164 \h 14912.3.7.3Behavior PAGEREF _Toc408910165 \h 14912.3.7.4Response PAGEREF _Toc408910166 \h 149Annex ADICOM Media Types PAGEREF _Toc408910167 \h 149A.1application/dicom PAGEREF _Toc408910168 \h 150A.1application/dicom+json, application/json PAGEREF _Toc408910169 \h 15012.3.7.5JSON Search Results PAGEREF _Toc408910170 \h 150A.1.1application/dicom+xml PAGEREF _Toc408910171 \h 15012.3.7.6XML Search Results PAGEREF _Toc408910172 \h 15012.3.8XML Status Details Document PAGEREF _Toc408910173 \h 15112.3.8.1Status Details Example PAGEREF _Toc408910174 \h 151Annex BRendered Media Types PAGEREF _Toc408910175 \h 152Annex COther Media Types PAGEREF _Toc408910176 \h 152C.1WADL Document Format - application/vnd.sun.wadl+xml PAGEREF _Toc408910177 \h 152C.1.1IANA Registration PAGEREF _Toc408910178 \h 152C.1.2Definition PAGEREF _Toc408910179 \h 15312.3.8.2Methods PAGEREF _Toc408910180 \h 15412.3.8.2.1Retrieve Methods PAGEREF _Toc408910181 \h 15412.3.8.2.2Store Methods PAGEREF _Toc408910182 \h 15512.3.8.2.3Search Methods PAGEREF _Toc408910183 \h 15612.3.8.2.4Update Methods PAGEREF _Toc408910184 \h 15712.3.8.2.5Subscribe Methods PAGEREF _Toc408910185 \h 158Annex DStatus Details PAGEREF _Toc408910186 \h 159Annex EHTTP Status Codes (Informative) PAGEREF _Toc408910187 \h 160Annex FDICOM Media Types PAGEREF _Toc408910188 \h 161F.1application/dicom PAGEREF _Toc408910189 \h 161F.2application/dicom+xml PAGEREF _Toc408910190 \h 162F.3Application/dicom+json or application/json PAGEREF _Toc408910191 \h 162F.4application/dicom+bulkdata PAGEREF _Toc408910192 \h 162Notice and DisclaimerThe information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.ForewordThis DICOM Standard was developed according to the procedures of the DICOM Standards Committee.The DICOM Standard is structured as a multi-part document using the guidelines established in [Ref Biblio ISO Directives]...PS3.1 should be used as the base reference for the current parts of this standard..ScopeThis standard specifies web-based protocols, based on HTTP/HTTPS, for transmitting and receiving DICOM (Digital Imaging and Communications in Medicine) resources (e.g., images, medical imaging reports). It is intended to be used for distribution medical imaging related information. It provides simple mechanisms for creating, retrieving, updating, deleting, and searching for DICOM resources. Data may be transmitted in native DICOM representations or in “rendered” representations (e.g., JPEG or GIF). This standard relates only to composite DICOM objects (not to other DICOM objects). Authentication, authorization and auditing security mechanisms are outside the scope of this standard.ConformanceSystems claiming conformance to this standard shall function in accordance with all its mandatory sections.Normative ReferencesThe following normative documents contain provisions that, through reference in this text, constitute provisions of this part of DICOM. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this part of DICOM are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain registers of currently valid International Standards.ebRS ebXML Registry ServiceHL7 CDA Health Level Seven, Clinical Document Architecture (CDA)IETF RFC 822 Standard for ARPA Internet Text Messages RFC 2045 and followings MIME Multipurpose Internet Mail Extension RFC 3240 Application/dicom MIME Sub-type Registration RFC 3986 Uniform Resource Identifiers (URI): Generic Syntax RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON) RFC 6455 The WebSocket Protocol RFC 6570 URI Template RFC 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content RFC 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests RFC 7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests RFC 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching RFC 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication RFC 7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations RFC 7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations 10918 JPEG Standard for digital compression and encoding of continuous-tone still imagesIHE ITI TF-2x: Appendix V IHE IT Infrastructure Technical Framework, Volume 2x, Appendix V (Web Services for IHE Transactions)SUBM-wadl-20090831 Web Application Description Language (WADL), W3C Member Submission 31 August 2009 )The Unicode Standard, "Chapter 2. General Structure". The Unicode Standard (6.0 ed.). Mountain View, California, USA: The Unicode Consortium. ISBN 978-1-936213-01-6. and DefinitionsFor the purposes of this part of DICOM, the following terms and definitions apply.DICOM TermsAttributeData ElementInformation EntityInstanceInstanceUIDObjectObjectIDSeriesSeriesUIDSop InstanceStudyStudyUIDTagUIDDICOMweb Terms and DefinitionsThe following terms are used throughout this part of the standard; but they are, in general, not used in the rest of this standardStudy or Study InstanceSeries or Series InstanceInstance or SOP InstanceA composite SOP Instance, as defined in PS3.3, that has been allocated a DICOM unique identifier.. DICOMwebThe set of protocols defined in PS3.18.User AgentA user agent that understands and can processes responses from a DICOMweb origin server. DICOMweb Origin ServerA program that can originate authoritative responses for DICOMweb target resources.HTTP Terms and DefinitionsThe DICOMweb Standard uses the following HTTP terminology extensively. In order to understand the DICOMweb Standard, it is important to understand these terms.Absolute-URI ReferenceAbsolute-Path A relative URI reference that begins with a single slash character ‘/’.Content CodingAn encoding transformation that can be applied to a representation. Content encodings are primarily used to allow a representation to be compressed or otherwise transformed without losing the identity of its underlying media type and without loss of information. See [rfc7231, Section 3.1.2.1< >] for details.Effective Request URIFor a user agent, the effective request URI is the target URI.Header FieldMedia TypeA media type is an identifier, possibly with parameters, that is used to identify the format and/or encoding of a representation. The media type contained in the Content-Type header field tells the receiver how to parse or decode the message payload.Message BodyMethodNetwork-PathA relative URI reference that begins with two slash characters ‘//’.Origin Server The term "origin server" refers to the program that can originate authoritative responses for a given target resource. See [RFC7230 Section 2.1 Client/Server Messaging].Payload, Payload BodyReason PhraseRelative-PathA relative URI reference that does not begin with a slash character.RepresentationWhen used in the DICOMweb Standard the term representation means the representation of a resource.“For the purposes of HTTP, a "representation" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.” [RFC7231]Each representation is encoded in a format that is identified by its media type.ResourceIn the most general sense a resource is something that is addressable by a URI. [RFC3986] says the following about resources:“This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI. Familiar examples include an electronic document, an image, a source of information with a consistent purpose (e.g., "today's weather report for Los Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a collection of other resources. A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources. Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., "parent" or "employee"), or numeric values (e.g., zero, one, and infinity).” [RFC3986]Resource GroupA resource group is a collection of resources that may or may not have structure. Request TargetIn a direct request to an origin server this is the Absolute-Path and Query Components of the Target-URI. For a more detailed description see [RFC7230, Section 5.3]< >].Target URIThe absolute form of the URI reference in a request. It is typically used as an identifier for the “Target Resource”. The Target URI excludes the fragment component.A URI reference (Section 2.7) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order to obtain the "target URI".Target ResourceA resource located on an origin server that is the Target of a request. A URI reference is typically used as an identifier for the “target resource”, that is the resource(s) that is referenced in the URI of an HTTP request.Target URIThe absolute form of the URI in an HTTP request.Status CodeUniform Resource IdentifiersThe HTTP standard uses Uniform Resource Identifiers (URIs) to reference or address resources accessible on the World Wide Web (WWW). The syntax of URIs is defined in [RFC3986]. A URI is composed of the following components:Absolute-URI= <absolute-URI, see [RFC3986], Section 4.3>Relative-part <relative-part, see [RFC3986], Section 4.2>Scheme = <scheme, see [RFC3986], Section 3.1>Authority = <authority, see [RFC3986], Section 3.2>Uri-host = <host, see [RFC3986], Section 3.2.2>Port = <port, see [RFC3986], Section 3.2.3>Path-Abempty = <path-abempty, see [RFC3986], Section 3.3>Segment = <segment, see [RFC3986], Section 3.3>Query = <query, see [RFC3986], Section 3.4>Fragment = <fragment, see [RFC3986], Section 3.5>Absolute-path = 1*( "/" segment ) < = relative-part [ "?" query ] < >URI-reference See [RFC3986, Section 4.1].User AgentAny of the various client programs that initiate a request, including (but not limited to) browsers, spiders (web-based robots), command-line tools, custom applications, and mobile apps. See RFC-7230 Section 2.1 Client/Server Messaging.Other TermsUTF-8The Unicode Standard, "Chapter 2. General Structure". The Unicode Standard (6.0 ed.). Mountain View, California, USA: The Unicode Consortium. ISBN 978-1-936213-01-6. and Abbreviated TermsDICOMDigital Imaging and Communications in MedicineHL7Health Level SevenHTMLHyperText Markup LanguageHTTPHyperText Transfer ProtocolHTTP/1.1Version 1.1 of the HyperText Transfer ProtocolHTTP/2Version 2 of the HyperText Transfer ProtocolHTTPSHyperText Transfer Protocol SecureHTTPS/1.1Version 1.1 of the HyperText Transfer ProtocolHTTPS/2Version 2 of the HyperText Transfer ProtocolIHEIntegrating the Healthcare EnterpriseMIMEMultipurpose Internet Mail ExtensionsMTOMMessage Transmission Optimization MechanismQIDO-RSQuery based on ID for DICOM Objects by RESTful ServicesRESTRepresentational State TransferRESTfulA w RESTful Web service is RESTful if it is a Web service implemented using the REST architecture and principles. and HTTP (see )RS ProtocolThe RESTful web service protocol defined in Section 9 of this document.SOAPSimple Object Access Protocol (SOAP12 for SOAP version 1.2)SOPService Object PairSTOW-RSSTore Over the Web by RESTful Services. This term is retired. This is now called the RS Store Transaction.UIDUnique (DICOM) IdentifierUPS-RSThe RS Unified Procedure Step by RESTful ServiceURI/URLUniform Resource Identifier / LocatorURI ProtocolThe protocol defined in Section 7 of this document.WADLWeb Application Description LanguageWADO-RSWeb Access to DICOM Objects by RESTful ServicesWADO-URIWeb Access to DICOM Objects by URIWADO-WSWeb Access to DICOM Objects by Web Services (WS*)WS ProtocolThe protocol defined in Section 8 of this documentWSDLWeb Services Description LanguageXMLeXtensible Markup LanguageXOPXML-binary Optimized PackagingDICOMweb OverviewClosed Issues#IssuesOpen Issues#IssuesStatusShould we define our own DICOMweb “reason phrases”?OpenEditorial Issues#IssuesStatusIt seems to be common practice to use relative URI (starting with ‘/’) to describe resource templates. This would eliminate {+svc} everywhere. Should we make this change?OpenWhat should the format of the Status Code table be? Is it enough to include it here?YesClosed[add a statement about the goals and history of DICOMweb]DICOMweb Use ofs HTTP (Informative)When used in this document the term HTTP and HTTP Standard refers to the family of HTTP protocols including: HTTP/1.1, HTTPS/1.1, HTTP/2 and HTTPS/2, as defined by the relevant IETF RFCs.The DICOMweb Standard is defined on top of the HTTP and DICOMweb transactions are defined in terms of HTTP messages. The HTTP standards are normative for all aspects of message content and transmission. In there are any conflicts between the DICOMweb Standard and the HTTP standards the HTTP standards are normative.DICOMweb Protocols, Services, and TransactionsThe DICOMweb protocols are all built on top of the HTTP and HTTPS protocols. Throughout this document the term ‘HTTP’ will be used to denote either HTTP or HTTPS along with any version of these protocol supported by DICOMweb protocols.The DICOMweb Standard defines three different web protocols: URI, WS, and RS. Each protocol is named for the type of web services protocol that it uses in its implementation. Each protocol defines one or more services. Each service operates on a set of well-defined resources, called a resource group. Each service defines a set of transactions that operate on its resources.The URI protocol is the oldest protocol. It first became part of the Standard in 20XX. The URI protocol gets its name from the fact that its transactions are all based on the query component of the URI in its request messages. The URI protocol implements one eponymous service that retrieves representations of its resources, which are all DICOM SOP Instance. The URI service defines three transactions that retrieve 1) DICOM representations, 2) rendered representations, and 3) rendered representations of presentation state SOP instances.The WS protocol is a much newer protocol. It first became part of the Standard in 20XX. The WS protocol gets its name from the fact that its transactions are all based on the WS-I Web Services Interoperability stack and in particular on the Simple Object Access Protocol (SOAP). The WS protocol was created to provide a DICOM interface to the IHE XDS-I.b medical imaging standard. The WS protocol also implements one eponymous service that retrieves representations of its resources, which are DICOM Studies and their substructure. The WS service defines three transactions 1) Retrieve Document Set, 2) Retrieve Rendered Document Set, and 3) Retrieve Document Set Metadata.The RS protocol is the newest protocol. Its first service became part of the Standard in 2012. The RS protocol endeavors to define RESTful Services, hence its name. The RS protocol currently defines a Storage Service and a Worklist Service. Each of these services have numerous transactions. The Storage Service not only defines retrieve transactions, but also store, search, and capabilities transactions. The Worklist Service also defines an extensive set of transactions.ResourcesThis Part of the Standard does not limit the scope of resources; rather, the term "resource" is used in a general sense for whatever might be identified by a URI. Most of the resources defined by this Part of the Standard are either DICOMweb services or Information Objects defined by the DICOM Information Model. See PS3.3, Section 6. A resource may contain sub-resources.In this standard, as with HTTP in general, resources are referenced by URIs. DICOMweb services are focused on two principle resources: studies and work lists.The studies resource is collection of DICOM studies, where each study contains one or more series and each series contains one or more instances. An instance resource might be a single or multi-frame image, a presentation state, a structured report, etc.A worklist resource contains work item resources.Studies, Series, Instance, and Frame List ResourcesRepresentationsResources are encoded as representations. A representation is a concrete data object that contains…DICOMweb defines three different types of representations: SOP Instances, Metadata, and Bulkdata. SOP InstancesThe DICOMweb unit of communication is the Composite SOP Instance, which is a concrete occurrence of an Information Object. Throughout Part 18 the term instance means Composite SOP Instance unless stated otherwise. Instances can be stored and retrieved. See PS3.3.Each instance contains attributes from the patient, study, series, and instance level. For example, if a series resource contains 12 instances, then a transaction that retrieves that series will contain the representations of 12 instances, and each instance will contain patient, study, series, and instance level attributes.An Attribute is an abstract concept that has a 1) Semantic Identifier, which defines its semantic meaning, 2) a Type, which defines rules for whether the attribute is required in an Information Object, 3) a Value Representation, which defines the data type of the values, and a Value Multiplicity, which defines the number of value(s) that an Attribute Representation may contain.A Data Element is a concrete representation of an attribute. Data Elements have a Tag that is an encoding of the Semantic Identifier, possibly a Value Representation Code, and a value (See PS3.5Each attribute has a Tag, which defines the semantic meaning of the attribute, a Value Representation, which defines its data type, and a value, which is an octet stream, that is a sequence of bytes.Normalized SOP InstanceComposite SOP InstanceMetadata, and Bulkdata ResourcesMost attribute values are small, but some, such as images or video, can be quite large. In order to improve communication efficiency an Instance can be decomposed into metadata and bulkdata.MetadataA metadata instance contains all the attributes of the Instance, except that for certain value representations, any values that are larger than an origin server defined threshold, may be moved into a bulkdata object, with the attribute value being replaced by a URI that references it, called the BulkdataURL. The Bulkdata URI references the associated bulkdata value.The value representations whose values can be moved to bulkdata are: FL, FD, IS, LT, OB, OD, OF, OW, SL, SS, ST, UL, UN, US, and UT.BulkdataA bulkdata instance contains all the bulkdata, i.e., large values, that have been removed from the related metadata instance.The metadata should be consistent with the characteristics of the bulkdata on the server. If bulkdata is requested using specific transfer syntaxes or media types, it is possible that the bulkdata retrieved may be inconsistent with the metadata. For example, a request to retrieve a Study whose Tag (0028,2110) "Lossy Image Compression" is set to "00", indicating no lossy compression, with a lossy compression media type will provide pixel data that is inconsistent with the metadata. It is the responsibility of the client to deal with these inconsistencies appropriately.Note1.The server is not required to replace any attribute with a BulkdataURL.2.For media types that do not allow binary values, binary values are Base64 encoded.3.Some DICOM instances, such as work items, may not allow bulkdata conversion. 4.While metadata and bulkdata are currently defined as resources, they are more appropriately media types and are expected to be define as such in the near future.DICOMweb Transactions and SyntaxDICOMweb transactions are defined in terms of HTTP request/response message pairs.Messages are defined using the ABNF Grammar defined in [RFC7230, Section 1.2]. This includes the list extension ‘#’ defined in [RFC7230, Section 7], that allows for compact definition of comma-separated lists using a '#' operator (similar to the '*' operator that indicates repetition).Request and Response Message FormatAll DICOMweb request messages have the following format:method SP {/resource}{?query*} SP version CRLF*header-field? CRLF? CRLF[payload]Method ? {/resource}{?query*} ? version ?*header-field ??[payload]And all response messages have the following format:version ? status-code ? reason-phrase?*header-field ??[payload]Where,methodis the HTTP method (such as GET, POST, etc.);resourceis relative URI that specifies the path to the target resource, where the base URI is the absolute URI of the service;queryis the query component, which specifies zero or more query parameters (see [ref]);versionis the version of the HTTP protocol being used.header-fieldspecifies the header-fields, separated by CRLF.[payload]is the, possibly empty, payload.version is the version of the HTTP protocol being used.status-code is a 3 digit integer encoding the type of the response.reason-phrase is a short description of the response status.The terms defined above will be used throughout the rest of this standard when specifying request message formats.Syntactic variables are lowercase. Literal characters in the format are in bold face, parameters are specified using URI Templates. The symbol ‘?’ stands for the US-ASCII space (0x20) literal character, and ’?’ stands for the ASCII carriage return (0xD) and line feed (0xA) literal characters.Resource targets are specified as URI TemplatesNone of the protocols or services defined by the DICOMweb Standard use the Fragment Component of the request URI.Target URI format:Absolute:{scheme}://{server}{/service}{/resource}{?query}{&more}Relative:/ or {/resource}{?query}{&more}Request MessagesThe syntax of request messages is:version ? status-code ? reason-phrase?*header-field ??[payload]The following sections explain the parts of the request message in detail.MethodsThe request method is one of the HTTP methods, such as GET, POST, etc.Target-URI SyntaxIn this standard, as with HTTP in general, resources are referenced by URIs. Their structure is defined using URI Templates as defined in [RFC6570]. Each service defines the resources it manages and URI templates used to reference them.Each request contains a Target-URI. The following URI template variables are used throughout the standard when describing the target URI of a request message:{/resource}The path to the resource?{query}One or more required query parameters{?query} / {?query*}Zero or more query parametersQuery Parameters and Their Syntax (Normative)DICOMweb requests may use the query component of the target-URI to specify parameters. Parameters are ‘name=value’ pairs. The ‘name’ start with an alphabetic or underscore character, followed by zero or more alphanumeric or underscore ‘_’ characters. The parameter may have one or more comma-separated values. Values are composed of any legal query character as defined by [RFC3986], except equal ‘=’, ampersand ‘&’ and comma ‘,’.For example:?deidentify&cols=512&region=10,10,500,500The following grammar defines the general syntax of parameters contained in the query component of the URI. Specific HTTP transactions defined elsewhere in this standard may further refine the legal <name> and/or <value> rules.query = parameter [ *("&" parameter) ]parameter = name "=" #value / attribute “=” #attribute-valuename = 1*(ALPHA / “_” ) *( ALPHA / DIGIT / "_")value = *vchar [ *(“,” *vchar) ]attribute = keyword [ *( “.” attribute ) ] / tag [ *( “.” attribute) ]keyword = Data Element Keyword from PS3.6, Table 6-1tag = Data Element Tag from PS3.6, Table 6-1vchar = unreserved / pct-encoded / vspecial / ":" / "@"vspecial = "!" / "$" / "'" / "(" / ")" / "*" / "+" / ";" / “/” / “?”Where these rules are from [RFC3986]:unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"pct-encoded = "%" HEXDIG HEXDIGAnd these rules are from [RFC5234]:ALPHA = %x41-5A / %x61-7A ; A-Z / a-zDIGIT = %x30-39 ; 0-9HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"Each query parameter is composed of either a <name> and one or more <values> or an <attribute> and one or more <attribute-values>.<name>s start with a letter or underscore ‘_’, followed by zero or more letters, digits, or underscores. If a parameter has multiple values they are separated by a comma. Multiple parameters are separated by the ampersand ‘&’ character.The encoding of the <value> above shall be defined by the media type.Note1.No whitespace is permitted in URIs. Whitespace around line breaks and the line breaks themselves should be stripped before parsing the URI (See RFC 3986 Appendix C).2.RFC 3986 does not permit an empty query component, i.e. if the "?" appears in the URI then there must be some legal query parameters in the URI.3.The <vchar> rule (value characters rule) defined above is the <query> rule of RFC 3986, which defines the legal character for the query component, except for the equal ‘=’, comma ‘,’ and ampersand ‘&’ characters.Query Parameter SpecificationsAll query parameters are strings. Their format is <name>=<values>, where value is specified using a URI template. For example, the “viewport” parameter is specified as:viewport = {rows, columns}where rows and columns are positive integersHere rows and columns in the URI template are variable names for parameter values.The parameter definition should include:The type of value the string represents, how it is parsed, and what characters are legalThe minimum and maximum length of the stringHow many values the parameter may haveThe range of the value(s)Their format is specified using URI templates.Table 6.3-X defines standard names for parameter value types. Parameter definitions use these names to specify the constraints on the value type. Table 6.3-X: Query Parameter Value TypesValue TypeConstraintDescription#type, lengthA comma-separated list containing <type> values, with max length.attributeSee the ABNF for attribute parameters below.binarylengthA Base64 encoded stringdecimalrangeA string specifying a decimal number, with maximum length 64.integerrangeA string specifying an integer, with a maximum length 12keywordSee below.tagvalid tagSee below.namecharset, lengthA token, as defined by HTTP, used to specify the type of a uidValid, lengthA string containing a valid UID, with maximum length 64uuidValidA string containing a valid uuid [ref]32 lowercase hexadecimal digits, displayed in 5 groups separated by hyphens in the form (8-4-4-4-12). For example: 123a4567-b89b-98c7-d654-3210fedcba98All parameters and their values must be strings; however, the values represented are not necessarily strings. Table X.Y-z contains the conversion rules for non-string data types.Data TypeEncoding RuleDecoding RuleBinary attribute values: OB, OD, OF, OW, UNQuery parameter values shall not be padded to an even length with a NULL character.Request Header Fields (Informative)This section describes the header-fields that are typically used by DICOMweb messages.Content Negotiation Header FieldsAll DICOMweb requests that expect to receive a response containing a payload shallshould provide an Accept header field [ref ].AcceptUser agents use the Accept header field to specify a list of media types that are acceptable in the response payload. See [RFC7231, Section 5.3.2]. Any request that expects a response should shall specify an Accept header field with one or more media types.The media types in the Accept header can be given a priority ordering by using Quality Values. See [RFC7231, Section 5.3.1].DICOMweb has extended this header field for DICOM media types to include an optional transfer syntax parameter. See [ref media types]. Accept-EncodingThe Accept-Encoding header field is used by user agents to specify a list of content encodings [RFC7231, Section 3.1.2.1< ;] that are acceptable in the response payload.User agents use the Accept-Charset header field to specify a list of character set names that are acceptable in the response payload. See [RFC7231, Section 5.3.3].Character set names are case-insensitive. The user agent shall use IANA Character Set Names if defined in the [IANA Character Sets registry].Annex XX lists DICOM character sets with links to their corresponding names in the IANA Character Set registry.Note1.Since most media types, including application/dicom+xml, and application/json have a default character set of UTF-8, the Accept-Charset header field is rarely used.2.Many media types specify a ‘Charset’ parameter that can be used to specify the character set used with the media type.Content Negotiation Header ParametersAll DICOMweb requests that expect to receive a response containing a payload might also provide one or more of the following content negotiation header parameters. Quality Valueq={x} where 0.0 < X <= 1.0Many of the request header fields for proactive negotiation use a common parameter, named "q" (case-insensitive), to assign a relative "weight" to the preference for that associated kind of content. This weight is referred to as a "quality value" (or "qvalue") because the same parameter name is often used within server configurations to assign a weight to the relative quality of the various representations that can be selected for a resource. See [RFC7231, Section 5.3.1].CharsetMany media types, especially text/* types, define a Charset parameter that specifies the character set for the representation.Content RepresentationThe header fields described in are used to specify the representations contained in the payload of a message. All messages that contain a payload should include the following header fields:Content-TypeThe Content-Type header field is used to specify the media type of the payload. If a DICOMweb message has a payload it shall have a Content-Type header field. Depending on the media type this header field may not fully specify the contents of the payload. See [RFC7231, Section 3.1.1.5]].The following header field should be included…Content-LocationThe Content-Location header field contains a URI reference to the resource that corresponds to the representation in the payload. See [RFC7231, Section 3.1.4.2].The following header field shall be present when the message contains a payload and does not have a Transfer-Encoding header field.Content-LengthThe Content-Length header field specifies the length of the payload or of an anticipated payload as a decimal number of octets. It shall be included when a message does not have a Transfer-Encoding header field. [ref]For messages that do not include a payload body, the Content-Length indicates the size of the selected representation. See [RFC7231, Section 3].The following optional header fields are used to specify information about the encoding of the payload: Content-EncodingThe "Content-Encoding" header field indicates what transfer encodings have been applied to the representation contained in the payload, beyond those inherent in the media type, and thus specify what decoding mechanisms have to be applied in order to obtain data in the media type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a representation's data to be compressed without losing the identity of its underlying media type. See [RFC7231, Section 3.1.2.2].Content-LanguageThe "Content-Language" header field describes the natural language(s) of the intended audience for the representation. It is recommended that any message with a payload include this header field. See [RFC7231, Section 3.1.3.2]. For example,Content-Language: en-USThere are no requirements for language negotiation in DICOM.Transfer Syntax Parameters for Content Negotiation and -Representation Header FieldsOrigin servers that implement the RS protocol shall be prepared to handle transfer syntax parameters for all imaging media types. The syntax is:media-type; transfer-syntax={transfer-syntax}For example, an Accept header field might look as follows:Accept: application/dicom; transfer-syntax=1.2.840.10008.1.2.4.70Request PayloadThe message body (if any) of an HTTP message is used to carry the payload body or payload of that message. The message body is identical to the payload unless a transfer coding has been applied, as described in [HYPERLINK "C:\\Users\\jfp\\Documents\\DICOM\\WG-27\\Supplements\\Re-Doc Part 18\\RFC7230, Section 3.3.1" HYPERLINK "RFC7230, Section 3.3.1" RFC7230, Section 3.3.1]. This standard uses the terms payload, payload body, and message payload interchangeably to denote the message body before any transfer coding has been applied to it.All messages have payloads, but the payload may be empty, i.e. length = zero.The rules for when a payload is allowed in a message differ for requests and responses.The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field.The presence of a message body in a response depends on both the request method to which it is responding and the response (status code)< >.BehaviorEach DICOMweb transaction definition includes a Behavior Section that describes processing that occurs on the origin server based on the format and contents of the request message, including the method, parameters, and especially the target resource(s). It also describes the format and representation(s) contained in the response message.The origin server shall return an error response if it cannot satisfy the request.Response Message FormatThe syntax of a response message is:version ? status-code ? reason-phrase?*header-field ??[payload]Where the syntactic variables are defined in Section X.Y.The following sections explain the response message components in detail.Status Codes (Informative)A status-code is a three-digit integer that encodes the result of the origin server’s attempt to understand and satisfy the request. The HTTP/1.1 Standard says:“HTTP status codes are extensible. …The reason phrases listed here are only recommendations -- they can be replaced by local equivalents without affecting the protocol.”[RFC7231]The first digit of the status-code defines the class of the response. Table 6.4-1 shows the five classes that have been defined.Table 6.4-x: Status Code ClassesClassMeaning1xx: InformationalRequest received, continuing process2xx: Success The action was successfully received, understood, and accepted3xx: RedirectionFurther action must be taken in order to complete the request4xx: Client ErrorThe request contains bad syntax or cannot be fulfilled5xx: Server ErrorThe server failed to fulfill an apparently valid requestThe following table, which contains the status codes defined by the HTTP Standard, is informative. It is copied from the IANA HTTP Status Code Registry, which is normative.Table 6.4-1: HTTP Status Codes Used by PS3.18Value?Description?CRUDQOReference?100ContinueX[RFC7231, Section 6.2.1]101Switching ProtocolsX[RFC7231, Section 6.2.2]102Processing[RFC2518]103-199 Unassigned200OKXXX[RFC7231, Section 6.3.1]201CreatedX[RFC7231, Section 6.3.2]202AcceptedXX[RFC7231, Section 6.3.3]203Non-Authoritative Information[RFC7231, Section 6.3.4]204No ContentX[RFC7231, Section 6.3.5]205Reset Content[RFC7231, Section 6.3.6]206Partial ContentXXXX[RFC7233, Section 4.1]207Multi-Status[RFC4918]208Already Reported[RFC5842]209-225 Unassigned226IM Used[RFC3229]227-299 Unassigned300Multiple Choices[RFC7231, Section 6.4.1]301Moved PermanentlyXXXX[RFC7231, Section 6.4.2]302Found[RFC7231, Section 6.4.3]303See Other[RFC7231, Section 6.4.4]304Not Modified[RFC7232, Section 4.1]305Use Proxy[RFC7231, Section 6.4.5]306 (Unused)[RFC7231, Section 6.4.6]307Temporary Redirect[RFC7231, Section 6.4.7]308Permanent Redirect[RFC7238]309-399 Unassigned400Bad RequestXXXXXX[RFC7231, Section 6.5.1]401UnauthorizedXXXXXX[RFC7235, Section 3.1]402Payment Required[RFC7231, Section 6.5.2]403ForbiddenXXXXXX[RFC7231, Section 6.5.3]404Not Found[RFC7231, Section 6.5.4]405Method Not AllowedXXXXXX[RFC7231, Section 6.5.5]406Not AcceptableXXXXXX[RFC7231, Section 6.5.6]407Proxy Authentication RequiredXXXXXX[RFC7235, Section 3.2]408Request TimeoutXXXXXX[RFC7231, Section 6.5.7]409Conflict[RFC7231, Section 6.5.8]410GoneXXX?X[RFC7231, Section 6.5.9]411Length RequiredXX?[RFC7231, Section 6.5.10]412Precondition Failed[RFC7232, Section 4.2]413Payload Too LargeXX[RFC7231, Section 6.5.11]414URI Too LongXXXXXX[RFC7231, Section 6.5.12]415Unsupported Media TypeXXXXXX[RFC7231, Section 6.5.13]416Range Not Satisfiable[RFC7233, Section 4.4]417Expectation Failed[RFC7231, Section 6.5.14]418-421 Unassigned422Unprocessable Entity[RFC4918]423LockedXXXXXX[RFC4918]424Failed Dependency[RFC4918]425 Unassigned426Upgrade Required[RFC7231, Section 6.5.15]427 Unassigned428Precondition Required?[RFC6585]429Too Many RequestsXXXXXX[RFC6585]430 Unassigned431Request Header Fields Too LargeXXXXXX[RFC6585]432-499 Unassigned500Internal Server ErrorXXXXXX[RFC7231, Section 6.6.1]501Not ImplementedXXXXXX[RFC7231, Section 6.6.2]502Bad Gateway?[RFC7231, Section 6.6.3]503Service UnavailableXXXXXX[RFC7231, Section 6.6.4]504Gateway TimeoutXXXXXX[RFC7231, Section 6.6.5]505HTTP Version Not SupportedXXXXXX[RFC7231, Section 6.6.6]506Variant Also Negotiates[RFC2295]507Insufficient StorageXXXXXX[RFC4918]508Loop Detected[RFC5842]509 Unassigned510Not Extended[RFC2774]511Network Authentication Required[RFC6585]512-599 UnassignedKeys to abbreviated column heading in Table x.y above:CodeTransaction TypeCCreate new resourcesRRetrieve resourcesUUpdate existing resourcesDDelete resourcesQSearch for resourcesOOther (Change State, Upgrade)The most common HTTP status codes used by RS services are listed in Table 9.4-1. IANA maintains the HTTP Status Code Registry, which contains a complete list of registered status codes.Table 9.4-X: Response Status CodesCode PhraseDescriptionSuccess – the 2xx class of status codes indicates that the client's request was successfully received, understood, and accepted.200OKIndicates that all target resource representations are contained in the payload.201CreatedIndicates that the request has been fulfilled and has resulted in one or more new resources being created.202AcceptedIndicates that the request has been accepted for processing, but the processing has not been completed. The user agent can use a 203Non-Authoritative InformationIndicates that the request was successful but the enclosed payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy. See [RFC7230], Section 5.7.2.204No-ContentIndicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. This should be the response when content is successfully uploaded and the response has no payload.205Reset ContentIndicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server. This code could be returned in response to a Worklist Service Create Work Item request.206Partial ContentIndicates that some, but not all, of the target resource representations are contained in the payload.This could be because the origin server does not support the media types, transfer syntaxes for some but not all requested content.The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.400Bad RequestIndicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request …). Also indicates that no instances were stored due to bad message syntax.401UnauthorizedIndicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resourse.403ForbiddenIndicates that the origin server understood the request, but refused to authorize it (e.g., an authorized user with insufficient privileges). If authentication credentials were provided in the request, the server considers them insufficient to grant access.404Not FoundIndicates that the origin server did not find a representation for the target resource or is not willing to disclose that one exists. This might be a temporary condition. If the origin server knows that the resource has been deleted the 410 (Gone) status code is preferred over 404.405Method Not AllowedIndicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.406Not AcceptableIndicates that the target resource does not have a representation that would be acceptable to the user agent, according to the content negotiation header fields in the request, and the server is unwilling to supply a default representation.The server SHOULD generate a payload containing a list of available representation characteristics (media types) and corresponding resource identifiers from which the user or user agent can choose the one most appropriate.409ConflictIndicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.This code might Indicate that the origin server was unable to store any instances due to a conflict in the request (e.g., unsupported SOP Class or SOP Instance mismatch).I410GoneIndicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) ought to be used instead.411Length RequiredIndicates that the server refuses to accept the request without a defined Content-Length.413Payload Too LargeIndicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process.414URI Too LongIndicates that the server is refusing to service the request because the request-target (Section 5.3 of [RFC7230]) is longer than the server is willing to interpret.415Unsupported Media TypeIndicates that the origin server does not support the Content-Type in the request payload.The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.500Internal Server ErrorIndicates that the server encountered an unexpected condition that prevented it from fulfilling the request.501Not ImplementedIndicates that the server does not support the functionality required to fulfill the request.503Service UnavailableIndicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.505HTTP Version Not SupportedIndicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message.Response Header FieldsThis part of the service descriptions defines the header fields that are required, conditionally required, or optional in the response.If the response has a payload some or all of the Representation Metadata header fields (see [ref]) should be present.General with PayloadContent-TypeContent-LocationContent-LengthResponse PayloadThe presence of a payload in a response depends on both the request method to which it is responding and the response (status code)< >.Status Details Payload for Responses with IssuesWe need a general mechanism for sending Status Details for the case where a transaction is either partially successful or has failed. We propose to use the ideas in “Status Details for HTTP APIs [See ].The format of this payload should be defined by the media type.We should define JSON, XML, and HTML versions. HTML would be the default if not defined by the media typeFor example, a HTTP response carrying JSON Status Details:HTTP/1.1 403 ForbiddenContent-Type: application/problem+jsonContent-Language: en{ "type": "", "title": "You do not have enough credit.", "detail": "Your current balance is 30, but that costs 50.", "instance": "", "balance": 30, "accounts": ["", ""]}PayloadsBoth requests and responses can have payloads. Messages that have a payload typically have Payload-Related Header FieldsPayload- Related Header FieldsContent-LengthContent-RangeTrailerTransfer-EncodingContent-Type and Content-Location header fields. There are two basic payload structures: single part and multi-part.Payload FormatSingle Part PayloadA single part payload contains one representation that is described by the content header fields, i.e., Content-Type, Content-Length, Content-Location, etc. The Content-Type header field shall have a single part media-type. [ref]Multi-Part PayloadA multi- part payload contains one or more representations, the first representation is described by the content header fields of the message. The Content-Type header field shall have a multi-part media-type such as:content-type: multipart/related; type={root-media-type}; boundary=“---boundary---”Where,multipart/relatedis a media type defined by [RFC2387 <;].root-media-typeis a single part media type that specifies the media type of the root, typically the first part, in the payload. If the value of the type parameter and the root body part's content-type differ then the User Agent's behavior is undefined.boundaryspecifies a string that acts as a boundary between message parts.Each part starts with the boundary followed by a carriage return and line feed (?).Each part in a multi-part payload contains one or more header fields followed by a representation in the media type specified by the Content-Type header. Each part in a multi-part payload shall start with a boundary string, followed by Content-Type and Content-Location header fields, followed by either a Content-Length or a Transfer-Encoding header field, optionally followed by a Content-Description header field.The syntax of a multipart payload is defined as follows:Message Header Fields:Content-Type: Multipart/Related; type=”application/dicom”; boundary={---boundary---}?Content-Location: {service}/studies/012}/series/345/instance/678?Note: The type parameter is either a token or a quoted-string; however, if the type parameter contains any non-token characters it must be a quoted-string. Since type parameters typically contain a slash ‘/’, they are almost always quoted-strings.Multipart Payload Format:{---boundary---}?Content-Type: “application/dicom”?Content-Location: {service}/studies/012}/series/345/instance/678?Content-Description: PS3.10 SOP Instance??{payload}?{---boundary---}?Content-Type: “application/dicom”?. . .Figure 9.2-1: Mapping between IOD and Multi-Part PayloadRepresentations and Media TypesDICOM Instances, whether SOP, metadata or bulkdata can be represented using binary, XML, or JSON.Each Protocol and/or Service defines the representations and media types that are required and recommended. They may also defined the default media type.The media type also specifies whether the payload contains a single representation (single part), or multiple representations (multipart). Multipart payloads are only defined for the RS Protocol. See Section 9.4.4.2.Internet media types [RFC2046] are the basis for both content negotiation and data typing of message payloads. A media describes the format of a representation of a resource. Each DICOMweb service has a set of media types that it supports.HTTP uses the Content-Type [RFC 7231, Section 3.1.1.5] and Accept [RFC7231, Section 5.3.2] header fields, for content negotiation and data typing.Representation CategoriesA media type identifies the format of a representation of a resource. Media types are the values of the Accept header field and the Content-Type header field.The media types in the Accept header field(s) define the media types that are acceptable to the user agent in the response.The media type in the Content-Type header field of a message, or payload part, describes the format of the representation contained in the payload of that message or part. This standard categorizes media types based on the SOP classes in PS3.3. A target resource’s category depends on its SOP class. The categories are:Non-RenderedNative DICOM InstancesComposite nstancesThe Native category corresponds to all composite SOP classes encoded as defined by this Standard. These media types are used for representations of Information Entities defined by this Standard. Any DICOM resource can have a DICOM representation using a DICOM media type. The DICOM media types are defined in Annex X.DICOM Normalize InstancesDICOM encapsulated CDACDA encapsulated DICOMCDANon services are defined for these at this time.RenderedSingle Frame Image Pixel DatasThe single frame image resource category corresponds to SOP classes defined in PS3.3 that consist of a single image frame, instances of multi-frame SOP Classes that contain only one frame, or consist of single frame accessed using a Frame Number parameter.These media types are used for rendered representations that contain a single image.Multi-Frame Image Pixel DataThe multi-frame image resource category corresponds to SOP classes defined in PS3.3 that are multi-frame or video image instances. These instances may have representations in either a DICOM media type or in one of the rendered multi-frame media types. Non-DICOM DocumentsThe textual resource category includes all SOP classes defined in PS3.3 that include the SR Document Content Module. This includes documents, such as narrative text or unencapsulated PDF., structured reports, CAD, measurement reports and key object selection documents.Implementers are strongly encouraged to support a textual media type that is in conformance with HL7 CDA R2, e.g., text/xml.Non-Image DiCOM InstancesOtherThe Other resource category includes all Composite SOP Classes that are not included in the categories above. Only DICOM media types are required for this category. Any appropriate media type may be used for rendered representations of these resources.The origin server shall support all default and required media types for a particular protocol, i.e., URI, WS or RS. The origin server may also support other media types not listed here.Media Type SyntaxThe syntax of media types is as follows:NameRulemedia-type= type "/" subtype *( OWS ";" OWS parameter )type = tokensubtype = tokenparameter = name “=” valuename= tokenvalue= (token / quoted-string)Where, the parameters are optional and are typically defined by the media <type/subtype>. The type, subtype, and parameter name tokens are case-insensitive. Parameter values may or may not be case-sensitive, depending on the semantics of the parameter name.Note:Unlike some similar constructs in other header fields, media type parameters do not allow whitespace (even "bad" whitespace) around the "=" characterSee [RFC7231, Section 3.1.1.1] for more information of HTTP use of media types. See Annex XX for detailed explanations of DICOMweb media types.Standard Transaction TypesThe format of a transaction’s request and response message can be characterized by the transaction’s type. The following Transaction Types are typical of the services defined in this Part of the Standard. Whether a request or response has a payload depends on the type of transaction, including the request method, target resource, and parameters. Table X.Y-Z below defines the methods and payloads used by the various services and their transactions. The response payload column is for successful responses only.Table X.Y-Z: Transaction PayloadsTransaction TypeMethodRequestPayloadResponse PayloadDescriptionCreatePOSTRepresentation(s)Empty or SDDCreates a new resource from the representation in the request payload.RetrieveGETEmptyRepresentation(s) or SDDRetrieves a representation of a resource, contained in the response payload.UpdatePUTRepresentation(s)Empty or SDDUpdates a resource using the representation contained in the request payload.DeleteDELETEEmptySDDdeletes a resourceSearchGETEmpty or ParametersRepresentation(s) or SDDSearches a resource using the search criteria in the request and returns zero or more representations of matches.Capabilities Subservice TransactionCapabilitiesOPTIONSEmptyCapabilities Descriptionor SDDRetrieves a Capabilities Description Document from a service.Notification Subservice NotificationsOpen ChannelGETSDDSend Event?Create SubscriptionPOST?SDDDelete SubscriptionDELTETESDDThe term ‘SDD’ in the Response Payload column refers to the Status Details Document that should be returned in all error responses. See Section X.Y.SecurityThis standard does not introduce any security-related requirements. It is likely that the information contained within DICOM objects identifies the patient. HTTPS can be used to protect information in transit. The underlying DICOM implementation decides whether or not to grant access to a particular DICOM object based on whatever security policy or mechanism it has in place. A server is unlikely to fulfill a request from an unknown user (e.g., accessed via the HTTP protocol) unless it is certain that the data requested has no Personally Identifying Information [ref] within it and has been approved for public viewing.DICOMweb Service DescriptionsEach service defined in this standard is described according to the following structure:ServiceA general description of the serviceResourcesA description of the resources that can get the target of this transaction along with URI-templates.TransactionsAn overview of the transactions defined by the service.One or more Transaction DescriptionsOne or more Transaction Descriptions in the following format:Transaction OverviewTarget resources for this transactionThe request:Resource pathQuery parametersHeader fieldsRequest payloadA descriptions of the request payload, if anyThe behavior of the origin server on receiving the request; processing it and creating the response.The response:Status codesHeader fieldsResponse PayloadMedia types A brief description of media types supported by this transaction, along with references to the appropriate Annex.A brief description of any media types that Media types supported by this serviceA brief description of media types supported by this service, along with references to the appropriate Annex.URI Protocol (WADO-URI)Closed Issues#IssuesOpen Issues#IssuesStatusWhat should the maximum value for ‘rows’ and ‘columns’ parameters be?What should the range of ‘windowCenter’ and windowWidth be? refStatus codes for URI have not been defined in the past. Should they be? If so, does it need a CP?Have browsers advanced enough that we can specify the grayscale and color space? Should blending PSes be permitted. Yes, since they were not previously specified to not be included?. Problems with current: 1) if you get an image without specifying the window and level you do not know what the windowing is and therefore you can apply adjustments. Potential solutions return the image and information about how it was rendered, i.e. a json presentation state in a multipart payload. 2) Want multiples images in a payload. The request and return would need to handle presentation states for each image. Can we use a Content-Disposition header? Number, time, location, phase.Am I working at the image level or at the frame level?Editorial Issues#IssuesStatusShould Content-Location be optional for this service? Yes, If the Target URI is the same as the target resource URI, then the Content-Location header field should be omitted; otherwise, the Content-Location header field should be included.ClosedWhat are the bounds on Window Center and Width values?Should the URI Media Types table be included in 7.2.4? This would mean including the same table in section 8.2.4.Yes, then when URI is retired no change will need to be made to WSClosedFor region, would xMin, yMin, xMax, yMax be better names?If the region specified by the parameter is ill defined should it be an error or should the original image size be returned, i.e. as if there were no region argument.URI: return original image size;WS: return original image size,RS: return an error.ClosedWhat order should the rendering parameters be presented in? Pipeline? Alphabetic?Suggest pipeline order, first, then alphabetical.Should we use and {object-id} query parameter instead of {requestType=WADL, study_uid, series_uid, object_uid}?No, Use all four parameters.ClosedTable X.Y-Z: Query Parameters by TransactionParameterRetrieve InstanceDICOMRenderedPresentationStateanonymizeXframeNumberXregionXrowsXXcolumnsXXwindowCenterXwindowWidthXannotationXXimageQualityXX URI Service[explain why it is called URI and give some history]Include referencesThe URI Protocol is composed of one service with three transactions.Table 7.2-1: URI Service TransactionsTransactionTarget ResourceMedia TypesRequestPayloadResponsePayloadDescriptionRetrieve DICOM InstanceSOP InstanceDICOMEmptyRepresentationor Emptyor PDReturns a single DICOM instance by retrieving the resource in the ‘application/dicom’ media type.Retrieve Rendered InstanceSOP Instance RenderedEmptyRepresentationor Empty or PDReturns a single image by rendering the resource in an acceptable media type. Target resource may shall not be a presentation state instance Retrieve Presentation State InstancePresentation State SOP InstanceRenderedEmptyRepresentationor Emptyor PDReturns a single image by rendering the presentation state specified by the resource in an acceptable media-type. Target resource must shall be a presentation state instanceRequestAll URI Services have the following request message format.GET?/?{requestType=WADO,study_uid,series_uid,object_uid}{&params*}?HTTP/1.1 ?Accept: dicom-media-type ?*header-field ??Where,/is the base URI of the Retrieve Service;requestType=WADOIdentifies this as a URI (previously WADO) request;study_uidis a valid DICOM Study Instance UID; series_uidis a valid DICOM Series Instance UID; andobjectIDis a valid DICOM SOP Instance UID; and&params*specifies that zero or more additional query parameters may be specified. See each transaction for details.The request should always include one or more Accept header fields that specify the media types that are acceptable to the user agent making the request.All URI Service request messages have the following characteristics:They use the HTTP/1.1 protocol.They use the GET method.The target resource is always a DICOM SOP Instance.The object identification query parameters (see 7.2.1.2.1 below) are required on each request,They use the standard content negotiation header fields (see RFC7231, Section 3.4), Object Identification ParametersUser agents shall include all parameters in this section in all URI requests. The origin server shall support all parameters in this section.Table 7.2-X: Object Identification ParametersNameVRDescriptionrequestTypeUIURI request typestudy_uidUIStudy Instance UIDseries_uidUISeries Instance UIDobject_uidUISOP Instance UIDThe value of the “requestType” parameter must be ‘WADO’.Request TyperequestType = WADOThe “requestType” specifies that this is a URI (WADO) request. Its value shall be "WADO".Unique Identifier of the Studystudy_uid = Study Instance UIDThe “study_uid” parameter identifies the study that contains the target resource. Its value shall be a Study Instance UID.Unique Identifier of the Seriesseries_uid = Series Instance UIDThe “series_uid” parameter identifies the series that contains the target resource. Its value shall be a Series Instance UID. This parameter is only used by the Retrieve DICOM Instance and Retrieve Rendered Instance transactions.Unique Identifier of the Instanceobject_uid = SOP Instance UDIThe “object_uid” parameter identifies the instance that contains the target resource. Its value shall be a SOP Instance UID. This parameter is only used by the Retrieve DICOM Instance and Retrieve Rendered Instance transactions.Other Query ParametersUnique Identifier of the Presentation SeriesThis section was previously defined in DICOM. It is now retired. See PS 3.18-2014c, Section 8.1.9.The Unique Identifier of the Series parameter, “series_uid”, should be used instead. See Section 7.2.1.1.3.Unique Identifier of the Presentation ObjectThis section was previously defined in DICOM. It is now retired. See PS 3.18-2014c, Section 8.1.10.The Unique Identifier of the Instance parameter, “object_uid”, should be used instead. See Section 7.2.1.1.4.MIME Type of the Response (Retired)This section was previously defined in DICOM. It is now retired. See PS 3.18-2014c, Section 8.1.5.Media types are specified using the Accept header field. See Section 6.4.2.4.1.Transfer Syntax UID (Retired)This section was previously defined in DICOM. It is now retired. See PS 3.18-2014c, Section 8.2.11.Transfer syntax is specified as a media type parameter in the Accept or Content-Type header fields as appropriate. See Section Charset of the Response (Retired)This section was previously defined in DICOM. It is now retired. See PS 3.18-2014b, Section 8.1.6.Character set is specified using the Accept-Charset header field. See SectionHeader FieldsRequired:AcceptThis transaction uses the standard header fields. See Section 6.3.2.3.Request PayloadURI Services have an empty request payload.BehaviorThe Origen-Server uses the object identification query parameters to specify the SOP Instance that is the target resource of the request. The processing of that instance and the response are specified in the individual URI services define below.ResponseURI responses have the following format:HTTP/1.1?status-code ?reason-phrase?Content-Type: application/dicom ?*header-field??[payload]Where, a successful response <payload> contains the requested instance representation.Status CodesA success response shall have a status code of 200 (OK).An error response will have one of the status codes from Section X.Y.Z.Header FieldsThe following response header field requirements are pertinent to all URI transactions.Required:Content-TypeRecommended if there is no Transfer-Encoding header field:Content-LengthOptional:Content-LocationContent-EncodingSee Section 6.3.2.4PayloadAll successful URI responses have a payload that contains a representation of the target resource in an acceptable media type.All failure responses may have an empty payload. Media TypesTable 7.6-1 contains default, required, recommended, and optional media types for the URI service. The service shall support all default and required media types. Table 6.3-1: URI and WS Media TypesResource CategoryMedia TypeRequirementReferenceDICOMapplication/dicomdefaultRFC3240Single Frame Imagesimage/jpegdefaultISO/IEC 10918image/gifrequiredimage/pngrequiredimage/jp2requiredMulti-Frame Imagesimage/gifrecommendedvideo/mpegrecommendedText Objectstext/htmlrequiredtext/plainrequiredtext/rtfrecommendedtext/xmlrecommendedapplication/pdfrecommendedOther Objectsapplication/dicomrequiredRFC3240other media typesoptionalAll requests should specify the acceptable media types using the Accept header field. If no media type is specified, the response payload shall contain a representation in the default media type for the target resource’s category. If the resource category, of the target resource, has no default media type then the response shall use the application/dicom media type.When an image/jpeg representation is returned, it shall be encoded using the JPEG baseline lossy 8 bit Huffman encoded non-hierarchical non-sequential process ISO/IEC 10918. [ref]It is recommended that the Server also support a "CDA" media type, in conformance to HL7 CDA R2, e.g., text/xml.The origin server may support other media types. All media types supported should be included in the conformance statement and the response from the Capabilities Service.The media types supported by the origin server shall be included in the conformance statement.Acceptable Media TypeThe phrase “in an acceptable media type” when used with respect to the URI protocol means:One of the media types contained in the Accept header field(s) of a request; orOne of the media types contained in the “contentType” query parameter; or The default media type for the service or transaction, if defined.Retrieve DICOM Instance TransactionThe Retrieve DICOM Instance request specifies a target resource that is a single DICOM SOP Instance using the object identification query parameters, and a successful response contains a representation of that resource in the application/dicom media type.RequestThe request has the following format:GET?/?{requestType=WADO}{&study_uid,series_uid,instanceUID}{&anonymize}?HTTP/1.1 ?Accept: application/dicom?*header-field ??The request has the following characteristics:The target resource path “/” is a URI Reference to the Retrieve Service.The object identification query parameters are required.The Accept header is required and its value must be ‘application/dicom’.The request has no payload.Resource”/” specifies the base URI of this service.Query ParametersThis service requires the object identification query parameters (see 7.2.1.2.1), but it also supports the following parameter.Anonymizeanonymize = yesThe “anonymize” parameter is optional, and specifies that the target resource shall have all Personally Identifiable Information (PII) removed. This includes removing or "blanking out" any annotation area(s) containing PII burned into the pixels or in overlays. This process is called de-identification and is sometimes referred to as anonymization; although, the latter term is discouraged. See PS3.15 Section E. Attribute Confidentiality Profiles.De-identification is the responsibility of the origin server. De-identified objects shall have a new SOP Instance UID that is different from that of the original identified objects. The Server may return an error if either it cannot or refuses to de-identify the requested objects.Header FieldsRequired:Accept: application/dicomSee Section 6.3.1.3.PayloadThe request payload is empty.BehaviorThe origin server retrieves the SOP Instance specified by the target resource and returns it in the response payload. ResponseThe response has the following format:HTTP/1.1?status-code?reason-phrase?Content-Type: application/dicom ?*header-field??[payload]A success response contains a status code of 200 (OK) and a single part payload containing the target resource in the application/dicom media type.Status CodesA success response shall have a status code of 200 (OK). A failure response will have a failure status code from Table X.Y-Z.Header FieldsRequired:Content-TypeSee Sections 7.2.3.2 and 6.3.1.3.2.PayloadA success payload contains a representation of the target resource in the application/dicom media type.A failure response may have an empty payload; however, it is recommended that it contains a Status Details document. See Section 7.2.3.3.Media TypeThe Retrieve DICOM Instance service only supports the ‘application/dicom’ media type. See Section 7.2.4 and Annex X for details.URI Retrieve Rendered Instance TransactionThe Retrieve Rendered Instance request specifies a target resource that is a single DICOM SOP Instance using the object identification query parameters. A successful response shall contain a representation of that resource in an acceptable rendered media type. See Section x.y-Z.RequestThe request has the following format:GET?/?{requestType=WADO,study_uid,series_uid,instanceUID}{&rendering*}?HTTP/1.1?Accept: rendered-media-types ?*header-field*??Where,rendering = {&annotation,rows,columns,region,windowCenter,windowWidth,frameNumber,imageQuality}rendered-media-typesis one or more of the media types defined in Table x.y-z.The request has the following characteristics:The target resource may not be a presentation state series or instance.Only rendered media types shall be specified in the Accept header field. The application/dicom media type shall not be specified.This transaction provides additional query parameters that specify how the origin server should render the target resource.Target ResourceThe resource path component of the URI is “/”, this specifies the base URI of the service.Query ParametersThis service requires the object identification query parameters specified in Section 7.2.1.2.1, but it also supports additional query parameters that specify how the target resource is rendered.The following rules pertain to all parameters defined in this section:All parameters in this section are optional for the user agent and required for the origin server.The parameters only apply to image and video media types, as defined in Section X.X.The data types of the parameter values are defined in Section 6.3.1.2.2.Unless the “rows” or “columns” parameter is specified the returned image (or selected region) shall be in its original size.The following table contains a synopsis of the available rendering parameters:Table 7.4-X: Retrieve Rendered Instance Query ParametersNameData TypeValue DescriptionframeNumberintegerThe number of the frame to retrieveregiondecimalFour decimal numbers that specify the regionrowsintegerThe number of rows in returned imagecolumnsintegerThe number of columns in returned imagewindowCenterdecimalThe luminosity of the imagewindowWidthdecimalThe contrast of the imageannotationkeywordAnnotations to be applied to imageimageQualityintegerThe quality of the lossy compressionAnnotation on the Objectannotation = patient / techniqueThe “annotation” parameter specifies that annotations should be applied to the returned image. Its value shall be a non-empty, comma-separated list of one or more of the following items:patient – displays patient information (e.g., patient name, birth date, etc.)technique– displays technique information (e.g., image number, study date, image position, etc.).When used in conjunction with the region parameter, it shall be applied after the selection of the region.The exact nature and presentation of the annotation is determined by the origin server.Frame NumberframeNumber = {integer}where 1 <= integer <= total number of framesThe “frameNumber” parameter specifies the frame number of an image within the multi-frame instance specified by the target resource. It shall be ignored for all objects other than multi-frame objects.Image QualityimageQuality = {integer}where 1 <= integer <= 100The “imageQuality” parameter controls the relative quality of lossy compressed images. Its value is an Integer string that ranges from 1 to 100 inclusive, 100 having the best quality.NoteThe meaning of this parameter depends on the media type and is determined by the origin server.Pixel Rows in Rendered Imagerows = {integer}where 0 <= integer The “rows” parameter specifies the height in pixels of the rendered image. The returned image shall have the same aspect ratio as the original image.N.B:The user agent may specify “rows” or “columns”, but should not specify both. If both are specified, then the origin server shall scale the returned images, maintaining their original aspect ratio, until either the image width is the same as the viewport width or the image depth is the same as the viewport depth, whichever comes first. In other words, viewport scaling makes the image(s) as large as possible without overflowing the viewport area.Pixel Columns in Rendered Imagecolumns = {integer}where 0 <= integer The “columns” parameter specifies the width in pixels of the rendered image. The returned image shall have the same aspect ratio as the original image.See N.B. in 7.4.1.2.2.Region of Target Resourceregion = {xMin,yMin,xMax,yMax}where range =0.0 <= xMin < xMax <= 1.0, and0.0 <= yMin < yMax <= 1.0The “region” parameter specifies a rectangular region of the target resource. Its value shall be a list of four comma separated, positive decimal strings, representing in the following order:xMinthe top row of the region, yMinthe left column of the region, xMaxthe bottom row of the region, yMaxthe right column of the region, The region is specified using a normalized coordinate system relative to the size of the original image, measured in rows and columns. Where 0.0 corresponds to the top row and left column of the image, and1.0 corresponds to the bottom row and right column of the image.If this parameter is supported, an image corresponding to the specified region shall be returned in the response.If this parameter specifies an ill-defined region, the origin server shall … Note:The origin server may not support this parameter. If this parameter is supported, an image corresponding to the specified region shall be returned with size corresponding to the specified normalized coordinates.Window Center of the Rendered ImagewindowCenter={decimal}where ???The “windowCenter” parameter controls the luminosity of the returned images, as defined in PS3.3. If the “windowWidth” parameter is present, this parameter shall also be present. Window Width of the Rendered ImagewindowWidth={decimal}where???The “windowWidth” parameter controls the contrast of the returned images, as defined in PS3.3. If the “windowCenter” parameter is present, this parameter shall also be present.Header FieldsRequired:AcceptSee Section 6.3.1.3PayloadThe request payload shall be empty.BehaviorThe origin server will render the target resource in an acceptable media type, and return it in the response payload. ResponseThe response has the following format:HTTP/1.1?status-code?reason-phrase?Content-Type: rendered-media-type?*header-field??[payload]A success response contains a status code of 200 (OK) and a single part payload containing the target resource in the rendered media type.A failure response will contain a failure status code and possibly a Status Details payload.Status CodesA success response shall have a status code of 200 (OK). A failure response will have a failure status code from Table X.Y-Z.Header FieldsRequired:Content-TypeSee Section 6.3.1.3.2PayloadA success payload contains a representation of the target resource in an acceptable media type.A failure response may have an empty payload; however, it is recommended that it contains a Status Details document. See Section 7.2.3.3.Media TypesSee Section 7.6 for the rendered media types supported by the URI service.URI Retrieve Rendered Presentation State TransactionIn the URI Retrieve Rendered Presentation State (Rendered PS) Transaction, the user agent requests that the origin server render the target resource, which must be a presentation state instance, in an acceptable media type as specified by the presentation state and query parameters. The rendered representation is returned in the response.RequestThe URI Retrieve Rendered Presentation State request message has the following format:GET?/?{requestType=WADO,study_uid,series_uid,object_uid}{&query*}?HTTP/1.1 ?Accept: rendered-media-type ?*header-field ??The request has the following characteristics:The target resource shall be a presentation state instance.Only rendered media types shall be specified in the Accept header field. The application/dicom media type shall not be specified.This transaction provides additional query parameters that specify how the origin server should render the target resource.Query ParametersThis service requires the object identification query parameters specified in Section 7.2.1.2.1, but it also supports additional query parameters that specify how the target resource is rendered.The following rules pertain to all parameters defined in this section:All parameters in this section are optional for the user agent and required for the origin server.The parameters only apply to image and video media types, as defined in Section X.X.The data types of the parameter values are defined in Section 6.3.1.2.2.Unless the “rows” or “columns” parameter is specified the returned image (or selected region) shall be in its original size.The following table contains a synopsis of the available rendering parameters:Table 7.5-1: Retrieve Presentation State ParametersNameData TypeValue DescriptionrowsintegerThe number of rows in returned imagecolumnsintegerThe number of columns in returned imageannotationkeywordAnnotations to be applied to imageimageQualityintegerThe quality of the lossy compressionPixel Rows in Rendered Imagerows = {integer}where, range = 1 <= rowsSee 7.4.1.2.2.Pixel Columns in Rendered Imagecolumns = {integer}where, range = 0 <= columnsSee 7.4.1.2.2.Image Annotationannotation = {patient | technique}See Section 7.4.1.2.1.Image Qualityquality = {integer}where, range = 1 <= quality <= 100See Section 7.4.1.2.8.Header FieldsRequired:AcceptSee Section 6.3.1.3.2.PayloadThe request payload shall be empty.BehaviorThe origin server will render the target presentation state instance in an acceptable media type, using the appropriate presentation state pipeline as specified in PS3.3, Section xxx.If the annotation parameter is present, the specified annotations will be applied to the image after it has been rendered using the target presentation state, and before it has been encoded in an acceptable media type. The annotations may be applied as an overlay or they may be “burned in”.If the Presentation Size Mode in the presentation state is SCALE TO FIT or TRUE SIZE, then the displayed area specified in the presentation shall be scaled to fit the size specified by the rows and/or columns parameters if present, otherwise the displayed area selected in the presentation state will be returned without scaling.If the Presentation Size Mode in the presentation state is MAGNIFY, then the displayed area specified in the presentation shall be magnified (scaled) as specified in the presentation state. It shall then be cropped to fit the size specified by the rows and/or columns parameters, if present.Any Displayed Area relative annotations specified in the presentation state shall be rendered relative to the Specified Displayed Area within the presentation state, not the size of the returned image.Though the output of the presentation state is defined in DICOM to be in P-Values (grayscale values intended for display on a device calibrated to the DICOM Grayscale Standard Display Function PS3.14), the grayscale or color space for the images returned by the request is not defined by this standard.Note:As specified in DICOM, the Presentation State will be in the same study as the images it applies to.ResponseThe response has the following format:HTTP/1.1?status-code ?reason-phrase ?Content-Type: rendered-media-type ?*header-field??[payload]A success response contains a status code of 200 (OK) and a single part payload containing the target resource in the rendered media type.A failure response will contain a failure status code and possibly a Status Details payload.Status CodeA success response shall have a status code of 200 (OK). A failure response shall have an appropriate failure status code from Table x.y.z.Header FieldsRequired:Content-TypeSee Section 6.3.1.3.2PayloadA success payload shall have a single part that contains a representation of the target resource in an acceptable media type.A failure response may have an empty payload; however, it is recommended that it contains a Status Details document. See Section 7.2.3.3.WS* Web Services Protocol (WS)Closed Issues#IssuesOpen Issues#IssuesEditorial Issues#IssuesShould we add message format to this section?TransactionsTransactionMethodRequestPayloadResponsePayloadDescriptionRetrieveDocumentSetGETEmptyinstance(s)or PDThis action retrieves a set of DICOM instances and other objects. This action corresponds to the IHE XDS-I.b transaction RAD-69. The DICOM instances are formatted in accordance with PS3.10, and encapsulated in a Web Services response.RetrieveRenderedDocumentSetGETEmptyRenderedinstance(s)or PDThis action retrieves a set of DICOM instances that have been rendered into the requested format. For example, if rendering into JPEG was requested, these will be the JPEG renderings of the requested set of DICOM objects.RetrievePresentationStateGETEmpty1 rendered PS instance Retrieve Document Set MetadataGETEmptyMetadata instance(s)This action retrieves a set of DICOM instances presented as an Infoset with the bulkdata removed. This service can retrieve either the full metadata, or a subset selected by XPath arguments. The XML encoding for the DICOM attributes is defined in PS3.19.TODO add parameters section to Retrieve Rendered Document SetAdd Retrieve Rendered Presentation StateTalk to Larry T. about other potential modificationsThe DICOM Web Service defines several action types. An implementation shall support at least one of these actions. The three action types are:Retrieve Imaging Document SetThis action retrieves a set of DICOM instances and other objects. This action corresponds to the IHE XDS-I.b transaction RAD-69. The DICOM instances are formatted in accordance with HYPERLINK ":\\Users\\jfp\\Documents\\DICOM\\WG-27\\Supplements\\Re-Doc%20Part%2018\\part10.pdf" \l "PS3.10" \h PS3.10, and encapsulated in a Web Services response.Retrieve Rendered Imaging Document SetThis action retrieves a set of DICOM instances that have been rendered into the requested format. For example, if rendering into JPEG was requested, these will be the JPEG renderings of the requested set of DICOM objects.Retrieve Imaging Document Set MetadataThis action retrieves a set of DICOM instances presented as an Infoset with the bulkdata removed. This service can retrieve either the full metadata, or a subset selected by XPath arguments. The XML encoding for the DICOM attributes is defined in HYPERLINK ":\\Users\\jfp\\Documents\\DICOM\\WG-27\\Supplements\\Re-Doc%20Part%2018\\part19.pdf" \l "PS3.19" \h PS3.19.The Web Services actions shall be fully compliant with the Basic Profile of WS-I as defined in IHE IT Infrastructure Technical Framework Vol 2x Annex V. All <wsa:Action> elements shall have the mustUnderstand attribute set (mustUnderstand="1").Acceptable Media TypeThe phrase “in an acceptable media type” when used with respect to the URI protocol means:One of the media types contained in the Accept header field(s) of a request;One of the media types contained in the “ContentType” query parameter; or The default media type, if defined.Retrieve Imaging Document SetRequestThe specific Web Services parameters to be used for the Retrieve Imaging Document Set action shall be as follows, in the order that they would appear in the WSDL definition:The following types shall be imported (xsd:import) in the /definitions/types section:namespace="urn:ihe:rad:xdsi-b:2009", schema="XDSI.b_ImagingDocumentSource.xsd"The baseline XDS.b schema (namespace="urn:ihe:iti:xds-b:2007", schema="XDS.b_DocumentRepository.xsd")The baseline DICOM WADO-WS schema (namespace="urn:dicom:wado:ws:2011", schema="dicom.wado.ws.2011.xsd")The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set Request message shall be an "iherad:RetrieveImagingDocumentSetRequest" as defined below.The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set Response message shall be an "ihe:RetrieveDocumentSetResponse" as defined below.The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Imaging Document Set Request message shall be "urn:ihe:rad:2009:RetrieveImagingDocumentSet".The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve Imaging Document Set Response message shall be "urn:ihe:iti:2007:RetrieveDocumentSetResponse".The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be "urn:ihe:rad:2009:RetrieveImagingDocumentSet".The <iherad:RetrieveImagingDocumentSetRequest/> element for use with the Retrieve Imaging Document Set Request Message is defined as:One or more <iherad:StudyRequest/> elements each of which includes a "studyInstanceUID" attribute identifying the study associated with the DICOM images/ objects being retrieved. Each <iherad:StudyRequest/> element shall contain:One or more <iherad:SeriesRequest/> elements each of which includes a "seriesInstanceUID" attribute identifying the series associated with the DICOM images/ objects being retrieved. Each <iherad:SeriesRequest/> element shall contain:One or more <ihe:DocumentRequest/> elements, each one representing an individual document that the requestor wants to retrieve from the Web Server. Each <ihe:DocumentRequest/> element contains:An optional <ihe:RepositoryUniqueId/> element that identifies the Web Server from which the document is to be retrieved. This value corresponds to XDSDocumentEntry.repositoryUniqueId. The RepositoryUniqueID is similar to a DICOM AETitle, but is a uniqueID assigned to the WADO-WS Web Server rather than a locally assigned string identifier. There will be a separate RepositoryUniqueID for each web service end point.A required <ihe:DocumentUniqueId/> element that identifies the document within the source. For example, this value could be a SOP Instance UID obtained from a Key Object Selection (KOS) instance.An optional <ihe:HomeCommunityId/> element. See the IHE Profiles for the definition and possible uses of this element.An optional <wado:Anonymize/> element.An optional <wado:FrameNumber/> element.A required <iherad:TransferSyntaxUIDList/> element that contains a list of one or more <ihe:TransferSyntaxUID> elements. Each of the <iherad:TransferSyntaxUID> elements represent one of the transfer syntax encodings that the Imaging Document Consumer is capable of processing.ResponseA Web Server shall provide the document(s) indicated in the request. The Web Server shall return the document(s) or an error code when the document could not be returned. The pixel data shall be encoded using one of the DICOM transfer syntaxes included in the Retrieve Imaging Document Set Request Message. If the Imaging Document Source cannot encode the pixel data using any of the requested transfer syntaxes then an error status shall be returned.Form of the ResponseThe <ihe:RetrieveDocumentResponse/> element for use with the Retrieve Imaging Document Set Response Message is defined as:A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse elementAn optional sequence of <ihe:DocumentResponse/> elements containingAn optional <ihe:HomeCommunityId/> element. The value of this element shall be the same as the value of the /RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityId element in the Retrieve Document Set Request Message. If the <ihe:HomeCommunityId/> element is not present in the Retrieve Document Set Request Message, this value shall not be present.An optional <ihe:RepositoryUniqueId/> that identifies the Imaging Document Source from which the document is to be retrieved. The value of this element shall be the same as the value of the /RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest/RepositoryUniqueId element in the original Retrieve Imaging Document Set Request Message. This value corresponds to XDSDocumentEntry.repositoryUniqueId.A required <ihe:DocumentUniqueId/> that identifies the document within the Imaging Document Source. The value of this element shall be the same as the value of the /RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest/DocumentUniqueId element in the original Retrieve Imaging Document Set Request Message. This value corresponds to the SOP Instance UID in the Retrieve Document Request.A conditional <wado:FrameNumber/> that identifies the frame within the source document. It shall be present if and only if <wado:FrameNumber/> was in the requestA required <ihe:Document/> element that contains the retrieved document as an XOP Infoset.A required <ihe:mimeType/> element that indicates the media type of the retrieved document.The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall status of the request: It shall contain one of the following values:urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Successurn:ihe:iti:2007:ResponseStatusType:PartialSuccessurn:oasis:names:tc:ebxml-regrep:ResponseStatusType:FailureSee ITI TF-2a: 4.1.13 Error Reporting for the interpretation of these values.For each document requested in a /RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest element:If the document is successfully retrieved (without warning) then no /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be present and a /RetrieveDocumentSetResponse/DocumentResponse/Document element shall be returned containing the document as base64binary encoded data.If a warning is reported when retrieving the document, then a /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be returned with:@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning@errorCode is specified@codeContext contains the warning message@location contains the DocumentUniqueId of the document requestedThe document shall be returned in an instance of /RetrieveDocumentSetResponse/DocumentResponse/Document as base64binary encoded data. The returned document and warning are correlated via the DocumentUniqueId.If an error is reported when retrieving a document, then a /RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be returned with:@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error@errorCode is specified@codeContext contains the error message@location contains the DocumentUniqueId of the document requestedNo corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be returnedThe error conditions for failures and associated error codes are given below in section 6.4.4. These errors shall be detected and the associated errorCode returned if that error occurs. Additional errors defined in the ebRS standard, in ITI TF-2: 4.1.13 "Error Reporting", and defined by the implementer may be returned.JPIPIf the Web Client specifies a transfer syntax field of 1.2.840.10008.1.2.4.94 (DICOM JPIP Referenced Transfer Syntax) or 1.2.840.10008.1.2.4.95 (DICOM JPIP Referenced Deflate Transfer Syntax), and the Web Server supports the requested transfer syntax the following behavior is expected:If the DICOM Image Object(s) already have the same JPIP transfer syntax as the one indicated in the request, the Retrieve Imaging Document Set Response shall include the DICOM Image Objects unchanged.If the DICOM Image Object(s) have a transfer syntax that differs from that of the request, the Retrieve Imaging Document Set Response shall include the DICOM image with the transfer syntax changed to the requested transfer syntax. In addition, the pixel data Attribute (7FE0,0010 tag) will have been removed and replaced with a Pixel Data Provider URL (0028,7FE0 tag). The URL represents the JPIP request and will include the specific target information.Upon receipt of this Retrieve Imaging Document Set Response, the Imaging Document Consumer may request the pixel data from the pixel data provider using the supplied URL. Additional parameters required by the application may be appended to the URL when accessing the pixel data provider.For example, a JPIP request for a 200 by 200 pixel rendition of the entire image can be constructed from the Pixel Data Provider URL as follows:Pixel Data Provider URL (0028,7FE0) = Generated by the application = Rendered Imaging Document SetRequestThe specific Web Services parameters to be used for the Retrieve Rendered Imaging Document Set action shall be as follows, in the order that they would appear in the WSDL definition:The following types shall be imported (xsd:import) in the /definitions/types section:namespace="urn:ihe:rad:xdsi-b:2009", schema="XDSI.b_ImagingDocumentSource.xsd"The baseline XDS.b schema (namespace="urn:ihe:iti:xds-b:2007", schema="XDS.b_DocumentRepository.xsd")The baseline DICOM WADO-WS schema (namespace="urn:dicom:wado:ws:2011", schema="dicom.wado.ws.2011.xsd")The /definitions/message/part/@element attribute of the Retrieve Rendered Imaging Document Set Request message shall be a "wado:RetrieveRenderedImagingDocumentSetRequest" as defined below.The /definitions/message/part/@element attribute of the Retrieve Rendered Imaging Document Set Response message shall be a "wado:RetrieveRenderedImagingDocumentSetResponse" as defined below.The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Rendered Imaging Document Set Request message shall be "urn:dicom:ws:wado:2011:RetrieveRenderedImagingDocumentSet".The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve Imaging Document Set Response message shall be "urn:dicom:ws:wado:2011:RetrieveRenderedImagingDocumentSetResponse".The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be "urn:dicom:ws:wado:2011:RetrieveRenderedImagingDocumentSet".The <wado:RetrieveRenderedImagingDocumentSetRequest/> element for use with the Retrieve Imaging Document Set Request Message is defined as:One or more <wado:StudyRequest/> elements each of which includes a Study Instance UID" attribute identifying the study associated with the DICOM images/ objects being retrieved. Each <iherad:StudyRequest/> element shall contain:One or more <wado:SeriesRequest/> elements each of which includes a Series Instance UID attribute identifying the series associated with the DICOM images/ objects being retrieved. Each <iherad:SeriesRequest/> element shall contain:One or more <wado:RenderedDocumentRequest/> elements, each one representing an individual document that the requestor wants to retrieve from the Web Server. Each <wado:DocumentRequest/> element contains:An optional <ihe:RepositoryUniqueId/> element that identifies the Web Server from which the document is to be retrieved. This value corresponds to XDSDocumentEntry.repositoryUniqueId. The RepositoryUniqueID is similar to a DICOM AETitle, but is a uniqueID assigned to the WADO-WS Web Server rather than a locally assigned string identifier. There will be a separate RepositoryUniqueID for each web service end point.A required <ihe:DocumentUniqueId/> element that identifies the document within the source. This value corresponds to the SOP Instance UID referenced within the DICOM manifest.An optional <ihe:HomeCommunityId/> element that corresponds to the home attribute of the Identifiable class in ebRIM.An optional <wado:Annotation/> element.An optional <wado:Rows/> element.An optional <wado:Columns/> element.An optional <wado:Region/> element.An optional <wado:WindowCenter/> element.An optional <wado:WindowWidth/> element.An optional <wado:ImageQuality/> element.An optional <wado:PresentationUID/> element.An optional <wado:PresentationSeriesUID/> element.An optional <wado:Anonymize/> elementAn optional <wado:FrameNumber/> element.A required <wado:ContentTypeList/> element that contains a list of one or more <wado:ContentType> elements.An optional <wado:CharsetList/> element that contains a list of one or more <wado:Charset> elements.ParametersThis service requires the object identification query parameters specified in Section 7.2.1.2.1, but it also supports additional query parameters that specify how the target resource is rendered.The following rules pertain to all parameters defined in this section:All parameters in this section are optional for the user agent and required for the origin server.The parameters only apply to image and video media types, as defined in Section X.X.The data types of the parameter values are defined in Section 6.3.1.2.2<#6.3.1.2.2>.Unless the “rows” or “columns” parameter is specified the returned image (or selected region) shall be in its original size.The following table contains a synopsis of the available rendering parameters:Table 8.2-X: Rendering Query ParametersNameData TypeValue DescriptionFrameNumberintegerThe number of the frame to retrieveRegiondecimalFour decimal numbers that specify the regionRowsintegerThe number of rows in returned imageColumnsintegerThe number of columns in returned imageWindowCenterdecimalThe luminosity of the imageWindowWidthdecimalThe contrast of the imageAnnotationkeywordAnnotations to be applied to imageImageQualityintegerThe quality of the lossy compressionAnnotation on the ObjectAnnotation = {patient / technique}The “Annotation” parameter specifies that annotations should be applied to the returned image. Its value shall be a non-empty, comma-separated list of one or more of the following items:patient – displays patient information (e.g., patient name, birth date, etc.)technique– displays technique information (e.g., image number, study date, image position, etc.).When used in conjunction with the region parameter, it shall be applied after the selection of the region.The exact nature and presentation of the annotation is determined by the origin server.Pixel Rows in Rendered ImageRows = {integer}where 0 <= Rows The “Rows” parameter specifies the height in pixels of the rendered image. The returned image shall have the same aspect ratio as the original image.N.B:The user agent may specify “rows” or “columns”, but should not specify both. If both are specified, then the origin server shall scale the returned images, maintaining their original aspect ratio, until either the image width is the same as the viewport width or the image depth is the same as the viewport depth, whichever comes first. In other words, viewport scaling makes the image(s) as large as possible without overflowing the viewport area.Pixel Columns in Rendered ImageColumns = {integer}where 0 <= Columns The “columns” parameter specifies the width in pixels of the rendered image. The returned image shall have the same aspect ratio as the original image.See N.B. in 7.4.1.2.2.Region RenderedRegion = {xMin,yMin,xMax,yMax} where0.0 <= top < bottom <= 1.0, and0.0 <= left < right <= 1.0.The “Region” parameter specifies a rectangular region of the target resource. Its value shall be a list of four comma separated, positive decimal strings, representing in the following order:xMINthe top row of the region, Yminthe left column of the region, xMAXthe bottom row of the region, YmAXthe right column of the region, The region is specified using a normalized coordinate system relative to the size of the original image, measured in rows and columns. Where 0.0 corresponds to the top row and left column of the image,1.0 corresponds to the bottom row and right column of the image, andIf this parameter is supported, an image corresponding to the specified region shall be returned in the response.If this parameter specifies an ill-defined region, the origin server shall … Note:The origin server may not support this parameter. If this parameter is supported, an image corresponding to the specified region shall be returned with size corresponding to the specified normalized coordinates.Window Center of the Rendered ImageWindowCenter={decimal}where ???The “WindowCenter” parameter controls the luminosity of the returned images, as defined in PS3.3. If the “WindowWidth” parameter is present, this parameter shall also be present. Window Width of the Rendered ImageWindowWidth={decimal}where???The “WindowWidth” parameter controls the contrast of the returned images, as defined in PS3.3. If the “WindowCenter” parameter is present, this parameter shall also be present.Frame NumberFrameNumber = {integer}where 0 <= integer <= total number of framesThe “FrameNumber” parameter specifies the frame number of an image within the multi-frame instance specified by the target resource. It shall be ignored for all objects other than multi-frame objects.Image QualityImageQuality = {integer}where 1 <= integer <= 100The “ImageQuality” parameter controls the relative quality of lossy compressed images. Its value is an Integer string that ranges from 1 to 100 inclusive, 100 having the best quality.NoteThe meaning of this parameter depends on the media type and is determined by the origin server.ResponseAn Web Server shall render and then provide the document(s) indicated in the request. The Web Server shall return the rendered documents or an error code when the document could not be returned. The rendered forms shall be the subset specified, and in the format requested. If the Imaging Document Source cannot render the pixel data in that manner then an error status shall be returned.The <wado:RetrieveRenderedImagingDocumentResponse/> element for use with the Retrieve Imaging Document Set Response Message, Retrieve Rendered Imaging Document Set Response Message and Retrieve Imaging Document Set Metadata Response Message is defined as:A required /ihe:RetrieveDocumentSetResponse/rs:RegistryResponse elementAn optional sequence of <wado:RenderedDocumentResponse/> elements containing:A <ihe:HomeCommunityId/> element. The value of this element shall be the same as the value of the StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityId element in the Request Message. If the <ihe:HomeCommunityId/> element is not present in the Request Message, this value shall not be present.A required <ihe:RepositoryUniqueId/> that identifies the Imaging Document Source from which the document was retrieved. The value of this element shall be the same as the value of the StudyRequest/SeriesRequest/DocumentRequest/RepositoryUniqueId element in the original Request Message.A required <wado:SourceDocumentUniqueId/> that identifies the source document. The value of this element shall be the same as the value of the StudyRequest/SeriesRequest/DocumentRequest/DocumentUniqueId element in the original Request Message. This value identifies the source, and is not an ID for the resulting rendered document.A conditional <wado:FrameNumber/> that identifies the frame within the source document. It shall be present if and only if <wado:FrameNumber/> was in the request.A required <wado:Annotation/> element that contains the actual value used.A required <wado:Rows/> element that contains the actual value used.A required <wado:Columns/> element that contains the actual value used.A required <wado:Region/> element that contains the actual value used.A required <wado:WindowCenter/> element that contains the actual value used.A required <wado:WindowWidth/> element that contains the actual value used.A required <wado:ImageQuality/> element that contains the actual value used.A required <wado:PresentationUID/> element that contains the actual value used if a PresentationUID was used.A required <wado:PresentationSeriesUID/> element that contains the actual value used if a PresentationSeriesUID was used.An optional <wado:Anonymize/> element that shall be present if the rendered instance was anonymized.A required <ihe:Document/> element that contains the rendered document encoded as an XOP Infoset.A required <ihe:mimeType/> element that indicates the media type of the retrieved document.The /RetrieveDocumentSetResponse/rs:RegistryResponse/@status attributes provides the overall status of the request: It shall contain one of the following values:urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Successurn:ihe:iti:2007:ResponseStatusType:PartialSuccessurn:oasis:names:tc:ebxml-regrep:ResponseStatusType:FailureFor each document requested in a /RetrieveRenderedImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest element:If the document is successfully rendered (without warning) then no /RetrieveRenderedImagingDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be present and a /RetrieveRenderedImagingDocumentSetResponse/DocumentResponse/Document element shall be returned containing the rendered document as base64binary encoded data.If a warning is reported when retrieving the document, then a /RetrieveRenderedImagingDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be returned with:@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning@errorCode is specified@codeContext contains the warning message@location contains the DocumentUniqueId of the document requestedThe rendered document shall be returned in an instance of /RetrieveRenderedImagingDocumentSetResponse/DocumentResponse/Document as base64binary encoded data. The returned document and warning are correlated via the DocumentUniqueId.If an error is reported when retrieving a document, then a /RetrieveRenderedImagingDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be returned with:@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error@errorCode is specified@codeContext contains the error message@location contains the DocumentUniqueId of the document requestedNo corresponding RetrieveRenderedImagingDocumentSetResponse/DocumentResponse element shall be returnedThe error conditions for failures and associated error codes are given below in section 6.4.4. These errors shall be detected and the associated errorCode returned if that error occurs. Additional errors defined in the ebRS standard, in ITI TF-2: 4.1.13 "Error Reporting", and defined by the implementer may be returned.Retrieve Rendered Presentation State RequestTODORetrieve Imaging Document Set Metadata RequestRequestThe specific Web Services parameters to be used for the Retrieve Imaging Document Set Metadata action shall be as follows, in the order that they would appear in the WSDL definition:The following types shall be imported (xsd:import) in the /definitions/types section:namespace="urn:ihe:rad:xdsi-b:2009", schema="XDSI.b_ImagingDocumentSource.xsd"The baseline XDS.b schema (namespace="urn:ihe:iti:xds-b:2007", schema="XDS.b_DocumentRepository.xsd")The baseline DICOM WADO-WS schema (namespace="urn:dicom:wado:ws:2011", schema="dicom.wado.ws.2011.xsd")The /definitions/message/part/@element attribute of the Retrieve Imaging Document Information Set Request message shall be defined an "wado:RetrieveImagingDocumentSetInformationRequest" as defined below.The /definitions/message/part/@element attribute of the Retrieve Imaging Document Set Information Response message shall be defined an "wado:RetrieveImagingDocumentSetInformationResponse" as defined below.The /definitions/portType/operation/input/@wsaw:Action attribute for the Retrieve Imaging Document Set Information Request message shall be "urn:wado:2011:RetrieveImagingDocumentSetInformation".The /definitions/portType/operation/output/@wsaw:Action attribute for the Retrieve Imaging Document Set Information Response message shall be "urn:wado:2011:RetrieveImagingDocumentSetInformationResponse".The /definitions/binding/operation/soap12:operation/@soapAction attribute shall be "urn:wado:2011:RetrieveImagingDocumentSetInformation".The <wado:RetrieveImagingDocumentSetInformationRequest/> element for use with the Retrieve Imaging Document Set Request Message is defined as:One or more <wado:StudyRequest/> elements each of which includes a "studyInstanceUID" attribute identifying the study associated with the DICOM images/objects being retrieved. Each <iherad:StudyRequest/> element shall contain:One or more <wado:SeriesRequest/> elements each of which includes a "seriesInstanceUID" attribute identifying the series associated with the DICOM images/objects being retrieved. Each <iherad:SeriesRequest/> element shall contain:One or more <wado:DocumentInformationRequest/> elements, each one representing an individual document that the requestor wants to retrieve from the Web Server. Each < wado:DocumentInformationRequest /> element contains:· An required <ihe:RepositoryUniqueId/> element that identifies the Web Server from which the document is to be retrieved. This value corresponds to XDSDocumentEntry.repositoryUniqueId. The RepositoryUniqueID is similar to a DICOM AE Title, but is a uniqueID assigned to the WADO-WS Web Server rather than a locally assigned string identifier. There will be a separate RepositoryUniqueID for each web service end point.A required <ihe:DocumentUniqueId/> element that identifies the document within the source. For example, this value could be a SOP Instance UID obtained from a Key Object Selection (KOS) instance.An optional <ihe:HomeCommunityId/> element. See the IHE Profiles for the definition and possible uses of this element.An optional <wado:Anonymize/> elementA required <wado:XPath/> that contains the text corresponding to the XPath "filter" applied to the Native DICOM Model transposition of the object, as defined in PS3.19.NoteIf the requested filter is "/", then all of the metadata is requested.ResponseA Web Server shall extract information from each document specified in a Document Set Information Request. This shall be done by the logical equivalent of:convert the non-pixel data for each of the requested data into an XML encoded formapply each of the wado:XPath elements to this XML encoded formprovide the XPath response as part of the Document Set Information Response.See PS3.19 for details on conversion to XML encoded form.The Web Server shall return the XPath results or an error code when the document could not be processed.The <wado:RetrieveImagingDocumentSetInformationResponse/> element for use with the Retrieve Imaging Document Set Response Message is additionally defined as:A required /wado:RetrieveImagingDocumentSetInformationResponse/rs:RegistryResponse elementAn optional sequence of <wado:DocumentInformationResponse/> elements containing:A <ihe:HomeCommunityId/> element. The value of this element shall be the same as the value of the StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityId element in the Request Message. If the <ihe:HomeCommunityId/> element is not present in the Request Message, this value shall not be present.A required <ihe:DocumentUniqueId/> that identifies the document within the Web Server. The value of this element shall be the same as the value of the StudyRequest/SeriesRequest/DocumentRequest/DocumentUniqueId element in the original Request Message. This value corresponds to the SOP Instance UID.A conditional <wado:FrameNumber/> that identifies the frame within the source document. It shall be present if and only if <wado:FrameNumber/> was in the request.One <wado:XPathResponseList/> containing:A required <wado:XPathResponse> that contains the XPath results for each <wado:XPath/> elements, in the same order as in the request encoded as an XOP Infoset. The response element shall be empty if there was no XPath match.The /RetrieveImagingDocumentSetInformationResponse/rs:RegistryResponse/@status attributes provides the overall status of the request: It shall contain one of the following values:urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Successurn:ihe:iti:2007:ResponseStatusType:PartialSuccessurn:oasis:names:tc:ebxml-regrep:ResponseStatusType:FailureFor each document requested in a /RetrieveImagingDocumentSetInformationRequest/StudyRequest/SeriesRequest/DocumentRequest element:If the document is successfully retrieved (without warning) then no /RetrieveImagingDocumentSetInformationResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be present and a /RetrieveImagingDocumentSetInformationResponse/DocumentResponse/Document element shall be returned containing the document as base64binary encoded data.If a warning is reported when retrieving the document, then a /RetrieveImagingDocumentSetInformationResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be returned with:@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning@errorCode is specified@codeContext contains the warning message@location contains the DocumentUniqueId of the document requestedThe document shall be returned in an instance of /RetrieveDocumentSetResponse/DocumentResponse/Document as base64binary encoded data. The returned document and warning are correlated via the DocumentUniqueId.If an error is reported when retrieving a document, then a /RetrieveImagingDocumentSetInformationResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError element shall be returned with:@severity is urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error@errorCode is specified@codeContext contains the error message@location contains the DocumentUniqueId of the document requestedNo corresponding RetrieveDocumentSetResponse/DocumentResponse element shall be returnedThe error conditions for failures and associated error codes are given below in section 6.4.4. These errors shall be detected and the associated errorCode returned if that error occurs. Additional errors defined in the ebRS standard, in ITI TF-2: 4.1.13 "Error Reporting", and defined by the implementer may be returned.WS Media TypesTable 8.6-1 contains default, required, recommended, and optional media types for the WS service. The default and required media types shall be supported by an implementation of this service.Table 8.6-1: URI and WS Media TypesResource CategoryMedia TypeRequirementReferenceDICOMapplication/dicomdefaultRFC3240Single Frame Imageimage/jpegdefaultISO/IEC 10918image/gifrequiredimage/pngrequiredimage/jp2requiredMulti-Frame ImageVideoimage/gifrecommendedvideo/mpegrecommendedText Objectstext/htmlrequiredtext/plainrequiredtext/rtfrecommendedtext/xmlrecommendedapplication/pdfrecommendedOther Objectsapplication/dicomrequiredRFC3240other media typesoptionalAll requests should specify the acceptable media types using the Accept header field. If no media type is specified, the response payload shall contain a representation in the default media type for the target resource’s category. If the resource category, of the target resource, has no default media type then the response shall use the application/dicom media type.When an image/jpeg representation is returned, it shall be encoded using the JPEG baseline lossy 8 bit Huffman encoded non-hierarchical non-sequential process ISO/IEC 10918. [ref]It is recommended that the Server also support a "CDA" media type, in conformance to HL7 CDA R2, e.g., text/xml.The origin server may support other media types. All media types supported should be included in the conformance statement and the response from the Capabilities Service.The media types supported by the origin server should be included in the conformance statement, and in the Retrieve Capabilities response.Error CodesThe following errorCodes are defined and shall be used to report any of the associated error and warning situations. Other errorCodes may be present for other error and warning situations.Table 8.4-1.?Error CodesError CodeError Situationurn:dicom:wado:0001Unable to anonymize the requested instance(s).urn:dicom:wado:0002Web Server does not support anonymization.urn:dicom:wado:0003The requested instance(s) are not immediately available, but can be made available by manual request.urn:dicom:wado:0004Instance is no longer available, e.g., document retention rules have caused it to be removed or relocated.urn:dicom:wado:0005The requested instance(s) cannot be returned because the size or count exceeds resource limits.urn:dicom:wado:0006Web Server does not support the requested format or transfer syntax.urn:dicom:wado:0007The requested instance(s) cannot be provided in the requested format or transfer syntax.urn:dicom:wado:0008Single image format is not available for multi-frame images.urn:dicom:wado:0009Identifier does not match SOP Class (see PS3.7 C-MOVE)urn:dicom:wado:0010Inconsistent identifiers, e.g., Study and Series are correct but Series is in a different Study (see PS3.7 C-MOVE)urn:dicom:wado:0011SOP Class not supported (see PS3.7 C-MOVE)urn:dicom:wado:0012Invalid parameter value in request (see PS3.7 C-MOVE)urn:dicom:wado:0013Unsupported parameter in request (see PS3.7 C-MOVE)urn:dicom:wado:0014Processing Failure (see PS3.7 C-MOVE)urn:dicom:wado:0015Study Instance UID not knownurn:dicom:wado:0016Series Instance UID not knownurn:dicom:wado:0017Document UID not knownurn:dicom:wado:0018Out of range Frame numberurn:dicom:wado:0019Presentation UID not knownurn:dicom:wado:0020Presentation Series UID not knownRestful Web Services Protocol (RS)Closed Issues#IssuesOpen Issues#Issues1Should the capabilities service be redefined as a transaction that each service must implement? There are currently two services: 1) studies and 2) worklistShould we generalize the Worklist subscriptions into a general set of notification transactions that can be implemented for each service?Should we define a de-identification transaction for the RS Storage service?Should we define a de-identification transaction for the RS Worklist service?Should the origin server be required to return an error status if there is no acceptable media type as well as a payload describing the supported media types?Should we defined the media type */* to mean that the origin server can return any media type it likes or the default media type for the resource category, or should we define other default media types. If media types are specified and no acceptable media type is available then error no acceptable media type.Proposed CPs#IssuesThe Store transactions for both Storage and Worklist services should be update to return the following status codes:200 OK: The target payload was successfully stored and there is a non-empty response payload201 Created: The target payload did not exist and was successfully stored, Content-Length or Content-Encoding tells whether there is a payload or not202 Accepted: The target payload was successfully receive, but has not been or only partially processed. The payload should contain a Status Details document describing the current status. The user agent can use a Retrieve at a later time to determine the status204 No Content: The target payload was successfully stored and the payload is empty.206 Partial Success: The target payload was partially successfully stored and there may be a Status Details payloadEditorial Issues#IssuesRS Services OverviewThe RS Protocol is composed of the following services:Table 9.2-X: RS Protocol ServicesService NameDescriptionStudiesReturns one or more DICOM objects specified by the target resource in an acceptable media types. WorklistReturns one or more rendered images specified by the target resource in an acceptable media type.Target ResourcesThe target resources of the RS Protocol are typically DICOM Information Entities; but they may be other entities. The general format of resource URI templates is:/resource-type/{resource-id]/resource-subtype/{resource-id}/…{?query}Where,resource-typeis a literal string, for example “studies”, andresource-idis a variable that identifies a specific resourceTransaction OverviewEach transaction is composed of a request message and a response message, sometimes referred to as a request/response pair.Request Message FormatAll RS Protocol request messages have the following format:method?{/resource }{?query}?version?*header-field??[payload]Where,methodThe method used by the transaction.{/resource}A relative URI that specifies the path to the target resource. The base URI is the absolute URI of the service.{?query}The part of the URI that specifies optional query parameters;versionThe HTTP version, either ‘HTTP/1.1’, ‘HTTPS/1.1’, ‘HTTP/2’ or ‘HTTPS/2’.*header-fieldA list of request header fields, one per line.[payload]An optional payload, containing a sequence of octets, which is defined by the transaction.Note1.The ‘?’ in the message above indicates a space character.2.The ’?’ in the message above indicate an ASCII carriage-return followed by a linefeed character.2.HTTP/2 has the same high level syntax as HTTP/1.1. The principle difference is in how the data is framed and transported between the client and server. See [refs < ;, and <;].ResourcesQuery ParametersEach service specifies the query parameters that it supports.Header Fields Required:AcceptSee Section 6.3.1.3PayloadPayloadWhether or not a request has a payload depends on the method, BehaviorThe specific behavior of the origin server is defined by each transaction. The behavior section should include information about the target resource, such as how it is retrieved or modified; how the representation is decided or transformed; the criteria for success or error in the response; and whether or not the response has a payload.ResponseAll RS Protocol response messages have the following format:version?status-code?reason-phrase?*header-field??[payload]Where,version specifies the HTTP version,;status-code is a three digit code describing the result of the request;reason-phraseexists for the sole purpose of associating a textual description with the status code;*header-field?a list of request header fields, one per line;[payload]an optional payload, which is a sequence of octets, that is defined by the transaction.NoteSee the notes in Section 9.4.1.Status CodesThe most common HTTP status codes used by RS services are listed in Table 9.4-1. Most of these codes are described in detail in [RFC7231]. IANA maintains the HTTP Status Code Registry, which contains a complete list of registered status codes.Table 9.4-X: Response Status CodesStatusCode PhraseDescriptionSuccessThe 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.200SuccessIndicates that all target resource representations are contained in the payload.201CreatedIndicates that the request has been fulfilled and has resulted in one or more new resources being created.202AcceptedIndicates that the request has been accepted for processing, but the processing has not been completed. The user agent can use a 203Non-Authoritative InformationIndicates that the request was successful but the enclosed payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy. See [RFC7230], Section 5.7.2.204No-ContentIndicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. This should be the response when content is successfully uploaded and the response has no payload.205Reset ContentIndicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server. This code could be returned in response to a Worklist Service Create Work Item request.Warning206Partial ContentIndicates that some, but not all, of the target resource representations are contained in the payload.This could be because the origin server does not support the media types, transfer syntaxes for some but not all requested content.Client ErrorThe 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.400Bad RequestIndicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request …). Also indicates that no instances were stored due to bad message syntax.401UnauthorizedIndicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resourse.403ForbiddenIndicates that the origin server understood the request, but refused to authorize it (e.g., an authorized user with insufficient privileges). If authentication credentials were provided in the request, the server considers them insufficient to grant access.404Not FoundIndicates that the origin server did not find a representation for the target resource or is not willing to disclose that one exists. This might be a temporary condition. If the origin server knows that the resource has been deleted the 410 (Gone) status code is preferred over 404.405Method Not AllowedIndicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.406Not AcceptableIndicates that the target resource does not have a representation that would be acceptable to the user agent, according to the content negotiation header fields in the request, and the server is unwilling to supply a default representation.The server SHOULD generate a payload containing a list of available representation characteristics (media types) and corresponding resource identifiers from which the user or user agent can choose the one most appropriate.409ConflictIndicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.This code might Indicate that the origin server was unable to store any instances due to a conflict in the request (e.g., unsupported SOP Class or SOP Instance mismatch).I410GoneIndicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) ought to be used instead.411Length RequiredIndicates that the server refuses to accept the request without a defined Content-Length.413Payload Too LargeIndicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process.414URI Too LongIndicates that the server is refusing to service the request because the request-target (Section 5.3 of [RFC7230]) is longer than the server is willing to interpret.415Unsupported Media TypeIndicates that the origin server does not support the Content-Type in the request payload.Server ErrorThe 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.500Internal Server ErrorIndicates that the server encountered an unexpected condition that prevented it from fulfilling the request.501Not ImplementedIndicates that the server does not support the functionality required to fulfill the request.503Service UnavailableIndicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.505HTTP Version Not SupportedIndicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message.Header FieldsRequired:Content-TypeRequired if there is no Transfer-Encoding header field:Content-LengthRequired if a new resource has been created:LocationOptional:Content-LocationContent-EncodingWarningSee Section 6.3.1.3.2Response PayloadPayloadBoth requests and responses can have payloads. Messages that have a payload typically have Representation and Payload Header Fields. The RS protocol can have single part or multipart payloads depending on the media type. See Section 6 for details.Content-Type and Content-Location header fields. There are two basic payload structures: single part and multi-part.Each part in a multi-part payload shall start with a boundary string, followed by Content-Type and Content-Location header fields, followed by either a Content-Length or a Transfer-Encoding header field, optionally followed by a Content-Description header field.RS Media TypesTable 6.3-2 contains default, required, recommended, and optional media types for the URI service. The RS protocol does not have any default media types. The origin server determines the media type of the response based on the Accept header field and the target resource. If no Accept header field is contained in the request, the media type of the response payload, if any, shall be the default media subtype. If not default media type is defined for the resource’s category then the origin server shall return a 4zz error and should include a Status Details document that describes the media types available for the resource type. Table 9.3-x: RS Media TypesResource CategoryMedia TypeRequirementReferenceDICOMapplication/dicomdefaultRFC3240application/dicom+jsonrequiredapplication/dicom+xmlrequiredapplication/jsonrequiredImage (single frame)image/jpegdefaultISO/IEC 10918Image/dicomrecommendedImage/dicom+jpgrecommendedImage/dicom+jpg-lsrecommendedimage/jp2requiredimage/gifrequiredimage/pngrequiredImage (multi-frame)image/dicom+jpxrecommendedImage/gifrecommendedVideovideo/mpegrecommendedVideo/mp4recommendedText Objectstext/htmlrequiredtext/plainrequiredtext/rtfrecommendedtext/xmlrecommendedapplication/pdfrecommendedOther Objectsapplication/dicomrequiredRFC3240other media typesoptionalWhen an image/jpeg media type is returned, the image shall be encoded using the JPEG baseline lossy 8 bit Huffman encoded non-hierarchical non-sequential process ISO/IEC 10918. [ref]NoteThe media types supported by the origin server should be included in the conformance statement and in the Capabilities Description document.The media type defines the format of the representation(s) contained in the payloadAcceptable Media TypeThe term “acceptable media type” is used throughout this part of the Standard. It means:a media type that is contained in the Accept header field of the request; or, if the request has no Accept header field it means the default media type for the target resource. If no default subtype is defined then the media type will be determined by the origin server. If the origin server supports no acceptable media type it shall return an error response. If there is no default subtype then the origin server should return an error status code of 415 (Unsupported Media Type).The phrase “an acceptable media type” is used throughout the RS protocol to mean:One of the media types contained in the Accept header field(s) of a request; orIf the request does not contain a request header, the default media type for the resource, if defined.Some resources contain more than one type of object, for example studies typically have images and reports (text base objects). The user agent should include image, muli-frame image and text base media types in the accept header.Multipart Related Media TypeImaging Media Types and Transfer SyntaxOrigin servers implement the RS protocol shall be prepared to handle transfer syntax parameters for all imaging media types. The syntax is:*(media-type *(“;” “transfer-syntax” “=” {transfer-syntax} ) )For example, an Accept header field might look as follows:Accept: application/dicom; transfer-syntax=1.2.840.10008.1.2.4.70, ; transfer-syntax=1.2.840.10008.1.2.4.71Retrieve Capabilities TransactionThe Retrieve Capabilities transaction requests that the request target, which shall be an RS service, returns a Capabilities Description document, which is machine readable. The Capabilities Description document describes the transactions, resources, representations, etc. supported by the service.All RS origin servers shall support the Retrieve Capabilities transaction. The Capabilities Description document shall describe the service in as much detail as possible.The Retrieve Capabilities transaction supports the transaction in Table 9.8-1. Table 9.4-1: Retrieve Capabilities TransactionTransactionURI TemplateDescriptionRetrieve Capabilities/Retrieve a Capabilities Description document from the service in an acceptable media type.RequestThe Retrieve Capabilities request uses the OPTIONS method and has the following format:OPTIONS?/?version?*header-field??ResourcesThe only target-resource supported by this transaction is the service itself. The target-URI, ‘/’, is the base URL for the service. See Section 9.2.1 for detailsQuery ParametersThis transaction has no defined query parameters.Header FieldsRequired:AcceptRecommended:Content Negotiation Header FieldsSee Section 6.3.1.3.PayloadThe request has no payload.BehaviorThe origin server will return a machine readable description of its capabilities in an acceptable media type.ResponseThe format of the response is as follows:version?status-code?reason-phrase?Content-Type: media-type?*header-field??[payload]A success response shall have a payload containing a Capabilities Description document encoded in a media type consistent with the Accept header of the request.Status CodesA success response will have a status code of 200 (OK). A failure response shall have a status code from Table X.Y-Z, and should include a Status Details document.Header FieldsRequired:Content-TypeSee Section 6.3.1.3.2.PayloadA success payload contains a Capabilities Description document in an acceptable media type.A failure response may have an empty payload; however, it is recommended that it contains a Status Details document. See Section 7.2.3.3.Media TypesThe Retrieve Capabilities service supports the following media types:application/vnd.sun.wadl+xmlSee Annex X, Y-z.Notification Subservice An RS service may implement a Notification Subservice. This subservice enables user agents to be notified of events associated with resources managed by the Service. If a Service defines a Notification Subservice, user agents may open a notification channel to an origin server implementing the Service. Such user agents are called subscribers.A Service may offer different types of subscriptions. The Service defines the types of subscriptions that it supports and each implementation of the Services shall maintain a list a subscribers for each type of subscription it offers. Subscribers receive notifications of events associated with the resource(s) to which they have subscribedA subscriber to a resource should be able to receive all notifications and possibly filtered notifications. The Service defines any filters that can be applied to a stream of notifications.Upon receipt of the Create Subscription, Suspend Global Subscription or Delete Subscription request, the origin server shall attempt to update the appropriate subscription state Global Subscription State, Filtered Global Subscription and/or Work Item Subscription State of the specified Application Entity with respect to the specified SOP Instance UID as described in Table?CC.2.3-2 in PS3.4 and then return an appropriate response.Deletion LocksFiltersResourcesEach service defines the resources to which user agents may subscribe.Service EventsHowever, any RS service is itself a resource, and there are some standard event types defined for all services. All origin servers who implement the Notification Subservice should provide the following service related event notifications:Server shutting downServer load increasing?Server low on resources?Server problem?TransactionsAny service that supports the Notification Subservice must support the following transactions:A user agent can subscribe to the three types of resources in the following table:Table 12.2-1: Notification Subsystem TransactionsNameTarget URIDescriptionOpen Channel/The user agent requests that the origin server upgrade the connection to a Notification Channel using a WebSocket.Send Event/The origin server sends an Event Report to a subscriber (a user agent). Create Subscription/Receive event notifications for any Work Item in the Worklist that passes a specified subscription filter.Delete Subscription/Open Event Channel TransactionThe Open Event Channel transaction is only define in this section. This transaction may not be defined by the service implementing the Notification Subservice. It is the same for all services.This transaction opens a WebSocket channel that will be used to send Event Reports to the client. The WebSocket connection can use the same TCP port as the HTTP connection, but they are separate connections.See RFC-6455 for details of the WebSocket protocol.RequestThe request shall have the following format:GET?/?version?Host: server.?Upgrade: websocket?Connection: Upgrade?Sec-WebSocket-Key: {key}?Sec-WebSocket-Protocol: {protocols}?Sec-WebSocket-Version: {ws-version}?*header-field??Query ParametersThere are no query parameters defined, but the service defining this transaction may define query parameters.Header FieldsRequired:Upgrade: websocketConnection: UpgradeSec-WebSocket-KeySec-WebSocket-ProtocolSec-WebSocket-VersionPayloadTypically the request has no payload, but the actual payload is defined by the service.BehaviorThe origin server upgrades the HTTP connection to a WebSocket connection and records the association between the user agent and the WebSocket. In the future the origin server will use this WebSocket connection to send Event Reports for any Work Items that have subscriptions from the user agent.The origin server opens and maintains the active WebSocket connection to the user agent and uses it to send Event Report messages for Work Items that have subscriptions from the user agent. See Section?6.9.7.2, “Behavior”).The connection shall remain open and may be used by the server to send Event messages (see Section 6.9.11, “SendEventReport”).If the WebSocket connection is lost at any point the user agent can re-establish it by repeating the request.The state of a WebSocket connection does not affect subscriptions and an origin server is not required to queue messages when the connection is down.NoteA user agent will only receive the initial state of a newly-subscribed Work Item if the WebSocket connection was initiated prior to creating the subscription.ResponseThe response shall have the following format:version?status-code?reason-phrase?Upgrade: websocket?Connection: Upgrade?Sec-WebSocket-Accept: response-key?Sec-WebSocket-Protocol: protocol?*header-field??Status CodesA success response will contain a status code of 101 (Switching Protocols), which indicates that the origin server has opened the connection.A failure response will contain an appropriate status code from Table .Header FieldsRequired:Upgrade: websocketConnection: UpgradeSec-WebSocket-AcceptSec-WebSocket-ProtocolPayloadThe payload is defined by the service. An error payload should contain a Status Details document.Media TypesThis transaction shall specify no media types in the request or response.Send Event Report TransactionThis transaction sends Event Reports from the origin server to a user agent over an established WebSocket connection.RequestThe request will use the WebSocket Data Frame transmission protocol.PayloadThe Event Report shall contain all mandatory attributes described in Table?CC.2.4-1 in PS3.4 and Table?10.3-1 in PS3.7 for the event type.Event Report FormatEvents Reports are encoded as WebSocket data frames with an opcode of "%x1" (text).The frame payload data shall be a DICOM JSON dataset containing the attributes of the Event Report.The following is an example WebSocket payload:{"00000002": [ "1.2.840.10008.5.1.4.34.6.4" ],"00000100": [ 256 ],"00000110": [ 23 ],"00001000": [ "1.2.840.10008.5.1.4.34.6.4.2.3.44.22231" ],"00001001": [ 1 ],"00741238": [ "SCHEDULED" ],"00744041": [ "READY" ]}?The WebSocket protocol does not allow content negotiation so it is not possible to support both XML and JSON encoding of Event Report messages without extending the protocol.BehaviorPS3.4, Section CC.2.4.3 describes the scenarios in which an origin server sends Event Reports to a subscriber, as well as the content of the Event Report messages.ResponseThere is no response.Create Subscription TransactionThis transaction records subscribers to whom future events associated with the specified resources will be reported.RequestThe request shall be formatted as follows:POST?/{+resources}{?deletionlock,filter}?version?Content-Length: 0?*header-field??Where,resourcesis defined by the service.deletionlock= true / falseIf present, shall have a value of ‘true’ or ‘false’, indicating whether or not the user agent is requesting a Deletion Lock.filter= *{attribute-value-pair}If present, specifies the attribute-value pairs describing the filter parameters. See Section 6.7.1.1 for {attribute} and {value} encoding rules.Header FieldsRequired:Content-Length: 0See Section 6.3.1.3PayloadTypically the request has no payload, but the actual payload is defined by the service.BehaviorThe origin server shall create a subscription to the target resource for the user agent.The origin server shall support the management of subscriptions as specified by the SCP behavior in PS3.4, Section CC.2.3.3.Upon receipt of the Create Subscription, Suspend Global Subscription or Delete Subscription request, the origin server shall attempt to update the Global Subscription State, Filtered Global Subscription and/or Work Item Subscription State of the specified Application Entity with respect to the specified SOP Instance UID as described in PS3.4, Table CC.2.3-2 and then return the appropriate response.ResponseThe response shall have the following format:version ?status-code ?reason-phrase?Location: {+web-socket}?Content-Length: 0?{*header-field?}?[payload]Where,{+web-socket}is the base URL for the WebSocket service. This shall include the WebSocket protocol (either WS or WSS) and may include a combination of authority and path.Status CodesA success response shall contain a status code of 201 (Created). A failure response shall contain a status code from Table .Header FieldsRequired:LocationRequired if the Create Subscription request was accepted but the Deletion Lock was not, the response shall include the following Warning header field: Warning: 299 {+service}: Deletion Lock not granted.Required if the request was rejected with a status code of 403, because Filtered Global Subscriptions are not supported, the response message shall include the following Warning header field:Warning: 299 {+SERVICE}: The origin server does not support Global Subscription Filtering.PayloadThe payload is defined by the service. An error payload should contain a Status Details document.Media TypesThe service shall define all media-types supported.Delete SubscriptionThe target resource must be a resource to which the user agent has subscribed. If the “suspend” query parameter is “true” any current subscription are left in place, but no more subscriptions shall be created for the target resource. If the “suspend” parameter is “false” all current subscriptions to the target resource are deleted and no more will be created. If the “suspend” parameter is not present, it’s value is “false”.If the target resource is the Worklist and the “suspend” query parameter is “true” then all future subscriptions to Work Items are cancelled. If the “suspend” query parameter is either “false” or not present, the all current and future subscriptions are cancelled.RequestThe request shall be formatted as follows:DELETE? /{+subscription}{?suspend}?version?Content-Length: 0?*header-field??Query Parameterssubscriptiona URI referencing the subscription.?suspend=true / falseIf present and its value is “true”, it indicates that the subscription should be suspended, i.e. current subscriptions should not be deleted, but no future subscriptions shall be created. If it is not present or its value is “false” all current subscriptions to the resource are deleted and no future subscriptions shall be created.Header FieldsRequired:Content-Length: 0PayloadTypically the request has no payload, but the actual payload is defined by the service.BehaviorIf the “suspend” query parameter is “true” the origin server shall no longer automatically subscribe the user agent to newly-created Work Items; however, this does not delete existing subscriptions to Work Items. If the “suspend” query parameter is “false” or not present the origin server shall remove any of the user agent’s existing subscriptions to the target resource.The origin server shall conform to the behavior described in Section 12.1.8.4, “Behavior”.ResponseThe response shall have the following format:version?status-code?reason-phrase?Content-Length: 0?*header-field??Status CodesA success response shall contain a status code of 200 (OK), indicating that the target subscription(s) have been suspended or deleted.A failure response will contain an appropriate status code from Table 12.2-A.Header FieldsRequired:Content-Length: 0PayloadThe payload is defined by the service. An error payload should contain an Status Details document.Media TypesUnless specified otherwise in the transaction definition, the Notification Subsystem supports the following media types:application/jsonapplication/dicom+jsonRestful Studies ServiceClosed Issues#IssuesOpen Issues#IssueStatusCan the ‘deidentify’ parameter be used with the Retrieve DICOM service? Needs a CPEditorial Issues#IssueStatusChanged URI template variables to be lowercase with ‘_’ separating words (snake case)ClosedThe RS Storage Service defines a set of transactions that enable a user agent to store, retrieve, and search an origin server for studies, series, instances, frames, and bulkdata, along with their metadata variants.ResourcesThe resources managed by the Storage Service are a collection of DICOM Studies. The resources are conceptually organized in a tree hierarchy that corresponds to the DICOM Information Entity Model (see xxx), that is, Study, Series, and Instance.The following URI template variables are used in the definitions of the resources in Table 10.1-1:{study_uid}the Study UID of a study contained in the Studies resource.{series_uid}the Series UID of a series contained within the parent resource.{instance_uid}the SOP Instance UID of an instance contained within the parent resource.{frames}a comma-separated (comma = %2C) list of frame numbers in ascending order contained within a single instance.{+bulkdata}a URI that references a bulkdata resource.The Storage Service defines the following resources:Table 10.1-1: RS Resource Names, URI Templates and DescriptionsNameURI Template and DescriptionService/The Service resource is the base URI of one or more RS Services.All Studies/studiesThe All Studies resource references the entire collection of studies contained in the Studies Service. All RS Storage Service resources begin with this resource.Study/studies/{study_uid}The Study resource references a single study.Study Metadata/studies/{study_uid}/metadataThe Study Metadata resource references the metadata of a single study. Study Metadata is defined to be all attributes in the specified study, where any values larger than a threshold defined by the origin server may be replaced by a Bulkdata Reference. This threshold is typically in the range: 128 <= threshold <= 1024 bytes.All Series/seriesThe All Series resource references the collection of all series in all studies contained in the Studies Service.Study’s Series/studies/{study_uid}/seriesThe Study’s Series resource references the collection of all series contained in a study.Series/studies/{study_uid}/series/{series_uid}The Series resource references a single series in a study Series Metadata/studies/{study_uid}/series/{series_uid}/metadataThe Series Metadata resource references the metadata of a single series in in a study.All Instances/instancesThe All Instances resource references the collection of all instances in all series in all studies contained in the Studies Service.Study’s Instances/studies/{study_uid}/instancesThe Study’s Instances resource references the collection of all instances in a single study.Series’ Instances/studies/{study_uid}/series/{series_uid}/instancesThe Series’ Instances resource references the collection of all series in a single study.Instance/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}The Instance resource references a single instance contained in a series.Instance Metadata /studies/{study_uid}/series/{series_uid}/instances/{instance_uid}/metadataThe Instance Metadata resource references the metadata of a single instance contained in a series.Frame List/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}/frames/{frame_list}The Frames resource references an ordered collection of frames in a single multi-frame instance. Bulkdata{+bulkdata}The Bulkdata resource references one or more bulkdata objects. Bulkdata URIs are contained in a metadata resource. A metadata resource must be retrieved first, then the bulkdata URIs that it contains can be used to retrieve bulkdata resources. The URI is determined by the origin server. It is not specified by this standard.TransactionsThe Storage Service defines the six transactions specified in the following table:Table 10.2-1: Storage Service TransactionsTransactionMethodRequestPayloadResponsePayloadDescriptionRetrieveCapabilitiesOPTIONSEmptyCapabilities DescriptionRetrieves a description of the capabilities of the storage service, including transactions, resources, query parameters, etc.Retrieve DICOMGETEmptyInstance(s)or PDRetrieves one or more representations, specified by the target resource in an acceptable DICOM media type.Retrieve RenderedGETEmptyRenderedinstance(s)or PDRetrieves one or more representations, specified by the target resource, which shall not be a presentation state, in an acceptable rendered media type(s).Retrieve PSGETEmptyRendered PS instanceRetrieves one or more representations, specified by the target resource, which shall be a presentation state instance, in an acceptable rendered media type(s).StorePOSTInstance(s)Empty or PDStores one or more DICOM representations, contained in the request payload, in the location referenced by the target resource.SearchGETEmptyResult(s)Searches the target resource for objects that match the search parameters and returns a list of matches in an acceptable media type.Open Event ChannelOpens a WebSocket channel between the user agent and origin server, which the origin server uses to send event notifications.Send Event ReportSends an Event Notification Report from the origin server to the user agent.CreateSubscriptionDeleteSubscriptionTable 10.2-2 shows the resources defined for each transaction.Table 10.2-2 Resources by TransactionResourceRetrieveDicomRetrieveRenderedRetrievePSStoreSearchCapabilities/XAll StudiesXXStudyXXXXStudy MetadataXXAll SeriesXStudy’s Series??XSeriesXXSeries MetadataXXAll InstancesXStudy InstancesXXXSeries’ InstancesXXXInstanceXXXXInstance MetadataXFrame ListXXXRetrieve DICOM TransactionThe Retrieve DICOM transaction retrieves the target resource in a DICOM media type.RequestThe Retrieve DICOM services has the following retrieve message format:GET?{/resource}{?deidentify}?version?*header-field??Where,deidentify = yes / noSee Section 10.3.1.2.1 for details.ResourcesThe Retrieve DICOM transaction supports the resources listed in Table 10.3-1. If an origin server supports this transaction it shall support all resources.Table 10.3-1 shows the resources, with their URI templates, supported by the Retrieve DICOM transaction.Table 10.3-1: Resources, Templates, and DescriptionTarget ResourceResource URI TemplateStudy/studies/{study_uid}Retrieves a study in an acceptable DICOM media type.Study Metadata/studies/{study_uid}/metadataRetrieves the metadata for a study in an acceptable DICOM media type.Series/studies/{study_uid}/series/{series_uid}Retrieves a series in an acceptable DICOM media type.Series Metadata/studies/{study_uid}/series/{series_uid}/metadataRetrieves the metadata for a series in an acceptable DICOM media type.Instance/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}Retrieves a instance in an acceptable DICOM media type.Instance Metadata/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}/metadataRetrieves the metadata for an instance in an acceptable DICOM media type.Frames/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}/frames/{frame_list}Retrieves one or more frames in an acceptable DICOM media type.Bulkdata{/bulkdata}Retrieves one or more bulkdata items in an acceptable DICOM media type.Query ParametersDe-Identificationdeidentify = yes / noThe “deidentify” parameter is optional and has a value of ‘yes’ or ‘no’. It specifies that the target resource shall have all Personally Identifiable Information (PII) removed. This includes removing or "blanking out" any area(s) containing PII burned into the pixels or in overlays in the return representations. This process is called de-identification and is sometimes referred to as anonymization; although, the latter term is discouraged. See PS3.15 Section E. Attribute Confidentiality Profiles.De-identification is the responsibility of the origin server. De-identified objects shall have a new SOP Instance UID that is different from that of the original identified objects. The Server may return an error if either it cannot or refuses to de-identify the requested objects.Header FieldsRequired:AcceptSee Section 6.3.1.3PayloadThe request has no payload.BehaviorThe origin server locates the target resource and returns in an acceptable DICOM media type.ResponseThe response has the following format:version?status-code?reason-phrase?Content-Type: dicom-media-type?*header-field??[payload]Where,dicom-media-type is one of the media types defined in Table 10.3-X and Annex X.Status CodesThe following status codes are defined for the RS Protocol and shall be used to report any of the associated error and warning situations. Implementers may use other status codes for other error and warning situations. Table 10.3-X: Status CodesStatusCodePhraseDescriptionSuccess200OKIndicates that all instances were successfully retrieved.Warning206Partial ContentIndicates that the response contains some, but not all, of the requested content.ErrorSee Table X.Y-ZHeader FieldsRequired:Content-TypeSee Section 6.3.1.3.2PayloadA success response has a payload containing one or more representations of the DICOM instances specified by the target resource. The payload may be single part or multipart depending on the media type.An error response may have no payload; however, it is recommended that failure responses contain a Status Details document that describes the problems encountered by the origin server.Media TypesDICOM Pixel data shall be encoded using the media types in Table 9.2-1. These media types have a corresponding transfer syntax that is specified by a UID which is the value of the transfer syntax parameter. The column marked DFT indicates the default transfer syntax (D) for a specific media type. For imaging media types without a default, the Explicit VR Little Endian transfer syntax will be used, if a transfer syntax parameter is not specified. See PS3.5 and PS3.6.Origin servers implementing the RS protocol shall be prepared to handle transfer syntax parameters for all imaging media types. The syntax is:media-type; transfer-syntax={transfer-syntax}For example, an Accept header field might look as follows:Accept: multipart/related; type=”application/dicom”; transfer-syntax=1.2.840.10008.1.2.4.70orAccept: application/json; transfer-syntax=1.2.840.10008.1.2.4.70Table 10.3-1: DICOM Image Media Types and Legal Transfer SyntaxesMedia TypeTransfer Syntax UIDDefault NameSingle Frame ImageImage/dicom+evle1.2.840.10008.1.2.1DExplicit VR Little EndianNote: Equivalent to the application/octet-stream media type.image/dicom+jpeg1.2.840.10008.1.2.4.50JPEG Baseline Lossy 8 bit 1.2.840.10008.1.2.4.51JPEG Extended Lossy 12 bit1.2.840.10008.1.2.4.57JPEG Lossless, Non-Hierarchical1.2.840.10008.1.2.4.70DJPEG Lossless, Non-Hierarchical, First Order Predictionimage/dicom+rle1.2.840.10008.1.2.5DRLE Losslessimage/dicom+jpeg-ls1.2.840.10008.1.2.4.80JPEG-LS Lossless1.2.840.10008.1.2.4.81JPEG-LS Lossy (Near Lossless)image/dicom+jp21.2.840.10008.1.2.4.90DJPEG 2000 Lossless1.2.840.10008.1.2.4.91JPEG 2000image/dicom+jpx1.2.840.10008.1.2.4.92DJPEG 2000 Part 2 Multi-component Lossless1.2.840.10008.1.2.4.93JPEG 2000 Part 2 Multi-component Multi-Frame Imageimage/dicom+jpx1.2.840.10008.1.2.4.92DJPEG 2000 Part 2 Multi-component Lossless1.2.840.10008.1.2.4.93JPEG 2000 Part 2 Multi-componentVideovideo/mpeg1.2.840.10008.1.2.4.100MPEG2 Main Profile @ Main Level1.2.840.10008.1.2.4.101MPEG2 Main Profile @ High Levelvideo/mp41.2.840.10008.1.2.4.102MPEG-4 H.264 High Profile1.2.840.10008.1.2.4.103MPEG-4 H.264 BD-compatible High ProfileSee Sections 6.3.5 and 9.2.4 for information about RS Protocol media types.Digital Imaging and Communication in Medicine (DICOM)RS Supplement 174: Rendering for Restful Services**** Begin Remove before Public Comment ****Note:WG-06 believes that the decision as to what parameters should be included in RS Rendering, should be based on what is easy to do in a user agent without putting stress on the CPU or memory system.Scope for RenderingDentistry is out of scopeShould be Diagnostic quality renderingRendering will not be fully specifiedShould allow only presentation states to be rendered? What are the consequences? Request should be able to include a PS specification payload.What about Documents?They are different media typeEditor’s Note:The new HTTP/1.1 standard (RFC 7231 Section 3.3) recommends that:Response messages with an error status code usually contain a payload that represents the error condition, such that it describes the error state and what next steps are suggested for resolving it.Editorial Issues#IssueStatus1Is there any reason to de-identify a rendered image? Yes notes in PS.2Is there any reason to de-identify other rendered objects?Documents? YesOther types??3What is the correct ordering of the rendering parameters according to the rendering pipeline?4How should the parameter definition sections be ordered – by pipeline or alphabetically?Decision: AlphabeticallyClosed5Should the region parameters be named (top, left, bottom, right) or (xMin, yMin, xMax, yMax)?Mathworks (x, y, width, height) in pixelsImageMagick(width, height, xOffset, yOffset)IIIF ImageAPI(x, y, w, h) or (pct: x, y, w, h) where 0, 0 is upper left corner6Should Flip and Rotate be done before or after the Region is selected? After?**** End of Remove before Public Comment ****Closed Issues1Should unknown parameter keywords be ignored or should they generate errors?Decision: Unknown parameters should be ignored. URI and WS should also ignore unknown parameters.2Can vendors add other parameters? YES. Any vendor defined parameters should be specified in their Conformance Statement and in their Service Capabilities response.3What should we do if the region parameter is ill defined?Decision: return an error.4Should there be a separate service for rendering?Yes. There should be three separate retrieve services. One for DICOM, one for rendered images using query parameters, and one for rendered images using presentation states. The render presentation state service should only reference presentation states.5Should Accept headers be in preference order?No. Proxies won’t preserve the ordering. The ‘q’ (quality) parameter can be used to specify preference order.6Should we add the ability to specify VOILUT function, and/or which VOILUT by number? No. A Presentation State instance has only one VOILUT.7If no parameters are supplied by the user agent, how should the response payload be rendered?Decision: rendered in TRUE SIZE with no transformation applied.8Should a ‘viewport=rows, columns’ parameter be included. It makes the scaling choice easier for the user agent. The semantics would be that the origin server would scale the image to the largest size possible while maintaining the original aspect ratio.Yes. “Viewport” should be included and “rows” and “columns” should not be supported by RS Retrieve Rendered.9Should we keep the Retrieve Rendered Presentation Study and Series transactions? Are the semantics clear enough? If so what should the behavior be? What is the best heuristic?No. Only one PS instance can be retrieved11aPart 1: Should implementations of RS rendering services be required to support all composite SOP classes? No. List in conformance statement and Capabilities Descriptions.14Should Rendering support all the photometric interpretations?Decision: “Supported SOP Classes, with their implied photometric interpretations, shall be specified in Conformance Statement and Capabilities Description. Do not see a need to mandate a baseline.”18Should the rendered PS transaction have a ‘deidentify’ parameter. Yes, On a best efforts basis. The origin server can refuse to de-identify any instance.43Which parameters can be used with presentation states?Decision: The only parameters that can be used with PSes are ‘annotation’, ‘deidentify’, ‘imageQuality’, and ‘viewport’.Open Issues#IssueStatusGeneral0What are the target use cases for RS RenderingDisplay one image per URI inside a report, email, or other document?Display multiple images per URI inside a report, email, or other document?Retrieve images for display in a web based clinical viewer?Retrieve images for display in a web based diagnostic viewer?What others?10Should RS rendering services be mandatory if you implement RS Retrieve? (leaning toward No)11bPart 2: Should implementations have to be able to support any objects that it can retrieve as native DICOM (leaning towards No).12Part 1: Should the Rendering Services support Structured Display? (Dental and eye care) supply references. Part 2: Should the supplement address this?Part 3: If defined, should it be a separate transaction?13Should we specify how interpolation is done for images that are being magnified and then scaled to fit a viewport? What about images that are smaller than the viewport?*Take a look at IHE mamo profile, and Pathology whole slide IOD.Should we have an interpolation algorithm parameter?*If the origin server does a non-linear interpolation it should say so.Is there a way to get derivation information into an overlay, so that it is visible?JFP Todo15What status code should we use for partial success, i.e., some instances were unable to be rendered, some frames rendered but not all? RS Retrieve* uses 206 and RS Store uses 202? Should we create our own status code? We could request one from IANA - extensions for RS rendering will be retrofitted to URI? To the extent that they can be. Since URI can only return one object, some of the functionality in RS will not be possible to retrofit.17Can we define the grayscale and color space, if the window on the user agent device can be calibrated?For dumb clients there is not much we can do; however, for smart user agents, what information can they provide, what parameters should they use to transmit the information, and what should the server be required to do with that information. For example, clients could measure ambient light, send it to the server in a parameter and the server could re-render the image appropriately. In other words, who is responsible for applying calibration information – the client or the server?19Do we need to say anything about making measurements on rendered images?20Should origin servers be required to support all the rendering query parameters? If not, what should be done if the origin server is unable to perform all the transformation specified in the request?21What should be done in the cases of Partial Success of transformations, i.e. where some transformations where not able to be applied to all instances?Return an error with a description of the problems.Return the images that were successfully rendered, with a message in the Warning header field?Other?22Can the ‘deidentify’ parameter be used with the Rendering services?Specific Parameters30Part 1: Should we extend the “annotation” parameter to use the DICOM keywords or tags in IHE BIR to specify the annotations?Part 2: Should we specify where the information goes on the screen? If so, how would be specify the locations?31When should annotations be applied? Proposal after the region is selected and scaled to the appropriate size. This is not specified in the PS pipelines.33Should the “order” of Images parameter be included? When the user agent receives a set of images, It cannot reorder the images in any meaningful way because it has no information that lets it change the order in a meaning full way; unless the user agent retrieved the metadata first.34Should the “rotate” parameter be included?35Should the “flip” parameter be included?36Should the server defined presets be included in the “window” parameter?37Is there anything missing from the Retrieve Rendered service?Should the coordinates of the “region” parameter be in pixels or normalized from 0.0 to 1.1? The browser would typically generate the units in pixels.Presentation States40Should Blending Presentation States be allowed to be supported?42What Presentation State SOP classes should be included in Presentation State rendering? All of them? 2D only? 3D? What 3D?Should any be mandatory?Should all supported SOP classes be specified in the Conformance Statement?44Can presentation states refer to non-image object? Yes, so they must be considered when de-identifying themdelete49Is there anything missing from the Retrieve Rendered Presentation State service?.RS Retrieve Rendered TransactionThe Retrieve Rendered service retrieves DICOM objects rendered as: images, text based documents, or other appropriate representations depending on the resource. Its primary use case is to provide user agents with a simple interface for displaying medical images and related documents, without requiring deep knowledge of DICOM data structures and encodings. It is similar to the Retrieve DICOM service in that it uses the same method, resources, header fields and status codes. The primarily difference is the query parameters and media types supported.If the target resource references contains any presentation state instances they shall not be rendered.If the region parameter is not present, images are rendered in their original size.RequestThe Retrieve Rendered service has the following request message format:GET?{resource-path}{?query*}?version?*header-field??Where, query = zero or more query parameters as defined in Section 10.4.1.2 below.Target ResourcesTable 10.4-1 shows the resources supported by the Retrieve Rendered transaction along with their associated URI templates.Table 10.4-1: Resources, Templates, and DescriptionTarget ResourceResource URI TemplateStudy/studies/{study_uid}Retrieves a study in an acceptable rendered media type.Series/studies/{study_uid}/series/{series_uid}Retrieves a series in an acceptable rendered media type.Instance/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}Retrieves a instance in an acceptable rendered media type.Frames/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}/frames/{frame_list}Retrieves one or more frames in an acceptable rendered media type.Bulkdata{/bulkdata}Retrieves one or more bulkdata items in an acceptable rendered media type.The specified resource shall not contain any presentation state series or instances.Query ParametersThis service defines query parameters that specify how the identified instance(s) is rendered. The parameters defined in this section specify various rendering transformations to be applied to the images contained in the target resource.The following rules pertain to all parameters defined in this section:All parameters are optional for the user agent.The “deidentify” and “order” parameters are optional for the origin server; all other are required. These parameters only apply to resources that are images and video as defined in Section 9.3.6.These parameters do not apply to resources that are not images or video. Instances that are not images will be rendered in an acceptable media type, if one exists; otherwise, they will not be rendered.The data types of the parameter values are defined in Section [ref]Unless otherwise specified the image(s) are rendered in their original size. For example, when no parameters are supplied.The set of transformations specified by the parameters in this section shall be applied to the target resource images as if they were a presentation state, that is, in the order specified by the applicable image rendering pipeline specified in PS 3.3.Table 10.4-2: Query Parameters for the Retrieve Rendered ServiceKeyValuesTypeR/ODescriptiondeidentify‘yes’ or ‘no’ORemove all Personally Identifying Information from the target resource.orderkeywordOOrder of the return images.regionx, y, width, heightintegerRThe sub-region of the image(s)flipkeywordRFlip the image(s) along their ‘horizontal’ or ‘vertical’ axis.rotatedegreesintegerRRotate the image by 90 degree increments from -270 to 270.windowcenter, width or keyworddecimalRSet the Window LevelannotationkeywordRAnnotates the image(s) with information.viewportwidth, heightintegerRScales the images to the size of the viewportqualityfactorintegerRSpecifies the quality (1 <= integer <= 100) of lossy compressed images.Annotation on the Imageannotation = (patient / procedure) / #{attribute}The “annotation” parameter specifies that the target resource shall be annotated with information about the patient and/or procedure. If this parameter is not present, the returned images shall have no annotations applied. The parameter value is a non-empty comma-separated list of either:patientfor displaying patient information on the image(s) (e.g. name, birth date, etc.)procedurefor displaying information of the procedure or technique usedattributeone or more of the attribute identifiers defined below in Table 10.4-3.The annotation may be burned into the returned image pixels or overlays may be used.When used in conjunction with the “region” and/or “viewport” parameters, the annotations shall be applied after the region has been selected and the image(s) scaled to the appropriate size.If the “deidentify” parameter is present, no Personally Identifiable Information shall be present in the annotations. The ‘patient’ keyword and any patient attributes shall be ignored by the origin server. The exact nature and presentation of the annotations is determined by the origin server. Any additional annotation attributes supported by the server should be documented in the Conformance Statement and in the Retrieve Capabilities response.Table 10.4-3: Attribute IdentifiersKeywordTagNotesPatient IdentifiersPatientName00100010PatientID00100020PatientBirthDate00100030PatientSex00100040InstitutionName00080080StudyID00200010AccessionNumber00080050SeriesNumber00200011SeriesDescription0008103EAcquisitionDateTime0008002Aif present, else AcquisitionDate (0008,0022) and AcquisitionTime (0008,0032), if present, else ContentDate (0008,0023) and ContentTime (0008,0033), if present, else SeriesDate (0008,0021) and SeriesTime (0008,0031), if present, else StudyDate (0008,0020) and StudyTime (0008,0030)Procedure IdentifiersInstanceNumber 00200013(for correlation with slices described in the report)SliceLocation 00201041If present, else TablePosition (0018,9327), if present elsea value derived from ImagePosition (Patient) (0020,0032)SliceThickness00180050SpacingBetweenSlices00180088if present, else a value derived from successive values of Image Position (Patient) (0020,0032) perpendicular to the Image Orientation (Patient) (0020,0037)IVContrastUsedSee noteswhether or not intravenous contrast was used (C+/-), derived from Contrast/Bolus Agent Sequence (0018,0012), if present, else Contrast/Bolus Agent (0018,0010)CompressedSee noteswhether or not lossy compression has been applied, derived from Lossy Image990 Compression (0028,2110), and if so, the value of Lossy Image Compression Ratio(0028,2112) and Lossy Image Compression Method (0028,2114), if present (as per FDA Guidance for the Submission Of Premarket Notifications for Medical Image Management Devices, July 27, 2000)WindowCenter00281050the currently applied window center and width (or window top and bottom for clamped modeWindowWidth00281051De-Identificationdeidentify = yes / noSee Section 10.3.1.3.1.Flip Imageflip = {keyword}where keyword = ‘horizontal’ or ‘vertical’The “flip” parameter controls the flipping of the image(s) in the target resource. The value is either “horizontal” or “vertical,” which specifies the axis around which the image is flipped.Order of Rendered Imagesorder = {keyword}The “order” parameter requests that the target resource image(s) be returned in a specific order. The value is one of the keywords defined in Table 10.4-x below.Table 20.4-x: Keywords for Ordering ImagesKeywordDescriptionAttributetimeThe objects in the response will be in ascending order by acquisition time.{0008,0012) InstanceCreationDate(0008,0013) InstanceCreationTImenumberThe objects in the response will be in ascending order by series number, instance number and frame number.(0020,0011) SeriesNumber,(0020,0013) InstanceNumber,(0020,9156) FrameAcquisitionNumberpositionThe objects in the response will be in ascending order by series, instance and frame position.(0020,0032 ) ImagePositionPatientphaseThe objects in the response will be in ascending order by series, instance and frame position.TemporalPositionIndexThe implementer may provide additional keyword values, which should be included in the conformance statement and in the Retrieve Capabilities response.Quality of the Imagequality = {integer}where 1 <= integer <= 100The “quality” parameter specifies the requested quality of the rendered images. The value shall be an integer in the inclusive range of 1 to 100.It is only supported for media types that allow lossy compression.Region of the Imageregion = {x, y, width, height} where 0 <= x, y, width, height <= 32,6767 (216 – 1)The “region” parameter requests a rectangular region of the original image(s). Its value shall be a list of four comma-separated, non-negative integers, which represent in the following order:xoffset from top, left corneryoffset from top, left cornerwidthwidth of regionheightheight of region,If the specified region is not within the bounds of the image the origin server shall return an error response, with a status code of 400 (Bad Request), and a payload containing a Problems Details document.If the region parameter is not present the returned representations shall be in their original size.Rotate the Imagerotate = {integer}where -270 <= integer <= 270 in 90? incrementsThe “rotate” parameter specifies that the target resource image(s) should be rotated before rendering. The value is an integer that is a multiple of 90 between -270 and 270 inclusive. A positive value indicates clockwise rotation, and a negative value indicates counterclockwise rotation.If both the “region” and “rotate” parameters are present the region will be selected before it is rotated.Window Level Imagewindow = {center,width) / {preset}where center and width are decimal numbers, and preset is an origin server defined keywordThe “window” parameter controls the luminosity and contrast of the images as defined in PS 3.3. The value shall be either two comma-separated decimal values, specifying the Window Center and Window Width in that order, or one keyword. Preset keywords defined by the origin server and correspond to specific values for Window Center and Window Width.This Standard does not define either: 1) the range of the decimal values, or 2) the set of preset keywords and associated values. The origin server may define preset keywords and their values. The user agent can use the Retrieve Capabilities transaction to retrieve the origin server’s Capabilities Description document, which shall contain any preset keywords that it defines.View Port on the User Agentviewport = {width,height}where 0 <= width, height <= 32,6767 (216 – 1)The “viewport” parameter specifies a rectangular area defined by its width and height in pixels. The viewport is intended to correspond to a window on the user agent’s device. The origin server shall scale the rendered images, maintaining their original aspect ratio, until either the image width is the same as the viewport width or the image height is the same as the viewport height, whichever comes first. In other words, viewport scaling makes the image(s) as large as possible, within the viewport, without overflowing the viewport area.If the viewport parameter is not present, the returned images are not scaled.Header FieldsRequired:AcceptSee Section 6.3.1.3PayloadThis request has no payload.BehaviorThe target resource(s) are rendered according to the query parameters, by applying the transformations according to the appropriate rendering pipeline specified in PS3.3, Sections xx.ResponseA success response shall contain a success status code (2XX), appropriate content representation headers, and a payload containing one or more representation encoded in an acceptable media type.An error response will contain an error status code (4XX or 5XX), appropriate error response headers, and may contain a payload with a Status Details document.Status CodesThe most common success status codes are:200 SuccessThe origin server successfully rendered all of the instances referenced by the resource.206 WarningThe origin server successfully rendered only some of the instances referenced by the resource.4XX ErrorThe origin server was unable to successfully render any of the instances. It will return an Error Status Code from Table X.Y-z and should include a Status Details document in the payload.Header FieldsRequired:Content-TypeSee Section 6.3.1.3PayloadThe origin server shall include all successfully rendered images in the payload. If no instances were successfully rendered, the payload should contain a Status Details document.Media TypesA successful Retrieve Rendered transaction shall return rendered media types. See Section 9.3.5.Retrieve Rendered Presentation States Instance TransactionThe Retrieve Rendered Presentation State (PS) Instance transaction retrieves a rendering of the target resource, which must be a presentation state instance, in an acceptable media type.The transaction has the following characteristics:1.The target resource shall be a single presentation state instance.2.The media type specified in the request shall be a rendered media type.Request The Retrieve Presentation State transactions uses the GET method. The request has the following format:GET?{/resource}{?query*}?version?*header-field??Target ResourceTable 10.5-x shows the target resources and their URI template for this transaction. The target resource shall reference only one presentation state instance.Table 10.4-1: Target Resource, URI Template, and DescriptionTarget ResourceResource URI TemplateInstance/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}Retrieves a PS instance in an acceptable rendered media type.Frames/studies/{study_uid}/series/{series_uid}/instances/{instance_uid}/{frame_list}Retrieves one or more frames from a PS instance in an acceptable rendered media type.Bulkdata{/bulkdataI}Retrieves one or more rendered frames from a bulkdata item in an acceptable rendered media type.Query ParametersThe Retrieve Rendered Presentation State service provides query parameters that may be used to specify how the origin server should render the target resource before returning it in the payload.Annotations on the Imageannotation = (patient / procedure) / #{attributeIDattribute}See Section 10.4.1.2.1.De-Identificationdeidentify = yesThe “deidentify” parameter specifies that any Personally Identifiable Information is to be removed from all representations returned in the payload. See Section 9.3.2.2.2Volume of Interest Lookup Table (VOI LUT)voiLutItemNumber = { integer }non-negative or positive?The “voiLutSequenceItemNumber” parameter specifies the VOI LUT Sequence (0028,3010) Item to be used to render the returned images.Quality of the Imagequality = {integer}where 1 <= integer <= 100See Section 10.4.1.2.x.View Port on the User Agentviewport = {rows,columns}where rows and columns are positive integersSee Section 10.4.1.2.x.Header FieldsRequired:AcceptSee Section 6.3.1.3.PayloadThe request message has no payload.BehaviorThe origin server shall support all of the query parameters defined by this transaction.The origin server shall render the presentation state instance referenced by the target resource in an acceptable media type. Rendering a presentation state instance requires rendering its Referenced SOP Instance (0008,1155) using the rendering pipeline specified in PS 3.4.If the Presentation Size Mode is TRUE SIZE the displayed area specified in the presentation state shall NOT be scaled; however, if a “viewport” parameter was specified, and a success response message shall have a Warning header field containing the following text:Warning {+service}: Presentation Size Mode was TRUE SIZE. The image has not been scaled to the specified viewport={rows,columns}.if the Presentation Size Mode is SCALE TO FIT, the displayed area specified in the presentation state shall be scaled to maximize the size of the image in the viewport, while maintaining its aspect ratio; however, if no “viewport” parameter was specified the image shall not be scaled, and a success response message shall have a Warning header field containing the following text::Warning {+service}: Presentation Size Mode was SCALE TO FIT, but not view port was specified. The image has not been scaled.If the Presentation Size Mode in the presentation state is MAGNIFY, then the displayed area specified in the presentation shall be magnified (scaled) as specified in the presentation state. It will then be cropped to fit the size specified by the viewport parameters, if present. Any Displayed Area relative annotations specified in the presentation state are rendered relative to the Specified Displayed Area within the presentation state, not the size of the view port.If the Annotation parameter is present the annotations shall be applied to the images after the presentation state has been applied.ResponseA success response shall contain a success status code (2XX), appropriate content representation headers, and a payload containing one representation encoded in an acceptable media type.An error response will contain an error status code (4XX or 5XX), appropriate error response headers, and may contain a payload with a Problem DetailsStatus Details document.Status CodesThe most common success status codes are:200 SuccessThe origin server successfully rendered all of the instance referenced by the resource.4XX ErrorThe origin server was unable to successfully render any of the instances. It will return an Error Status Code from Table X.Y-z and should include a Problem DetailsStatus Details document in the payload.Header FieldsRequired:Content-TypeSee Section 6.3.1.3.2PayloadThe origin server shall include a successfully rendered image in the payload. If the instance was not successfully rendered, the payload may contain a Problem DetailsStatus Details document.Media TypesThis service supports rendered media types. See Sections 6.3.5, 9.2.4, and Annex X for information about RS media types.Store ServiceThe Store Service stores instances contained in the request payload at the location specified by the target resource. It is used to create or update DICOM studies on the origin server.The Store Service supports only DICOM media types.This transaction requests that the origin server create, append, or update resources for the instances contained in the request payload, that is, it stores the instances so that they can be retrieved in the future. The target resource specifies whether the instances can come from only one or from more than one study.Request Transactions in this service use the POST method. The request syntax is:POST?/studies{/study_uid}?version?Content-Type: dicom-media-type?*header-field??[payload]Where,studyUIDstudy_uid is the Study Instance UID of a DICOM Study. If the studyUIDstudy_uid is specified all instances contained in the payload shall be from that study. Instances not matching the studyUIDstudy_uid shall be rejected.dicom-media-typeis one of the media types from [ref].The request message has the following characteristics:The referenced resource shall be either /studies or /studies/{study_uid}{/study_uid}.The request has no defined query parameters.The Content-Type header fields, which shall be present and contain a DICOM media type, specifies the representation media type contained in the payload.The request must have a payload that contains one or more DICOM instances, encoded in the media type specified by the Content-Type header field.ResourcesThe target resource shall reference either the Studies or Study resource.The Store service transactions and their associated resources are specified in Table 9.5-X. The URI Template associated with the resources is specified in Table 9.2-1.Table 9.5-X: Store Service Transactions and ResourcesTransactionResourceURI TemplateStore InstancesStudies/studies{/study_uid}Stores a set of instances possibly from different studies. The instances can later be retrieved using one of the RS Retrieve transactions.Study/studies/{/study_uid}Stores a set of instances that shall have the same Study Instance UID as study_uid above. The instances can later be retrieved using one of the Studies Service retrieve transactions.Query ParametersThe Store service defines no query parameters.Header FieldsRequired:Content-TypeSee Section 6.3.1.3.2.PayloadThe request payload contains all the representations to be stored, in one of the DICOM media types, specified by the Content-Type header field.BehaviorThe origin server will take the instances contained in the payload and store them so that they may be retrieved later using the Studies Service retrieve transactions.However, before storing the instances the origin server may coerce or replace the values of data elements such as Patient Name, Patient ID, and Accession Number. For example, this might occur when importing media from an external institution, reconciling the instances against a master patient index, or reconciling them against an imaging procedure order. The origin server may also fix incorrect values, such as Patient Name or Patient ID; for example, because an incorrect worklist item was chosen or operator input error has occurred.If any element is coerced or corrected, the Original Attribute Sequence (0400,0561) shall be included in the DICOM Object that is stored and may be included in the Status Details document. See Section 9.6.4.3.NoteFor more information on populating the Original Attribute Sequence see PS3.3, Section C.12.1.ResponseThe response shall have the following format:version?status-code?reason-phrase?Location: {+studyURI}?*header-field??[payload]Where,studyURIis the URI of the created or updated Study resource.The response shall contain a status code and reason phrase, followed by a payload containing a Status Details document, as defined in Table 6.6.1-2, in an acceptable media type. If the request does not include an Accept header field, the Content-Type of the response shall be the same as the Content-Type of the request. The payload shall be encoded in a DICOM media type as specified in Annex X. The media types that are currently supported are:An application/dicom+xmlAn application/jsonStatus CodesThe origin server shall return an appropriate status code. The most common status codes are:Table 10.6-x: Common Status CodesCodeDescriptionSuccess200 (OK)The origin server has successfully received, processed, and stored all of the instances contained in the request payload, and at least one of the instances belonged to an existing study.201 (Created)The origin server has successfully received, processed, and stored all of the instances contained in the request payload; and all the instances belonged to newly created studies.202 (Accepted)If the origin server successfully received all the instances in the request payload, but has not stored all of them.204 (No Content)Indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. This should be the response when content is successfully uploaded and the response has no payload.206 (Partial Content)The origin server has successfully received and processed all the instances, but did not store all of them because of errors in processing.Error409 (Conflict)The origin server failed to store any of the instances contained in the request payload because of instance specific errors.4XXSee [ref]5XXSee [ref]Header FieldsRequired:Content-TypeLocationRecommend:WarningIt is recommended that the text returned in the Warning header field (see RFC7234, Section 5.5) contain a DICOM Status Code and descriptive reason as defined in Section 10.6.4.2.1. For example,Warning: "A700: Out of memorySee Section 6.3.1.3.2PayloadThe payload shall contain a Status Details document that contains status information for each instance in the request payload as defined in Table 10.6-X below. The Status Details document may also include information about the the addition, modification, or deletion of attributes by the origin server, for each instance.If the request does not contain an Accept header field, the media type of the Status Details object shall be the same as the media type of the request.Table 10.6-X: Status DetailsAttribute NameTagTypeAttribute DescriptionRetrieve URL(0008,1190)2The URI where the Study can be retrieved.Note: The VR of this attribute has changed from UT to UR.Failed SOP Sequence(0008,1198)1CA sequence of Items where each Item references an instance that was not stored.Required if any instances failed to store.>Table?10-11 “SOP Instance Reference Macro Attributes” in PS3.3>Failure Reason(0008,1197)1The reason that storage could not be provided for this instance. See Section 10.6.4.3.1.Referenced SOP Sequence(0008,1199)1CA sequence of Items where each Item references an instance that was successfully stored.Required if any instances were successfully stored.>Table?10-11 “SOP Instance Reference Macro Attributes” in PS3.3>Retrieve URL(0008,1190)2The URI where the instance can be retrieved.Note: The VR of this attribute has changed from UT to UR.>Warning Reason(0008,1196)1CThe reason that this instance was accepted with warnings.Required if there was a warning for this instance. See Section 10.6.4.3.2.>Original Attributes Sequence(0400,0561)3Sequence containing all attributes that were removed or replaced by other values.One or more Items are permitted in this sequence.>>Attribute Modification DateTime(0400,0562)1Date and time the attributes were removed and/or replaced.>>Modifying System(0400,0563)1Identification of the system that removed and/or replaced the attributes.>>Reason for the Attribute Modification(0400,0565)1Reason for the attribute modification. Defined terms are:COERCE = Replace values of attributes such as Patient Name, ID, Accession Number, for example, during import of media from an external institution, or reconciliation against a master patient index.CORRECT = Replace incorrect values, such as Patient Name or ID, for example, when incorrect worklist item was chosen or operator input error.>>Modified Attributes Sequence(0400,0550)1Sequence that contains all the Attributes, with their previous values, that were modified or removed from the main data set.Only a single Item shall be included in this sequence.>>Any Attribute from the main data set that was modified or removed; may include Sequence Attributes and their Items.Failure ReasonThe following values shall be used for the Failure Reason (0008,1197) in the Status Details document for this transaction:Table 10.6-X: Failure Reason CodesCodeDescriptionA7xx - Refused out of ResourcesThe origin server did not store the instance because it was out of resources.A9xx - Error: Data Set does not match SOP ClassThe origin server did not store the instance because the instance does not conform to its specified SOP Class.Cxxx - Error: Cannot understandThe origin server did not store the instance because it cannot understand certain Data Elements.C122 - Referenced Transfer Syntax not supportedThe origin server did not store the instance because it does not support the requested Transfer Syntax for the instance.0110 - Processing failureThe origin server did not store the instance because of a general failure in processing the operation.0122 - Referenced SOP Class not supportedThe origin server did not store the instance because it does not support the requested SOP Class.Additional codes may be used for the Failure Reason (0008,1197) for other issues. Implementation specific Failure Reason codes shall be defined in the conformance statement and returned in the Capabilities Description document.In the event that multiple codes may apply, the single most appropriate code shall be used.For more information on Failure Reason Codes see PS3.3 Section X.Y.Z.Warning ReasonThe following values shall be used for the Warning Reason (0008,1196) in the Store Status Details:Table 9.6-X: Warning Reason Codes Code & PhraseDescriptionB000 - Coercion of Data ElementsThe origin server modified one or more data elements during storage of the instance. See Section?6.6.1.3.B006 - Elements DiscardedThe origin server discarded some data elements before storing the instance. See Section?6.6.1.3.B007 - Data Set does not match SOP ClassThe origin server observed that the Data Set did not match the constraints of the SOP Class.Additional codes may be used for the Warning Reason (0008,1196) for other issues. Implementation specific Warning Reason codes shall be defined in the conformance statement and returned in the Capabilities service response.In the event that multiple codes may apply, the single most appropriate code shall be used.For more information on Warning Reason Codes see PS3.3 Section X.Y.Z.Media TypesThe Service is required to support uncompressed Bulkdata.The supported media types are:Table 10.6-x: Store Transaction Media TypesMedia TypeRequiredmultipart/related; type=”application/dicom”[; transfer-syntax={ts}]Requiredmultipart/related; type=”application/dicom+xml” [; transfer-syntax={ts}]?multipart/related; type=application/json [; transfer-syntax={ts}]?multipart/related; type= application/octet-streamRequiredWhere{ts}is an optional transfer syntax UID that specifies the transfer syntax of images contained in the payload.See Sections 6.3.5 and 9.2.4 for information about RS media types.See Annex X for definitions of the DICOM media types.Search TransactionThe Search transaction searches the target resource for contained resources that match the search criteria defined by the query parameters.RequestThe Search service uses the GET method and has the following message format:GET?{/resource}{?query*, fuzzy_matching, limit, offset}?version?Accept: media-type*header-field??See Section 10.7.4 for details.ResourcesTable 10.7-1 shows the resources along with the URI templates for their target URIs.Table 10.7-1: Search Resources, URI Templates, and DescriptionsResourceURI Template and DescriptionAll Studies/studies{?query*}Search this service for any Study matching the query parametersAll Series/series{?query*}Searches this service for any Series that match the query parameters.Study’s Series/studies/{study_uid}/series{?query*}Searches the specified Study for any Series matching the query parameters All Instances/instances{?query*}Searches this service for any Instances that match the query parameters.Study’s Instances/studies/{study_uid}/instances{?query*}Searches the specified Study for any Instances matching the query parametersSeries’ Instances/studies/{study_uid}/series/{series_uid}/instances{?query*}Searches the specified Series in Study for any Instances matching the query parametersAny origin server that supports this transaction shall support all resources specified in Table.Search Query ParametersThe following table contains the ABNF for Search Request query parameters:Table 7.1-2: ABNF Grammar for Query ParametersTermRulequery“?” term *(“&” term)term= *(attribute “=” value) / ; zero or more attribute-value pairs *includefield / ; zero or more includefield parameters 0:1fuzzy / ; zero or one fuzzymatching parameters 0:1offset / ; zero or one offset parameters 0:1limit ; zero or one limit parametersattribute= keyword *(“.” attribute) / tag *(“.” attribute)keyword ; A data element keyword from PS3.6, Table x.ytag ; A data element tag from PS3.6, Table x.yvalue ; A value that corresponds to the value representation associated with the keyword or tag in PS3.6, Table x.y. If the value representation is binary then it shall be encoded in base64.includefield= “includefield ” “=” #attribute / all ; The value is either a comma-separated list of attributes or "all", which indicates that all available attributes should be included in the responsefuzzy= “fuzzymatching” “=” “true” / “false” ; A Boolean value indicating whether fuzzy matching should be used or not.offset= “Offset” “=” skipped-resultsskipped-results ;A non-negative integer number of results to skip, before including results in the responselimit= “limit” “=” maximum-resultsMaximum-results ; An integer indicating the maximum number of results to return in the responseThe Search service supports the following search parameters:Parameter Key and ValueNumber of Values{attribute_pair}{attribute}={value}0 to n {attribute}={value} pairs allowedIncludefield = #{attributes*} | all0 to N includefield = #{attribute} pairs allowed. Each includefield where "all" indicates that all available attributes should be included for each responsefuzzy_matching = true /| falseA Boolean value indicating whether fuzzy matching should be used or not.offset={skippedResults}A non-negative integer number of results to skip, before including results in the response.limit={maximumResults}An integer indicating the maximum number of results to return in the responseIn Table 10.7-2 above each {attribute} must refer to one of:Patient IE attributesStudy IE attributesSeries IE attributes (only Search for Series or Search for Instances requests)Composite Instance IE attributes (only Search for Instances requests)Additional Query/Retrieve Attributes (PS3.4 Section C.3.4)Timezone Offset From UTC (0008,0201)The next section give the encoding rules for {attribute} and {value}.Encoding Rules for {attribute} and {value}1.Each {attribute} parameter name shall be unique unless the associated DICOM Attribute allows UID List matching (see PS3.4 Section C.2.2.2.2), in which case the {value} is a comma-separated list of UIDs.2.The acceptable values for {value} are determined by the types of matching allowed by C-FIND for its associated {attribute}. See PS3.4 Section C.2.2.2. All characters in {value} that are disallowed in the query component of URIs shall be percent-encoded. See [RFC3986] for details.3.If an {attribute} is a value of an "includefield" parameter, it is equivalent to C-FIND Universal matching for that attribute. See PS3.4 Section C.2.2.2.3.{attribute} can be one of the following:{tag}where, {tag} is a string with eight hexadecimal string corresponding to the Tag of a data element (see PS3.6, Section 6),{keyword}where, {keyword} is the Keyword of a data element (see PS3.6, Section 6),,{tag}.{attribute}where, {attribute} is an element of the sequence specified by {tag}, or{keyword}.{attribute}where, {attribute} is an element of the sequence specified by {keyword}.Notes1. Examples of valid values for {attribute}:0020000DStudyInstanceUID00101002.00100020OtherPatientIDsSequence.PatientID00101002.00100024.00400032OtherPatientIDsSequence.IssuerOfPatientIDQualifiersSequence.UniversalEntityID2. Examples of valid Search URLs:*?&00101002.00100020=11235813?&limit=25*?&OtherPatientIDsSequence.00100020=11235813 HYPERLINK "" Grammar for Search Query Parametersattribute= name = valuesname= keyword [ *( “.” attribute ) ] / tag [ *( “.” attribute) ]Where <keyword>s, <tag>s, and <values> are defined in PS3.6 Table 6-1. The encoding of the <value> above shall be defined by the media type.Fuzzy MatchingThe “fuzzy_matching” parameter specifies whether fuzzy matching of Person Names shall be performed by the origin server. It is optional. If the parameter is not present then its value is “false”. See PS3.X Section…Offset, Limit and Number of Results ReturnedThe user agent can use the “offset” and “limit” parameters to control the set of results return. These parameters allow the user agent to paginate the results.Header FieldsRequired:AcceptSee Section 6.3.1.3.PayloadThe request has no payload.BehaviorThe origin server shall perform the search indicated by the request and it shall return the search results or, when the search cannot be performed, a failure status code.MatchingThe matching semantics for each attribute are determined by the types of matching allowed by C-FIND (see Section?C.2.2.2 in PS3.4).Matching results shall be generated according to the Hierarchical Search Method described in Section?C.4.1.3.1.1 in PS3.bined DateTime matching shall be performed (see Section?C.2.2.2.5 in PS3.4).NoteIf an origin server is acting as a proxy for a C-FIND SCP that does not support combined DateTime matching, it will need to perform a C-FIND request using Date only and filter results outside the time range before returning a responseIf the TimezoneOffsetFromUTC / 00080201 parameter name is included in the request, dates and times in the request are to be interpreted in the specified time zone.If the "fuzzymatchingfuzzy_matching” query parameter is included in the request and its value is “true", and it is supported then additional fuzzy semantic matching of person names shall be performed in the manner specified in the DICOM Conformance Statement for the origin server. If Fuzzy Matching is not supported, the response shall include the following HTTP/1.1 Warning header:Warning: 299 {+service}: "Fuzzy Matching is not supported. Only literal matching has been performed."where {+service} is the base URL for the service. See RFC 7230 Section for more information in the Warning header field.NoteThe Warning header field is separate from the Status Line and does not affect the returned Status Code.Required Query ParametersThe origin server shall support the query parameters described in Table 10.7-X:Table 10.7-X: Search ParametersIE LevelKeywordTagStudyStudyDate00080020StudyTime00080030AccessionNumber00080050ModalitiesInStudy00080061ReferringPhysicianName00080090PatientName00100010PatientID00100020StudyInstanceUID0020000DStudyID00200010SeriesModality00080060SeriesInstanceUID0020000ESeriesNumber00200011PerformedProcedureStepStartDate00400244PerformedProcedureStepStartTime00400245RequestAttributeSequence00400275>ScheduledProcedureStepID00400009>RequestedProcedureID00401001InstanceSOPClassUID00080016SOPInstanceUID00080018InstanceNumber00200013If studyUIDstudy_uid is not specified in the resource-path and this formSeries-Level of Relational Search is supported, all Study-level attributes specified in Table 10.7-X shall also be supported.If {SeriesUID}{series_uid} is not specified in the URL and this form ofInstance-Level Relational Search is supported, all Series-level attributes specified in Table 10.7-X shall also be supported.Fuzzy MatchingFuzzymatching = true / falseIf the “fuzzymatchingfuzzy_matching” parameter is not present then it defaults to false and no fuzzy matching will be performed. If the parameter is present with a value isof “true” and the origin server supports fuzzy matching then additional fuzzy semantic matching of person names shall be performed in the manner specified in the DICOM Conformance Statement for the origin server. See PS3.X Section Y.Z.Pagination using Offset and LimitIf the “limit” parameter is not specified or its value exceeds the total number of matching results then {maximumResults} is the lesser of the number of matching results and the maximum number of results supported by the Server.If the “offset” parameter is not specified or its value is less than zero then {skippedResults} is zero.The first result returned shall be result number ({skippedResults} + 1). The last result returned shall be result number ({skippedResults} + {maximumResults}). If ({skippedResults} + 1) exceeds {maximumResults} then no results are returned.If the number of results exceeds the maximum supported by the server, the server shall return the maximum supported results and the response shall include the following HTTP/1.1 Warning header field. See RFC7230 Section 5.5:Warning: 299 {SERVICE}: "The number of results exceeded the maximum supported by the server. Additional results can be requested.The server shall be idempotent so that if the list of results is the same, the response to a request with a specific set of parameters shall always be the same, including order. If the complete list of results is different for subsequent transactions the responses may be different. In a situation where results are changing due to changes in the server contents, queries using the limit and offset may be inconsistent.ResponseThe response will contain …The response format depends on the Accept header specified in the request.Status CodesTable 10.7-4 lists the status codes that shall be used to report any of the associated error and warning situations. Other error codes may be present for other error and warning situations.Table 10.7-X: Status CodesStatusCodeDescriptionSuccess200The query completed and any matching results are returned in the message body.206ToDoFailureSee Section X.Y.Z.Header FieldsRequired:Content-TypeWarningSee Section 6.3.1.3.2<#6.3.1.3.2>PayloadThe response payload will contain the following information.Response Payload of Search for StudyFor each matching Study, the origin server shall return all attributes in accordance with Table?6.7.1-2:Table?6.7.1-2. Search for Study Response PayloadAttribute NameTagNotesSpecific Character Set(0008,0005)If necessary for encoding any returned attributesStudy Date(0008,0020)Study Time(0008,0030)Accession Number(0008,0050)Instance Availability(0008,0056)Modalities in Study(0008,0061)Referring Physician's Name(0008,0090)Timezone Offset From UTC(0008,0201)May be absent if no value is availableRetrieve URL(0008,1190)Shall be empty if the resource cannot be retrieved via an RS retrieve serviceNoteThe VR of this attribute has changed from UT to UR.Patient's Name(0010,0010)Patient ID(0010,0020)Patient's Birth Date(0010,0030)Patient's Sex(0010,0040)Study Instance UID(0020,000D)Study ID(0020,0010)Number of Study Related Series(0020,1206)Number of Study Related Instances(0020,1208)All other Study Level DICOM Attributes passed as {attributeIDattribute} query parameters that are supported by the origin server as matching or return attributesAll other Study Level DICOM Attributes passed as "include" query parameter values that are supported by the origin server as return attributesAll available Study Level DICOM Attributes if the "include" query parameter is included with a value of "all"Series Level and Instance Level attributes passed as "include" query values shall not be returned.NoteThe above list is consistent with those required for IHE RAD-14 (see Table 4.14-1).Response Payload of Search for SeriesFor each matching Series, the origin server shall return all attributes listed in Table?6.7.1-2a:Table?6.7.1-2a.?Search for Series Response PayloadAttribute NameTagNotesSpecific Character Set(0008,0005)If necessary for encoding any returned attributesModality(0008,0056)Timezone Offset From UTC(0008,0201)May be absent if no value is availableSeries Description(0008,103E)May be absent if no value is availableRetrieve URL(0008,1190)Shall be empty if the resource cannot be retrieved via the Retrieve DICOM serviceNoteThe VR of this attribute has changed from UT to UR.Series Instance UID(0020,000E)Series Number(0020,0011)Number of Series Related Instances(0020,1209)Performed Procedure Step Start Date(0040,0244)May be absent if no value is availablePerformed Procedure Step Start Time(0040,0245)May be absent if no value is availableRequest Attribute Sequence(0040,0275)May be absent if no value is available>Scheduled Procedure Step ID(0040,0009)>Requested Procedure ID(0040,1001)All other Series Level DICOM Attributes passed as {attributeIDattribute} query parameters that are supported by the origin server as matching or return attributesAll other Study or Series Level DICOM Attributes passed as "include" query parameter values that are supported by the origin server as return attributesAll available Instance Level DICOM Attributes if the "include" query parameter is included with a value of "all"If {studyUID}{study_uid} is not specified, all sStudy-level attributes specified in Table?6.7.1-2Instance Level attributes passed as "include" query values shall not be returned.NoteThe above list is consistent with the attributes required for IHE RAD-14 (see Table 4.14-1).Response Payload of Search for InstanceFor each matching instance, the origin server shall return all attributes listed in Table?6.7.1-2b:Table?6.7.1-2b.?Response Payload of Search for InstanceAttribute NameTagNotesSpecific Character Set(0008,0005)If necessary for encoding any returned attributesSOP Class UID(0008,0016)SOP Instance UID(0008,0018)Instance Availability(0008,0056)Timezone Offset From UTC(0008,0201)May be absent if no value is availableRetrieve URL(0008,1190)Shall be empty if the resource cannot be retrieved via a Retrieve serviceNoteThe VR of this attribute has changed from UT to UR.Instance Number(0020,0013)Rows(0028,0010)Only present for Image InstancesColumns(0028,0011)Only present for Image InstancesBits Allocated(0028,0100)Only present for Image InstancesNumber of Frames(0028,0008)Only present for Multi-frame image instancesAll other Instance Level Attributes passed as {attributeIDattribute} query keys that are supported by the origin server as matching or return attributesAll other Study, Series or Instance Level Attributes passed as "include" query values that are supported by the origin server as return attributesAll available Instance Level Attributes if the "include" query key is included with a value of "all"If {studyUID}{study_uid} is not specified, all Study-level attributes specified in Table?6.7.1-2If {SeriesInstanceUIDseries_uid} is not specified, all Series-level attributes specified in Table?6.7.1-2aNoteThe above list is consistent with the attributes required for IHE RAD-14 (see Table 4.14-1 and Table 4.14-2).Media TypesThe origin server shall support the following media types:multipart/related; type=application/dicom+xml Retrieve Capabilities TransactionClosed Issues#IssuesOpen Issues#IssuesThe Retrieve Capabilities transaction requests that the target service return a machine readable document, called the Capabilities Description, of the transactions, resources, and representations provided by that service. The Retrieve Capabilities Service transaction shall be implemented by each restful service defined in this standard. a single transaction which shall be supported by all implementations.TransactionsThe Retrieve Capabilities Service supports the transactions in Table 9.8-1. If an origin server supports this service it shall support all transactions.Table 9.4-1: Retrieve Capabilities TransactionTransactionURI TemplateDescriptionRetrieve CapabilitiesRetrieve a descriptions of the service’s capabilities in an acceptable media type.RequestThe Retrieve Capabilities request uses the OPTIONS method and has the following format:OPTIONS?/?version?*header-field??Where, “/” is the base URL for the service. This may be a combination of protocol (either http or https), host, port, and application. See Section 9.2.1 for details.ResourcesThe only resource supported by this transaction is a service itself. Each RS service will support this transaction.Query ParametersThis service has no query parameters.Header FieldsRequired:AcceptSee Section 6.3.1.3.PayloadThe request has no payload.BehaviorThe origin server will return a machine readable description of its capabilities in an acceptable media type.ResponseThe format of the response is as follows:version?status-code?reason-phrase?Content-Type: {media-type}?*header-field??[payload]All responses have single part payloads. A successful response will return a Web Application Description Language (WADL) document encoded in a Media Type consistent with the Accept header of the request.Status CodesA success response will have a status code of 200 (OK).A failure response will have a status code from Table X.Y-Z.Header FieldsRequired:Content-TypeSee Section 6.3.1.3.2.PayloadA success payload is single part and contains a representation of a WADL document in an acceptable media type.The WADL document shall contain one top-level "application" element, which shall contain one "resources" element whose "base" attribute value is “/”, which is the base URL for the Storage Service.A failure response may have an empty payload; however, it is recommended that it contains a “Problem Details” document. See Section 7.2.3.3.Media TypesThe Retrieve Capabilities service supports the following media types:application/vnd.sun.wadl+xmlapplication/jsonSee Annex X, Y, … WADL Document FormatThe full WADL resource tree follows directly and unambiguously from the RESTful resource endpoints defined in 6.5, 6.6, 6.7 and 6.9.For informative purposes, the full resource tree and the methods defined for each resource are described in Table 9.8-X.Table 9.8-XResources and MethodsResourceMethods supported (excluding Retrieve Capabilities)Reference/N/AN/AstudiesSearchForStudiesStoreInstances6.8.1.2.2.36.8.1.2.2.2{StudyUID}RetrieveStudyStoreStudyInstances6.8.1.2.2.16.8.1.2.2.3metadataRetrieveStudyMetadata6.8.1.2.2.1seriesSearchForStudySeries6.8.1.2.2.3{SeriesInstanceUID}RetrieveSeries6.8.1.2.2.1metadataRetrieveSeriesMetadata6.8.1.2.2.1instancesSearchForStudySeriesInstances6.8.1.2.2.3{SOPInstanceUID}RetrieveInstance6.8.1.2.2.1metadataRetrieveInstanceMetadata6.8.1.2.2.1framesN/AN/A{framelist}RetrieveFrames6.8.1.2.2.1instancesSearchForStudyInstances6.8.1.2.2.3seriesSearchForSeries6.8.1.2.2.3{SeriesInstanceUID}N/AN/A{instances}SearchForInstances6.8.1.2.2.3instancesSearchForInstances6.8.1.2.2.3{BulkDataURL}RetrieveBulkData6.8.1.2.2.1workitemsSearchForUPSCreateUPS6.8.1.2.2.36.8.1.2.2.2{UPSInstanceUID}RetrieveUPSUpdateUPS6.8.1.2.2.16.8.1.2.2.4stateChangeUPSState6.8.1.2.2.4cancelrequestRequestUPSCancel6.8.1.2.2.4subscribersN/AN/A{AETitle}CreateSubscriptionDeleteSubscription6.8.1.2.2.56.8.1.2.2.51.2.840.10008.5.1.4.34.5N/AN/AsubscribersN/AN/A{AETitle}CreateSubscriptionDeleteSubscription6.8.1.2.2.56.8.1.2.2.5suspendSuspendGlobalSubscription6.8.1.2.2.51.2.840.10008.5.1.4.34.5.1N/AN/AsubscribersN/AN/A{AETitle}CreateSubscriptionDeleteSubscription6.8.1.2.2.56.8.1.2.2.5suspendSuspendGlobalSubscription6.8.1.2.2.5MethodsRetrieve MethodsThe Retrieve methods define the capabilities of one of the following resources:A WADO-RS resource (see 6.5) or A Retrieve UPS resource (see 6.9.4).The Retrieve methods shall contain the following attributes:A "name" attribute with a value of "GET"An "id" attribute with a value of "RetrieveStudy", "RetrieveSeries", "RetrieveInstance", "RetrieveBulkData", "RetrieveFrames", "RetrieveStudyMetadata", "RetrieveSeriesMetadata", "RetrieveInstanceMetadata" or "RetrieveUPS"The Retrieve methods shall contain a "request" element with "param" elements documenting the following:supported Accept header valuesif the same Media Type is supported with multiple Transfer Syntaxes there should be one entry for each combination of Media Type and Transfer SyntaxThe Retrieve methods shall contain one or more "response" elements documenting the following:supported Status CodesMedia Types returned for each Status Code (if applicable)if the same Media Type is supported with multiple Transfer Syntaxes there should be one entry for each combination of Media Type and Transfer SyntaxNoteMore than one Status Code can be described by a single "response" element.Example:<method name="GET" id="RetrieveStudies"> <request> <param name="Accept" style="header" default="multipart/related; type=application/dicom"> <option value="multipart/related; type=application/dicom" /> <option value="multipart/related; type=application/dicom"; transfer-syntax=1.2.840.10008.1.2 /> <option value="multipart/related; type=application/dicom"; transfer-syntax=1.2.840.10008.1.2.1 /> <option value="multipart/related; type=application/octet-stream" /> <option value="multipart/related; type=image/dicom+jpx" /> <option value="multipart/related; type=image/dicom+jpx; transfer-syntax=1.2.840.10008.1.2.4.92" /> <option value="multipart/related; type= video/mpeg; transfer-syntax=1.2.840.10008.1.2.4.100" /> </param> </request> <response status="200,206"> <representation mediaType="multipart/related; type=application/dicom"; transfer-syntax=1.2.840.10008.1.2 /> <representation mediaType="multipart/related; type=application/dicom"; transfer-syntax=1.2.840.10008.1.2.1 /> <representation mediaType="multipart/related; type=application/octet-stream" /> <representation mediaType="multipart/related; type= image/dicom+jpx" /> <representation mediaType="multipart/related; type= image/dicom+jpx; transfer-syntax=1.2.840.10008.1.2.4.92" /> <representation mediaType="multipart/related; type= video/mpeg; transfer-syntax=1.2.840.10008.1.2.4.100" /> </response> <response status="400 404 406 410 503" /></method>Store MethodsThe Store methods define the capabilities of a Store resource (see 6.6) or a CreateUPS resource (see 6.9.1).The Store methods shall contain the following attributes:A "name" attribute with a value of "POST"An "id" attribute with a value of "StoreInstances", "StoreStudyInstances" or "CreateUPS"The Store methods shall contain a "request" element with "param" elements documenting the following:supported Accept header valuessupported Representationsif the same Media Type is supported with multiple Transfer Syntaxes there should be one entry for each combination of Media Type and Transfer SyntaxThe Store methods shall contain one or more "response" elements documenting the following:supported Status CodesMedia Types returned for each Status Code (if applicable)Headers returned for each Status CodeNoteMore than one Status Code can be described by a single "response" element.Example:<method name="GET" id="StoreInstances"> <request> <param name="Accept" style="header" default="application/dicom+xml"> <option value="application/dicom+xml" /> </param> <representation mediaType="multipart/related; type=application/dicom" /> <representation mediaType="multipart/related; type=application/dicom; transfer-syntax=1.2.840.10008.1.2" /> <representation mediaType="multipart/related; type=application/dicom; transfer-syntax=1.2.840.10008.1.2.1" /> <representation mediaType="multipart/related; type=application/dicom+xml" /> <representation mediaType="multipart/related; type=application/dicom+xml; transfer-syntax=1.2.840.10008.1.2" /> <representation mediaType="multipart/related; type=application/dicom+xml; transfer-syntax=1.2.840.10008.1.2.1" /> <representation mediaType="multipart/related; type=application/dicom+xml; transfer-syntax=1.2.840.10008.1.2.4.92" /> <representation mediaType="multipart/related; type=application/dicom+xml; transfer-syntax=1.2.840.10008.1.2.4.100" /> </request> <response status="200" /> <response status="202,409"> <representation mediaType="application/dicom+xml" /> </response> <response status="400,401,403,503" /></method>Search MethodsThe Search methods define the capabilities of a Search Transaction (see 6.7) or a SearchForUPS resource (see 6.9.3).The Search methods shall contain the following attributes:A "name" attribute with a value of "GET"An "id" attribute with a value of "SearchForStudies", "SearchForStudySeries", "SearchForSeries", "SearchForStudySeriesInstances", "SearchForStudyInstances", "SearchForSeriesInstances", "SearchForInstances" or "SearchForUPS"The Search methods shall contain a "request" element with "param" elements documenting the following:supported Accept header valuessupport for the Cache-control headersupport of "limit", "offset" and "fuzzymatchingfuzzy_matching" query parameterssupported search parameters (both tag and keyword variants shall be listed)supported options for the "includefield" parameter (both tag and keyword variants shall be listed)The Search methods shall contain one or more "response" elements documenting the following:supported Status Codesreturned "header" parameters, including use of "warning headers"Media Types returned for each Status Code (if applicable)NoteMore than one Status Code can be described by a single "response" element.Example:<method name="GET" id="SearchForStudies"> <request> <param name="Accept" style="header" default="multipart/related; type=application/dicom+xml"> <option value="multipart/related; type=application/dicom+xml" /> <option value="application/json" /> </param> <param name="Cache-control" style="header"> <option value="no-cache" /> </param> <param name="limit" style="query" /> <param name="offset" style="query" /> <param name="fuzzymatchingfuzzy_matching" style="query" /> <param name="StudyDate" style="query" /> <param name="00080020" style="query" /> <param name="StudyTime" style="query" /> <param name="00080030" style="query" /> … <param name="includefield" style="query" repeating="true" /> <option value="all" /> <option value="00081049" /> <option value="PhysiciansOfRecordIdentificationSequence" /> <option value="00081060" /> <option value="NameOfPhysiciansReadingStudy" /> … </param></request><response status="200"> <representation mediaType="multipart/related; type=application/dicom+xml" /> <representation mediaType="application/json" /></response><response status="400 401 403 413 503" /></method>Update MethodsThe Update methods define the capabilities of an UpdateUPS, a ChangeUPSState or a RequestUPSCancellation resource (see 6.9.2).The Update methods shall contain the following attributes:A "name" attribute with a value of "POST" for UpdateUPS and RequestUPSCancelA "name" attribute with a value of "PUT" for ChangeUPSStateAn "id" attribute with a value of "UpdateUPS", "ChangeUPSState" or "RequestUPSCancellation"The Update methods shall contain a "request" element with "param" elements documenting the following:supported RepresentationsThe Update methods shall contain one or more "response" elements documenting the following:supported Status CodesHeaders returned for each Status CodeNoteMore than one Status Code can be described by a single "response" element.Example:<method name="POST" id="UpdateUPS"> <request> <representation mediaType="application/dicom+xml" /> <representation mediaType="application/json" /> </request> <response status="200"> <param name="Warning" style="header" fixed="299 {+svc}: The UPS was created with modifications." /> <param name="Warning" style="header" fixed="299 {+svc}: Requested optional Attributes are not supported." /> </response> <response status="409"> <param name="Warning" style="header" fixed="299 {+svc}: The Transaction UID is missing." /> <param name="Warning" style="header" fixed="299 {+svc}: The Transaction UID is incorrect." /> <param name="Warning" style="header" fixed="299 {+svc}: The submitted request is inconsistent with the current state of the UPS Instance." /> </response> <response status="400 401 403 404 503" /></method>Where {+svc} is the base URI for the service.Subscribe MethodsThe Subscribe methods define the capabilities of a Create Subscription, a Suspend Global Subscription or a Delete Subscription resource (see 6.9.7, 6.9.8 and 6.9.9).The Subscribe methods shall contain the following attributes:A "name" attribute with a value of "POST" for CreateSubscription and SuspendGlobalSubscriptionA "name" attribute with a value of "DELETE" for DeleteSubscriptionAn "id" attribute with a value of "CreateSubscription", "SuspendGlobalSubscription" or "DeleteSubscription"The Subscribe methods shall contain a "request" element with "param" elements documenting the following:supported RepresentationsThe Subscribe methods shall contain one or more "response" elements documenting the following:supported Status CodesHeaders returned for each Status CodeNoteMore than one Status Code can be described by a single "response" element.Example:<method name="POST" id="CreateSubscription"> <request> <param name="deletionlock" style="query" default="false"> <option value="true" /> <option value="false" /> </param> </request> <response status="201"> <param name="Warning" style="header" fixed="299 {+svc}: Deletion Lock not granted." /> </response> <response status="403"> <param name="Warning" style="header" fixed="299 {+svc}: The origin server does not support Global Subscription Filtering." /> </response> <response status="400 401 404 409 503" /></method>Where {+svc} is the base URI for the service.Unified Workflow and Procedure Step (UPS Worklist) ServiceClosed Issues#IssuesOpen Issues#IssuesThe UPS Worklist service, or just Worklist service, defines a RESTful interface to the UPS SOP Classes in PS3.3 [link] & PS3.4 [link]. If an origin server implements a Worklist service, it manages a single (global) worklist. user agents can create, update, retrieve, search for and request cancellation of work items on that worklist. Each work item is identified by a DICOM UID.SubscriptionsUser agents can also request notificationsUser agents can also request to receive notifications called Event Reports for a single work item or for all work items managed by the origin server. In order to receive notifications the user agent must first request that the origin server open an event channel to the user agent. b open an event channel changes state or when subscribe, unsubscribe, or suspendThis RS Service defines a RESTful interface to the UPS SOP Classes (see PS3.3 & PS3.4).A UPS origin server manages one worklist, aka the Global WorklistTerminologyWorklistWork itemEach work item is a UPS SOP Instance, we will prefer the term work item because it is moreC-FINDEvent Report (N-Event-Report)N-ACTIONN-CREATEN-GETN-FINDNeed a general transition diagram that shows the states and transitions without subscriptionsNeed another one with subscriptionsOverviewTransactionsThe UPS Service supports following transactions:TransactionMethodRequestPayloadResponsePayloadDescriptionCapabilitiesGETEmpty1 work itemCreatePOST1 work itememptyUpdatePUTN attributesemptySearchGETEmptyN resultsRetrieveGETEmpty1 work itemChange StatePUT?NoRequest CancellationPOSTYesNoCreate SubscriptionPOSTEmptyEmptySuspend SubscriptionPOSTEmptyEmptyDelete SubscriptionDELETEEmptyEmptyOpen Event ChannelGETEmptyEmptySend Event Report---YesEmptyTable X.Y-A: UPS Worklist TransactionsUPS TransactionDescriptionUPS DIMSE [link]CreateRequests the creation of a UPS Instance on the origin server.N-CREATEUpdateThis action sets the attributes of a UPS Instance managed by the origin server.N-SETSearchSearches for work itemsC-FINDRetrieveRetrieves a work itemN-GETChange StateChanges the state of a work itemN-ACTION"Change UPS State"Request CancellationRequests the cancellation of a work itemN-ACTION"Request UPS Cancel"Create SubscriptionCreates a subscription N-ACTION"Subscribe to Receive Event Reports".Suspend Global SubscriptionSuspends an existing subscription to the Global WorklistN-ACTION"Suspend Global Subscription".Delete SubscriptionCancels an existing subscription to a work item or to the Global WorklistN-ACTION“Unsubscribe from Receiving Event Reports”Open Event ChannelInitiates a WebSocket connection to the origin server to allow the user agent to start receiving Event Report messagesSend Event ReportThe origin server sends an Event Report to a user agent using a WebSocket connection.N-EVENT-REPORTAn origin server shall support all UPS Worklist server transactions.The requirements for a UPS origin server that is also a Unified Worklist and Procedure Step SCP are described in PS3.4 Section CC.1. [link]UPS Requests OverviewThe Worklist service transactions used the method and resource URI template specified in Table 9.9-ATable 9.9-A: Worklist Methods and ResourcesTransactionSectionMethodMethod & ResourceCreate6.9.1POST/workitems{?WorkItemUID}Update6.9.2POST/workitems/{WorkItemUID}{?transaction}Search6.9.3GET/workitems{?query*}Retrieve6.9.4GET/workitems/{workItemUID}Change State6.9.5PUT/workitems/{workItemUID}/stateRequest Cancellation6.9.6POST/workitems/{workItemUID}/cancelrequestCreate Subscription6.9.7POST/workitems/{workItemUID}/subscribers/{AETitle}{?deletionlock}/workitems/1.2.840.10008.5.1.4.34.5/subscribers/{AETitle}{?deletionlock}/workitems/1.2.840.10008.5.1.4.34.5.1/subscribers/{AETitle}{?deletionlock,query*}Suspend Global Subscription6.9.8POST/workitems/1.2.840.10008.5.1.4.34.5/subscribers/{AETitle}/suspend/workitems/1.2.840.10008.5.1.4.34.5.1/subscribers/{AETitle}/suspendDelete Subscription6.9.9DELETE/workitems/{workItemUID}/subscribers/{AETitle}Open Event Channel6.9.10GET{+socket}/subscribers/{AETitle}Send Event Report6.9.11N/AN/AAcknowlege?The origin server shall comply with all requirements placed on the SCP for the corresponding services in Annex CC in PS3.4.ResourcesQuery ParametersHeader FieldsRequired:AcceptSee Section 6.3.1.3PayloadThe payload depends on the transaction.Behavior OverviewTODOResponse OverviewStatus CodesThe status codes defined in Table X.Y-Z below are the primary status codes used by this service; however, any of the status codes in Table 6.X-Z might be used by the transactions defined by this service.Table X.Y-1.?Status CodesStatusCodeReason PhraseDescriptionSuccess200OKThe work item was updated201CreatedThe work item was created206Partial ContentOnly some of the query results were returned and the rest can be requested.Failure400Bad RequestThe UPS-RS origin server was unable to understand the request401UnauthorizedThe UPS-RS origin server refused to accept the request because the client is not authenticated.403ForbiddenThe UPS-RS origin server understood the request, but is refusing to perform the query (e.g., an authenticated user with insufficient privileges).404Not foundThe specified UPS Instance does not exist or is not managed by this origin server.409ConflictThe request cannot be performed for one of the following reasons:the submitted request is inconsistent with the current state of the UPS Instancethe Transaction UID is missing, orthe Transaction UID is incorrect503BusyService is unavailable.Media TypesThe media types supported by the UPS Worklist service are:application/jsonapplication/dicom+xmlAdd a table of language mapping from ps3.4 to worklistBasic TransactionsCreate Work Item TransactionRequestThe request has the following format:POST?/workitems/{?workItemUID}?version?Content-Type: media-type?*header-field??[payload]Where,workItemUIDspecifies the Affected SOP Instance UID (0000,1000) of the requested work item. If no workItemUID is specified the origin server will create and assign a new UID. See [ref] on creating UIDs from UUIDs.media-typeis a media type supported by the service.ResourcesTODOQuery ParametersworkItemUIDspecifies the UID of the created work item. It is optional, if not supplied the origin server will create and assign a new UID. See [ref] on creating UIDs from UUIDs.Header FieldsRequired:Content-TypeSee Section 6.3.1.3.PayloadThe payload shall be single part and shall contain a single work item. The work item will contain all attributes to be stored. Any binary data contained in the payload shall be inline (ref element in xml & json).The work item shall comply with all instance requirements in the Req. Type N-CREATE column of Table CC.2.5-3 in PS3.4.BehaviorThe origin server shall create and maintain work items as specified in the request, and as specified by the SCP behavior defined in PS3.4 Section CC.2.5.3.ResponseThe response has the following format:version?status-code?reason-phrase?Location: {+workItemURI}?*header-field??Where,{+workItemURI}is the URI of the created work item.The origin server shall return an appropriate status code, with no payload.Status CodesA successful response will contain a status code of 201 (Created). A failure response will contain an appropriate failure status code from table X.Y-A. Header FieldsRequired in success response: Content-LocationLocationThe URI of the created work item. This URI shall correspond to the created resource, not to a particular representation.If the work item was modified by the origin server the response shall also have the following header:Warning: 299 {+service}: The Work Item was created with modifications.?See Section 6.3.1.3.2.PayloadThe response payload is empty.Retrieve Work ItemThis transaction retrieves a Work Item from a Worklist.RequestGET?/workitems/{workItemUID}?version?Accept: {media-type}?*header-field??Where,{workItemUID}workItemUIDis the UID of a Work Item.Header FieldsRequired:AcceptRecommended:Cache-control: no-cacheIf included, specifies that search results returned should be current and not cached.See Section 6.3.1.3PayloadThe request payload is empty.BehaviorThe origin server shall return the specified Work Item.NoteThe requirement for the origin server to respond to GET requests for UPS Instances that have moved to the COMPLETED or CANCELED state is limited. See Section?CC.2.1.3 in PS3.4.The user agent origin server shall not return the Transaction UID (0008,1195) attribute of the Work Item. This is necessary to preserve this Attribute's role as an access lock.ResponseThe response shall have the following format:version?status-code?reason-phrase?Content-Type: text/plain?*header-field??[payload]Status CodesA success response will contain a status code of 200 (OK).A failure response will contain an appropriate status code from Table 12.2-A.Header FieldsRequired:Content-TypeSee Section PayloadA success response has a single part payload containing the requested Work Item in an acceptable media type.A failure response payload shall be empty.Media TypesAn origin server shall support all media-types allowed in the request.The media types supported by this transaction are:application/dicom+xml”application/jsonUpdate Work Item TransactionThe transaction modifies an existing work item.RequestThe request has the following format:POST?/workitems/{workitemUID}{?transactionUID}?version?Content-Type: media-type?*header-field??[payload]Where,workItemUIDis the UID of the work item.transactionUIDis the Transaction UID for the specified work item.If the UPS instance is currently in the SCHEDULED state, {transactionUID} shall not be specified.If the UPS instance is currently in the IN PROGRESS state, the {transactionUID} shall be specified.Because the request will be treated as atomic (indivisible) and idempotent (repeating the same request has no additional effect), all changes contained in the request shall leave the Work Item in an internally consistent state.Query ParametersRequired if work item state is IN-PROGRESS:transactionUIDthe UID of the lock that is used to modify the work item or change its state if the work item is IN-PROGRESS.Header FieldsRequired:Content-TypeSee Section 6.3.1.3PayloadThe request payload specifies changes to a single Work Item. It shall be single part and shall contain only attributes whose values are to be modified. Any binary data contained in the payload shall be inline. The changes shall comply with all requirements described in PS3.4 Section CC.2.6.2.BehaviorThe origin server shall modify the Work Item as specified in the request, and in a manner consistent with the SCP behavior specified in PS3.4 Section CC.2.6.3.Responseversion?status-code?reason-phrase?*header-field??Status CodesIf the Update request is successful the response will contain a status code of 200 (OK).If the request fails the response will contain an appropriate status code from table X.Y-A. Header FieldsIf the Work Item was updated but with modifications made by the origin server, the response shall include the following in the Warning header field:Warning: 299 {+service}: The Work Item was updated with modifications.If optional attributes were rejected, the response shall include the following Warning header field:Warning: 299 {+service}: Requested optional attributes are not supported.If the request was rejected with a 409 status code, the response shall include a Warning header field with one of following messages that best in describes the nature of the conflict:Warning: 299 {+service}: The Transaction UID is missing.Warning: 299 {+service}: The Transaction UID is incorrect.Warning: 299 {+service}: The submitted request is inconsistent with the current state of the Work Item.PayloadThe response payload is empty.Change Work Item State TransactionThis transaction changes the state of an existing Work Item.[explain the legal state transitions]RequestThe request shall have the following format:PUT?/workitems/{workItemUID}/state?version?Content-Type: {media-type}?*header-field??Where,{workItemUID}workItemUIDis the UID of a Work Item.Header FieldsRequired:Content-TypeSee Section 6.3.1.3PayloadThe request has a single part payload that describes a state change to the target Work Item. It shall include all attributes required for an SCU in PS3.4 Table CC.2.1-1.BehaviorThe origin server shall modify the target Work Item’s state as specified in the request. It shall do so as described by the SCP behavior in PS3.4 Section CC.2.1.3.ResponseThe response shall have the following format:version?status-code?reason-phrase?*header-field??Status CodesA success response will contain a status code of 200 (OK).A failure response will contain an appropriate status code from Table .Header FieldsIf the user agent specifies a Procedure Step State (0074,1000) attribute with a value of "CANCELED" and the Work Item is already in that state, the response message shall include the following Warning header field:Warning: 299 {+service}: The Work Item is already in the requested state of CANCELED.If the user agent specifies a Procedure Step State (0074,1000) attribute with a value of "COMPLETED" and the Work Item is already in that state, the response message shall include the following Warning header field:Warning: 299 {+service}: The UPS is already in the requested state of COMPLETED.If the request was rejected with a 409 status code, the response shall include a Warning header field with one of following messages that best in describes the nature of the conflict:Warning: 299 {+service}: The Transaction UID is missing.Warning: 299 {+service}: The Transaction UID is incorrect.Warning: 299 {+service}: The submitted request is inconsistent with the current state of the Work Item.PayloadThe response payload is empty.Media TypesAn origin server shall support all media-types allowed in the request.The media types supported by this transaction are:application/dicom+xml”application/jsonRequest Cancellation This transaction requests that a Work Item be cancelled, that is, that the origin server change its state to ‘cancelled’.[explain the legal state transitions]RequestPOST?/workitems/{workItemUID}/cancelrequest?version?Content-Type: {media-type}?*header-field??Where,{workItemUID}workItemUIDis the UID of a Work Item.Header FieldsRequired:Content-TypeSee Section 6.3.1.3PayloadThe request has a single part payload that describes a request to cancel the target Work Item. It shall include all attributes required for an SCU in PS3.4 Table CC.2.1-1.The payload may include a Reason for Cancellation and/or a proposed Procedure Step Discontinuation Reason Code Sequence. It may also include a Contact Display Name and/or a Contact URI for the person with whom the cancel request may be discussed.BehaviorThe origin server shall change the state of the target Work Item to CANCELED as shown in HYPERLINK ":\\Users\\jfp\\Documents\\DICOM\\WG-27\\Supplements\\Re-Doc%20Part%2018\\part04.pdf" \l "figure_CC.1.1-1" \h Figure?CC.1.1-1 in PS3.4. The origin server shall process the request as described by the SCP behavior in Section?CC.2.2.3 in PS3.4.To cancel an IN PROGRESS Work Item that the user agent is itself performing, the user agent shall instead use the Change Work Item State transaction as described in Section 12.2.4.The origin server shall modify the target Work Item’s state as specified in the request. It shall do so as described by the SCP behavior in PS3.4 Section CC.2.1.3.Response{version}version ?{status-code}status-code ?{reason-phrase}reason-phrase?*{header-field?}header-field??Status CodesA success response will contain a status code of 202 (Accepted). A success Status Code means that the Request was accepted, not that the Work Item has been canceled. The system performing the Work Item is not obliged to honor the request to cancel and in some scenarios, may not even receive notification of the request. See Section?CC.2.4 in PS3.4.A failure response will contain an appropriate status code from Table .Header FieldsIf the Work Item is already in a canceled state, the response message shall include the following Warning header field:Warning: 299 {+service}: The UPS is already in the requested state of CANCELED.PayloadThe response payload is empty.Media TypesAn origin server shall support all media-types allowed in the request.The media types supported by this transaction are:application/dicom+xmlapplication/jsonSearch for Work Items TransactionThis transaction returns a list of Work Items that match specified query parameters. Each Work Item in the returned list includes the any return attributes specified in the request,RequestThe request has the following format:GET?/workitems{?query} ?{version}version ?Accept: {media-type}?Cache-Control: no-cache?*{header-field?}header-field??Query ParametersThe query parameters have the following format:query = *{attribute / include / fuzzy / offset / limitattribute = attributeIDattribute = valueattributeIDattribute an attribute keyword or tag from the UPS IOD. See PS3.3 Section B.26.2.value a valid value for the attribute as defined in PS3.6.include = “include=” #attributeIDattribute / “all”“all” indicates that all attributes with values should be included for each response.fuzzy = “fuzzymatchingfuzzy_matching=” (true / false)limit = maximumResultsoffset = skippedResultsmaximumResults = positive integerskippedResults = positive-integerHeader FieldsRequired:AcceptRecommended:Cache-control: no-cache If included, specifies that search results returned should be current and not cached.See Section 6.3.1.3.PayloadThe request payload is empty.BehaviorThe Origin-Serverorigin server shall perform a search according the requirements for the RS Storage Service Search transaction. See Section 10.7.3.An Origin-Serverorigin server shall support matching against all Unified Procedure Step Instance Attributes in Table CC.2.5-3 in PS3.4 with a Match Key Type value of U, R or *.See Section 10.7.3.1 for matching behavior.For each matching Work Item, the Origin-Serverorigin server shall return:All Unified Procedure Step Instance Attributes in Table CC.2.5-3 in PS3.4 with a Return Key value of 1 and 2.All Unified Procedure Step Instance Attributes in Table CC.2.5-3 in PS3.4 with a Return Key value of 1C for which the conditional requirements are met.All other Unified Procedure Step Instance Attributes passed as {attributeIDattribute} query keys that are supported by the Origin-Serverorigin server as matching or return attributesAll other Unified Procedure Step Instance Attributes passed as "include" query values that are supported by the Origin-Serverorigin server as return attributes.ResponseThe response shall have the following format:{version}version ?{status-code}status-code ?{reason-phrase}reason-phrase?Content-Type: {media-type}?*{header-field?}header-field??[payload]Status CodesA success response will contain a status code of 200 (OK).A failure response will contain an appropriate status code from table X.Y-A.Header FieldsIf the Work Item was updated but with modifications made by the Origin-Serverorigin server, the response shall include the following in the Warning header field:?Warning: 299 {+svc}{+service}: The Work Item was updated with modifications.If optional attributes were rejected, the response shall include the following Warning header field:?Warning: 299 {+svc}{+service}: Requested optional attributes are not supported.If the request was rejected with a 409 status code, the response shall include a Warning header field with one of following messages that best in describes the nature of the conflict:?Warning: 299 {+svc}{+service}: The Transaction UID is missing.?Warning: 299 {+svc}{+service}: The Transaction UID is incorrect.?Warning: 299 {+svc}{+service}: The submitted request is inconsistent with the current state of the UPS Instance.PayloadThe response payload contains the search results in one of the media types specified by the request Accept header field. If there are no matching results the payload will be empty.Media TypesAn Origin-Serverorigin server shall support all media-types allowed in the request.The media types supported by this transaction are:multipart/related; type=”application/dicom+xml”; boundary={boundary}Specifies that the payload is a multipart message body where each part is a DICOM PS3.19 XML Dicom Native Model element containing the attributes for one matching Work Item. See PS3.19 Section A.1.application/jsonSpecifies that the payload is a JSON array containing one property for each matching Work Item, which in turn contains sub-properties describing the matching attributes for that Work Item. See Section?F.2.SubscriptionsEach Work Item can have a list a User-Agentuser agents who are subscribers, that is, they request that they be notified of events associated with the Work Item.The Worklist Service also has a list of User-Agentuser agents who are subscribers. These subscribers receive notification of any event associated with any Work Item. Subscribers to the Worklist can either receive all notifications or they can supply a filter, in which case they will only receive notifications for Work Items that pass the filter.Upon receipt of the Create Subscription, Suspend Global Subscription or Delete Subscription request, the Origin-Serverorigin server shall attempt to update the appropriate subscription state Global Subscription State, Filtered Global Subscription and/or Work Item Subscription State of the specified Application Entity with respect to the specified SOP Instance UID as described in Table?CC.2.3-2 in PS3.4 and then return an appropriate response.Deletion LocksFiltersResourcesA User-Agentuser agent can subscribe to the three types of resources in the following table:Table 12.2-1: Subscription ResourcesNameResourceDescriptionSubscriptionWork ItemReceive event notifications for a single Work Item.Global SubscriptionWorklistReceive event notifications for all Work Items in the Worklist.Filtered SubscriptionFiltered WorklistReceive event notifications for any Work Item in the Worklist that passes a specified subscription filter.Create Subscription TransactionThis transaction records subscribers to whom future events associated with the specified Work Items will be reported.RequestThe request shall be formatted as follows:POST?/workitems/{resource}?{version}version ?Content-Length: 0?*{header-field?}header-field??Where,{resource}is one of:{workItemUID}/subscribers/{aetitle}{?deletionlock}1.2.840.10008.5.1.4.34.5/subscribers/{aetitle}{?deletionlock}1.2.840.10008.5.1.4.34.5.1/subscribers/{aetitle}?{filter*}{?deletionlock}1.2.840.10008.5.1.4.34.5/subscribers/{aetitle}{?deletionlock}{&filter}And{aetitle}= 16{token}is an Application Entity Title that conforms to the “AE” Value Representation and identifies the Application Entity to be subscribed. See PS3.5 Table 6.2-1.{deletionlock} = true / falseIf present, shall have a value of ‘true’ or ‘false’, indicating whether or not the User-Agentuser agent is requesting a Deletion Lock.{filter}= *{attributeIDattribute}={value}If present, specifies the key/value pairs describing the filter parameters. Each {attributeIDattribute} shall refer to an attribute of the Unified Procedure Step IOD (see PS3.3, Section B.26.2). See Section 6.7.1.1 for {attributeIDattribute} and {value} encoding rules.**** This could be simplified to ****The request shall be formatted as follows:POST?/workitems{/workItemUID}{?filter}{&deletionlock}?{version}version ?Content-Length: 0?*{header-field?}header-field??Where,{/workItemUID}= {uid}Specifies an optional Work Item, if it is not present then the subscription will be global, that is, to all present and future items in the Worklist.{filter}= *{attributeIDattribute}={value}If present, specifies the key/value pairs describing the filter parameters. Each {attributeIDattribute} shall refer to an attribute of the Unified Procedure Step IOD (see PS3.3, Section B.26.2). See Section 6.7.1.1 for {attributeIDattribute} and {value} encoding rules.{deletionlock}= true / falseIf present, shall have a value of ‘true’ or ‘false’, indicating whether or not the User-Agentuser agent is requesting a Deletion Lock.**** end of simplification ****Header FieldsRequired:Content-Length: 0See Section 6.3.1.3PayloadThe request payload shall be empty.BehaviorThe Origin-Serverorigin server shall create a subscription to the target resource for the User-Agentuser agent.The Origin-Serverorigin server shall support the management of subscriptions as specified by the SCP behavior in PS3.4, Section CC.2.3.3.Upon receipt of the Create Subscription, Suspend Global Subscription or Delete Subscription request, the Origin-Serverorigin server shall attempt to update the Global Subscription State, Filtered Global Subscription and/or Work Item Subscription State of the specified Application Entity with respect to the specified SOP Instance UID as described in PS3.4, Table CC.2.3-2 and then return the appropriate response.ResponseThe response shall have the following format:{version}version ?{status-code}status-code ?{reason-phrase}reason-phrase?Location: {+web-socket}?Content-Length: 0?{*header-field?}?[payload]Where,{+web-socket}is the base URL for the WebSocket service. This shall include the WebSocket protocol (either WS or WSS) and may include a combination of authority and path.Status CodesA success response shall contain a status code of 201 (Created). A failure response shall contain a status code from Table .Header FieldsRequired:LocationRequired if the Create Subscription request was accepted but the Deletion Lock was not, the response shall include the following Warning header field: Warning: 299 {+svc}{+service}: Deletion Lock not granted.Required if the request was rejected with a status code of 403, because Filtered Global Subscriptions are not supported, the response message shall include the following Warning header field:Warning: 299 {+SERVICE}: The Origin-Serverorigin server does not support Global Subscription Filtering.PayloadThe response payload is empty.Media TypesAn Origin-Serverorigin server shall support all media-types allowed in the request.The media types supported by this transaction are:application/dicom+xml”application/jsonDelete SubscriptionIf the target resource is a Work Item the User-Agentuser agent’s subscription to that Work Item is removed. The “suspend” query parameter is ignored when the target resource is a Work Item.If the target resource is the Worklist and the “suspend” query parameter is “true” then all future subscriptions to Work Items are cancelled. If the “suspend” query parameter is either “false” or not present, the all current and future subscriptions are cancelled.RequestThe request shall be formatted as follows:DELETE?/workitems/{resource}/subscribers/{aetitle}{?suspend}?version?Content-Length: 0?*header-field??Where,resource={workItemUID} / 1.2.840.10008.5.1.4.34.5 / 1.2.840.10008.5.1.4.34.5.1aetitle=16{token}The subscribed Application Entity?suspend=true / falseIf present, indicates that the subscription should be suspended, i.e. current subscriptions should not be deleted, but no future subscriptions should be created.**** This could be simplified to ****DELETE?/workitems{/workItemUID}{?suspend}?version?Content-Length: 0?*header-field??Where,{?suspend}=true / falseIf present, indicates that the subscription should be suspended, i.e. current subscriptions should not be deleted, but no future subscriptions should be created.**** end of simplification ****Header FieldsRequired:Content-Length: 0PayloadThe request payload shall be empty.BehaviorIf the “suspend” query parameter is “true” the origin server shall no longer automatically subscribe the user agent to newly-created Work Items; however, this does not delete existing subscriptions to Work Items. If the “suspend” query parameter is “false” or not present the origin server shall remove any of the user agent’s existing subscriptions to the target resource.The origin server shall conform to the behavior described in Section 12.1.8.4, “Behavior”.ResponseThe response shall have the following format:version?status-code?reason-phrase?Content-Length: 0?*header-field??Status CodesA success response shall contain a status code of 200 (OK), indicating that the target subscription(s) have been suspended or deleted.A failure response will contain an appropriate status code from Table 12.2-A.Header FieldsRequired:Content-Length: 0PayloadThe response payload shall be empty.Media TypesThis transactions shall specify no media types in the request or response.Open Event Channel TransactionThis transaction opens a WebSocket channel that will be used to send Event Reports to the client. The WebSocket connection can use the same TCP port as the HTTP connection, but they are separate connections.See RFC-6455 for details of the WebSocket protocol.RequestThe request shall have the following format:GET?/subscribers/{aetitle}?version?*header-field??Where,/is the base URL for the WebSocket Worklist Service. This shall include the WebSocket protocol (either WS or WSS) and may include a combination of authority and path.aetitleidentifies the subscribed Application Entity.**** This could be simplified to: ****GET?/?version?Host: server.?Upgrade: websocket?Connection: Upgrade?Sec-WebSocket-Key: {key}?Sec-WebSocket-Protocol: {protocols}?Sec-WebSocket-Version: {ws-version}?*header-field??Where,/The base URL for the Worklist Service. This shall include the WebSocket scheme (either WS or WSS). **** End of simplification ****Header FieldsRequired:Upgrade: websocketConnection: UpgradeSec-WebSocket-KeySec-WebSocket-ProtocolSec-WebSocket-VersionPayloadThe request payload shall be empty.BehaviorThe origin server upgrades the HTTP connection to a WebSocket connection and records the association between the user agent and the WebSocket. In the future the origin server will use this WebSocket connection to send Event Reports for any Work Items that have subscriptions from the user agent.The origin server opens and maintains the active WebSocket connection to the user agent and uses it to send Event Report messages for Work Items that have subscriptions from the user agent. See Section?6.9.7.2, “Behavior”).The connection shall remain open and may be used by the server to send Event messages (see Section 6.9.11, “SendEventReport”).If the WebSocket connection is lost at any point the user agent can re-establish it by repeating the request.The state of a WebSocket connection does not affect subscriptions and an origin server is not required to queue messages when the connection is down.NoteA user agent will only receive the initial state of a newly-subscribed Work Item if the WebSocket connection was initiated prior to creating the subscription.ResponseThe response shall have the following format:version?status-code?reason-phrase?Upgrade: websocket?Connection: Upgrade?Sec-WebSocket-Accept: response-key?Sec-WebSocket-Protocol: protocol?*header-field??Where,Status CodesA success response will contain a status code of 101 (Switching Protocols), which indicates that the origin server has opened the connection.A failure response will contain an appropriate status code from Table .Header FieldsRequired:Upgrade: websocketConnection: UpgradeSec-WebSocket-AcceptSec-WebSocket-ProtocolPayloadThe response payload shall be empty.Media TypesThis transaction shall specify no media types in the request or response.Send Event ReportThis transaction sends Event Reports from the origin server to a user agent over an established WebSocket connection.RequestThe request will use the WebSocket Data Frame transmission protocol.PayloadThe Event Report shall contain all mandatory attributes described in Table?CC.2.4-1 in PS3.4 and Table?10.3-1 in PS3.7 for the event type.Events Reports are encoded as WebSocket data frames with an opcode of "%x1" (text).The frame payload data shall be a DICOM JSON dataset containing the attributes of the Event Report.Note1.Example WebSocket payload:{"00000002": [ "1.2.840.10008.5.1.4.34.6.4" ],"00000100": [ 256 ],"00000110": [ 23 ],"00001000": [ "1.2.840.10008.5.1.4.34.6.4.2.3.44.22231" ],"00001001": [ 1 ],"00741238": [ "SCHEDULED" ],"00744041": [ "READY" ]}?2.The WebSocket protocol does not allow content negotiation so it is not possible to support both XML and JSON encoding of Event Report messages without extending the protocol.BehaviorPS3.4, Section CC.2.4.3 describes the scenarios in which an origin server sends Event Reports to a subscriber, as well as the content of the Event Report messages.ResponseThere is no response.ParametersDICOM Media Types Closed Issues#IssuesOpen Issues#IssuesShould each Media Type have its own annex or should they all be in one AnnexShould the examples be part of the media type definitionShould the media type include the IANA Registration informationapplication/dicomapplication/dicom+json, application/jsonJSON Search ResultsContent-Type: application/jsonThe payload is a JSON array containing a DICOM JSON object for each matching study, series or instance containing sub-objects describing the matching attributes for each study, series or instance (see Section F.2).The origin server may use a bulkdata reference [ref] at its discretion (see Section F.2.6). For example, this might be done to avoid encoding a large DICOM Value Field, such as an image thumbnail.If there are no matching results, the payload will be empty.application/dicom+xmlXML Search ResultsContent-Type: multipart/related; type=application/dicom+xmlThe response is a multipart payload, where each part is a DICOM PS3.19 XML Native Dicom Model element containing the attributes for one matching Study, Series or Instance (see Section A.1 in PS3.19).The origin server may use a bulkdata reference [ref] at its discretion (see Table A.1.5-2 in PS3.19 and Section 6.5.6). For example, this might be done to avoid encoding a large DICOM Value Field, such as an image thumbnail.If there are no matching results, the payload will be empty.Each item in the multipart payload will contain the following HTTP/1.1 headers:Content-Type: application/dicom+xmlXML Status Details DocumentStatus Details ExampleThe following is an example of a PS3.18 XML Store Instances Response Module in the response message body containing 2 failed SOP Instances, 1 successful SOP Instance, and 1 accepted SOP Instance with a warning:<?xml version="1.0" encoding="utf-8"?><NativeDicomModel xmlns=""xsi:schemaLocation=""xmlns:xsi=""> <DicomAttribute tag="00081198" vr="SQ" keyword="FailedSOPSequence"> <Item number="1"> <DicomAttribute tag="00081150" vr="UI" keyword="ReferencedSOPClassUID"> <Value number="1">1.2.840.10008.3.1.2.3.1</Value> </DicomAttribute> <DicomAttribute tag="00081155" vr="UI" keyword="ReferencedSOPInstanceUID"> <Value number="1"> 2.16.124.113543.6003.1011758472.49886.19426.2085542308</Value> </DicomAttribute> <DicomAttribute tag="00081197" vr="US" keyword="FailureReason"> <Value number="1">290</Value> </DicomAttribute> </Item> <Item number="2"> <DicomAttribute tag="00081150" vr="UI" keyword="ReferencedSOPClassUID"> <Value number="1">1.2.840.10008.3.1.2.3.1</Value> </DicomAttribute> <DicomAttribute tag="00081155" vr="UI" keyword="ReferencedSOPInstanceUID"> <Value number="1"> 2.16.124.113543.6003.1011758472.49886.19426.2085542309</Value> </DicomAttribute> <DicomAttribute tag="00081197" vr="US" keyword="FailureReason"> <Value number="1">290</Value> </DicomAttribute> </Item> </DicomAttribute> <DicomAttribute tag="00081199" vr="SQ" keyword="ReferencedSOPSequence"> <Item number="1"> <DicomAttribute tag="00081150" vr="UI" keyword="ReferencedSOPClassUID"> <Value number="1">1.2.840.10008.5.1.4.1.1.2</Value> </DicomAttribute> <DicomAttribute tag="00081155" vr="UI" keyword="ReferencedSOPInstanceUID"> <Value number="1"> 2.16.124.113543.6003.189642796.63084.16748.2599092903</Value> </DicomAttribute> <DicomAttribute tag="00081190" vr="UR" keyword="RetrieveURL"> <Value number="1"> series/2.16.124.113543.6003.2588828330.45298.17418.2723805630/ instances/2.16.124.113543.6003.189642796.63084.16748.2599092903</Value> </DicomAttribute> </Item> <Item number="2"> <DicomAttribute tag="00081150" vr="UI" keyword="ReferencedSOPClassUID"> <Value number="1">1.2.840.10008.5.1.4.1.1.2</Value> </DicomAttribute> <DicomAttribute tag="00081155" vr="UI" keyword="ReferencedSOPInstanceUID"> <Value number="1"> 2.16.124.113543.6003.189642796.63084.16748.2599092905</Value> </DicomAttribute> <DicomAttribute tag="00081196" vr="US" keyword="WarningReason"> <Value number="1">45056</Value> </DicomAttribute> <DicomAttribute tag="00081190" vr="UR" keyword="RetrieveURL"> <Value number="1"> series/2.16.124.113543.6003.2588828330.45298.17418.2723805630/ instances/2.16.124.113543.6003.189642796.63084.16748.2599092905</Value> </DicomAttribute> </Item> </DicomAttribute> <DicomAttribute tag="00081190" vr="UR" keyword="RetrieveURL"> <Value number="1"> ; </DicomAttribute></NativeDicomModel>Rendered Media TypesOther Media TypesWADL Docuiment Format - application/vnd.sun.wadl+xmlThe Capabilities Description document shall contain one top-level "application" element, which shall contain one "resources" element whose "base" attribute value is “/”, which is the base URL for the Service.The full WADL resource tree follows directly and unambiguously from the RESTful resource endpoints defined in 6.5, 6.6, 6.7 and 6.9.For informative purposes, the full resource tree and the methods defined for each resource are described in Table 9.8-X.WADL Media Type RegistrationApplication/ vnd.sun.wadl+xml; chasetIANA Registration(last updated 07 March 2006)Name: Marc HadleyEmail: marc.hadley&MIME media type name: ApplicationMIME subtype name: Vendor Tree - vnd.sun.wadl+xmlRequired parameters: NoneOptional parameters:charset:This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in RFC 3023 [].Encoding considerations: 8bitThis media type may require encoding on transports not capable of handling 8 bit text.Security considerations:The media type does not contain active or executable content. The other security issues associates with this type have not been assessed.Interoperability considerations:This media type is designed to be interoperable across a wide range of platforms and devices with different capabilities. The format does not provide any functionality that could be considered as platform or device specific.Published specification: which use this media :None yet released.Additional information:1. Magic number(s): none2. File extension(s): .wadl3. Macintosh file type code: none4. Object Identifiers: nonePerson to contact for further information:1. Name: Marc Hadley2. Email: marc.hadley&Intended usage: CommonAuthor/Change controller: marc.hadley&(file created 07 March 2006)DefinitionGeneral Format:Table 9.8-XResources and MethodsResourceMethods supported (excluding Retrieve Capabilities)Reference/N/AN/AstudiesSearchForStudiesStoreInstances6.8.1.2.2.36.8.1.2.2.2{StudyUID}RetrieveStudyStoreStudyInstances6.8.1.2.2.16.8.1.2.2.3metadataRetrieveStudyMetadata6.8.1.2.2.1seriesSearchForStudySeries6.8.1.2.2.3{SeriesInstanceUID}RetrieveSeries6.8.1.2.2.1metadataRetrieveSeriesMetadata6.8.1.2.2.1instancesSearchForStudySeriesInstances6.8.1.2.2.3{SOPInstanceUID}RetrieveInstance6.8.1.2.2.1metadataRetrieveInstanceMetadata6.8.1.2.2.1framesN/AN/A{framelist}RetrieveFrames6.8.1.2.2.1instancesSearchForStudyInstances6.8.1.2.2.3seriesSearchForSeries6.8.1.2.2.3{SeriesInstanceUID}N/AN/A{instances}SearchForInstances6.8.1.2.2.3instancesSearchForInstances6.8.1.2.2.3{BulkDataURL}RetrieveBulkData6.8.1.2.2.1workitemsSearchForUPSCreateUPS6.8.1.2.2.36.8.1.2.2.2{UPSInstanceUID}RetrieveUPSUpdateUPS6.8.1.2.2.16.8.1.2.2.4stateChangeUPSState6.8.1.2.2.4cancelrequestRequestUPSCancel6.8.1.2.2.4subscribersN/AN/A{AETitle}CreateSubscriptionDeleteSubscription6.8.1.2.2.56.8.1.2.2.51.2.840.10008.5.1.4.34.5N/AN/AsubscribersN/AN/A{AETitle}CreateSubscriptionDeleteSubscription6.8.1.2.2.56.8.1.2.2.5suspendSuspendGlobalSubscription6.8.1.2.2.51.2.840.10008.5.1.4.34.5.1N/AN/AsubscribersN/AN/A{AETitle}CreateSubscriptionDeleteSubscription6.8.1.2.2.56.8.1.2.2.5suspendSuspendGlobalSubscription6.8.1.2.2.5MethodsRetrieve MethodsThe Retrieve methods define the capabilities of one of the following resources:A WADO-RS resource (see 6.5) or A Retrieve UPS resource (see 6.9.4).The Retrieve methods shall contain the following attributes:A "name" attribute with a value of "GET"An "id" attribute with a value of "RetrieveStudy", "RetrieveSeries", "RetrieveInstance", "RetrieveBulkData", "RetrieveFrames", "RetrieveStudyMetadata", "RetrieveSeriesMetadata", "RetrieveInstanceMetadata" or "RetrieveUPS"The Retrieve methods shall contain a "request" element with "param" elements documenting the following:supported Accept header valuesif the same Media Type is supported with multiple Transfer Syntaxes there should be one entry for each combination of Media Type and Transfer SyntaxThe Retrieve methods shall contain one or more "response" elements documenting the following:supported Status CodesMedia Types returned for each Status Code (if applicable)if the same Media Type is supported with multiple Transfer Syntaxes there should be one entry for each combination of Media Type and Transfer SyntaxNoteMore than one Status Code can be described by a single "response" element.Example:<method name="GET" id="RetrieveStudies"> <request> <param name="Accept" style="header" default="multipart/related; type=application/dicom"> <option value="multipart/related; type=application/dicom" /> <option value="multipart/related; type=application/dicom"; transfer-syntax=1.2.840.10008.1.2 /> <option value="multipart/related; type=application/dicom"; transfer-syntax=1.2.840.10008.1.2.1 /> <option value="multipart/related; type=application/octet-stream" /> <option value="multipart/related; type=image/dicom+jpx" /> <option value="multipart/related; type=image/dicom+jpx; transfer-syntax=1.2.840.10008.1.2.4.92" /> <option value="multipart/related; type= video/mpeg; transfer-syntax=1.2.840.10008.1.2.4.100" /> </param> </request> <response status="200,206"> <representation mediaType="multipart/related; type=application/dicom"; transfer-syntax=1.2.840.10008.1.2 /> <representation mediaType="multipart/related; type=application/dicom"; transfer-syntax=1.2.840.10008.1.2.1 /> <representation mediaType="multipart/related; type=application/octet-stream" /> <representation mediaType="multipart/related; type= image/dicom+jpx" /> <representation mediaType="multipart/related; type= image/dicom+jpx; transfer-syntax=1.2.840.10008.1.2.4.92" /> <representation mediaType="multipart/related; type= video/mpeg; transfer-syntax=1.2.840.10008.1.2.4.100" /> </response> <response status="400 404 406 410 503" /></method>Store MethodsThe Store methods define the capabilities of a Store resource (see 6.6) or a CreateUPS resource (see 6.9.1).The Store methods shall contain the following attributes:A "name" attribute with a value of "POST"An "id" attribute with a value of "StoreInstances", "StoreStudyInstances" or "CreateUPS"The Store methods shall contain a "request" element with "param" elements documenting the following:supported Accept header valuessupported Representationsif the same Media Type is supported with multiple Transfer Syntaxes there should be one entry for each combination of Media Type and Transfer SyntaxThe Store methods shall contain one or more "response" elements documenting the following:supported Status CodesMedia Types returned for each Status Code (if applicable)Headers returned for each Status CodeNoteMore than one Status Code can be described by a single "response" element.Example:<method name="GET" id="StoreInstances"> <request> <param name="Accept" style="header" default="application/dicom+xml"> <option value="application/dicom+xml" /> </param> <representation mediaType="multipart/related; type=application/dicom" /> <representation mediaType="multipart/related; type=application/dicom; transfer-syntax=1.2.840.10008.1.2" /> <representation mediaType="multipart/related; type=application/dicom; transfer-syntax=1.2.840.10008.1.2.1" /> <representation mediaType="multipart/related; type=application/dicom+xml" /> <representation mediaType="multipart/related; type=application/dicom+xml; transfer-syntax=1.2.840.10008.1.2" /> <representation mediaType="multipart/related; type=application/dicom+xml; transfer-syntax=1.2.840.10008.1.2.1" /> <representation mediaType="multipart/related; type=application/dicom+xml; transfer-syntax=1.2.840.10008.1.2.4.92" /> <representation mediaType="multipart/related; type=application/dicom+xml; transfer-syntax=1.2.840.10008.1.2.4.100" /> </request> <response status="200" /> <response status="202,409"> <representation mediaType="application/dicom+xml" /> </response> <response status="400,401,403,503" /></method>Search MethodsThe Search methods define the capabilities of a Search Transaction (see 6.7) or a SearchForUPS resource (see 6.9.3).The Search methods shall contain the following attributes:A "name" attribute with a value of "GET"An "id" attribute with a value of "SearchForStudies", "SearchForStudySeries", "SearchForSeries", "SearchForStudySeriesInstances", "SearchForStudyInstances", "SearchForSeriesInstances", "SearchForInstances" or "SearchForUPS"The Search methods shall contain a "request" element with "param" elements documenting the following:supported Accept header valuessupport for the Cache-control headersupport of "limit", "offset" and "fuzzymatchingfuzzy_matching" query parameterssupported search parameters (both tag and keyword variants shall be listed)supported options for the "includefield" parameter (both tag and keyword variants shall be listed)The Search methods shall contain one or more "response" elements documenting the following:supported Status Codesreturned "header" parameters, including use of "warning headers"Media Types returned for each Status Code (if applicable)NoteMore than one Status Code can be described by a single "response" element.Example:<method name="GET" id="SearchForStudies"> <request> <param name="Accept" style="header" default="multipart/related; type=application/dicom+xml"> <option value="multipart/related; type=application/dicom+xml" /> <option value="application/json" /> </param> <param name="Cache-control" style="header"> <option value="no-cache" /> </param> <param name="limit" style="query" /> <param name="offset" style="query" /> <param name="fuzzymatchingfuzzy_matching" style="query" /> <param name="StudyDate" style="query" /> <param name="00080020" style="query" /> <param name="StudyTime" style="query" /> <param name="00080030" style="query" /> … <param name="includefield" style="query" repeating="true" /> <option value="all" /> <option value="00081049" /> <option value="PhysiciansOfRecordIdentificationSequence" /> <option value="00081060" /> <option value="NameOfPhysiciansReadingStudy" /> … </param></request><response status="200"> <representation mediaType="multipart/related; type=application/dicom+xml" /> <representation mediaType="application/json" /></response><response status="400 401 403 413 503" /></method>Update MethodsThe Update methods define the capabilities of an UpdateUPS, a ChangeUPSState or a RequestUPSCancellation resource (see 6.9.2).The Update methods shall contain the following attributes:A "name" attribute with a value of "POST" for UpdateUPS and RequestUPSCancelA "name" attribute with a value of "PUT" for ChangeUPSStateAn "id" attribute with a value of "UpdateUPS", "ChangeUPSState" or "RequestUPSCancellation"The Update methods shall contain a "request" element with "param" elements documenting the following:supported RepresentationsThe Update methods shall contain one or more "response" elements documenting the following:supported Status CodesHeaders returned for each Status CodeNoteMore than one Status Code can be described by a single "response" element.Example:<method name="POST" id="UpdateUPS"> <request> <representation mediaType="application/dicom+xml" /> <representation mediaType="application/json" /> </request> <response status="200"> <param name="Warning" style="header" fixed="299 {+svc}: The UPS was created with modifications." /> <param name="Warning" style="header" fixed="299 {+svc}: Requested optional Attributes are not supported." /> </response> <response status="409"> <param name="Warning" style="header" fixed="299 {+svc}: The Transaction UID is missing." /> <param name="Warning" style="header" fixed="299 {+svc}: The Transaction UID is incorrect." /> <param name="Warning" style="header" fixed="299 {+svc}: The submitted request is inconsistent with the current state of the UPS Instance." /> </response> <response status="400 401 403 404 503" /></method>Where {+svc} is the base URI for the service.Subscribe MethodsThe Subscribe methods define the capabilities of a Create Subscription, a Suspend Global Subscription or a Delete Subscription resource (see 6.9.7, 6.9.8 and 6.9.9).The Subscribe methods shall contain the following attributes:A "name" attribute with a value of "POST" for CreateSubscription and SuspendGlobalSubscriptionA "name" attribute with a value of "DELETE" for DeleteSubscriptionAn "id" attribute with a value of "CreateSubscription", "SuspendGlobalSubscription" or "DeleteSubscription"The Subscribe methods shall contain a "request" element with "param" elements documenting the following:supported RepresentationsThe Subscribe methods shall contain one or more "response" elements documenting the following:supported Status CodesHeaders returned for each Status CodeNoteMore than one Status Code can be described by a single "response" element.Example:<method name="POST" id="CreateSubscription"> <request> <param name="deletionlock" style="query" default="false"> <option value="true" /> <option value="false" /> </param> </request> <response status="201"> <param name="Warning" style="header" fixed="299 {+svc}: Deletion Lock not granted." /> </response> <response status="403"> <param name="Warning" style="header" fixed="299 {+svc}: The origin server does not support Global Subscription Filtering." /> </response> <response status="400 401 404 409 503" /></method>Where {+svc} is the base URI for the service.Query Parameter SyntaxStatus DetailsThe DICOMweb Status Details is a machine-readable document containing the details of an RS transaction in an HTTP response. It is modeled on the HYPERLINK "" Problem Details for HTTP APIs. The document describes the results first with respect to the target resource, and then with respect to sub-resources contained in the target resource.A Status Details document MAY have the following members:"type" (string) - An absolute URI [RFC3986] that identifies the problem type. When dereferenced, it SHOULD provide human-readable documentation for the problem type (e.g., using HTML [W3C.REC-html401-19991224]). When this member is not present, its value is assumed to be "about:blank"."title" (string) - A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization."status" (number.number) - The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem, followed by a, possibly empty DICOM code."detail" (string) - An human readable explanation specific to this occurrence of the problem."location" (string) - An absolute URI that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced.“IOD” (string) – The Information Object Definition of the resource.“class” (string) – SOP Class UID of the resource.“sub-resources”: An array of Status Details documents for each sub-resource.Below is a JSON Schema for the Status Details document:{ type":URI,"title":String,“status”:ResourceStatus,“sub-resources”:[ ResourceStatus ],}Where,type:is a URI that identifies the type and structure of the document. For example, in the dicom+json media type the URL refers to a location where a JSON Schema for the document may be found.titleis the title of the status document.statusis an object describing the status of the target resource.sub-resourcesan array of resource statuses.A resource status have the following structure:{“type”:is a string containing one of ‘Success’, ‘Warning’, or ‘Error’.“ie”:is the Information Entity type of the resource,“class”:is the resources SOP Class UID of the resource,“location”:is a URI that references the resource,“code”:a string in the form of XXX.YYY, where XXX is the HTTP Status Code for the resource, and YYY is the DICOM status code for the resource.“detail”:a string describing the status with respect to this resource.}HTTP Status Codes (Informative)CodeReason-PhraseDICOMDefined in...100ContinueSection 6.2.1101Switching Protocols Section 6.2.2200OK Success Section 6.3.1201 Created Section 6.3.2202 Accepted Section 6.3.3203 Non-Authoritative Information Proxy Section 6.3.4204 No Content Section 6.3.5205 Reset Content Section 6.3.6206 Partial Content Section?4.1 of [RFC7233] 300 Multiple Choices Section 6.4.1301 Moved Permanently Section 6.4.2302 Found Section 6.4.3303See Other Section 6.4.4304 Not Modified Section?4.1 of [RFC7232] 305 Use Proxy Section 6.4.5307 Temporary Redirect Section 6.4.7400 Bad Request Section 6.5.1401 Unauthorized Section?3.1 of [RFC7235] 402 Payment Required Section 6.5.2403 Forbidden Section 6.5.3404 Not Found Section 6.5.4405 Method Not Allowed Section 6.5.5406 Not Acceptable Section 6.5.6407 Proxy Authentication Required Section?3.2 of [RFC7235] 408 Request Timeout Section 6.5.7409 Conflict Section 6.5.8410 Gone Section 6.5.9411 Length Required Section 6.5.10 412 Precondition Failed Section?4.2 of [RFC7232] 413 Payload Too Large Section 6.5.11 414 URI Too Long Section 6.5.12 415 Unsupported Media Type Section 6.5.13 416 Range Not Satisfiable Section?4.4 of [RFC7233] 417 Expectation Failed Section 6.5.14 426 Upgrade Required Section 6.5.15 500 Internal Server Error Section 6.6.1501 Not Implemented Section 6.6.2502 Bad Gateway Section 6.6.3503 Service Unavailable Section 6.6.4504 Gateway Timeout Section 6.6.5505 HTTP Version Not Supported Section 6.6.6The status codes listed below are defined in this specification, Section?4 of [RFC7232], Section?4 of [RFC7233], and Section?3 of [RFC7235]. The reason phrases listed here are only recommendations -- they can be replaced by local equivalents without affecting the protocol. Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls [RFC7234]; all other status codes are not cacheable by default.DICOM Media Typesapplication/dicomThe application/dicom media type is specified in [IETF RFCRFC ]The representations returned for this media type shall be encoded as PS3.10 binary objects in an acceptable Transfer Syntax (Explicit VR Little Endian by default) with one payload part per DICOM Instance. Other types of responses will be encoded in the following manner: (see Figure 6.5-1)..??NoteIf the Transfer Syntax is not specified, then a reversible (lossless) encoding is used.application/dicom+xmlAll XML responses shall be encoded as described in the Native DICOM Model defined in PS3.19 with one message part per XML object.Application/dicom+json or application/jsonAll JSON responses shall be encoded as a DICOM JSON Model Object as defined in Annex F.application/dicom+bulkdataUncompressed bulk and pixel data shall be encoded in a Little Endian format using the application/octet-stream media type with one message part per bulk databulkdata pressed pixel data may be encoded in one of three ways:1.Single-frame pixel data encoded using a single-frame media type (one message part)2.Multi-frame pixel data encoded using a single-frame media type (one frame per message part)3.Multi-frame or video pixel data encoded using a multi-frame media type (multiple frames in one message part)A.2.1 DefinitionA.2.2 SchemasA.2.3ExamplesA.3application/dicom+jsonA.3.1 DefinitionA.3.2 ExamplesA.4application/wadl+jsonWS SchemaF?DICOM JSON ModelF.1?Introduction to JavaScript Object Notation (JSON)JSON is a text-based open standard, derived from JavaScript, for representing data structures and associated arrays. It is language-independent, and primarily used for serializing and transmitting lightweight structured data over a network connection. It is described in detail by the Internet Engineering Task Force (IETF) in RFC 4627, available at DICOM JSON Model complements the XML-based Native DICOM Model, by providing a lightweight representation of data returned by DICOM web services. While this representation can be used to encode any type of DICOM Data Set it is expected to be used by client applications, especially mobile clients, such as described in the Search use cases (see Chapter?HHH in PS3.17).F.2?DICOM JSON ModelThe DICOM JSON Model follows the Native DICOM Model for XML very closely, so that systems can take advantage of both formats without much retooling. The Media Type for DICOM JSON is application/json. The default character repertoire shall be UTF-8 / ISO_IR 192.F.2.1?Multiple Results StructureMultiple results returned in JSON are organized as a single top-level array of JSON objects. This differs from the Native DICOM Model, which returns multiple results as a multi-part collection of singular XML documents.F.2.1.1?ExamplesF.2.1.1.1?Native DICOM Model<?xml version="1.0" encoding="UTF-8" xml:space="preserve" ?><NativeDicomModel> <DicomAttribute tag="0020000D" vr="UI" keyword="StudyInstanceUID"> <Value number="1">1.2.392.200036.9116.2.2.2.1762893313.1029997326.945873</Value> </DicomAttribute></NativeDicomModel>…<?xml version="1.0" encoding="UTF-8" xml:space="preserve" ?><NativeDicomModel> <DicomAttribute tag="0020000D" vr="UI" keyword="StudyInstanceUID"> <Value number="1">1.2.444.200036.9116.2.2.2.1762893313.1029997326.945876</Value> </DicomAttribute></NativeDicomModel>F.2.1.1.2?DICOM JSON Model[ { "0020000D": { "vr": "UI", "Value": [ "1.2.392.200036.9116.2.2.2.1762893313.1029997326.945873" ] } } { "0020000D" : { "vr": "UI", "Value": [ "1.2.392.200036.9116.2.2.2.2162893313.1029997326.945876" ] } }]F.2.2?DICOM JSON Model Object StructureThe DICOM JSON Model object is a representation of a DICOM Data Set.The internal structure of the DICOM JSON Model object is a sequence of objects representing attributes within the DICOM Data Set.Attribute objects within a DICOM JSON Model object must be ordered by their property name in ascending order.Group Length (gggg,0000) attributes shall not be included in a DICOM JSON Model object.The name of each attribute object is:The eight character uppercase hexadecimal representation of a DICOM TagEach attribute object contains the following named child objects:vr: A string encoding the DICOM Value Representation. The mapping between DICOM Value Representations and JSON Value Representations is described in Section?F.2.3.At most one of:Value: An array containing one of:The Value Field elements of a DICOM attribute with a VR other than PN, SQ, OB, OD, OF, OW, or UN (described in Section?F.2.4)The encoding of empty Value Field elements is described in Section?F.2.5The Value Field elements of a DICOM attribute with a VR of PN. The non-empty name components of each element are encoded as a JSON strings with the following names:AlphabeticIdeographicPhoneticJSON DICOM Model objects corresponding to the sequence items of an attribute with a VR of SQEmpty sequence items are represented by empty objectsBulkDataURI: A string encoding the WADO-RS URL of a bulk databulkdata item describing the Value Field of an enclosing Attribute with a VR of FL, FD, IS, LT, OB, OD, OF, OW, SL, SS, ST, UL, UN, US, or UT (described in Section?F.2.6)InlineBinary: A base64 string encoding the Value Field of an enclosing Attribute with a VR of OB, OD, OF, OW, or UN (described in Section?F.2.7)NoteFor Private Data Elements, the group and element numbers will follow the rules specified in Section?7.8.1 in PS3.5The person name representation is more closely aligned with the DICOM Data Element representation than the DICOM PS3.19 XML representation.F.2.3?DICOM JSON Value RepresentationThe value representation (VR) is included in each DICOM JSON Model attribute object and named "vr". For example:"vr": "CS"All DICOM Value Representations are mapped to specified JSON Data Types (see Table?F.2.3-1). The JSON encodings shall conform to the Definition, Character Repertoire (if applicable) and Length of Value specified for that Value Representation (see Section?6.2 “Value Representation (VR)” in PS3.5) with the following exceptions:Attributes with a Value Representation of AT shall be restricted to eight character uppercase hexadecimal representation of a DICOM TagTable?F.2.3-1.?DICOM VR to JSON Data Type MappingCodeVR NameJSON Data TypeAEApplication EntityStringASAge StringStringATAttribute TagStringCSCode StringStringDADateStringDSDecimalNumberDTDate TimeStringFLFloating Point SingleNumberFDFloating Point DoubleNumberISInteger StringNumberLOLong StringStringLTLong TextStringOBOther Byte StringBase64 encoded stringODOther Double StringBase64 encoded stringOFOther Float StringBase64 encoded stringOWOther Word StringBase64 encoded stringPNPerson NameObject containing Person Name component groups as strings (see Section?F.2.2)SHShort StringStringSLSigned LongNumberSQSequenceArray containing DICOM JSON ObjectsSSSigned ShortNumberSTShort TextStringTMTimeStringUIUIDStringULUnsigned LongNumberUNUnknownBase64 encoded stringURURIStringUSUnsigned ShortNumberUTUnlimited TextStringAlthough data, such as dates, are represented in the DICOM JSON model as strings, it is expected that they will be treated in the same manner as the original attribute as defined by Chapter?6 in PS3.6.F.2.4?DICOM JSON Value MultiplicityThe value or values of a given DICOM attribute are given in the "Value" array. The value multiplicity (VM) is not contained in the DICOM JSON object.For example:"Value": [ "bar", "foo" ]or:"Value": [ "bar" ]F.2.5?DICOM JSON Model Null ValuesIf an attribute is present in DICOM but empty (i.e., Value Length is 0), it shall be preserved in the DICOM JSON attribute object containing no "Value", "BulkDataURI" or "InlineBinary".If a multi-valued attribute has one or more empty values these are represented as "null" array elements. For example:"Value": [ "bar", null, "foo" ]If a sequence contains empty items these are represented as empty JSON object in the array."Value": [ { … }, { }, { … } ]F.2.6?BulkDataURIIf an attribute contains a "BulkdData URI" , this contains the URI ofit is a reference to a bulk data element as defined in Table?A.1.5-2 in PS3.19.F.2.7?InlineBinaryIf an attribute contains an "InlineBinary", this contains the base64 encoding of the enclosing attribute's Value Field.There is a single InlineBinary value representing the entire Value Field, and not one per Value in the case where the Value Multiplicity is greater than one. E.g., a LUT with 4096 16 bit entries that may be encoded in DICOM with a Value Representation of OW, with a VL of 8192 and a VM of 1, or a US VR with a VL of 8192 and a VM of 4096 would both be represented as a single InlineBinary string.All rules (e.g., byte ordering and swapping) in DICOM PS3.5 apply.NoteImplementers should in particular pay attention to the PS3.5 rules regarding the value representations of OD, OF and OW.F.3?Transformation with other DICOM FormatsF.3.1?Native DICOM Model XMLThe transformation between the Native DICOM Model XML and the DICOM JSON model cannot be done through the use of generic XML - JSON converters.The mapping between the two formats is as follows (see also Table?F.3.1-1):The XML "NativeDicomModel" element maps to the DICOM JSON Model ObjectEach "DicomAttribute" element maps to an attribute object within the DICOM JSON model objectThe "tag" attribute maps to the JSON object nameThe Native DICOM Model XML allows for duplicate Tag values and the DICOM JSON model does not. To resolve this, private attribute Tag values must be remapped according to the conflict avoidance rules specified in Section?7.8.1 “Private Data Element Tags” in PS3.5.The "vr" attribute maps to the "vr" child string"Value" elements map to members of the "Value" child arrayA "Value" element with the attribute "number=n" maps to "Value[n-1]"Empty "Value" elements are represented by "null" entries in the "Value" array"PersonName" elements map to objects within the "Value" array. For a "PersonName" element with the attribute "number=n":The "Alphabetic" element maps to "Value[n-1].Alphabetic"The "Ideographic" element maps to "PersonName[n].Ideographic"The "Phonetic" element maps to "PersonName[n].Phonetic"- "Item" elements map to members of the "Value" child arrayAn "Item" element with the attribute "number=n" maps to "Value[n-1]"Empty "Item" elements are represented by empty JSON property entries in the "Value" arrayThe "uri" attribute of the "BulkData" element maps to the "BulkDataURI" stringThe "InlineBinary" element maps to the "InlineBinary" stringTable?F.3.1-1.?XML to JSON MappingDICOM PS3.19 XMLDICOM JSON Model<NativeDicomModel><DicomAttribute tag= ggggee01 … /><DicomAttribute tag= ggggee02 … />…</NativeDicomModel>{ggggee01 : { … },ggggee02 : { … },…}<DicomAttributetag= ggggeeeevr= VR ><Value number="1"> Value </Value></DicomAttribute>ggggeeee : {"vr": VR ,"Value": [ Value ]}<DicomAttribute tag= ggggeeee … ><Value number="1"> Value1 </Value><Value number="2"> Value2 </Value>…</DicomAttribute>ggggeeee : {…"Value": [ Value1 ,Value2 , …]}<DicomAttribute tag= ggggeeee … ></DicomAttribute>ggggeeee : {…}<DicomAttribute tag= ggggeeee vr="PN" … ><PersonName number="1"><Alphabetic><FamilyName> SB1</FamilyName><GivenName> SB2</GivenName><MiddleName> SB3</MiddleName><NamePrefix> SB4</NamePrefix><NameSuffix> SB5</NameSuffix></Alphabetic><Ideographic><FamilyName> ID1</FamilyName>…</Ideographic><Phonetic><FamilyName> PH1</FamilyName>…</Phonetic></PersonName><PersonName number="2"><Alphabetic><FamilyName> SB6</FamilyName></Alphabetic></PersonName></DicomAttribute>ggggeeee : {…"vr": "PN","Value": [{" Alphabetic " : "SB1^SB2^SB3^SB4^SB5","Ideographic": "ID1^ID2^ID3^ID4^ID5" ,"Phonetic": "PH1^PH2^PH3^PH4^PH5"},{"Alphabetic":" SB6 "}]}<DicomAttribute tag= ggggeeee vr="SQ" … ><Item number="1"><DicomAttribute tag= ggggee01 … /><DicomAttribute tag= ggggee02 … />…</Item><Item number="2"><DicomAttribute tag= ggggee01 … /><DicomAttribute tag= ggggee02 … />…</Item><Item number="3"></Item>…</DicomAttribute>ggggeeee : {…"vr": "SQ","Value":[{ggggee01 : { … },ggggee02 : { … },…}{ggggee01 : { … },ggggee02 : { … },…}{ }…]}<DicomAttribute tag= ggggeeee … ><BulkData URI= BulkDataURI ></DicomAttribute>ggggeeee : {…"BulkDataURI": BulkDataURI}<DicomAttribute tag= ggggeeee … ><InlineBinary> Base64String </InlineBinary></DicomAttribute>ggggeeee : {…"InlineBinary": " Base64String"}<DicomAttribute tag= gggg00ee PrivateCreator= PrivateCreator … >…</DicomAttribute>ggggXXee : {…}F.4?DICOM JSON Model ExampleThe following example is a Storage ServiceSearch for Studies response consisting of two matching studies, corresponding to the example Search request: GET [ { // Result 1 "00080005": { "vr": "CS", "Value": [ "ISO_IR192" ] }, "00080020": { "vr": "DT", "Value": [ "20130409" ] }, "00080030": { "vr": "TM", "Value": [ "131600.0000" ] }, "00080050": { "vr": "SH", "Value": [ "11235813" ] }, "00080056": { "vr": "CS", "Value": [ "ONLINE" ] }, "00080061": { "vr": "CS", "Value": [ "CT", "PET" ] }, "00080090": { "vr": "PN", "Value": [ { "Alphabetic": "^Bob^^Dr." } ] }, "00081190": { "vr": "UR", "Value": [ " 1.2.392.200036.9116.2.2.2.1762893313.1029997326.945873" ] }, "00090010": { "vr": "LO", "Value": [ "Vendor A" ] }, "00091002": { "vr": "UN", "Value": [ "z0x9c8v7" ] }, "00100010": { "vr": "PN", "Value": [ { "Alphabetic": "Wang^XiaoDong", "Ideographic": "王^小東" } ] }, "00100020": { "vr": "LO", "Value": [ "12345" ] }, "00100021": { "vr": "LO", "Value": [ "Hospital A" ] }, "00100030": { "vr": "DT", "Value": [ "19670701" ] }, "00100040": { "vr": "CS", "Value": [ "M" ] }, "00101002": { "vr": "SQ", "Value": [ { "00100020": { "vr": "LO", "Value": [ "54321" ] }, "00100021": { "vr": "LO", "Value": [ "Hospital B" ] } }, { "00100020": { "vr": "LO", "Value": [ "24680" ] }, "00100021": { "vr": "LO", "Value": [ "Hospital C" ] } } ] }, "0020000D": { "vr": "UI", "Value": [ "1.2.392.200036.9116.2.2.2.1762893313.1029997326.945873" ] }, "00200010": { "vr": "SH", "Value": [ "11235813" ] }, "00201206": { "vr": "IS", "Value": [ 4 ] }, "00201208": { "vr": "IS", "Value": [ 942 ] } }, { // Result 2 "00080005": { "vr": "CS", "Value": [ "ISO_IR192" ] }, "00080020": { "vr": "DT", "Value": [ "20130309" ] }, "00080030": { "vr": "TM", "Value": [ "111900.0000" ] }, "00080050": { "vr": "SH", "Value": [ "11235821" ] }, "00080056": { "vr": "CS", "Value": [ "ONLINE" ] }, "00080061": { "vr": "CS", "Value": [ "CT", "PET" ] }, "00080090": { "vr": "PN", "Value": [ { "Alphabetic": "^Bob^^Dr." } ] }, "00081190": { "vr": "UR", "Value": [ " 1.2.392.200036.9116.2.2.2.2162893313.1029997326.945876" ] }, "00090010": { "vr": "LO", "Value": [ "Vendor A" ] }, "00091002": { "vr": "UN", "Value": [ "z0x9c8v7" ] }, "00100010": { "vr": "PN", "Value": [ { "Alphabetic": "Wang^XiaoDong", "Ideographic": "王^小東" } ] }, "00100020": { "vr": "LO", "Value": [ "12345" ] }, "00100021": { "vr": "LO", "Value": [ "Hospital A" ] }, "00100030": { "vr": "DT", "Value": [ "19670701" ] }, "00100040": { "vr": "CS", "Value": [ "M" ] }, "00101002": { "vr": "SQ", "Value": [ { "00100020": { "vr": "LO", "Value": [ "54321" ] }, "00100021": { "vr": "LO", "Value": [ "Hospital B" ] } }, { "00100020": { "vr": "LO", "Value": [ "24680" ] }, "00100021": { "vr": "LO", "Value": [ "Hospital C" ] } } ] }, "0020000D": { "vr": "UI", "Value": [ "1.2.392.200036.9116.2.2.2.2162893313.1029997326.945876" ] }, "00200010": { "vr": "SH", "Value": [ "11235821" ] }, "00201206": { "vr": "IS", "Value": [ 5 ] }, "00201208": { "vr": "IS", "Value": [ 1123 ] } }]F.5?ReferencesIETF RFCRFC 4627 (Normative JSON definition)JSON. (Informative)Wikipedia, definition of JSON. (Informative)JSON in FHIR. (Informative)G?WADL JSON RepresentationG.1?IntroductionWhile the WADL specification only specifies an XML encoding for the WADL payload, the data structure can easily be represented using JSON. Additionally, conversion from XML to JSON and vice-versa can be done in a lossless manner.G.2?XML ElementsThe JSON encoding of WADL XML elements depends on whether the element is:a "doc" elementan element that is unique within a particular parent element (e.g., "request")an element that can be repeated within a particular parent element (e.g., "param")G.2.1?Doc ElementsA "doc" element is represented as an array of objects, where each object may contain:a "@xml:lang" stringa "@title" stringa "value" stringExample:"doc": [ { "@xml:lang": "en", "value": "Granular cell tumor" }, { "@xml:lang": "ja", "value": "顆粒細胞腫" }, { "@xml:lang": "fr", "value": "Tumeur à cellules granuleuses" }]G.2.2?Unique ElementsAll unique WADL XML elements are represented as an object whose name is the name of the XML element and where each member may contain:a "@{attribute}" string for each XML attribute of the name {attribute}a child object for each child element that must be uniquea child array for each child element that may not be uniqueExample:"request": { "param": [ ... ], "representation": [ ... ]}G.2.3?Repeatable ElementsAll repeatable WADL XML elements are represented as an array of objects whose name is the name of the XML element and where each may contain:a "@{attribute}" string for each XML attribute of the name {attribute}a child object for each child element that must be uniquea child array for each child element that may not be uniqueExample:"param": [ { "@name": "Accept", "@style": "header" }, { "@name": "Cache-control", "@style": "header" } ]****** Extra stuff – delete before publishing ******RS Resource HierarchyA resource hierarchy that includes all Services//retrieve/dicom/studies/…/retrieve/rendered/studies/…/retrieve/rendered/ps/studies/…/store/studies/search/studies/search/series/search/instances/workflowA simpler resource hierarchy that includes all Services//retrieve/dicom/…/retrieve/rendered/…/retrieve/rendered/ps/…/store/…/search/…/search/series/search/instances/workflow ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download