Supplement 127: CT Radiation Dose Reporting (Dose SR)



Digital Imaging and Communications in Medicine (DICOM)Supplement 169: Simplified Adult Echocardiography ReportDICOM Standards Committee1300 N. 17th Street, Suite 900Rosslyn, Virginia 22209 USAVersion: Working Draft, Jan 7, 2014Developed pursuant to DICOM Work Item 2012-11-ATable of Contents TOC \o "1-3" \h \z \u Scope and Field PAGEREF _Toc376861283 \h 3Concepts PAGEREF _Toc376861284 \h 3TODO PAGEREF _Toc376861285 \h 4OPEN ISSUES PAGEREF _Toc376861286 \h 5CLOSED ISSUES PAGEREF _Toc376861287 \h 8Changes to NEMA Standards Publication PS 3.2-2011 PAGEREF _Toc376861288 \h 11Changes to NEMA Standards Publication PS 3.3-2011 PAGEREF _Toc376861289 \h 11Changes to NEMA Standards Publication PS 3.16-2011 PAGEREF _Toc376861290 \h 12simplified Adult Echocardiography TEMPLATES PAGEREF _Toc376861291 \h 12TID 5QQQEchocardiography Procedure Report PAGEREF _Toc376861292 \h 12TID 5QQYPre-coordinated Echo Measurement PAGEREF _Toc376861293 \h 14TID 5QQZPost-coordinated Echo Measurement PAGEREF _Toc376861294 \h 14CID newcid1Echo Derivation PAGEREF _Toc376861295 \h 17Changes to NEMA Standards Publication PS 3.17-2011 PAGEREF _Toc376861296 \h 21ANNEX ??: Mapping Guidance? Population Guidance? (Informative) PAGEREF _Toc376861297 \h 22 Scope and FieldThis supplement to the DICOM Standard introduces a simplified SR template for Adult Echocardiography measurements. It provides similar content to that of TID 5200 while addressing details that were the source of interoperability issues; in particular, varying degrees and patterns of pre- and post-coordination, multiple codes for the same concept and numerous optional descriptive modifiers. The new template will be driven significantly by currently documented ASE Guidelines and Standards.ConceptsThis text introduces concepts, principles, guidelines and convenient terms discussed by the committee that influenced the contents of the supplement. It may help reviewers better understand the material. If it still appears to be useful to implementers when the supplement moves to letter ballot it will likely be incorporated into a section in Part 17.Section containers and headings are not used in the new template. Receivers may choose group measurements based on Finding Site or some other logic as they see fit.<Note the distinction between SR being acquisition/evidence and the other side being findings which are more CDA/etc> Finding Site: The location at which the measurement was taken. While some measurements will be a measurement of the structure of the finding site itself, other measurements will measure something like flow in which case the Finding Site is simply the location, not the subject of the measurement. Method: Allows distinguishing between two measurements that tell you the same thing, derived in a different way. If two measurements tell you something different, it's not a method.<<If we want to “improve” the definition of a LOINC code, we basically have to get a new code assigned to our improved definition. Retiring the old code is optional>>TODODONESet up a Concepts Section with a “useful/important distinctions” subsection to capture them as we go.DONEREVIEW how this handles selection and min/max/avg, etc. for the Core setDONEChoose between TID 5201 and TID 36023602 (used by FPC Echo) is more complete and has more mandatory elementsGo with 3602 – it means that technically a cart shouldn’t send an object without requiring the tech to input a height weight.DONEReview TID 5220 Fetal Pediatric Congenital for additional elements to include/harmonize withReview Stress Echo template for template elements to consider/includeReview CID 12280 and 12281Confirm if ASE specifies units and whether those matchPropose additional measurements “common to most vendors” – Paul will post an initial spreadsheet for consideration.REDISCUSS Put a note in part 17 that all indexed values in the body of the report must use the same index value (e.g. BSA) from the Patient Characteristics sub-template.Submit a CP to change “Image or Spatial Coordinates” to “Spatial Coordinates or Image”. The former was confusing for some people, implying it was Coordinates that could either be image coordinates or spatial coordinates.Consider how consuming systems will handle Derivation (Min/Max/Mean/Selected). e.g. if you have three measurements and a fourth that says ”Mean”, is it clear what to do.>><<Seems reasonable for consumers to accomodate this>>WG-6 Questions:Does it matter if LOINC doesn’t specify units? What if they use something odd?Useful Tables:CID 12227Echocardiography Measurement MethodsCID 12226Echocardiography Image ViewsCID 12224Ultrasound Image ModesCID 12250Cardiac Ultrasound Common Linear MeasurementsCID 12222Orifice Flow PropertiesCID 12233Cardiac PhasesCID 12236Echo Anatomic SitesFuture Meetings:2014 AIUM Las Vegas, NV 3/29/2014 – 4/2/20142015 AIUM Orlando, FL 3/21/2015 – 3/25/20152016 AIUM Las Vegas, NV 3/19/2016 – 3/23/2016OPEN ISSUESScopeS1Should TID 5200 (the original) be retired when the new TID is introduced?A: Yes.Probably depends on how we support vendor-specific and user-defined.Should hopefully retire it. We can still ship products that are capable of sending 5200, but new products probably shouldn’t bother. If we offer two Adult Echo templates, some percentage of novice vendors will choose 5200 without understanding the implications.S2Is it necessary/practical to guarantee convertability from Old-to-New SOP?A: Guarantee, no. But try to keep it tractable.Doing so would prevent making new information mandatory which would also restrict harmonization with newer templates.Could allow systems to output both and let recipients choose to use the new?Note that a system that can’t fill in values could omit the measurement from the converted new SOP.S5Have other international groups published “Core Set” papers we should include?Get Public Comment inputLook into JIRA (Japan) and EAE (Europe)S6What is needed to address both the processing and reporting systems on the consuming side?Processing may want to tweak/select direct measurements and recalculate derived measurements. Reporting might want to just reach in for a single value.Need to encourage adoption. Note that some of the job is for the consuming system to filter/simplify based on its needs.One concept is to have a “summary” section.Another concepts is for the Cart to output two instances of the same IOD, one is sparse/summary (reporting), the other is more complete (processing). S7What is needed to handle “vendor-specific” measurements (beyond core)?What information gets recorded (eg display/screen name of the measurement on the original cart)How does it get slotted into the database, and who does that configuration?S8Can the vendor-specific strategy also be used for user-defined measurements? Maybe this is the root case and vendor-specific is just user-defined where the vendor is a user?Maybe the vendor presets are just too hard to navigate.Note that part of the problem is that these may not be well modelled. They “just want a label and a number” but then later they want intelligent handling of the data they have handicapped.S9How should the core set be expanded to include some common vendor-specific ones?S10How/Should vendor education be addressed?The new template makes finer distinctions than the old template. To reduce the validation load on the consuming systems, confidence is needed that the producing system is in fact taking the distinctions into account. E.g. Systole, vs End Systole, vs Atrial Systole. So if the pre-coordinated code means exactly End Systole, then don’t use the pre-coordinated code if the system measures at mid-systole.What kind of a process should WG12 have (if any) to monitor and react to updates from ASE?StructureSt2Should the list of Core Measurements be included directly in RID rows, or dereference through CID tables?Strongly consider TIDs. This would allow making some measurements conditional on other measurements and explicitly making units required, etc.Since there are 150-200 core measurements, might want to break out a few sub TIDs to make it more readable/manageable.St1Create a new SOP Class?A: Yes.We will create a template and will give it a new UID. This allows negotiation for the new template (and allows systems to reject the new template if they don’t support it). The contents still parse and process as SR (i.e. dsrdump still works, parsers don’t need to be changed, etc.)Of course the template can still be sent inside a generic SR SOP Class.Could this be handled with extended negotiation? Has anyone implemented it?How do we deal with the Average of several instances and the Selector of several instances?Should the Core Spreadsheet be maintained?The sorting and filtering and parsing could be very handy.CodingC9Do the Cardiac Phase/Cycle semantics refer to Mechanical or Electrical and the Chamber or the Organ?Most clear is to refer to the chamber. And be clear in the definition about time point vs time period and if needed time point at the end, not mid.Could allow that if not fully specified, the default chamber is the Left Ventricle, i.e. End Systole = Left Ventricle End SystoleIf just systole or diastole is referred to, it means the period of the full duration of systole or diastole. Often the code meaning will refer to Systolic X.Pre-coordinate but work off the codeset in CID 12233 (but need clear definitions, does SNOMED provide them?)C10Should missing codes be added in LOINC, SNOMED or DICOM?Most of the existing (mostly) pre-coordinated codes are from LOINC, most of the existing post-coordinated concepts are from SNOMED. When fully pre-coordinated codes exist in both, let’s prefer LOINC. If we don’t have LOINC, but we do have SNOMED, do we still ask LOINC for a new code, or do we just use the SNOMED? YES. If you need a LOINC measurement code, ask for one.For now, use DICOM Supp placeholder codes and consider this closer to or during Public Comment.Need to review the new LOINC codes introduced in Sup 78 and use if possible.C11How should values that have to be estimated by the operator/clinician be addressed?Need to allow the method for some measurements to be “estimated”.Should perhaps mandate that if there are derived/calculated values, then all input values must be included in the SR as well so it will be recorded if some inputs are estimated.May also need to use the tools to point specifically to the values that were used in a given equation.C13Does Hand Grip and Valsalva need to be encoded (in association with specific measurements)?C14What needs to be captured about the package/pre-processing before the measurement? E.g. if presence of special speckle tracking or proprietary segmentation, where does that fit in?Or is this about a unique method or a unique measurement vs about the package that was used.Do we need to record Stress Stage in a pre-coordinated way for each or specific measurements?Is this better recorded at a higher level in the object? (would force separate objects for different stages)Finding Site – is it the structure measured, the location where a measurement was taken, etc.Strong admiration of the problem. Mostly we get to avoid this by pre-coordinating the codes then there IS no Finding Site.But we will need to revisit when we consider user-defined measurements or “annotating modifiers”Do we have a need for grouping?Method modifier?It’s what we add new ones of most. Sometimes it matters.Consider the difference between a value, like velocity, that can be directly measured or can be derived from an equation. In the case of precoordination this is less of an issue since we simply explain which it is, but needs consideration for user-defined.Adding new methods has a rollout challengeNote that DCM 125212 is underspecified relative to the other codes that follow it.Supplemental informationNo modifiers on core measurements"For some attributes (e.g. the Image View for the Right Ventricule Free Wall Thickness) multiple valid values exist and we don't really care which it is (mdc). Prohibit senders from sending it (rather than allowing senders to code it and receivers to ignore it). Most importantly, we don't want transmission to fail because the receiver has trouble handling it."Do we want to differentiate equation/derived “measurements” from those measured directly?The derived don’t exactly have a view/mode/etc, or may be derived from elements in several views/modes/etc.CLOSED ISSUESScopeS3Should Cardiovascular History be reiterated in the Echo SR?A: No.If the worklist provides it, it might be OK to suggest it be copied, but otherwise, the Cart is not likely to have access to this information unless the tech does manual data entry, in which case, it’s not clear that the cart console is the best place/GUI to be typing it in. It would be better done by a clerical person on another system (e.g. the HIS, the RIS or the CVIS).Note that Indications have been included. Perhaps the same logic applies to those.S4What is in the core list of measurements?A: The full set of concepts from the ASE papers, as collated in the ASE Core spreadsheet. (about 150 currently) plus additional measurements proposed by vendors and found to be reasonably “common”.No new papers have come out recently so the original work stands (spanning 1989ish to 2012ish)StructureSt3Should the TID Row Order be Significant or Insignificant?A: Assume insignificant until a need is found for it to be significant.Order significant would be a harder for producer but might be easier for consumers.CodingC1Should the code meanings use uniform terminology or colloquial terminology?A: Use uniform but don’t be pedantic.Colloquial is somewhat random which might lead to coding errors. Use uniform terms unless they get too unwieldy. In any case, Apps can display them in the GUI/report any way they like.C2Bias toward pre-coordination or post-coordination? A. Pre-coordination.?Make it mandatory?Do not include modifiers[Structure/Location/Finding Site] [Observable][Flow Direction?] [Cardiac Phase] [Method] etcSee Google Doc.Would it be bad to allow lots of modifiers that reiterate semantics in the pre-coordinated code to allow “dumb” applications to handle new codes in some way (e.g. add to the For example some measurements will have “View not specified” since we don’t care and don’t want codes for all the different variants.<Do we allow a measurement to add a detail like view to a NOS code>But maybe we say that user measurements are completely post-coordinated and all modifiers are mandatory. But what process is this facilitating, and would it be better just to do the Conformance statement.Might want to have a user-defined-measurement flag (beyond the private coding scheme?)And we might want to put the vendor and user defined measurements in another group/container.Note that we will have to enforce some level of discipline on the user when creating/configuring new measurements.C3How can reasonable consistency of units be achieved?A: Stick to what is stated in ASE, but flag & discuss deviations from the following:Distance in cmArea in cm2 (except BSA in m2) Velocity in m/s (except Tissue Doppler in cm/s)Time in msVolume in mlMass in gFlow in ml/sSystems are welcome to do conversions when displaying measurements to users if some sites/users have preferences that differ from the standard.C4Should $DerivationParameter, $Equation, or $Table be encoded?A: No.They add complexity. Few creators use them. Few consumers support them (or else they get derailed when they are provided).For the core set the equation is pre-coordinated in the measurement. For user-defined measurements, it seems unlikely that consumers would parse/recomputed the value even if the equation was included in-band, rather than just documenting it out of band. Arguably, equations could be stuffed in the Code Meaning of the $Method (which is done in a couple of places in Part 16), since the only real user might be the clinician wanting to know what equation was used, but usually they are named, not expressed.Anyone with a concrete Echo use case for these should present it. (They are used somewhat in OB for the GA calculations)C5Should $Quotation be encoded?A: No.It adds complexity. Few creators use it. Few consumers support it (or else they get derailed when they are provided).Anyone with a concrete Echo use case for these should present it. C6Should $Equivalent Meaning of Concept Name be encoded?A: No.It adds complexity. Few creators use it. Few consumers support it (or else they get derailed when they are provided).Anyone with a concrete Echo use case for these should present it. C7Should $Laterality and $Topographical Modifier be encoded?A: No.Don’t need them for Cardiology (although vascular does). Left/right chambers are not laterality. Proximal/Distal/etc is not relevant.Anyone with a concrete Echo use case for these should present it. C8Should $Measurement Properties be encoded?A: No.It adds complexity (normality codes, level of significance, statistical properties, ranges, range authorities). Few if any creators use it. Few consumers support it (or else they get derailed when they are provided).Anyone with a concrete Echo use case for these should present it. The Selection Method concept is useful though. It will be migrated into the Derivation.C12Do Flow Direction semantics refer to the viewpoint of the probe or anatomy?A: Anatomy is most clinically useful (see CID 12221). While the probe knows towards/away, the app must help figure out the anatomic.Changes to NEMA Standards Publication PS 3.2-2011Digital Imaging and Communications in Medicine (DICOM)Part 2: ConformanceAdd Section:Describe documentation of vendor specific measurements. For example, the format could require that you document the view, the mode, the method, etc, etc, etcChanges to NEMA Standards Publication PS 3.3-2011Digital Imaging and Communications in Medicine (DICOM)Part 3: Information Object DefinitionsAdd new SOP Class if needed:<Likely needed but still a point of discussion>Changes to NEMA Standards Publication PS 3.16-2011Digital Imaging and Communications in Medicine (DICOM)Part 16: Content Mapping ResourceAdd new Section? to Annex Asimplified Adult Echocardiography TEMPLATESThe templates that comprise the Simplified Adult Echocardiography Report are interconnected as in Figure A-x.1 TID 5QQQSimplified Echo Procedure ReportTID 1204Language of Content Item and DescendantsTID 1001Observation ContextTID 3602Cardiovascular Patient CharacteristicsTID 5QQYPrecoordinated Echo MeasurementTID 5QQZPostcoordinated Echo MeasurementTID 5204Wall Motion AnalysisTID 5QQQSimplified Echo Procedure ReportTID 1204Language of Content Item and DescendantsTID 1001Observation ContextTID 3602Cardiovascular Patient CharacteristicsTID 5QQYPrecoordinated Echo MeasurementTID 5QQZPostcoordinated Echo MeasurementTID 5204Wall Motion AnalysisFigure A.x-1: Echocardiography Procedure Report Template StructureTID 5QQQEchocardiography Procedure Report This template forms the top of a content tree that allows an ultrasound device to describe the results of an adult echocardiography imaging procedure. It is instantiated at the root node. It can also be included in other templates that need to incorporate echocardiography findings into another report as quoted evidence.TID 5QQQ – Simplified Echo Procedure Report Type: ExtensibleOrder: Insignificant NLRel with ParentVTConcept NameVMReq TypeConditionValue Set Constraint1CONTAINEREV (125200, DCM, “Adult Echocardiography Procedure Report”)1M2>HAS CONCEPT MODINCLUDEDTID (1204) Language of Content Item and Descendants1U3>HAS OBS CONTEXTINCLUDEDTID (1001) Observation Context1M4>CONTAINSCONTAINEREV (121109, DCM, “Indications for Procedure”)1U5>>CONTAINSCODEEV (121071, DCM, “Finding”)1-nUDCID (12246) Cardiac Ultrasound Indication for Study6>>CONTAINSTEXTEV (121071, DCM, “Finding”)1U7>CONTAINSCONTAINERDT (121064, DCM, “Current Procedure Descriptions”) 1U8>>CONTAINSCODEDT (125203, DCM, “Acquisition Protocol”) 1-nMBCID (12001) Ultrasound Protocol Types REVIEW9>CONTAINSINCLUDEDTID (3602) Cardiovascular Patient Characteristics1U<<Note there are some mandatory contents but it is currently optional to include the module>>10>CONTAINSCONTAINEREV (111028, DCM, “Image Library”)1U11>>CONTAINSIMAGENo purpose of reference1-nMConsider if we want to have a container here for the pre-coords to be a midpoint between Order significant and Order non.Could also consider requiring they be sorted by code value (which is predictable/non-random and simple to implement)<<For the purpose of sup dev, will likely break up the following into a few anatomically grouped tables and maybe merge them all at the end>>20>CONTAINSINCLUDEDTID (5QQY) Pre-coordinated Echo Measurement1-nU$Measurement = Aortic Valve Annulus Diameter (LN, 18016-6)$Units = EV (cm, UCUM, “centimeter”)21>CONTAINSINCLUDEDTID (5QQY) Pre-coordinated Echo Measurement1-nU$Measurement = Aortic Valve Velocity-Time Integral (LN, 18169-3)$Units = EV (cm, UCUM, “centimeter”)21>CONTAINSINCLUDEDTID (5QQY) Pre-coordinated Echo Measurement1-nU$Measurement = Aortic Valve Peak Systolic Flow (LN, 11706-9)$Units = EV (m/s, UCUM, “meter per second”)<<refer to spreadsheet>>N>CONTAINSINCLUDEDTID (5QQZ) Post-coordinated Echo Measurement1-nU$Measurement = …probably your vendor-specific private pre-coordinated code…$Units = …the units for this code….N+1>CONTAINSINCLUDEDTID (5204) Wall Motion Analysis1-nU$Procedure = DT (P5-B3121, SRT, "Echocardiography for Determining Ventricular Contraction").Content Item DescriptionsRow 6A text string containing one or more sentences describing one or more indications, possibly with additional comments from the physician or tech.Row 11All images which are referenced in the body of the SR will be listed here.TID 5QQYPre-coordinated Echo MeasurementThis Template codes numeric echo measurements where most of the details about the nature of the measurement have been pre-coordinated in the measurement code. In contrast, see TID 5QQZ Post-coordinated Echo Measurement. The pre-coordinated measurement code and units are provided when this Template is included from a parent Template.Note that this template is a simple subset of TID 300.TID 5QQY ParametersParameter NameParameter Usage$Measurement Coded term or Context Group for Concept Name of measurement$UnitsUnits of MeasurementTID 5QQY Pre-coordinated Echo Measurement Type: ExtensibleOrder: InsignificantNLRelation with ParentValue TypeConcept NameVMReq TypeConditionValue Set Constraint1NUM$Measurement1MUnits = $Units2>HAS CONCEPT MODCODEEV (121401, DCM, “Derivation”) 1UDCID (newcid1) Echo Derivation3>INCLUDEDTID (320) Image or Spatial Coordinates<<Do we want to permit SCOORD3D here? Probably since we are seeing more Echo 3D>>1-nU$Purpose = EV (121112, DCM, "Source of measurement”)4>INCLUDEDTID (321) Waveform or Temporal Coordinates1-nU$Purpose = EV (121112, DCM, "Source of measurement”)Content Item DescriptionsTID 5QQZPost-coordinated Echo MeasurementThis Template codes numeric echo measurements where most of the details about the nature of the measurement have been post-coordinated in modifiers and acquisition context. In contrast, see TID 5QQY Pre-coordinated Echo Measurement. It is intended to be used for User-defined and Vendor-defined Echo Measurements.TID 5QQZPost-coordinated Echo Measurement Type: ExtensibleOrder: InsignificantNLRelation with ParentValue TypeConcept NameVMReq TypeConditionValue Set Constraint1NUM$Measurement1MUnits = $Units1a>HAS CONCEPT MODCODEEV (121401, DCM, “Derivation”) 1UDCID (newcid1) Echo Derivation1b>INCLUDEDTID (320) Image or Spatial Coordinates1-nU$Purpose = EV (121112, DCM, "Source of measurement”)1c>INCLUDEDTID (321) Waveform or Temporal Coordinates1-nU$Purpose = EV (121112, DCM, "Source of measurement”)2>HAS CONCEPT MODCODEEV (G-C0E3, SRT, “Finding Site”)1MBCID (12236) Echo Anatomic3Observable? Characteristic?MCIFF the measurement is not unambiguously associated with a characteristic of the structure of the Finding Site in Row 2.4Measurement5>HAS CONCEPT MODCODEEV (G-C036, SRT, “Measurement Method")1M<<Do we need codes for “Direct Measurement” or “NOS”>>BCID (12227) Echocardiography Measurement Methods6>HAS ACQ CONTEXTCODEEV (G-0373, SRT, “Image Mode”)1MDCID (12224) Ultrasound Image Modes7>HAS ACQ CONTEXTCODEEV (111031, DCM, “Image View”)1MBCID (12226) Echocardiography Image View8>HAS CONCEPT MODCODEEV (R-4089A, SRT, “Cardiac Cycle Point”)1UDCID (12233) Cardiac Phase9>HAS CONCEPT MODCODEEV (G-C048, SRT, “Flow Direction”)1MCIFF the flow direction is significant for this measurement.BCID (12221) Flow Direction10>HAS CONCEPT MODCODEEV (R-40899, SRT, “Respiratory Cycle Point”)1MCIFF the respiratory cycle point is significant for this measurement.DCID (12234) Respiration StateN>HAS CONCEPT MODINCLUDEDTID (1210) Equivalent Meaning of Concept Name1UPost-coordinated Code here? Or send it as parameter to the 5QQY include at the top?Echo Measurement DescriptionsRow 1<< vendor values and user values would look similar except for Dictionary>>Row 2The finding site should reflect the anatomical location where the measurement is taken, preferably coded using SNOMED to a find detail as possibleRow 3For example, in the case of Doppler, the Characteristic is the Antegrade Flow or the Retrograde Flow at the Finding Site. In the case of a diameter measurement with a finding site of a blood vessel, generally Row 3 would not be present.Row N “Equivalent Meaning of Concept Name” allows the creating application to specify the preferred composed concept name representing the measurement and the associated post-coordination Concept Modifiers. Add the following CID’s to Part 16 Annex B:CID newcid1Echo DerivationContext ID newcid1Echo DerivationType: Extensible Version: yyyymmddCoding Scheme Designator(0008,0102)Code Value(0008,0100)Code Meaning (0008,0104)SRTG-A437MaximumSRTR-404FBMinimumSRTR-00317MeanDCM121410User chosen valueDCM121411Most recent value chosenAdd the following Definitions to Annex DDICOM Code Definitions (Coding Scheme Designator “DCM” Coding Scheme Version “01”)Code Valuexe “(0008,0100)”Code Meaningxe “(0008,0104)”Definition…Definition Template:The <attribute> in <units> of the <structure/characteristic> measured in <mode/view> at/during <time/phase> using the <method> normalized by <index>. The measurement may have been taken using any <leftovers>.Consider removing units since that is not fundamental to the concept and is communicated in the $units anyway.Aortic Valve Annulus DiameterThe diameter in cm of the Aortic Valve Annulus measured in 2D mode at End Systole. The measurement may have been taken using any view or method.Aortic Valve Flow VTIThe Velocity Time Integral in cm of the Aortic Valve Flow measured in Doppler mode during Systole. The measurement may have been taken using any view or method.Aortic Valve Flow Peak VelocityThe Peak Velocity in m/s of the Aortic Valve Flow measured in Doppler mode during Systole. The measurement may have been taken using any view or method.Aortic Valve Flow Mean VelocityThe Mean Velocity in m/s of the Aortic Valve Flow measured in Doppler mode during Systole. The measurement may have been taken using any view or method.Aortic Valve Peak Instantaneous GradientThe Peak Instantaneous Pressure Gradient in mmHg across the Aortic Valve measured in Doppler mode during Systole using the Simplified Bernoulli method. Aortic Valve Mean GradientThe Mean Pressure Gradient in mmHg across the Aortic Valve measured in Doppler mode during Systole using the Simplified Bernoulli method. Aortic Valve Regurgitant Flow VTIThe Velocity Time Integral in cm of the Aortic Valve Regurgitant Flow measured in Doppler mode during Diastole. The measurement may have been taken using any view or method.Aortic Valve Regurgitant Flow Volume by PISAThe Volume in ml of the Aortic Valve Regurgitant Flow measured in Doppler mode during Diastole using the PISA method. The measurement may have been taken using any view.Aortic Valve Regurgitant Flow Jet Area to LVOT AreaThe Ratio in % of the Aortic Valve Regurgitant Flow Jet Area to the LVOT Area measured in Doppler mode during Diastole (?). The measurement may have been taken using any view.Aortic Valve Regurgitant Flow Effective Orifice AreaThe Effective Orifice Area in cm2 of the Aortic Valve Regurgitant Flow measured in Doppler mode during Diastole using the volume derived from the PISA method? The measurement may have been taken using any view.Aortic Valve Regurgitant FractionThe Ratio in % of the Aortic Valve Regurgitant Volume to the Aortic Valve Stroke Volume measured in Doppler mode. The measurement may have been taken using any view.Aortic Valve Area by Continuity VTI / BSAAn indexed value in cm2/m2 representing the Area in cm2 of the Aortic Valve measured in Doppler mode using the Continuity VTI method, normalized to the Body Surface Area in m2.Pulmonary Vein Flow S-wave Peak VelocityThe Peak Velocity in m/s of the Pulmonary Vein Flow measured in pulsed Doppler mode during Systole. The measurement may have been taken using any view or method and in any of the Pulmonary Veins.Pulmonary Vein Flow A-wave DurationThe Duration in ms of the Pulmonary Vein Flow measured in pulsed Doppler mode during Atrial Systole. The measurement may have been taken using any view or method and in any of the Pulmonary Veins.Delta DThe difference in duration in ms between the duration of the Pulmonary Vein Flow measured in pulsed Doppler mode during Atrial Systole, and the duration of the Mitral Valve Flow measured in pulsed Doppler mode during Atrial Systole. The measurement may have been taken using any view or method and in any of the Pulmonary Veins.Modify Definitions in Annex D as shown:DICOM Code Definitions (Coding Scheme Designator “DCM” Coding Scheme Version “01”)Code Valuexe “(0008,0100)”Code Meaningxe “(0008,0104)”DefinitionChanges to NEMA Standards Publication PS 3.17-2011Digital Imaging and Communications in Medicine (DICOM)Part 17: Explanatory InformationAdd Annex ??ANNEX ??: Mapping Guidance? Population Guidance? (Informative)Use Case 0: Store and Use Core SetUse Case 1: Store and Display on PACS (non-semantic number)[User configures Cart: define tool/interaction and link to new measurement = ID + Label String][User writes down detailed description of new measurement] (which then gets thrown in the shredder)User takes measurement on CartCart stores measurement value & units in SR for the exam under the ID+Label StringCart sends SR to PACSUser selects an exam on PACS for displayPACS opens image and renders to screen[User configures PACS: define layout/overlay and link row to SR Tag = ID]PACS opens SR, finds ID, renders Label String, renders value+unitsQ. Can we allow the customer to sometimes use LN code for the ID and sometimes local code? In any case it would be handy to use the same ID on several carts so they Use Case 2: Store and Insert in Report (non-semantic)Same as PACS, but PACS=>Reporting Station, Layout=>Template, Render=>InsertUse Case 3: Store and Plot Graph? Trending? Database? Etc.May be useful to limit Use Case 3 to single/individual patient and push Big Data/Population health into Use Case 4.** Include a description of the sub-case where the object is from some other hospital. How do you track down the paper? E.g. look in the header for the institution, call their Echo group, quote the name of the measurement and ask for documentation.Q. How do we handle dumb reporting systems? Could send a two objects, a stripped down one for the reporters and a fully fledged one for the CVIS. Could assume that the CVIS will pre-process and spoonfeed the reporter. Could assume that the cart will be down-configured to minimal outputs. Could imagine a flag. The cases are: how do I handle multiples of the same measurement (and know you should take the last, or the mean) vs recognizing specialized (e.g. X by Method A and X by Method B to be instances of generic X). ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download