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, Mar 21, 2014Developed pursuant to DICOM Work Item 2012-11-ATable of Contents TOC \o "1-3" \h \z \u Scope and Field PAGEREF _Toc383705964 \h 3Concepts PAGEREF _Toc383705965 \h 3TODO PAGEREF _Toc383705966 \h 5OPEN ISSUES PAGEREF _Toc383705967 \h 6CLOSED ISSUES PAGEREF _Toc383705968 \h 11Changes to NEMA Standards Publication PS 3.2-2011 PAGEREF _Toc383705969 \h 15Changes to NEMA Standards Publication PS 3.3-2011 PAGEREF _Toc383705970 \h 15Changes to NEMA Standards Publication PS 3.16-2011 PAGEREF _Toc383705971 \h 16simplified Adult Echocardiography TEMPLATES PAGEREF _Toc383705972 \h 16TID 5QQQEchocardiography Procedure Report PAGEREF _Toc383705973 \h 16TID 3QQPre-coordinated Echo Measurement PAGEREF _Toc383705974 \h 18TID 3QZPost-coordinated Echo Measurement PAGEREF _Toc383705975 \h 18CID newcid1Echo Derivation PAGEREF _Toc383705976 \h 21CID newcid2Echo Finding Subjects PAGEREF _Toc383705977 \h 21CID newcid3Echo Measurement Type PAGEREF _Toc383705978 \h 22CID newcid4Echo Measured Properties PAGEREF _Toc383705979 \h 22CID newcid0Core Echo Measurements PAGEREF _Toc383705980 \h 23Changes to NEMA Standards Publication PS 3.17-2011 PAGEREF _Toc383705981 \h 27ANNEX ??: Mapping Guidance? Population Guidance? (Informative) PAGEREF _Toc383705982 \h 28 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.Anatomic Sections: Were included as containers and headings in the old template to facilitate layout of printed/displayed reports. These were a source of problematic variability and are not used in the new template. Receivers may choose group measurements based on Finding Site or some other logic as they see fit. By configuring this at the receiver it can be consistently organized in one place rather than having to synchronize the behavior of many carts. SR objects are considered acquisition data/evidence. When the findings are transcoded into CDA reports sections will likely be introduced in the CDA as appropriate.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 actual subject of the measurement (e.g. at a valve, be clear when it is the velocity of the blood, not the velocity of the valve leaflets). 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.Indexing: All Core Set measurements that index against BSA, and all post-coordinated measurements that reference (LN, 8277-6, Body Surface Area) as their index are using the value recorded for BSA in the Patient Characteristics TID. The TID can encode the equation used to derive the BSA.Myocardium refers to the tissue from the endocardium to the epicardium and includes the intraventricular septum.Useful Tables:CID 12222Orifice Flow PropertiesCID 12224Ultrasound Image ModesCID 12226Echocardiography Image ViewsCID 12227Echocardiography Measurement MethodsCID 12233Cardiac PhasesCID 12236Echo Anatomic SitesCID 12250Cardiac Ultrasound Common Linear MeasurementsFuture 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/2016TODODONEChoose 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.Review 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.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 accommodate this>>Gopi – Diagram the four viewpoints (New Cart, Old Cart, New Receiver, Old Receiver) and how they will use/understand/respond to new and old SRs when doing association negotiation and/or extended negotiation and/or parsing the objects. Earl – Consider how a 5200 parser would respond to being given a new object. It would be nice if it provides some basic success.Get New LOINC CodesIf we want to “improve” the definition of a LOINC code, we have to get a new code assigned to our improved definition. Retiring the old code is optional.PS 3.16 Annex G says that LN 11726-7 Peak Velocity is synonymous with Peak Systolic Velocity.Is that true in LOINC? Is that what we want?WG-6 Questions:PS 3.16 Annex H seems to redefine the code meaning of many LN codes. What’s the history?(Added to get more clear short names, ask Harry for details. OK for us to use too.)OPEN 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.On the other hand, if our “fallback” for non-Core measurements that can’t be coded in the structured post-coordinated bucket is to suggest they be sent with 5200 then we shouldn’t retire it. Maybe they can use generic Comprehensive SR.S2Is it necessary/practical to guarantee convertibility from Old-to-New SOP?A: Guarantee, no. We are trying to make sure that the new SOP is reasonably powerful so it may be reasonably 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)(Japan signed on to at least one of the ASE papers)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.Possible approaches:have a “summary” sectionuse a “Preferred” flag to highlight the values for simple consumers output two instances of the same IOD from the cart, one is sparse/summary (reporting), the other is more complete (processing). S7How much do we support “vendor-specific” measurements (beyond core)?Common measurements could be added to the Core Set. “Well behaved” measurements can go in the Post-Coordinated Measurement container.That should handle a large number of typical variations. By using the spreadsheet to model the core set, we’ll have a good set of “basis axes” for the Post-Coordinated Measurement container.So what should we do about measurements that don’t fit in the Post-Coordinated bucket.We could add a “freeform” container with few rulesWe could add an “Additional Modifier Code Sequence” to the Post-Coordinated bucket or simply allow it to be extendedWe could tell them they just have to make a Private SOP Class.The danger is that “lazy implementers” might just put everything in the freeform section or otherwise abuse the tools.There is of course a tradeoff between interoperability/simplicity and being able to use this for ANY measurement (particularly “ambiguous codes” that are 1-1 coordinated between sites and vendors)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? That’s the intentMaybe 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.S10What kind of a process should WG12 have (if any) to monitor and react to updates from ASE?S11S13How/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.Is TEE excluded?Having View=mdc for most measurements means TEE is not excluded and that is good. Check if there are TEE issues for ones where View is not mdc.StructureSt2Should the list of Core Measurements be included directly in TID rows, or dereference through CID tables?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.On the other hand, CIDs are much more readable for implementers.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 at the template level? Has anyone implemented it?Q (Earl) Would a generic or flexible 5200 parser handle the new template OK? If so, it’s a nice avenue of legacy reader support.Gopi – will diagram how this will work with New Sender – New Receiver, New Sender (how does the sender know it is getting a new one, how does the sender know it’s a New R that handles it not an Old R that drops it) – Old Receiver, Old Sender – New Receiver, Old Sender – Old Receiver.** Proposing constraint that samples must be consistent with the stats** Update the Selector/Derived as shown on the diagram on the whiteboardWithin the container (Pre-Coord; Post-Coord), should measurements be sorted by code?A: No.It would be a predictable/non-random order that would be simple to implement.It would group multiple instances of the same measurement together.But parsers have to handle any order anyway, and it’s a simple run through to sift for what you need.Should the Image Library container be MC based on use of REFER in the children?It’s simplest to make it optional. Really the recipient can construct the library themselves?The purpose is to describe the images, not just list them. So maybe it doesn’t really serve a purpose here.Do not use references from the children to the image library – it’s complex for the parser. Better to just have a direct “by value” reference in the measurement to the specific image instance.Or should the use of REFER or INFER be mandated below?(Ann looking into more detail)Should the Core Spreadsheet be maintained?The sorting and filtering and parsing could be very handy for some.The details would not otherwise be included in the DICOM standard.Consider somehow fitting it into Part 17?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)?Maybe yes. This is significant for Mitral E Velocity. (and others?)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. Might need a method modifier.Should we try to unify/converge units across modalities?A: No.I.e. when the same measurement is made in CT, MR, XA, …Probably outside scope for this supplement, but we have been sloppy and someone should tackle it.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)Is Stress Echo in scope for this Object? (It’s not handled in 5200 now – although it references 5202 which references the Echo section) Note that Wall Motion Scoring is not really used outside of Stress. So do we want to bring in 5202 to our template. And if so, how does it work. It would start breaking up into sections again.How can a consumer identify/strip out derived values (that could be re-derived if needed?) vs measured values?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.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."Should ratios and indexes be modelled in the post-coordinated structure?Representing a simple numerator/denominator relationship between two values might be tractable and might address a lot of vendor and user-defined variations (e.g. wishing to index against BMI instead of BSA, or taking a ratio of two values)Significant resistance noted. Will evaluate once a structure for modelling this is proposed.Review how TID5223 modelled indexes.How should Indexed Measurements (e.g. by BSA) be encoded?Is it fair to say that whenever an indexed measurement is stored, the unindexed measure is also stored? (e.g. LVID & LVID/BSA)We should likely require that whenever an indexed measure is stored, the index itself (BSA) also be stored with the value that was used in the indexed measure. Are there cases where we might use different values of BSA in the same acquisition set?One approach would be to store the base value and the index and if anyone wants the indexed value, they could compute it in a single step. That would be fine for databases and analysis packages, but would it work for display overlays and report insertions?Do we add an “Indexed by” attribute, and record the code for the index used, eg. BSA. Then the Measurement could contain the nature of the base measure, as long as consumers are smart enough to look at the Indexed by column to understand why a “diameter” measure is in cm/m2.In the case of pre-coordinated codes, the Indexing is built into the concept.Average of Septal & Lateral values used instead of separately? E:eprime ratioCLOSED 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)S12Should advanced equations be modelled?A: No. Too complex and open ended.Should the vanilla template retain a few congenital codes?A: Yes. Want to allow a vanilla workup to record a few of these measurements without invoking the more sophisticated Fet/Ped/Con template which supports a more complete workup. Forcing them to switch to the FPC template could be problematic since some sites don’t expect that and won’t have it configured. The current list in the spreadsheet is sufficient.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 cm/sTime 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.How should different BSA calculation methods be handled?A: Core Set will code DuBois.Other methods can be handled as vendor/user-defined. The receiver can also compute alternate indexes.What does Finding Site mean (in Post-Coordinated measurements)? A: The nominal location where the measurement was taken. It may or may not be the subject of the measurement. The latter is coded in Finding Subject. For example, Doppler can measure the velocity of both blood and tissue. A Finding Site=Mitral Valve and Finding Subject= Antegrade Flow means a measurement of the velocity of the antegrade blood flow taken at the mitral valve.Note there are a few ambiguous cases: the Pulmonary Pressure is the site of the mmHg finding value, but a measurement sample was taken elsewhere to compute that finding.Should we allow modifiers on Finding Site?A: Not in Post-coordinated.It is irrelevant in Pre-coordinated. It is seldom used in post-coordinated. Simplest is to use more specific Finding Sites when needed.If we allow an “Unconstrained bucket” then modifiers of everything could be allowed.The main drivers for modifiers would be to allow tagging particular segments of a vessel or specific parts of a Mitral Valve Leaflet. Modifiers could, however, open a can of worms for receiving systems in terms of unexpected pairings.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> See Homework for Gopi to model the different cases.Changes to NEMA Standards Publication PS 3.16-2011Digital Imaging and Communications in Medicine (DICOM)Part 16: Content Mapping ResourceAdd new Section to Annex A following Echocardiography Procedure Report Templatessimplified 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 3QQPrecoordinated Echo MeasurementTID 3QZPostcoordinated Echo MeasurementTID 5204Wall Motion Analysis (TBD)TID 5QQQSimplified Echo Procedure ReportTID 1204Language of Content Item and DescendantsTID 1001Observation ContextTID 3602Cardiovascular Patient CharacteristicsTID 3QQPrecoordinated Echo MeasurementTID 3QZPostcoordinated Echo MeasurementTID 5204Wall Motion Analysis (TBD)Figure 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: Non-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>CONTAINSCONTAINERDT (121064, DCM, “Current Procedure Descriptions”) 1U5>>CONTAINSCODEDT (125203, DCM, “Acquisition Protocol”) 1-nMBCID (12001) Ultrasound Protocol Types6>CONTAINSCONTAINEREV (121109, DCM, “Indications for Procedure”)1U7>>CONTAINSCODEEV (121071, DCM, “Finding”)1-nUDCID (12246) Cardiac Ultrasound Indication for Study8>>CONTAINSTEXTEV (121071, DCM, “Finding”)1U9>CONTAINSINCLUDEDTID (3602) Cardiovascular Patient Characteristics1U10>CONTAINSCONTAINEREV (111028, DCM, “Image Library”)1U11>>CONTAINSIMAGENo purpose of reference1-nM12>CONTAINSCONTAINEREV (newcode001, DCM, “Pre-coordinated Measurements”)1M13>>CONTAINSINCLUDEDTID (3QQ) Pre-coordinated Echo Measurement1-nU$Measurement = DCID (newcid0) Core Echo Measurements$Units = corresponding value from Units column of CID (newcid0)14>CONTAINSCONTAINEREV (newcode002, DCM, “Post-coordinated Measurements”)1M15>>CONTAINSINCLUDEDTID (3QZ) Post-coordinated Echo Measurement1-nUTBD>CONTAINSINCLUDEDTID (5204) Wall Motion Analysis1-nU$Procedure = DT (P5-B3121, SRT, "Echocardiography for Determining Ventricular Contraction")Content Item DescriptionsRow 8A 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.Row 13Multiple instances of the same measurement code may be present in the container. Each instance represents a different sample or derivation. This template makes no requirement that any or all samples be sent. For example, a mean value of all the samples of a given measurement could be sent without sending any or all of the samples from which the mean was calculated. Device configuration and/or operator interactions determine what measurements are sent.<<Can we include the 5202/5203 here (even if it is a one line version) to communicate the “symmetry”/compatibility with the “original template”>><<And where there are deviations communication the rationale, e.g. we don’t send the finding site because it is inherent in the pre-coordinated measurement code>>TID 3QQPre-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 3QZ 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 3QQ ParametersParameter NameParameter Usage$Measurement Coded term or Context Group for Concept Name of measurement$UnitsUnits of MeasurementTID 3QQ Pre-coordinated Echo Measurement Type: Non-ExtensibleOrder: InsignificantNLRelation with ParentValue TypeConcept NameVMReq TypeConditionValue Set Constraint1NUM$Measurement1MUnits = $Units2>HAS CONCEPT MODCODEEV (121401, DCM, “Derivation”) 1-nUDCID (newcid1) Echo Derivation3>INCLUDEDTID (320) Image or Spatial Coordinates<<WG6: Since we have some Echo 3D, do we need TID 322 to add SCOORD3D to TID 320? Or can we just add to 320 directly? Or has someone already done this?>><Duplicate in 3QZ>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 DescriptionsRow 2If Row 2 is not present, then the measurement is simply a sample.TID 3QZPost-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 3QQ Pre-coordinated Echo Measurement. It is intended to be used for User-defined and Vendor-defined Echo Measurements.TID 3QZPost-coordinated Echo Measurement Type: Non-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 Coordinates1-nU$Purpose = EV (121112, DCM, "Source of measurement”)4>INCLUDEDTID (321) Waveform or Temporal Coordinates1-nU$Purpose = EV (121112, DCM, "Source of measurement”)5>HAS CONCEPT MODCODEEV (G-C0E3, SRT, “Finding Site”)1MBCID (12236) Echo Anatomic6>HAS CONCEPT MODCODEEV (newcode003, DCM, “Finding Subject”)1MDCID (newcid2) Echo Finding Subjects7>HAS CONCEPT MODCODEEV (newcode004, DCM, “Measurement Type”)1MDCID (newcid3) Echo Measurement Types8>HAS CONCEPT MODCODEEV (newcode005, DCM, “Measured Property”)1MDCID (newcid4) Echo Measurement Properties9>HAS CONCEPT MODCODEEV (G-C036, SRT, “Measurement Method")1MCBCID (12227) Echocardiography Measurement Methods10>HAS ACQ CONTEXTCODEEV (G-0373, SRT, “Image Mode”)1MDCID (12224) Ultrasound Image Modes11>HAS ACQ CONTEXTCODEEV (111031, DCM, “Image View”)1MBCID (12226) Echocardiography Image View12>HAS CONCEPT MODCODEEV (R-4089A, SRT, “Cardiac Cycle Point”)1MCIFF the cardiac cycle point is significant for this measurement.DCID (12233) Cardiac Phase13>HAS CONCEPT MODCODEEV (G-C048, SRT, “Flow Direction”)1MCIFF the flow direction is significant for this measurement.DCID (12221) Flow Direction14>HAS CONCEPT MODCODEEV (R-40899, SRT, “Respiratory Cycle Point”)1MCIFF the respiratory cycle point is significant for this measurement.DCID (12234) Respiration StateEcho Measurement DescriptionsRow 1<< vendor values and user values would look similar except for Dictionary>> <<Intention is that vendors can send a consistent fully pre-coordinated (private) code here so that parsers can recognize post-coordinated measurements that have been previously analyzed/vetted/accepted/databased>><<Note that this depends on the vendor maintaining a stable list of these pre-coordinated codes it uses. What if the vendor doesn’t feel like doing that. Should we make it a UID? Or have a DICOM Code for “This measurement has no stable continuity. Parse the post-coordinated details but assume nothing beyond those.”?>>Row 5The finding site reflects the anatomical location where the measurement is taken, preferably coded using SNOMED to as fine detail as possible.Row 6The finding subject reflects the subject of the measurement. In many cases, for example Aortic Root Diameter, the subject is the structure of the finding site.In other cases, for example Mitral Valve Regurgitant Flow Peak Velocity, the finding site is the mitral valve, the finding subject is the Regurgitant Flow and the measured property is the Peak Velocity.Add the following CID’s to Part 16 Annex B:CID newcid1Measurement LabelsContext ID newcid1Measurement LabelsType: Extensible Version: yyyymmddCoding Scheme Designator(0008,0102)Code Value(0008,0100)Code Meaning (0008,0104)SRTG-A437Maximum – this sample was the maximumSRTR-404FBMinimum – this sample was the minimumDCM121411Most Recent Value – this sample was the most recentDCM121410User chosen value – this sample was chosen (as representative) by the user SRTR-00317Mean – this isn’t a sample, it’s the averageDCMPreferred – this is the single preferred value for this measurementCID newcid2Echo Finding SubjectsContext ID newcid2Echo Finding SubjectsType: Extensible Version: yyyymmddCoding Scheme Designator(0008,0102)Code Value(0008,0100)Code Meaning (0008,0104)DCMnewcode100Structure of the Finding SiteDCMnewcode101Behavior of the Finding SiteSRTR-42047Antegrade Flow (at the Finding Site)SRTG-0367Regurgitant Flow (at the Finding Site)CID newcid3Echo Measurement TypeContext ID newcid3Echo Measurement TypeType: Extensible Version: yyyymmddCoding Scheme Designator(0008,0102)Code Value(0008,0100)Code Meaning (0008,0104)DCMnewcode110DirectDCMnewcode111IndexedDCMnewcode112RatioDCMnewcode113FractionDCMnewcode114CalculatedCID newcid4Echo Measured PropertiesContext ID newcid4Echo Measured PropertiesType: Extensible Version: yyyymmddCoding Scheme Designator(0008,0102)Code Value(0008,0100)Code Meaning (0008,0104)LN20168-1Acceleration TimeLN59130-5Alias VelocitySRTG-A166AreaSRTF-32070Cardiac Ejection FractionSRTG-038ECardiovascular Orifice AreaLN20217-6Deceleration TimeSRTM-02550DiameterLN59120-6dP/dt by USDurationLN20222-6Ejection TimeLN59093-5Epicardial AreaLN59132-1Fractional ShorteningLN59084-4Isovolumic Contraction TimeLN59083-6Isovolumic Relaxation TimeLN20256-4Mean Gradient [Pressure] by DopplerLN20352-1Mean VelocityLN20247-3Peak Gradient [Pressure] by US.calculatedLN34141-2Peak Instantaneous Flow RatePeak PressureLN11726-7Peak VelocityPISA RadiusLN59085-1Pre-Ejection PeriodPressureLN20280-4Pressure Half Time by US.calculatedSRTG-0390Regurgitation FractionLN59090-1ROI Internal Dimension by USLN59089-3ROI Thickness by USSRTF-32120Stroke VolumeLN12144-2Systolic to Diastolic Velocity RatioSRTF-02692Vascular ResistanceVelocityLN20354-7Velocity Time IntegralVena Contracta WidthSRTG-D705VolumeLN33878-0Volume FlowDCM122447Wall MassCID newcid0Core Echo Measurements Context ID newcid0Core Echo MeasurementsType: Non-Extensible Version: yyyymmddCoding Scheme Designator(0008,0102)Code Value(0008,0100)Code Meaning (0008,0104)UnitsLN18016-6Aortic Valve Annulus Diameter(cm, UCUM, “centimeter”)LN18169-3Aortic Valve Velocity-Time Integral(cm, UCUM, “centimeter”)LN11706-9Aortic Valve Peak Systolic Flow(m/s, UCUM, “meter per second”)LNLNLN29431-4Interventricular Septum Thickness Diastole by US.M-mode(cm, UCUM, “centimeter”)LN29433-0Interventricular Septum Thickness Systole by US.M-mode(cm, UCUM, “centimeter”)LN29436-3Left ventricular Internal Diameter Minor Axis Diastole(cm, UCUM, “centimeter”)LN29438-9Left Ventricle Internal Systolic Dimension(cm, UCUM, “centimeter”)Modify the following CID’s in Part 16 Annex B:CID 12233Cardiac PhaseContext ID 12233Cardiac PhaseType: Extensible Version: 20100317Coding Scheme Designator(0008,0102)Code Value(0008,0100)Code Meaning (0008,0104)SRTF-32020SystoleSRTF-32010DiastoleSRTF-32011End DiastoleSRTR-FAB5BEnd SystoleSRTR-40B1BEarly DiastoleSRTF-32021Peak SystolicSRTF-32030Atrial SystoleSRTF-32040Ventricular SystoleSRTR-40B12Ventricular Isovolumic ContractionSRTR-40B11Ventricular EjectionSRTR-40B10Ventricular Isovolumic RelaxationSRTR-40B1CDiastolic Rapid InflowSRTR-40B21DiastasisFull Cardiac CycleLeft Atrial A-waveAdd 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…newcode001Pre-coordinated MeasurementsMeasurements that are described by a single pre-coordinated code.newcode002Post-coordinated MeasurementsMeasurements that are described by a collection of (generally atomic) post-coordinated codes.newcode004Measurement Typenewcode005Measured Propertynewcode100Structure of the Finding SiteThe subject of a measurement is the physical structure of the Finding Site, such as the mass or diameter.newcode101Behavior of the Finding SiteThe subject of a measurement is the behavior of the Finding Site, such as the velocity or duration of motion.newcode110Directnewcode111Indexednewcode112Rationewcode113Fractionnewcode114Calculated Fully pre-coordinated terms:Definition Template:The <attribute> in <units> of the <structure/characteristic> measured/calculated at/during <time/phase> in <mode/view> 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. Preference is to leave units out of the definition and to tie them down in the TID (or CID if we can do that).May also talk to Daniel Vreeman – LOINC will provide their atomic elements in a spreadsheet. Download it.Aortic Valve Annulus DiameterThe diameter in cm of the Aortic Valve Annulus measured at End Systole in 2D mode. 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 during Systole in Doppler mode. 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 during Systole in Doppler mode. 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 during Systole in Doppler mode. 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 during Systole in Doppler mode using the Simplified Bernoulli method. Aortic Valve Mean GradientThe Mean Pressure Gradient in mmHg across the Aortic Valve measured during Systole in Doppler mode using the Simplified Bernoulli method. Aortic Valve Regurgitant Flow VTIThe Velocity Time Integral in cm of the Aortic Valve Regurgitant Flow measured during Diastole in Doppler mode. 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 during Diastole in Doppler mode 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 during Diastole (?) in Doppler mode. 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 during Diastole in Doppler mode 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 during Systole in pulsed Doppler mode. 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 during Atrial Systole in pulsed Doppler mode. 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 during Atrial Systole in pulsed Doppler mode, and the duration of the Mitral Valve Flow measured during Atrial Systole in pulsed Doppler mode. 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.Use Case X: Identifying matching different non-standard measurement codes from different vendorsAlso consider if they use the same measurement code, but different modifiers. (Could happen if the LN code is not fully pre-coordinated). Maybe we should mandate that you have to use unique precoordinated codes unless the LOINC is fully pre-coordinated.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).X1 = 3.2X2 = 3.1 (location a)X3 = 3.3X4 = 3.1 (location b)3.23.13.33.13.3 – Max3.18 – Mean3.1 – Most Recent3.2 – Sample3.1 – Sample3.3 – Sample, Max3.1 – Sample, Most Recent3.18 - Mean3.2 – Sample3.1 – Sample3.3 – Sample3.1 - Sample3.18 – Mean3.3 – Max3.1 – Most Recent ................
................

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

Google Online Preview   Download