open-ortho / dicom4ortho Goto Github PK

Currently, only supports family name and given name (first and last). However, DICOM PN also support suffixe, middle and prefix. To be able to add Dr., for example, that level of implementation would be needed.

Currently, i have written my own helper function. However, i could use the pydicom.valuerep.PersonName as documented in https://pydicom.github.io/pydicom/stable/reference/generated/pydicom.valuerep.PersonName.html . Limitation is that out of the box it doesn't support adding name attributes after having set one. So setting first name then setting last name would result in a last name only.

This is how a simple implementation could look like:

from pydicom.valuerep import PersonName

...

    @ property
    def patient_firstname(self):
        return PersonName(self._ds.PatientName).given_name
        
    @ patient_firstname.setter
    def patient_firstname(self, firstname):
        self._ds.PatientName = PersonName.from_named_components(
            given_name=firstname
        )

Question is: how important is this?

model.DicomBase.acquisition_datetime does not take into account a passed datetime which already has tzinfo.

The dicom4ortho should also have an easy way to upload to a PACS, preferably using WADO. Although backward compatibility with traditional C-MOVE might be requested/required.

We need a way to save a set of Photos as part of the same series. It is therefore required to do something like this:

from m_orthodontic_photograph import OrthodonticSeries
from m_orthodontic_photograph import OrthodonticPhotograph

series = OrthodonticSeries()
# generates a new OrthodonticSeries object with its UUID

photo = OrthodonticPhotograph()
photo.set...
# set various parameters for photo


series.add(photo)

series.save(location="output/directory/")

Currently hard coded in OrthodonticPhotograph, QualityControlImage should be a user setting, as defined in ADA-1107, which can be used anytime the staff, for example, takes silly pictures just to test that the system is working properly. Which actually is a relatively frequent use case.

Here is the official Informative DICOM mapping to follow:

https://dicom.nema.org/medical/dicom/current/output/chtml/part17/chapter_NNNN.html

Tooth Codes needs to be filled out in m_tooth_codes. Currently they are empty.

After reviewing the tooth codes briefly with Mark Jurkovich, we have found that some of them are incorrect. They will have to be corrected in WP1100 first, then implemented here again here.

One of the CLI arguments is --image-type. However, a new user would not know the allowed values for this field.

The ADA-1107 repo a CSV file called views.csv which contains the DICOM tags to use for clinically relevant information. dicom4ortho should use that file to perform the mapping. This would also allow dicom4ortho to support various different versions of ADA-1107.

Currently, dicom3tools are used to test/verify the conformance of the produced image. There is a mention in README.md to use defaults.py. Could be better to use a .env schema? Or a local config scheme? Maybe default the location of the tools under modules/. The Makefile could automatically download the tool. I think the URL is pretty standard. For example:

https://www.dclunie.com/dicom3tools/workinprogress/winexe/dicom3tools_winexe_1.00.snapshot.20220618093127.zip

Burned In Annotation is probably a rare use case, but there could be some equipment which prints the date or something else on the image itself.

Currently, when passing a 850kB JPG image, the image is transformed into about 8.5MB, as it is stored in raw DICOM format. This is incorrect, because the DICOM tags incorrectly report the image has not lost information, while it has. Besides, there is no extra information being saved by decompressing a lossy compressed JPG image. The ideal flow would be to:

• capture image in RAW format
• pass it to dicom4ortho
• have dicom4ortho compress is using some lossless compression algorithm like JPEG2000
• save image in DICOM (as encapsulated)

Or encapsulate the passed JPEG as such, correctly stating its lossy compression.

m_orthodontic_photograph_types has many methods which still don't do anything. These need to be implemented.

m_orthodontic_photograph.ALLOWED_TEETH array should be completed for IV image types.

No teeth is being set for EV, because EVs are not intended to show teeth.

Instead of having dicom4ortho load the CSV files necessary to generate the correct DICOM from ADA-1107 at runtime, it would be better to just include them as a resource into the Python package. This issue is present in the develop branch and needs to be fixed there.