Sup 219 - JSON Representation of DICOM Structured Reports DICOM Standards Committee - Working Group 23 - Artificial Intelligence/Application Hosting

1300 N. 17th Street Suite 900 Rosslyn VA 22209 USA

2017-2020 NEMA Status: Draft Standard for Trial Use 2020/08/13 This supplement is prepared pursuant to work item: 2019-04-A. Publication of this Draft Standard for Trial Use and Comment has been approved by the Base Standard Working Group of the DICOM Standards Committee. Distribution of this draft standard for comment shall not continue beyond 12 months from the date of publication. It is expected, but not certain, that following this 12 month period, this Draft Standard, revised as necessary, will be submitted to the DICOM Standards Committee for approval as an addition to the DICOM Standard. Suggestions for revision should be directed to David Clunie on behalf of Working Group 23.

This Supplement describes a JSON representation of DICOM Structured Reports, similar to the PS3.18 JSON representation, to allow implementers to encode image-derived results. Patterns are defined for transformation of measurement and annotation information for use-cases related to the reporting of artificial intelligence (AI), machine learning (ML) and quantitative imaging (QI) results. The approach is applicable not only to export of AI/ML results but also to encoding of truth data for AI/ML training, testing and validation. JSON has emerged as the preferred representation for results from machine learning algorithms amongst implementers who are not familiar with the DICOM Standard. Such results typically lack the composite context information required in a managed clinical environment (such as patient and study identity information), as well as references to the DICOM images used as input, needed to store, distribute and render the results on an image viewing system. DICOM Structured Reports (SR) are the most common form of semantically meaningful annotation created and distributed in an interoperable manner for clinical use. Accordingly, this supplement describes a mapping between a JSON representation of the measurement and annotation result payload expected from an AI system, and the traditional binary DICOM SR encoding of the same information. DICOM PS3.16 defines templates for different applications of SR. The TID 1500 Measurement Report template describes a generic pattern that is suitable for encoding AI/ML results as well as other quantitative and qualitative (categorical or descriptive) results. The JSON representation in this Supplement is exemplified using TID 1500, but the representation supports full semantic fidelity round-trip encoding of any DICOM SR instance, regardless of the template. Using an appropriate tool, a complete and compliant binary SR can be created automatically from the JSON, with the subtleties of DICOM encoding hidden from the user. The JSON representation may be useful beyond the primary AI/ML application that motivated the work. It is not expected that the JSON representation will be used as the persistent form, but rather that the existing DICOM binary object storage infrastructure will be used. A multi-step process for transformation is envisaged. First, the result payload itself may be encoded in JSON; this is limited to the minimal necessary information to describe the result itself, for simplicity and ease of use by AI/ML algorithm implementers. Then, this result JSON is merged with the necessary JSON representation of the composite context and other mandatory, or relevant optional, SR content (such as UIDs, image libraries, hierarchical identification and report status management information), which, when transformed, would result in a valid SR IOD with template-compliant content. Finally, the JSON is transformed into the traditional binary DICOM SR representation for transport, storage and management in an interoperable form. An Informative Annex describing such a "successive refinement" approach is included. The scope of this Supplement is limited to describing the representation and the transformation. It is anticipated that future Supplements will extend the DICOMweb services to support transformation of JSON DICOM SR into binary DICOM SR, and to retrieve transformed content, e.g., by leveraging the existing STOW-RS and WADO-RS mechanisms. The JSON representation leverages the "business name" concept from HL7 Green CDA, such that short meaningful strings can be used in the JSON for coded tuples for concept names and values, as well as for DICOM Attributes in the top level Data Set. The business names are defined in separate, potentially reusable, JSON files, which may be user- or organization-supplied or automatically generated. Traditionally, DICOM SR makes extensive use of coded terminology to maximize semantic interoperability and to avoid reinventing existing content. However, choosing and encoding codes can be burdensome to implementers. The use of DICOM Data Element tags rather than keywords can be similarly confusing. Accordingly, "business names" are used as a substitute for the more arcane codes and tags that are normally used. For example, "StudyDate" may be used in the JSON representation in place of (0008,0020), and "Length" may be used as opposed to (410668003, SCT, "Length"). The business names to be used can either by supplied by the creator of the JSON representation, some other organization or authority, or selected from a standard list of keywords from the DICOM Data Dictionary (PS3.6) or business names for concepts provided in the DICOM Content Mapping Resource (DCMR) (PS3.16). The business names are not qualified by any prefix or namespace in the interests of terseness and simplicity. The scope of uniqueness of the business names only has to encompass the encoded JSON file and its accompanying business names JSON file. That said, business names may be as complex a string as the user cares to create, and any current or future convention for pseudo-name space mechanisms can be utilized if desired. The choice of JSON representation leverages the existing PS3.18 Annex F JSON representation of ordinary DICOM objects at the data element level, with the use of keywords in place of data element tags for clarity and simplicity. The DICOM SR content is divided into two components, the data elements representing the SR Content Tree, which are encoded as if each node (content item) of the Content Tree were a distinct entity, and the remainder of the DICOM data elements that are normally encoded in the top level DICOM data set. When parsing the JSON representation, all DICOM keywords that are recognized and that are not part of the SR Content Tree are extracted, then all remaining content is examined for matches with the defined business names. To the extent possible, the relationships and value types that are defined for the DICOM binary SR representation are elided from the JSON representation, and either defined with the business names, or inferred from context. For example, whether a coded concept has a CONTAINS or HAS CONCEPT MOD relationship with its parent CONTAINER value type is not something an AI/ML implementer is likely to be concerned about, and requires a level of DICOM expertise that they are unlikely to have. Accordingly, a coded concept that is always used as a concept modifier can have this declared in the business name descriptor rather than repeating the information in every use in the JSON payload. Similarly, some concepts always have a predictable value type (e.g., of CODE or TEXT or NUM) that can be declared in the business name file. Occasionally, SR content items have no required concept name (e.g., IMAGE references within SCOORD) but such patterns can be detected and inferred. When ambiguity is possible, then the JSON representation can be made explicit to resolve it (e.g., to distinguish TEXT from CODE value types when either may be used and there is ambiguity as to whether the value should be used literally or looked up as a business name for the code value). At this time, no similar standard XML representation is defined, though the concepts are equally applicable, theoretically. The consensus in the AI/ML community at this time seems to be to focus on JSON. Several tool-kits have their own XML schemas and representations for DICOM SR, but there has been no significant effort to harmonize or standardize these, and the outstanding work item to do so (2012-11B) has been withdrawn after many years of inaction. This Supplement defines a new Part, PS3.23, to contain the alternative representation, and includes the existing Attribute level XML and JSON encodings factored out of PS3.19 and PS3.18. Add new Informative Annex to PS3.17 as follows:

A reliable and interoperable interchange framework for the communication of results requires not only that a means of encoding the result payload be defined, but that the result be accompanied by the necessary metadata to allow its management in a patient-related and workflow-related context, even when the result is detached from the system in which it is managed. Just as for DICOM images, this result metadata is defined according to the DICOM Information Model, and it is encoded in the corresponding Composite Instances that are the persistent, interchangeable representation of DICOM Structured Reports. However, it is recognized that result creation and rendering systems may be modular in their design, such that one component of a system may not be aware of, or need to be aware of, certain types of information. As a case in point, a machine-learning-based algorithm that generates a numerical result, such as probability of malignancy, may need no knowledge of a patient's identifying or descriptive metadata. Conversely, a result management system, to which the exact nature of the result payload is essentially opaque, needs the identifying metadata but may be agnostic to result payload structure and content that may be supplied by different algorithms. It is important to identify and communicate the meaning of results to provide context to the receiving/rendering systems in order for them to meaningfully record or render the results. Where appropriate, the results should be named/labeled and coded in the JSON by the a component that knows the meaning of or code associated with that result. The use of Business Names allows separation of the component that uses a concept from the component that provides the details of the concept in the Business Names File. Accordingly, the JSON representation of Structured Reports has been designed to allow for such modularization and division of responsibility for content generation.

This Section describes an example of successive refinement of a relatively simple numerical payload with image-, lesion-, study-, and patient-related metadata. illustrates an example of a pipeline that might used to take algorithm-generated result content in its most minimal form through several successive stages, adding the necessary metadata to generate a complete JSON representation of a valid DICOM Structured Report, which is then converted into its traditional binary representation and sent to an ordinary DICOM Storage SCP. The JSON fragments illustrated in this example are not in their own right valid DICOM SR Instances. Each fragment is merely an intermediate artifact that may be used to communicate between successive steps in a manner that is not defined by the standard, but which may be convenient for implementers. Only the final complete representation with its entire Content Tree and Composite Context is a valid representation that may be transcoded into a valid SOP Instance conforming to the corresponding IOD for the SR Storage SOP Class used. The components in this pipeline need not be physically co-located or on-premise. E.g. the algorithm could execute on a cloud-based computing resource using anonymized data, and the context information be managed and added on-premise when the results were returned.

The AI Algorithm in this example may produce a very simple numeric result, such as the single linear dimension of a tumor illustrated in . This measurement is linked to the image coordinates from which it is derived, as follows: In reality, many machine learning and quantitative algorithms operate on image pixel data that has been extracted from a DICOM Composite Image SOP Instance. Hence the algorithm software may be unaware of the SOP Instance UID and SOP Class UID of the image. It is expected that, at the very least, such algorithms will be wrapped by a management system that maintains the correspondence between the DICOM UIDs and the image pixel data used by the algorithm. Such algorithms may make use of coordinate representations that do not exactly match the DICOM sub-pixel resolution 2D or patient-relative, volume-relative or slide-relative 3D coordinate systems. It is expected that such algorithms will be wrapped by a management system that transforms the coordinates into the standard form as necessary. In this example, the AI algorithm is producing only content encoded according to a nested content template, which is intended to be later embedded in a more complete root template such as TID 1500. As such, the root content item that it produces starts at the MeasurementGroup (ROI) level, not the ImagingMeasurementReport level. There is no lesion tracking information provided, since this particular hypothetical algorithm is assumed to be unaware of longitudinal temporal relationships. Next, the Lesion Manager adds longitudinal lesion tracking information, a finding and a finding site, since it has access to out-of-band information related to lesions measured at different time points: Next, a DICOM-Image Aware System wraps the nested MeasurementGroup level content into a root-template, such as an ImagingMeasurementReport, and adds contextual information that includes: identification of the template used language information Image Library entries corresponding to the referenced images information about the Procedure Reported Person Observer Context Finally, a Patient-Study Aware System takes the Structured Report Content Tree from the previous stage, and adds the necessary top-level DICOM Data Set Attributes to produce a valid DICOM SOP Instance compliant with the Enhanced SR Storage SOP Class, initially in its JSON Representation. This step includes adding such contextual information as: Patient identifying and descriptive metadata Study identifying and descriptive metadata, including an appropriate StudyInstanceUID, such as that extracted from the referenced image(s) Equipment identifying and descriptive metadata new Series identifying and descriptive metadata, including an appropriate new SeriesInstanceUID new Instance identifying and descriptive metadata, including an appropriate new SOPInstanceUID and an appropriate SR Storage SOP Class UID additional DICOM Attributes and Values necessary to conform to the SR Storage SOP Class, including: additional Person Observer Context information in the AuthorObserverSequence report status management information, such as the CompletionFlag and VerificationFlag the evidence sequence(s) necessary to provide a full hierarchical UID-based route to the reference image content, to support a hierarchical rather than relational query (DIMSE C-FIND or QIDO-RS), such as the CurrentRequestedProcedureEvidenceSequence The Patient-Study Aware System then transforms the JSON representation into the traditional binary DICOM SR representation and transmits the persistent object to the PACS using either a DIMSE C-STORE Operation or a DICOMweb Store (STOW-RS) Transaction. For clarity, the necessary Business Names Files accompanying the communication between each stage of the pipeline have been elided from the example above. Whether particular Business Names are assumed in the hypothetical transactions between successive steps or are explicitly communicated in Business Names Files is not defined. For the sake of argument, the simplest Business Names File to support the initial communication between the AI Algorithm and the Lesion Manager would be as follows: For the last step in this example, conversion by a separate tool from a complete JSON representation to the binary DICOM form of the Structured Report, the complete Business Names File (as defined for the similar example in PS3.23 Section B.3.4.2.4), as well as a dictionary of DICOM Standard Data Element Keywords, would be required,

Why are content items nested in a JSON Array? DICOM SR templates may specify that the order of content items is significant, and only JSON Arrays preserve order; the fields of a JSON Object are specifically unordered. I.e., though this suggested alternative would be seem to be simpler: and is valid JSON, it would not preserve the order of the content items, so this is the structure required by the DICOM Standard: Also, DICOM SR allows for multiple sibling content items with the same concept name, whereas JSON does not permit the use of the same name for name-value pairs within a JSON Object. I.e., though this suggested alternative would be seem to be simpler: it is not valid JSON, so this is the structure required by the DICOM Standard: Why is each content item nested in a JSON Object? JSON Array contents are values, not name-value pairs, so as a consequence of using JSON Arrays to preserve order, each content item name-value pair needs to be nested in an object. I.e., though this suggested alternative would be seem to be simpler: it is not valid JSON, so this is the required structure:

DICOM PS3.23 20xx - Alternative Representations DICOM Standards Committee 2019 NEMA The 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. This 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 . This part of the DICOM Standard describes representations of DICOM encoded instances and messages that are alternatives to the traditional binary encoding defined in PS3.5. It includes: encoding of DICOM instances and messages at the Attribute level in XML, encoding of DICOM instances and messages at the Attribute level in JSON, and encoding of DICOM Structured Reports at the Content Item level in JSON. The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below. ISO/IEC Directives, Part 3 ISO/IEC 1989 RFC4627 IETF July 2006 XML W3C 2006/09/29 For the purposes of this Standard the following definitions apply.

The following definitions are commonly used in this Part of the DICOM Standard: Coding Schemes Dictionaries (lexicons) of concepts (terms) with assigned codes and well defined meanings. Content Item A node in the Content Tree of a DICOM SR document, consisting of either a container with a coded Concept Name, or a name-value pair with a coded Concept Name and a Concept Value. Content Tree The tree of Content Items of a DICOM SR document. Context Group A set of coded concepts defined by a Mapping Resource forming a set appropriate to use in a particular context. Context ID (CID) Identifier of a Context Group. Template A pattern that describes the Content Items, Value Types, Relationship Types and Value Sets that may be used in part of a Structured Report Content Tree, or in other Content Item constructs, such as Acquisition Context or Protocol Context. Analogous to a Module of an Information Object Definition. Template ID (TID) Identifier of a Template.

The following definitions are commonly used in this Part of the DICOM Standard: Business Name Identifier for a Concept or Attribute that corresponds to a business requirement for information exchange. See also a similar definition in PS3.20 in the context of HL7 CDA templates, and discussion in PS3.20 Section 5.2.1, which includes the statement that "the use of readable and intuitive Business Names provides a method of direct access to insert data that is specific to each clinical report instance". Composite Context Those Attributes of higher-level Entities in the Information Model that provide the Context for newly created lower-level Entities, and which have the same values as other lower-level Entities have for the same higher-level Entities. Typically the Patient and Study Composite Context are merged with (shared by) new Series and Instance level information when a new Series of Instances is created on a different device or on a different occasion than the earlier Instances.

The following symbols and abbreviations are used in this Part of the Standard. DICOM Digital Imaging and Communications in Medicine IOD Information Object Definition ISO International Standards Organization JSON JavaScript Object Notation NEMA National Electrical Manufacturers Association SR Structured Reporting UCUM Unified Code for Units of Measure UID Unique Identifier XML Extensible Markup Language XSLT Extensible Stylesheet Language Transformations Terms listed in Definitions are capitalized throughout the document.

XML (Extensible Markup Language) is a language that defines a set of rules for encoding documents and other data structures in a format that is both human-readable and machine-readable. It is language-independent, and primarily used for serializing and transmitting structured data. It is described in detail by the W3C .

Include contents of PS3.19 Section A.1 Native DICOM Model, renaming "Native DICOM Model" to "XML Encoding of DICOM Instances in Native Format" and renumbering sections appropriately.

...

...

...

...

...

...

...

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 .

The JSON Encoding of DICOM Instances and Messages defines a representation of DICOM SOP Instances as JSON that allows a sender or recipient of data to create or navigate through a DICOM Data Set using JSON-based tools instead of relying on tool kits that understand the binary encoding of DICOM. An alternative JSON encoding is defined in for Structured Reports, in a manner that abstracts the Content Tree structure rather than encoding individual elements of each content item. This does not mean that an SR cannot be encoded using the representation described in this Section.

Include contents of PS3.18 Section F.2 DICOM JSON Model, renaming "DICOM JSON Model" to "JSON Encoding of DICOM Instances and Messages" and renumbering sections appropriately:

Include contents of PS3.18 Section F.3 Transformation with other DICOM Formats, renaming "DICOM JSON Model" to "JSON Encoding of DICOM Instances and Messages" and renumbering sections appropriately:

Include contents of PS3.18 Section DICOM JSON Model Example, renaming "DICOM JSON Model" to "JSON Encoding of DICOM Instances and Messages" and renumbering sections appropriately:

The JSON Encoding of DICOM Structured Reports defines a representation of DICOM Structured Report Instances as JSON that allows a sender or recipient of data to create or navigate through a DICOM Structured Report using JSON-based tools instead of relying on tool kits that understand the binary encoding of DICOM. An alternative JSON encoding is defined in for any Data Set, including DICOM Structured Reports, in a manner that encodes individual elements of each content item, rather than abstracting the Content Tree structure. The encoding described in this Section allows for representation of DICOM SR SOP Instances as JSON in a manner that satisfies the goal of enabling the use of JSON-based tools (as does the alternative JSON encoding in ), but additionally allows a sender or recipient of data to create or navigate through a JSON-encoded DICOM Data Set with less knowledge of the native DICOM encoding details. The representation in this Section provides a simplified syntax that allows the use of standard keywords or arbitrary Business Names, which are easier to construct and read. This helps implementers who may not be intimately familiar with the coding systems related to their data. Further, this representation facilitates the incremental construction of an instance by separate steps (i.e., "successive refinement"), by allowing the encoding to represent a distinct subset of an entire instance. The concept of successive refinement helps implementers who may not have the full context required to define a complete DICOM instance. See the informative discussion in PS3.17 .

The JSON SR encoding consists of two types of file: a JSON-encoded Content File a JSON-encoded Business Names File Corresponding Media Types are declared as follows: application/x-dicom-sr+json for the JSON-encoded Content File application/x-dicom-bn+json for the JSON-encoded Business Names File These Media Types are experimental. They will be replaced by official Media Types once this Supplement is Final Text and appropriate types are registered with IANA. At this time there is no PS3.18 Study Retrieval (WADO-RS) behavior defined that uses these media types. However, if a user agent were to request the retrieval of a DICOM SR instance and to restrict the Accept header to these two experimental media types, an origin server that implements the transformation of the binary DICOM SR to the JSON encoding is not prohibited from returning it in the requested form. The default character repertoire for both the JSON-encoded Content File and the JSON-encoded Business Names File shall be UTF-8 / ISO_IR 192. The Content File consists of: a single top-level array containing a single JSON object (i.e., a single "result" in terminology), that single JSON object containing an unordered set of subordinate JSON objects, each of which is either: a JSON-encoded DICOM Attribute of the top level Data Set, or the root node of a JSON-encoded DICOM Structured Report Content Tree In , the set of subordinate objects is defined to be ordered by their property name in ascending order. No such order is required in the representation defined here, since the property names are Business Names, not hexadecimal numeric representations of a DICOM Tag. There is no need to sort the property names alphabetically, and it would be unnecessarily burdensome to the author of the JSON representation to require them to be sorted in their binary DICOM Tag order, though such ordering will be required when converting to binary DICOM encoding. Business Names are used to identify: DICOM Attributes (rather than using DICOM Data Element Tags) Codes used in the DICOM SR Content Tree Restrictions on the format of Business Names are described in . Standard DICOM Attributes used in the Content File are identified by the Keyword used in the PS3.6 Table 6-1 Registry of DICOM Data Elements. It is not necessary to define Standard DICOM Attributes used in the Business Names File, but it is not prohibited. If Private DICOM Attributes are present, corresponding Private Creator Data Elements shall also be present. Private DICOM Attributes used in the Content File may be defined in the Business Names File. All codes used in the Content File shall be defined in the Business Names File. Business Names are not used for Code Sequence Items in Code Sequence Attributes outside of the SR Content Tree; rather, they are encoded in the traditional manner, i.e., as individual DICOM Attributes. The reasons for this are (a) to align the DICOM Attribute header as closely with as possible, and (b) very few, if any, Code Sequence Items are used in DICOM Structured Reporting SOP Classes outside of the SR Content Tree. The Business Names File also encodes other information related to the Content Items for which a Code is used as the Concept Name, including: Value Type Relationship

Each DICOM Attribute in the top level Data Set, and all of the DICOM Attributes nested within Sequence Attributes in the top level Data Set, except the Attributes describing the root node of the Structured Report Content Tree, are encoded as follows: Each Attribute shall be encoded in the same manner as used for the JSON Encoding of DICOM Instances and Messages, as defined in , except that In place of the eight character uppercase hexadecimal representation of a DICOM Tag used as the name of each Attribute object, one of the following may be used: a Standard DICOM Data Element Keyword from PS3.6 Table 6-1 Registry of DICOM Data Elements, or a Business Name defined in the Business Names File The Value Representation ("vr") may be omitted for Standard Data Element Keywords (since a dictionary is expected to be available to the parser), or if it is defined in the Business Names File A single JSON String may be used in place of the JSON Object and its enclosed "Value" Array when the value consists of a single value and the "vr" has been omitted An empty JSON String (""), empty JSON object ({}), or null may be used to encode a zero length value In place of a UID encoded in a UI VR, a Standard DICOM UID Keyword from PS3.6 Table A-1 UID Values may be used No mechanism is provided to define UIDs in the Business Names File. For example, any of the following is a valid encoding of the same Attribute that contains a single value: The following are valid encodings of the same Attribute that contains no value (is zero length): For consistency with the JSON encoding described in , a null value is not used when a multi-valued attribute has one or more empty values, in which case a "Value" Array is always present. The following would also be valid, if the Business Names "FechaDeEstudio" or "検査日" were defined for the DICOM Data Element in the Business Names File: The following are valid encodings of the same UI VR Attribute, using either a standard keyword or the actual UID: The following is an example of a Private Data Element, together with the required Private Creator, encoded using the hexadecimal tag: or encoded using a Business Name, if "NumberOfPhases" and "AcmeCorpCreator" were defined in the Business Names File: The following Attributes in the top level Data Set describing the root node of the Structured Report Content Tree shall not be encoded as described in this section: ContentSequence ValueType ConceptNameCodeSequence ContinuityOfContent ContentTemplateSequence MappingResource TemplateIdentifier

A DICOM Structured Report Content Tree consists of a nested set of Content Items of unlimited depth, beginning with a single root Content Item.

Each Content Item, including the root Content Item, shall be encoded as a single JSON name-value pair, consisting of: a JSON name, which is a Business Name defined in the Business Names File, for the DICOM Concept Name Code Sequence a JSON value, which is a JSON Array (or in the case of an unannotated leaf node, a JSON String), whose encoding depends on: the DICOM Content Item Value Type whether the Content Item is a leaf node of the tree or has children whether children are by-value or by-reference Neither the Value Type nor the Relationship Type are explicitly encoded in the JSON SR Content Tree representation, since: appropriate types are defined in the Business Name File when more than one type is defined in the Business Name File, sufficient context allows the Value Type and the Relationship Type to be deduced for anonymous Content Items (those without a Concept Name), sufficient context allows the Value Type and the Relationship Type to be deduced The following is an example of a leaf Content Item: The enclosing JSON Array may be omitted for a leaf node with a single value, no children and no annotations, and a single JSON String used to represent the text value or a coded value Business Name. The following is an example of the same leaf Content Item without the enclosing JSON Array for the value:

For Content Items with children, the last entry of the JSON object value Array is itself an Array, which contains the ordered list of child Content Items, each of which is a JSON object. Leaf Content Items omit the final Array, rather than encoding an empty Array. Arrays are used to preserve the order of child Content Items, which may be significant. Use of an Array allows for multiple children with the same Concept Name, since JSON does not permit multiple JSON Objects with the same name. The following is an example of a CODE Content Item with one child that is also a CODE Content Item:

There are Attributes of Content Items that need to be encoded to describe particular Attributes of specific Value Types of Content Items, to preserve the full fidelity of the content and to address structural concerns, such as by-reference relationships. These are encoded using Standard Content Item Annotations. The first item of the JSON object value Array may be a JSON Object, containing a set of JSON Objects each of which is a Content Item Annotation. The names of all Standard Content Item Annotations begin with the "_" symbol. The Standard Content Item Annotations that may be used with any Content Item Value Type are: _label A JSON String that is the label of a Content Item that may be the target of a by-reference relationship _ref A JSON String that is the reference to a labeled Content Item that is the target of a by-reference relationship _obsdt A JSON String that is the value of the ObservationDateTime (DT VR) of a Content Item _obsuid A JSON String that is the value of the ObservationUID (UI VR) of a Content Item Annotations that are specific to individual Value Types of Content Items are described in the definition of each Value Type. Other annotations than those defined in the standard are permitted in the Content Item Annotation object as long as their names do not begin with the "_" symbol. The intent of allowing other annotations is to allow preservation of private DICOM Attributes that may be associated with the Content Item, but for which no standard representation is defined. This is an example of Content Item Annotations used to describe ObservationDateTime and ObservationUID of a leaf CODE Content Item:

Most commonly, the Content Tree is strictly hierarchical (i.e., a tree) and many templates and some SR Storage SOP Classes constrain the encoding to that pattern. However, by-reference relationships (which allow for a directed acyclic graph) are permitted by the underlying mechanism and hence are supported in the JSON encoding by use of Content Item Annotations. Both the referenced Content Item and the referencing Content Item need to be decorated with Content Item Annotations as follows: The referenced Content Item must have a _label annotation, whose value shall be a string unique amongst such labels within the instance. The referencing Content Item must have a _ref annotation, whose value shall correspond to the _label annotation of the referenced Content Item within the instance. In the traditional binary DICOM SR encoding, references are made using ReferencedContentItemIdentifier (see PS3.3 C.17.3.2.5), which is the numeric hierarchical position (the set of ordinal positions along the by-value relationship path from the root Content Item) in the Content Tree. The _label and _ref annotations are not required to be the numeric hierarchical position in the Content Tree. Accordingly, a receiver should not expect to be able to parse the structure of labels, only recognize them. The parser of the JSON representation is required to map the _ref values to the numeric hierarchical position by tracking the position of Content Items with _label annotations. Since forward references are permitted, this may require two passes of the JSON file. The following is a simplified example of a reference from a CAD finding SCOORD to an IMAGE Content Item in an Image Library:

The encoding of Content Items depends on their Value Type. There is a specific JSON representation for each of the Value Types defined in PS3.3 Table C.17-5 Document Content Macro Attributes. The pattern of encoding for each Value Type not only allows each Content Item to be encoded with full fidelity, but also allows for recognition of the Value Type by the parser when it is not explicitly defined for the Concept Name in the Business Names File, or is potentially ambiguous, such as for anonymous Content Items that do not have a Concept Name.

The following Value Type never has a value, though it may have children, and is encoded in the JSON value Array without a value: CONTAINER The following is an example of a CONTAINER Content Item, where the code and Value Type for "ImageLibrary" are defined in the Business Names File: The following is an example of a CONTAINER Content Item, with one child that is a CONTAINER with no children of its own: A parser can assume that a CONTAINS, HAS CONCEPT MOD, HAS ACQ CONTEXT or HAS OBS CONTEXT Relationship Type is needed between a parent CONTAINER Content Item and any type of child Content Item, since those are the only relationships permitted for CONTAINER parents. A typical example would be a CODE child of a CONTAINER with a CONTAINS relationship, where as the same CODE may be used elsewhere as a child of a non-container (such as a CODE or NUM) with a HAS PROPERTIES relationship. The Standard Content Item Annotations that are specific to CONTAINER are: _tid A JSON String that is the TemplateIdentifier (VR CS) value of the ContentTemplateSequence of a CONTAINER Content Item _tmr A JSON String that is the template MappingResource (VR CS) value of the ContentTemplateSequence of a CONTAINER Content Item _tmruid A JSON String that is the template MappingResourceUID (VR UI) value of the ContentTemplateSequence of a CONTAINER Content Item _cont A JSON String that is the ContinuityOfContent (VR CS) value of a CONTAINER Content Item. If absent, defaults to "SEPARATE". This is an example of Content Item Annotations used to describe the template used for a root level CONTAINER (with the child Array illustrated but children omitted):

The following Value Types consist of a single value that is either textual or a code, and are all encoded in the JSON value Array using a single JSON String: CODE DATE DATETIME TEXT TIME UIDREF The JSON String value may represent a text value, or a Business Name representing a code or UID, depending on the Value Type deduced from the Concept Name. A parser can assume that the Value Type is CODE when the encoded value is a JSON String that can be found amongst the set of Business Names. A typical example of when this is necessary would be when the same Concept Name is used for both CODE and TEXT content items. The following are examples of a TEXT Content Item with no children, where the code and Value Type for "Comment" is defined in the Business Names File, encoded with and without the enclosing JSON Array: The following is an example of a CODE Content Item with no children, where the code and Value Type for "FindingSite", as well as the code for the "Liver", are defined in the Business Names File, encoded with and without the enclosing JSON Array: The following is an example of a CODE Content Item with one child that is also a CODE Content Item, with no children of its own:

The following Value Type consists of a single numeric value encoded in a JSON String or JSON Number: NUM The JSON String or JSON Number is the value of the NumericValue (VR DS) in MeasuredValueSequence. Either a JSON String or JSON Number is permitted, and a JSON String may be used to preserve the original format during transformation of the representation, or if needed to avoid losing precision of a decimal string. Since the encoding of the value in the binary DICOM SR is as a Decimal String, use of a JSON Number rather than a JSON String may result in formatting changes, such as removal of trailing zeroes after the decimal point, removal of a decimal point if the value is a whole integer and conversion from scientific to decimal notation, which may affect string value comparison in a round trip. Allowing either a JSON String or JSON Number is consistent with the handling of IS and DS attributes outside the Content Tree as described in . The Standard Content Item Annotations that are specific to NUM are: _units A JSON String that is the Business Name of the code in the MeasurementUnitsCodeSequence (VR SQ) in MeasuredValueSequence. _float A JSON Number that is the value of the FloatingPointValue (VR FD) in MeasuredValueSequence. _numerator A JSON Number that is the value of the RationalNumeratorValue (VR SL) in MeasuredValueSequence. _denominator A JSON Number that is the value of the RationalDenominatorValue (VR SL) in MeasuredValueSequence. _numqual A JSON String that is the Business Name of the code in NumericValueQualifierCodeSequence (VR SQ) in MeasuredValueSequence. See PS3.3 Table C.18.1-1 Numeric Measurement Macro Attributes for further details of what these Attributes mean. The following is an example of a NUM Content Item with no children, where the code and Value Type for "Length", as well as the code for the "mm", are defined in the Business Names File, and the numeric value is encoded as a JSON String: This is the same example, but with the numeric value encoded as a JSON Number: This is a (contrived) example of the less commonly used NUM Content Item Annotations, using a Business Name of "MeasurementFailure" for (114006, DCM, "Measurement failure"):

The following Value Types reference Storage SOP Instances: COMPOSITE IMAGE WAVEFORM The Standard Content Item Annotations that are shared by COMPOSITE, IMAGE and WAVEFORM are: _class A JSON String that is the value of ReferencedSOPClassUID (VR UI) in ReferencedSOPSequence _instance A JSON String that is the value of ReferencedSOPInstanceUID (VR UI) in ReferencedSOPSequence The additional Standard Content Item Annotations that are specific to IMAGE are: _frame A JSON Number that is the single value of ReferencedFrameNumber (VR US), or a JSON Array that contains the one or more values of ReferencedFrameNumber _segment A JSON Number that is the value of ReferencedSegmentNumber (VR US) _prclass A JSON String that is the value of ReferencedSOPClassUID (VR UI) in ReferencedSOPSequence (to a Presentation State Instance) within ReferencedSOPSequence _prinstance A JSON String that is the value of ReferencedSOPInstanceUID (VR UI) in ReferencedSOPSequence (to a Presentation State Instance) within ReferencedSOPSequence _rwvmclass A JSON String that is the value of ReferencedSOPClassUID (VR UI) in ReferencedRealWorldValueMappingInstanceSequence _rwvminstance A JSON String that is the value of ReferencedSOPInstanceUID (VR UI) in ReferencedRealWorldValueMappingInstanceSequence The following is an example of an IMAGE Content Item with no children, for which the Concept Name describes the purpose of reference: The following is an example of an IMAGE Content Item with no children, for which there is no Concept Name encoded (i.e., is an anonymous Content Item): A parser can detect that this is an IMAGE (rather than a COMPOSITE or WAVEFORM) Content Item even in the absence of a Business Name for the Concept Name, by recognizing that the standard Content Item Annotation "_class" is present and has a value that is recognized as an Image Storage SOP Class UID. The following is an example of an IMAGE Content Item with no children, for which the Concept Name describes the purpose of reference and with a ReferencedSegmentNumber: The additional Standard Content Item Annotations that are specific to WAVEFORM are: [TBD.] [TBD. If a WAVEFORM Content Item has other Attributes than ReferencedSOPClassUID and ReferencedSOPInstanceUID ....]

The following Value Types encode coordinates and their type: SCOORD SCOORD3D TCOORD The Standard Content Item Annotations that are common to SCOORD and SCOORD3D are: _gtype A JSON String that is the value of GraphicType (VR CS) The Standard Content Item Annotations that are specific to SCOORD are: _coord2d A JSON Array that contains the values of GraphicData (VR FL) The following is an example of an SCOORD Content Item SELECTED FROM an IMAGE, for which there is no Concept Name encoded for either (i.e., they are both anonymous Content Items): A parser can detect that this is an SCOORD Content Item even in the absence of a Business Name for the Concept Name by recognizing that the standard Content Item Annotation "_coord2d" is present. The use of a distinct annotation specific to 2D coordinates simplifies distinguishing the content item from an SCOORD3D, as well as signalling that the coordinate tuples have two values. A parser can assume that a SELECTED FROM Relationship Type is needed between the parent SCOORD Content Item and the child IMAGE Content Item, since that is the only relationship permitted between these two Value Types. A parser can assume that an INFERRED FROM Relationship Type is needed between a parent TEXT, CODE or NUM Content Item and a child SCOORD Content Item, since that is the only relationship permitted between these Value Types. [TBD. Add other annotations, specifically PixelOriginInterpretation (for WSI) and FiducialUID.] The Standard Content Item Annotations that are specific to SCOORD3D are: _coord3d A JSON Array that contains the values of GraphicData (VR FL) _for A JSON String that contains the value of ReferencedFrameOfReferenceUID (VR UI) The following is an example of an SCOORD3D Content Item, for which there is no Concept Name encoded (i.e., it is an anonymous Content Item): A parser can detect that this is an SCOORD3D Content Item even in the absence of a Business Name for the Concept Name by recognizing that the standard Content Item Annotation "_coord3d" is present. The use of a distinct annotation specific to 3D coordinates simplifies distinguishing the content item from an SCOORD, as well as signalling that the coordinate tuples have three values. [TBD. The Standard Content Item Annotations that are specific to TCOORD are:] [TBD. ... annotations for TemporalRangeType, ReferencedSamplePositions, ReferencedTimeOffsets or Referenced DateTime.]

The following Value Type encodes person names: PNAME The Standard Content Item Annotations that are specific to PNAME are: _alphabetic A JSON String that is the alphabetic group of PN components. _ideographic A JSON String that is the ideographic group of PN components. _phonetic A JSON String that is the phonetic group of PN components. The annotation property names are different than those used in the top level data set representation of PN attributes, because reserved keywords are required to begin with an underscore. The components and component groups of a PN VR are described in PS3.5 Section 6.2 Value Representation (VR). The following is an example of a PNAME Content Item with no children, with only an alphabetic group: The following is an example of a PNAME Content Item with no children, with an alphabetic and ideographic but no phonetic group:

The Business Names File consists of: a single top-level array containing zero or more JSON objects, each of those JSON objects describing: a coded concept used as the concept name of a name-value pair, a coded concept used as the value of a name-value pair, or a DICOM data element. Each JSON object in the top level array contains a single subordinate JSON object that has a property name that is the Business Name. The JSON objects are nested since the same property name may be used to describe both a coded concept and a DICOM data element. E.g., such concepts as "StudyDate" or "Modality" may be used in the Content File as a DICOM Attribute or Content Item or both.

Business Names shall consist of letters, digits, and underscores (the '_' symbol), but no other special characters. Business Names shall not begin with an underscore, which is reserved for annotations defined by the DICOM standard. Business Names are case sensitive. These restrictions are a subset of valid JSON property names (https://www.json.org/json-en.html) and valid JavaScript identifiers Though the use of upper camel-case (https://en.wikipedia.org/wiki/Camel_case), US-ASCII strings matches the convention used for DICOM Data Element keywords in PS3.6, it is not required for user-defined business names. For example, it is preferred that "ImageRegion" be used, rather than "imageRegion" or "Imageregion" or "Image_Region", but none of these other variants is explicitly prohibited. However, "Image Region" is prohibited since spaces are not permitted, even though JSON theoretically allows spaces in property names. Specifically, strings in localized character sets are permitted, and this includes letters within those localized character sets. The business names used for units are a special case, for which it may be important to preserve the correct case. E.g., one would not want to capitalize "mm" as "Mm", but "Millimeter" would be reasonable. There is considerable variation in PS3.16 templates and context groups with respect to whether code meanings for units are abbreviated or not. See also the discussions at https://google.github.io/styleguide/jsoncstyleguide.xml#Property_Name_Guidelines and https://mathiasbynens.be/notes/javascript-identifiers. It is strongly advised that known JavaScript reserved words not be used as Business Names (specifically, keywords, future reserved words, null literals and Boolean literals).

A coded concept, whether used as a value or concept name, is defined with the following basic properties: _cv The CodeValue of the coded concept _csd The CodingSchemeDesignator of the coded concept _cm The CodeMeaning of the coded concept This is an example of the definition of a coded concept for (41806-1, LN, "CT Abdomen"): A coded concept that is used as the Concept Name of a Content Item is defined with the following additional properties: _vt The Value Type of the Content Item, encoded as a JSON Array of one or more JSON Strings corresponding to the Value Types defined in PS3.3 Table C.17.3-7. _rel The Relationship Type of the Content Item with its parent Content Item, encoded as a JSON Array of one or more JSON Strings corresponding to the Relationship Types defined in PS3.3 Table C.17.3-8. A JSON Array rather than a single JSON String value is used, since some Concept Names may be used with different types in different contexts. E.g., (121050, DCM, "Equivalent Meaning of Concept Name") may have a CODE or a TEXT Value Type. (111010, DCM, "Center") may have a HAS PROPERTIES or INFERRED FROM Relationship Type. This is an example of the definition of a coded concept for (363698007, SCT, "Finding Site") that may be used as a Concept Name of a Content Item, with the Value Type of CODE and a Relationship Type of HAS CONCEPT MOD: Less commonly used (extended) properties of the coded concept are as follows: _csv The CodingSchemeVersion (VR SH) _lcv The LongCodeValue (VR UC) _urncv The URNCodeValue (VR UR) _cid The ContextIdentifier (VR CS) _cuid The ContextUID (VR UI) _cmr The MappingResource (VR CS) _cmruid The MappingResourceUID (VR UI) _cmrname The MappingResourceName (VR LO) _cvers The ContextGroupVersion (VR DT) _cext The ContextGroupExtensionFlag (VR CS) _clocvers The ContextGroupLocalVersion (VR DT) _cextcruid The ContextGroupExtensionCreatorUID (VR UI)

A DICOM data element, whether Standard or Private, is defined with the following basic properties: _tag The eight character uppercase hexadecimal representation of a DICOM Tag, as defined in . _vr The Value Representation encoded as JSON String corresponding to the Value Representations defined in PS3.5 Table 6.2-1 This is an example of the definition of a Standard Data Element, Series Instance UID (0020,000E): In the case of Private Data Elements, the tag shall be exactly as encoded in the Data Set, i.e., with the block number included. The corresponding Private Creator Data Element is included in the JSON-encoded SR Content File. This is to be consistent with the encoding defined in . It also means that neither the creator nor the parser needs to be aware of the distinction between Private and Standard Data Elements when transforming between the binary and JSON representations. This is an example of the definition of a Private Data Element and its corresponding Private Creator: The value of the Private Creator Data Element is not specified in the Business Names File, and needs to be encoded in the JSON Content File, e.g., "ACME CORP ELEMENTS" or similar. There is no relationship defined in the Business Names File between the Private Data Element and the Private Creator. It is only in the JSON Content File, which makes use of these Business Names, that the correspondence between the definition of a block of Private Data Elements and the use of that block is established through the Data Element Tag numerical values as defined in PS3.5 Section 7.8.1.

The following is the simplest example of the content that TID 1500 allows for a single linear distance measurement. Note that TID 1500 requires both a Tracking Identifier and Tracking Unique Identifier. These are minimal requirements of the Template, not of the JSON transformation per se, and might not be needed by other Templates.

A compact representation of the semantic content of the transformed DICOM SR tree is shown here: CONTAINS: CONTAINER: (126010,DCM,"Imaging Measurements") [SEPARATE] >>CONTAINS: CONTAINER: (125007,DCM,"Measurement Group") [SEPARATE] >>>HAS OBS CONTEXT: TEXT: (112039,DCM,"Tracking Identifier") = "5b6eb4301d3175942d29985a3d0fbb00" >>>HAS OBS CONTEXT: UIDREF: (112040,DCM,"Tracking Unique Identifier") = "1.3.6.1.4.1.5962.1.1.0.0.0.1535644357.22655.1" >>>CONTAINS: NUM: (410668003,SCT,"Length") = 66.43856134 (mm,UCUM,"mm") >>>>INFERRED FROM: SCOORD: = POLYLINE {172.835357666016,270.064086914062,133.798889160156,343.045318603516} >>>>>SELECTED FROM: IMAGE: = (1.2.840.10008.5.1.4.1.1.2,1.3.6.1.4.1.14519.5.2.1.9203.4004.268018422288818573226516023762) ]]>

This is the JSON File consisting of just the Content Item Tree, with the DICOM top level Data Set omitted for clarity, such as might be produced by an AI Algorithm and Lesion Manager before merging with the Composite Context:

The following is a more realistic example of a TID 1500 encoding of a single linear distance measurement, which adds Language and Country, the Person Observer, the Procedure Reported, an Image Library entry, and a Finding Site.

A compact representation of the semantic content of the transformed DICOM SR tree is shown here: HAS CONCEPT MOD: CODE: (121049,DCM,"Language of Content Item and Descendants") = (eng,RFC5646,"English") >>HAS CONCEPT MOD: CODE: (121046,DCM,"Country of Language") = (US,ISO3166_1,"United States") >HAS OBS CONTEXT: PNAME: (121008,DCM,"Person Observer Name") = "adventurous_cod" >HAS CONCEPT MOD: CODE: (121058,DCM,"Procedure reported") = (41806-1,LN,"CT Abdomen") >CONTAINS: CONTAINER: (111028,DCM,"Image Library") [SEPARATE] >>CONTAINS: CONTAINER: (126200,DCM,"Image Library Group") [SEPARATE] >>>CONTAINS: IMAGE: (121112,DCM,"Source of Measurement") = (1.2.840.10008.5.1.4.1.1.2,1.3.6.1.4.1.14519.5.2.1.8421.4008.767475413701844560980492237110) >>>>HAS ACQ CONTEXT: CODE: (121139,DCM,"Modality") = (CT,DCM,"Computed Tomography") >>>>HAS ACQ CONTEXT: DATE: (111060,DCM,"Study Date") = "19921113" >>>>HAS ACQ CONTEXT: TIME: (111061,DCM,"Study Time") = "135823" >CONTAINS: CONTAINER: (126010,DCM,"Imaging Measurements") [SEPARATE] >>CONTAINS: CONTAINER: (125007,DCM,"Measurement Group") [SEPARATE] >>>HAS OBS CONTEXT: TEXT: (112039,DCM,"Tracking Identifier") = "5b6eb4301d3175942d29985a3d1b142f" >>>HAS OBS CONTEXT: UIDREF: (112040,DCM,"Tracking Unique Identifier") = "1.3.6.1.4.1.5962.1.1.0.0.0.1535644357.22655.48" >>>CONTAINS: CODE: (121071,DCM,"Finding") = (108369006,SCT,"Neoplasm") >>>HAS CONCEPT MOD: CODE: (363698007,SCT,"Finding Site") = (10200004,SCT,"Liver") >>>CONTAINS: NUM: (410668003,SCT,"Length") = 97.08595644 (mm,UCUM,"mm") >>>>INFERRED FROM: SCOORD: (121055,DCM,"Path") = POLYLINE {186.41325378418,274.590057373047,89.1049728393555,374.727081298828} >>>>>SELECTED FROM: IMAGE: (121112,DCM,"Source of Measurement") = (1.2.840.10008.5.1.4.1.1.2,1.3.6.1.4.1.14519.5.2.1.8421.4008.767475413701844560980492237110) ]]>

This is the JSON File consisting of just the Content Item Tree, with the DICOM top level Data Set omitted for clarity, such as might be produced by an AI tool before merging with the Composite Context:

This is the entire JSON File consisting of the DICOM top level Data Set and the Content Item Tree, such as might be produced after merging the AI tool output with the Composite Context required to encode a valid SOP Instance:

This is the JSON Business Names File for this example, which defines the coded concepts used, as well as the Value Type and Relationship Type for those coded concepts used as Concept Names for Content Items:

This Section describes an example JSON representation of measurement and clinical data SRs for hybrid CT/PET head and neck tumor images. This example is derived from subject QIN-HEADNECK-01-0024 publicly available at The Cancer Image Archive (TCIA) (https://nbia.cancerimagingarchive.net/nbia-search/). The obsolete SRT codes have been replaced with SCT codes, though the UIDs have not been changed. This example uses segmentations rather than spatial coordinates, and so there is a reference to a separate SEG object to define the ROI. Note the use of the "_segment" to select the segment within the referenced SEG object. The (very long) lists of images in the CurrentRequestedProcedureEvidenceSequence and the Image Library from the original have been truncated for the purpose of this example. A few slices are included to illustrate the use of the Image Library and to highlight that once used there, they also need to be included in CurrentRequestedProcedureEvidenceSequence. In this example, the Image Library is used to describe the PET images that were segmented, and describes them as 18^FDG. The use of Person Name Content Items is illustrated, for which the name components and groups are encoded as annotations, even though in this example there is only a single alphabetic component "User1". The use of Private Data Elements is illustrated, in this case from the RSNA CTP tool used for de-identification by TCIA. The use of private codes is illustrated. The use of post-coordinated measurement definitions, e.g., with a primary concept name that indicates the physical quantity, such as SUVbw, and a derivation modifier, such as maximum or mean. A more compact pretty printer has been used than in the other examples. A full description of the project that led to the creation of these images can be found in Fedorov A et al. DICOM for quantitative imaging biomarker development: a standards based approach to sharing clinical data and structured PET/CT analysis results in head and neck cancer research. PeerJ. 2016 May 24;4:e2057. Available from: https://peerj.com/articles/2057/.

A compact representation of the semantic content of the transformed DICOM SR tree is shown here: HAS CONCEPT MOD: CODE: (121049,DCM,"Language of Content Item and Descendants") = (eng,RFC3066,"English") >>HAS CONCEPT MOD: CODE: (121046,DCM,"Country of Language") = (US,ISO3166_1,"United States") >HAS OBS CONTEXT: CODE: (121005,DCM,"Observer Type") = (121006,DCM,"Person") >HAS OBS CONTEXT: PNAME: (121008,DCM,"Person Observer Name") = "User1" >HAS CONCEPT MOD: CODE: (121058,DCM,"Procedure reported") = (44139-4,LN,"PET whole body") >CONTAINS: CONTAINER: (111028,DCM,"Image Library") [SEPARATE] (DCMR,1600) >>CONTAINS: CONTAINER: (126200,DCM,"Image Library Group") [SEPARATE] >>>HAS ACQ CONTEXT: CODE: (121139,DCM,"Modality") = (PT,DCM,"Positron emission tomography") >>>HAS ACQ CONTEXT: DATE: (111060,DCM,"Study Date") = "19860810" >>>HAS ACQ CONTEXT: TIME: (111061,DCM,"Study Time") = "124529.439000" >>>HAS ACQ CONTEXT: DATE: (111018,DCM,"Content Date") = "19860810" >>>HAS ACQ CONTEXT: TIME: (111019,DCM,"Content Time") = "132849.000000" >>>HAS ACQ CONTEXT: DATE: (126201,DCM,"Acquisition Date") = "19860810" >>>HAS ACQ CONTEXT: TIME: (126202,DCM,"Acquisition Time") = "131803.409000" >>>HAS ACQ CONTEXT: UIDREF: (112227,DCM,"Frame of Reference UID") = "1.3.6.1.4.1.14519.5.2.1.2744.7002.148581826664809938988000313184" >>>HAS ACQ CONTEXT: NUM: (110910,DCM,"Pixel Data Rows") = 128 ({pixels},UCUM,"pixels") >>>HAS ACQ CONTEXT: NUM: (110911,DCM,"Pixel Data Columns") = 128 ({pixels},UCUM,"pixels") >>>HAS ACQ CONTEXT: CODE: (89457008,SCT,"Radionuclide") = (77004003,SCT,"^18^Fluorine") >>>HAS ACQ CONTEXT: CODE: (349358000,SCT,"Radiopharmaceutical agent") = (35321007,SCT,"Fluorodeoxyglucose F^18^") >>>CONTAINS: IMAGE: = (1.2.840.10008.5.1.4.1.1.128,1.3.6.1.4.1.14519.5.2.1.2744.7002.221784495212110180451913187136) >>>CONTAINS: IMAGE: = (1.2.840.10008.5.1.4.1.1.128,1.3.6.1.4.1.14519.5.2.1.2744.7002.227723169531643726818780678655) >CONTAINS: CONTAINER: (126010,DCM,"Imaging Measurements") [SEPARATE] >>CONTAINS: CONTAINER: (125007,DCM,"Measurement Group") [SEPARATE] (DCMR,1411) >>>HAS OBS CONTEXT: TEXT: (C67447,NCIt,"Activity Session") = "1" >>>HAS OBS CONTEXT: TEXT: (112039,DCM,"Tracking Identifier") = "primary tumor" >>>HAS OBS CONTEXT: UIDREF: (112040,DCM,"Tracking Unique Identifier") = "2.25.321931685067302978142568823813987841964" >>>CONTAINS: CODE: (121071,DCM,"Finding") = (86049000,SCT,"Neoplasm, Primary") >>>HAS OBS CONTEXT: TEXT: (C2348792,UMLS,"Time Point") = "1" >>>CONTAINS: IMAGE: (121191,DCM,"Referenced Segment") = (1.2.840.10008.5.1.4.1.1.66.4,1.2.276.0.7230010.3.1.4.8323329.20179.1440001365.123124) [Segment 1] >>>CONTAINS: UIDREF: (121232,DCM,"Source series for image segmentation") = "1.3.6.1.4.1.14519.5.2.1.2744.7002.117357550898198415937979788256" >>>CONTAINS: COMPOSITE: (126100,DCM,"Real World Value Map used for measurement") (1.2.840.10008.5.1.4.1.1.67,1.2.276.0.7230010.3.1.4.8323329.19845.1440001342.736084) >>>HAS CONCEPT MOD: CODE: (370129005,SCT,"Measurement Method") = (126410,DCM,"SUV body weight calculation method") >>>HAS CONCEPT MOD: CODE: (363698007,SCT,"Finding Site") = (47975008,SCT,"base of tongue") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 3.6443 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (373098007,SCT,"Mean") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 3.17526 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (255605001,SCT,"Minimum") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 4.42643 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (56851009,SCT,"Maximum") >>>CONTAINS: NUM: (118565006,SCT,"Volume") = 2.28107 (ml,UCUM,"Milliliter") >>>>HAS CONCEPT MOD: CODE: (370129005,SCT,"Measurement Method") = (126030,DCM,"Sum of segmented voxel volumes") >>>CONTAINS: NUM: (126033,DCM,"Total Lesion Glycolysis") = 8.31291 (g,UCUM,"Gram") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 0.268671 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (386136009,SCT,"Standard Deviation") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 3.45872 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (250137,99PMP,"25th Percentile Value") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 3.62904 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (373099004,SCT,"Median") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 3.77375 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (250138,99PMP,"75th Percentile Value") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 4.21502 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (250139,99PMP,"Upper Adjacent Value") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 3.65419 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (C2347976,UMLS,"RMS") >>>CONTAINS: NUM: (250145,99PMP,"Glycolysis Within First Quarter of Intensity Range") = 2.5636 (g,UCUM,"Gram") >>>CONTAINS: NUM: (250146,99PMP,"Glycolysis Within Second Quarter of Intensity Range") = 3.54251 (g,UCUM,"Gram") >>>CONTAINS: NUM: (250147,99PMP,"Glycolysis Within Third Quarter of Intensity Range") = 1.66598 (g,UCUM,"Gram") >>>CONTAINS: NUM: (250148,99PMP,"Glycolysis Within Fourth Quarter of Intensity Range") = 0.54082 (g,UCUM,"Gram") >>>CONTAINS: NUM: (250140,99PMP,"Percent Within First Quarter of Intensity Range") = 33.3333 (%,UCUM,"Percent") >>>CONTAINS: NUM: (250141,99PMP,"Percent Within Second Quarter of Intensity Range") = 42.5926 (%,UCUM,"Percent") >>>CONTAINS: NUM: (250142,99PMP,"Percent Within Third Quarter of Intensity Range") = 18.5185 (%,UCUM,"Percent") >>>CONTAINS: NUM: (250143,99PMP,"Percent Within Fourth Quarter of Intensity Range") = 5.55556 (%,UCUM,"Percent") >>>CONTAINS: NUM: (126037,DCM,"Standardized Added Metabolic Activity") = 2.53492 (g,UCUM,"Gram") >>>CONTAINS: NUM: (126038,DCM,"Standardized Added Metabolic Activity Background") = 2.53302 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>CONTAINS: CONTAINER: (125007,DCM,"Measurement Group") [SEPARATE] (DCMR,1411) >>>HAS OBS CONTEXT: TEXT: (C67447,NCIt,"Activity Session") = "1" >>>HAS OBS CONTEXT: TEXT: (112039,DCM,"Tracking Identifier") = "lymph node 1" >>>HAS OBS CONTEXT: UIDREF: (112040,DCM,"Tracking Unique Identifier") = "2.25.322468926483622453759930389728579237804" >>>CONTAINS: CODE: (121071,DCM,"Finding") = (14799000,SCT,"Neoplasm, Secondary") >>>HAS OBS CONTEXT: TEXT: (C2348792,UMLS,"Time Point") = "1" >>>CONTAINS: IMAGE: (121191,DCM,"Referenced Segment") = (1.2.840.10008.5.1.4.1.1.66.4,1.2.276.0.7230010.3.1.4.8323329.20179.1440001365.123124) [Segment 2] >>>CONTAINS: UIDREF: (121232,DCM,"Source series for image segmentation") = "1.3.6.1.4.1.14519.5.2.1.2744.7002.117357550898198415937979788256" >>>CONTAINS: COMPOSITE: (126100,DCM,"Real World Value Map used for measurement") (1.2.840.10008.5.1.4.1.1.67,1.2.276.0.7230010.3.1.4.8323329.19845.1440001342.736084) >>>HAS CONCEPT MOD: CODE: (370129005,SCT,"Measurement Method") = (126410,DCM,"SUV body weight calculation method") >>>HAS CONCEPT MOD: CODE: (363698007,SCT,"Finding Site") = (312501005,SCT,"lymph node of head and neck") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 4.15059 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (373098007,SCT,"Mean") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 2.95195 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (255605001,SCT,"Minimum") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 7.20806 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (56851009,SCT,"Maximum") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 5.50284 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (126031,DCM,"Peak Value Within ROI") >>>CONTAINS: NUM: (118565006,SCT,"Volume") = 6.71648 (ml,UCUM,"Milliliter") >>>>HAS CONCEPT MOD: CODE: (370129005,SCT,"Measurement Method") = (126030,DCM,"Sum of segmented voxel volumes") >>>CONTAINS: NUM: (126033,DCM,"Total Lesion Glycolysis") = 27.8774 (g,UCUM,"Gram") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 0.995325 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (386136009,SCT,"Standard Deviation") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 3.31104 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (250137,99PMP,"25th Percentile Value") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 3.86546 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (373099004,SCT,"Median") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 4.76111 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (250138,99PMP,"75th Percentile Value") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 6.86802 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (250139,99PMP,"Upper Adjacent Value") >>>CONTAINS: NUM: (126401,DCM,"SUVbw") = 4.26826 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") >>>>HAS CONCEPT MOD: CODE: (121401,DCM,"Derivation") = (C2347976,UMLS,"RMS") >>>CONTAINS: NUM: (250145,99PMP,"Glycolysis Within First Quarter of Intensity Range") = 13.058 (g,UCUM,"Gram") >>>CONTAINS: NUM: (250146,99PMP,"Glycolysis Within Second Quarter of Intensity Range") = 7.63872 (g,UCUM,"Gram") >>>CONTAINS: NUM: (250147,99PMP,"Glycolysis Within Third Quarter of Intensity Range") = 4.66945 (g,UCUM,"Gram") >>>CONTAINS: NUM: (250148,99PMP,"Glycolysis Within Fourth Quarter of Intensity Range") = 2.51121 (g,UCUM,"Gram") >>>CONTAINS: NUM: (250140,99PMP,"Percent Within First Quarter of Intensity Range") = 56.6038 (%,UCUM,"Percent") >>>CONTAINS: NUM: (250141,99PMP,"Percent Within Second Quarter of Intensity Range") = 25.1572 (%,UCUM,"Percent") >>>CONTAINS: NUM: (250142,99PMP,"Percent Within Third Quarter of Intensity Range") = 12.5786 (%,UCUM,"Percent") >>>CONTAINS: NUM: (250143,99PMP,"Percent Within Fourth Quarter of Intensity Range") = 5.66038 (%,UCUM,"Percent") >>>CONTAINS: NUM: (126037,DCM,"Standardized Added Metabolic Activity") = 14.128 (g,UCUM,"Gram") >>>CONTAINS: NUM: (126038,DCM,"Standardized Added Metabolic Activity Background") = 2.0471 ({SUVbw}g/ml,UCUM,"Standardized Uptake Value body weight") ]]>

This is the entire JSON File consisting of the DICOM top level Data Set and the Content Item Tree required to encode a valid SOP Instance:

This is the JSON Business Names File for this example, which defines the coded concepts used, as well as the Value Type and Relationship Type for those coded concepts used as Concept Names for Content Items:

The following suggested JSON Schemas for the Content File and Business Names File are informative only, and do not validate all of the constraints required by the Standard. These schemas have the following characteristics: They use a draft-specific JSON Schema; for some validators, this is required, for others it may need to be generic, e.g., ""http://json-schema.org/schema#" The identifiers ("$id") of the Schemas are only proposed and should not be relied on as standard; also note that earlier drafts of JSON Schema used a property of "id" instead of "$id"

This Schema has the following characteristics: It validates only selected top level Data Set entries, as a means of exemplifying how to validate certain constructs for mandatory attributes It depends on the Business Name "ImagingMeasurementReport" to detect the root SR Content Tree entry, which is otherwise not distinguishable Value Type specific content is not yet validated

This Schema has the following characteristics: The properties of the array are specified as "additionalProperties", since the Business Names are user-defined. The "additionalProperties" nested "pattern" and "properties" entries do not appear to be recognized by the validators tested (i.e., are not checked).

Amend PS3.18 as follows (changes to existing text are bold and underlined for additions and struckthrough for removals):

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 , available at . See PS3.23 . The 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 QIDO-RS use cases (see ).

Amend PS3.18 to delete the entire contents of the following sections that have been moved to PS3.23 and replace them with a statement that they are retired and with a reference to the new location in PS.23:

Retired. See PS3.23 .

Retired. See PS3.23 .

Retired. See PS3.23 .

Amend PS3.19 to delete the entire contents of the following sections that have been moved to PS3.23 and replace them with a statement that they are retired and with a reference to the new location in PS.23:

Retired. See PS3.23 .

Retired. See PS3.23 .

Retired. See PS3.23 .

Retired. See PS3.23 .

Retired. See PS3.23 .

Retired. Se PS3.23e .

Retired. See PS3.23 .