Feature request: Support for DICOM Supplement 247 Eyecare Measurement Templates (TID 6001–6009)

[oftalmos-org]

Summary

DICOM Supplement 247 "Eyecare Measurement Templates" was included in DICOM 2025c (July 2025). It defines structured report templates specifically for ophthalmic measurements that should replace the current practice of encoding these measurements in generic TID 1500 reports.

We are building a multi-vendor OCT → DICOM pipeline (Optopol Revo FC130, Zeiss Cirrus HD-OCT) that currently uses TID 1500 via highdicom. We would like to migrate to the correct ophthalmic templates once highdicom supports them.

TIDs needed

TID	Name	Use case
6001	Ophthalmology Measurements Group	Root container
6004	Circumpapillary RNFL Key Measurements	RNFL circle scan (OCT)
6005	Macular Thickness Key Measurements	ETDRS grid, CMT (OCT)
6006	Ganglion Cell Layer Key Measurements	mGCIPL (OCT)
6002	Visual Field Key Measurements	Static perimetry (HFA, PTS 925)
6003	Optic Disc Key Measurements	C/D ratio, ONH
6007	Corneal Topography Key Measurements	Topography

Reference

• Supplement 247 PDF: https://dicom.nema.org/Dicom/News/January2025/docs/sups/sup247.pdf
• DICOM PS3.16 templates: TID 6001–6009

Question

Is there a planned release or branch for Supplement 247 support? If not, we would be interested in contributing an implementation.

[CPBridge]

Hi @oftalmos-org

My position on SR templates is that there are so many and we do not have the resources to possibly implement all of them unfortunately. We give TID1500 special status because it is a very general-purpose template. The templates you listed are not a priority for us, sorry.

That said, if you or people like you have certain templates that are important to you/them and are willing to put together high-quality implementations, then I would gratefully accept them into the library. If you want to go ahead with this, I am also happy to advise on how to go about it if you have questions. Please make sure to try to follow the style of the existing templates and re-use components where you can. I would also look at the discussion on #355 and #365 where a contributor previously worked on adding a different set of templates. It seems that may be abandoned now unfortunately, but the discussion including the design decisions taken and some of the missteps made there too would be useful for you.

[oftalmos-org]

Thanks for the guidance, @CPBridge — understood on the resource constraints.

I've reviewed #355 and #365 carefully and I'm prepared to contribute a full implementation of Supplement 247. My group is building a multi-vendor OCT → DICOM SR pipeline and we need these templates in production, so we have both the motivation and real-world test cases to validate the implementation.

Planned scope: all TIDs defined in Supplement 247 (root container + visual field, optic disc, RNFL, macular thickness, GCL, endothelial cell count, corneal topography), following the modular package structure and design patterns discussed in #365.

Before opening a draft PR, a couple of questions:

• Is the restructure of templates.py → templates/ package still desired as a prerequisite, or would you prefer the ophthalmic templates added to the existing monolithic file for now?
• Any preference on whether the Supplement 247 Context Groups (CID definitions) should live in a new coding_ophthalmology.py or be folded into the existing coding.py?

Happy to open a draft PR once the basic structure is in place for early feedback.

[CPBridge]

@oftalmos-org sounds great, thanks for being willing to contribute this work to the library so others can use it

Is the restructure of templates.py → templates/ package still desired as a prerequisite, or would you prefer the ophthalmic templates added to the existing monolithic file for now?

Yes I think that still makes sense. Probably it will be easiest to just do this in your PR and if work on #365 we'll have to rebase it.

Any preference on whether the Supplement 247 Context Groups (CID definitions) should live in a new coding_ophthalmology.py or be folded into the existing coding.py?

Not really sure what you mean here. The coding.py file does not define CIDs. The codes are actually part of the pydicom library. We should probably try to contribute these new CIDs there in a parallel PR

Happy to open a draft PR once the basic structure is in place for early feedback.

Sounds good!