Background The commenter is referencing the Diagnostic Imaging Data Class in USCDI source: https://www.healthit.gov/isa/sites/isa/files/2023-10/USCDI-Version-4-October-2023-Errata-Final.pdf   Which states that the Data Element, Diagnostic Imaging Report is "the interpreted results of imaging tests" Rationale 1) Regarding the comment:   USCDI states that a Diagnostic Imaging Report is the result of a Diagnostic Imaging Test. US core does not support determining what report is the result of a test. We disagree, In US Core, the Diagnostic Imaging Test are referenced in the Diagnostic Imaging Report by the Must Support elements: {{DiagnosticReport.result: }}" Observations that are part of this diagnostic report.") and {{DiagnosticReport.media: }}"A list of key images associated with this report. The images are generally created during the diagnostic process, and may be directly of the patient, or of treated specimens (i.e. slides of interest)." and the optional element: {{DiagnosticReport.imagingStudy: }}"One or more links to full details of any imaging performed during the diagnostic investigation. Typically, this is imaging performed by DICOM enabled modalities, but this is not required. A fully enabled PACS viewer can use this information to provide views of the source images." and we provide the additional Profile Specific Implementation Guidance: Diagnostic imaging results in visual images requiring interpretation and clinical test results/reports may also reference images as part of the report. There is no single approach for accessing imaging studies alongside clinical data using a single authorization flow to give patients and providers access the images. The  media.link  element is marked as Must Support and the  Media  resource to which it links can support a variety of patient-friendly content such as jpg images of xrays (see the DiagnosticReport Chest Xray Report Example). DICOM studies, series, and SOP instances are encoded as UUID identifiers in the  ImagingStudy  resource which is referenced by the  imagingStudy  element. This optional element can be used by systems with the tools and specific viewers to view these images. Alternatively, systems can use business identifiers such as accession numbers in the  identifer  element to access the source images from external sources. 2) Regarding the comment: In FHIR this is typically done using DiagnosticReport.basedOn, a field that is not supported by UScore. I suggest that US core requires support for DiagnosticReport.basedOn pointing to the corresponding ServiceRequest. We disagree, assuming "this" is referring to point 1) above ( "determining what report is the result of a test."), then DiagnosticReport.basedOn does not reference Diagnostic imaging tests, it references the Order for the Diagnostic Imaging tests. Although we recognize the value of DiagnosticReport.basedOn element, it is not a minimum expectation for the US DiagnosticReport resources. However, other profiles and implementers can introduce it and describe the best practices for their use cases.  Other DiagnosticReport Profiles constraining DiagnosticReport.basedOn.  US Realm International Realm 1/24 3/17 When there is sufficient adoption by the implementation community, we can reconsider adding it to the US Core Profiles.