PS-2020a / part17

OOOO Encoding Perfusion Parameters for​ Parametric Maps and ROI Measurements​ (Informative)​

ThisAnnexcontainsexamplesofhowtoencodeperfusionmodelsandacquisitionparameterswithintheQuantityDefinitionSequence​ of Parametric Maps and in ROIs in Measurement Report SR Documents.​

Some measurements described as "relative" or "normalized" are calculated by dividing the measurement in a region of interest by a​ corresponding measurement from a reference region chosen for comparison purposes.​

The approach suggested is to describe that a perfusion value is being measured by using absolute or relative regional blood flow or​ volume (generic) as the concept name of the numeric measurement, and to add post-coordinated concept modifiers to describe:​

•​the general anatomic location and type of finding that mirror common usage of terminology specific to the application​

•​the size of any reference region used​

•​a coded description of the location of any reference region in terms of:​

•​anatomic site (drawn from CID 7192 "Anatomical Structure Segmentation Property Types")​

•​laterality (drawn from CID 244 “Laterality” or CID 246 “Relative Laterality” )​

Also illustrated is how the (121050, DCM, "Equivalent Meaning of Concept Name") can be used to communicate a single human​ readable textual description for the entire concept.​

The example used is from the oncology domain, but similar patterns can be used for other applications, e.g., for stroke.​

OOOO.1 Encoding Relative Cerebral Tumor Blood Flow for Parametric Maps​

This example shows how to use the Table C.7.6.16-12b “Real World Value Mapping Item Macro Attributes” in PS3.3 to describe pixel​ values of blood flow maps. It elaborates on the simple example provided in Section C.7.6.16.2.11.1.2 “Real World Values Mapping​ SequenceAttributes”byaddingcodedconceptsthatdescribethelocationofthemeasurementandthelocationandsizeofthereference​ region.​

•​Real World Value Mapping Sequence (0040,9096)​

•​...​

•​Real World Value Intercept (0040,9224) = "0"​

•​Real World Value Slope (0040,9225) = "1E-03"​

•​LUT Explanation (0028,3003) = "Relative Cerebral Tumor Blood Flow, relative to 150mm2 contralateral normal cerebellar gray​ matter"​

•​LUT Label (0040,9210) = "rCBF"​

•​Measurement Units Code Sequence (0040,08EA) = ({ratio}, UCUM, "ratio")​

•​Quantity Definition Sequence (0040,9220):​

•​CODE (246205007, SCT, "Quantity") = (126397, DCM, "Relative Regional Blood Flow)​

•​CODE (363698007, SCT, "Finding Site") = (12738006, SCT, "Brain")​

•​CODE (121071, DCM, "Finding") = (108369006, SCT, "Neoplasm")​

- Standard -​

•​CODE (C94970, NCIt, "Reference Region") = (25991003, SCT, "Cerebellar Cortex")​

•​CODE (272741003, SCT, "Laterality") = (255209002, SCT, "Contralateral")​

•​NUMERIC (42798000, SCT, "Area") = 150 (mm2, UCUM, "mm2")​

•​TEXT (121050, DCM, "Equivalent Meaning of Concept Name") = "Relative cerebral tumor blood flow relative to 150mm2​ contralateral normal cerebellar gray matter"​

In this usage, the text of the (121050, DCM, "Equivalent Meaning of Concept Name") is redundant with the value of LUT Explanation​ (0028,3003); either or both could be omitted.​

The qualifiers of the quantity in this example, specifically the finding and finding site, are intentionally more generic (i.e., brain and​ neoplasm, respectively) than the more specific locations used in the SR examples that follow (i.e., left temporal lobe and primary​ neoplasm), since the purpose is to specify the type of the quantity, not encode an entire report in the quantity definition.​

Thenestingoftheindentedmodifiersintheexampleillustratesthatlateralityandareaaremodifiersofthereferenceregion(i.e.,encoded​ in the Content Item Modifier Sequence (0040,0441) of the Quantity Definition Sequence (0040,9220)).​

OOOO.2 Encoding Relative Cerebral Tumor Blood Volume for ROIs in Measure-​ ment Report SR Documents​

This example shows how to describe the total relative cerebral blood volume value of a region of interest that is a tumor in the left​ temporal lobe. In this case the template used is TID 1419 ROI Measurements within TID 1411 “Volumetric ROI Measurements” to​ separately encode the ROI with the total relative CBV and the ROI for the reference region with its size, with the relationship between​ them implicit in the presence of a coded reference region.​

For clarity, the enclosure of the content items within a Measurement Group container and the accompanying tracking identifiers and​ spatial information (coordinates and image and/or segmentation references) are not shown here.​

•​CODE (121071, DCM, "Finding") = (86049000, SCT, "Neoplasm, Primary")​

•​NUM (126398, DCM, "Relative Regional Blood Volume) = 1.2 ({ratio}, UCUM, "ratio")​

•​HAS CONCEPT MOD CODE (363698007, SCT, "Finding Site") = (78277001, SCT, "Temporal lobe")​

•​HAS CONCEPT MOD CODE (272741003, SCT, "Laterality") = (7771000, SCT, "Left")​

•​HAS CONCEPT MOD CODE (121401, DCM, "Derivation") = (255619001, SCT, "Total")​

•​HAS CONCEPT MOD TEXT (121050, DCM, "Equivalent Meaning of Concept Name") = "Total tumor blood volume relative to​ 150mm2 contralateral normal cerebral white matter"​

The reference region, its blood flow and size, would be specified as:​

•​CODE (121071, DCM, "Finding") = (C94970, NCIt, "Reference Region")​

•​NUM (126391, DCM, "Absolute Regional Blood Volume) = 34.6 (ml/(100.ml), UCUM, "ml/(100.ml)")​

•​HAS CONCEPT MOD CODE (363698007, SCT, "Finding Site") = (68523003, SCT, "Cerebral White Matter")​

•​HAS CONCEPT MOD CODE (272741003, SCT, "Laterality") = (255209002, SCT, "Contralateral")​

•​HAS CONCEPT MOD CODE (121401, DCM, "Derivation") = (255619001, SCT, "Total")​

•​NUM (42798000, SCT, "Area") = 150 (mm2, UCUM, "mm2")​

Alternatively, if the absolute blood volume of the reference region is not available, then its size can be specified alone, e.g.:​

•​CODE (121071, DCM, "Finding") = (C94970, NCIt, "Reference Region")​

•​NUM (42798000, SCT, "Area") = 150 (mm2, UCUM, "mm2")​

- Standard -​

•​HAS CONCEPT MOD CODE (363698007, SCT, "Finding Site") = (68523003, SCT, "Cerebral White Matter")​

•​HAS CONCEPT MOD CODE (272741003, SCT, "Laterality") = (255209002, SCT, "Contralateral")​

The use of a specific reference region may be made explicit if the detailed information for both of the two source measurements, the​ absolute CBV for the lesion and the reference region, is available, in which case they could be encoded as their own instances of​ TID 1411 “Volumetric ROI Measurements”, and then the derived relative measurement encoded using TID 1420 "Measurements​ Derived From Multiple ROI Measurements", as follows:​

•​NUM (126398, DCM, "Relative Regional Blood Volume) = 1.2 ({ratio}, UCUM, "ratio")​

•​R-INFERRED FROM reference to measurement group content item of absolute measurement (Row 1 of TID 1411)​

•​R-INFERRED FROM reference to measurement group content item of reference region measurement (Row 1 of TID 1411)​

OOOO.5 Informative References​

This section lists useful references related to the taxonomy of perfusion measurements.​

OOOO.5.1 Perfusion Measurement Descriptions​

[Wetzel 2002] Radiology. Wetzel SG, Cha S, Johnson G, and et al. 2002. 224. 3. 797–803. “Relative Cerebral Blood Volume Meas-​ urements in Intracranial Mass Lesions: Interobserver and Intraobserver Reproducibility Study”. http://dx.doi.org/10.1148/​ radiol.2243011014 .​

[Bjørnerud 2010] J Cereb Blood Flow Metab. Bjørnerud A and Emblem KE. 2010. 30. 5. 1066–78. “A fully automated method for​ quantitative cerebral hemodynamic analysis using DSC–MRI”. http://dx.doi.org/10.1038/jcbfm.2010.4 .​

[Knutsson 2004] Magnetic Resonance Imaging. Knutsson L, Ståhlberg F, and Wirestam R. 2004. 22. 6. 789–98. “Aspects on the ac-​ curacyofcerebralperfusionparametersobtainedbydynamicsusceptibilitycontrastMRI:asimulationstudy”. http://dx.doi.org/​ 10.1016/j.mri.2003.12.002 .​

[Ziegelitz 2009] Magnetic Resonance in Medicine. Ziegelitz D, Starck G, Mikkelsen IK, and et al. 2009. 62. 1. 56–65. “Absolute​ quantification of cerebral blood flow in neurologically normal volunteers: Dynamic-susceptibility contrast MRI-perfusion​ compared with computed tomography (CT)-perfusion”. http://dx.doi.org/10.1002/mrm.21975 .​

[Jain 2011] AJNR. Jain R. 2011. 32. 9. 1570-1577. “Perfusion CT Imaging of Brain Tumors: An Overview”. http://doi.org/10.3174/​ ajnr.A2263 .​

[Wintermark2001]AJNR.WintermarkM,ThiranJP,MaederP,andetal.2001.22.5.905–14.“Simultaneousmeasurementofregional​ cerebral blood flow by perfusion CT and stable xenon CT: a validation study”. http://www.ajnr.org/content/22/5/905 .​

- Standard -​

- Standard -​

PPPP Real-Time Video Use Cases​ (Informative)​

PPPP.1 Introduction​

Figure PPPP.1-1. Overview diagram of operating room​

As shown in Figure PPPP.1-1, the DICOM Real-Time Video (DICOM-RTV) communication is used to connect various video or multi-​ frame sources to various destinations, through a standard IP switch, instead of using a video switch. In the future, the equipment​ producing video will support DICOM-RTV natively but it is anticipated that the first implementations will rely on the use of converters​ tocreateaDICOM-RTVstreamfromthevideostream(e.g.,SDI)andassociatedmetadatacomingfrominformationsystems,through​ existing mechanisms (e.g., DICOM Worklist). Such converters have to be synchronized with the Grand Master which is delivering a​ very precise universal time. Similarly, the video receivers (e.g., monitors) will be connected to the central switch via a converter which​ has also to be synchronized via the Grand Master. The different DICOM-RTV streams can be displayed, recorded, converted or​ combined together for different use cases. The medical metadata in the DICOM-RTV streams can be used to improve the quality of​ the whole system, as explained in the following use cases.​

Figure PPPP.1-2. Real-Time Video stream content overview​

As shown in Figure PPPP.1-2, the DICOM Real-Time Video stream is comprised of typically three different flows ("essences") for​ respectively video, audio and medical metadata information, using the intrinsic capability of IP to convey different flows on the same​ medium, multiplexing three kinds of blocks. There will be thousands of blocks for each video frame, hundreds for each audio sample​ and one for the medical metadata associated to each video frame, respectively represented as "V" (video) , "A" (audio) and "M"​ (metadata) on the Figure PPPP.1-3, which is the network view of the real-time streaming.​

- Standard -​

Time

Figure PPPP.1-3. Real-Time Video transmission details​

PPPP.2 Use Case: Duplicating Video On Additional Monitors​

In the context of image guided surgery, two operators are directly contributing to the procedure:​

•​a surgeon performing the operation itself, using relevant instruments;​

•​an assistant controlling the imaging system (e.g., laparoscope).​

In some situations, both operators cannot stand on the same side of the patient. Because the control image has to be in front of each​ operator, two monitors are required, a primary one, directly connected to the imaging system, and the second one on the other side​ of the patient.​

Additionaloperators(e.g.,surgerynurse)mightalsohavetoseewhatishappeningonadditionalmonitorsinordertoanticipateactions​ (e.g., providing instrument).​

Figure PPPP.2-1. Duplicating on additional monitor​

Thelivevideoimagehastobetransferredtoadditionalmonitorswithaminimallatency,withoutmodifyingtheimageitself(resolution…).​ The latency between the two monitors (see Figure PPPP.2-1) should be compatible with collaborative activity for surgery where the​ surgeon is, for example, operating based on the primary monitor and the assistant is controlling the endoscope based on the second​ monitor. All equipment is synchronized with the Grand Master. The DICOM-RTV generation capability might be either an integrated​ part of the laparoscope product, or the laparoscope might send an HD video signal to the DICOM-RTV generator (Video-to-DICOM​ converter on the Figure PPPP.2-1). It is important that the converter be able to send video with or without a metadata overlay to the​ assistant monitor. This supplement addresses only the communication aspects, not the presentation.​

PPPP.3 Use Case: Post Review by Senior​

A junior surgeon performs a procedure which apparently goes well. The next day, the patient experiences a complication requiring​ the surgeon to refer the patient to a senior surgeon.​

In order to decide what to do, the senior surgeon:​

•​reviews and understands what happened;​

•​takes the decision to re-operate on the patient or not;​

- Standard -​

•​accesses the videos of the first operation, if a new operation is performed.​

Moreover, the junior surgeon has to review her/his own work in order to prevent against a new mistake.​

Figure PPPP.3-1. Recording multiple video sources​

A good quality recording of video needs to be kept, at least for a certain duration, including all the video information (endoscopy,​ overhead, monitoring, …) and associated metadata from the surgery (see Figure PPPP.3-1). In this case, the metadata is coming​ directly from each device.. The recording has to maintain time consistency between the different video channels. Section PPPP.8.1​ describes how the video could be captured and stored as a DICOM IOD using the present DICOM Store Service, as shown in Fig-​ ure PPPP.3-1, however the video could also be stored in another format. Such IODs could be retrieved and displayed using conven-​ tional DICOM workstation as shown in Figure PPPP.3-1. They could also be played back using DICOM-RTV as described in section​ PPPP.8.2.​

PPPP.4 Use Case: Automatic Display in Operating Room (or)​

Figure PPPP.4-1. Displaying multiple source on one unique monitor​

SomeORshavelargemonitorsdisplayingavarietyofnecessaryinformation.Dependingonthestageoftheprocedure,theinformation​ to display changes. To improve the quality of the real-time information shared inside the OR, it is relevant to automate the changes​ of layout and content of such a display, based on the metadata conveyed along with the video (e.g., displaying the endoscope image​ only when the endoscope is inside the patient body).​

- Standard -​

All the video streams have to be transferred with the relevant metadata (patient, study, equipment…) , as shown in Figure PPPP.4-​ 1. Mechanisms to select and execute the layout of images on the large monitor are not defined. Only the method for conveying the​ multiple synchronized videos along with the metadata, used as parameters for controlling the layout, is specified.​

PPPP.5 Use Case: Augmented Reality​

Figure PPPP.5-1. Application combining multiple real-time video sources​

For image guided surgery, Augmented Reality (AR) applications enrich the live images by adding information as overlay, either 3D​ display of patient anatomy reconstructed from MR or CT scans, or 3D projections of other real-time medical imaging (3D ultrasound​ typically). In the second case, display devices (glasses, tablets…) show a real-time "combination" image merging the primary live​ imaging (endoscopy, overhead, microscopy…) and the real-time secondary live imaging (ultrasound, X-Ray…). The real-time​ "combination" image could also be exported as a new video source, through the DICOM Real-Time Video protocol.​

All video streams have to be transferred with ultra-low latency and very strict synchronization between frames (see Figure PPPP.5-​ 1). Metadata associated with the video has to be updated at the frame rate (e.g., 3D position of the US probe). The mechanisms used​ for generating augmented reality views or to detect and follow 3D position of devices are out of scope. Only the method for conveying​ the multiple synchronized video/multi-frame sources along with the parameters, that may change at every frame, is specified.​

PPPP.6 Use Case: Robotic Aided Surgery​

Robotic assisted surgery involves using image guided robots or "cobots" (collaborative robots) for different kinds of procedures. Dif-​ ferentdevicesusetheinformationprovidedbytherobot(actualposition,pressurefeedback…)synchronizedwiththevideoproduced​ by imaging sources. For effective haptic feedback, it may be necessary to convey such information at a frequency higher than the​ video frequency, i.e.; 400 Hz vs. 60 Hz for present HD video.​

PPPP.7 Example of DICOM Real-Time Video Implementation​

The following example illustrates a specific implementation of the Generic Use Case 4: Augmented Reality described above.​

- Standard -​

Figure PPPP.7-1. Example of implementation for Augmented reality based on optical image​

The described use case is the replacement of the lens in cataract surgery (capsulorhexis). The lenses are manufactured individually,​ taking into account the patient's astigmatism. The best places for the incision, the position where the capsule bag should be torn and​ theoptimalalignmentforthenewlensarecalculatedandagraphicalplaneisoverlaidontotheopticalpathofthemicroscopetoassist​ the surgeon, as shown in Figure PPPP.7-1.​

Some solutions consist of a frame grabber in ophthalmology microscopes which grab video frames at 50 / 60 Hz. These frames are​ analyzed to identify the position and orientation of the eye and then a series of graphical objects are superimposed as a graphical​ plane onto the optical path to show the surgeon the best place to perform the incisions and how to orient the new lens to compensate​ the astigmatism.​

Practically,thevideoframegrabbingtakes3framestobeaccessibletotheimageprocessorcomputingtheseriesofgraphicalobjects​ to be drawn as overlays on the optical image. It results in a delay between the frame used to create the objects and the one on which​ these objects are drawn. For safety reasons, it is important to record what the surgeon has seen. Due to the latency of the frame​ grabbing and the calculation of the positions of these graphical objects, the digital images are delayed in memory to also blend these​ objects onto the right digital image for the recording made in parallel.​

DICOM Real-Time Video enables the storage of the recorded video and the frame by frame positions of these graphical objects​ separately. It might also be used to store other values associated with the streams such as the microscope's zoom, focus and light​ intensity values or the phaco's various settings, pressure, in the DICOM-RTV Metadata Flow. These separately stored flows could​ be later mixed together to aid in post-operative analysis or for teaching purposes. It would be possible to re-play the overlay either​ on the later image where the surgeon saw it, or on the image it was calculated from, to improve the algorithm. It would also reduce​ theworkloadofthemachineduringtheoperationbecausetheblendingofthevideotogetherwiththedisplayaidswouldbeperformed​ later during the post-operative analysis phase, and also maintain the original images.​

The RTP Timestamp (RTS) of both video and DICOM-RTV Metadata Flows must match. Frame Origin Timestamp (FOTS) contained​ in DICOM-RTV Metadata must be consistent with RTP Timestamp, enabling the proper synchronization between flows. As shown in​ Figure PPPP.7-2, it is expected that the Frame Origin Timestamp relative of both the digital image and the overlays are set to T6​ when the Image Datetime is T3 and the Referenced Image Datetime of the Mask is T0, represented as the T0 MASK.​

- Standard -​

Figure PPPP.7-2. Example of implementation for Augmented reality based on optical image​

Note​

In the case the surgeon is viewing the digital image and not the optical image, the approach could be different, as shown in​ Figure PPPP.7-3.​

- Standard -​