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 .
[Berry 2012] 2012. “The AASM Manual for the scoring of sleep and associated events: rules, terminology and technical specifications. Version 2.0.”. http://www.aasmnet.org .
[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.
[ASTM F 75] . Standard Specification for Cobalt-28 Chromium-6 Molybdenum Alloy Castings and Casting Alloy for Surgical Implants.
[ASTM F 90] . Standard Specification for Wrought Cobalt-20Chromium-15Tungsten-10Nickel Alloy for Surgical Implant Applications.
[ASTM F 136] . Standard Specification for Wrought Titanium-6Aluminum-4Vanadium ELI (Extra Low Interstitial) Alloy for Surgical Implant Applications.
[ASTM F 138] . Standard Specification for Wrought 18Chromium-14Nickel-2.5Molybdenum Stainless Steel Bar and Wire for Surgical Implants.
[ASTM F 688] . Standard Specification for Wrought Cobalt-35Nickel-20Chromium-10Molybdenum Alloy Plate, Sheet, and Foil for Surgical Implants.
[ASTM F 1058] . Standard Specification for Wrought 40Cobalt-20Chromium-16Iron-15Nickel-7Molybdenum Alloy Wire, Strip, and Strip Bar for Surgical Implant Applications.
[ASTM F 1295] . Standard Specification for Wrought Titanium-6Aluminum-7Niobium Alloy for Surgical Implant Applications.
[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 .
[ICRU Report 62] 1999. Prescribing, recording, and reporting photon beam therapy (supplement to ICRU Report 50).
[IEC 60601-2-1] . Medical Electrical Equipment - Part 2-1: Particular requirements for the basic safety and essential performance of electron accelerators in the range 1 MeV to 50 MeV.
[IEC 60601-2-44] . Medical Electrical Equipment - Part 2-44: Particular Requirements for the Safety of X-Ray Equipment for Computed Tomography.
[IEC 60601-2-64] . Medical Electrical Equipment - Part 2-64: Particular requirements for the basic safety and essential performance of light ion beam medical electrical equipment.
[IEC 62563-1] 2009. Ed 1.0. Medical Electrical Equipment - Medical image display systems - Part 1: Evaluation methods.
[IEC 62985] 2019. Methods For Calculating Size Specific Dose Estimates (SSDE) For Computed Tomography.
[IHE RAD TF-1] IHE Radiology (RAD) Technical Framework, Volume 1 - Integration Profiles. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf .
[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 5832-3] . Implants for surgery – Metallic materials — Part 3: Wrought titanium 6-aluminium 4-vanadium alloy.
[ISO 5832-4] . Implants for surgery – Metallic materials — Part 4: Cobalt-chromium-molybdenum casting alloy.
[ISO 5832-5] . Implants for surgery – Metallic materials — Part 5: Wrought cobalt-chromium-tungsten-nickel alloy.
[ISO 5832-6] . Implants for surgery – Metallic materials — Part 6: Wrought cobalt-nickel-chromium-molybdenum alloy.
[ISO 5832-7] . Implants for surgery – Metallic materials — Part 7: Forgeable and cold-formed cobalt-chromium-nickel-molybdenum-iron alloy.
[ISO 5832-11] . Implants for surgery – Metallic materials — Part 11: Wrought titanium 6-aluminium 7-niobium alloy.
[ISO 5832-14] . Implants for surgery – Metallic materials — Part 14: Wrought titanium 15-molybdenum 5-zirconium 3-aluminium alloy.
[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 .
[Kenneweg 2019] J Am Acad Dermatol. 2019. 6. 1564–84. “Developing an international standard for the classification of surface anatomic location for use in clinical practice and epidemiologic research”. doi:10.1016/j.jaad.2018.08.035 http://www.jaad.org/article/S0190-9622(18)32489-7/ .
[NEMA XR 25-2019] 2019. Computed Tomography Dose Check Standard. http://www.nema.org/Standards/view/Computed-Tomography-Dose-Check .
[RadLex] 2006. A Lexicon for Uniform Indexing and Retrieval of Radiology Information Resources. http://www.radlex.org/ .
[RadElement] Common Data Elements (CDEs) for Radiology. http://radelement.org/ .
[RFC 3881] September 2004. Security Audit and Access Accountability Message - XML Data Definitions for Healthcare Applications.
[J1086_201210] Oct 2012. Numbering Metals and Alloys. http://www.sae.org/standards/content/j1086_201210/ .
[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 .
[Seeck 2017] Clinical Neurophysiology. 2017. 10. 2070-7. “The standardized EEG electrode array of the IFCN”. doi:10.1016/j.clinph.2017.06.254 http://www.sciencedirect.com/science/article/pii/S1388245717304832 .
[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 Describes 16- and 17-segment models. .
[Voigt 2015] Eur Heart J Cardiovasc Imaging. 2015. 1. 1-11. “Definitions for a common standard for 2D speckle tracking echocardiography: consensus document of the EACVI/ASE/Industry Task Force to standardize deformation imaging”. doi:10.1093/ehjci/jeu184 Describes 16-, 17-, and 18-segment models. .
[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/qcdrDataSample/prodFiles/2018%20Files/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® International Edition 2021/07/31, 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) is a joint effort of the European Society of Urogenital Radiology, the American College of Radiology and the AdMeTech Foundation.
[PI-RADS] 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 source:
American College of Radiology: http://www.acr.org/~/media/ACR/Documents/PDF/QualitySafety/Resources/PIRADS/PIRADS%20V2.pdf
[PI-RADS v2.1] Eur Urol. 2019/09. 3. 340–351. “Prostate Imaging Reporting and Data System Version 2.1: 2019 Update of Prostate Imaging Reporting and Data System Version 2”. doi:10.1016/j.eururo.2019.02.033 http://www.europeanurology.com/article/S0302-2838(19)30180-0/abstract .
[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/ .
[Rozenkrantz 2013] Radiology. 2013/11. 2. 482–492. “Prostate cancer localization using multiparametric MR imaging: comparison of Prostate Imaging Reporting and Data System (PI-RADS) and Likert scales”. doi:10.1148/radiol.13122233 http://dx.doi.org/10.1148/radiol.13122233 .
[Kuru 2013] BJU Int. 2013. 5. 568–577. “Definitions of terms, processes and a minimum dataset for transperineal prostate biopsies: a standardization approach of the Ginsburg Study Group for Enhanced Prostate Diagnostics”. doi:10.1111/bju.12132 http://onlinelibrary.wiley.com/doi/10.1111/bju.12132/full .
Injector and modality manufacturers use the CiA 425 CANopen standard for communication and synchronization between devices.
A portion of the terminology used within the CT/MR Cardiovascular Analysis Report is derived from CAD-RADS™.
[CAD-RADS™] Journal of Cardiovascular Computed Tomography. 2016. 269-81. “CAD-RADS™ Coronary Artery Disease – Reporting and Data System. An expert consensus document of the Society of Cardiovascular Computed Tomography (SCCT), the American College of Radiology (ACR) and the North American Society for Cardiovascular Imaging (NASCI). Endorsed by the American College of Cardiology.”. doi:10.1016/j.jcct.2016.04.005 http://www.journalofcardiovascularct.com/article/S1934-5925(16)30048-X/ .
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:
This Part of the Standard makes use of the following terms defined in PS3.5:
A unit of radiation output used to quantify a Meterset. See Section C.36.1.1.3 “Meterset” in PS3.3 .
This Part of the Standard makes use of the following terms defined in PS3.3:
The following symbols and abbreviations are used in this Part of the Standard.
Computer-Aided Detection and/or Computer-Aided Diagnosis for chest radiography
Computer-Aided Detection and/or Computer-Aided Diagnosis for colon radiography
Computer-Aided Detection and/or Computer-Aided Diagnosis for Mammography
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.
Annex A and Annex 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.
When templates are amended, temporary assignments of new rows between existing rows may be indicated by an alphabetic suffix, as in "6a" after "6", etc.
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:
Mandatory. Shall be present. An empty Measured Value Sequence (0040,A300) is not permitted when unknown, only for failures. See Section 6.1.7.1.
Mandatory Conditional. Shall be present if the specified condition is satisfied. An empty Measured Value Sequence (0040,A300) is not permitted when unknown, only for failures. See Section 6.1.7.1.
User Option Conditional. May not be present. May be present according to the specified condition.
There is an interaction between the VM and the Requirement Type with respect to the number of times that a Content Item (or included Template) may actually be present, as follows:
Section C.18.1 Numeric Measurement Macro in PS3.3 permits the Measured Value Sequence (0040,A300), which contains the Numeric Value (0040,A30A) and Measurement Units Code Sequence (0040,08EA) to be zero length.
This does not apply to the Section 10.2 Content Item Macro in PS3.3 , which does not permit an empty Measured Value Sequence (0040,A300) nor does it include a Numeric Value Qualifier Code Sequence (0040,A301).
The unknown state shall be distinguished from valid arithmetic or device or algorithm failure related states (in which cases a numeric string that complies with the PS3.5 Value Representation for DS cannot be created).
If the Template Requirement Type is M or MC, then:
A zero length Measured Value Sequence (0040,A300) is permitted for any of the reasons listed in CID 43 “Numeric Value Failure Qualifier”
A zero length Measured Value Sequence (0040,A300) is not permitted for any of the reasons listed in CID 44 “Numeric Value Unknown Qualifier”, or any other semantically equivalent reason
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). For example:
Defaults to (121006, DCM, "Person")
Defaults to Value of Institution Name (0008,0080) of the General Equipment Module
A default value may also be specified to indicate that a Content Item is expected to have a particular value unless there is a reason for it to be different. This is especially true in the case where a Content Item is mandatory and, therefore, must not be absent.
For the UIDREF Content Item in Row 1 of TID 1004 “Device Observer Identifying Attributes”, the Value Set Constraint column specifies: "Defaults to Value of Device UID (0018,1002) of the General Equipment Module". That means, the value of this Content Item should be the same as the value of the referenced Attribute unless there is a reason for it to be different.
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. For example:
UNITS = DCID 7460 “Linear Measurement Unit”
The constraints on the units apply only when Measured Value Sequence (0040,A300) contains an item (i.e., a numeric value is present).
The presence of constraints on the units does not imply that a value is required to be sent, since Measured Value Sequence (0040,A300) is Type 2 and may be zero length if permitted by the Requirement Type for the Content Item in the Template.
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.
The SR Document Content Module specifies "SEPARATE" and "CONTINUOUS" as the Enumerated Values for Continuity of Content Flag (0040,A050).
Constraints on the value of the Graphic Type(0070,0023) may be specified in the Value Set Constraint field if and only if the Value Type is SCOORD. The constraint may specify a set of allowed values, or a set of disallowed values. For example:
Constraints on various aspects of the TABLE Content Item may be specified in the Value Set Constraint field, including the manner of encoding the tabulated values, either by row, by column, by individual cells, or by reference to other Content Items, by specifying:
Fixed values, minimums and/or maximums for the number of table rows (NROWS) and/or columns (NCOLUMNS)
Defined or enumerated coded entries, or baseline or defined Context Groups for Concept Name Code Sequence (0040,A043) to use in Table Row Definition Sequence (0040,A806) (ROW n) and/or Table Column Definition Sequence (0040,A807) (COLUMN n)
Defined or enumerated coded entries, or baseline or defined Context Groups for Concept Code Sequence (0040,A168) to use in Cell Values Sequence (0040,A808) (ROW n VALUES) and/or (COLUMN n VALUES) and/or (CELL r, c VALUES)
Defined or enumerated coded entries, or baseline or defined Context Groups for Measurement Units Code Sequence (0040,08EA) to use in Table Row Definition Sequence (0040,A806) (ROW n UNITS) and/or Table Column Definition Sequence (0040,A807) (COLUMN n UNITS) and/or Cell Values Sequence (0040,A808) (CELL r, c UNITS)
Permitted VR to use in Selector Attribute VR (0072,0050) for specified rows (ROW n VR) , columns (COLUMN n VR) or cells (CELL r,c VR) , when values are encoded literally
Permitted referenced Content Item target (TID ttt ROW rrr) for specified rows (ROW n REF) , columns (COLUMN n REF) or cells (CELL r,c REF), when values are specified by reference
It is also helpful to provide a detailed description of the form of the table in the corresponding Content Item Description.
|
COLUMN 1 = EV (111526, DCM, "DateTime Started") COLUMN 2 = EV (113734, DCM, "X-Ray Tube Current") |
|
The X-Ray Source Transformation Matrix is encoded as a 4 by 4 matrix of dimensionless numbers of the form defined in Section C.20.2.1.1 Frame of Reference Transformation Matrix in PS3.3 . The table may be encoded as entire rows, entire columns or individual cells of double float numeric values. |
|
COLUMN 1 = EV (111526, DCM, "DateTime Started") COLUMN 2 = EV (111632, DCM, "Anode Target Material") |
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:
assigned a UID (that is defined in PS3.6)
linked to various resource files that contain representations of the Context Group (in FHIR JSON, FHIR XML and IHE SVS XML)
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 “Measurement Unit”.
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 .