Print
Email- Forum
- Communities
- Enterprise Imaging
- Subject: Submit Public Comments on Supplement 219 JSON Representation of DICOM Structured Reports
Subject: Submit Public Comments on Supplement 219 JSON Representation of DICOM Structured Reports
- Andrea MacLean
-
Topic Author
- Offline
- Posts: 317
4 years 11 months ago #5463
by Andrea MacLean
Subject: Submit Public Comments on Supplement 219 JSON Representation of DICOM Structured Reports was created by Andrea MacLean
Posted on behalf of DICOM International (Luiza)
Subject: Submit Public Comments on Supplement 219 JSON Representation of DICOM Structured Reports.
Scope and Field of Application
This Supplement describes a JSON representation of DICOM Structured Reports, similar to the PS3.18 JSON representation, to allow AI developers 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 developers 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 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 conversion 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 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 developers. 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 a 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.
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 scope of this Supplement is limited to describing the representation and the transformation. 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 a separate, potentially reusable, JSON file, which may be user- or organization-supplied or automatically generated.
DICOM SR traditionally makes very extensive use of coded terminology to maximize semantic interoperability and to avoid reinventing existing content. However, choosing and encoding codes can be burdensome to developers. Similarly, 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, though 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 developer 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).
In the interest of simplicity, the JSON representation chosen is largely positional rather than using named parameters; e.g., the payload of a content item that is a TEXT or CODE value type is an array of strings, which in the degenerate form is a single value, wherein the string is used as a TEXT value or a CODE business name depending on what the concept name is recognized to be, rather than explicitly naming the type of value (i.e., "Kidney" rather than {"@code": "Kidney"}. Similarly, more complex content item value types like NUM or SCOORD or IMAGE, for which there are multiple values with a specific purpose are defined positionally as well, e.g., the position in the array determines whether the business name is for the units, or the UID is for the SOP Class or SOP Instance, or whether the value is the graphic type or an array of coordinates (and for the latter, which are X and Y), etc. This places greater demands on the parser/converter as well as the documentation, but provides simplicity (if not always clarity) for the user. Alternatives such as fully qualifying every parameter with its type and purpose produced an undesirably cluttered representation, especially for the simple use cases.
At this time, no similar standard XML representation is defined, thought the concepts are equally applicable, theoretically. The consensus in the AI/ML community at this time seems to be to focus on JSON. Several toolkits 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.
All comments should be submitted as soon as possible but NO LATER than by midnight, Monday, December 23, 2019.
Who can comment? All interested persons are invited to comment. Recipients of this solicitation should feel free to forward it to anybody who may be interested in this topic but is not listed on DICOM e-mail lists. There is no cost or obligation associated with commenting and no membership in any committee is required to comment but commenters will be requested to include their contact information with their comments.
What will happen to your comments? DICOM Working Group 06 and DICOM Working Group WG-23 will review the comments and discuss their resolution. WG-06 is authorized by the DICOM Standard Committee to decide on the technical merits of the comments.
Instructions for accessing the documents and submitting comments:
1. The DICOM Secretariat (MITA/NEMA) uses the third party software, Higher Logic for the collection and management of the public comments.
2. Download document(s) to local drives:
Click on the links below to download the PDF, Word, and/or XML versions. If the PDF version is different from any other format the PDF governs.
3. Enter and submit comment(s):
When clicking on the “Comment” link below; the comment submission template appears. You may complete multiple comment templates and submit as a single comment (“Save and add another”) or you may submit a single comment (“Save”) and restart the process to submit another comment.
Forms of comments:
• You may enter free text, attach a document containing your comments, or mark-up parts or the whole of the document and attach same.
• If your comments relate to several specific sections, you can combine them in a single comment entry or make separate comment entries.
Mandatory fields:
• Commenter’s name, affiliation, e-mails address.
• “Subject” – Sup 219 PC
• “Comment” – may be a higher-level statement or may be detailed technical comment with tables, illustrations, ‘cut-and-paste from the draft, etc.
• “Proposed solution” - may be a higher-level statement or may be marked up or new text, tables, illustrations, etc.
• “Save and add another” -you may complete multiple comment templates and submit as a single comment
• “Save” - you may submit a single comment and restart the process to submit additional comments.
Notes for optional fields/items:
• “Category” - would be most helpful, please complete!
• “Section” and “Item” very helpful for all comments. However; may not be applicable to high level comments.
• “Supporting File” - may attach a document to the comment
Files can be found here: infocentral.infoway-inforoute.ca/en/resources/docs/imagingdocs/dicom/3083-json-representation-of-dicom-structured-reports-pdf-public-comment-by-dec-23-2019
infocentral.infoway-inforoute.ca/en/resources/docs/imagingdocs/dicom/3082-json-representation-of-dicom-structured-reports-public-comment-by-dec-23-2019
Link to public comments page: standards.nema.org/higherlogic/ws/public/add_comment?document_id=27452
www.dicomstandard.org/comment/
If you still have any questions and need assistance to complete and submit a comment, contact me @Kowalczyk, Luiza.
Luiza Kowalczyk, AStd.
Senior Manager, DICOM Operations
Medical Imaging & Technology Alliance (MITA)
1300 North 17th Street, Suite 900, Arlington, VA 22209, USA
Office: +1. 703.841.3259 | Cell: +1.703.655.99.11
Skype: luizako23
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
www.dicomstandard.org | www.dicomstandard.org/participate/
Subject: Submit Public Comments on Supplement 219 JSON Representation of DICOM Structured Reports.
Scope and Field of Application
This Supplement describes a JSON representation of DICOM Structured Reports, similar to the PS3.18 JSON representation, to allow AI developers 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 developers 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 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 conversion 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 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 developers. 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 a 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.
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 scope of this Supplement is limited to describing the representation and the transformation. 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 a separate, potentially reusable, JSON file, which may be user- or organization-supplied or automatically generated.
DICOM SR traditionally makes very extensive use of coded terminology to maximize semantic interoperability and to avoid reinventing existing content. However, choosing and encoding codes can be burdensome to developers. Similarly, 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, though 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 developer 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).
In the interest of simplicity, the JSON representation chosen is largely positional rather than using named parameters; e.g., the payload of a content item that is a TEXT or CODE value type is an array of strings, which in the degenerate form is a single value, wherein the string is used as a TEXT value or a CODE business name depending on what the concept name is recognized to be, rather than explicitly naming the type of value (i.e., "Kidney" rather than {"@code": "Kidney"}. Similarly, more complex content item value types like NUM or SCOORD or IMAGE, for which there are multiple values with a specific purpose are defined positionally as well, e.g., the position in the array determines whether the business name is for the units, or the UID is for the SOP Class or SOP Instance, or whether the value is the graphic type or an array of coordinates (and for the latter, which are X and Y), etc. This places greater demands on the parser/converter as well as the documentation, but provides simplicity (if not always clarity) for the user. Alternatives such as fully qualifying every parameter with its type and purpose produced an undesirably cluttered representation, especially for the simple use cases.
At this time, no similar standard XML representation is defined, thought the concepts are equally applicable, theoretically. The consensus in the AI/ML community at this time seems to be to focus on JSON. Several toolkits 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.
All comments should be submitted as soon as possible but NO LATER than by midnight, Monday, December 23, 2019.
Who can comment? All interested persons are invited to comment. Recipients of this solicitation should feel free to forward it to anybody who may be interested in this topic but is not listed on DICOM e-mail lists. There is no cost or obligation associated with commenting and no membership in any committee is required to comment but commenters will be requested to include their contact information with their comments.
What will happen to your comments? DICOM Working Group 06 and DICOM Working Group WG-23 will review the comments and discuss their resolution. WG-06 is authorized by the DICOM Standard Committee to decide on the technical merits of the comments.
Instructions for accessing the documents and submitting comments:
1. The DICOM Secretariat (MITA/NEMA) uses the third party software, Higher Logic for the collection and management of the public comments.
2. Download document(s) to local drives:
Click on the links below to download the PDF, Word, and/or XML versions. If the PDF version is different from any other format the PDF governs.
3. Enter and submit comment(s):
When clicking on the “Comment” link below; the comment submission template appears. You may complete multiple comment templates and submit as a single comment (“Save and add another”) or you may submit a single comment (“Save”) and restart the process to submit another comment.
Forms of comments:
• You may enter free text, attach a document containing your comments, or mark-up parts or the whole of the document and attach same.
• If your comments relate to several specific sections, you can combine them in a single comment entry or make separate comment entries.
Mandatory fields:
• Commenter’s name, affiliation, e-mails address.
• “Subject” – Sup 219 PC
• “Comment” – may be a higher-level statement or may be detailed technical comment with tables, illustrations, ‘cut-and-paste from the draft, etc.
• “Proposed solution” - may be a higher-level statement or may be marked up or new text, tables, illustrations, etc.
• “Save and add another” -you may complete multiple comment templates and submit as a single comment
• “Save” - you may submit a single comment and restart the process to submit additional comments.
Notes for optional fields/items:
• “Category” - would be most helpful, please complete!
• “Section” and “Item” very helpful for all comments. However; may not be applicable to high level comments.
• “Supporting File” - may attach a document to the comment
Files can be found here: infocentral.infoway-inforoute.ca/en/resources/docs/imagingdocs/dicom/3083-json-representation-of-dicom-structured-reports-pdf-public-comment-by-dec-23-2019
infocentral.infoway-inforoute.ca/en/resources/docs/imagingdocs/dicom/3082-json-representation-of-dicom-structured-reports-public-comment-by-dec-23-2019
Link to public comments page: standards.nema.org/higherlogic/ws/public/add_comment?document_id=27452
www.dicomstandard.org/comment/
If you still have any questions and need assistance to complete and submit a comment, contact me @Kowalczyk, Luiza.
Luiza Kowalczyk, AStd.
Senior Manager, DICOM Operations
Medical Imaging & Technology Alliance (MITA)
1300 North 17th Street, Suite 900, Arlington, VA 22209, USA
Office: +1. 703.841.3259 | Cell: +1.703.655.99.11
Skype: luizako23
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
www.dicomstandard.org | www.dicomstandard.org/participate/
Please Log in or Create an account to join the conversation.
Twitter