Table of Contents
List of Figures
List of Tables
The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.
NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.
NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.
In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.
NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.
This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.
The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].
PS3.1 should be used as the base reference for the current parts of this Standard.
DICOM® is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information, all rights reserved.
HL7® and CDA® are the registered trademarks of Health Level Seven International, all rights reserved.
SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of SNOMED International, all rights reserved.
LOINC® is the registered trademark of Regenstrief Institute, Inc, all rights reserved.
This Part of the DICOM Standard specifies the DICOM Content Mapping Resource (DCMR), which defines the Templates and Context Groups used elsewhere in the Standard.
The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.
[Alderman 1992] Coronary Artery Disease. 1992. 12. 1189-208. “The angiographic definitions of the bypass angioplasty revascularization investigation”. http://journals.lww.com/coronary-artery/Abstract/1992/12000/The_angiographie_definitions_of_the_Bypass.12.aspx .
[ASTM E 1762-04] . Standard Guide for Electronic Authentication of Health Care Information, ASTM International.
[ASTM E 2084-00] . Standard Specification for Authentication of Healthcare Information Using Digital Signatures, ASTM International.
[AAPM Report 204] 2011. Size-Specific Dose Estimates (SSDE) in Pediatric and Adult Body CT Examinations. http://www.aapm.org/pubs/reports/RPT_204.pdf .
[AAPM Report 220] September 2014. Report of AAPM Task Group 220 - Use of Water Equivalent Diameter for Calculating Patient Size and Size-Specific Dose Estimates (SSDE) in CT. http://www.aapm.org/pubs/reports/rpt_220.pdf .
[AAPM OR 03] 2005. Assessment of Display Performance for Medical Imaging Systems. http://www.aapm.org/pubs/reports/OR_03.pdf .
[DIN 6868-57] 2001. Image quality assurance in diagnostic X-ray departments - Acceptance testing for image display devices.
[ETDRS Report Number 10] . Report Number 10, Grading Diabetic Retinopathy from Stereoscopic Color Fundus Photographs- An Extension of the Modified Airlie House Classification. Ophthalmology, May 1991, vol98 (p786-805), Supplement.
[Feuvret] International Journal of Radiation Oncology, Biology, Physics. 2006. 2. 333-342. “Conformity index: a review”. http://dx.doi.org/10.1016/j.ijrobp.2005.09.028 .
[IBSI Features] >arXiv. 17 Sep 2018. “Image biomarker standardisation initiative - Reference manual”. http://arxiv.org/abs/1612.07003 .
[IEC 60601-2-44] . Medical Electrical Equipment - Part 2-44: Particular Requirements for the Safety of X-Ray Equipment for Computed Tomography.
[IEC 62563-1] 2009. Ed 1.0. Medical Electrical Equipment - Medical image display systems - Part 1: Evaluation methods.
[ISO/IEC Directives, Part 2] 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .
[ISO 639-3] 2007. Codes for the representation of names of languages — Part 3: Alpha-3 code for comprehensive coverage of languages.
[ISO 8824-1] 2015. Information Technology - Abstract Syntax 1 (ASN.1): Specification of Basic Notation.
[ISO 9834-1] 2012. Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree.
[JJ1017] October 5, 2005. 3.0. Guidelines for HIS, RIS, PACS - Modality Data Communication on Scheduling, Billing, and Examination Records. http://www.jira-net.or.jp/commission/system/04_information/files/JJ1017VER3_20051005.doc .
[NEMA XR 25-2010] 2010. Computed Tomography Dose Check Standard. http://www.nema.org/stds/xr25.cfm .
[RadLex] 2006. A Lexicon for Uniform Indexing and Retrieval of Radiology Information Resources. http://www.radlex.org/ .
[RFC 3881] September 2004. Security Audit and Access Accountability Message - XML Data Definitions for Healthcare Applications.
[Scanlon 1999] Journal of the American College of Cardiology. May 1999. 6. 1756-824. “ACC/AHA guidelines for coronary angiography - A report of the American College of Cardiology/American Heart Association Task Force on Practice Guidelines (Committee on Coronary Angiography) developed in collaboration with the Society for Cardiac Angiography and Interventions”. doi:10.1016/S0735-1097(99)00126-6 http://www.sciencedirect.com/science/article/pii/S0735109799001266 .
[SMPTE RP133] 1991. Specifications for Medical Diagnostic Imaging Test Pattern for Television Monitors and Hard-copy Recording Cameras.
[Stout et al 2013] Molecular Imaging. 2013. 7. 1-15. “Guidance for Methods Descriptions Used in Preclinical Imaging Papers”. http://journals.sagepub.com/doi/pdf/10.2310/7290.2013.00055 .
A portion of the terminology used within the Mammography CAD SR SOP Class and the Breast Imaging Report and Relevant Patient Information for Breast Imaging Templates is derived from BI-RADS®, a copyrighted lexicon of breast imaging terminology and nomenclature licensed by DICOM from the American College of Radiology.
[BI-RADS®] 1998. 3.0. Breast Imaging Reporting and Data System Atlas. http://www.acr.org/Quality-Safety/Resources/BIRADS .
References to MQCM 1999 are made in the description of the Mammography CAD SR SOP Class. In this MQCM 1999 refers to the Mammography Quality Control Manual 1999, available from the American College of Radiology. This document describes a standardized approach to mammographic acquisition standards, patient positioning, and so on. The DICOM Standard does not require Mammography CAD SR SOP Class implementations to adhere to MQCM 1999.
[MQCM] 1999. Mammography Quality Control Manual. http://www.acr.org/Education/Education-Catalog/Products/639 .
References to MQSA are made in the description of the Mammography CAD SR SOP Class. In this MQSA refers to the Mammography Quality Standards Act final rules. While MQSA is a federal regulation of the United States government, it provides the only widely published standards for mammographic quality and is incorporated in this document for that reason. The DICOM Standard does not require Mammography CAD SR SOP Class implementations to adhere to MQSA.
[MQSA] 2002. Mammography Quality Standards Act Regulations. http://www.fda.gov/Radiation-EmittingProducts/MammographyQualityStandardsActandProgram/Regulations/ucm110906.htm .
[ACR Position Statement] 2001. Quality Control and Improvement, Safety, Infection Control, and Patient Education. http://www.acr.org/Quality-Safety/Radiology-Safety .
References are made in the description of the Chest CAD SR Templates and context groups.
[Fraser and Pare] 1999. 4th. xvii-xxxi. Diagnosis of Diseases of the Chest. Terms Used in Chest Radiology.
[Fraser and Pare] 1999. 4th. xxxiii-xxxvi. Diagnosis of Diseases of the Chest. Terms for CT of the Lungs.
[ACR CT PE] 2001. 109-113. ACR Standards. ACR Standard for the Performance of Computed Tomography for the Detection of Pulmonary Embolism in Adults.
[ACR HR CT] 2001. 115-118. ACR Standards. ACR Standard for the Performance of High-Resolution Computed Tomography (HRCT) of the Lungs in Adults.
References to Response Evaluation Criteria are made from the Chest CAD SR Templates and context groups
[RECIST] Journal of the National Cancer Institute. February 2, 2000. 3. 205-216. “New Guidelines to Evaluate the Response to Treatment in Solid Tumors”. http://www.eortc.be/recist/ .
[WHO] 1979. WHO Handbook for Reporting Results for Cancer Treatment. WHO Offset Publication No. 48. http://whqlibdoc.who.int/publications/9241700483.pdf .
[Cerqueira 2002] Circulation. 2002. 4. 539. “AHA Scientific Statement: Standardized Myocardial Segmentation and Nomenclature for Tomographic Imaging of the Heart”. doi:10.1161/hc0402.102975
[Sheehan, 1986] Circulation. 1986. 2. 293-305. “Advantages and applications of the centerline method for characterizing regional ventricular function”. doi:10.1161/01.CIR.74.2.293
[Slager, 1986] J Am Coll Cardiol.. 1986. 2. 317-26. “Quantitative assessment of regional left ventricular motion using endocardial landmarks”. doi:10.1016/S0735-1097(86)80498-3
[Kennedy, 1970] Am Heart J. 1970. 3. 343. “Left ventricular volume and mass from single-plane cineangiocardiogram. A comparison of anteroposterior and right anterior oblique methods”.
[Dodge, 1960] Am Heart J. 1960. 5. 762. “The use of biplane angiocardiography for the measurement of left ventricular volume in man”. http://www.sciencedirect.com/science/article/pii/0002870360903598 .
[Wynne, 1978] Am J Cardiol. 1978. 4. 726. “Estimation of left ventricular volumes in man from biplane cineangiograms filmed in oblique projections”.
[Boak, 1977] Cathet Cardiovasc Diagn. 1977. 3. 217-30. “A geometric basis for calculation of right ventricular volume in man”. doi:10.1002/ccd.1810030305
[Ferlinz, 1977] Am Heart J. 1977. 1. 87-90. “Measurements of right ventricular volumes in man from single plane cineangiograms. A comparison to the biplane approach”. http://www.sciencedirect.com/science/article/pii/S0002870377803487 .
[Graham, 1973] Circulation. 1973. 1. 144-53. “Right ventricular volume determinations in children. Normal values and observations with volume or pressure overload”. doi:10.1161/01.CIR.47.1.144
[Arcilla, 1971] Chest. 1971. 5. 446. “Angiographic method for volume estimation of right and left ventricles”. doi:10.1378/chest.60.5.446
[Mintz, 2001] Journal of the American College of Cardiology. 2001. 5. 1478-1492. “American College of Cardiology Clinical Expert Consensus Document on Standards for Acquisition, Measurement and Reporting of Intravascular Ultrasound Studies (IVUS)”. doi:10.1016/S0735-1097(01)01175-5
[Di Mario, 1998] European Heart Journal. 1998. 2. 207-229. “Clinical Application and Image Interpretation in Intravascular Ultrasound”. doi:10.1053/euhj.1996.0433
[Zalis, 2005] Radiology. 2005. 1. 3-9. “CT Colonography Reporting and Data System: A Consensus Proposal”. doi:10.1148/radiol.2361041926
[Eggli, 1998] J Bone Joint Surg Br. 1998. 3. 382-390. “The value of preoperative planning for total hip arthroplasty”. http://www.bjj.boneandjoint.org.uk/content/80-B/3/382 .
[LOINC] 2014. Logical Observation Identifier Names and Codes. http://loinc.org/ .
This product includes all or a portion of the LOINC® table, LOINC panels and forms file, LOINC document ontology file, and/or LOINC hierarchies file, or is derived from one or more of the foregoing, subject to a license from Regenstrief Institute, Inc. Your use of the LOINC table, LOINC codes, LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file also is subject to this license, a copy of which is available at http://loinc.org/terms-of-use. The current complete LOINC table, LOINC Users' Guide, LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file are available for download at http://loinc.org/. The LOINC table and LOINC codes are copyright © 1995-2014, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee. The LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies file are copyright © 1995-2014, Regenstrief Institute, Inc. All rights reserved.
The LOINC table (in all formats), LOINC panels and forms file, LOINC document ontology file, and LOINC hierarchies are provided "as is." Any express or implied warranties are disclaimed, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
A small portion of the LOINC table may include content (e.g., survey instruments) that is subject to copyrights owned by third parties. Such content has been mapped to LOINC terms under applicable copyright and terms of use. Notice of such third party copyright and license terms would need to be included if such content is included.
[UCUM] 2013. Unified Code for Units of Measure. http://unitsofmeasure.org/ .
This product includes all or a portion of the UCUM table, UCUM codes, and UCUM definitions or is derived from it, subject to a license from Regenstrief Institute, Inc. and The UCUM Organization. Your use of the UCUM table, UCUM codes, UCUM definitions also is subject to this license, a copy of which is available at http://unitsofmeasure.org/. The current complete UCUM table, UCUM Specification are available for download at http://unitsofmeasure.org/. The UCUM table and UCUM codes are copyright © 1995-2013, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved.
The UCUM table (in all formats), UCUM definitions, and specification are provided "as is." Any express or implied warranties are disclaimed, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
[AQI Schema] 2015/07/30. Anesthesia Quality Institute Schema. http://www.aqihq.org/aqischdoc/default.html .
Used by permission of the Anesthesia Quality Institute (AQI) (http://www.aqihq.org/), established by the American Society of Anesthesiologists (ASA).
Extracts of ISO/IEEE 11073 reprinted by permission of IEEE, 3 Park Avenue, New York, NY 10016-5997 USA. Copyright by IEEE. http://standards.ieee.org/.
Under license from IEEE, the term codes and descriptions of the ISO/IEEE 11073 Nomenclature are available at no cost through the Rosetta Terminology Mapping Management System of the U.S. National Institute of Standards and Technology. http://rtmms.nist.gov/rtmms/index.htm
[ISO/IEEE 11073-10101] 2004. . Health informatics - Point-of-care medical device communication - Nomenclature.
This DICOM Standard incorporates SNOMED CT®, used by permission of SNOMED International. SNOMED CT®, was originally created by The College of American Pathologists (CAP). SNOMED International was formerly known as the International Health Terminology Standards Development Organisation (IHTSDO).
The SNOMED CT terms used in this Standard (the SNOMED CT DICOM Subset) are the subject of a licensing agreement between NEMA and SNOMED International that allows the use of this defined subset in DICOM conformant applications without further license or payment of fee. Any use of SNOMED CT beyond the terms published in the DICOM Standard is subject to SNOMED CT licensing rules, which may include a fee. For further information about SNOMED CT licensing, go to http://www.snomed.org/snomed-ct/get-snomed or contact SNOMED International at info@snomed.org.
This DICOM Standard incorporates various veterinary terms from the SNOMED CT VetSCT extension, used by permission of the Veterinary Terminology Services Laboratory (VTSL) (http://vtsl.vetmed.vt.edu/). These terms were previously included in SNOMED CT but have since been inactivated as moved elsewhere.
The Prostate Imaging and Report and Data System Version 2 (PI-RADS v2) is a joint effort of the European Society of Urogenital Radiology, the American College of Radiology and the AdMetech Foundation.
[PI-RADS v2] Eur Urol. 2016/01. 1. 16-40. “PI-RADS Prostate Imaging - Reporting and Data System: 2015, Version 2”. doi:10.1016/j.eururo.2015.08.052 http://www.europeanurology.com/article/S0302-2838%2815%2900848-9/ .
PI-RADS is also available from the following sources:
American College of Radiology: http://www.acr.org/~/media/ACR/Documents/PDF/QualitySafety/Resources/PIRADS/PIRADS%20V2.pdf
[Prostate Eu Concensus] Eur Urol. 2011. 4. 477-94. “Magnetic resonance imaging for the detection, localisation, and characterisation of prostate cancer: recommendations from a European consensus meeting”. doi:10.1016/j.eururo.2010.12.009 http://www.europeanurology.com/article/S0302-2838(10)01187-5/ .
[ESUR Guidelines] Eur Radiol. 2012/04. 4. 746-57. “ESUR prostate MR guidelines 2012”. doi:10.1007/s00330-011-2377-y http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3297750/ .
For the purposes of this Standard the following definitions apply.
The following definitions are commonly used in this Part of the DICOM Standard:
Identifier that specifies the suggested Context Group for a Code Sequence Attribute.
See Table 5.6-1 “Conventions for Specification of Context Groups” in PS3.3 .
Identifier that specifies a Template suggested to be used in the creation of a set of Content Items.
Dictionary (lexicons) of concepts (terms) with assigned codes and well defined meanings.
A set of coded concepts defined by a Mapping Resource forming a set appropriate to use in a particular context.
Identifier that specifies the Context Group for a Code Sequence Attribute that shall be used.
See Table 5.6-1 “Conventions for Specification of Context Groups” in PS3.3 .
Identifier that specifies a Template that shall be used in the creation of a set of Content Items.
A Mapping Resource that defines Templates and Context Groups for use in DICOM IODs.
Context Group that may be extended by a particular application by inclusion of additional concepts.
See Table 5.6-1 “Conventions for Specification of Context Groups” in PS3.3 .
A Template that may be extended by a particular application by inclusion of additional Content Items beyond those specified in the Template.
A resource that defines context-dependent usage constraints (i.e., Value Set or Relationship Type restrictions) for Attributes. A resource that specifies the mapping of the content of an external controlled terminology to the components of a message standard.
Context Group whose defined set of concepts shall not be extended by an application.
See Table 5.6-1 “Conventions for Specification of Context Groups” in PS3.3 .
A Template that specifies the exact set of Content Items and corresponding Value Sets that shall be used and that shall not be extended by an application.
The association between two Concepts. Examples: "HAS PROPERTIES", "CONTAINS", "INFERRED FROM".
A Template whose first content item is a CONTAINER content item intended to be encoded in the top level Data Set of a SOP Instance. I.e., the "root node" of the "content tree".
A pattern that describes the Content Items, Value Types, Relationship Types and Value Sets that may be used in part of a Structured Report content tree, or in other Content Item constructs, such as Acquisition Context or Protocol Context. Analogous to a Module of an Information Object Definition.
The allowed values of a Code Sequence Attribute in a given context. Specified either as one or more individual values or by reference to a Context Group.
This Part of the Standard makes use of the following terms defined in PS3.3:
A substance administered to improve the imaging of specific organs, tissues, diseases and physiological functions. Adapted from Wikipedia http://en.wikipedia.org/wiki/Imaging_agent.
This Part of the Standard makes use of the following terms defined in PS3.1:
This Part of the Standard makes use of the following terms defined in PS3.4:
The following symbols and abbreviations are used in this Part of the Standard.
Computer-Aided Detection and/or Computer-Aided Diagnosis for Mammography
Computer-Aided Detection and/or Computer-Aided Diagnosis for chest radiography
Computer-Aided Detection and/or Computer-Aided Diagnosis for colon radiography
The following upper-case abbreviations represent specific Attributes:
Terms listed in Section 3 are capitalized throughout the document.
Templates are patterns that specify the Concept Names, Requirements, Conditions, Value Types, Value Multiplicity, Value Set restrictions, Relationship Types and other attributes of Content Items for a particular application.
An IOD may specify that particular Standard Templates shall be used or may be used to define or constrain the content of a Content Item construct. A Content Item construct includes a coded concept name and one of several types of coded values. Content Item constructs are used in:
the main Data Set and recursively nested Content Sequences (0040,A730) of the SR Document Content Module
the Acquisition Context Sequence(0040,0555) of the Acquisition Context Module,
the Protocol Context Sequence (0040,0440) and Content Item Modifier Sequence (0040,0441) of the Scheduled Procedure Step Module, Image Acquisition Results Module, and others.
the Specimen Preparation Step Content Item Sequence (0040,0612) of the Specimen Module.
Annexes A and C of this Part define Standard Templates.
Standard Extended and Private Templates may be defined by implementers of the Standard. The rules for definition of Standard Extended and Private SR Templates are similar to the rules for definition of Standard Extended and Private SOP Classes. One row of a Template definition table corresponds to one row of a Module table.
Each Standard Template is specified by a Template table in this Part. Each Template table specifies exactly one Template, corresponding to a pattern of content within a Content Item construct.
Each Template table identifies whether the order of Content Items is significant or not significant. SOP Instances whose content is based on a Template where the order is significant shall encode the top level Content Items in the order they are specified in the Template, and the subsidiary Content Items under each parent item in the order they are specified, and so on for each Nesting Level. The significance of the order applies only to the Template itself; subsidiary included Templates may have a different order significance.
Even if a Template specifies that the order is not significant, there may be significance to the order in which Content Items are encoded in a SOP Instance. For example, CONTAINER Content Items with attribute Continuity of Content (0040,A050) value CONTINUOUS encode Content Items in narrative sequence, and procedure logs encode Content Items in time order.
The Content Items from subsidiary Templates may be intermingled if and only if the parent and subsidiary all specify that the order is not significant. This permits later refactoring into reusable Templates.
The range of concepts and the options that are permitted in a family of SR Documents vary inversely with the level of constraint that is applied by the corresponding SR Template. The more narrow the range of concepts and the more restricted the options permitted by a Template, the more predictable the content of the SR Documents will be.
A very specific Template defines a family of SR Documents that are very similar to each other. They have a narrow range of content options (e.g., high level of constraint of Content Item values; use of CODE or NUM with Enumerated Context Groups) and their content is therefore highly predictable. A very general (e.g., permissive or broad) Template defines a family of SR Documents that may differ considerably from one another. They have a broader range of content options (e.g., low level of constraint of Content Item values; use of TEXT and relatively little restriction of Content Item values) and their content is less predictable.
The degree of interoperability that may be achieved with a family of SR Documents generated from a Template may be determined intentionally and precisely at a desired level by appropriate Template design to achieve the necessary degree of predictability of SR Document contents.
SR Templates are described using tables of the following form:
Acquisition Context Templates are described using tables of the following form:
Protocol Context Templates are described using tables of the following form:
The semantics of the fields (columns) of Template tables are defined by subsections of this Section. A row of a Template table specifies either one Content Item or inclusion of another Template that may specify any number of Content Items (see Section 6.2.3 for definition of Included Templates). Each Template table is named by a title, identified by a TID number and further explained by a description such as explanation of Template contents, purpose and use cases.
The following conventions are defined for the form of references to coded concepts, Context Groups and Templates.
Code Meanings are enclosed in quotation marks (for example "cm"). Code Values and Coding Scheme Designators are not enclosed in quotation marks unless a comma occurs in the string.
References to coded concepts take the following form:
If reference to a specific coding scheme version is required, it takes the following form:
References to Context Groups take the following form:
References to Templates take the following form:
Each row of a Template Table is denoted by a row number. The first row is numbered 1 and subsequent rows are numbered in ascending order with increments of 1. This number denotes a row for convenient description as well as reference in conditions. The Row Number of a Content Item in a Template may or may not be the same as the ordinal position of the corresponding Sequence Item (representing the Content Item) in a Content Sequence (0040,A730), depending on the number of times the Content Item is repeated.
The Content Item specified in the first row of a Template table may be of any Value Type. Specifically, it is not constrained to be a CONTAINER.
The nesting level of Content Items is denoted by ">" symbols, one per level of nesting below the initial Source Content Item (of the Template) in a manner similar to the depiction of nested Sequences of Items in Modules Tables in PS3.3. When it is necessary to specify the Target Content Item(s) of a relationship, they are specified in the row(s) immediately following the corresponding Source Content Item. The Nesting Level of a Target Content Item is one greater than the Nesting Level of the corresponding (parent) Source Content Item. The Content Item specified in row 1 of a Template Table is at the top level (i.e., no ">" symbol is ever present in the NL field for the first Content Item in the table).
Acquisition Context Templates have no Nesting Level field. Protocol Context and UPS Processing Parameter Templates allow a single Nesting Level implemented through the Content Item Modifier Sequence (see PS3.3).
Relationship Type and Relationship Mode (i.e., By-value or By-reference) constraints, if defined, are specified in this field, as described Table 6.1.3-1.
Relationship Type and Mode are specified for each row that specifies a target Content Item.
Relationship Type and Mode may also be specified when another Template is included, either "top-down" or "bottom-up" or both (i.e., in the "INCLUDE Template" row of the calling Template, or in all rows of the included Template, or in both places). There shall be no conflict between the Relationship Type and Mode of a row that includes another Template and the Relationship Type and Mode of the rows of the included Template.
SR IODs specify Enumerated Values for Relationship Types. If a Relationship Type other than one of the Defined Terms for Relationship Type (0040,A010) is specified in a Private SOP Class, there is a significant risk to interoperability. Documentation accompanying Templates for Private SOP Classes should define any Relationship-type extensions in the manner that the Standard Relationship Types are defined in PS3.3.
Acquisition Context and Protocol Context Templates have no Relationship field.
The Value Type field specifies the SR Value Type of the Content Item or conveys the word "INCLUDE" to indicate that another Template is to be included (substituted for the row). See Section 6.2.3 for further description of "Included Templates".
Any constraints on the Concept Name are specified in the Concept Name field as defined or enumerated coded entries, or as baseline or defined context groups. Alternatively, when the VT field is "INCLUDE", the Concept Name field specifies the Template to be included.
The absence of an entry in the Concept Name field means that any code may be used, from any coding scheme, including codes from private coding schemes.
The VM field indicates the number of times that either a Content Item of the specified pattern or an included Template may appear in this position. Table 6.1.6-1 specifies the values that are permitted in this field.
Table 6.1.6-1. Permitted Values for VM
The Requirement Type field specifies the requirements on the presence or absence of the Content Item or included Template.
There is typically no need to specify Requirement Type separately for SCU and SCP of the Basic SR SOP Classes, because the SCP is required to support the entire content of any SR Document it receives. Therefore, for Basic SR SOP Classes, Requirement Type effectively only applies to the SCU.
The following symbols are used:
The Condition field specifies any conditions upon which presence or absence of the Content Item or its values depends. This field specifies any Concept Name(s) or Values upon which there are dependencies.
References in Condition statements to coded concepts or values, whether to select a Content Item to test or to specify a value to test against, are of the form (CV, CSD, "CM"). As is always the case for coded entries, the matching is performed against CV and CSD, irrespective of the string value of CM.
References may also be made to row numbers (e.g., to specify exclusive OR conditions that span multiple rows of a Template table).
The following abbreviations are used:
Any constraints on the Value Set for a CODE Content Item are specified in this field as defined or enumerated coded entries, or as baseline or defined context groups.
The absence of an entry in the Value Set Constraint field for a CODE Content Item means that any code may be used, from any coding scheme, including codes from private coding schemes.
The Value Set Constraint column may specify a default value for the Content Item if the Content Item is not present, either as a fixed value, or by reference to another Content Item, or by reference to an Attribute from the Data Set other than within the Content Sequence (0040,A730).
Any constraints on units of measurement are specified in the Value Set Constraint field if and only if the Value Type is NUM. The constraints are specified either as defined or enumerated coded entries, or as baseline or defined context groups.
The absence of any constraint on units of measurement means that any code for units may be used, from any coding scheme, including codes from private coding schemes.
The value of the Continuity of Content Flag (0040,A050) may be specified in the Value Set Constraint field if and only if the Value Type is CONTAINER.
When a Content Item may have different value sets, each depending on different conditions, the description of each different case begins in a separate row of the Template Table.
When it is necessary to specify the Target Content Item(s) of a relationship, they are specified in the row(s) immediately following the Source Content Item. The Nesting level of a Target Content Item (or set of Target Content Items specified indirectly via an 'include Template' macro) is one greater than the Nesting Level of the corresponding Source Content Item, as indicated by an increase in the number of ">" characters in the nesting level.
When a Content Item may be the Source of multiple relationships having different Relationship Types and/or different Relationship Modes and/or different patterns of Target Content Item(s), the description of each different case begins in a separate row of the Template Table.
When the Source Content Item of a relationship has VM of greater than 1, the specified pattern of Target Content Items applies to all instantiations of the Source Content Item.
For example, if a Template specifies that the VM of a Source Content Item is 1-n and specifies a By-value relationship to two CODE Content Items with particular value set constraints, then each instantiation of the Source Content Item has a By-value relationship to two CODE Content Items with the specified value constraints.
When a Source Content Item that has a Requirement Type of U, UC or MC is not present (is not instantiated), no Target Content Items of that Source Content Item are present, even if one or more of the Target Content Items is designated with a Requirement Type of M or MC.
A Template may specify another Template to be included by specifying "INCLUDE" in the Value Type field and the identifier of the included Template in the Concept Name field. All of the rows of the specified Template are in included in the invoking Template, effectively substituting the specified Template for the row where the inclusion is invoked. Whether or not the inclusion is user optional, mandatory or conditional is specified in the Requirement and Condition fields. The number of times the included Template may be repeated is specified in the VM field.
A Template that is included by another Template may include parameters that are replaced by values defined in the invoking Template. Parameters may be used to specify coded concepts or Context Groups in the Concept Name, Condition, or Value Set Constraint fields of a Template.
An included Template that accepts parameters shall be introduced by a table listing those parameters of the form:
Parameters are indicated by a name beginning with the character "$".
The invoking Template may specify the value of the parameters in the included Template by name in the Value Set Constraint field of the INCLUDE row. The parameter in the included Template shall be replaced by the specified parameter value. Specification of a parameter value shall be of one of the following forms:
The specification of a parameter value is valid only for the directly included Template. Therefore, it needs to be explicitly respecified in Templates intermediate between the originally specifying Template and the target Template. The intermediate Template may use the same parameter name as used by the Template it invokes; in such a case, the intermediate Template would invoke the subsidiary Template with a specification in the Value Set Constraint field such as:
$parametername = $parametername
In this case, the left hand instance of $parametername is the name in the subsidiary Template, and the right hand instance is the (parametrized) value passed into the current Template.
The invoking Template is not required to specify all parameters of included Templates. If not specified, the value set (term or context group) for that parameter is unconstrained. An unconstrained value in a Condition will cause the condition to fail.
Though it may not be explicitly shown in a particular Template, the use of any coded Concept Name in any Content Item may be defined in a post-coordinated rather than pre-coordinated manner, unless explicitly forbidden by the IOD or the Template.
Accordingly, any such Content Item may have any number of Target Content Items via a "HAS CONCEPT MOD" relationship, even if not explicitly specified in a Template. Each Target Content Item of such a relationship may be more complicated than a single Content Item if the IOD permits (i.e., the post-coordinated concept may potentially be defined by a complex sub-tree).
An Extensible Template may be extended in an Application generating SOP Instances to include additional Content Items in its definition. Such Content Items shall not duplicate concepts for which an encoding is defined in the Template. I.e., if a method is provided for the encoding of a concept in the Template, that concept shall not be encoded using a different Content Item in an extension to the Template.
There is no requirement that the included additional Content Items in a Template extension be placed at the end of the Template. The additional Content Items may be included at any semantically appropriate location in the Template, regardless of whether the order of Content Items in the Template is significant.
A Non-extensible Template shall not be modified in an Application by the addition of Content Items to its definition.
The set of Content Items in either an Extensible or a Non-extensible Template may be changed in subsequent editions of the Standard, in accordance with the procedures of the DICOM Standards Committee.
A Non-Extensible Template may include a Template that is Extensible. In invoking such a Template, the content structure of SOP Instances created from the Non-Extensible Template may vary according to the varying content structure allowed by the extension of the included Template.
Context Groups specify Value Set restrictions for Code Value (0008,0100) (or Long Code Value (0008,0119) or URN Code Value (0008,0120)) and Code Meaning (0008,0104) of Code Sequence Attributes for given functional or operational contexts. This Section specifies the semantics of DCMR Context Group Tables.
Context Groups are described using tables of the following form (optional columns are shown with italic column titles):
A row of a Context Group table specifies one coded concept. Each Context Group table is named by a title and identified by a CID number and version.
The columns of the tables consist of:
In those cases where it is necessary, Coding Scheme Version (the value of Coding Scheme Version (0008,0103)) may also be specified. This column may be absent if Coding Scheme Version is not required for any of the coded concepts in the Context Group.
The value specified in the Code Meaning field is an acceptable value for the specified code value, but does not preclude the use of other synonymous text in the same or other language.
If further description of the concept represented by the code is required in the DCMR (rather than referring to an external coding scheme), it is included in a separate table.
Optional columns may provide an informative mapping from the coded concepts of the Context Group to a reference terminology specified in the column heading. Typical reference terminologies include SNOMED CT and UMLS.
An optional column may provide a normative baseline or defined set of units to use for numeric measurements using the concept, either as a single term (e.g., DT ({ratio}, UCUM, "ratio")), a list of such terms, or a reference to a Context Group (e.g., DCID 7277 "Units of Diffusion Rate Area Over Time").
A Context Group may alternatively be defined by narrative reference to an externally defined coding scheme.
See for instance CID 82 “Units of Measurement”.
The 'Include Context Group' macro is a concise mechanism for including (by-reference) all of the rows of a specified Context Group in the invoking Context Group, effectively substituting the specified Context Group for the row where the macro is invoked. If an 'Include Context Group' is specified, it shall be specified in the Concept Name column of a Context Group Table. Table 7.2.1-1 specifies the syntax of the 'Include Context Group macro. Inclusion may be nested, in that included Context Groups may themselves include other Context Groups. This gives rise to the possibility of circular inclusion and multiple inclusion, in which case the Context Group shall consist of the transitive closure of the set of all coded concepts within the included Context Groups.
For example, it is reasonable to have the following definitions for context groups:
The contents of Context ID 1 will be a, b, c, e, f, g, h, i.
Context Group 82 is defined to include all units of measurement relevant to DICOM IODs. In the past it was envisaged that an extensible list of pre-coordinated codes would be included in the mapping resource.
DICOM has now adopted the Unified Codes for Units of Measurement (UCUM) standard for all units of measurement. This coding scheme allows for the "construction" of pre-coordinated codes from atomic components.
The specialization of the UCUM standard as it is used in DICOM involves the following rules:
the version of UCUM from which a code is constructed is not required, as it is not needed to resolve ambiguity in the Code Value or Code Meaning; however, there is no restriction on the version being specified in Coding Scheme Version
the Code Value will be constructed from UCUM and make use of the "case-sensitive" form of UCUM code (e.g., "ml/s")
the Code Meaning for other than UCUM unity may be one of the following:
the "print" value specified in UCUM (e.g., "mmHg" for Code Value mm[Hg])
constructed from the "names" of individual components using the Americanized form of name (e.g., "milliliters/second")
constructed from the "names" of individual components using the European form of name (e.g., " millilitres /second")
In the case of UCUM unity ("1", or curly braces expression) it is forbidden to use "1" as a Code Meaning. Annex G provides Code Meanings for a Code Value (0008,0100) of 1. A Template or Context Group may constrain the Code Meaning according to the following rules:
UCUM default unit 1 shall use one of the Code Meaning synonyms specified in Annex G
ratios of identically dimensioned values may use ({ratio}, UCUM, "ratio")
unitless numeric scores may use ({M:N}, UCUM, "range: M:N") to specify the minimum and maximum value, for example, ({0:10}, UCUM, "range: 0:10")
counts using UCUM annotation shall always use the text within the curly braces as the Code Meaning, for example, ({masses}, UCUM, "masses")
compositions of a curly braces expression with other UCUM values may use a conventional clinical representation, for example, ({H.B.}/min, UCUM, "BPM")
The UCUM standard states that the preferred display values for codes deg (degrees of plane angle) and Cel (degrees Celsius) are "°" and "°C". However, the character ° does not have a representation in the DICOM default character set (ASCII, ISO-IR 6). The Code Meaning specified in this Part therefore uses "deg" and "C". SOP Instances that specify a Specific Character Set that allows the character ° may use Code Meanings "°" and "°C".
Code Meaning "C" formally conflicts with the Code Meaning for Coulomb. In the context of DICOM use, the possibility of confusion to a user based on the display of the Code Meaning is considered remote, as there is little use of Coulomb in imaging, and the context of the displayed item Concept Name would resolve between temperature and electric charge. Automated processing based on the Code Values should not face an issue as the Code Values differ.
The character ° has Unicode code point U+00B0, and is represented as 0xB0 in ISO-IR 100 (Latin-1), ISO-IR 101 (Latin-2), ISO-IR 109 (Latin-3), ISO-IR 110 (Latin-4), ISO-IR 126 (Greek), ISO-IR 138 (Hebrew), and ISO-IR 148 (Latin-5). It is not encodable in ISO-IR 13 (Katakana), ISO-IR 144 (Cyrillic), ISO-IR 127 (Arabic), or ISO-IR 166 (Thai).
An Application may extend an Extensible Context Group by adding terms for new concepts. Applications may not substitute other terms of the same concept in the Context Group. Applications may not add a term that means "unspecified" or "missing" or "unknown" similar; if such a concept is intended to be permitted then the Standard will include it in the Context Group already. Such extension may be made without a change in Context Group Identifier, but with the specification of Context Group Extensions (see PS3.3).
Non-extensible Context Groups shall not be modified in an Application.
Table 8-1 lists the coding schemes (and their designators) defined for use in DICOM; Table 8-2 lists the HL7v3 coding schemes referenced for use in DICOM. Additionally, any coding scheme may be used that has an entry in the HL7 Registry of Coding Schemes (HL7 v2 Table 0396, or the equivalent online registry), in which case the HL7 Symbolic Name shall be used as the value for the Coding Scheme Designator in DICOM, as long as it does not conflict with an entry Table 8-1 and fits within the Value Representation of the DICOM Coding Scheme Designator (0008,0102) attribute. As specified in the HL7 v2 Table 0396, local or private coding schemes shall be identified by an alphanumeric identifier beginning with the characters "99".
An earlier version of this table was formerly contained in Annex D of PS3.3.
See Section 8.2 “Coding Scheme Designator and Coding Scheme Version” in PS3.3 for further description.
The Coding Scheme UIDs are provided for reference only; the normative specification of UIDs and their associated meaning is the responsibility of the coding scheme developer and/or HL7.
The current version of HL7 v2 Table 0396 is available at http://www.hl7.org/special/committees/vocab/table_0396/index.cfm.
The HL7 registration of Coding Schemes is available at http://www.hl7.org/oid/index.cfm.
Publication of codes or references to coding schemes within DICOM does not constitute a grant of intellectual property rights to implementers. Use of some Coding Schemes may require a license, or purchase of the relevant coding scheme publication. Implementers should consult the relevant coding scheme publisher; see also Section 2.
The values of Coding Scheme Name (0008,0115), Coding Scheme Responsible Organization (0008,0116) and Coding Scheme Resources Sequence (0008,0109), if available, may be used to fill the corresponding optional attributes of the Coding Scheme Identification Sequence (0008,0110) in the Section C.12.1 “SOP Common Module” in PS3.3 .
Table 8-1. Coding Schemes
|
ACR Index for Radiological Diagnosis Revised, 3rd Edition 1986 |
|||||
|
[ASTM E 2084-00] Signature Purpose codes (see Annex A1 of ASTM E 2084), ASTM Subcommittee E 31.20 Data and System Security for Health Information |
|||||
|
Bypass Angioplasty Revascularization Investigation[Alderman 1992]; endorsed by ACC/AHA Guidelines for Coronary Angiography[Scanlon 1999]. |
|||||
|
ACR Breast Imaging Reporting and Data System [BI-RADS®], Coding Scheme Version (0008,0103) is required; code values are section and paragraph identifiers within the publication where the code meaning is defined (e.g., "I.D.1", where I = Breast Imaging Lexicon, D = Special Cases, 1 = Tubular Density, as the code value for "Tubular Density"). |
|||||
|
American Medical Association's Current Procedure Terminology 4 (CPT-4) |
|||||
|
American Medical Association's Current Procedure Terminology 5 (CPT-5) |
|||||
|
The Public ID is used as the Code Value. These can be looked up as in the following example (the version is required): http://cdebrowser.nci.nih.gov/CDEBrowser/search?dataElementDetails=9/&cdeId=2178693&version=2.1&PageId=DataElementsGroup |
|||||
|
American Dental Association's (ADA) Current Dental Terminology 2 (CDT-2) |
|||||
|
Dublin Code Metadata for Resource Discovery. The code value is the Label field, e.g., "Creator" (capitalization significant). |
|||||
|
DOC: http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_D.html OWL: ftp://medical.nema.org/medical/dicom/current/ontology/dcm.owl.zip |
PS3.16 Content Mapping Resource, Annex D (Note that HL7 also specifies an OID of 2.16.840.1.113883.6.31, but deprecates it in favor of 1.2.840.10008.2.16.4). |
||||
|
DOC: http://dicom.nema.org/medical/dicom/current/output/chtml/part06/chapter_A.html |
|||||
|
DOC: http://sig.biostr.washington.edu/projects/fm/AboutFM.html OWL: http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.zip |
|||||
|
Healthcare Financing Administration (HCFA) Common Procedure Coding System (HCPCS) |
|||||
|
International Classification of Diseases revision 10 (ICD-10) |
|||||
|
International Classification of Diseases revision 11 (ICD-11) |
|||||
|
International Classification of Diseases revision 9, with Clinical Modifications (ICD-9-CM) |
|||||
|
[RFC 4646], Tags for Identifying Languages, The Internet Society (2005) [RFC 4646] has been superceded by [RFC 5646]. |
|||||
|
[ISO 639-1] Two-letter language codes |
|||||
|
[ISO 639-2] Three-letter language codes |
|||||
|
[ISO 3166-1] alpha-2 Country Codes |
|||||
|
Representation of Human Sexes (not used) ISO5218_1, which uses numeric codes, was improperly specified in CID 7455 Sex in earlier editions of the Standard. The alphabetic codes improperly attributed to that coding scheme have been added to the DICOM Controlled Terminology, and thus all references to coding scheme ISO5218_1 should be considered equivalent to coding scheme DCM. |
|||||
|
[ISO 8824-1] ISO/IEC 8824-1- Information Technology - Abstract Syntax 1 (ASN.1): Specification of Basic Notation, and [ISO 9834-1] - Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree |
|||||
|
A Taxonomic Serial Number (TSN) is a unique, persistent, non-intelligent identifier for a scientific name in the context of the Integrated Taxonomic Information System (ITIS). |
|||||
|
DOC: http://loinc.org/ |
[LOINC] Logical Observation Identifier Names and Codes |
||||
|
DOC: http://www.informatics.jax.org/searches/AMA.cgi?id=MA:0002405 |
Hayamizu TF, Mangan M, Corradi JP, Kadin JA, Ringwald M. The Adult Mouse Anatomical Dictionary: a tool for annotating and integrating data. Genome Biology 2005;6(3):R29. doi:10.1186/gb-2005-6-3-r29. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1088948/ |
||||
|
Mayo Clinic Non-radiological Images Specific Body Structure Anatomical Surface Region Guide |
The numeric code of entries in the Mayo Clinic Non-radiological Images Specific Body Structure Anatomical Surface Region Guide. |
||||
|
ISO/IEEE 11073 Medical Device Nomenclature, including all its subsections ([ISO/IEEE 11073-10101], [ISO/IEEE 11073-10101a], [ISO/IEEE 11073-10102], etc.), encoded as decimal strings <partition>:<element> |
|||||
|
The MGI ID from the Mouse Genome Initiative (MGI) nomenclature. |
|||||
|
US National Library of Medicine (NLM) Medical Subject Headings (MeSH) |
|||||
|
Bernstein AD, et al."The NASPE/BPEG Defibrillator Code" PACE, 16:1776-1780, 1993 |
|||||
|
DOC: http://www.hrsonline.org/Practice-Guidance/Clinical-Guidelines-Documents/2002-The-Revised-NASPE-BPEG-Generic-Code-for-Antibradycardia-AdaptiveRate-and-Multisite-Pacing |
NASPE/BPEG Generic Pacemaker Code (2000) Bernstein AD, et al."The Revised NASPE/BPEG Generic Code for antibradycardia, adaptive-rate, and multisite pacing." Pacing Clin Electrophysiol., 25:260-264, 2002 See http://www.hrsonline.org/Practice-Guidance/Clinical-Guidelines-Documents/2002-The-Revised-NASPE-BPEG-Generic-Code-for-Antibradycardia-AdaptiveRate-and-Multisite-Pacing. |
||||
|
American College of Cardiology National Cardiovascular Data Registry™ Cath Lab Module Version 1.1, 1997; Version 2.0b, 1999 |
|||||
|
DOC: http://www.fda.gov/Drugs/InformationOnDrugs/ucm142438.htm |
The code value is the 10 digit 3 segment NDC code with "-" between segments included and no asterisk (leading zero placeholder). |
||||
|
DOC: http://braininfo.rprc.washington.edu/aboutBrainInfo.aspx#NeuroNames |
|||||
|
DOC: http://digital.nhs.uk/article/1108/National-Interim-Clinical-Imaging-Procedure-NICIP-Code-Set |
UK National Health Service National Interim Clinical Imaging Procedures (NICIP) Short Code (e.g., "CCHAPC" for CT Thorax abdomen pelvis with contrast) |
||||
|
The numeric code of entries in the New York University Melanoma Clinical Cooperative Group's numbering system. |
|||||
|
DOC: http://www.ihe.net/Technical_Framework/upload/IHE_PAT_Suppl_APSR_Appendix_Value_Sets_2011_03_31.xls |
|||||
|
US National Center for Biotechnology Information (NCBI) PubChem Compound CID. |
|||||
|
[RFC 3066], Tags for the Identification of Languages, Internet Engineering Task Force NoteHL7 uses "IETF3066" for the symbolic name. [RFC 3066] has been superseded by [RFC 4646], which in turn has been superceded by [RFC 5646]. |
|||||
|
[RFC 3881], Security Audit and Access Accountability Message - XML Data Definitions for Healthcare Applications |
|||||
|
[RFC 5646], Tags for Identifying Languages, The Internet Society (2009) NoteThe HL7 OID Registry specifies "rfc5646", not "ietf5646", as the Desired Symbolic Name (inconsistent with the pattern used for [RFC 4646]). [RFC 5646] constitutes one part of IETF Best Current Practice BCP 47 Tags for Identifying Languages, which also includes [RFC 4647] Matching of Language Tags; [RFC 4647] is not relevant in this context. |
|||||
|
SNOMED DICOM Microglossary (Retired) (see Section 8.1) |
|||||
|
Standard Communications Protocol for Computer-Assisted Electrocardiography, Draft proposal for ISO Standard, AAMI, Revision 1.3 |
|||||
|
SNOMED International Version 3 (see Section 8.1) |
|||||
|
[SNOMED], using the CT code values |
|||||
|
[SNOMED], using the "SNOMED-RT style" code values (see Section 8.1) |
|||||
|
DOC: http://uberon.org/ |
The Uberon ID from the Uberon integrated cross-species ontology covering anatomical structures in animals. |
||||
|
[UCUM] Unified Code for Units of Measure |
|||||
SNOMED (the Systematized Nomenclature of Medicine) Clinical Terms (CT) is the preferred coding system within DICOM for anatomy, clinical findings, procedures, pharmaceutical/biologic products (including contrast agents), and other clinical terms.
SNOMED has had various versions, including SNOMED International (Version 3), which was issued in 1993 and revised through 1998, SNOMED Reference Terminology, the successor to SNOMED 3 that was published between 1999 and 2001, and SNOMED Clinical Terms, which has been the name since 2002. The coding scheme is fully backward-compatible across SNOMED 3, SNOMED-RT, and SNOMED CT. SNOMED CT introduced a solely numeric set of codes (ConceptID) in addition to the former alphanumeric codes (SnomedID), but all SNOMED terminology concepts have both a numeric and an alphanumeric code.
In previous editions of the DICOM Standard, the following Coding Scheme Designators were used for SNOMED codes in DICOM:
All uses of SNOMED CT coded terms in DICOM are now indicated by the Coding Scheme Designator "SCT", identifying them as SNOMED CT numeric Concept IDs as code values.
When a Coding Scheme Designator of "99SDM", "SNM3" or "SRT" is encountered by a receiving system, the "SNOMED-RT style" alphanumeric Code Value needs to be mapped to the corresponding concept designated by the SNOMED CT Concept IDs assigned to the same concept.
"SRT" as a coding scheme designator was used only in the DICOM Standard. HL7v2 did not standardize a coding scheme designator for SNOMED-RT.
When interoperating with systems that use SNOMED CT codes, Application Entities may receive and are expected to send Code Sequences with a numeric ConceptID code. It is the responsibility of such Application Entities to convert any alphanumeric SnomedID with Coding Scheme Designator "SRT" used in old DICOM objects and services to the corresponding numeric ConceptID code.
Some non-DICOM systems may use a Coding Scheme Designator of "SNOMED-CT" rather than "SCT" as is used in DICOM.
The SNOMED organization's policy on the use of "antecedent versions", including the continued use of "SNOMED-RT style" alphanumeric code values is described at: http://www.snomed.org/news-articles/timetable-for-the-withdrawal-of-legacy-snomed-codes.
Since the SNOMED organization no longer distributes a reference set that includes a mapping of "SNOMED-RT style" SNOMED IDs to SNOMED Concept IDs a complete mapping of those used in DICOM is provided in Annex O to allow implementers to process legacy objects from legacy devices and archives.
In general, DICOM uses the anatomic concepts with the term "structure", rather than with the term "entire". This is an important distinction in SNOMED. "Entire" is a child concept to "structure", has a more restricted meaning, and typically is used in conjunction with treatments (e.g., "excision of entire right kidney"). It is used in distinction to other sibling children of the parent concept that may identify parts of the parent anatomic feature. Since imaging typically targets both the anatomic feature and the area around it, or sometimes just part of the anatomic feature, DICOM usually uses "structure" concepts that are more inclusive than the "entire" concepts.
[ISO 8824-1] and [ISO 9834-1] are the standards defined for the generation of object identifiers that are used as DICOM Unique Identifiers (see PS3.5), can also serve as a general mechanism for identifying organizations and objects defined by those organizations.
When the Coding Scheme Designator is ISO_OID, the Code Value shall be the numeric (dot delimited) form of a valid object identifier.
A repository of known existing object identifiers can be found at http://www.oid-info.com/index.htm. For example:
the ISO 9834-1 assigned numeric object identifier for the country France, is "1.0.3166.2.2.1.250" (since ISO 3166 defines a means for maintaining country codes using object identifiers)
the object identifier for the RIPEMD-160 cryptographic hash function is "1.0.10118.3.0.49"
the object identifier for the HL7 V2 table of codes for marital status is "2.16.840.1.113883.12.2"
The re-use of object identifiers for existing concepts that do not have an alternative more appropriate coding scheme compatible with DICOM provides a mechanism to avoid defining new codes. For example, HL7 assigned object identifiers can be found at http://www.hl7.org/oid/index.cfm.
Though the intent of ISO_OID is to define organizational roots for the hierarchical assignment of object identifiers, and not specifically to identify organizations per se, the organizational root values can be construed as identifying the organization. For example, the DICOM Standards Organization itself can be identified by the value "1.2.840.10008". See also CID 5002 “Organizations”.
As this Standard and external coding schemes are maintained, the codes specified as Concept Names, Concept Values and in Conditions may change. The previous codes are considered Retired but implementations may continue to send them and receivers will be expected to be able to continue to recognize the Retired codes, including the Code Value and Coding Scheme Designator, even if the current Standard does not publish them.
A notable example is the change throughout the Standard from using "SNOMED-RT style" code values with a Coding Scheme Designator of "SRT", "SNM3" or "99SDM", to the use of SNOMED CT numeric code values with a Coding Scheme Designator of "SCT". A mapping of retired to new SNOMED codes is found in Annex O.
This Annex specifies the content of Standard Templates that may be used by DICOM SR IODs.
This Template provides a general structure for a numeric measurement, together with evaluations of its normality and/or significance, and the inference source(s) for its value. This structure is instantiated by inclusion of this Template with specific contextual parameters from a parent Template.
Table TID 300. Parameters