innolitics/dicom-standard

The DICOM standard, in JSON format, parsed from the HTML version using Python scripts

dicom-standard's Issues

Parse SOP class UIDs from Part 3.4

I think it would be helpful to parse this table http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_B.5.html, and add SOPClassUID to this output https://github.com/innolitics/dicom-standard/blob/master/standard/ciods.json to allow for unambiguous identification of the CIOD corresponding to a specific instance.

What do you think? I am also wondering how do you perform this mapping right now in the website in absence of those UIDs?

Typo in DICOM Standard causes invalid JSON output

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.8.14.html#sect_C.8.8.14

The error is for DICOM tag (300A,0089)-- the standard does not have a comma separating the two tag values.

Need to

1. Fix this parsing error by making the system more robust to typos like this
2. Add assertions about the output shape of JSON to catch errors like this in future versions of the standard.

Parse the DICOM Attribute Confidentiality Profiles

Parse the DICOM Attribute Confidentiality Profiles from Part 15 and store them in the JSON as appropriate.

AttributeError: Dataset does not have attribute 'ImagePositionPatient'.

Bug description

slices = [dicom.read_file(path + '/' + s,force = True) for s in os.listdir(path)]
slices.sort(key = lambda x: float(x.ImagePositionPatient[2]))
AttributeError: Dataset does not have attribute 'ImagePositionPatient'.

When I define "slices[i]" as a single dicom file rather than trying to combine all of them, I can write slices[i].ImagePositionPatient and it returns something like [x, y,z] so the original files definitely have this attribute. It seems like when I sort them all, it somehow loses the attribute.

Steps for reproduction

Expected behavior

Additional context (e.g. screenshots)

Duplicate Entries in modules_to_attributes.json

There are two entries in modules_to_attributes.json which have the same value for the path key. The duplicated value is: "sr-document-content:0040a730:00700022".

We should investigate this, as it appears to be an error.

We should also check for other duplicates.

The "File-Set Identification" module's information entity is not parsed correctly

Bug description

The "File-Set Identification" module's information entity is not parsed correctly.

Steps for reproduction

Visit:

https://dicom.innolitics.com/ciods/basic-directory/file-set-identification

Expected behavior

The module's information entity would be present, instead of the string "null."

Additional context (e.g. screenshots)

Enable filtering by data element type

Is your feature request related to a problem? Please describe.

As a content developer I would like to be able to find out quickly and easily what are the mandatory parts of a content and which ones are optional. At the moment the viewer shows all tags plus their data element type so you have to filter this list manually somehow to determine the minimum set of elements for a valid content.

Proposed feature

Provide a filter option where you can choose the data element type via check boxes, the graph would highlight the elements of the selected data type. So you could, for example, select “1” and “1C” to make all required and conditionally required elements more prominently visible.

Ideally you could expand all nodes within a content to see quickly what are required tags and what are the optional ones.

My initial idea was to show / hide the selected elements but there can be required tags within optional tags so deciding on what to show when may be tricky. For example, the alternate content description sequence (0070,0087) is a type 3 element within surface segmentation. It contains a type 1 element in the form of the language code sequence (0008,0006). If the graph does not show type 3 elements you would not see the sequence. So when you start adding it to your content and want to cross-check what’s the required data within the sequence you would be out of luck as the sub-tree would be hidden.

Potential alternatives

Show / hide the elements according to the filter criteria. Keep nodes containing selected elements visible but maybe less prominent if they are not selected by themselves.

Make it possible to copy & paste the tree into excel to filter there.

Description should say "non-human" rather than "animal"

Bug description

The description for the "Patient Species Description Attribute" says "Required if the Patient is an animal..." but I think it meant to say "Required if the Patient is non-human..." since humans are animals. Similar issue for the description for the "Patient Species Code Sequence Attribute".

website network error

Bug description
I can't use search when I visit https://dicom.innolitics.com/ciods/cr-image/general-image/00880200/00280106#, so I open console and find some error.

00280106:46 GET https://d1z6rmlpn5ezsx.cloudfront.net/runtime.f680b64047043eed1ea7.js net::ERR_NAME_NOT_RESOLVED
00280106:47 GET https://d1z6rmlpn5ezsx.cloudfront.net/vendors~main.21a3fb6dec78740dc92d.js net::ERR_NAME_NOT_RESOLVED
00280106:48 GET https://d1z6rmlpn5ezsx.cloudfront.net/dicom~main.8b3443b17b1fc6ebf066.js net::ERR_NAME_NOT_RESOLVED
00280106:49 GET https://d1z6rmlpn5ezsx.cloudfront.net/main.fccea959f15eeee3edba.js net::ERR_NAME_NOT_RESOLVED

please fix it when you see it.

Steps for reproduction
open url in browser

Expected behavior

Additional context (e.g. screenshots)

File Editor (beta) labels Referenced Frame of Reference Sequence incorrectly

Bug description
When RT Structure Set file is loaded into File Editor (beta) the 3006,0010 Referenced Frame of Reference Sequence is labeled as RT ROI Observations Sequence 3006,0080 and then shows items below that sequence which do not belong to the 3006,0080 sequence, but do belong to the 3006,0010 sequence. See screen shot below.

Steps for reproduction

Expected behavior

Additional context (e.g. screenshots)

Parse Enumerated Values and Defined Terms

Is your feature request related to a problem? Please describe.

N/A

Proposed feature

It would be nice if we could parse and make available enumerated values and defined terms. See:

http://dicom.nema.org/medical/dicom/current/output/html/part05.html#sect_6.3

These could be useful for DICOM validators or libraries. E.g., the DICOM Standard Browser's Analyze feature could warn users if the have an invalid value for a field that takes enumerated values.

Some thought would need to be put into the proper data format for this.

Potential alternatives

N/A

Additional context (e.g. screenshots)

N/A

Fix CI build process

The CI build process is failing. This appears to be caused by Travis xenial now shipping with 3.6 preinstalled whereas it previously included 3.7 and 3.8. Our script attempts to use 3.7.

This thread may be useful.

If other issues are exposed once the build step is working, we should fix them as well. The desired end state is having a functional CI workflow again.

Print Management Specific Modules

Bug description

Seems like there is an inconstency for Printer Modules. I cannot find:

• http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.13.9.html

For instance:

Date Of Last Calibration (0018,1200) Date when the printer was last calibrated.

Steps for reproduction

Expected behavior

Additional context (e.g. screenshots)

ciods.json "Table" in id CT Performed Procedure Protocol

ciods.json (line 770):
id "Table CT Performed Procedure Protocol" instead of
id "CT Performed Procedure Protocol"
I guess this is a bug of the Nema Website since its displaying the Table name twice in the Header.
http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.82.html#table_A.82.1.3-1

The actual UID: 1.2.840.10008.5.1.4.1.1.200.1 doesn't contain the Name Table.

Fix Parser Bug

See discussion here:

https://groups.google.com/forum/?hl=en#!topic/comp.protocols.dicom/F3RKlfBVkJ4

Migrating from the client side repository.

Typo at Dnand

Bug description
There is a typo here: https://dicom.innolitics.com/ciods/rt-dose/rt-dvh/30040050/30040058
A space is missing.
The description text says "...dose bin widths Dnand associated..." where it should say "...dose bin widths Dn and associated..."

Steps for reproduction
Browse here: https://dicom.innolitics.com/ciods/rt-dose/rt-dvh/30040050/30040058

Expected behavior
Should say "...dose bin widths Dn and associated..."

Additional context (e.g. screenshots)

DICOM Standard consistency checks

We should begin adding tests to check that the standard is consistent with itself.

To start, we can add a check to make sure that the retired attributes in part 15 are consistent with part 5.

Fix update-standard workflow

The update-standard workflow has not run successfully for ~5 months. See https://github.com/innolitics/dicom-standard/actions?query=workflow%3Aupdate-standard and https://github.com/innolitics/dicom-standard/blob/master/.github/workflows/update-standard.yml.

Missing Tag from module_to_attributes.json in attributes.json

Found an Error while checking the attributes.json against the module_to_attributes.json.
"tag":"(0006,0001)" (dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.27.html#table_C.7.6.27-1) from module_to_attributes is missing in the attributes.json.

Improve Documentation

• Add an "Installation" section; we can install using pip install dicom-standard. Also include the curl or wget commands needed to pull down either the latest version of the JSON or a particular pinned version.
• Add a section which describes our philosophy for the format of the JSON files; in particular, that it is likely that the JSON will need to get massaged for other use-cases. Mention that this was originally for our DICOM standard browser (and link to it). Then discuss how our philosophy has changed to be more general. See #24 (comment) for a good starting place!
• Take a pass through the existing sections and clean them up; prune them out as much as possible
• Discuss how we handle issues with the DICOM standard
• Discuss how often/when we update the JSON files
• Explain how we handle functional group macros, and why they are a weird exception. Maybe we could include it in a list of the processing steps we handle on behalf of users of the library, along with expanding macros and the various DICOM standard inconsistencies we correct for.

Sorting and Transfer Syntaxes

Is your feature request related to a problem? Please describe.
No, just feature

Proposed feature

1. I think a more structured sorting of the CIODs would be great. Either logically grouped and then alphabetically, or simply alphabetically Currently I can't find a rhyme or reason as to why CIODs appear in which position :-) It seems that at times it sorts it by "occurrence in the field" (like in the beginning we have CR,CT,MR,NM... and then much later we have Spatial Registration) but then it seems to loose that alignment further down.. Maybe I just don't understand.. and if there is a logic, would you care to share? :)
2. I think it's be awesome to have an expanded tree/overview/lists or some form of organized display of Transfer Syntaxes and SOP Class UIDs.

Additional context (e.g. screenshots)

Functional Group Macros are not available

Bug description

The documentation states PS3.3 has been completely processed, this is inaccurate, since to the best of my knowledge, functional group macros are not available anywhere in the 'standard' folder (as json).

Steps for reproduction

% git grep "Enhanced MR Image Functional Group Macros" -- standard

Expected behavior

Should return at least one JSON file.

409

Bug description

Steps for reproduction

Expected behavior

Additional context (e.g. screenshots)

IOD-specific Functional Groups tables are not parsed

This discussion is the followup on this and following comments #15 (comment), which are not related to #15.

Enhanced MR module table includes "Multi-frame Functional Groups", but (if I understand correctly), the IOD-specific content of this module is alluded to in the row 3 of that definition, which in turn is defined in "Enhanced MR Image Functional Group Macros", which includes "Frame Content", which includes StackID and InStackPositionNumber. So I don't think there is a way to parse this out automatically.

As a consequence of the above, Innolitics DICOM browser "analyzer" does not populate any of the Per-frame or Shared FGs for the multiframe input files:

@johndgiese we discussed it today with @dclunie at our weekly IDC call.

For the enhanced family of objects, table immediately following the modules table defining IOD will contain the functional groups included in that IOD. Essentially, those IOD-specific macros establish another level of attributes organization, separate from modules.

Maybe it makes sense to define "virtual" modules for functional groups from enhanced IODs, e.g., "enhanced-mr-fg", and dump all attributes from the enhanced object specific FG table?

Segmentation CIOD is broken

Bug description
Segmentation CIOD -> Multi-frame Functional Groups ->Shared Functional Groups
lists wrong functional groups:
Segment Identification Sequence, Plane Position (Slide) Sequence are both not in the standard: http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.16.2.html

Also please double check if all of them are actually type 1 or 1C since some of the types are listed as 1, but the description states conditionally required.

In general it would also be helpful to state what is supposed to be written in those single item sequences since all of the information is actually rather provided on a per frame level. Therefore, it is very confusing to share information from one specific frame across all frames, but that is rather a problem in the dicom standard itself.

Expected behavior
remove both

Website crashes during search - "rt related"

I cannot reopen the earlier closed issue, so I am creating a new one.

#29 is not resolved, the crash is happening with the current version of the website and the same search string.

Information Entity empty in ciod_to_modules.json

Information Entity (ciod: real-time-video-photographic-image) Empty in Line 5789 and 5796.
Should be Image.

Webapp crashes during search

I wanted to find "RT Related ROI Sequence (3006,0030)" that someone mentioned, and I discovered that after I type "rt related" in Search, the app crashes.

Add "id" property to JSON files to act as a foreign key

To better organize the data stored in the JSON files as a relational database, we should add an id property to each value.

This will make it easier to access related values that are located in separate JSON files and help avoid putting excessive amounts of data into a single file.

Get all tests to pass

Some tests are failing at the moment.

File-set Identification Module has no description

Bug description
The File-Set Identification Module has no description (See Section F.3). This results in the parser improperly saving the table name as the description:

dicom-standard/standard/modules.json

Lines 2240 to 2245 in ff9a32e

	{
	"name":"File-Set Identification",
	"id":"file-set-identification",
	"description":"<p>\n<strong>Table\u00a0F.3-2.\u00a0File-Set Identification Module Attributes</strong>\n</p>",
	"linkToStandard":"http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_F.3.2.html#table_F.3-2"
	},

Expected behavior
A description value of None or null.

Additional context (e.g. screenshots)

Extractor does not work with the 2019c version of the standard

I am getting the following error:

$ make
cat standard/part03.html | sed -e 's/&nbps;/ /g' -e 's/​//g' > tmp/part03.html
PYTHONPATH=.. python3 extract_ciod_module_data.py tmp/part03.html > tmp/raw_ciod_module_tables.json
PYTHONPATH=.. python3 process_ciods.py tmp/raw_ciod_module_tables.json > dist/ciods.json
PYTHONPATH=.. python3 extract_modules_with_attributes.py tmp/part03.html > tmp/raw_module_attribute_tables.json
PYTHONPATH=.. python3 extract_macros.py tmp/part03.html > tmp/raw_macro_tables.json
PYTHONPATH=.. python3 preprocess_modules_with_attributes.py tmp/raw_module_attribute_tables.json tmp/raw_macro_tables.json > tmp/preprocessed_modules_attributes.json
Traceback (most recent call last):
  File "preprocess_modules_with_attributes.py", line 55, in 
    tables_with_macros = expand_all_macros(module_attr_tables, macro_tables)
  File "preprocess_modules_with_attributes.py", line 18, in expand_all_macros
    for table in module_attr_tables]
  File "preprocess_modules_with_attributes.py", line 18, in 
    for table in module_attr_tables]
  File "/Users/fedorov/github/dicom-standard/dicom_standard/macro_utils.py", line 22, in expand_macro_rows
    for attr in table['attributes']]
  File "/Users/fedorov/github/dicom-standard/dicom_standard/macro_utils.py", line 22, in 
    for attr in table['attributes']]
  File "/Users/fedorov/github/dicom-standard/dicom_standard/macro_utils.py", line 30, in get_attributes_to_insert
    new_attributes = get_macro_attributes(attribute, macros, table_id)
  File "/Users/fedorov/github/dicom-standard/dicom_standard/macro_utils.py", line 53, in get_macro_attributes
    return expand_macro_rows(get_macros_by_id(macro_id, macros, hierarchy_marker), macros)
  File "/Users/fedorov/github/dicom-standard/dicom_standard/macro_utils.py", line 72, in get_macros_by_id
    macro['attributes'] = update_attribute_hierarchy_markers(macro['attributes'], hierarchy_marker)
  File "/Users/fedorov/github/dicom-standard/dicom_standard/macro_utils.py", line 77, in update_attribute_hierarchy_markers
    return [add_marker_to_attr(attribute, marker) for attribute in attributes]
  File "/Users/fedorov/github/dicom-standard/dicom_standard/macro_utils.py", line 77, in 
    return [add_marker_to_attr(attribute, marker) for attribute in attributes]
  File "/Users/fedorov/github/dicom-standard/dicom_standard/macro_utils.py", line 81, in add_marker_to_attr
    parsed_attribute_name = BeautifulSoup(attribute['name'], 'html.parser').find('td')
KeyError: 'name'
make: *** [tmp/preprocessed_modules_attributes.json] Error 1

please check

Bug description

Steps for reproduction

Expected behavior

Additional context (e.g. screenshots)

deep link to tag, search by URL

Is your feature request related to a problem? Please describe.

We want to help people understand documents that include descriptions of dicom headers by linking out to information about a tag.

Proposed feature

It would be great if we could deep link to a tag search in your browser.

Currently I can deeplink to a tag if I know the IOD it belongs to:

https://dicom.innolitics.com/ciods/ct-image/general-study/00080020

I'd like to be able to include a deep line like:

https://dicom.innolitics.com/search/00080020

that would be the the same as typing 00080020 into the search tab.

But from what I can see the search interface is currently using an HTTP POST, and there's no way to embed the search term in the URL.

Potential alternatives

The search term could be in url parameters instead of being part of the URL itself.

Additional context (e.g. screenshots)

Issues with the DICOM standard site

@fedorov There have been a few issues identified that seem to be caused by bugs or inconsistencies on the site. I've compiled a detailed list below:

1. Table A.82.1.3-1 is mis-titled "Table CT Performed Procedure Protocol" when it should be "CT Performed Procedure Protocol" (Issue #18)
   

2. Table A.32.10-1 has blank IE columns for "Real-Time Acquisition" and "Current Frame Functional Group" modules when the value should be "Image" (Issue #17)
   

3. Tables A.85.2.1-1, A.85.2.2-1, and A.85.2.3-1 are all missing an IE column for the "Common Instance Reference" module (related to Issue #17)
   

4. All subsections of Section C.7.6.16.2 are contained within the same HTML page (unsure if this is a bug)

   • To be consistent with the rest of the site, Section 7.6.16.2.11.1.2 should be accessible through sect_C.7.6.16.2.11.html but that doesn't exist
   • As an example of another section, A.35.1.3.1.2 can be accessed through sect_A.35.html

I've hard-coded some fixes that allow the parsers to extract the correct data from these tables/sections, but they should be removed when these issues are addressed (or a more robust fix implemented if 4 is the intendended structure)

Basic SR Content Sequence Attribute fails to reference the Document Relationship Macro Attributes

Bug description

Basic SR Content Sequence Attribute fails to reference the Document Relationship Macro Attributes.
The Document Relationship Macro contains the (recursive) Content Sequence Attribute, which is kind of the basis of SR.
This may not be readily modeled in the tree (because it implies infinite recursion if one isn't careful about it), but I spent a lot of time scratching my head on this until I went directly to the DICOM Standard. I guess I'd prefer to see one Content Sequence attribute shown within the top level Content Sequence attribute with no further sequence items inside it with some wording that indicates "recursion here, it's turtles all the way down to the leaf attributes".

Steps for reproduction

Expected behavior

Additional context (e.g. screenshots)
See http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.17.3.html#sect_C.17.3
and compare to "there's no Content Sequence attribute within the Content Sequence attribute".

`browser` Styling issue when de-selecting fields

Bug description
When de-selecting the fields in the Dicom web browser the styling change to a orange colour with a white background. When selecting another field without hovering over the previous one, the background colour changes but the text remains white in the previous field which makes it unreadable

Steps for reproduction
1 - Select a dicom tag
2 - Select a dicom tag above the previous one
3 - Defect - Dicom tag's font from step 1 is now white and unreadable against the background

Expected behavior
On step 3, the Dicom tag styling should revert back to the original style

Additional context (e.g. screenshots)
Using Google Chrome Version 99.0.4844.82 (Official Build) (64-bit)

Update to Python 3.8 and improve type hints

Python 3.8 supports TypedDict, defined in PEP 589. We should use this to improve the type hints for the dictionaries used to represent objects in the various JSON files.

Example:

class CiodModuleDict(TypedDict):
    ciodId: str
    moduleId: str
    usage: str
    conditionalStatement: Optional[str]
    informationEntity: str

A few CIOD descriptions are "None"

Bug description

A few of the CIOD descriptions just contain the word "None"

Steps for reproduction

visit, e.g., https://dicom.innolitics.com/ciods/rt-physician-intent

Expected behavior

The associated descriptions should be included (it seems that there is a description, in at least a couple of the CIODs that currently say "None"---perhaps they are in a different location than normal?)

Incorporate Notes into Tag Descriptions

Is your feature request related to a problem? Please describe.

No.

Proposed feature

Some DICOM tag descriptions are incomplete since notes are not included in the details tab. Compare this apge

https://dicom.innolitics.com/ciods/encapsulated-pdf/sc-equipment/00080064

to this one

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#table_C.8-24

and in particular notice that "Note 1" does not appear in the DICOM Standard Browser page.

If the note were referenced in the table, I believe it would be pulled in. Thus, it seems like we need an additional "linking" mechanism to connect the table to the appropriate tag descriptions.

Potential alternatives

n/a

Additional context (e.g. screenshots)

n/a

Add system to automatically pull down and process new versions of the standard

We want to set up a system which will periodically check for changes to the DICOM standard.

If there are changes to the HTML:

1. Run the new HTML through our parser
2. Make sure all of the tests are passing
3. If all the tests pass AND the JSON output is also different, then commit the new JSON files, release a new version to pypi and tag the current commit as appropriate

I am not sure how to accomplish this. Perhaps GitHub actions?

https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#onschedule

Review end-to-end tests

We should review our existing end-to-end tests, and add as many new ones as we can think of. E.g., we probably need some new ones for the new JSON file.

Incorrect DICOM "View In Standard" Link

As reported in this thread:

https://groups.google.com/forum/#!topic/comp.protocols.dicom/YrMeGX-_9H8

Go to:

https://dicom.innolitics.com/ciods/enhanced-mr-image/enhanced-mr-image/00189073

Select "View in standard" (right side), incorrect link is:

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.16.2.2.html#sect_C.7.6.16.2.2.1

should be instead:

http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.16.2.html#sect_C.7.6.16.2.2.1

Browser lists Type 1 attributes for SR Document Content module where these may not be required

Bug description

The SR Document Content modules includes the Document Content Macro Attributes, which includes 9 macros but only one of these macro is required to be included depending on the Value Type (VT) value.
The Innolitics browser (which I love BTW) is listing attributes from all these macros so some Type 1 attributes listed by the browser are not Type 1.

Steps for reproduction

Compare with http://dicom.nema.org/dicom/2013/output/chtml/part03/sect_C.17.html#sect_C.17.3

Expected behavior

Not easy to solve as Innolitics browser does expand all macros (which is a very useful feature). The solution will have to be discussed. Either propose a selective macro expansion with user selection or adding some information in the right pane with the dependence to the VT.

Additional context (e.g. screenshots)
Not required

Description of 'C.7.6.2.1.1 Image Position and Image Orientation' is incomplete

Bug description
Right hand side description 'C.7.6.2.1.1 Image Position and Image Orientation' ends before text end is reached compared to the standard document.

Steps for reproduction
https://dicom.innolitics.com/ciods/rt-dose/image-plane/00200032 and scroll down to the end of desciption

Expected behavior
show full text of 'C.7.6.2.1.1 Image Position and Image Orientation' as shown here: http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.2.html#table_C.7-10

Additional context (e.g. screenshots)

Errors in attributes.json

(0018,9445) and (0028,0020) should be marked as retired, but they are not.

browser failure of secondary capture

Hi

I want to make a secondary capture as a dicom file ; but to know the required missing dicom fields I'd like to use the dicom.innolitics.com interface as the generate dicom secondary capture made do work on some PACS clients but not every one of them...

Bug description
When dragged a secondary capture in the dicom standard browser, an error occur

Steps for reproduction
download ; unzip ; drag and drop the anonymized dicom file and then upload it on the web interface

Expected behavior
to see the required missing dicom fields

test_sc.dcm.zip

Thanks,
Best

'Unable to parse error' on SR document, even though it opens in other DICOM viewers

@browser

Bug description
The file browser did not recognize the Structured Report (SR) file as valid.
However, the same file opened in MicroDicom viewer (attached screenshot and the dcm file itself)

Steps for reproduction

1. Created a minimal SR using fo-toolkit. (in code)
2. Saved to a dicom file (in code)
3. Tried to open in browser using File Editor (beta)

Here's the code (C#) I used to build the file.

            var dataset = new DicomDataset
            {
                // type 1 attributes
                { DicomTag.SOPClassUID, DicomUID.BasicTextSRStorage},
                { DicomTag.SOPInstanceUID,  DicomUID.Generate()},
                { DicomTag.StudyInstanceUID, DicomUID.Generate()},
                { DicomTag.SeriesInstanceUID, DicomUID.Generate()},
                { DicomTag.Modality, "SR" },
            };

            try
            {
                // Create the root content item which is the title
                DicomCodeItem titleCode = new DicomCodeItem("121144", "DCM", "Document Title");
                //DicomContentItem titleValue = new DicomContentItem(titleCode, DicomRelationship.Contains, DicomValueType.Text, "A Very Simple Structured Report");

                //titleCode.Add(DicomTag.SequenceDelimitationItem, string.Empty);
                // Prepare the one content item 
                DicomCodeItem textCode = new DicomCodeItem("111412", "DCM", "Narrative Summary");
                DicomContentItem textItem = new DicomContentItem(textCode, DicomRelationship.Contains, DicomValueType.Text, "Hello World!!");

                // Now we can create a special content item called a 'structured report'
                DicomStructuredReport report = new DicomStructuredReport(titleCode, textItem);

                // We need to add the dataset with all the patient, study, series stuff to the report (not the other way around)
                report.Dataset.Add(dataset);

                // Save the dataset to a file
                DicomFile file = new DicomFile();
                file.Dataset.Add(report.Dataset);
                file.FileMetaInfo.TransferSyntax = DicomTransferSyntax.ImplicitVRLittleEndian; //Specify transfer syntax

                DicomIOWriter.DicomWriteOptions options = new DicomIOWriter.DicomWriteOptions();
                options.ExplicitLengthSequenceItems = true;
                options.ExplicitLengthSequences = true;
                file.Save(dicom_file, options);
            }
            catch (DicomStructuredReportException exception)
            {
                System.Diagnostics.Trace.WriteLine("");
                System.Diagnostics.Trace.WriteLine("----------------------------------------------------");
                System.Diagnostics.Trace.WriteLine("Error creating structured report ...");
                System.Diagnostics.Trace.WriteLine(exception.ToString());
                System.Diagnostics.Trace.WriteLine("----------------------------------------------------");
                System.Diagnostics.Trace.WriteLine("");
            }

Expected behavior

Browser should accept the file and show its tags in orange. Even if some tags are missing, should show missing tags in red.

Additional context (e.g. screenshots)

sr_basic.zip

---

p.s. I am a fan of this browser!! Keep up the great work!

Inconsistent letter case in information entity names

Bug description
ciod_to_modules.json contains one entry where the letter 'o' in the informationEntity "Frame of Reference" is capitalized, while all the others have it lower-cased. It looks like these are supposed to be the same, and this inconsistency makes it more difficult to use information entity names for lookups.

Steps for reproduction

jq -r '.[] | .informationEntity' ciod_to_modules.json | sort | uniq -c | grep Frame

    116 Frame of Reference
      1 Frame Of Reference

jq 'map(select(.informationEntity == "Frame Of Reference"))' ciod_to_modules.json

[
  {
    "ciodId": "rendition-selection-document",
    "moduleId": "synchronization",
    "usage": "M",
    "conditionalStatement": null,
    "informationEntity": "Frame Of Reference"
  }
]

Expected behavior
The first command should output 117 Frame of Reference, i.e. all the "Frame of Reference" information entities should have the same letter casing.

Document the path key

Both module_to_attributes.json and macro_to_attributes.json contain multiple entries for the same attribute in the same macro/module. These entries share everything except the path value. See for example this one module–attribute combination:

jq 'map(select(.moduleId == "acquisition-context" and .tag == "(0008,0100)"))' module_to_attributes.json | sort | uniq -u

  }
[
]
    "path": "acquisition-context:00400555:004008ea:00080100",
    "path": "acquisition-context:00400555:004008ea:00080121:00080100",
    "path": "acquisition-context:00400555:0040a043:00080100",
    "path": "acquisition-context:00400555:0040a043:00080121:00080100",
    "path": "acquisition-context:00400555:0040a168:00080100",
    "path": "acquisition-context:00400555:0040a168:00080121:00080100",

(The delimiters on the first three lines also happen to not be repeated in the JSON.)

It seems counter-intuitive that the same attribute appears multiple times in the same module/macro, as the browser itself also appears to display a single occurrence for a single attribute–module/macro pair. The path appears to be some kind of indicator of the inclusion hierarchy in the standard, but it's hard to see how it's derived from the same source URL all the path variants share. Could this path key be documented somewhere so it's more apparent what it's intended for?