Copyright © 2026 NEMA
Содержание
List of Figures
List of Tables
Информация в настоящей публикации была признана технически обоснованной по консенсусу лиц, участвовавших в разработке и утверждении документа на момент его создания. Консенсус не обязательно означает единогласное согласие среди всех лиц, участвующих в разработке настоящего документа.
Стандарты и руководящие публикации NEMA, одной из которых является документ, содержащийся в настоящем издании, разрабатываются в рамках процесса добровольной разработки стандартов на основе консенсуса. Этот процесс объединяет добровольцев и/или выявляет мнения лиц, заинтересованных в теме, охваченной настоящей публикацией. Хотя NEMA управляет процессом и устанавливает правила для обеспечения справедливости при выработке консенсуса, она не составляет документ и не проводит независимо тестирование, оценку или проверку точности или полноты любой информации или обоснованности любых суждений, содержащихся в её стандартах и руководящих публикациях.
NEMA не несёт ответственности за любые телесные повреждения, ущерб имуществу или иные убытки любого характера, будь то особые, косвенные, последующие или компенсационные, прямо или косвенно вытекающие из публикации, использования, применения или полагания на настоящий документ. NEMA отказывается и не даёт никаких гарантий или поручительств, явных или подразумеваемых, относительно точности или полноты любой информации, опубликованной в настоящем издании, и отказывается и не гарантирует, что информация в настоящем документе будет отвечать каким-либо вашим конкретным целям или потребностям. NEMA не обязуется гарантировать характеристики продукции или услуг любого отдельного производителя или продавца в силу настоящего стандарта или руководства.
Публикуя и предоставляя доступ к настоящему документу, NEMA не берёт на себя оказание профессиональных или иных услуг для любого лица или организации или от их имени, равно как и NEMA не берёт на себя выполнение каких-либо обязанностей, возложенных на любое лицо или организацию в отношении третьих лиц. Любое лицо, использующее настоящий документ, должно полагаться на собственное независимое суждение или, в зависимости от обстоятельств, обращаться за консультацией к компетентному специалисту при определении меры разумной осторожности в каждой конкретной ситуации. Информация и другие стандарты по теме, охваченной настоящей публикацией, могут быть доступны из других источников, к которым пользователь может пожелать обратиться за дополнительными мнениями или сведениями, не охваченными настоящей публикацией.
NEMA не имеет полномочий и не берёт на себя контроль или обеспечение соблюдения положений настоящего документа. NEMA не сертифицирует, не испытывает и не инспектирует продукцию, конструкцию или установки в целях безопасности или охраны здоровья. Любая сертификация или иное заявление о соответствии любой информации, связанной со здоровьем или безопасностью, в настоящем документе не может быть приписана NEMA и является исключительной ответственностью лица, проводящего сертификацию, или автора соответствующего заявления.
Настоящий стандарт DICOM был разработан в соответствии с процедурами Комитета по стандартам DICOM.
Стандарт DICOM структурирован как многочастный документ с использованием руководящих принципов, установленных в [ISO/IEC Directives, Part 2].
PS3.1 следует использовать в качестве базового справочника для действующих частей настоящего Стандарта.
DICOM® является зарегистрированным товарным знаком Национальной ассоциации производителей электрооборудования (National Electrical Manufacturers Association) для её публикаций стандартов, относящихся к цифровой связи медицинской информации, все права защищены.
HL7® и CDA® являются зарегистрированными товарными знаками Health Level Seven International, все права защищены.
SNOMED®, SNOMED Clinical Terms®, SNOMED CT® являются зарегистрированными товарными знаками Международной организации по разработке стандартов терминологии в области здравоохранения (International Health Terminology Standards Development Organisation , IHTSDO), все права защищены.
LOINC® является зарегистрированным товарным знаком Regenstrief Institute, Inc, все права защищены.
Настоящая Часть стандарта DICOM определяет набор информационных объектных дефиниций (Information Object Definitions, IOD), предоставляющих абстрактное описание реальных объектов, применимых для передачи цифровой медицинской информации. Для каждого IOD настоящая Часть определяет:
Для каждого IOD настоящая Часть не определяет:
Настоящая Часть связана с другими частями стандарта DICOM в следующем:
PS3.4 Спецификации сервисных классов (Service Class Specifications) определяет службы прикладного уровня путём группировки служб DIMSE с IOD, определёнными в настоящей Части;
PS3.5 Структура данных и семантика (Data Structure and Semantics) определяет кодирование данных, используемое в протоколе DIMSE применительно к IOD, определённым в настоящей Части;
PS3.6 Словарь данных (Data Dictionary) содержит индекс по Tag всех атрибутов IOD, определённых в настоящей Части. Этот индекс включает представление значения (Value Representation) и кратность значения (Value Multiplicity) для каждого атрибута;
PS3.7 Протокол обмена сообщениями (Message Exchange Protocol) определяет службы и протокол DIMSE, которые могут применяться к IOD, определённым в настоящей Части.
Следующие стандарты содержат положения, которые посредством ссылок в настоящем тексте составляют положения настоящего Стандарта. На момент публикации указанные редакции были действующими. Все стандарты подлежат пересмотру, и сторонам соглашений, основанных на настоящем Стандарте, рекомендуется изучить возможности применения самых последних редакций указанных ниже стандартов.
[ISO/IEC Directives, Part 2] 2021. 9.0. Rules for the structure and drafting of International Standards. http://www.iso.org/sites/directives/current/part2/index.xhtml .
[ISO 7498-1] 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.
[ISO 7498-2] 1989. Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2: Security Architecture.
[ISO/TR 8509] Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 has been withdrawn. See ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .
[ISO 8825-1] 2002. Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[ISO/IEC 8859-1] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 1: Latin alphabet No. 1.
[ISO/IEC 8859-2] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 2: Latin alphabet No. 2.
[ISO/IEC 8859-3] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 3: Latin alphabet No. 3.
[ISO/IEC 8859-4] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 4: Latin alphabet No. 4.
[ISO/IEC 8859-5] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 5: Latin/Cyrillic alphabet.
[ISO/IEC 8859-6] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 6: Latin/Arabic alphabet.
[ISO/IEC 8859-7] 1987. Information processing - 8-bit single-byte coded graphic character sets - Part 7: Latin/Greek alphabet.
[ISO/IEC 8859-8] 1988. Information processing - 8-bit single-byte coded graphic character sets - Part 8: Latin/Hebrew alphabet.
[ISO/IEC 8859-9] 1989. Information processing - 8-bit single-byte coded graphic character sets - Part 9: Latin alphabet No. 5.
[ISO/IEC 8859-15] 1999. Information technology — 8-bit single-byte coded graphic character sets — Part 15: Latin alphabet No. 9.
[ISO/IEC 10118-3] 1998. Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions (RIPEMD-160 reference). The draft RIPEMD-160 specification and sample code are also available at http://homes.esat.kuleuven.be/~bosselae/ripemd160.html .
[ISO/IEC 10646] 2020. Information Technology - Universal Coded Character Set (UCS). ISO/IEC 10646-2020 is the same as Unicode Version 13.0, available at http://unicode.org .
[ISO/IEC 10918-1] 1994. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 1 - Requirements and implementation guidelines.
[ISO/IEC 10918-5] 2013. JPEG Standard for digital compression and encoding of continuous-tone still images. Part 5 - JPEG File Interchange Format (JFIF).
[ISO 11664-4] 2008. Colorimetry - Part 4: CIE 1976 L*a*b* Colour space. ISO 11664-4 2008 is the same as CIE S 014-4/E:2007 .
[ISO 12232] 2006. Photography - Digital still cameras - Determination of exposure index, ISO speed ratings, standard output sensitivity, and recommended exposure index. http://www.iso.org/standard/37777.html .
[ISO 12233] 2018. Photography - Electronic still picture imaging - Resolution and spatial frequency responses. http://www.iso.org/standard/71696.html .
[ISO 12234-2] 2001. Electronic still-picture imaging - Removable memory - Part 2: TIFF/EP image data formats. http://www.iso.org/standard/29377.html .
[ISO/IEC 13818-1] 2000. Information technology - Generic coding of moving pictures and associated audio information: Systems.
[ISO/IEC 13818-2] 2000. Information technology - Generic coding of moving pictures and associated audio information: Video.
[ISO/IEC 13818-3] 1998. Information technology - Generic coding of moving pictures and associated audio information - Part 3: Audio.
[ISO/IEC 13818-4] 2004. Information technology - Generic coding of moving pictures and associated audio information - Part 4: Conformance testing.
[ISO/IEC 14495-1] 1997. Lossless and near-lossless coding of continuous tone still images (JPEG-LS).
[ISO/IEC 14496-10] 2009. Information technology - Coding of audio-visual objects - Part 210: Advanced Video Coding. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52974 .
[ISO/IEC 14496-22] Information technology - Coding of audio-visual objects - Part 22: Open Font Format. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52136 .
[ISO 14524] 2009. Photography - Electronic still-picture cameras - Methods for measuring opto-electronic conversion functions (OECFs). http://www.iso.org/standard/43527.html .
[ISO 15076-1] 2005. Image technology colour management - Architecture, profile format, and data structure. Also available as ICC.1:2004-10 (Profile version 4.2.0.0), International Color Consortium, available at http://www.color.org/v4spec.xalter .
[ISO/IEC 18181-1] 2022. Information technology - JPEG XL Image Coding System - Part 1 Core Coding System.
[ISO 21320-1] 2015. Information technology – Document Container File – Part 1: Core. http://standards.iso.org/ittf/PubliclyAvailableStandards/c060101_ISO_IEC_21320-1_2015.zip .
[ISO 22028-2] 2013. Photography and graphic technology - Extended colour encodings for digital image storage, manipulation and interchange - Part 2: Reference output medium metric RGB colour image encoding (ROMM RGB). http://www.iso.org/iso/catalogue_detail.htm?csnumber=56591 .
[ISO/IEC 23008-2] Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 2: High efficiency video coding. http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=67660 .
[ISO 32000-1] Document management - Portable document format - Part 1. http://www.iso.org/iso/catalogue_detail.htm?csnumber=51502 .
[IEC 60601-2-1] 2020. Ed.4. 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-33] 2010. Ed.3.1. Medical Electrical Equipment - Part 2-33: Particular requirements for the basic safety and essential performance of magnetic resonance equipment for medical diagnosis.
[IEC 60601-2-44] 2016. Ed.3.2. Medical Electrical Equipment - Part 2-44: Particular Requirements for the Safety of X-Ray Equipment for Computed Tomography.
[IEC 60601-2-63] 2012. Medical Electrical Equipment - Part 2-63: Particular requirements for the basic safety and essential performance of dental extra-oral X-Ray equipment.
[IEC 60601-2-64] 2014. Medical Electrical Equipment - Part 2-64: Particular requirements for the basic safety and essential performance of light ion beam medical electrical equipment.
[IEC 61966-2.1] 1999. Ed 1.0. Multimedia systems and equipment - colour measurement and management - Part 2.1: colour management - Default RGB colour space - sRGB.
[IEC 62494-1] 2008. Medical electrical equipment - Exposure index of digital X-Ray imaging systems - Part 1: Definitions and requirements for general radiography.
[IEC 62563-1] 2009. Ed 1.0. Medical Electrical Equipment - Medical image display systems - Part 1: Evaluation methods.
[ISO IR 13] 1975. Registration - The Japanese KATAKANA graphic set of characters. http://www.itscj.ipsj.or.jp/iso-ir/013.pdf .
[ISO IR 14] 1975. Registration - The Japanese Roman graphic set of characters. http://www.itscj.ipsj.or.jp/iso-ir/014.pdf .
[ISO IR 100] 1986. Registration - Right-hand Part of the Latin Alphabet Nr. 1. http://www.itscj.ipsj.or.jp/iso-ir/100.pdf .
[ISO IR 101] 1986. Registration - Right-hand Part of the Latin Alphabet Nr. 2. http://www.itscj.ipsj.or.jp/iso-ir/101.pdf .
[ISO IR 109] 1986. Registration - Right-hand Part of the Latin Alphabet Nr. 3. http://www.itscj.ipsj.or.jp/iso-ir/109.pdf .
[ISO IR 110] 1986. Registration - Right-hand Part of the Latin Alphabet Nr. 4. http://www.itscj.ipsj.or.jp/iso-ir/110.pdf .
[ISO IR 126] 1986. Registration - Right-hand Part of the Latin/Greek alphabet. http://www.itscj.ipsj.or.jp/iso-ir/126.pdf .
[ISO IR 127] 1986. Registration - Right-hand Part of Latin/Arabic alphabet. http://www.itscj.ipsj.or.jp/iso-ir/127.pdf .
[ISO IR 138] 1987. Registration - Latin/Hebrew alphabet. http://www.itscj.ipsj.or.jp/iso-ir/138.pdf .
[ISO IR 144] 1988. Registration - Cyrillic Part of the Latin/Cyrillic Alphabet. http://www.itscj.ipsj.or.jp/iso-ir/144.pdf .
[ISO IR 148] 1988. Registration - Right-hand Part of Latin alphabet No. 5. http://www.itscj.ipsj.or.jp/iso-ir/148.pdf .
[ISO IR 166] 1992. Registration - Thai Character Set. http://www.itscj.ipsj.or.jp/iso-ir/166.pdf .
[ISO IR 192] 1996. Registration - UCS Transformation Format (UTF-8), implementation level 3, without standard return. http://www.itscj.ipsj.or.jp/iso-ir/192.pdf .
[ISO IR 203] 1998. Registration - European supplementary Latin set ("Latin 9"). http://www.itscj.ipsj.or.jp/iso-ir/203.pdf .
[ITU-T X.509] 2000. Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks. ITU-T Recommendation X.509 is similar to ISO/IEC 9594-8 1990. However, the ITU-T recommendation is the more familiar form, and was revised in 1993 and 2000, with two sets of corrections in 2001. ITU-T was formerly known as CCITT. .
[RFC1321] The MD5 Message-Digest Algorithm. http://tools.ietf.org/html/rfc1321 .
[RFC1951] DEFLATE Compressed Data Format Specification Version 1.3. http://tools.ietf.org/html/rfc1952 .
[RFC1952] GZIP file format specification version 4.3. http://tools.ietf.org/html/rfc1952 .
[RFC2046] November 1996. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. http://tools.ietf.org/html/rfc2046 .
[RFC2437] October 1998. PKCS #1 RSA Cryptography Specifications Version 2.0. http://tools.ietf.org/html/rfc2437 . The RSA Encryption Standard is also defined in informative Annex A of ISO/IEC 9796, and in Normative Annex A of the CEN/TC251 European Prestandard prENV 12388:1996. .
[RFC3161] Internet X.509 Public Key Infrastructure; Time Stamp Protocols. http://tools.ietf.org/html/rfc3161 .
[RFC3986] Uniform Resource Identifiers (URI): Generic Syntax. http://tools.ietf.org/html/rfc3986 .
[RFC5652] September 2009. Cryptographic Message Syntax. http://tools.ietf.org/html/rfc5652 .
[RFC6151] March 2011. Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms. http://tools.ietf.org/html/rfc6151 .
[RFC7230] Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. http://tools.ietf.org/html/rfc7230 .
[RFC7231] Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. http://tools.ietf.org/html/rfc7231 .
[RFC7530] Network File System (NFS) Version 4 Protocol. http://tools.ietf.org/html/rfc7530 .
[HL7 V2.5] 2003. HL7 Standard Version 2.5 - An Application Protocol for Electronic Data Exchange in Healthcare Environments. http://www.hl7.org/documentcenter/private/standards/V25/HL7_Messaging_v25_PDF.zip .
[HL7 V2.9.1] 2024. HL7 Version 2.9.1 Messaging Standard - An Application Protocol for Electronic Data Exchange in Healthcare Environments. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=649 .
[HL7 CDA R1] 2000. HL7 Version 3 Standard: Clinical Document Architecture Framework, Release 1. http://www.hl7.org/documentcenter/private/standards/cda/r1/HL7_CDA_R1_FINAL.zip .
[HL7 CDA R2] 2005. HL7 Version 3 Standard: Clinical Document Architecture Framework, Release 2. http://www.hl7.org/documentcenter/private/standards/cda/r2/cda_r2_normativewebedition2010.zip .
[HL7 SPL R1.0] 2024. HL7 Structured Product Labeling Standard, Release 1.0. http://www.hl7.org/documentcenter/private/standards/SPL/SPL_Specification_ANSI_R1.0-2004.zip .
[HL7 Gender Harmony Model] 2021. The HL7 Informative Document: Gender Harmony - Modeling Sex and Gender Representation, Release 1. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=564 .
[HL7 Gender Harmony IG] . HL7 Cross Paradigm Implementation Guide: Gender Harmony - Sex and Gender Representation, Edition 1. http://hl7.org/xprod/ig/uv/gender-harmony/ .
[HL7 CDA R2.0 Gender Harmony IG] . HL7 CDA® R2 Implementation Guide: Gender Harmony - Sex and Gender Representation, Edition 1. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=633 .
[HL7 FHIR 5 Patient Gender] HL7 FHIR Release 5 - Patient Gender and Sex. http://hl7.org/fhir/R5/patient.html#gender .
[FIPS PUB 46] . Data Encryption Standard (DES). Withdrawn . http://csrc.nist.gov/publications/fips/archive/fips46-3/fips46-3.pdf .
[FIPS PUB 180-4] August 2015. Secure Hash Standard (SHS). http://doi.org/10.6028/NIST.FIPS.180-4 .
[FIPS PUB 202] August 2015. SHA-3 Standard. http://doi.org/10.6028/NIST.FIPS.202 .
[ACR-NEMA 300-1985] 1985. Digital Imaging and Communications. http://dicom.nema.org/medical/dicom/1985/ACR-NEMA_300-1985.pdf .
[ACR-NEMA 300-1988] 1988. Digital Imaging and Communications. http://dicom.nema.org/medical/dicom/1988/ACR-NEMA_300-1988.pdf .
[Adobe RGB] 1998. 2005-05. Adobe RGB (1998) Color Image Encoding. http://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf .
[Anderson 1986] Medical Physics. 1986. 6. 898-903. “A "natural" volume-dose histogram for brachytherapy”. doi:10.1118/1.595815
[ANSI X9.52] 1998. Triple Data Encryption Algorithm Modes of Operation, Accredited Standards Committee (ASC) X9, Financial Services.
[APEX] August 4, 2007. APEX — The Additive System of Photographic Exposure. http://dougkerr.net/Pumpkin/articles/APEX.pdf .
[BI-RADS®] 1998. 3.0. Breast Imaging Reporting and Data System Atlas. http://www.acr.org/Quality-Safety/Resources/BIRADS .
[DCI DCSS] May 29, 2024. Digital Cinema System Specification. http://www.dcimovies.com/dci-specification .
[Display-P3] Display P3 Color Encoding. http://www.color.org/chardata/rgb/DisplayP3.xalter .
[ECMA 235] 1996. The ECMA GSS-API Mechanism. http://www.ecma-international.org/publications/standards/Ecma-235.htm .
[EXIF 2.31] July 2016. 2.31. Exchangeable Image File Format for Digital Still Cameras - CIPA DC-008, JEITA CP-3451C Translation. http://cipa.jp/std/documents/e/DC-008-Translation-2016-E.pdf .
[FDA UDI] 2016. 1.2. UDI formats by FDA-Accredited Issuing Agency. http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/UDIIssuingAgencies/UCM489869.pdf .
[JIS X 0212] 1990. Code of the supplementary Japanese Graphic Character set for information interchange.
[NEMA UD3] 2004. Standard for Real-Time Display of Thermal and Mechanical Acoustic Output Indices on Diagnostic Ultrasound Equipment.
[IEEE 754] 2019. IEEE Standard for Floating Point Arithmetic. http://dx.doi.org/10.1109/IEEESTD.2019.8766229 .
[IEEE 1588] 2008. Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. doi:10.1109/IEEESTD.2008.4579760
[IHE ITI TF-2b] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2b Transactions Part B – Sections 3.29 – 3.64. http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf .
[IHE RAD TF-1] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 1 Integration Profiles. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf .
[IHE RAD TF-1x] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 1x Appendices to Integration Profiles. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1x.pdf .
[IHE RAD TF-2] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2 Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf .
[IHE RAD TF-2x] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2x Appendices to Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2x.pdf .
[IHE RAD TF-3] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 3 Cross-Transaction Specifications and Content Specifications. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol3.pdf .
[IHE RAD TF-4] Integrating the Healthcare Enterprise Radiology Technical Framework Volume 4 National Extensions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol4.pdf .
[OBJ] 1992. Advanced Visualizer. B1. Object Files (.obj). http://www.cs.utah.edu/~boulos/cs3505/obj_spec.pdf .
[PDF] 1985. Fifth Edition. PDF Reference, version 1.6. http://www.adobe.com/devnet/pdf/pdf_reference_archive.html .
[TIS 620-2533] 1990. Thai Characters Code for Information Interchange. http://www.nectec.or.th/it-standards/std620/std620.html .
[McCollough 2007] Radiology. 2007. 2. 527. “A multi-institutional, multi-manufacturer, international standard for the quantification of coronary artery calcium using cardiac CT”. doi:10.1148/radiol.2432050808
[CSS2] 2011. Cascading Style Sheet (CSS) CSS2 generic font families. http://www.w3.org/TR/REC-CSS2/fonts.html#generic-font-families .
[HPGL] . PCL/PJL Reference PCL5 Printer Language Technical Reference Manual. IIHP 5961-0509. http://www.hp.com/ctg/Manual/bpl13211.pdf .
[AAPM TG 116] July 2009. Report of AAPM Task Group 116 - An Exposure Indicator for Digital Radiography. http://www.aapm.org/pubs/reports/rpt_116.pdf .
[AAPM Report 204] 2011. Report of AAPM Task Group 204 - 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.
[US 6,272,235] Method and Apparatus for Creating a Virtual Microscope Slide. US Patent. 6,272,235. August 7, 2001.
[Porter and Duff 1984] Computer Graphics. 1984. 3. 253-259. “Compositing Digital Images”. doi:10.1145/800031.808606 http://keithp.com/~keithp/porterduff/p253-porter.pdf .
[Phong 1975] Communications of the ACM. 1975. 6. 311-317. “Illumination for computer generated pictures”. doi:10.1145/360825.360839 http://www.cs.northwestern.edu/~ago820/cs395/Papers/Phong_1975.pdf .
[Poynton 2008] 2008/01/24. Chroma subsampling notation. http://www.poynton.com/PDFs/Chroma_subsampling_notation.pdf .
[POSIX] 2017. POSIX.1-2017 (IEEE Std 1003.1™-2017). http://pubs.opengroup.org/onlinepubs/9699919799/ .
[ZIP] 1989. ZIP File Format Specification. http://www.pkware.com/documents/casestudies/APPNOTE.TXT .
[Chytyk-Praznik 2013] Med Phys. 2013. 3. 031713. “Model-based prediction of portal dose images during patient treatment”. doi:10.1118/1.4792203
[SMPTE RP 431-2:2011] 2011. D-Cinema Quality — Reference Projector and Environment. http://pub.smpte.org/latest/rp431-2/rp0431-2-2011.pdf .
Для целей настоящего Стандарта применяются следующие определения.
Настоящая Часть Стандарта основана на концепциях, разработанных в [ISO 7498-1] and [ISO 7498-2] и использует следующие термины, определённые в них:
См. [ISO 7498-1].
См. [ISO 7498-1].
В данной Части Стандарта используются следующие термины, определённые в [ISO/TR 8509]:
См. [ISO/TR 8509].
В данной Части Стандарта используются следующие термины, определённые в PS3.1:
В данной Части Стандарта используются следующие термины, определённые в PS3.4:
В данной Части Стандарта используются следующие термины, определённые в PS3.5:
В данной Части Стандарта используются следующие термины, определённые в PS3.7:
В данной Части Стандарта используются следующие термины, определённые в PS3.8:
Описание условий, присутствовавших во время получения данных (data acquisition).
Последовательный компонент части протокола, относящейся к получению данных (acquisition), содержащий параметры, необходимые для выполнения одного получения. В случае КТ это соответствует напряжению на трубке, току трубки, времени вращения, пространственному положению и т.д., а элемент протокола получения также соответствует PROTOCOL ELEMENT из [NEMA XR-25]. В случае РА (XA) это соответствует техническим факторам и алгоритмам управления получением изображения, например, kVp, mA, длительности импульса, целевым показателям качества изображения, диапазону вращения и т.д.
Утвердительное заявление или декларация указанной сущности относительно указанного или подразумеваемого субъекта для указанной или подразумеваемой цели.
Уникальный идентификатор атрибута информационного объекта, состоящий из упорядоченной пары чисел (номера группы (Group Number), за которым следует номер элемента (Element number)).
Значение элемента данных (Data Element), соответствующего атрибуту информационного объекта.
Basic Directory Information Object Definition представляет собой абстракцию информации для идентификации набора файлов (File-set) и облегчения доступа к информации, хранящейся в файлах набора файлов, на основе ключевой медицинской информации.
Модель, определяющая отношения между различными типами записей каталога (Directory Records), которые могут использоваться при построении каталогов DICOM (DICOM Directories).
Информация и поведение, которые могут использоваться для смешивания (blending) двух или более наборов изображений в целях представления (программный просмотр, softcopy display).
Набор временно́ связанных кадров (Frames), полученных с постоянной или переменной частотой кадров. Этот термин включает общий класс сериографии (архаичный термин).
Значение атрибута, состоящее из элемента (Item) атрибута последовательности кодов (Code Sequence Attribute).
Атрибут, который (как правило) включает строку «Code Sequence» в имени атрибута (Attribute Name) и имеет VR SQ (Sequence of Items). Его назначение — кодировать концепты с использованием значений кодов и, опционально, текстовых значений из схем кодирования (Coding Schemes). Атрибуты, из которых строятся элементы последовательности (наборы атрибутов) атрибутов последовательности кодов, определены в разделах 8.1–8.8.
Информационная объектная дефиниция (IOD), представляющая части нескольких сущностей в прикладной модели DICOM (DICOM Application Model). Такой IOD включает атрибуты, не присущие непосредственно реальному объекту, который представляет IOD, а присущие связанным реальным объектам.
Изображение, данные пикселей которого были построены на основе данных пикселей одного или нескольких других изображений (исходных изображений).
Диаграмма «сущность-связь» (Entity-Relationship diagram), используемая для моделирования отношений между реальными объектами, входящими в область применения стандарта DICOM.
Диаграмма «сущность-связь», используемая для моделирования отношений между информационными объектными дефинициями, представляющими классы реальных объектов, определённых прикладной моделью DICOM.
Одна двумерная плоскость пикселей многокадрового изображения (Multi-frame Image).
Набор логически связанных атрибутов, значения которых, как правило, изменяются совместно. Может использоваться в многокадровых IOD для описания параметров, изменяющихся для каждого кадра.
Та часть информации, определённой составным IOD (Composite IOD), которая относится к одному конкретному классу реальных объектов. Между информационными сущностями и сущностями прикладной модели DICOM существует взаимно-однозначное соответствие.
Абстракция данных класса схожих реальных объектов, определяющая природу и атрибуты, относящиеся к представляемому классу реальных объектов.
Перечень исследований (Studies), серий (Series) и экземпляров SOP DICOM, а также связанных метаданных, управляемый системой-репозиторием.
Набор атрибутов в составе информационной сущности или нормализованного IOD, логически связанных между собой.
Изображение, содержащее несколько двумерных плоскостей пикселей.
Информационная объектная дефиниция, представляющая единственную сущность в прикладной модели DICOM. Такой IOD включает атрибуты, присущие исключительно реальному объекту, который представляет IOD.
Информация и поведение, которые могут использоваться для представления (программного просмотра, softcopy display) изображений.
Последовательный компонент протокола, состоящий из всех параметров, необходимых для выполнения данного компонента протокола.
Последовательный компонент части протокола, относящейся к реконструкции, например, генерация тонких срезов КТ или мультипланарных реформатов, либо генерация обработанных 2D-изображений РА или 3D-рентгеновских изображений.
Выбранное подмножество отсчётов (samples) в пределах набора данных, определённое для конкретной цели.
Параметры, определяющие выбор исследований DICOM, включаемых в инвентарь (Inventory). Параметры задаются в виде правил соответствия для значений атрибутов.
Часть целого, например классификация пикселей на изображении.
Специализация (Specialization) — это замена Type, диапазона значений и/или описания атрибута в общем модуле IOD его Type, диапазоном значений и/или описанием, определёнными в модуле IOD, специфичном для модальности.
Один и тот же атрибут может присутствовать в нескольких модулях одного IOD, не будучи заданным как «специализированный» («Specialized»).
Последовательный компонент части протокола, относящейся к хранению, например отправка серии изображений в PACS, архив или рабочую станцию обработки.
В данной Части Стандарта используются следующие термины, определённые в [ISO/IEC 2022]:
См. [ISO/IEC 2022].
См. [ISO/IEC 2022].
См. [ISO/IEC 2022].
Настоящая Часть Стандарта основана на концепциях, разработанных в [IEC 61217] и использует следующие термины, определённые в нём:
См. [IEC 61217].
См. [IEC 61217].
См. [IEC 61217].
См. [IEC 61217].
См. [IEC 61217].
См. [IEC 61217].
См. [IEC 61217].
См. [IEC 61217].
В данной Части Стандарта используются следующие термины, определённые в PS3.14:
В данной Части Стандарта используются следующие термины, определённые в PS3.16:
В данной Части Стандарта используются следующие термины, определённые в [ISO 7498-2]:
Определение: «Данные, добавленные к единице данных, или криптографическое преобразование единицы данных, позволяющее получателю единицы данных доказать источник и целостность этой единицы и защититься от подделки, например, со стороны получателя».
Определение: «свойство, заключающееся в том, что информация не становится доступной или не раскрывается неавторизованным лицам, сущностям или процессам».
Определение: «подтверждение того, что источник полученных данных соответствует заявленному».
Определение: «свойство, заключающееся в том, что данные не были изменены или уничтожены несанкционированным образом».
Определение: «генерация, хранение, распространение, удаление, архивирование и применение ключей в соответствии с политикой безопасности».
В данной Части Стандарта используются следующие термины, определённые в [ECMA 235]:
В данной Части Стандарта используются следующие термины, определённые в PS3.15:
RCS — это пространственная система координат в DICOM Frame of Reference. Она представляет собой выбранное начало отсчёта, ориентацию и пространственный масштаб IE Image в декартовом пространстве. RCS является правой декартовой системой координат, то есть векторное произведение единичного вектора вдоль положительной оси x и единичного вектора вдоль положительной оси y равно единичному вектору вдоль положительной оси z. Единица длины равна одному миллиметру. Как правило, IE Image содержит пространственное отображение, определяющее соответствие между отсчётами изображения и декартовыми пространственными областями RCS.
Роговичная система координат (Corneal Coordinate System) используется в качестве Frame of Reference, устанавливающей пространственное отношение относительно вершины роговицы (corneal vertex). Вершина роговицы — это точка, расположенная на пересечении линии взгляда пациента (зрительной оси) и наружной поверхности роговицы. Дополнительные пояснения см. в разделе C.8.30.3.1.4.
Фидуциальная метка (fiducial) — это уникальный признак или ориентир, пригодный в качестве пространственного эталона или для сопоставления между схожими объектами. Фидуциальная метка может способствовать определению начала отсчёта и ориентации выбранной системы координат. Идентификация фидуциальных меток в разных наборах данных — распространённый способ установления пространственного соответствия между схожими объектами.
Фидуциальная точка (Fiducial Point) определяет конкретное местоположение фидуциальной метки. Фидуциальная точка задаётся относительно изображения или относительно RCS.
Также называется Multi-Planar Reformatting. Визуализация данных, создаваемая путём выборки объёмных данных, как правило представленная стопкой плоскостей изображения, расположенной вблизи пересечения объёма с плоскостью, изогнутой плоскостью, слоем (slab) или изогнутым слоем.
MPR, в котором отсчёты центрированы на единственной плоскости, пересекающей объём.
Presentation State, определяющий преобразование из трёхмерных пространственных входных данных (объёма) в двумерные пространственные выходные данные, с возможным влиянием на другие измерения, например временное.
Reference Coordinate System, к которой регистрируются входные данные Volumetric Presentation State и к которой (если не указано иное) привязаны значения атрибутов Volumetric Presentation State.
Представление объёмных данных с двумя пространственными измерениями.
В данной Части Стандарта используются следующие термины, некоторые из которых определены в PS3.14 или [IEC 62563-1]:
Часть системы отображения (Display System). Подсистема отображения (Display Subsystem) состоит из одного устройства отображения (Display Device) и нуля или более других устройств (например, контроллеров). Система отображения включает одну или несколько подсистем отображения.
См. [IEC 62563-1].
В данной Части Стандарта используются следующие термины, определённые в PS3.14:
Буквенно-цифровой идентификатор, присваиваемый системой уникальной идентификации устройств (unique device identification system), созданной FDA, для маркировки и идентификации устройств на протяжении их распространения и использования. См. http://www.fda.gov/udi.
Узел дерева содержимого (Content Tree) документа DICOM SR, представляющий собой либо контейнер с кодированным именем концепта (Concept Name), либо пару имя-значение с кодированным именем концепта и значением концепта (Concept Value).
Дерево элементов содержимого (Content Items) документа DICOM SR.
В данной Части Стандарта используются следующие термины, определённые в PS3.10:
В настоящей части стандарта используются следующие символы и сокращения.
Comité Européen de Normalisation - Technical Committee 251 - Medical Informatics
Computer-Aided Detection and/or Computer-Aided Diagnosis for chest radiography
International Telecommunications Union - Telecommunications Standardization Sector
Japan Medical Imaging and Radiological Systems Industries Association
Computer-Aided Detection and/or Computer-Aided Diagnosis for Mammography
Сущность (entity) используется в модели «сущность-связь» (Entity-Relationship, E-R) для представления реального объекта, класса реальных объектов или представления данных DICOM (например, IOD или модуля). Сущность изображается, как показано на Рисунке 5.1-1.
Связь (relationship), определяющая, как связаны сущности, изображается в настоящей Части стандарта DICOM в виде ромба, как показано на Рисунке 5.1-2.
Связь читается от исходной сущности к целевой в направлении, указанном стрелками. Буквы a и b обозначают соответственно кардинальность исходной и целевой сущностей связи. Допускаются следующие значения кардинальности:
(a = 1, b = 1) — одна исходная сущность связана с одной целевой сущностью
(a = 1, b = 0-n) — одна исходная сущность связана с нулём или более целевых сущностей
(a = 1, b = 1-n) — одна исходная сущность связана с одной или более целевых сущностей
(a = 1-n, b = 1) — одна или более исходных сущностей связаны с одной целевой сущностью
(a = 1-n, b = 0-n) — одна или более исходных сущностей связаны с нулём или более целевых сущностей
(a = 1-n, b = 1-n) — одна или более исходных сущностей связаны с одной или более целевых сущностей
В связи, где (a = 1-n, b = 1-n), значения кардинальности исходной и целевой сущностей могут отличаться. Значение «n» просто означает «один или более».
DICOM добавил использование стрелок к условным обозначениям E-R-диаграмм, часто применяемым в другой литературе. Это сделано во избежание возможности вывести неверную связь, что может произойти при чтении связи в порядке, обратном предполагаемому. Например, связь «Кошка ловит мышь» могла бы быть прочитана как «Мышь ловит кошку», если бы стрелки отсутствовали.
Связь может быть двунаправленной (то есть верной в обоих направлениях). В этом случае используется условное обозначение в виде стрелок, направленных как на исходную, так и на целевую сущность.
Некоторые таблицы настоящего Стандарта описывают последовательности элементов (Sequences of Items) с использованием символа «>». Символ «>» предшествует имени атрибута (или модуля), являющегося членом элемента (Item). Все отмеченные атрибуты (или модули) относятся к общему описанию элемента, который может повторяться, образуя последовательность элементов. Эта последовательность элементов вложена в атрибут (или модуль), предшествующий в таблице первому члену, отмеченному символом «>».
Следующая таблица описывает атрибут «Referenced Series Sequences» как последовательность из одного или более элементов, каждый из которых содержит три атрибута, отмеченных символом «>». Последовательность элементов вложена в значение атрибута Referenced Series Sequence. Следующий атрибут (не отмеченный) не входит в элементы последовательности.
Эта нотация может использоваться для создания вложенных иерархических структур с помощью «>>» на втором уровне вложенности и так далее.
Type атрибута-последовательности определяет, должен ли сам атрибут-последовательность присутствовать, а описание атрибута-последовательности может определять, должны ли и сколько элементов должно присутствовать в последовательности. Types атрибутов набора данных, входящего в последовательность, включая любую условность, задаются в рамках каждого набора данных, то есть для каждого элемента, присутствующего в последовательности. См. PS3.5.
Для описания количества элементов в описании атрибута предпочтительны следующие формулировки:
Кодирование пустых атрибутов-последовательностей описано в PS3.5.
В ряде случаев для нормализованных IOD Type и условия элемента данных определены в соответствующей дефиниции службы в PS3.4, в других случаях — в описании атрибута в PS3.3. Для любого атрибута внутри последовательности нет необходимости указывать условие «требуется, если присутствует элемент последовательности», поскольку это всегда подразумевается, независимо от наличия дополнительных требований.
Данный раздел объявлен устаревшим (Retired). См. Раздел 8.
Некоторые таблицы содержат ссылки на макросы атрибутов (Attribute Macros). Это условное обозначение используется в случаях, когда одни и те же атрибуты используются в нескольких таблицах или в нескольких местах одного модуля. Ссылка означает, что атрибуты макроса атрибутов должны быть включены в модуль вместо строки, содержащей ссылку на макрос атрибутов.
В некоторых случаях макрос атрибутов используется в последовательности (VR элемента данных, в котором закодирован атрибут, равен SQ, см. PS3.5). В этом случае ссылке предшествует один или более символов «>». Количество символов «>» указывает уровень в последовательности, который занимают все атрибуты в макросе атрибутов.
Может выполняться специализация описания атрибутов в макросе атрибутов. В таких случаях эта специализация описывается в столбце «Description» модуля.
Ниже приведён пример этого условного обозначения.
Таблица 5.4-1 представляет собой пример таблицы модуля, использующей условное обозначение макроса атрибутов.
Таблица 5.4-2 — это пример макроса атрибутов, на который есть ссылка в Таблице 5.4-1.
Содержимое примера таблицы модуля, если бы оно не было описано с использованием примера макроса, выглядело бы, как показано в Таблице 5.4-3.
Таблица 5.4-3. Пример таблицы модуля без использования макроса атрибутов (Example Module Table Without The Use of An Attribute Macro)
|
в данном модуле данный атрибут был специализирован до Type 1, как указано в Таблице 5.4-1. |
Когда нормализованный IOD в PS3.3 использует модули (например, SOP Common Module) или макросы атрибутов, заданные с Types элементов данных, эти заданные Types и условия элементов данных не применяются. Вместо этого Types и условия элементов данных должны быть заданы для каждого атрибута как для SCU, так и для SCP в соответствующей дефиниции службы в PS3.4.
Для атрибутов последовательности кодов (Code Sequences) используются следующие условные обозначения:
См. также «Codes and Controlled Terminology Definitions» в PS3.16 .
В сочетании с определением группы контекста как Extensible или Non-extensible в PS3.16, применяются условные обозначения, приведённые в Таблице 5.6-1.
Таблица 5.6-1. Условные обозначения для задания групп контекста (Conventions for Specification of Context Groups)
|
Может использоваться любой код, если его значение применимо к контексту вызова. |
||
|
Могут использоваться коды из группы контекста. Вместо кодов из группы контекста могут использоваться альтернативные коды для того же концепта (то есть с тем же значением), поскольку это может расцениваться как отказ от использования Baseline Context Group. Коды, не входящие в группу контекста, могут использоваться как расширение, если их значение находится в пределах области действия этой группы контекста. То есть может использоваться любой код, если его значение применимо к контексту вызова. См. также Section 7.2.3 “Extension of Context Groups” в PS3.16 . |
Non-extensible группы контекста не используются в качестве Baseline Context Group. |
|
|
Должны использоваться коды из группы контекста. Коды, не входящие в группу контекста, могут использоваться как расширение указанной группы контекста, если их значение находится в пределах области действия этой группы контекста. См. также Section 7.2.3 “Extension of Context Groups” в PS3.16 . |
Должны использоваться коды из группы контекста. Коды, не входящие в группу контекста, использоваться не должны. |
|
Информационная модель DICOM определяет структуру и организацию информации, относящейся к передаче медицинских изображений. Рисунок 6-1 показывает отношения между основными структурами информационной модели DICOM.
Рисунок 6-1. Основные структуры информационной модели DICOM (Major Structures of DICOM Information Model)
Информационная объектная дефиниция (Information Object Definition, IOD) — это объектно-ориентированная абстрактная модель данных, используемая для задания информации о реальных объектах. IOD предоставляет взаимодействующим прикладным сущностям (Application Entities) общее представление об обмениваемой информации.
IOD представляет не конкретный экземпляр реального объекта, а класс реальных объектов, обладающих общими свойствами. IOD, используемый для представления, как правило, одного класса реальных объектов, называется нормализованным информационным объектом (Normalized Information Object). IOD, включающий информацию о связанных реальных объектах, называется составным информационным объектом (Composite Information Object).
Составной IOD (Composite IOD) — это IOD, представляющий части нескольких сущностей, входящих в модель реального мира DICOM (DICOM Model of the Real World). Эта модель представлена в Разделе 7. Такой IOD включает атрибуты, не присущие непосредственно реальному объекту, который представляет IOD, а присущие связанным реальным объектам.
Эти связанные реальные объекты обеспечивают полный контекст обмениваемой информации. При передаче экземпляра составного IOD между прикладными сущностями передаётся весь этот контекст. Отношения между экземплярами составных IOD должны передаваться в этой контекстной информации.
Составные IOD определены в Приложении A.
Нормализованный IOD (Normalized IOD) — это IOD, представляющий, как правило, одну сущность в модели реального мира DICOM.
При передаче экземпляра нормализованного IOD контекст для этого экземпляра фактически не передаётся. Вместо этого контекст предоставляется посредством указателей на связанные экземпляры нормализованных IOD.
Нормализованные IOD определены в Приложении B.
Атрибуты IOD описывают свойства экземпляра реального объекта. Связанные атрибуты группируются в модули, представляющие более высокий уровень семантики, документированный в спецификациях модулей, приведённых в Приложении C.
Атрибуты кодируются как элементы данных (Data Elements) с использованием правил, концепций представления значения (Value Representation) и кратности значения (Value Multiplicity), заданных в PS3.5. Для конкретных элементов данных представление значения и кратность значения заданы в словаре данных (Data Dictionary) в PS3.6.
Если в IOD включены несколько модулей, содержащих один и тот же атрибут(ы), атрибут должен быть закодирован в элемент данных только один раз.
Для онлайн-обмена службы DIMSE позволяют прикладной сущности DICOM вызывать операцию или уведомление через сеть или интерфейс «точка-точка». Службы DIMSE определены в PS3.7.
Для обмена через хранение на носителях службы хранения на носителях (Media Storage Services) позволяют прикладной сущности DICOM вызывать операции, связанные с хранением на носителях.
Эти службы хранения на носителях рассматриваются в PS3.10.
Группа служб DIMSE (DIMSE Service Group) задаёт одну или более операций/уведомлений, определённых в PS3.7, применимых к IOD.
Группы служб DIMSE определены в PS3.4 в спецификации класса пары сервис-объект (Service-Object Pair Class).
Дефиниции классов SOP в PS3.4 содержат правила и семантику, которые могут ограничивать использование служб в группе служб DIMSE и/или атрибуты IOD. PS3.10 и PS3.18 содержат правила и семантику, которые могут ограничивать атрибуты IOD или использование служб соответственно в службах хранения на носителях и веб-службах.
Выбор классов SOP используется прикладными сущностями для установления согласованного набора возможностей поддержки их взаимодействия для классов SOP на основе служб DIMSE. Это согласование выполняется во время установления ассоциации, как описано в PS3.7. Расширенное согласование позволяет прикладным сущностям дополнительно согласовать конкретные опции в рамках класса SOP.
Класс SOP, как он определён в информационной модели DICOM, эквивалентен в терминологии ISO/OSI классу управляемого объекта (Managed Object Class). Читатели, знакомые с объектно-ориентированной терминологией, узнают в операциях (и уведомлениях) класса SOP методы класса объекта.
DICOM определяет два типа классов SOP: нормализованные и составные. Для служб DIMSE нормализованные классы SOP определяются как объединение нормализованного IOD и набора служб DIMSE-N, тогда как составные классы SOP определяются как объединение составного IOD и набора служб DIMSE-C. Службы хранения на носителях поддерживают только составные IOD, а веб-службы поддерживают как нормализованные, так и составные классы SOP.
Спецификации классов SOP играют центральную роль в определении требований соответствия DICOM. Они позволяют прикладным сущностям DICOM выбирать чётко определённое подмножество стандарта DICOM V3.0 на прикладном уровне, соответствие которому они могут заявить. См. PS3.2.
Установление ассоциации — это первая фаза взаимодействия между равноправными прикладными сущностями, совместимыми с DICOM. Прикладные сущности должны использовать установление ассоциации для согласования того, какие классы SOP могут быть переданы и как эти данные будут закодированы.
Согласование ассоциации определено в PS3.7.
Спецификация сервисного класса определяет группу из одного или более классов SOP, относящихся к конкретной функции, которая должна быть выполнена взаимодействующими прикладными сущностями. Спецификация сервисного класса также определяет правила, позволяющие реализациям заявлять некоторый заранее определённый уровень соответствия одному или нескольким классам SOP. Приложения могут соответствовать классам SOP в роли Service Class User (SCU), Service Class Provider (SCP) или обеих ролей.
Спецификации сервисных классов определены в PS3.4.
Рисунок 7-1a, Рисунок 7-1b и Рисунок 7-3 изображают представление DICOM о реальном мире, определяющее релевантные реальные объекты и их отношения в рамках области применения стандарта DICOM. Это обеспечивает общую основу для согласованности между различными информационными объектами, определёнными стандартом DICOM.
Хотя, как правило, одна серия пространственно определяется одной Frame of Reference, могут возникать ситуации, в которых серия содержит некоторые экземпляры без определённой Frame of Reference.
Рисунок 7-2d. Информационная модель DICOM — IMPLANT TEMPLATES (DICOM Information Model - IMPLANT TEMPLATES)
Рисунок 7-3. Модель реального мира для интерфейса Modality-IS (Model of the Real World for the Purpose of Modality-IS Interface)
Информационная модель DICOM производна от модели реального мира DICOM. Информационная модель DICOM, представленная на Рисунке 7-2b, Рисунке 7-2c и Рисунке 7-2d, определяет различные IOD, заданные настоящим Стандартом, и их отношения. Взаимно-однозначное соответствие между IOD DICOM и реальными объектами существует не всегда. Например, составной IOD содержит атрибуты нескольких реальных объектов, таких как серия (Series), оборудование (Equipment), Frame of Reference, исследование (Study) и пациент (Patient).
Сущности на Рисунке 7-2b, Рисунке 7-2c и Рисунке 7-2d соответствуют IOD, определённым в Приложении A, Приложении B и Приложении C.
Приложение A определяет составные IOD (например, изображения), получаемые на ряде модальностей (например, CT, MR, NM, US, CR, Secondary Capture). Эти составные IOD ссылаются на модули, приведённые в Приложении C.
Приложение B определяет нормализованные IOD (например, Film Session, Print Job) для ряда сервисных классов, заданных в PS3.4. Эти нормализованные IOD ссылаются на дефиниции модулей, приведённые в Приложении C.
Для целей сервисного класса Basic Worklist Management и классов SOP Modality Performed Procedure Step выполнено расширение исходной модели реального мира DICOM, как показано на Рисунке 7-3.
Приложение B «Integration of Modality Worklist and Modality Performed Procedure Step in The Original DICOM Standard (Informative)» в PS3.17 рассматривает связь этого расширения с исходной моделью реального мира DICOM.
Рисунок 7-3 представляет собой абстрактное описание объектов реального мира, задействованных в интерфейсе Modality-IS. Его не следует рассматривать как схему базы данных для реализации.
Пациент (Patient) — это человеческий или иной организм, получающий или зарегистрированный для получения медицинских услуг, либо являющийся субъектом одного или более исследований (Studies) для иной цели, например, для научных исследований.
В некоторых случаях несколько людей или иных организмов могут исследоваться одновременно и для целей модели идентифицируются как один пациент. Например, мать и один или более плодов при дородовом акушерском УЗИ, несколько образцов в едином тканевом микрочипе, или группа из нескольких лабораторных животных, визуализируемых одновременно.
Эпизод обслуживания (Service Episode) — это совокупность событий, объединённых в интервале, ограниченном временем начала и окончания. Эпизод обслуживания — это контекст, в котором происходит лечение или ведение произвольного подмножества медицинских состояний пациента. Определение времени начала, времени окончания и включённых событий эпизода обслуживания совершенно произвольно; он может включать одно амбулаторное посещение или госпитализацию, либо охватывать значительный период времени, например продолжительность беременности, курс онкологического лечения или кардиологический эпизод от инфаркта до реабилитации. Эпизод обслуживания может затрагивать одну или более медицинских организаций (Healthcare Organizations) (административных сущностей, уполномочивающих поставщиков медицинских услуг (Healthcare Providers) оказывать услуги в пределах их юридической административной области, например, больницы, частные врачебные кабинеты, многопрофильные клиники, дома престарелых).
Подмножество эпизода обслуживания, визит (Visit), — это совокупность событий, входящих в зону ответственности конкретной медицинской организации в рамках одного учреждения. Визит может быть связан с одним или более физическими местоположениями (например, разными кабинетами, отделениями или зданиями) в пределах определения учреждения медицинской организацией, с диагнозами при поступлении и выписке, а также с временны́ми границами визита.
Визит является частью эпизода обслуживания. Эпизод обслуживания описывает несколько административных аспектов медицинского обслуживания, тогда как визит ограничен описанием одного посещения пациентом учреждения.
В контексте класса SOP Modality Worklist атрибуты эпизода обслуживания определены в модулях Visit.
Атрибуты для Visit по историческим причинам часто используют термин «admission» («поступление»), хотя посещение амбулаторной клиники не подразумевает поступления в качестве стационарного пациента.
Запрос на визуализационное обслуживание (Imaging Service Request) — это набор из одной или более запрошенных процедур (Requested Procedures), выбранных из перечня типов процедур (Procedure Types). Запрос на визуализационное обслуживание подаётся одним авторизованным заказчиком визуализационного обслуживания одному авторизованному поставщику визуализационного обслуживания в контексте одного эпизода обслуживания. Запрос на визуализационное обслуживание включает релевантную специфическую и общую информацию. Каждый экземпляр запроса на визуализационное обслуживание несёт информацию, общую для одной или более запрошенных процедур, запрошенных одновременно. Запрос на визуализационное обслуживание может быть связан с одним или более визитами, происходящими в рамках одного эпизода обслуживания. Наличие запроса на визуализационное обслуживание обычно приводит к созданию одного или более отчётов о визуализационном обслуживании (Imaging Service Reports) и их рассылке на одно или более мест назначения.
В контексте Modality Worklist информация, предоставляемая запросом на визуализационное обслуживание, направлена на выполнение одной или более визуализационных процедур, то есть на получение новых изображений.
Запрос на визуализационное обслуживание идентифицируется по Accession Number (0008,0050), который обычно является номером, генерируемым информационной системой отделения, но может генерироваться более комплексной системой, охватывающей отделения или предприятия. Область уникальности Accession Number (0008,0050) определяется его эмитентом (issuer), который может быть закодирован в Issuer of Accession Number Sequence (0008,0051).
Тип процедуры (Procedure Type) идентифицирует класс процедур. В контексте визуализационного обслуживания тип процедуры — это элемент каталога визуализационных процедур, который может быть запрошен и по которому может быть составлен отчёт в учреждении визуализационного обслуживания. Экземпляр типа процедуры, как правило, имеет наименование и один или более других идентификаторов. Тип процедуры связан с одним или более планами процедур (Procedure Plans).
Запрошенная процедура (Requested Procedure) — это экземпляр процедуры данного типа процедуры. Экземпляр запрошенной процедуры включает все элементы информации, заданные экземпляром плана процедуры (Procedure Plan), выбранным для запрошенной процедуры поставщиком визуализационного обслуживания. Этот план процедуры определяется поставщиком визуализационного обслуживания на основе шаблонов планов процедур, связанных с рассматриваемым типом процедуры. Запрос на визуализационное обслуживание может включать запросы на несколько различных запрошенных процедур. Назначение данной сущности — установить связь между запросами на визуализационное обслуживание и типами процедур, передать информацию, относящуюся к этой связи, и установить отношения между запрошенными процедурами и другими сущностями, необходимыми для их описания. Одна запрошенная процедура одного типа процедуры является наименьшей единицей обслуживания, которая может быть запрошена, включена в отчёт, закодирована и выставлена к оплате. Выполнение одного экземпляра запрошенной процедуры задаётся ровно одним планом процедуры. Запрошенная процедура приводит к одному или более запланированным этапам процедуры (Scheduled Procedure Steps), включающим протоколы, заданные планом процедуры. Запрошенная процедура может быть связана с одним или более визитами. Запрошенная процедура может задействовать одну или более единиц оборудования.
Запланированный этап процедуры модальности (Modality Scheduled Procedure Step) — это произвольно определённая запланированная единица обслуживания, задаваемая планом процедуры для запрошенной процедуры. Запланированный этап процедуры модальности предписывает протокол, который может идентифицироваться одним или более кодами протокола. Запланированный этап процедуры модальности задействует оборудование (например, оборудование визуализационной модальности, анестезиологическое оборудование, хирургическое оборудование, транспортировочное оборудование), людские ресурсы, расходные материалы, местоположение и время (например, время начала, время окончания, продолжительность). Хотя в контексте визуализационного обслуживания планирование запланированного этапа процедуры модальности может включать лишь общее обозначение визуализационной модальности, которому может соответствовать несколько единиц оборудования одного типа, выполнение одного экземпляра запланированного этапа процедуры модальности задействует одну и только одну единицу оборудования визуализационной модальности.
Выполнение запланированного этапа процедуры модальности может привести к созданию нуля или более экземпляров Modality Performed Procedure Step.
Сущность Procedure Step предусмотрена для поддержки управления логистическими аспектами процедур (например, управление материалами, людскими ресурсами, планирование). Полное определение содержимого этапов процедуры и протоколов, согласно которым они выполняются, зависит от реализации и выходит за рамки настоящего Стандарта.
Запланированный этап процедуры модальности может относиться более чем к одной запрошенной процедуре (например, запланированный этап процедуры модальности, требующий внутривенного введения йодного контраста, может быть общим для внутривенной пиелографии и КТ-исследования). Однако для целей выставления счетов экземпляр запланированного этапа процедуры модальности, как правило, считается частью только одной запрошенной процедуры.
План процедуры (Procedure Plan) — это спецификация, определяющая набор протоколов, которые должны быть выполнены для выполнения запланированных этапов процедуры запрошенной процедуры. Каждый запланированный этап процедуры выполняется согласно одному протоколу, который может идентифицироваться одним или более кодами протокола и может быть описан в Defined Procedure Protocol. Протоколы, фактически выполненные в ходе этапа процедуры, могут быть зафиксированы в Performed Procedure Protocol и могут отличаться от предписанных в соответствующем плане процедуры. Сверка фактически выполненных протоколов с предписанным планом процедуры является важным элементом контроля качества.
Протокол (Protocol) — это спецификация действий, предписанных планом процедуры для выполнения конкретного этапа процедуры. Запланированный этап процедуры содержит только один протокол, который может передаваться одним или более кодами протокола.
Протокол может задаваться Defined Procedure Protocol для использования на любом подходящем пациенте.
После выполнения этапа процедуры протокол может быть задокументирован в Performed Procedure Protocol.
Defined Procedure Protocol описывает набор параметров и связанных деталей для предписанного действия. Defined Procedure Protocol может предоставлять конкретные значения для релевантных параметров либо задавать ограничения на эти параметры (например, допустимый диапазон) для определения выбора конкретных значений.
Defined Procedure Protocol не связан с каким-либо конкретным пациентом или запланированным этапом процедуры. Defined Procedure Protocol может содержать параметры, специфичные для конкретной модели или версии устройства, либо быть общим, описывая только параметры, общие для нескольких моделей устройств.
Defined Procedure Protocol может включать такую информацию, как клиническое назначение, показания и подходящие модели устройств, предназначенную для выбора и управления.
Performed Procedure Protocol кодирует использованные значения параметров. Performed Procedure Protocol всегда связан с конкретным пациентом и Performed Procedure Step. Performed Procedure Protocol может ссылаться на Defined Procedure Protocol, на котором он основан, но иначе не фиксирует исходные ограничения и то, были ли они соблюдены итоговыми значениями, зафиксированными в Performed Procedure Protocol.
Выполненный этап процедуры (Performed Procedure Step) — это произвольно определённая единица обслуживания, которая была фактически выполнена (а не просто запланирована). Логически он соответствует запланированному этапу процедуры, однако реальные условия могут диктовать, что фактически выполненное не полностью соответствует запрошенному или запланированному.
Например, два или более запланированных этапа процедуры, запрошенные процедуры или запросы на визуализационное обслуживание могут быть сформированы разными направляющими врачами (Referring Physicians), но могут быть удовлетворены одним выполненным этапом процедуры по усмотрению выполняющего врача (Performing Physician) или оператора. В качестве альтернативы, для удовлетворения одного запланированного этапа процедуры могут потребоваться несколько выполненных этапов процедуры на разных типах или экземплярах оборудования вследствие клинической необходимости, условий сбоя или в течение продолжительного периода времени.
Он содержит информацию, описывающую тип фактически выполненной процедуры. Эта информация представлена Performed Protocol, который может задаваться одним или более кодами протокола.
Запрошенная процедура приводит к созданию нуля или более выполненных этапов процедуры.
Запланированный этап процедуры приводит к созданию нуля или более выполненных этапов процедуры.
Выполненный этап процедуры содержит информацию о своём состоянии (например, выполняется, прерван или завершён).
Modality Performed Procedure Step (MPPS) — это выполненный этап процедуры, являющийся результатом активности (такой как получение изображений от пациента или иного визуализируемого субъекта) на модальности.
Он содержит информацию, описывающую выполнение этапа визуализационной процедуры, включая данные о выполнении самой процедуры и данные для выставления счетов и управления материалами.
Modality Performed Procedure Step содержит ссылки на ноль или более серий изображений и другие составные экземпляры SOP, которые могут быть созданы в рамках этапа процедуры. Конкретная серия является частью только одного Modality Performed Procedure Step.
Назначение Modality Performed Procedure Step — сообщать о том, что было выполнено; он не подразумевает какой-либо семантики хранения. Хотя MPPS представляет собой единицу обслуживания в рамках рабочего процесса (workflow), спецификация самого рабочего процесса выходит за рамки настоящего Стандарта, и MPPS не идентифицирует и не управляет какими-либо последующими действиями, подлежащими выполнению.
Например, модальность может создавать как изображения «for processing» для автоматизированного анализа, так и изображения «for presentation» для просмотра человеком из одного и того же получения. Стандарт не определяет, является ли создание этих изображений одной единицей обслуживания или двумя. Один экземпляр Modality Performed Procedure Step может перечислять как изображения «for processing», так и изображения «for presentation», независимо от того, были ли оба набора изображений сохранены в одну и ту же AE или в разные AE, либо вообще сохранены, поскольку MPPS не зависит от семантики хранения. В качестве альтернативы модальность может рассматривать эти два набора изображений как две отдельные единицы обслуживания и отправлять два отдельных экземпляра MPPS.
Structured Report о дозе облучения (Radiation Dose Structured Report, RDSR) от событий облучения при получении может ссылаться на тот же экземпляр MPPS, что и полученные изображения, опять же независимо от того, куда такой Radiation Dose Structured Report может быть передан, если вообще будет. В качестве альтернативы модальность может рассматривать создание Radiation Dose Structured Report (RDSR) как отдельную единицу обслуживания и сообщать о нём в отдельном MPPS.
Другой пример — случай тонко- и толстослойных КТ-изображений, полученных из одних и тех же исходных (raw) данных получения. Если реконструкция обоих наборов изображений заранее определена и автоматически инициируется выбором протокола, то на оба набора можно сослаться из одного экземпляра MPPS. Однако если реконструкция одного или другого набора выполняется ретроспективно посредством ручного вмешательства через некоторое время после завершения MPPS получения, последующие экземпляры обязательно будут указаны в новом экземпляре MPPS, поскольку MPPS получения не может быть изменён после завершения.
Завершение MPPS может быть значимым событием, инициирующим или обеспечивающим последующую активность, однако не предполагается требование настройки модальности для «управления» такой активностью. «Единицы обслуживания», которые модальность описывает в MPPS, и то, как модальность соотносит эти выполненные этапы процедуры с запланированными этапами процедуры, являются решениями по реализации, выходящими за рамки настоящего Стандарта. Профиль IHE Radiology Scheduled Workflow [IHE RAD TF-1] предоставляет дополнительные рекомендации по реализации.
MPPS может описывать экземпляры, которые были получены, но не были и, возможно, никогда не будут сохранены. Например, модальность может быть способна сохранить КТ-получение как несколько однокадровых экземпляров SOP CT Image Storage, как один многокадровый экземпляр SOP Enhanced CT Image Storage, либо как несколько экземпляров SOP Enhanced CT Image Storage, вместе образующих конкатенацию (Concatenation). MPPS может описывать все три возможности, даже если в итоге будет сохранён только один вариант, возможно, в зависимости от согласованных возможностей получателя хранения. В качестве альтернативы для разных классов SOP хранения могут использоваться отдельные экземпляры MPPS.
MPPS содержит только экземпляры, созданные модальностью, а не экземпляры, преобразованные и созданные впоследствии в ответ на запрос (например, при конвертации устаревших данных).
MPPS не является заменой и не эквивалентен запросу Storage Commitment или Instance Availability Notification.
Устарело (Retired). См. PS3.3-2011.
Устарело (Retired). См. PS3.3-2011.
Устарело (Retired). См. PS3.3-2011.
Клинический документ (Clinical Document) — это часть медицинской карты пациента. Клинический документ представляет собой документирование клинических наблюдений и услуг и обладает следующими характеристиками:
Постоянство (Persistence) — клинический документ продолжает существовать в неизменном состоянии в течение периода времени, определённого локальными и регуляторными требованиями.
Ответственное хранение (Stewardship) — клинический документ поддерживается организацией, которой доверено его хранение.
Возможность аутентификации (Potential for authentication) — клинический документ представляет собой совокупность информации, предназначенную для юридического удостоверения.
Контекст (Context) — клинический документ устанавливает контекст по умолчанию для своего содержимого.
Целостность (Wholeness) — аутентификация клинического документа применяется ко всему документу и не применяется к отдельным его частям вне полного контекста документа.
Читаемость человеком (Human readability) — клинический документ читаем человеком.
Клинические документы могут предоставлять значимый контекст для выполнения визуализационных и связанных процедур, например, клинический анамнез пациента, результаты лабораторных исследований до визуализационной процедуры, или предварительные медицинские распоряжения пациента.
Клинические документы могут быть связаны с эпизодами обслуживания, запросами на обслуживание, запрошенными процедурами или другими сущностями, подчинёнными пациенту в модели реального мира. Такие связи явно не моделируются для целей контекста Modality-IS.
Клинические документы являются одним из подклассов класса структурированных документов здравоохранения (Structured Documents); структурированные документы в общем случае не обязательно связаны с пациентом. Структурированные документы могут использоваться для операционных инструкций визуализационных процедур, например, в маркировке продукции, планах процедур или планах ухода за пациентом.
Формат и семантика структурированных документов, включая клинические документы, определяются вне рамок стандарта DICOM (например, HL7). DICOM предоставляет средства для ссылки на структурированные документы в контексте Modality-IS.
Общий класс структурированных документов не моделируется в модели реального мира; моделируются только конкретные подклассы, например, клинические документы.
Устарело (Retired). См. PS3.3-2011.
Для размещения больших наборов кадров (Frames) в экземплярах SOP многокадровых изображений диаграмма «сущность-связь» реального мира была расширена для описания отношений этих экземпляров: конкатенация (Concatenation) (см. Раздел 7.5.1) и организация измерений (Dimension Organization) (см. Раздел 7.5.2). Рисунок 7.5-1 изображает дополнения к Рисунку 7-1a.
Рисунок 7.5-1. Расширение модели реального мира конкатенациями и измерениями (Extension of the Real World Model with Concatenations and Dimensions)
По причинам, специфичным для реализации (таким как практические ограничения на максимальный размер отдельного экземпляра SOP), содержимое многокадрового изображения может потребоваться разделить более чем на один экземпляр SOP. Эти экземпляры SOP вместе образуют конкатенацию (Concatenation) — группу экземпляров SOP в пределах серии, однозначно идентифицируемую по Concatenation UID (0020,9161).
Организация измерений содержит набор измерений. Измерение (dimension) — это набор атрибутов, изменяющихся для каждого кадра образом, известным до получения изображения, определяемых генерирующим приложением и специально предназначенных для представления. Другие атрибуты также могут изменяться для каждого кадра, однако если они не присутствуют в организации измерений, они не считаются значимыми в качестве измерения для целей организации.
Принимающие приложения должны использовать порядок измерений в качестве ориентира при представлении изображений, если присутствует Multi-frame Dimension Module. Первый элемент Dimension Index Sequence должен быть наиболее медленно изменяющимся индексом.
См. пример в Разделе C.7.6.17.
Модель реального мира DICOM расширена для клинических испытаний и исследований добавлением нескольких объектов, отношения которых друг с другом и с существующими объектами реального мира DICOM показаны на Рисунке 7.6-1.
Атрибуты объектов Clinical Trial Sponsor, Clinical Trial Protocol, Clinical Trial Subject и Clinical Trial Site представлены в Clinical Trial Subject Module в составе Patient IE. Атрибуты объекта Clinical Trial Time Point представлены в Clinical Trial Study Module в составе Study IE. Атрибут Clinical Trial Coordinating Center представлен в Clinical Trial Series Module в составе Series IE.
Рисунок 7.6-1. Модель реального мира DICOM — клинические испытания и исследования (DICOM Model of the Real World - Clinical Trials and Research)
Для целей информации о клинических испытаниях и исследованиях выполнено расширение модели реального мира DICOM, как показано на Рисунке 7.6-1.
Clinical Trial Sponsor идентифицирует агентство, группу или учреждение, ответственное за проведение и/или финансирование клинического испытания или исследования, а также за присвоение идентификатора протокола (Protocol Identifier).
Clinical Trial Protocol идентифицирует исследовательский протокол, в который включён субъект (Subject). Протокол имеет идентификатор протокола (Protocol Identifier) и имя протокола (Protocol Name), а также информацию, связанную с одобрением этическим комитетом (Ethics Committee), Institutional Review Board (IRB) или Institutional Animal Care and Use Committees (IACUC).
Clinical Trial Subject идентифицирует пациента, включённого в качестве субъекта в исследовательский протокол.
Clinical Trial Site идентифицирует местоположение или учреждение, в котором субъект проходит лечение или обследование и которое отвечает за подачу данных клинического испытания или исследования. Изображения и/или данные клинического испытания для данного субъекта могут собираться в альтернативных учреждениях, например, контрольные сканирования в спутниковом визуализационном центре, однако Clinical Trial Site представляет собой основное место ведения пациента и подачи данных в контексте клинического испытания или исследования. В доклинических исследованиях с лабораторными животными это, как правило, единственная лаборатория или совместно используемый ресурсный объект.
Clinical Trial Time Point идентифицирует визуализационное исследование в контексте серии продольных (longitudinal) получений данных в исследовательском протоколе. Time Point определяет набор исследований, объединённых как клиническая временная точка или подача данных в клиническом испытании либо ином исследовании.
Clinical Trial Coordinating Center идентифицирует учреждение, ответственное за координацию сбора, управления, обработки и/или анализа изображений и связанных данных для субъектов, включённых в клиническое испытание или исследование. В рамках данного Clinical Trial Protocol может быть несколько Clinical Trial Coordinating Centers, каждый из которых обрабатывает различные аспекты клинических данных, подаваемых Clinical Trial Sites. В доклинических исследованиях с лабораторными животными это может быть учреждение, где выполняется постобработка, отдельное от лаборатории, где данные получены.
См. Раздел 7.13.
См. Раздел 7.13.
Модель реального мира DICOM расширена для образцов (Specimens) добавлением нескольких объектов, отношения которых друг с другом и с существующими объектами реального мира DICOM показаны на Рисунке 7.9-1.
Атрибуты объектов Specimen, Container, Component и Preparation Step представлены в Specimen Module в составе Image IOD.
Физический объект (или совокупность объектов) является образцом (specimen), если лаборатория рассматривает его как единую дискретную, однозначно идентифицированную единицу, являющуюся субъектом одного или более этапов лабораторного (диагностического) рабочего процесса.
Контейнеры образцов (или просто «контейнеры») играют важную роль в лабораторных (диагностических) процессах. На большинстве, но не на всех этапах процесса образцы содержатся в контейнерах, и контейнер часто несёт ID своего образца. Иногда контейнер становится неотъемлемо связан с образцом (например, парафиновый блок), а в некоторых ситуациях (таких как исследование ткани под микроскопом) контейнер (предметное стекло и покровное стекло) становится частью оптического пути.
Контейнеры часто состоят из компонентов. Например, «предметное стекло» (slide) — это контейнер, состоящий из стеклянной пластины, покровного стекла и «клея», скрепляющего их вместе.
См. Раздел 7.13.
Модель реального мира DICOM расширена добавлением объекта Unified Procedure Step, отношение которого к существующим объектам реального мира DICOM показано на Рисунке 7.11-1.
Рисунок 7.11-1. Модель реального мира DICOM — Unified Procedure Step (DICOM Model of the Real World - Unified Procedure Step)
Unified Procedure Step (UPS) представляет собой произвольную единицу обслуживания. Unified Procedure Steps, как правило, планируются в ответ на запрошенную процедуру, хотя UPS может быть инициирован и другими событиями, такими как запланированная калибровка, завершение предшествующей работы в конвейере и т.д.
Unified Procedure Step (UPS) объединяет детали запрошенного этапа процедуры, детали хода выполнения и детали фактически выполненного этапа процедуры. Эти детали могут описывать конкретную сервисную активность, субъект и/или данные, над которыми выполняется действие, инициатора и контекст запроса, задействованные человеческие/аппаратные/прикладные ресурсы, приоритет, дату, время и местоположение активности, а также ссылки на итоговые выходные данные.
Обычно детали фактически выполненной активности соответствуют деталям запрошенной активности, однако реальные условия могут диктовать, что фактически выполненное не полностью соответствует запрошенному или запланированному.
Модель реального мира DICOM расширена для системы отображения (Display System) добавлением сущности, отдельной от остальных объектов реального мира DICOM, как показано на Рисунке 7.12-1. Display System не связана с какими-либо конкретными объектами существующей информационной модели DICOM, поскольку не связана с конкретным пациентом. Один объект Display System включён в Display System IOD.
Рисунок 7.12-1. Модель реального мира DICOM — система отображения (DICOM Model of the Real World - Display System)
Подсистема отображения (Display Subsystem) представляет собой цель задачи Display QA, такой как калибровка. Например, станция чтения PACS с одним цветным контроллером, управляющим одним дисплеем, и 4 полутоновыми дисплеями, каждый из которых управляется двумя контроллерами, моделируется как 5 подсистем отображения, каждая из которых может быть целью задачи Display QA. Планшет представляет собой одну систему отображения с устройством отображения (Display Device), но без внешне доступного контроллера. Хотя подсистема отображения может включать компоненты помимо устройства отображения, данная модель фокусируется только на устройстве отображения.
Рисунок 7.12-2. Состав подсистемы отображения в Display System IOD (Display Subsystem Composition in the Display System IOD)
Рисунок 7.12-2 иллюстрирует, как состав подсистем отображения представлен в Display System IOD.
Модель реального мира DICOM расширена для различной не связанной с пациентом информации заданием сущностей, как правило, отдельных от остальной информационной модели реального мира DICOM. Эти информационные сущности не связаны с конкретным пациентом. Хотя между сущностями могут существовать отношения, к этим сущностям не применяется какая-либо иерархия.
Информационная сущность Hanging Protocol задаёт предпочтения просмотра конкретного пользователя или группы для конкретного типа исследования (сочетание Modality, Anatomy, Laterality и, опционально, Procedure и/или Reason). Дефиниция Hanging Protocol включает дескрипторы, идентифицирующие Hanging Protocol, его создателя, тип исследования, к которому он относится, тип наборов изображений для отображения, предполагаемую среду отображения и предполагаемую компоновку экрана(ов).
IE Hanging Protocol не имеет каких-либо отношений с другими информационными сущностями. См. Рисунок 7.13-1.
Рисунок 7.13-1. Модель реального мира DICOM — Hanging Protocol (DICOM Model of the Real World - Hanging Protocol)
Информационная сущность Color Palette задаёт цветовую палитру, пригодную для применения к изображению с одним информационным каналом (полутоновому), для отображения его в цвете, то есть псевдоокрашивания.
На IE Color Palette могут ссылаться информационные сущности изображения (Image) или Presentation State. См. Рисунок 7.13-2.
Color Palette IOD инстанцирует только IE Color Palette.
Рисунок 7.13-2. Модель реального мира DICOM — цветовая палитра (DICOM Model of the Real World - Color Palette)
Информационная сущность Implant Template задаёт 2D- и/или 3D-шаблон, представляющий физический имплант. IE задаёт механизмы для сборки имплантов (implant assembly), то есть жёсткого соединения двух или более имплантов.
IE Implant Template может быть связан с IE Surface (см. Раздел A.1.2.18) или с IE Encapsulated Document (см. Раздел A.1.2.16) для задания 2D- или 3D-шаблона.
IE Implant Template может быть связан с IE Frame of Reference (см. Раздел A.1.2.5) для поддержки регистрации шаблона с анатомическими ориентирами пациента в отдельной Frame of Reference.
IE Implant Template может быть связан с IE Implant Assembly Template для задания составных сборок из нескольких частей. IE Implant Template может быть связан с IE Implant Template Group для совместного управления набором шаблонов.
См. Рисунок 7.13-3.
Рисунок 7.13-3. Модель реального мира DICOM — шаблоны имплантов (DICOM Model of the Real World - Implant Templates)
Информационная сущность Implant Assembly Template задаёт способ объединения нескольких имплантов для достижения определённой цели.
Модель реального мира DICOM расширена добавлением объектов Defined Procedure Protocol и Performed Procedure Protocol, отношение которых к существующим объектам реального мира DICOM показано на Рисунке 7.13.4-1.
Обратите внимание, что информация в IE Equipment описывает оборудование, создавшее экземпляр. Информация в параметрах протокола может описывать оборудование, на котором предполагается выполнять протокол, которое может как совпадать, так и не совпадать с оборудованием, создавшим экземпляр.
Рисунок 7.13.4-1. Модель реального мира DICOM — хранение протоколов (DICOM Model of the Real World - Protocol Storage)
Информационная сущность Approval описывает утверждение экземпляра.
Рисунок 7.13.5-1. Модель реального мира DICOM — утверждение (DICOM Model of the Real World - Approval)
Рисунок 7.13.6-1 показывает диаграмму «сущность-связь» для информационной модели Inventory. Информационная сущность Inventory предоставляет инвентарь исследований и составляющих их серий и экземпляров SOP, управляемый репозиторием (таким как система архивирования и передачи изображений — PACS). Информационная модель Inventory включает контекстную информацию о каждом исследовании через IE Patient и Imaging Service Request. Она включает информацию о хранимых экземплярах SOP, в том числе о механизмах доступа, поддерживаемых репозиторием.
Данная информационная модель аналогична Study Root Query/Retrieve Information Model (см. раздел C.6.2.1 в PS3.4).
Между исследованием и запросами на визуализационное обслуживание в реальном мире может существовать потенциально сложная связь (см., например, [IHE RAD TF-2], раздел 4.6.4.1.2.3 «Relationship between Scheduled and Performed Procedure Steps»). Однако информационная модель Inventory следует базовой информационной модели Study и поддерживает только один Accession Number, представляющий запрос на визуализационное обслуживание (см. Раздел C.7.2.1). Обратите внимание, что если с исследованием связано несколько запросов на визуализационное обслуживание, атрибуты запроса могут кодироваться на уровне серии.
Рисунок 7.13.6-1. Диаграмма «сущность-связь» информационной модели Inventory (Inventory Information Model E-R Diagram)
Для целей классов SOP RT Second Generation модель реального мира DICOM описана в настоящем разделе. Данное подмножество модели реального мира охватывает требования по передаче информации о запланированном и выполненном радиотерапевтическом лечении и связанных данных.
Рисунок 7.14-1 описывает наиболее важные элементы, задействованные в области радиотерапии в DICOM.
Рисунок 7.14-1. Модель реального мира DICOM — радиотерапия (DICOM Model of the Real World - Radiotherapy)
IOD, содержащие представление объёмов (Volumes), поверхностей (Surfaces), линий (Lines), точек (Points), могут быть аннотированы посредством RT Segment Annotation.
Для лучшей читаемости диаграмма содержит только наиболее важные отношения, например, все объекты имеют отношение к пациенту, однако не все эти отношения являются частью данной диаграммы.
RT Course — это сущность верхнего уровня, представляющая курс радиотерапевтического лечения, обычно задаваемый одним или более RT Prescriptions, как правило, для определённой опухоли или группы опухолей. У пациента, проходящего радиотерапевтическое лечение, в каждый момент времени активен один курс лечения. RT Course может состоять из нескольких RT Treatment Phases (возможно, с перерывами в лечении между ними). Каждая фаза лечения может состоять из одного или более RT Treatment Sessions. RT Treatment Session проводится за один визит пациента в место с лечебным аппаратом и, как правило, доставляет фракцию одного или более RT Radiation Sets. Новый RT Course назначается, когда пациент лечится по поводу рецидива или нового очага опухоли — как правило, спустя год или более после завершения предыдущего RT Course.
RT Course можно рассматривать как контейнер, собирающий все основные объекты, относящиеся к данному курсу. RT Physician Intent и RT Radiation Sets ссылаются на другие сопутствующие объекты, необходимые для подготовки, проведения и анализа лечения. Информация о времени (даты начала и фазирование лечения, перерывы и т.д.) также является частью информации RT Course. Кроме того, он содержит информацию о текущем статусе планирования и проведения лечения. RT Course — это динамический объект, представляющий текущий статус лечения пациента.
RT Course может также включать информацию о ранее проведённом лечении посредством ссылок на предыдущие объекты RT Course либо путём непосредственной фиксации информации в атрибутах.
RT Physician Intent описывает, каким образом врач намерен достичь излечивающей или паллиативной терапии. Эта информация включает, помимо прочего, использование внешней лучевой терапии или брахитерапии, суммарные и фракционные дозы и схемы фракционирования, области лечения, дозиметрические цели (Dosimetric Objectives), предполагаемую методику лечения, энергию пучка или изотопы, а также примечания по укладке пациента.
Conceptual Volume — это ссылка на определённую анатомическую область или точку. Conceptual Volumes могут иметь или не иметь представления в сегментированных изображениях. В большинстве случаев они будут связаны с одним или более объёмными представлениями в различных наборах изображений, полученных в разное время.
Например, в ходе курса радиотерапии на этапе назначения врачи задают области, для которых предписывается доза. Впоследствии на эти области ссылаются другие объекты для отслеживания рассчитанной и доставленной дозы в ходе лечения. Эту возможность ссылки обеспечивает Conceptual Volume.
RT Segment Annotation аннотирует сегментированные области, заданные в других экземплярах SOP, специфичной для радиотерапии информацией о роли и RT-специфичных типах областей (например, clinical target volume, organ at risk, bolus), а также другой информацией, такой как определения плотности. Экземпляр SOP RT Segment Annotation может ссылаться на любую сущность геометрического представления общего назначения, определённую DICOM.
RT Radiation Set — это совокупность RT Radiations. RT Radiation Set определяет фракцию радиотерапевтического лечения, которая будет применена один или более раз. RT Radiation Set доставляется путём доставки излучения всех указанных RT Radiations.
Параллельные и прерывистые схемы фракционирования, например лечение нескольких целевых областей с разными временными схемами, представляются несколькими RT Radiation Sets.
RT Radiation — это непрерывный набор контрольных точек (Control Points), описывающих параметры аппарата и позиционирования, применяемые при доставке лечения. RT Radiation описывает одну часть RT Radiation Set и представляет однофракционную доставку терапевтического излучения, предназначенную для доставки неделимым образом. В терминологии конечного пользователя RT Radiation обычно называют пучком (beam) (при дистанционной лучевой терапии) или катетером (при брахитерапии).
RT Radiation Record фиксирует фактические параметры лечения, применённые при доставке RT Radiation в контексте конкретной фракции. Как правило, эти параметры совпадают с описанными в составе RT Radiation, но могут отличаться вследствие решений специалиста и/или обстоятельств технологии доставки, и/или по различным другим причинам.
RT Course может быть разделён на несколько RT Treatment Phases. Каждая RT Treatment Phase представляет период времени, в течение которого определённое количество RT Treatment Fractions доставляется посредством RT Radiation Sets для достижения конкретной цели лечения (см. Раздел 7.14.9 и Раздел 7.14.10).
RT Treatment Phase также определяет хронологическую связь между RT Radiation Sets, лечение которыми проводится одновременно и/или последовательно.
Фракционирование (Fractionation) описывает разделение курса доставки терапевтического излучения на несколько сеансов. Каждый сеанс может состоять из доставки одного или более RT Radiation Sets. Временна́я схема сеансов называется схемой фракционирования (fractionation scheme).
Дополнительные описания и примеры таких схем приведены в Разделе 7.14.10.
RT Treatment Session — это совокупность событий RT-лечения, выполняемых непрерывным образом без каких-либо перерывов между ними (кроме времени, необходимого для требуемой подготовки), в рамках одного визита. Она ограничена периодом времени между входом пациента в процедурный кабинет и выходом из него. В рамках сеанса лечения может проводиться лечение одним или более RT Radiation Sets (RSet на Рисунке 7.14-2), каждый из которых задаётся RT Radiation Set Delivery Instruction. RT Treatment Session может также включать визуализацию. Группа доставок излучения, разделённых намеренной задержкой для учёта эффектов радиобиологического восстановления, рассматривается как отдельные Treatment Sessions.
Treatment Session UID (300A,0700), если присутствует, однозначно идентифицирует RT Treatment Session.
Каждое лечение RT Radiation Set обозначается как RT Treatment Fraction (часто сокращается как Fx) с номером фракции, начинающимся с 1 на первой RT Treatment Session, на которой доставляется RT Radiation Set, и увеличивающимся на 1 на каждом последующем сеансе лечения.
RT Treatment Fraction — это доставка части суммарной дозы (доставка которой определяется RT Radiation Set), равномерно разделённой на меньшие дозы, доставляемые в течение периода времени (например, ежедневно в течение 4–6 недель). В радиотерапии такое разделение дозы во времени называется фракционированием дозы (dose fractionation).
Частичные лечения (partial treatments) обозначают RT Treatment Fractions, которые по какой-либо причине не были выполнены полностью (например, из-за недомогания пациента, поломки аппарата доставки). Оставшаяся часть RT Treatment Fraction обычно доставляется позднее. Эта оставшаяся часть имеет тот же номер фракции, что и Partial Treatment Fraction. Последующие лечения начнут новую RT Treatment Fraction с увеличенным номером фракции.
На Рисунке 7.14-3 заштрихованные области каждого Radiation Set представляют часть, в которой доза фактически доставлена. Таким образом, частично заштрихованные Radiation Sets представляют частичное лечение.
Макрос Dosimetric Objective задаёт предполагаемую цель, используемую при определении дозиметрического плана для оптимизации плана и т.д. Dosimetric Objectives могут задавать ограничения, влияющие на дозу, такие как ограничения объёма дозы, минимальную или максимальную дозу, ограничения по времени лечения или MU, а также радиобиологические эффекты.
Основным способом включения кодированных данных записей в IOD DICOM является атрибут последовательности кодов (Code Sequence Attribute). Атрибуты последовательности кодов кодируются как последовательность элементов (Sequence of Items) с использованием макроса, описанного в настоящем разделе. Эти атрибуты обычно включают строку «Code Sequence» в имени атрибута. Их назначение — кодировать термины с использованием кодов из схем кодирования (Coding Schemes).
В настоящем Стандарте атрибуты последовательности кодов определены для различных концептов, например: Primary Anatomic Structure Sequence (0008,2228) и другие атрибуты для описания анатомии; и Intervention Drug Code Sequence (0018,0029) для документирования введения лекарственных средств, имеющих особое значение для визуализационных процедур.
Каждый элемент атрибута последовательности кодов содержит триплет Coding Scheme Designator (0008,0102), Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120)) и Code Meaning (0008,0104). Также могут присутствовать другие опциональные и условные атрибуты.
Для любого конкретного атрибута последовательности кодов диапазон кодов, который может использоваться для этого атрибута (набор значений, Value Set), может быть предложен или ограничен заданием группы контекста (Context Group). Модуль или шаблон, в котором используется атрибут, определит, является ли группа контекста baseline или defined. Baseline Context Group перечисляет коды для терминов, которые предлагаются и могут использоваться, но не обязаны использоваться. Defined Context Group перечисляет коды для терминов, которые должны использоваться, если термин используется.
Группы контекста определяются в Mapping Resource, таком как DICOM Content Mapping Resource (DCMR), заданный в PS3.16. Группы контекста состоят из списков контекстно связанных кодированных концептов, включающих Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120)) и Coding Scheme Designator (0008,0102). Каждый концепт уникален в пределах группы контекста и идентифицируется своим Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120)) и Coding Scheme Designator (0008,0102). Спецификация группы контекста указывает, является ли она расширяемой (extensible), то есть может ли она быть изменена в приложении для использования дополнительных терминов (см. PS3.16). Используется ли группа контекста как Baseline или Defined Context Group, определяется не в самом mapping resource, а в шаблоне или модуле, в котором используется атрибут последовательности кодов.
Группы контекста идентифицируются метками, называемыми идентификаторами контекста (Context Identifiers, CID). Формально Context Identifier (0008,010F) задаёт контекст использования, а не конкретный список значений кодов, выбранных для этого контекста использования в группе контекста. Набор значений, заданный в Стандарте для конкретного контекста, может изменяться со временем, а набор значений, используемый прикладной сущностью для конкретного контекста, может включать локальное или частное расширение сверх набора значений Стандарта.
Таким образом, конкретный набор значений кодов, используемый прикладной сущностью, идентифицируется Mapping Resource (0008,0105) в сочетании с Context Identifier (0008,010F), Context Group Version (0008,0106) и идентификаторами любого частного расширения.
Использование прикладной сущностью кодированных терминов, отсутствующих в группе контекста, заданной Стандартом, не требует явной идентификации частного расширения. В этом случае прикладная сущность является неявным источником расширения.
Для целей согласования с концептами словаря HL7 группы контекста эквивалентны HL7 Value Sets.
Code Value (0008,0100) — это идентификатор, однозначный в пределах схемы кодирования (Coding Scheme), обозначенной Coding Scheme Designator (0008,0102) и Coding Scheme Version (0008,0103).
Long Code Value (0008,0119) или URN Code Value (0008,0120) используются только для кодов, превышающих ограничение размера Code Value (0008,0100) в 16 символов. Если длина значения кода превышает 16 символов, Code Value (0008,0100) не должен присутствовать. Если длина значения кода составляет 16 символов или менее, Code Value (0008,0100) должен содержать код, а Long Code Value (0008,0119) и URN Code Value (0008,0120) присутствовать не должны. URN Code Value (0008,0120) должен использоваться для кодов, представленных в нотации URN или URL. Long Code Value (0008,0119) должен использоваться для кодов, представленных в других нотациях и превышающих 16 символов в длину.
Атрибут Coding Scheme Designator (0008,0102) идентифицирует схему кодирования, в которой определён код для термина. Стандартные обозначения схем кодирования, используемые при обмене информацией DICOM, перечислены в PS3.16. Могут использоваться и другие обозначения схем кодирования, как частных, так и публичных, в соответствии с PS3.16. Дополнительная идентификация обозначений схем кодирования, используемых в экземпляре SOP, может быть приведена в Coding Scheme Identification Sequence (0008,0110) (см. Раздел C.12.1).
Типичные схемы кодирования, используемые в DICOM, включают «DCM» для кодов, определённых DICOM, «SCT» для SNOMED CT и «LN» для LOINC. См. Annex 8 «Coding Schemes» в PS3.16.
Обозначения схем кодирования, начинающиеся с «99», и обозначение схемы кодирования «L» определены в HL7 V2 как частные или локальные схемы кодирования.
Большинство IOD, определяющих использование кодированных терминов, предусматривают возможность использования частных кодов и схем кодирования путём замены Baseline Context Groups или расширения Defined Context Groups. Системы, поддерживающие такое использование частных кодов, должны предоставлять механизм настройки наборов Coding Scheme Designator (0008,0102), Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120)) и Code Meaning (0008,0104) для поддержки взаимодействия частных кодов с другими системами.
Настоятельно рекомендуется идентифицировать локальные или нестандартные схемы кодирования в Coding Scheme Identification Sequence (0008,0110). Документы или машиночитаемые представления схемы кодирования (например, файлы CSV или OWL) могут быть связаны через Coding Scheme URL (0008,010E). Подходящие значения см. в Таблице 8-1 «Coding Schemes» в PS3.16 .
Коды URN и URL обычно не имеют Coding Scheme Designator (0008,0102).
Атрибут Coding Scheme Version (0008,0103) может использоваться для идентификации версии схемы кодирования, если необходимо разрешить неоднозначность в Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Coding Scheme Version (0008,0103) не требуется для обратно совместимых редакций схемы кодирования, поскольку Coding Scheme Designator (0008,0102) идентифицирует схему кодирования в целом в том виде, в каком она в настоящее время опубликована ответственной организацией.
См. обсуждение обозначений схем кодирования SNOMED 99SDM, SNM3, SRT и SCT в PS3.16.
Например, ICD-10 не является обратно совместимой редакцией ICD-9, и поэтому имеет иное Coding Scheme Designator, а не просто другую Coding Scheme Version.
Code Meaning (0008,0104) — это текст, имеющий смысл для человека и передающий значение термина, определённого комбинацией Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120)) и Coding Scheme Designator (0008,0102). Хотя такое значение можно «найти» в словаре схемы кодирования, оно кодируется для удобства приложений, не имеющих доступа к такому словарю.
Следует отметить, что для конкретного Coding Scheme Designator (0008,0102) и Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120) может быть определено несколько альтернативных значений Code Meaning (0008,0104). Это могут быть синонимы на одном языке или переводы схемы кодирования на другие языки. Поэтому значение Code Meaning (0008,0104) никогда не должно использоваться в качестве ключа, индекса или значения для принятия решений — вместо этого может использоваться комбинация Coding Scheme Designator (0008,0102) и Code Value (0008,0100), Long Code Value (0008,0119) или URN Code Value (0008,0120). Code Meaning (0008,0104) является исключительно аннотативным, описательным атрибутом.
Это не означает, что Code Meaning (0008,0104) может заполняться произвольным свободным текстом. Должны использоваться доступные значения из схемы кодирования или перевод на выбранный язык.
Значение Mapping Resource (0008,0105) обозначает Mapping Resource сообщений/терминологии, задающий группу контекста, которая задаёт набор значений. Defined Terms для значения Mapping Resource (0008,0105) должны быть:
PS3.16 задаёт DICOM Content Mapping Resource (DCMR).
Если не указано иное, DCMR является источником всех групп контекста и шаблонов, заданных в настоящем Стандарте.
Mapping Resources могут однозначно идентифицироваться Mapping Resource UID (0008,0118).
Частные Mapping Resources (не перечисленные среди Defined Terms в настоящем разделе) могут идентифицироваться префиксом «99».
Mapping Resource Name (0008,0122) может содержать наименование Mapping Resource. Значение может, например, обозначать учреждение или организацию, задавшую набор значений (Value Set).
Context Group Version (0008,0106) передаёт версию группы контекста, идентифицированной Context Identifier (0008,010F). Данный атрибут использует VR DT, однако для групп контекста, заданных в PS3.16, точность Context Group Version (0008,0106) ограничена днём, а смещение часового пояса не используется.
Значение Context Identifier (0008,010F) идентифицирует группу контекста, заданную Mapping Resource (0008,0105), из которой были выбраны значения Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120)) и Code Meaning (0008,0104), либо к которой Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120)) и Code Meaning (0008,0104) были добавлены в качестве частного расширения группы контекста (см. Раздел 8.7). Context Identifier (0008,010F) использует VR CS, и для групп контекста, заданных в PS3.16, значением должен быть Context Group Identifier в виде строки цифр без ведущих нулей, не включающей строку «CID».
Значение Context UID (0008,0117) однозначно идентифицирует группу контекста. См. PS3.6.
Context Group Extension Flag (0008,010B) может использоваться для обозначения пары Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120)) и Code Meaning (0008,0104) как выбора из частного расширения группы контекста. Если Context Group Extension Flag (0008,010B) присутствует и имеет значение «Y», Context Group Extension Creator UID (0008,010D) должен использоваться для идентификации лица или организации, создавшей расширение группы контекста. Context Group Local Version (0008,0107) передаёт специфичную для реализации частную DateTime версии группы контекста, содержащей частные расширения.
Эти атрибуты предоставляют реализациям удобное средство для расширения наборов кодов при сохранении ссылочной целостности относительно исходной Context Group Version (0008,0106).
Локально заданное (частное) значение Context Group Local Version (0008,0107) обычно представляет собой более позднюю дату, чем стандартное значение Context Group Version (0008,0106), заданное в стандартном Mapping Resource сообщений/терминологии, определяющем группу контекста.
Таблица 8.8-1 задаёт набор атрибутов по умолчанию, инкапсулированных в элементах атрибутов последовательности кодов. Эти атрибуты составляют макрос Code Sequence Macro.
Инструкция «Include Table 8.8-1 “Code Sequence Macro Attributes” » может использоваться в IOD как краткий способ указать, что атрибуты Таблицы 8.8-1 включены в спецификацию набора атрибутов последовательности элементов. Дополнительные ограничения на элемент данных последовательности кодов (например, группа контекста, задающая набор значений) могут добавляться к инструкции «Include Table 8.8-1 “Code Sequence Macro Attributes” ».
Спецификации по умолчанию данного раздела переопределяются в пределах области действия элемента последовательности, атрибута последовательности кодов или IOD соответствующими спецификациями, заданными в пределах области действия этого элемента последовательности, атрибута последовательности кодов или IOD. Дополнительные атрибуты также могут задаваться при инстанцировании макроса.
Basic Coded Entry Attributes полностью определяют Coded Entry. Если требуется передать перечень, из которого был выбран код, дополнительно могут присутствовать опциональные Enhanced Encoding Mode Attributes.
Таблица 8.8-1a. Основные атрибуты макроса последовательности кодов (Basic Code Sequence Macro Attributes)
|
ОСНОВНЫЕ АТРИБУТЫ КОДИРОВАННОЙ ЗАПИСИ (BASIC CODED ENTRY ATTRIBUTES) |
|||
|
Идентификатор кодированной записи (Coded Entry). См. Раздел 8.1. Должен присутствовать, если длина значения кода составляет 16 символов или менее и значение кода не является URN или URL. |
|||
|
Идентификатор схемы кодирования, в которой определена кодированная запись. См. Раздел 8.2. Должен присутствовать, если присутствует Code Value (0008,0100) или Long Code Value (0008,0119). В остальных случаях может присутствовать. |
|||
|
Идентификатор версии схемы кодирования, если необходимо разрешить неоднозначность. См. Раздел 8.2. Требуется, если значение Coding Scheme Designator (0008,0102) присутствует и недостаточно для однозначной идентификации Code Value (0008,0100) или Long Code Value (0008,0119). Не должен присутствовать, если Coding Scheme Designator (0008,0102) отсутствует. В остальных случаях может присутствовать. |
|||
|
Текст, передающий смысл кодированной записи. См. Раздел 8.3. |
|||
|
Идентификатор кодированной записи (Coded Entry). См. Раздел 8.1. Должен присутствовать, если Code Value (0008,0100) не присутствует и значение кода не является URN или URL. |
|||
|
Идентификатор кодированной записи (Coded Entry). См. Раздел 8.1. Должен присутствовать, если Code Value (0008,0100) не присутствует и значение кода является URN или URL. |
|||
Таблица 8.8-1b. Расширенные атрибуты макроса последовательности кодов (Enhanced Code Sequence Macro Attributes)
|
Идентификатор группы контекста, из которой была выбрана кодированная запись. См. Раздел 8.6. |
|||
|
Уникальный идентификатор группы контекста, из которой была выбрана кодированная запись. См. Раздел 8.6. |
|||
|
Идентификатор Mapping Resource, задающего группу контекста, из которой была выбрана кодированная запись. См. Раздел 8.4. Требуется, если присутствует Context Identifier (0008,010F). |
|||
|
Уникальный идентификатор Mapping Resource, задающего группу контекста, из которой была выбрана кодированная запись. NoteУникальный идентификатор для DICOM Content Mapping Resource «DCMR» задан в PS3.6. |
|||
|
Наименование Mapping Resource, задающего группу контекста, из которой была выбрана кодированная запись. См. Раздел 8.4. |
|||
|
Идентификатор версии группы контекста, из которой была выбрана кодированная запись. См. Раздел 8.5. Требуется, если присутствует Context Identifier (0008,010F). |
|||
|
Указывает, выбран ли триплет Code Value (0008,0100) (либо Long Code Value (0008,0119), либо URN Code Value (0008,0120))/Coding Scheme Designator (0008,0102)/Code Meaning (0008,0104) из частного расширения группы контекста, идентифицированной в Context Identifier (0008,010F). См. Раздел 8.7. |
|||
|
Специфичная для реализации версия группы контекста, содержащей частные расширения. См. Раздел 8.7. Требуется, если значение Context Group Extension Flag (0008,010B) равно «Y». |
|||
|
Идентифицирует лицо или организацию, создавшую расширение группы контекста. См. Раздел 8.7. Требуется, если значение Context Group Extension Flag (0008,010B) равно «Y». |
Таблица 8.8-1. Атрибуты макроса последовательности кодов (Code Sequence Macro Attributes)
|
ОСНОВНЫЕ АТРИБУТЫ КОДИРОВАННОЙ ЗАПИСИ (BASIC CODED ENTRY ATTRIBUTES) |
|||
|
Include Table 8.8-1a |
|||
|
Коды, считающиеся эквивалентными создающей системой. В данной последовательности допускается один или более элементов. См. Раздел 8.9. |
|||
|
>Include Table 8.8-1a |
|||
|
>Include Table 8.8-1b |
|||
|
Include Table 8.8-1b |
|||
Equivalent Code Sequence (0008,0121) может опционально использоваться для передачи разных кодов для одного и того же концепта.
Эквивалентность определяется как наличие одинакового или схожего смысла и требует, чтобы эквивалентные концепты не включали различные аспекты, свойства, признаки, характеристики или параметры.
Например, коды SNOMED и FMA для анатомической структуры молочной железы, (76752008, SCT, "Breast") и (57983, FMA, "Breast"), считались бы эквивалентными. Ни один из них не был бы эквивалентен концептам, преждевременно координирующим другие аспекты, такие как латеральность, например, (80248007, SCT, "Left breast"), или орган целиком, например, (181131000, SCT, "Entire breast").
Некоторые сценарии, в которых создающей системе полезно передавать эквивалентные коды, включают:
когда в стандартной схеме кодирования присутствуют разные представления одного и того же концепта, например идентификаторы стиля SNOMED-CT, SNOMED-RT и CTV3,
когда один и тот же концепт присутствует в разных стандартных схемах кодирования, но считается создающей системой синонимичным, например анатомические концепты из SNOMED и FMA, и
когда один и тот же концепт присутствует как в локальной, так и в стандартной схеме кодирования, но считается создающей системой синонимичным, например локальный частный код процедуры и тот же концепт в LOINC, SNOMED или RADLEX.
Таблица 8.8-1b может использоваться для идентификации группы контекста, из которой были выбраны коды, например, для конкретного межучрежденческого, межприкладного контекста для испытаний, исследований и приложений, основанных на знаниях.
Пример кодирования длинного кода SNOMED CT как элемента последовательности:
SCT:621566751000087104 не входит в SNOMED CT DICOM Subset и отсутствует в редакции SNOMED CT INT. Он взят из Canadian National Extension и используется здесь исключительно в качестве примера.
Пример короткого кода SNOMED CT с эквивалентными кодами SNOMED SRT и CTV3 (Read) как элемента последовательности:
|
Dimeglumine gadopentetate 469.01mg/mL inj soln 15mL pfld syr |
||||
|
Dimeglumine gadopentetate 469.01mg/mL inj soln 15mL pfld syr |
||||
|
Dimeglumine gadopentetate 469.01mg/mL inj soln 15mL pfld syr |
||||
SCT:406400000 не входит в SNOMED CT DICOM Subset и используется здесь исключительно в качестве примера.
Пример кодирования длинного URN как элемента последовательности.
По мере сопровождения настоящего Стандарта и внешних схем кодирования коды, заданные в качестве значений для атрибутов последовательности кодов и в условиях, могут изменяться. Прежние коды считаются устаревшими (Retired), однако реализации могут продолжать их отправлять, и от получателей ожидается способность продолжать распознавать устаревшие коды, включая значения Code Value (0008,0100) и Coding Scheme Designator (0008,0102), даже если действующая редакция Стандарта их не публикует.
Заметный пример — переход во всём Стандарте от использования значений кода в «стиле SNOMED-RT» с Coding Scheme Designator (0008,0102), равным «SRT», «SNM3» или «99SDM», к использованию числовых значений кода SNOMED CT с Coding Scheme Designator (0008,0102), равным «SCT». Эти устаревшие коды можно найти в PS3.3-2019a. Сопоставление устаревших и новых значений кодов SNOMED приведено в Annex O «SNOMED Concept ID to SNOMED ID Mapping» в PS3.16.
Раздел 9 был определён в предыдущей редакции стандарта DICOM. См. PS3.3-2004. Раздел объявлен устаревшим (Retired), а его содержимое объединено в Разделе C.18.8.
Этот макрос может использоваться для указания кодированного представления лица, такого как медицинский работник, и организации, перед которой это лицо несёт ответственность.
Этот макрос обычно используется внутри элемента последовательности для идентификации отдельного лица, например врача или оператора устройства.
Текстовое имя лица в свободной форме не включено в этот макрос, поскольку для хранения таких значений уже широко используются специальные атрибуты.
Базовые (Baseline), определённые (Defined) или перечислимые (Enumerated) CID не заданы, как и какая-либо конкретная схема кодирования. На практике работники обычно идентифицируются с использованием локальной или национальной схемы кодирования. Например, может использоваться локальный обозначитель схемы кодирования (Coding Scheme Designator), а в качестве значения кода (Code Value) — внутренний больничный идентификационный номер лица.
Организация указывается либо кодированной последовательностью, либо текстовым именем в свободной форме, но не тем и другим одновременно. Для идентификации стандартных организаций, ответственных за создание общеизвестных экземпляров (Well Known Instances), предусмотрен базовый (Baseline) CID стандартных организаций.
Таблица 10-1. Атрибуты макроса идентификации личности (Person Identification Macro Attributes)
Элемент содержимого (Content Item) представляет собой гибкое средство кодирования идентификаторов и значений атрибутов с использованием макроса последовательности кода (см. раздел 8) для кодированной терминологии, определяемой схемой кодирования. Элемент содержимого предоставляет пару «имя-значение», то есть имя понятия (Concept Name), закодированное как последовательность кода, и значение понятия (Concept Value). Значение понятия может кодироваться с помощью любого набора общих атрибутов, определяемых типом значения (Value Type), включая текстовые, персональные, числовые значения и кодированные значения понятия (последовательность кода).
Если сравнивать элемент содержимого с нативным элементом данных DICOM, то Concept Name Code Sequence (0040,A043) соответствует тегу элемента данных и имени атрибута, Value Type — представлению значения (VR), а значение понятия — полю значения элемента данных. См. PS3.5.
Тип значения IMAGE в этом макросе не включает атрибуты типа 3 типа значения IMAGE, определённого в разделе C.17.3, поскольку они не требуются для элементов содержимого контекста получения (Acquisition Context) или контекста протокола (Protocol Context).
Конкретные варианты использования элемента содержимого могут вызывать макрос элемента содержимого, определённый в этом разделе, макрос содержимого документа из раздела C.17.3, либо иную аналогичную конструкцию. Вызов макроса элемента содержимого может ограничивать допустимые значения Value Type (0040,A040).
Тип значения NUMERIC в этом макросе отличается от типа значения NUM, определённого в разделе C.17.3, поскольку кодирование значения понятия отличается.
Value Type использует перечислимые значения (Enumerated Values), чтобы гарантировать неиспользование нестандартных типов значений и предотвратить недобросовестное использование, например, типа значения CONTAINER в стиле SR для создания вложенного содержимого, что не является целью данного макроса.
В некоторых случаях использования этого макроса может применяться Content Item Modifier Sequence (0040,0441) для достижения единственного уровня «вложенности». Этот атрибут не включён в сам макрос, чтобы предотвратить рекурсивное включение.
Значение столбца Type в этом макросе применительно к нормализованным IOD см. в разделе 5.4.
Таблица 10-2. Атрибуты макроса элемента содержимого (Content Item Macro Attributes)
|
Тип значения, закодированного в этом элементе «имя-значение». |
|||
|
Дата и время завершения этого элемента. Для целей регистрации измерений или журналирования событий временем завершения считается время окончания сбора данных измерения или время окончания события. |
|||
|
Дата и время начала этого элемента. Для целей регистрации измерений или журналирования событий временем начала считается момент окончания сбора данных измерения или момент начала события. |
|||
|
Кодированное имя понятия для этого элемента «имя-значение». В этой последовательности должен присутствовать только один элемент. |
|||
|
Значение DateTime для этого элемента «имя-значение». Обязателен, если Value Type (0040,A040) имеет значение DATETIME. |
|||
|
Значение Date для этого элемента «имя-значение». Обязателен, если Value Type (0040,A040) имеет значение DATE. |
|||
|
Значение Time для этого элемента «имя-значение». Обязателен, если Value Type (0040,A040) имеет значение TIME. |
|||
|
Значение имени лица для этого элемента «имя-значение». Обязателен, если Value Type (0040,A040) имеет значение PNAME. |
|||
|
Значение UID для этого элемента «имя-значение». Обязателен, если Value Type (0040,A040) имеет значение UIDREF. |
|||
|
Текстовое значение для этого элемента «имя-значение». Обязателен, если Value Type (0040,A040) имеет значение TEXT. |
|||
|
Кодированное значение понятия для этого элемента «имя-значение». В этой последовательности должен присутствовать только один элемент. Обязателен, если Value Type (0040,A040) имеет значение CODE. |
|||
|
Числовое значение для этого элемента «имя-значение». Должно присутствовать только одно значение. Обязателен, если Value Type (0040,A040) имеет значение NUMERIC. |
|||
|
Представление Numeric Value (0040,A30A) в виде числа с плавающей точкой. Должно присутствовать столько же значений, сколько в Numeric Value (0040,A30A). Обязателен, если точности Numeric Value (0040,A30A) недостаточно для представления значения в виде строки. В противном случае может присутствовать. |
|||
|
Целочисленный числитель рационального представления Numeric Value (0040,A30A), закодированный как знаковое целое значение. Должно присутствовать столько же значений, сколько в Numeric Value (0040,A30A). Обязателен, если точности Numeric Value (0040,A30A) недостаточно для представления рационального значения в виде строки. В противном случае может присутствовать. |
|||
|
Целочисленный знаменатель рационального представления Numeric Value (0040,A30A), закодированный как ненулевое беззнаковое целое значение. Должно присутствовать столько же значений, сколько в Numeric Value (0040,A30A). Обязателен, если присутствует Rational Numerator Value (0040,A162). |
|||
|
Единицы измерения числового значения в этом элементе «имя-значение». В этой последовательности должен присутствовать только один элемент. Обязателен, если Value Type (0040,A040) имеет значение NUMERIC. |
|||
|
Значение составной ссылки на экземпляр SOP (Composite SOP Instance Reference) для этого элемента «имя-значение». В этой последовательности должен присутствовать только один элемент. Обязателен, если Value Type (0040,A040) имеет значение COMPOSITE, IMAGE или WAVEFORM. |
|||
|
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Определяет номера кадров в пределах Referenced SOP Instance, к которым относится ссылка. Первый кадр обозначается номером 1. Обязателен, если Referenced SOP Instance является многокадровым изображением, ссылка распространяется не на все кадры, и отсутствует Referenced Segment Number (0062,000B). |
|||
|
Определяет сегменты, к которым относится ссылка, идентифицируемые Segment Number (0062,0004). Обязателен, если Referenced SOP Instance является Segmentation или Surface Segmentation, ссылка распространяется не на все сегменты, и отсутствует Referenced Frame Number (0008,1160). |
|||
|
Список каналов Waveform, к которым относится ссылка. См. раздел C.18.5.1.1. Обязателен, если Referenced SOP Instance является Waveform, содержащим несколько каналов, и ссылка распространяется не на все каналы всех Multiplex Groups. |
|||
Элемент содержимого с модификаторами — это средство описания структурированного содержимого, для которого требуется элемент содержимого с единственным опциональным уровнем модификаторов, то есть двухуровневая структура элементов содержимого. Вызов макроса элемента содержимого с модификаторами обычно определяет допустимые значения с помощью шаблона контекста протокола (Protocol Context Template) в PS3.16, который допускает единственный уровень вложенности (см. раздел 6.1.2 «Nesting Level (NL)» в PS3.16 ). Ограничения на использование этого макроса могут быть указаны в PS3.16 Annex C, который может вызываться в IOD в PS3.3.
Таблица 10.2.1-1. Атрибуты макроса элемента содержимого с модификаторами (Content Item with Modifiers Macro Attributes)
Таблица 10-3. Атрибуты макроса ссылки на экземпляр SOP изображения (Image SOP Instance Reference Macro Attributes)
|
Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Определяет номера кадров в пределах Referenced SOP Instance, к которым относится ссылка. Первый кадр обозначается номером 1. Обязателен, если Referenced SOP Instance является многокадровым изображением, ссылка распространяется не на все кадры, и отсутствует Referenced Segment Number (0062,000B). |
|||
|
Определяет номер сегмента, к которому относится ссылка. Обязателен, если Referenced SOP Instance является Segmentation или Surface Segmentation, ссылка распространяется не на все сегменты, и отсутствует Referenced Frame Number (0008,1160). |
|||
Таблица 10-3b «Referenced Instances and Access Macro Attributes» содержит идентификаторы и сведения о доступе для набора экземпляров. Она предназначена для предоставления достаточной информации для получения (retrieve) ссылочных экземпляров.
Таблица 10-3b. Атрибуты макроса ссылочных экземпляров и доступа к ним (Referenced Instances and Access Macro Attributes)
|
Уникальный идентификатор исследования (Study). Обязателен, если Type of Instances (0040,E020) имеет значение DICOM, а информационная модель ссылочного экземпляра содержит IE Study. |
|||
|
Уникальный идентификатор серии (Series), являющейся частью исследования, указанного в Study Instance UID (0020,000D), если он присутствует, и содержащей ссылочный(е) экземпляр(ы) объекта. Обязателен, если Type of Instances (0040,E020) имеет значение DICOM, а информационная модель ссылочного экземпляра содержит IE Series. |
|||
|
Ссылки на экземпляры объектов. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Идентификатор экземпляра инкапсулированного структурированного документа HL7, закодированный как UID (OID или UUID), объединённый с помощью символа «^» со значением Extension (если Extension присутствует в Instance Identifier). Обязателен, если Type of Instances (0040,E020) имеет значение CDA. |
|||
|
Определяет номера кадров в пределах Referenced SOP Instance, к которым относится ссылка. Первый кадр обозначается номером 1. Обязателен, если Referenced SOP Instance является многокадровым изображением, ссылка распространяется не на все кадры, и отсутствует Referenced Segment Number (0062,000B). |
|||
|
Определяет номер сегмента, к которому относится ссылка. Обязателен, если Referenced SOP Instance является Segmentation, ссылка распространяется не на все сегменты, и отсутствует Referenced Frame Number (0008,1160). |
|||
|
Сведения о получении (retrieve) экземпляров с помощью службы DICOM Retrieve. Обязателен, если отсутствуют DICOM Media Retrieval Sequence (0040,E022), WADO Retrieval Sequence (0040,E023), WADO-RS Retrieval Sequence (0040,E025) и XDS Retrieval Sequence (0040,E024). В противном случае может присутствовать. Эта последовательность должна идентифицировать только те источники, о которых известно, что они содержат экземпляры, указанные в Referenced SOP Sequence (0008,1199). В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Название прикладного объекта DICOM (Application Entity), с которого ссылочный(е) экземпляр(ы) может быть получен по сети. |
|||
|
Сведения о получении экземпляров с носителя (Media). Обязателен, если отсутствуют DICOM Retrieval Sequence (0040,E021), WADO Retrieval Sequence (0040,E023), WADO-RS Retrieval Sequence (0040,E025) и XDS Retrieval Sequence (0040,E024). В противном случае может присутствовать. Эта последовательность должна идентифицировать только те носители, о которых известно, что они содержат экземпляры, указанные в Referenced SOP Sequence (0008,1199). В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Понятный человеку идентификатор, специфичный для пользователя или реализации, идентифицирующий носитель хранения (Storage Media), на котором находится(ятся) ссылочный(е) экземпляр(ы). |
|||
|
Однозначно идентифицирует носитель хранения, на котором находится(ятся) ссылочный(е) экземпляр(ы). |
|||
|
Сведения о получении экземпляров, доступных через WADO-URI. NoteЭта последовательность относится к использованию URI-based Web Access to DICOM Objects (WADO-URI). Получение через транзакцию IHE XDS-I.b RAD-69 [IHE RAD TF-2] описывается в XDS Retrieval Sequence (0040,E024). Обязателен, если отсутствуют DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO-RS Retrieval Sequence (0040,E025) и XDS Retrieval Sequence (0040,E024). В противном случае может присутствовать. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
URI/URL, указывающий местоположение ссылочного(ых) экземпляра(ов). Включает полностью заданные схему, полномочия (authority), путь и запрос в соответствии с [RFC3986]. |
|||
|
Сведения о получении экземпляров с использованием транзакции IHE XDS-I.b RAD-69. NoteПолучение через WADO-URI описывается в WADO Retrieval Sequence (0040,E023). Получение через WADO-RS описывается в WADO-RS Retrieval Sequence (0040,E025). Обязателен, если отсутствуют DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO-RS Retrieval Sequence (0040,E025) и WADO Retrieval Sequence (0040,E023). В противном случае может присутствовать. Эта последовательность должна идентифицировать только те репозитории, о которых известно, что они содержат экземпляры, указанные в Referenced SOP Sequence (0008,1199). В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Однозначно идентифицирует репозиторий, из которого могут быть получены ссылочные экземпляры. |
|||
|
Однозначно идентифицирует сообщество (Community), в которое могут быть направлены запросы на ссылочные экземпляры. |
|||
|
Сведения о получении экземпляров через WADO-RS. NoteПолучение через WADO-URI описывается в WADO Retrieval Sequence (0040,E023). Получение через транзакцию IHE XDS-I.b RAD-69 [IHE RAD TF-2] описывается в XDS Retrieval Sequence (0040,E024). Обязателен, если отсутствуют DICOM Retrieval Sequence (0040,E021), DICOM Media Retrieval Sequence (0040,E022), WADO Retrieval Sequence (0040,E023) и XDS Retrieval Sequence (0040,E024). В противном случае может присутствовать. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
URL, указывающий местоположение ссылочного(ых) экземпляра(ов). |
Таблица 10-3c «Storage Macro Attributes» содержит сведения о том, где и как хранить экземпляры. Она предназначена для предоставления достаточной информации для сохранения экземпляров в нужном месте.
Этот макрос зеркально повторяет Таблицу 10-3b «Referenced Instances and Access Macro Attributes».
Таблица 10-3c. Атрибуты макроса хранения (Storage Macro Attributes)
|
Однозначно идентифицирует ссылочный класс SOP. Обязателен, если запрос на хранение относится только к конкретному классу SOP. |
|||
|
Сведения о хранении экземпляров с помощью службы DICOM Storage. Обязателен, если отсутствует STOW-RS Storage Sequence (0040,4072) или XDS Storage Sequence (0040,4074). В противном случае может присутствовать. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Название прикладного объекта DICOM (Application Entity), на который будут сохранены экземпляры. |
|||
|
Сведения о хранении экземпляров через STOW-RS. Обязателен, если отсутствуют DICOM Storage Sequence (0040,4071) и XDS Storage Sequence (0040,4074). В противном случае может присутствовать. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
URI/URL, указывающий местоположение службы хранения STOW-RS, на которую будут сохранены экземпляры. Значение должно представлять собой полностью заданный URI с протоколом, полномочиями (authority) и путём, в соответствии с [RFC3986] и разделом 10.5 «Store Transaction» PS3.18. |
|||
|
Сведения о хранении экземпляров с помощью транзакции IHE Provide and Register Document Set-b (ITI-41) [IHE ITI TF-2b]. Обязателен, если отсутствуют STOW-RS Storage Sequence (0040,4072) и DICOM Storage Sequence (0040,4071). В противном случае может присутствовать. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Однозначно идентифицирует репозиторий, из которого могут быть получены ссылочные экземпляры. |
|||
|
Однозначно идентифицирует сообщество (Community), в которое могут быть направлены запросы на ссылочные экземпляры. |
Таблица 10-4 определяет атрибуты макроса ссылки на серию и экземпляр, который перечисляет серии (Series) и экземпляры SOP в этих сериях.
Таблица 10-4. Атрибуты макроса ссылки на серию и экземпляр (Series and Instance Reference Macro Attributes)
|
Последовательность элементов, каждый из которых включает атрибуты одной серии. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Уникальный идентификатор серии, содержащей ссылочные экземпляры. |
|||
|
Последовательность элементов, каждый из которых предоставляет ссылку на экземпляр, являющийся частью серии, определённой значением Series Instance UID (0020,000E) в охватывающем элементе. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
Таблица 10-5, Таблица 10-6, Таблица 10-7 и Таблица 10-7b определяют атрибуты для идентификации общей области анатомии пациента, подвергнутой исследованию, с использованием кодированной терминологии, а также основной(ых) структуры(структур) в пределах этой области, являющейся(ихся) объектом текущего экземпляра SOP. Единственные различия между этими макросами — Type и число элементов последовательности Anatomic Region Sequence (0008,2218). Таблица 10-8 описывает атрибуты для кодирования только основной структуры.
Вызов этих макросов может задавать базовые (Baseline) или определённые (Defined) CID для Anatomic Region Sequence (0008,2218), Anatomic Region Modifier Sequence (0008,2220) и/или Primary Anatomic Structure Sequence (0008,2228).
Общая область тела (например, анатомическая область, орган или полость тела, подвергающиеся исследованию) определяется значением Anatomic Region Sequence (0008,2218). Характеристики исследуемой анатомической области, такие как субобласть (например, медиальная, латеральная, верхняя, нижняя, доля, квадрант) и латеральность (например, правая, левая, обе), могут уточняться с помощью Anatomic Region Modifier Sequence (0008,2220).
Эти атрибуты позволяют задавать информацию, кодируемую атрибутом Body Part Examined (0018,0015) в модуле General Series Module, более надёжным и согласованным способом.
Конкретные анатомические структуры интереса в пределах изображения (например, определённая артерия в пределах анатомической области) определяются значением Primary Anatomic Structure Sequence (0008,2228). Характеристики анатомической структуры, такие как её расположение (например, подкапсульное, периферическое, центральное), конфигурация (например, расширенная, сжатая) и латеральность (например, правая, левая, обе) и т. д., могут уточняться с помощью Primary Anatomic Structure Modifier Sequence (0008,2230).
Латеральность часто кодируется в отдельном атрибуте — Image Laterality (0020,0062) или Frame Laterality (0020,9072), а не в Anatomic Region Modifier Sequence (0008,2220) или Primary Anatomic Structure Modifier Sequence (0008,2230). Соответствие между значениями приведено ниже:
Приведённые коды взяты из CID 244 “Laterality”.
То, являются ли различные анатомические структуры парными или непарными (обладают ли латеральностью), показано в Table L-5 “Pairedness of Anatomic Concepts” in PS3.16.
Таблица 10-5. Атрибуты обязательного макроса общей анатомии (General Anatomy Mandatory Macro Attributes)
|
Последовательность, определяющая анатомическую область интереса в этом экземпляре (то есть внешнюю анатомию, анатомию поверхности или общую область тела). В этой последовательности должен присутствовать только один элемент. |
|||
|
Последовательность элементов, изменяющих анатомическую область интереса в этом экземпляре. В этой последовательности допускается один или несколько элементов. |
|||
|
DCID 2 “Anatomic Modifier”, если иное не определено при вызове макроса. |
|||
|
Include Table 10-8 “Primary Anatomic Structure Macro Attributes” |
|||
Таблица 10-6. Атрибуты требуемого макроса общей анатомии (General Anatomy Required Macro Attributes)
|
Последовательность, определяющая анатомическую область интереса в этом экземпляре (то есть внешнюю анатомию, анатомию поверхности или общую область тела). В этой последовательности допускается ноль или один элемент. |
|||
|
Последовательность элементов, изменяющих анатомическую область интереса в этом экземпляре В этой последовательности допускается один или несколько элементов. |
|||
|
DCID 2 “Anatomic Modifier”, если иное не определено при вызове макроса. |
|||
|
Include Table 10-8 “Primary Anatomic Structure Macro Attributes” |
|||
Таблица 10-7. Атрибуты необязательного макроса общей анатомии (General Anatomy Optional Macro Attributes)
|
Последовательность, определяющая анатомическую область интереса в этом экземпляре (то есть внешнюю анатомию, анатомию поверхности или общую область тела). |
|||
|
Последовательность элементов, изменяющих анатомическую область интереса в этом экземпляре В этой последовательности допускается один или несколько элементов. |
|||
|
DCID 2 “Anatomic Modifier”, если иное не определено при вызове макроса. |
|||
|
Include Table 10-8 “Primary Anatomic Structure Macro Attributes” |
|||
Таблица 10-7b. Атрибуты необязательного макроса общей анатомии для нескольких участков (Multiple Site General Anatomy Optional Macro Attributes)
|
Последовательность, определяющая анатомическую область интереса в этом экземпляре (то есть внешнюю анатомию, анатомию поверхности или общую область тела). В этой последовательности допускается один или несколько элементов. |
|||
|
Последовательность элементов, изменяющих анатомическую область интереса в этом экземпляре В этой последовательности допускается один или несколько элементов. |
|||
|
DCID 2 “Anatomic Modifier”, если иное не определено при вызове макроса. |
|||
|
Include Table 10-8 “Primary Anatomic Structure Macro Attributes” |
|||
Таблица 10-8. Атрибуты макроса основной анатомической структуры (Primary Anatomic Structure Macro Attributes)
Таблица 10-9. Атрибуты макроса атрибутов запроса (Request Attributes Macro Attributes)
|
Идентификатор, идентифицирующий Requested Procedure в составе Imaging Service Request. Обязателен, если процедура была запланирована (scheduled). В противном случае может присутствовать. NoteЭто условие позволяет содержимому данного макроса присутствовать (например, для указания причины проведения процедуры — например, является ли маммография скрининговой или диагностической) даже если процедура не была официально запланирована и значение этого идентификатора неизвестно, вместо того чтобы придумывать фиктивное значение. |
|||
|
Номер, сгенерированный информационной системой отделения, идентифицирующий Imaging Service Request. |
|||
|
Идентификатор органа, присвоившего (Assigning Authority) Accession Number. |
|||
|
>Include Table 10-17 “HL7v2 Hierarchic Designator Macro Attributes” |
|||
|
Уникальный идентификатор исследования (Study), предоставленный для данной Requested Procedure. |
|||
|
Однозначно идентифицирует исследования (Studies), связанные с данным экземпляром SOP. В этой последовательности допускается один или несколько элементов. См. раздел 10.6.1. |
|||
|
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Административное описание или классификация Requested Procedure, сформированные учреждением. |
|||
|
Последовательность, передающая Procedure Type запрошенной процедуры. |
|||
|
Кодированная причина запроса данной процедуры. В этой последовательности допускается один или несколько элементов. |
|||
|
Идентификатор, идентифицирующий Scheduled Procedure Step. Обязателен, если процедура была запланирована (scheduled). NoteЭто условие позволяет содержимому данного макроса присутствовать (например, для указания причины проведения процедуры — например, является ли маммография скрининговой или диагностической) даже если шаг процедуры не был официально запланирован и значение этого идентификатора неизвестно, вместо того чтобы придумывать фиктивное значение. |
|||
|
Описание или классификация выполняемого Scheduled Procedure Step, сформированные учреждением. |
|||
|
Последовательность, описывающая Scheduled Protocol в соответствии с определённой схемой кодирования. В этой последовательности допускается один или несколько элементов. |
|||
|
Последовательность, задающая контекст для элемента Scheduled Protocol Code Sequence (0040,0008). В этой последовательности допускается один или несколько элементов. |
|||
|
Последовательность, задающая модификаторы для элемента содержимого Protocol Context (Protocol Context Content Item). В этой последовательности допускается один или несколько элементов. См. раздел C.4.10.1. |
|||
|
>>>Include Table 10-2 “Content Item Macro Attributes” |
|||
Поскольку Referenced Study Sequence (0008,1110) имеет Type 2 или 3 в зависимости от варианта использования, атрибут может иметь нулевую длину или отсутствовать соответственно.
Если Referenced Study Sequence (0008,1110) присутствует с элементом, в Referenced SOP Class UID (0008,1150) может использоваться SOP Class UID класса SOP Detached Study Management (Retired).
Таблица 10-10 определяет атрибуты макроса базовой калибровки шага пикселей (Basic Pixel Spacing Calibration Macro).
Таблица 10-10. Атрибуты макроса базовой калибровки шага пикселей (Basic Pixel Spacing Calibration Macro Attributes)
|
Физическое расстояние в теле пациента между центрами соседних пикселей, задаваемое числовой парой значений — шаг между соседними строками (разделитель) шаг между соседними столбцами, в мм. См. раздел 10.7.1.1 и раздел 10.7.1.3. Обязателен, если изображение было откалибровано. В противном случае может присутствовать. |
|||
|
Тип коррекции эффекта геометрического увеличения или калибровки по объекту известного размера, если таковая выполнялась. См. раздел 10.7.1.2. |
|||
|
Текстовое описание типа выполненной коррекции или калибровки в свободной форме. Note
Обязателен, если присутствует Pixel Spacing Calibration Type (0028,0A02). |
Pixel Spacing (0028,0030) задаёт физическое расстояние в теле пациента между центрами соседних пикселей.
Если Pixel Spacing (0028,0030) присутствует, а изображение не было откалибровано для коррекции эффекта геометрического увеличения, значения этого атрибута должны совпадать со значениями Imager Pixel Spacing (0018,1164) или Nominal Scanned Pixel Spacing (0018,2010), если любой из этих атрибутов присутствует.
Если Pixel Spacing (0028,0030) присутствует, а его значения отличаются от значений Imager Pixel Spacing (0018,1164) или Nominal Scanned Pixel Spacing (0018,2010), значит изображение было скорректировано с учётом известного или предполагаемого геометрического увеличения, либо откалибровано относительно объекта известного размера на известной глубине в теле пациента.
Если отсутствуют Pixel Spacing Calibration Type (0028,0A02), Imager Pixel Spacing (0018,1164) и Nominal Scanned Pixel Spacing (0018,2010), определить, была ли выполнена коррекция или калибровка, невозможно.
Pixel Spacing Calibration Type (0028,0A02) задаёт тип коррекции эффекта геометрического увеличения или калибровки по объекту известного размера, если таковая выполнялась.
Enumerated Values:
Значения Pixel Spacing (0028,0030) учитывают предполагаемый или известный эффект геометрического увеличения и соответствуют некоторой неуказанной глубине в теле пациента; таким образом, значения Pixel Spacing (0028,0030) могут использоваться для измерений объектов, расположенных близко к центральному лучу и на той же глубине.
Значения Pixel Spacing (0028,0030) были откалиброваны оператором или программным обеспечением обработки изображений путём измерения объекта (маркера, fiducial), видимого в пиксельных данных, имеющего известный размер и расположенного близко к центральному лучу; таким образом, значения Pixel Spacing (0028,0030) могут использоваться для измерений объектов, расположенных близко к центральному лучу и на той же глубине в теле пациента, что и маркер.
Все атрибуты, связанные с шагом пикселей, кодируются как физическое расстояние между центрами каждого двумерного пикселя, задаваемое двумя числовыми значениями.
Первое значение — это шаг строк в мм, то есть расстояние между центрами соседних строк, или вертикальный шаг.
Второе значение — это шаг столбцов в мм, то есть расстояние между центрами соседних столбцов, или горизонтальный шаг.
Для иллюстрации рассмотрим пример, показанный на рисунке 10.7.1.3-1.
Pixel Spacing = Row Spacing \ Column Spacing = 0.30\0.25.
Все атрибуты, связанные с шагом пикселей, должны иметь положительные ненулевые значения, за исключением случаев, когда присутствует только одна строка, один столбец или один пиксель данных — в этом случае соответствующее значение может быть равно нулю.
Одна строка, один столбец или один «пиксель» могут встречаться в экземплярах MR Spectroscopy. Если значение ненулевое, его назначение может заключаться в передаче размеров одной строки, одного столбца или одного пикселя, например, в однопиксельной (single voxel) MR-спектроскопии; иного механизма для передачи этой информации не существует.
Таблица 10-11 определяет атрибуты макроса ссылки на экземпляр SOP, который ссылается на экземпляр SOP.
Таблица 10-12 определяет атрибуты макроса идентификации содержимого (Content Identification Macro), которые идентифицируют и описывают экземпляр SOP, потенциально созданный человеком-пользователем, взаимодействующим с приложением.
Таблица 10-12. Атрибуты макроса идентификации содержимого (Content Identification Macro Attributes)
Таблица 10.9.1-1 определяет атрибуты улучшенного макроса идентификации содержимого (Enhanced Content Identification Macro), который идентифицирует содержимое с помощью метки, поддерживающей символы нижнего регистра и заданные наборы символов. Если требуется строка кода (Code String), см. раздел 10.9 «Content Identification Macro».
Таблица 10.9.1-1. Атрибуты улучшенного макроса идентификации содержимого (Enhanced Content Identification Macro Attributes)
|
Метка данного экземпляра SOP, определяемая пользователем. См. раздел 10.9.1.1.1. |
|||
|
Описание содержимого данного экземпляра SOP, определяемое пользователем. См. раздел 10.9.1.1.1. |
|||
User Content Label (3010,0033) должен представлять собой короткий текст в свободной форме, определяемый пользователем и обеспечивающий основную идентификацию данного объекта для других пользователей. Content Description (0070,0081) допускает более длинную строку, содержащую дополнительный описательный идентифицирующий текст.
Эта информация предназначена для отображения человеку-читателю. Не должна использоваться для структурированной обработки.
Таблица 10.9.2-1 определяет атрибуты расширенного макроса идентификации содержимого (Extended Content Identification Macro), который идентифицирует содержимое с помощью метки, поддерживающей символы нижнего регистра и заданные наборы символов. Если требуется строка кода (Code String), см. раздел 10.9 «Content Identification Macro».
Таблица 10.9.2-1. Атрибуты расширенного макроса идентификации содержимого (Extended Content Identification Macro Attributes)
|
Метка содержимого данного экземпляра SOP, определяемая пользователем. См. раздел 10.9.2.1.1. |
|||
|
Описание содержимого данного экземпляра SOP, определяемое пользователем. См. раздел 10.9.2.1.1. |
|||
User Content Long Label (3010,0034) должен представлять собой текст в свободной форме, определяемый пользователем и обеспечивающий основную идентификацию данного объекта для других пользователей. Content Description (0070,0081) допускает более длинную строку, содержащую дополнительный описательный идентифицирующий текст.
Эта информация предназначена для отображения человеку-читателю. Не должна использоваться для структурированной обработки.
Таблица 10.9.3-1. Атрибуты макроса создателя содержимого (Content Creator Macro Attributes)
|
Имя оператора (например, технолога или врача), создающего содержимое экземпляра SOP. |
|||
|
>Include Table 10-1 “Person Identification Macro Attributes” |
|||
Таблица 10-13 определяет атрибуты макроса общих исходных источников (General Contributing Sources Macro), которые описывают общие характеристики исходных источников, использованных для создания нового экземпляра SOP.
Таблица 10-13. Атрибуты макроса общих исходных источников (General Contributing Sources Macro Attributes)
|
Последовательность, идентифицирующая исходные экземпляры SOP. Обязателен, если данный экземпляр SOP создан из других экземпляров SOP DICOM. NoteЭтот атрибут отсутствует в случае, если источники, использованные для создания данного экземпляра SOP, не являются экземплярами SOP, например, объём, непосредственно сгенерированный системой сбора данных. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Уникальный идентификатор исследования исходных экземпляров SOP (Contributing SOP Instances). |
|||
|
Последовательность элементов, каждый из которых включает атрибуты одной серии. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Уникальный идентификатор серии, содержащей ссылочные экземпляры. |
|||
|
Последовательность элементов, каждый из которых предоставляет ссылку на экземпляр, являющийся частью серии, определённой значением Series Instance UID (0020,000E) в охватывающем элементе. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
>>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Название модели производителя оборудования, создавшего источники. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
Серийный номер производителя оборудования, создавшего источники. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
Обозначение производителем версии программного обеспечения оборудования, создавшего источники. См. раздел C.7.5.1.1.3. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
Дата первоначального изготовления или повторного изготовления (в отличие от восстановления) оборудования, создавшего источники. |
|||
|
Дата установки оборудования, создавшего источники, в его текущем местоположении. Устройство могло использоваться или не использоваться до установки в текущем местоположении. |
|||
|
Время начала сбора данных, в результате которого были получены источники. Значение должно представлять собой дату и время начала первого исходного экземпляра SOP группы, заданной Contributing SOP Instances Reference Sequence (0020,9529). Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
Определяемое пользователем имя, идентифицирующее аппарат, создавший источники. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
Имя(имена) оператора(ов), сопровождавшего(их) серию. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
Идентификация оператора(ов), сопровождавшего(их) серию. В этой последовательности должен присутствовать один или несколько элементов. При наличии более одного элемента их число и порядок должны соответствовать значению Operators' Name (0008,1070), если оно присутствует. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
>Include Table 10-1 “Person Identification Macro Attributes” |
|||
|
Определяемое пользователем описание условий, в которых была выполнена серия. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
Последовательность, описывающая протокол, выполненный для шага процедуры (Procedure Step), создавшего источники. В этой последовательности должен присутствовать один или несколько элементов. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
|
Определяемое пользователем имя протокола, использованного для получения данного изображения. Обязателен, если присутствует и совпадает во всех исходных экземплярах SOP. |
|||
Атрибуты первого уровня макроса General Contributing Sources Macro содержат информацию, общую для всех Referenced SOP Instances, включённых в Contributing SOP Instances Reference Sequence. Это позволяет не дублировать информацию, когда исходные экземпляры являются однокадровыми объектами и/или относятся к разным сериям с одинаковыми протоколом и информацией о производителе.
Как правило, макрос General Contributing Sources Macro вызывается изнутри другой последовательности. Поэтому, если «общие» атрибуты макроса различаются между Referenced SOP Instances — например, разные протоколы получения, версии программного обеспечения и т. д., — вызывающая последовательность будет содержать несколько элементов.
Таблица 10-14 определяет атрибуты макроса исходных источников изображений (Contributing Image Sources Macro), которые описывают связанные с изображением характеристики исходных источников изображений, использованных для создания нового экземпляра SOP (например, экземпляра SOP объёма).
Таблица 10-14. Атрибуты макроса исходных источников изображений (Contributing Image Sources Macro Attributes)
|
Число бит, хранимых для каждого сэмпла пикселя. Каждый сэмпл должен иметь одинаковое число хранимых бит. Дополнительные разъяснения см. в PS3.5. |
|||
|
Указывает, подвергались ли исходные изображения (Source Images) сжатию с потерями (в какой-либо момент их существования). Enumerated Values: См. раздел C.7.6.1.1.5. Обязателен, если известно, было ли выполнено сжатие с потерями (Lossy Compression) для изображений. |
|||
|
Описывает приблизительный(е) коэффициент(ы) сжатия с потерями, применённый(е) к данному изображению. См. раздел C.7.6.1.1.5.2. Обязателен, если Lossy Image Compression (0028,2110) имеет значение «01». |
|||
|
Метка для метода(ов) сжатия с потерями, применённого(ых) к исходным изображениям. См. раздел C.7.6.1.1.5.1. Обязателен, если Lossy Image Compression (0028,2110) имеет значение «01». |
Таблица 10-15 определяет атрибуты макроса ориентации пациента (Patient Orientation Macro), которые описывают ориентацию пациента относительно силы тяжести и оборудования.
Таблица 10-15. Атрибуты макроса ориентации пациента (Patient Orientation Macro Attributes)
|
Описание ориентации пациента относительно силы тяжести. Дополнительные разъяснения см. в разделе C.8.4.6.1.1 и разделе C.8.11.5.1.2. В этой последовательности должен присутствовать только один элемент. |
|||
|
Модификатор ориентации пациента. Обязателен, если необходим для полного указания ориентации пациента относительно силы тяжести. В этой последовательности должен присутствовать только один элемент. |
|||
|
Описание ориентации пациента относительно гентри (gantry). Дополнительные разъяснения см. в разделе C.8.4.6.1.3. |
|||
Таблица 10-15a содержит атрибуты, описывающие ориентацию пациента относительно силы тяжести и обязательную связь с оборудованием.
Таблица 10-15a. Атрибуты макроса ориентации пациента и связи с оборудованием (Patient Orientation and Equipment Relationship Macro Attributes)
|
Последовательность, описывающая ориентацию пациента относительно силы тяжести. Дополнительные разъяснения см. в разделе C.8.4.6.1.1 и разделе C.8.11.5.1.2. В этой последовательности должен присутствовать только один элемент. |
|||
|
Модификатор ориентации пациента. Обязателен, если необходим для полного указания ориентации пациента относительно силы тяжести. В этой последовательности должен присутствовать только один элемент. |
|||
|
Описание ориентации пациента относительно оборудования. Дополнительные разъяснения см. в разделе C.36.6.1.8. В этой последовательности должен присутствовать только один элемент. |
|||
Атрибуты этого макроса могут использоваться для сопоставления системы координат, связанной с пациентом (Patient-Based Coordinate System) (см. раздел C.7.6.2), с оборудованием.
Таблица 10-16. Атрибуты макроса сводки шага выполненной процедуры (Performed Procedure Step Summary Macro Attributes)
|
Идентификатор, сгенерированный пользователем или оборудованием, для той части процедуры, которая была выполнена в рамках данного шага. |
|||
|
Описание или классификация выполненного шага процедуры, сформированные учреждением. |
|||
|
Последовательность, описывающая протокол, выполненный для данного шага процедуры. В этой последовательности допускается один или несколько элементов. |
|||
|
Последовательность, задающая контекст для элемента Performed Protocol Code Sequence (0040,0260). В этой последовательности допускается один или несколько элементов. |
|||
|
Последовательность, задающая модификаторы для элемента содержимого Protocol Context (Protocol Context Content Item). В этой последовательности допускается один или несколько элементов. См. раздел C.4.10.1. |
|||
|
>>>Include Table 10-2 “Content Item Macro Attributes” |
|||
|
Определяемые пользователем комментарии к Performed Procedure Step. |
|||
Таблица 10-17 определяет атрибуты макроса иерархического обозначителя HL7v2 (HL7v2 Hierarchic Designator Macro), которые идентифицируют сущность (систему, организацию, ведомство или подразделение), ответственную за управление или присвоение заданного набора идентификаторов экземпляров (например, номер отправителя или исполнителя заказа, идентификаторы пациента, идентификаторы поставщика услуг и т. д.). Такой сущностью может быть конкретное медицинское приложение, например, система регистрации, присваивающая идентификаторы пациентов, государственный орган, например, лицензирующий орган, присваивающий профессиональные идентификаторы или номера водительских удостоверений, либо учреждение, в котором присваиваются такие идентификаторы.
Это определение идентично HL7 v2.5, раздел 2.A.33, с незначительными изменениями стиля изложения.
Эти атрибуты эквивалентны компонентам типов данных HL7 v2 Hierarchic Designator (HD) и Entity Identifier (EI) (см. HL7 v2, глава 2.A).
Если присутствуют оба атрибута — Local Namespace Entity ID (0040,0031) и Universal Entity ID (0040,0032), — они должны относиться к одной и той же сущности.
Таблица 10-17. Атрибуты макроса иерархического обозначителя HL7v2 (HL7v2 Hierarchic Designator Macro Attributes)
Таблица 10-18 определяет атрибуты макроса издателя идентификатора пациента (Issuer of Patient ID Macro), которые идентифицируют источник Patient ID (0010,0020).
Эти атрибуты эквивалентны компонентам типа данных HL7 v2 Extended Composite ID with Check Digit (CX) (см. HL7 v2, глава 2.A.14), используемого в поле HL7 v2 PID-3 Patient Identifier List.
Таблица 10-18. Атрибуты макроса издателя идентификатора пациента (Issuer of Patient ID Macro Attributes)
|
Идентификатор органа-эмитента (Assigning Authority) (системы, организации, ведомства или подразделения), присвоившего Patient ID. |
|||
|
Атрибуты, уточняющие или квалифицирующие идентичность издателя Patient ID, либо определяющие область действия Patient ID. |
|||
|
Универсальный или уникальный идентификатор органа-эмитента Patient ID (Assigning Authority). Орган, идентифицируемый этим атрибутом, должен совпадать с органом, указанным в Issuer of Patient ID (0010,0021), если он присутствует. |
|||
|
Стандарт, определяющий формат Universal Entity ID (0040,0032). Обязателен, если присутствует Universal Entity ID (0040,0032). Определённые термины (Defined Terms) см. в разделе 10.14. |
|||
|
Тип Patient ID. Определённые термины см. в HL7 v2 Table 0203. |
|||
|
Идентификатор места или местоположения, где идентификатор был впервые присвоен пациенту. Этот компонент не является неотъемлемой частью идентификатора, а относится к его истории. |
|||
|
>>Include Table 10-17 “HL7v2 Hierarchic Designator Macro Attributes” |
|||
|
Геополитический орган, присвоивший идентификатор пациента. Как правило, код страны или штата/провинции. В этой последовательности допускается только один элемент. |
|||
|
BCID 5001 “Country” для кодов стран. |
|||
|
Ведомство или подразделение, присвоившее идентификатор пациента. В этой последовательности допускается только один элемент. |
|||
Таблица 10-19 определяет атрибуты макроса идентификации алгоритма (Algorithm Identification Macro), который идентифицирует и описывает алгоритм, использованный для создания или получения содержимого экземпляра SOP. Алгоритм описывается семейством алгоритма (Algorithm Family), конкретным именем алгоритма (Algorithm Name) и версией алгоритма (Algorithm Version). Может быть включена строка символов, содержащая параметры, использованные в алгоритме.
Таблица 10-19. Атрибуты макроса идентификации алгоритма (Algorithm Identification Macro Attributes)
Таблица 10-20 определяет атрибуты макроса атрибута-селектора (Selector Attribute Macro), которые идентифицируют либо конкретное значение атрибута, либо все значения атрибута, либо конкретный элемент последовательности, либо все элементы последовательности. Атрибут или элемент может быть вложен в одну или несколько последовательностей и/или в приватный атрибут.
Вызов макроса атрибута-селектора может определять дополнительную семантику. Например, если макрос атрибута-селектора используется для выбора «всех» значений атрибута с последующей проверкой этого набора значений на соответствие некоторому условию, то в конкретном вызове может быть определено, требуется ли, чтобы условию соответствовало хотя бы одно значение из набора, или чтобы условию соответствовали все значения набора.
Таблица 10-20a расширяет макрос атрибута-селектора дополнительными дескрипторами атрибутов.
Таблица 10-20. Атрибуты макроса атрибута-селектора (Selector Attribute Macro Attributes)
|
Тег элемента данных атрибута, на который делается ссылка. Обязателен, если выбранное содержимое не является элементом последовательности. |
|||
|
Неотрицательное целое число, определяющее, на какое значение многозначного атрибута, идентифицированного Selector Attribute (0072,0026), делается ссылка. Значение 1 определяет первое значение. Значение 0 определяет все значения. Если Value Multiplicity атрибута Selector Attribute (0072,0026) равна 1, значение этого атрибута должно быть равно 1. Обязателен, если выбранное содержимое является одиночным атрибутом с любым VR, отличным от SQ. |
|||
|
Содержит теги элементов данных пути к последовательности, содержащей атрибут, идентифицированный Selector Attribute (0072,0026), либо путь к элементу(ам), которые должны быть выбраны в Selector Sequence Pointer Items (0074,1057). Этот атрибут должен иметь то же число значений, что и уровень вложенности Selector Attribute (0072,0026) или выбранного(ых) элемента(ов). Обязателен, если Selector Attribute (0072,0026) вложен в одну или несколько последовательностей либо отсутствует. См. раздел 10.17.1.1. |
|||
|
Идентификация создателя группы приватных элементов данных, используемых для кодирования атрибутов в Selector Sequence Pointer (0072,0052). Этот атрибут должен иметь то же число значений, что и Selector Sequence Pointer (0072,0052). Для значений Selector Sequence Pointer (0072,0052), не являющихся тегом элемента данных приватного атрибута, соответствующее значение в Selector Sequence Pointer Private Creator (0072,0054) должно быть пустым. Обязателен, если присутствует Selector Sequence Pointer (0072,0052), и одно или несколько значений Selector Sequence Pointer (0072,0052) являются тегом элемента данных приватного атрибута. См. раздел 10.17.1.2. |
|||
|
Идентификация индексов элементов в Selector Sequence Pointer (0072,0052). Этот атрибут должен иметь то же число значений, что и Selector Sequence Pointer (0072,0052). Значение 1 определяет первый элемент соответствующей последовательности. Значение 0 определяет все элементы соответствующей последовательности. Обязателен, если присутствует Selector Sequence Pointer (0072,0052). См. раздел 10.17.1.1. |
|||
|
Идентификация создателя группы приватных элементов данных. Обязателен, если значение Selector Attribute (0072,0026) является тегом элемента данных приватного атрибута. См. раздел 10.17.1.2. |
Таблица 10-20a. Атрибуты расширенного макроса атрибута-селектора (Extended Selector Attribute Macro Attributes)
|
Имя Selector Attribute (0072,0026). Для стандартных элементов данных это должно быть значение из столбца Name таблицы Table 6-1 in PS3.6. |
|||
|
Ключевое слово (Keyword) Selector Attribute (0072,0026). Для стандартных элементов данных это должно быть значение из столбца Keyword таблицы Table 6-1 in PS3.6. |
|||
|
Представление значения (VR) Selector Attribute (0072,0026). Для стандартных элементов данных это должно быть значение из столбца VR таблицы Table 6-1 in PS3.6. |
|||
Примеры использования приведены в таблице 10-21.
Примеры включают выбор атрибута верхнего уровня, вложенного атрибута, одного элемента в последовательности верхнего уровня, всех элементов во вложенной последовательности, либо конкретного элемента во всех элементах родительской последовательности.
Таблица 10-21. Пример макроса атрибута-селектора (Selector Attribute Macro Example)
Selector Sequence Pointer Private Creator (0072,0054) и Selector Attribute Private Creator (0072,0056) содержат значение, соответствующее номерам элементов данных Private Creator (gggg,00pp), где gggg — нечётное, а pp принимает значения от 10 до FF. Они идентифицируют блок приватных элементов данных в пределах блока (gggg,ppxx). Когда Selector Attribute (0072,0026) или Selector Sequence Pointer (0072,0052) указывает на приватный элемент данных (gggg,ppxx), его значением должно быть (gggg,00xx).
Таблица 10-22 определяет атрибуты макроса идентификации набора данных из внешнего источника (Externally-Sourced Data Set Identification Macro), которые идентифицируют набор данных из внешнего источника (Externally-Sourced Data Set).
Таблица 10-22. Атрибуты макроса идентификации набора данных из внешнего источника (Externally-Sourced Data Set Identification Macro Attributes)
Таблица 10-23 определяет атрибуты макроса индекса экспозиции (Exposure Index Macro) раздела 10.19, которые описывают индекс экспозиции (Exposure Index) для однопроекционных рентгеновских изображений, как описано в IEC 62494-1 и отчёте AAPM Task Group 116.
Таблица 10-23. Атрибуты макроса индекса экспозиции (Exposure Index Macro Attributes)
Таблица 10-24 определяет атрибуты обязательного макроса направления обзора и прогрессии срезов (Mandatory View and Slice Progression Direction Macro), которые описывают ракурс (view), а в случае кардиологических ракурсов — направление срезов относительно анатомии сердца.
Таблица 10-24. Атрибуты обязательного макроса направления обзора и прогрессии срезов (Mandatory View and Slice Progression Direction Macro Attributes)
|
Последовательность, описывающая проекцию анатомической области интереса. В этой последовательности должен присутствовать только один элемент. |
|||
|
BCID 26 “Nuclear Medicine Projection”, если иное не указано при вызове. |
|||
|
Модификатор ракурса (View Modifier). Обязателен, если необходим для полного указания ракурса (View). В этой последовательности должно присутствовать ноль или более элементов. |
|||
|
BCID 23 “Cranio-Caudad Angulation”, если иное не указано при вызове. |
|||
|
Описывает анатомическое направление, в котором происходит прогрессия набора срезов (см. раздел 10.20.1.1). Имеет смысл только для кардиологических изображений. Перечислимые значения определены в разделе 10.20.1.1. Обязателен, если View Code Sequence (0054,0220) равно (103340004, SCT, "Short Axis") или (131185001, SCT, "Vertical Long Axis") или (131186000, SCT, "Horizontal Long Axis"). В противном случае может присутствовать. |
|||
Порядок изображений или кадров, к которому применяется Slice Progression Direction (0054,0500), зависит от IOD:
В случае Enhanced Multi-frame IOD, где может быть определён Stack ID (0020,9056), должен использоваться Stack ID (0020,9056), а срезы рассматриваются в порядке In Stack Position Number (0020,9057)
В случае Multi-frame Image IOD, не являющихся Enhanced, срезы рассматриваются в порядке кодирования кадров
В случае Single-frame Image IOD порядок определяется возрастанием значений Instance Number
Перечислимые значения зависят от ракурса (view):
Если View Code Sequence (0054,0220) указывает ракурс по короткой оси (short axis), например, когда он равен (103340004, SCT, "Short Axis"):
Если View Code Sequence (0054,0220) указывает ракурс по вертикальной длинной оси (vertical long axis), например, когда он равен (131185001, SCT, "Vertical Long Axis"):
Если View Code Sequence (0054,0220) указывает ракурс по горизонтальной длинной оси (horizontal long axis), например, когда он равен (131186000, SCT, "Horizontal Long Axis"):
Условия выбора перечислимых значений сформулированы достаточно обобщённо, а не применительно к одному конкретному кодированному ракурсу, чтобы учитывать эхокардиографические ракурсы, определённые в CID 12226 “Echocardiography Image View” in PS3.16 , в дополнение к ракурсам для CT, MR, NM и PET, определённым в CID 26 “Nuclear Medicine Projection” in PS3.16 .
Таблица 10-25 определяет атрибуты необязательного макроса направления обзора и прогрессии срезов (Optional View and Slice Progression Direction Macro), которые описывают ракурс (view), а в случае кардиологических ракурсов — направление срезов относительно анатомии сердца.
Таблица 10-25. Атрибуты необязательного макроса направления обзора и прогрессии срезов (Optional View and Slice Progression Direction Macro Attributes)
|
Последовательность, описывающая проекцию анатомической области интереса. |
|||
|
BCID 26 “Nuclear Medicine Projection”, если иное не указано при вызове. |
|||
|
Модификатор ракурса (View Modifier). В этой последовательности допускается один или несколько элементов. |
|||
|
BCID 23 “Cranio-Caudad Angulation”, если иное не указано при вызове. |
|||
|
Описывает анатомическое направление, в котором происходит прогрессия набора срезов (см. раздел 10.20.1.1). Имеет смысл только для кардиологических изображений. Перечислимые значения определены в разделе 10.20.1.1. |
|||
Таблица 10-26 определяет атрибуты макроса числового значения (Numeric Value Macro), который используется для связывания и передачи числового значения с кодированным понятием.
Таблица 10-26. Атрибуты макроса числового значения (Numeric Value Macro Attributes)
Retired. См. PS3.3-2024b.
Таблица 10-28 определяет атрибуты макроса управления перемещением устройства (Device Motion Control Macro), которые описывают требования к выполнению перемещения устройства из фактического положения в желаемое.
Таблица 10-28. Атрибуты макроса управления перемещением устройства (Device Motion Control Macro Attributes)
|
Определения управления перемещением устройства для каждой степени свободы. В этой последовательности допускается один или несколько элементов. |
|||
|
Параметр, к которому должно применяться управление перемещением устройства (Device Motion Control). |
|||
|
Допустимый режим выполнения перемещения (Motion Execution Mode). Обязателен, если отсутствует Device Motion Observation Mode (300A,0452). В противном случае может присутствовать. См. раздел 10.24.1.1. |
|||
|
Требуемый режим наблюдения за перемещением (Motion Observation Mode). Обязателен, если отсутствует Device Motion Execution Mode (300A,0451). В противном случае может присутствовать. См. раздел 10.24.1.2. |
|||
Device Motion Execution Mode (300A,0451) определяет, каким образом оператор инициирует и управляет перемещением.
Enumerated Values:
Устройство должно перемещаться, пока оператор удерживает активированным один или несколько переключателей на аппарате в течение всего периода перемещения, чтобы предотвратить неконтролируемое перемещение.
Устройство может автоматически перемещаться в желаемое положение по однократной команде оператора, без необходимости постоянно удерживать активированным какой-либо переключатель.
Перемещение устройства в желаемое положение может быть инициировано и выполнено автоматически самим устройством.
Таблица 10.25-1 определяет атрибуты макроса ограничения значения атрибута (Attribute Value Constraint Macro), который позволяет идентифицировать атрибут и наложить ограничения на допустимые значения этого атрибута. Ограничиваемый атрибут называется в этом макросе атрибутом-селектором (Selector Attribute).
Этот макрос не обрабатывает взаимные ограничения между несколькими атрибутами. Например, ограничение соотношения между двумя атрибутами конкретным значением невозможно, если только не существует третьего атрибута, кодирующего это соотношение, — тогда ограничение можно наложить на этот третий атрибут.
Экземпляр SOP, содержащий этот макрос, определяет назначение ограничений, которые могут включать ограничение значений атрибутов в других экземплярах SOP.
Таблица 10.25-1. Атрибуты макроса ограничения значения атрибута (Attribute Value Constraint Macro Attributes)
|
Include Table 10-20a “Extended Selector Attribute Macro Attributes” |
|||
|
Описывает, как значение(я), заданное(ые) в Constraint Value Sequence (0082,0034), должно(ы) использоваться для определения допустимости данного значения атрибута, идентифицированного Selector Attribute (0072,0026) См. раздел 10.25.1. |
|||
|
Уровень значимости выхода значения атрибута-селектора за пределы данного ограничения. См. раздел 10.25.2. |
|||
|
Условие значимости нарушения ограничения. Если условие не выполнено, нарушение не имеет значения. Условие может быть выражено в виде математического выражения, текста, понятного человеку, или в иной форме. Обязателен, если Constraint Violation Significance (0082,0036) значимо только при определённых условиях. |
|||
|
Значение(я), используемое(ые) для ограничения содержимого атрибута, на который ссылается Selector Attribute (0072,0026). Обязателен, если Constraint Type (0082,0032) не равно UNCONSTRAINED. Если Constraint Type (0082,0032) равно GREATER_OR_EQUAL, LESS_OR_EQUAL, GREATER_THAN, LESS_THAN, EQUAL или MEMBER_OF_CID, в этой последовательности должен присутствовать только один элемент. Если Constraint Type (0082,0032) равно RANGE_INCL или RANGE_EXCL, в этой последовательности должно присутствовать ровно два элемента, первый из которых меньше или равен второму. Если Constraint Type (0082,0032) равно MEMBER_OF или NOT_MEMBER_OF, в этой последовательности должен присутствовать один или несколько элементов. |
|||
|
Любые вложенные последовательности в Constraint Value Sequence (0082,0034) должны содержать только один элемент. Любой атрибут в элементе(ах) последовательности должен содержать единственное значение. Если Constraint Type (0082,0032) равно MEMBER_OF_CID, это должно быть Selector UI Value (0072,007F), несмотря на то, что Selector Attribute VR (0072,0050) равен SQ. См. раздел 10.25.1.1 |
|||
|
Содержит значение по умолчанию для содержимого Selector Attribute (0072,0026). |
|||
|
Единицы измерения значений элемента(ов) в Constraint Value Sequence (0082,0034) и Recommended Default Value Sequence (0082,0035). |
|||
|
Краткое указание, которое оператор-человек может учитывать при выборе подходящего значения для Selector Attribute (0072,0026) в рамках заданных ограничений. |
|||
Использование заданного(ых) значения(й) в Constraint Value Sequence (0082,0034) для ограничения значения атрибута, на который ссылается Selector Attribute (0072,0026), зависит от значения Constraint Type (0082,0032) следующим образом:
значение должно находиться между заданными значениями либо быть равным одному из заданных значений
значение должно находиться вне (то есть не между) заданных значений
значение не должно быть равно ни одному из заданных значений
Для MEMBER_OF_CID Constraint Value Sequence (0082,0034) должна содержать единственное значение Selector UI Value (0072,007F), содержащее Context Group UID (см. Table A-3 Context Group UID Values в PS3.6 ).
RANGE_INCL, RANGE_EXCL, GREATER_OR_EQUAL, LESS_OR_EQUAL, GREATER_THAN или LESS_THAN могут быть указаны только если Selector Attribute (0072,0026) имеет VR AS, DA, DS, DT, FD, FL, IS, SL, SS, TM, UL или US.
Дополнительные указания по сравнению значений см. в разделе C.2.2.2 PS3.4.
MEMBER_OF с единственным элементом в Constraint Value Sequence (0082,0034) допустим и эквивалентен EQUAL.
Если атрибут, на который ссылается Selector Attribute (0072,0026), имеет Value Multiplicity больше 1, а значение Selector Value Number (0072,0028) равно 0, все значения выбранного атрибута должны сравниваться с единственным заданным значением. Ограничение нарушается, если хотя бы одно из множества значений не удовлетворяет сравнению.
Нарушение одних ограничений может быть более значимым, чем других. Constraint Violation Significance (0082,0036) различает три уровня значимости.
Конкретное поведение, связанное с каждым уровнем, может определяться классом SOP или оставаться на усмотрение реализации. Например, нарушение ограничения со значимостью FAILURE может потребовать вмешательства оператора, специального аудита или отклонения проверяемого целевого экземпляра; нарушение ограничения со значимостью WARNING может потребовать уведомления оператора или регистрации предупреждающего сообщения; нарушение ограничения со значимостью INFORMATIVE может потребовать регистрации информационного сообщения либо не потребовать никаких действий, если ограничение выражает предпочтение, а не существенную проблему.
Таблица 10.26-1 определяет атрибуты макроса значения атрибута (Attribute Value Macro), который включает атрибут для хранения значения заданного VR.
Таблица 10.26-1. Атрибуты макроса значения атрибута (Attribute Value Macro Attributes)
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно AE. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно AS. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно AT. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно CS. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно DA. См. примечание 2. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно DS. См. примечание 1 и примечание 2. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно DT. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно FD. См. примечание 2. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно FL. См. примечание 2. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно IS. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно LO. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно LT. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно OB. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно OD. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно OF. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно OL. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно OV. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно OW. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно PN. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно SH. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно SL. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно SS. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно ST. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно SV. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно TM. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно UC. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно UI. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно UL. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно UN. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно UR. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно US. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно UT. |
|||
|
Значение атрибута, идентифицированного Selector Attribute (0072,0026). Обязателен, если присутствует Selector Attribute VR (0072,0050) и его значение равно UV. |
|||
|
Значение(я) атрибута, идентифицированного Selector Attribute (0072,0026). В этой последовательности должен присутствовать один или несколько элементов. См. раздел C.23.4.2.1.2. Обязателен, если присутствует Selector Attribute VR (0072,0050), его значение равно SQ, и атрибут, на который ссылается Selector Attribute (0072,0026), является последовательностью кодов (Code Sequence). |
|||
Для строковых представлений значений (Value Representations) должно использоваться значение, определённое Стандартом, а не буквальная строка. Например, «1.0E+3» равно «1000» и «1000.0».
При сопоставлении этого значения-селектора со значением атрибута приложению потребуется определённая гибкость в отношении точности.
Таблица 10.27-1 определяет атрибуты макроса опорного местоположения (Reference Location Macro), который позволяет идентифицировать и описать опорное местоположение в контексте пациента или скана. Например, макрос может описывать анатомически определённое местоположение вдоль оси КТ-скана для указания протяжённости скана или реконструкции. Местоположение может находиться внутри пациента (и отображаться на локализационном изображении) либо быть внешним ориентиром (на который выравнивается лазер).
Таблица 10.27-1. Атрибуты макроса опорного местоположения (Reference Location Macro Attributes)
|
Дополнительное пояснение опорного местоположения (Reference Location). Значение может включать описание относительного анатомического расположения, внешнего вида признака или ориентира, либо способа его идентификации. |
|||
|
Анатомический признак или опорная точка, на которых основано опорное местоположение. В этой последовательности должен присутствовать только один элемент. |
|||
|
Характеризует геометрию опорного местоположения (например, плоскость или точку). В этой последовательности должен присутствовать только один элемент. |
|||
|
Положительное смещение (в мм) от Reference Basis до фактического опорного местоположения (Reference Location). См. раздел 10.27.1. |
|||
|
Направление смещения (в терминах положения пациента) от Reference Basis к Reference Location. |
|||
Таблица 10.28-1 определяет атрибуты макроса идентификации элемента протокола (Protocol Element Identification Macro), который идентифицирует и описывает элемент протокола, например протокола получения (acquisition), протокола реконструкции или протокола хранения.
Таблица 10.28-1. Атрибуты макроса идентификации элемента протокола (Protocol Element Identification Macro Attributes)
|
Идентифицирует элемент протокола и порядок, в котором элементы выполняются в протоколе. Значение должно начинаться с 1 и монотонно увеличиваться на 1. |
|||
|
Описание назначения данного элемента в протоколе. Note
|
|||
|
Сводное описание характеристик данного элемента. Note
|
Таблица 10.29-1 определяет атрибуты макроса UDI (UDI Macro), который фиксирует сведения, связанные с уникальным идентификатором устройства (Unique Device Identifier, UDI).
Таблица 10.29-1. Атрибуты макроса UDI (UDI Macro Attributes)
|
Полная человекочитаемая форма (Human Readable Form) UDI, определённая издающим агентством (Issuing Agency). См. раздел 10.29.1. |
|||
|
Дополнительное описание устройства в свободной текстовой форме. Может использоваться для различения элементов, если в последовательности записано несколько UDI. |
UDI представляет собой комбинацию идентификатора устройства (Device Identifier) и идентификатора производства (Production Identifier).
Формат строки определяется соответствующим издающим агентством (Issuing Agency), например:
GS1 - http://www.gs1.org
HIBCC - http://www.hibcc.org
ICCBBA - http://www.iccbba.org
Детали кодирования действительного идентификатора устройства определяются издающим агентством. Полную документацию см. в материалах издающего агентства.
Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA) требует, чтобы издающее агентство использовало только символы и цифры из инвариантного набора символов ISO/IEC 646 (7-битный набор символов ISO, также известный как ISO IR 6). DICOM не накладывает ограничений на длину строки или набор символов, помимо ограничений, налагаемых представлением значения (VR) UT. Реализации должны быть готовы обрабатывать очень длинные строки и необычные символы.
Таблица 10.30-1 определяет атрибуты макроса утверждения (Assertion Macro), который используется для регистрации утверждений (Assertions), сделанных лицом или устройством относительно содержимого экземпляра SOP. Характер утверждения определяется Assertion Code.
Область действия утверждения (например, применяется ли оно ко всему экземпляру, к конкретному элементу последовательности и т. д.) описывается в месте включения макроса. Также ожидается, что при включении этого макроса будет ограничен базовый (Baseline) CID для Assertion Code Sequence (0044,0101).
Таблица 10.30-1. Атрибуты макроса утверждения (Assertion Macro Attributes)
|
В этой последовательности должен присутствовать только один элемент. |
|||
|
Лицо или устройство, делающее утверждение. В этой последовательности должен присутствовать только один элемент. |
|||
|
>Include Table C.17-3b “Identified Person or Device Macro Attributes” |
Organizational Role BCID 7452 “Organizational Role”. |
||
|
Дата и время истечения срока действия утверждения. Если этот атрибут отсутствует или пуст, это означает, что утверждение не имеет заранее определённой даты и времени истечения срока действия. |
|||
|
Ссылка на документ(ы), описывающий(е) семантику утверждения или служащий(е) основанием для его формирования. Элементы не должны быть пустыми. В этой последовательности допускается один или несколько элементов. |
|||
|
Уникальный идентификатор класса документа, на который делается ссылка. |
|||
|
Уникальный идентификатор документа, на который делается ссылка, используемый в ссылках на экземпляры DICOM (см. раздел C.12.1.1.6). |
|||
|
Идентификатор экземпляра документа, на который делается ссылка, закодированный как UID (OID или UUID), объединённый с помощью символа «^» со значением Extension (если Extension присутствует в Instance Identifier). |
|||
|
Путь доступа для получения документа, на который делается ссылка. Включает полностью заданные схему, полномочия (authority), путь и запрос в соответствии с [RFC3986]. |
|||
|
Другие утверждения, которые могут представлять интерес для систем, анализирующих данное утверждение. В этой последовательности допускается один или несколько элементов. |
|||
Таблица 10.31-1 определяет атрибуты макроса маркировки сущности (Entity Labeling Macro), который предоставляет идентификацию сущности для пользователя.
Эта информация предназначена для отображения человеку-читателю. Не должна использоваться для структурированной обработки.
Таблица 10.31-1. Атрибуты макроса маркировки сущности (Entity Labeling Macro Attributes)
|
Метка данной сущности, определяемая пользователем. См. раздел 10.31.1.1. |
|||
|
Имя данной сущности, определяемое пользователем. См. раздел 10.31.1.2. |
|||
|
Описание данной сущности, определяемое пользователем. См. раздел 10.31.1.2. |
Таблица 10.32-1 определяет атрибуты макроса длинной маркировки сущности (Entity Long Labeling Macro), который предоставляет идентификацию сущности для пользователя.
Эта информация предназначена для отображения человеку-читателю. Не должна использоваться для структурированной обработки.
Таблица 10.32-1. Атрибуты макроса длинной маркировки сущности (Entity Long Labeling Macro Attributes)
|
Метка данной сущности, определяемая пользователем. См. раздел 10.32.2.1. |
|||
|
Описание данной сущности, определяемое пользователем. См. раздел 10.31.1.2. |
Таблица 10.33-1 определяет атрибуты макроса концептуального объёма (Conceptual Volume Macro). Концептуальный объём (Conceptual Volume) — это абстрактная сущность, используемая для идентификации анатомической области (например, планового целевого объёма или комбинации нескольких анатомических объёмов) либо неанатомических объёмов, таких как болюс или маркер. Концептуальный объём может быть установлен без обязательного определения его пространственной протяжённости (например, концептуальный объём опухоли может быть установлен до её сегментации). Пространственная протяжённость концептуального объёма может изменяться со временем (например, по мере проведения лечения объём опухоли, соответствующий концептуальному объёму, будет изменяться).
Пространственная протяжённость концептуального объёма может определяться любой сущностью общего назначения, представляющей геометрическую информацию (такой как Segmentation, Surface Segmentation, экземпляр SOP RT Structure Set и подобные) либо их комбинацией, хотя концептуальный объём существует независимо от конкретного определения его пространственной протяжённости.
Концептуальный объём также может быть определён как комбинация других концептуальных объёмов.
Примеры концептуальных объёмов:
Концептуальный объём (с Conceptual Volume UID (3010,0006)) может использоваться для представления цели лечения в экземпляре SOP RT Physician Intent, основанном на наборе диагностических изображений, хотя фактическое определение контуров конкретного целевого объёма ещё не выполнено. Позднее целевой объём оконтуривается. Экземпляр SOP RT Segment Annotation ссылается на контуры объёма и связывает их с концептуальным объёмом через Conceptual Volume UID (3010,0006).
В адаптивном рабочем процессе анатомический объём может изменяться со временем. Концептуальный объём, напротив, не изменяется. Несколько экземпляров SOP RT Segment Annotation, каждый из которых ссылается на разные экземпляры Segmentation, могут быть связаны с одним и тем же концептуальным объёмом через Conceptual Volume UID (3010,0006), что позволяет отслеживать изменение объёма во времени.
Концептуальный объём может представлять цели и/или анатомические области, для которых отслеживаются вручную рассчитанные дозы (например, при экстренном лечении). В этом случае концептуальные объёмы могут быть сначала созданы в экземпляре SOP RT Physician Intent, а затем использованы в экземплярах SOP RT Radiation, либо могут быть сначала созданы в экземплярах Radiation SOP. После лечения эти концептуальные объёмы будут использоваться в RT Radiation Record для отслеживания доставленной дозы. Такие концептуальные объёмы могут никогда не ссылаться на сегментацию, а служить ключом для ссылки на концептуальный объём в этих различных экземплярах SOP.
Таблица 10.33-1. Атрибуты макроса концептуального объёма (Conceptual Volume Macro Attributes)
|
Ссылка на экземпляр SOP, содержащий исходное определение данного концептуального объёма, идентифицированного Conceptual Volume UID (3010,0006). Обязателен, если Conceptual Volume UID (3010,0006) был выпущен не в текущем экземпляре SOP, а считан из другого экземпляра SOP. В этой последовательности должен присутствовать только один элемент. |
|||
|
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Ссылается на один или несколько существующих концептуальных объёмов, представляющих то же понятие, что и текущий концептуальный объём. Эта последовательность может использоваться, когда ссылки на концептуальные объёмы существующих экземпляров SOP ретроспективно определяются как представляющие одну и ту же сущность. В этой последовательности допускается один или несколько элементов. См. раздел 10.33.1.1. |
|||
|
Ссылка на экземпляр SOP, содержащий Referenced Conceptual Volume UID (3010,000B) эквивалентного концептуального объёма. В этой последовательности должен присутствовать только один элемент. |
|||
|
>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Описание концептуального объёма, использованного для получения данного концептуального объёма. |
|||
|
Читаемое пользователем текстовое описание способа получения данного концептуального объёма. |
|||
|
Набор концептуальных объёмов, использованных для получения данного концептуального объёма. В этой последовательности должен присутствовать один или несколько элементов. |
|||
|
UID, идентифицирующий концептуальный объём, использованный для получения данного концептуального объёма. |
|||
|
Индекс составляющей в Source Conceptual Volume Sequence. Значение должно начинаться с 1 и монотонно увеличиваться на 1. |
|||
|
>>Conceptual Volume Constituent Segmentation Reference Sequence |
Содержит ссылку на составляющие экземпляра RT Segment Annotation, из которого получен концептуальный объём. В этой последовательности должно присутствовать ноль или один элемент. |
||
|
Ссылка на экземпляр SOP, содержащий Direct Segment Reference Sequence (3010,0023). В этой последовательности должен присутствовать только один элемент. См. раздел 10.34.1.3. |
|||
|
>>>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Segment Reference Index (3010,0022) в Segment Reference Sequence (3010,0021), соответствующий сегменту, представляющему данный концептуальный объём. Должен ссылаться только на элементы сегментов, содержащие Direct Segment Reference Sequence (3010,0023). |
|||
|
Алгоритм, использованный для получения данного концептуального объёма. В этой последовательности допускается один или несколько элементов. |
|||
|
>>Include Table 10-19 “Algorithm Identification Macro Attributes” |
|||
Концептуальные объёмы могут быть объявлены эквивалентными другим концептуальным объёмам. В таких случаях Equivalent Conceptual Volumes Sequence (3010,000A) используется в производных экземплярах SOP, которым известно о других экземплярах SOP, определяющих семантически эквивалентный объём, но использующих другие Conceptual Volume UID (3010,0006).
Derivation Conceptual Volume Sequence (3010,0014) может использоваться для описания способа получения концептуального объёма из одного или нескольких других концептуальных объёмов в случаях, когда полностью описать метод получения невозможно. Поскольку концептуальный объём не может быть математически построен из описания получения, он будет явно определён посредством сегментации.
Спецификация получения (derivation) отличается от комбинирования концептуальных объёмов, как определено в разделе 10.34 «Conceptual Volume Segmentation Reference and Combination Macro».
Таблица 10.34-1 определяет атрибуты макроса ссылки на сегментацию и комбинирования концептуального объёма (Conceptual Volume Segmentation Reference and Combination Macro), который позволяет комбинировать концептуальные объёмы в качестве составляющих комбинированного объёма. Характерный пример — сегментировать левое и правое лёгкое, а затем объявить «Лёгкие» комбинированным концептуальным объёмом, для которого можно задать ограничения назначения.
Этот макрос также позволяет ссылаться на экземпляры SOP RT Segment Annotation, содержащие сегментированное представление концептуального объёма. При вызове данного макроса указывается, требуется ли такое сегментированное представление.
Рисунок 10.34-1 описывает экземпляр RT Physician Intent, в котором концептуальные объёмы «Lung, left» и «Lung, right» упоминаются, но не определяются. В этом примере экземпляры RT Segmentation Annotation затем определяют объёмную информацию концептуальных объёмов, ссылаясь на конкретный сегмент экземпляра Segmentation и конкретную ROI в экземпляре RT Structure Set.
Рисунок 10.34-2. Ссылки на комбинирование концептуального объёма (Conceptual Volume Combination References)
Рисунок 10.34-1 описывает экземпляр RT Physician Intent, определяющий концептуальные объёмы «Lung, left» и «Lung, right», а также концептуальный объём «Lung» как комбинацию первых двух без прямой ссылки на определение объёма.
Таблица 10.34-1. Атрибуты макроса ссылки на сегментацию и комбинирования концептуального объёма (Conceptual Volume Segmentation Reference And Combination Macro Attributes)
|
Указание на то, что данный концептуальный объём является комбинацией других концептуальных объёмов. |
|||
|
Ссылки на концептуальные объёмы, являющиеся составляющими данного концептуального объёма. См. раздел 10.34.1.1. Обязателен, если Conceptual Volume Combination Flag (3010,000E) равно YES. В этой последовательности должен присутствовать один или несколько элементов. UID комбинированного концептуального объёма не должен включаться в эту последовательность. |
|||
|
Индекс, на который ссылается Conceptual Volume Combination Expression (3010,000C), идентифицирующий составляющую концептуального объёма. Значение должно начинаться с 1 и монотонно увеличиваться на 1. |
|||
|
UID, идентифицирующий концептуальный объём, являющийся составляющей комбинированного концептуального объёма. |
|||
|
Ссылка на экземпляр SOP, содержащий исходное определение составляющей концептуального объёма, идентифицированной Constituent Conceptual Volume UID (3010,0013) в этой последовательности. Если данный концептуальный объём был создан в текущем экземпляре SOP, то UID ссылочного экземпляра SOP совпадает с UID текущего экземпляра SOP. В этой последовательности должен присутствовать только один элемент. |
|||
|
>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
>Conceptual Volume Constituent Segmentation Reference Sequence |
Содержит сегментированное представление составляющей концептуального объёма. Обязателен, если Conceptual Volume Segmentation Defined Flag (3010,0010) равно YES, а концептуальный объём не является комбинацией других концептуальных объёмов. В этой последовательности должен присутствовать только один элемент. См. раздел 10.34.1.2. |
||
|
Ссылка на экземпляр SOP, содержащий Direct Segment Reference Sequence (3010,0023). В этой последовательности должен присутствовать только один элемент. См. раздел 10.34.1.3. |
|||
|
>>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Segment Reference Index (3010,0022) в Segment Reference Sequence (3010,0021), соответствующий сегменту, представляющему данный концептуальный объём. Должен ссылаться только на элементы сегментов, содержащие Direct Segment Reference Sequence (3010,0023). |
|||
|
Символьное выражение, задающее комбинацию концептуальных объёмов в виде текстовой строки, состоящей из значений Conceptual Volume Constituent Index (3010,000D), операторов комбинирования и скобок. Обязателен, если Conceptual Volume Combination Flag (3010,000E) равно YES. См. раздел 10.34.1.1. |
|||
|
Читаемое человеком описание комбинации концептуальных объёмов. Эта информация предназначена для отображения и не должна использоваться для структурированной обработки. Обязателен, если Conceptual Volume Combination Flag (3010,000E) равно YES. |
|||
|
Указание на то, что для данного концептуального объёма определены сегментации. |
|||
|
Содержит сегментированное представление концептуального объёма. Обязателен, если Conceptual Volume Segmentation Defined Flag (3010,0010) равно YES, а Conceptual Volume Combination Flag (3010,000E) равно NO. В этой последовательности должен присутствовать только один элемент. См. раздел 10.34.1.4. |
|||
|
Ссылка на экземпляр SOP, содержащий Segment Reference Sequence (3010,0021), в которой определён сегмент. В этой последовательности должен присутствовать только один элемент. См. раздел 10.34.1.3. |
|||
|
>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Segment Reference Index (3010,0022) в Segment Reference Sequence (3010,0021), соответствующий сегменту, представляющему данный концептуальный объём. В указанном элементе сегмента должна присутствовать Direct Segment Reference Sequence (3010,0023). |
|||
Для концептуальных объёмов, заданных как комбинация других концептуальных объёмов, логика комбинирования определяется значением текстовой строки Conceptual Volume Combination Expression (3010,000C).
Для применения геометрических операторов к набору концептуальных объёмов используется вложенная списочная нотация.
Первым элементом списка должен быть один из следующих геометрических операторов:
Результат операции NEGATION однозначно определён только при использовании в качестве операнда INTERSECTION. NEGATION вне контекста INTERSECTION приводит к бесконечному объёму.
Последующие элементы должны задавать аргументы геометрического оператора. Аргументом является либо значение Conceptual Volume Constituent Index (3010,000D) (то есть положительное целое число), либо заключённый в скобки список операций.
Грамматика Conceptual Volume Combination Expression (<sexpr>) приведена ниже в форме BNF (Backus Naur Form):
<sexpr> :: <cv> | <list>
<cv> :: 1 | 2 | 3 | …
<list> :: ( <op1><sp><sexpr> ) |
( <op2><sp><sexpr><sp><sexpr> ) |
( <op3><sp><args> )
<args> :: <sexpr><sp><sexpr> | <args><sp><sexpr>
<op1> :: NEGATION
<op2> :: SUBTRACTION | XOR
<op3> :: UNION | INTERSECTION
<sp> :: 0x20
Объединение парных органов 1 и 2 (непересекающихся)
Рисунок 10.34.1.1-1. Пример концептуального объёма — объединение непересекающихся объёмов (Conceptual Volume Example of Union of Disjoint Volumes)
Conceptual Volume Combination Expression (3010,000C):
Элементы в Conceptual Volume Constituent Sequence (3010,0008):
Таблица 10.34.1.1-1. Пример концептуального объёма — объединение непересекающихся объёмов (Conceptual Volume Example of Union of Disjoint Volumes)
Объединение парных органов 1 и 2 (пересекающихся)
Рисунок 10.34.1.1-2. Пример концептуального объёма — объединение пересекающихся объёмов (Conceptual Volume Example of Union of Non-disjoint Volumes)
Conceptual Volume Combination Expression (3010,000C):
Элементы в Conceptual Volume Constituent Sequence (3010,0008):
Таблица 10.34.1.1-2. Пример концептуального объёма — объединение пересекающихся объёмов (Conceptual Volume Example of Union of non-disjoint Volumes)
Объединение двух органов 1 и 2 с исключением объёма 3 с помощью NEGATION
Рисунок 10.34.1.1-3. Пример концептуального объёма — пересечение и отрицание (Conceptual Volume Example of Intersection and Negation)
Conceptual Volume Combination Expression (3010,000C):
(INTERSECTION (UNION 1 2) (NEGATION 3) )
Элементы в Conceptual Volume Constituent Sequence (3010,0008):
Таблица 10.34.1.1-3. Пример концептуального объёма — пересечение и отрицание (Conceptual Volume Example of Intersection and Negation)
Объединение парных органов 1 и 2 с исключением нескольких объёмов 3, 4 и 5
Рисунок 10.34.1.1-4. Пример концептуального объёма — пересечение и объединение (Conceptual Volume Example of Intersection and Union)
Conceptual Volume Combination Expression (3010,000C):
(INTERSECTION (UNION 1 2) (NEGATION (UNION 3 4 5) ))
Элементы в Conceptual Volume Constituent Sequence (3010,0008):
Таблица 10.34.1.1-4. Пример концептуального объёма — пересечение и объединение (Conceptual Volume Example of Intersection and Union)
Пересечение перекрывающихся объёмов 1 и 2
Рисунок 10.34.1.1-5. Пример концептуального объёма — пересечение неразъединённых объёмов (Conceptual Volume Example of Intersection of Non-disjunct Volumes)
Conceptual Volume Combination Expression (3010,000C):
Элементы в Conceptual Volume Constituent Sequence (3010,0008):
Таблица 10.34.1.1-5. Пример концептуального объёма — пересечение неразъединённых объёмов (Conceptual Volume Example of Intersection of non-disjunct Volumes)
Пересечение непересекающихся объёмов 1 и 2
Рисунок 10.34.1.1-6. Пример концептуального объёма — пересечение неразъединённых объёмов (Conceptual Volume Example of Intersection of Non-disjunct Volumes)
Conceptual Volume Combination Expression (3010,000C):
Элементы в Conceptual Volume Constituent Sequence (3010,0008):
Таблица 10.34.1.1-6. Пример концептуального объёма — пересечение непересекающихся объёмов (Conceptual Volume Example of Intersection of disjunct Volumes)
Conceptual Volume Constituent Segmentation Reference Sequence (3010,0012) содержит ссылку на сегментацию, геометрически представляющую объём данной составляющей. Ссылочные сегментации составляющих комбинированного концептуального объёма могут находиться в одной или нескольких системах координат (Frames of Reference).
Составляющие концептуального объёма не должны включать определяемый комбинированный концептуальный объём. Приложения, желающие объединить существующие сегментации в рамках одного концептуального объёма, должны создать новый экземпляр Segmentation.
Экземпляр SOP может быть указан в этой последовательности только в том случае, если он принадлежит классу SOP, включающему раздел C.36.9 Segment Reference Module.
Таблица 10.35-1 определяет атрибуты макроса модели устройства (Device Model Macro), содержащего общие атрибуты, необходимые для указания модели устройства, отличного от устройства, создающего экземпляр SOP.
Таблица 10.35-1. Атрибуты макроса модели устройства (Device Model Macro Attributes)
Таблица 10.36-1 определяет атрибуты макроса идентификации устройства (Device Identification Macro), который идентифицирует устройство (физическое или виртуальное).
Таблица 10.36-1. Атрибуты макроса идентификации устройства (Device Identification Macro Attributes)
|
В данной последовательности должен присутствовать только один элемент. |
|||
|
Обозначение версии программного обеспечения оборудования, присвоенное изготовителем. |
|||
|
Дата первоначального изготовления или повторного изготовления устройства (в отличие от восстановления). |
|||
|
Дата установки устройства в его текущем местоположении. Устройство могло использоваться или не использоваться до установки в его текущем местоположении. |
|||
|
Уникальный идентификатор устройства (Unique Device Identifier, UDI). В данной последовательности допускается один или несколько элементов. |
|||
|
>Include Table 10.29-1 “UDI Macro Attributes” |
|||
|
Идентификатор, предназначенный для считывания устройством, например сканером штрихкода. |
|||
|
Определяет тип альтернативного идентификатора устройства. Обязателен, если Device Alternate Identifier (3010,001B) имеет значение. |
|||
|
Описание формата, в котором выпущен Device Alternate Identifier (3010,001B). Обязателен, если Device Alternate Identifier (3010,001B) имеет значение. См. раздел 10.36.1.1. |
|||
Как правило, идентификатор устройства представляет собой код, который может быть электронно считан машиной, использующей данное устройство, например, для подтверждения его наличия.
Device Alternate Identifier Format (3010,001D) определяет формат значения Device Alternate Identifier (3010,001B).
Если значение Device Alternate Identifier Type (3010,001C) равно RFID, существует большое разнообразие форматов RFID (некоторые примеры: DOD-96, DOD-64 UID, GID-96, sgtin-96). Поддерживаемые значения формата должны быть определены в Заявлении о соответствии (Conformance Statement).
Для Device Alternate Identifier Type (3010,001C) = BARCODE см. раздел C.22.1.1.
Таблица 10.37-1 определяет атрибуты макроса связанных информационных сущностей (Related Information Entities Macro), который определяет ссылки на сущности и назначение ссылки. Ссылки могут быть сделаны на уровне исследования (Study), серии (Series), экземпляра (Instance) или кадра (Frame).
Атрибуты Pertinent SOP Classes in Study (3010,0052) и Pertinent SOP Classes in Series (3010,0053) позволяют указать релевантные классы SOP для заданного назначения. Эти атрибуты поддерживают фильтрацию по определённым классам SOP, указание соответствующих ключей запроса, а также позволяют принимающему приложению оценить свою способность обрабатывать указанные объекты.
Все ссылки на исследования, серии и экземпляры имеют одно общее назначение ссылки (Purpose of Reference).
Таблица 10.37-1. Атрибуты макроса связанных информационных сущностей (Related Information Entities Macro Attributes)
|
Описывает назначение, для которого создаются ссылки. В данной последовательности должен присутствовать только один элемент. |
|||
|
Исследования, релевантные для контекста вызова. В данной последовательности должен присутствовать один или несколько элементов. |
|||
|
Классы SOP в исследовании, релевантные для контекста вызова. Если отсутствует, все экземпляры SOP, включённые в указанное исследование, считаются релевантными. |
|||
|
Серии, релевантные для контекста вызова. В данной последовательности допускается один или несколько элементов. |
|||
|
Классы SOP в серии, релевантные для контекста вызова. Если отсутствует, все экземпляры SOP, включённые в указанную серию, считаются релевантными. |
|||
|
Экземпляры SOP изображений, релевантные в контексте вызова. В данной последовательности допускается один или несколько элементов. |
|||
|
>>>Include Table 10-3 “Image SOP Instance Reference Macro Attributes” |
|||
|
Экземпляры SOP, не являющиеся изображениями, релевантные в контексте вызова. В данной последовательности допускается один или несколько элементов. |
|||
|
>>>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
Таблица 10.38-1 определяет атрибуты макроса определения контура (Outline Definition Macro), который описывает двумерный (2D) контур в заданной системе координат.
Таблица 10.38-1. Атрибуты макроса определения контура (Outline Definition Macro Attributes)
|
См. раздел 10.38.1.1. |
|||
|
X-координата в мм левого края прямоугольного контура (параллельно оси y системы координат). Обязателен, если Outline Shape Type (0018,1630) равен RECTANGULAR. См. раздел 10.38.1.2. |
|||
|
X-координата в мм правого края прямоугольного контура (параллельно оси y системы координат). Обязателен, если Outline Shape Type (0018,1630) равен RECTANGULAR. См. раздел 10.38.1.2. |
|||
|
Y-координата в мм верхнего края прямоугольного контура (параллельно оси x системы координат). Обязателен, если Outline Shape Type (0018,1630) равен RECTANGULAR. См. раздел 10.38.1.2. |
|||
|
Y-координата в мм нижнего края прямоугольного контура (параллельно оси x системы координат). Обязателен, если Outline Shape Type (0018,1630) равен RECTANGULAR. См. раздел 10.38.1.2. |
|||
|
Расположение (x,y) в мм центра кругового контура. Обязателен, если Outline Shape Type (0018,1630) равен CIRCULAR. См. раздел 10.38.1.2. |
|||
|
Диаметр в мм кругового контура. Обязателен, если Outline Shape Type (0018,1630) равен CIRCULAR. См. раздел 10.38.1.2. |
|||
|
Количество вершин в Vertices of the Polygonal Outline (0018,1638). Обязателен, если Outline Shape Type (0018,1630) равен POLYGONAL. |
|||
|
Поток данных из пар x и y в мм. Полигональные контуры неявно замыкаются от последней вершины к начальной вершине, и все рёбра не должны пересекаться, кроме как в вершинах. Любая заданная вершина должна встречаться в потоке данных только один раз. Обязателен, если Outline Shape Type (0018,1630) равен POLYGONAL. Число пар в данном потоке данных должно быть равно значению Number of Polygonal Vertices (0018,1637). См. раздел 10.38.1.2. |
Таблица 10.39-1 определяет атрибуты макроса отношения пациента к оборудованию (Patient to Equipment Relationship Macro), который описывает положение пациента относительно устройства. Положение определяется посредством матрицы преобразования между системой координат пациента (Patient Frame of Reference) и системой координат оборудования (Equipment Frame of Reference).
Таблица 10.39-1. Атрибуты макроса отношения пациента к оборудованию (Patient to Equipment Relationship Macro Attributes)
|
Жёсткая однородная матрица преобразования 4x4, отображающая координатное пространство пациента в системе координат, используемой для модели пациента, в систему координат, определённую оборудованием. Элементы матрицы должны быть перечислены в порядке по строкам (row-major order). |
|||
|
Комментарии, введённые оператором-человеком относительно отношения между системой координат пациента и оборудованием. Только для целей отображения, не должны использоваться для иных целей. |
|||
|
Конкретные точки в системе координат пациента, которые дополнительно характеризуют положение пациента относительно оборудования. В данной последовательности должно присутствовать ноль или более элементов. |
|||
|
Координата (x,y,z) в мм, описывающая расположение в системе координат пациента, которое будет преобразовано в систему координат оборудования с помощью Image to Equipment Mapping Matrix (0028,9520). |
|||
|
Идентифицирует тип координаты расположения пациента. В данной последовательности должен присутствовать один или несколько элементов. |
|||
|
>>Include Table 8.8-1 “Code Sequence Macro Attributes”. |
|||
|
Фактические параметры положения опоры пациента (Patient Support Position). Должны соответствовать Image to Equipment Mapping Matrix (0028,9520). См. раздел 10.39.1.2. В данной последовательности должно присутствовать ноль или один элемент. |
|||
|
>Include Table 10.40-1 “Patient Support Position Macro Attributes”. |
|||
Единица оборудования имеет систему координат оборудования (Equipment Coordinate System), которая может использоваться для выражения геометрических понятий, таких как расположение и ориентация. Система координат характеризуется расположением начала координат и ориентацией координатных осей относительно оборудования. Система координат оборудования является правой (right-handed) системой координат.
Системы координат оборудования, как правило, основаны на стандартизированном определении осей. Выбор начала координат часто зависит от конкретного устройства или типа устройства. Им может быть любое значимое расположение на аппарате, например изоцентр аппарата, зависящий от изготовителя.
Система координат оборудования может использоваться в качестве родительской для производных систем координат.
Image to Equipment Mapping Matrix (0028,9520) описывает отношение между системой координат, ориентированной на пациента, и системой координат оборудования. Данная матрица AM Bописывает жёсткое преобразование точки ( Bx, By, Bz) относительно системы координат пациента в ( Ax, Ay, Az) относительно системы координат оборудования, как определено в разделе C.7.6.21.1.
Система координат оборудования идентифицируется по Equipment Frame of Reference UID (300A,0675). Дополнительную информацию об определении системы координат оборудования см. раздел 10.39.1.1. Система координат, ориентированная на пациента, идентифицируется по Frame of Reference UID (0020,0052) экземпляра SOP, в котором она используется. Обе системы координат выражены в миллиметрах.
Макрос положения опоры пациента (Patient Support Position Macro), вызываемый Patient Support Position Sequence (3006,00CB), позволяет обмениваться специфичными для устройства параметрами опоры пациента. Приложения, предназначенные для управления конкретным устройством опоры пациента, смогут разложить преобразование на специфичные для устройства параметры или получить матрицу преобразования из этих параметров. Приложения, которым неизвестно разложение преобразования на эти параметры и наоборот, всё равно смогут отображать пользователю исходные метки и числовые значения этих параметров.
Patient Support Position Sequence (3006,00CB) может присутствовать для аннотирования матрицы и отображения разложенного содержимого матрицы. Содержимое макроса положения опоры пациента (Patient Support Position Macro) должно использоваться только для целей отображения. Оно не должно использоваться для иных целей. Содержимое данного макроса не должно использоваться в качестве замены Image to Equipment Mapping Matrix (0028,9520). В общем случае существует более одного способа достичь точки в пространстве, описываемой Image to Equipment Mapping Matrix (0028,9520). Поэтому явно не подразумевается, каким образом достигается данное положение.
В некоторых случаях (например, экстренное лечение в радиотерапии) система координат пациента не определяется серией изображений. В этом случае для системы координат пациента используется произвольная система координат (Frame of Reference) в модуле системы координат (Frame of Reference Module) экземпляра SOP. Image to Equipment Mapping Matrix (0028,9520) имеет то же значение, что и в случае системы координат пациента на основе изображений.
Если система координат модели пациента недоступна, может использоваться общеизвестная (well-known) система координат устройства опоры пациента.
Общеизвестная система координат, а также её начало координат и ориентация относительно устройства должны быть документированы в Заявлении о соответствии (Conformance Statement). Обратите внимание, что ориентация осей общеизвестной системы координат привязана к устройству, а не к пациенту.
Например, начальное положение необходимо указать для настройки положения пациента до проведения визуализации. Для процедурного стола, начало координат и ориентация которого определены [IEC 61217], может использоваться общеизвестный Frame of Reference UID «1.2.840.10008.1.4.3.3».
Если присутствуют и Image to Equipment Mapping Matrix (0028,9520), и Patient Support Position Sequence (3006,00CB), информация в обоих местах должна быть согласована.
Таблица 10.40-1 определяет атрибуты макроса положения опоры пациента (Patient Support Position Macro), который предоставляет специфичные для устройства геометрические настройки опоры пациента.
Данная информация предназначена для отображения человеку-читателю и для поддержки позиционирования пациента, не основанного на изображениях; однако определение положения пациента относительно устройства содержится в Image to Equipment Mapping Matrix (0028,9520).
Таблица 10.40-1. Атрибуты макроса положения опоры пациента (Patient Support Position Macro Attributes)
|
Параметры перемещения и вращения для устройств опоры пациента. Обязателен, если Patient Support Position Specification Method (300A,065C) не равен ABSENT. В данной последовательности должен присутствовать один или несколько элементов, если Patient Support Position Specification Method (300A,065C) равен DEVICE_SPECIFIC. В данной последовательности должен присутствовать только один элемент, если Patient Support Position Specification Method (300A,065C) равен GLOBAL. |
|||
|
Значение Device Index (3010,0039) в Patient Support Devices Sequence (300A,0686), соответствующее используемому устройству опоры пациента. Обязателен, если Patient Support Position Specification Method (300A,065C) равен DEVICE_SPECIFIC. |
|||
|
Индекс, определяющий порядок применения элементов Patient Support Position Device Parameter Sequence (300A,065D). Значение должно начинаться с 1 и монотонно возрастать на 1. Обязателен, если Patient Support Position Specification Method (300A,065C) равен DEVICE_SPECIFIC. См. раздел 10.40.1. |
|||
|
Параметры перемещения и вращения для конкретного устройства опоры пациента. В данной последовательности должен присутствовать один или несколько элементов. |
|||
|
Индекс, определяющий порядок применения элементов Patient Support Position Parameter Sequence (300A,065B). Значение должно начинаться с 1 и монотонно возрастать на 1. Обязателен, если Patient Support Position Specification Method (300A,065C) равен DEVICE_SPECIFIC. См. раздел 10.40.1. |
|||
|
>>Include Table 10-2 “Content Item Macro Attributes”. |
|||
Device Order Index (300A,065E) и Patient Support Position Parameter Order Index (300A,065F) применяются последовательно, то есть все элементы Patient Support Position Parameter Sequence (300A,065B) применяются перед переходом к элементу Patient Support Position Device Parameter Sequence (300A,065D), указанному следующим значением Device Order Index (300A,065E).
Производитель может указывать коды, не включённые в TID 15302, и/или набор кодов, не идентичный набору, определённому в разделе 10.40.1.1 или разделе 10.40.1.2. Производитель должен документировать коды, используемые в данном макросе, в Заявлении о соответствии (Conformance Statement), а также соответствующие параметры, их геометрическую интерпретацию и порядок их применения. Эти параметры должны использовать единицы UCUM: мм для длин и градусы для углов.
Устройства, использующие системы координат [IEC 61217] для определения геометрических настроек устройства опоры пациента, должны использовать коды из Таблица 10.40-2, в порядке, указанном в колонке Patient Support Position Parameter Order Index (300A,065F). Другие коды не должны использоваться.
Таблица 10.40-2. Индекс порядка параметров положения опоры пациента IEC 61217 (IEC 61217 Patient Support Position Parameter Order Index)
Устройства, использующие изоцентрическое представление для определения геометрических настроек устройства опоры пациента, должны использовать коды из Таблица 10.40-3, в порядке, указанном в колонке Patient Support Position Parameter Order Index (300A,065F). Другие коды не должны использоваться.
Таблица 10.40-3. Индекс порядка параметров изоцентрического положения опоры пациента (Isocentric Patient Support Position Parameter Order Index)
Таблица 10.41-1 определяет атрибуты макроса ссылки на общий протокол процедуры (General Procedure Protocol Reference Macro), который идентифицирует экземпляр SOP протокола процедуры и элемент протокола, связанные с созданием экземпляра.
Поскольку все экземпляры в серии часто создаются на основе одного и того же протокола сбора/реконструкции, протокол часто рассматривается на уровне серии (Protocol Name (0018,1030) находится в General Series Module). Однако допустимо наличие нескольких экземпляров в одной серии, где каждый экземпляр был создан с использованием другого протокола и/или другого элемента протокола.
Таблица 10.41-1. Атрибуты макроса ссылки на общий протокол процедуры (General Procedure Protocol Reference Macro Attributes)
|
Экземпляр(ы) SOP определённого протокола процедуры (Defined Procedure Protocol), использованные для данного экземпляра. Обязателен, если данный экземпляр является выполненным протоколом процедуры (Performed Procedure Protocol), полученным из определённого протокола процедуры (Defined Procedure Protocol). В остальных случаях может присутствовать. В данной последовательности должен присутствовать один или несколько элементов. См. раздел 10.41.1. |
|||
|
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Единственное значение, соответствующее Protocol Element Number (0018,9921) из Acquisition Protocol Element Specification Sequence (0018,991F), соответствующего данному экземпляру. Не должен присутствовать, если присутствует Source Reconstruction Protocol Element Number (0018,993A). |
|||
|
Единственное значение, соответствующее Protocol Element Number (0018,9921) из Reconstruction Protocol Element Specification Sequence (0018,9933), соответствующего данному экземпляру. Не должен присутствовать, если присутствует Source Acquisition Protocol Element Number (0018,9938). |
|||
|
Экземпляр(ы) SOP выполненного протокола процедуры (Performed Procedure Protocol), описывающие условия, при которых был создан данный экземпляр. Обязателен, если был создан связанный экземпляр SOP выполненного протокола процедуры (Performed Procedure Protocol). В данной последовательности должен присутствовать один или несколько элементов. См. раздел 10.41.1. |
|||
|
>Include Table 10-11 “SOP Instance Reference Macro Attributes” |
|||
|
Единственное значение, соответствующее Protocol Element Number (0018,9921) из Acquisition Protocol Element Sequence (0018,9920), соответствующего данному экземпляру. Не должен присутствовать, если присутствует Source Reconstruction Protocol Element Number (0018,993A). |
|||
|
Единственное значение, соответствующее Protocol Element Number (0018,9921) из Reconstruction Protocol Element Sequence (0018,9934), соответствующего данному экземпляру. Не должен присутствовать, если присутствует Source Acquisition Protocol Element Number (0018,9938). |
|||
Referenced Defined Protocol Sequence (0018,990C) содержит ссылку на экземпляр(ы) SOP определённого протокола процедуры (Defined Procedure Protocol) и элемент протокола, использованные для создания данного экземпляра. Referenced Performed Protocol Sequence (0018,990D) содержит ссылку на экземпляр(ы) SOP выполненного протокола процедуры (Performed Procedure Protocol) и элемент протокола, описывающие условия, при которых был создан данный экземпляр.
Несколько элементов в Referenced Defined Protocol Sequence (0018,990C) могут представлять групповой случай, когда несколько определённых протоколов процедуры (Defined Procedure Protocol) были выполнены вместе как единый выполненный протокол процедуры (Performed Procedure Protocol).
Несколько элементов в Referenced Performed Protocol Sequence (0018,990D) рекомендуются, если сбор и реконструкция были зафиксированы в отдельных экземплярах SOP выполненного протокола процедуры (Performed Procedure Protocol). Однако не предполагается, что данная последовательность ссылается на экземпляры SOP определённого или предшествующего выполненного протокола, на основе которых был создан текущий экземпляр SOP выполненного протокола процедуры. Такие ссылки могут находиться внутри самого текущего экземпляра SOP выполненного протокола процедуры.
В случае, если сбор и реконструкция выполняются на двух отдельных устройствах, соединённых через сеть, устройство реконструкции может использовать Source Acquisition Protocol Element из Referenced Defined Protocol для определения изображений, которые будут реконструированы с заданным элементом протокола реконструкции.
Таблица 10.42-1 определяет атрибуты макроса иерархической ссылки на свидетельство (Hierarchical Evidence Reference Macro).
Таблица 10.42-1. Атрибуты макроса иерархической ссылки на свидетельство (Hierarchical Evidence Reference Macro Attributes)
|
Необработанные данные (Raw data), использованные для получения данного изображения. В данной последовательности допускается один или несколько элементов. NoteЭлементы данной последовательности могут идентифицировать необработанные данные, которые не были сохранены или закодированы как объект DICOM. Это позволяет распознать, что изображения и спектры в разных экземплярах были реконструированы из одних и тех же необработанных данных. Для таких элементов Referenced SOP Class UID (0008,1150) может быть равен "1.2.840.10008.5.1.4.1.1.66" (Raw Data Storage). |
|||
|
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
|
Ссылки на волновые формы (waveforms), полученные вместе с данным изображением. Эти волновые формы могут быть или не быть синхронизированы во времени с данным изображением. В данной последовательности допускается один или несколько элементов. |
|||
|
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
|
Полный набор составных экземпляров SOP, на которые указывают ссылки внутри Referenced Image Sequences данного экземпляра. См. раздел 10.42.1.1 для дополнительных пояснений. В данной последовательности должен присутствовать один или несколько элементов. Обязателен, если Referenced Image Sequence (0008,1140) присутствует и не пуст, и SOP Class UID (0008,0016) ссылающегося экземпляра SOP не является устаревшим преобразованным классом SOP ("1.2.840.10008.5.1.4.1.1.2.2" (Legacy Converted Enhanced CT Image Storage), "1.2.840.10008.5.1.4.1.1.4.4" (Legacy Converted Enhanced MR Image Storage), "1.2.840.10008.5.1.4.1.1.128.1" (Legacy Converted Enhanced PET Image Storage)). В остальных случаях может присутствовать. |
|||
|
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
|
Полный набор составных экземпляров SOP, на которые указывают ссылки внутри Source Image Sequences данного экземпляра. См. раздел 10.42.1.1 для дополнительных пояснений. В данной последовательности должен присутствовать один или несколько элементов. Обязателен, если Source Image Sequence (0008,2112) присутствует и не пуст, и SOP Class UID (0008,0016) ссылающегося экземпляра SOP не является устаревшим преобразованным классом SOP ("1.2.840.10008.5.1.4.1.1.2.2" (Legacy Converted Enhanced CT Image Storage), "1.2.840.10008.5.1.4.1.1.4.4" (Legacy Converted Enhanced MR Image Storage), "1.2.840.10008.5.1.4.1.1.128.1" (Legacy Converted Enhanced PET Image Storage)). В остальных случаях может присутствовать. |
|||
|
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
|
Ссылки на экземпляры состояния представления (Presentation State), созданные вместе с данным экземпляром NoteДанная последовательность не ссылается на состояния представления (Presentation States), созданные после создания изображения, например, во время интерпретации. В данной последовательности должен присутствовать один или несколько элементов. Обязателен, если состояние представления (Presentation State) создано вместе с изображениями. |
|||
|
>Include Table C.17-3 “Hierarchical SOP Instance Reference Macro Attributes” |
|||
Each Composite IOD is composed of the following Sections
Optionally, a Functional Group Macros Table used by the Multi-frame Functional Groups Module
Section A.1.1, Section A.1.2 and Section A.1.3 define the requirements of a) through d) above.
This Section of an IOD provides the Entity-Relationship (E-R) Model that depicts the relationships of the components or Information Entities (IE) of the specified IOD. It forms an IOD specific information model. This E-R model provides the complete context of how the Composite Instance information shall be interpreted when a Composite Instance is exchanged between two DICOM Application Entities; in particular, an IOD will specify a single IE at the level below the Series IE.
Even though Composite Instances are encoded as discrete individual components, each Composite Instance IOD E-R Model requires that all Composite Instances that are part of a specific Study shall share the same context. That is, all Composite Instances within a specific Patient Study share the same Patient and Study information; all Composite Instances within the same Series share the same Series information; etc.
Figure A.1-1 is the DICOM Composite Instance IOD Information Model. It applies to all Patient-related Composite Instance IODs defined in Annex A. However, a subset of this model may be specified by each individual Composite Instance IOD to accurately define the context for specific Composite Instance exchange.
The sub-sections of this Section describe the Information Entities (IE) that comprise the Composite Instance IODs defined in this Annex.
The Patient IE defines the characteristics of a Patient who is the subject of one or more medical Studies.
The Study IE defines the characteristics of a medical Study performed on a Patient. A Study is a collection of one or more Series of medical images, presentation states, and/or SR documents that are logically related for the purpose of diagnosing a Patient. Each Study is associated with exactly one Patient.
A Study may include Composite Instances that are created by a single modality, multiple modalities or by multiple devices of the same modality.
The Series IE defines the Attributes that are used to group Composite Instances into distinct logical sets. Each Series is associated with exactly one Study.
The following criteria group Composite Instances into a specific Series:
All Composite Instances within a Series must be of the same modality
Each Series may be associated with exactly one Frame of Reference IE, and if so associated all Composite Instances within the Series shall be spatially or temporally related to each other
All Composite Instances within the Series shall be created by the same equipment; therefore, each Series is associated with exactly one Equipment IE
All Composite Instances within a Series shall have the same Series information
Presentation States shall be grouped into one or more Series without Images or Waveforms (i.e., in a different Series from the Series containing the Images or Waveforms to which they refer).
The Series containing Grayscale, Color and Pseudo-Color Softcopy Presentation States and the Series containing the Images to which they refer are both contained within the same Study, except for Blending Presentation States, which may refer to images from different Studies.
The Series containing the Waveform Presentation State and the Series containing the Waveforms to which they refer are both contained within the same Study.
The Series containing the Waveform Presentation State and the Series containing Waveform Annotation SRs to which they refer are both contained in the same Study but in different Series.
Waveforms shall be grouped into Series without Images. A Frame of Reference IE may apply to both Waveform Series and Image Series.
SR Documents shall be grouped into Series without Images. The Frame of Reference IE may apply to SR Document Series, for SR Documents that contain 3D spatial coordinates relative to one or more spatial Frames of Reference, or temporal coordinates that require a temporal Frame of Reference.
The Equipment IE describes the particular device that produced the Series of Composite Instances. A device may produce one or more Series within a Study. The Equipment IE does not describe the data acquisition or image creation Attributes used to generate the Composite Instances within a Series. These Attributes are described in the Composite Instance specific IEs (e.g., the Image IE).
The Frame of Reference IE identifies the coordinate system that conveys spatial and/or temporal information of Composite Instances in a Series.
When present, a Frame of Reference IE may be related to one or more Series. In this case, it provides the ability to spatially or temporally relate multiple Series to each other. In such cases, the Series may share the UID of the Frame of Reference, or alternatively, a Registration SOP Instance may specify the spatial relationship explicitly, as a spatial transformation. A Frame of Reference IE may also spatially register a Frame of Reference to an atlas.
The Image IE defines the Attributes that describe the pixel data of an image. The pixel data may be generated as a direct result of Patient scanning (termed an Original Image) or the pixel data may be derived from the pixel data of one or more other images (termed a Derived Image). An image is defined by its image plane, pixel data characteristics, gray scale and/or color mapping characteristics and modality specific characteristics (acquisition parameters and image creation information).
An image is related to a single Series within a single Study.
The pixel data within an Image IE may be represented as a single Frame of pixels or as multiple Frames of pixel data. The Frames of a Multi-frame Image (a Cine Run or the slices of a volume) are sequentially ordered and share a number of common properties. A few Attributes may vary between Frames (e.g., Time, Angular Displacement, Slice Increment). All common Image IE Attributes refer to the first Frame of a Multi-frame Image.
Overlay, Modality and Value of Interest Lookup Table and Real World Value Mapping data may be included within an Image IE only if this information is directly associated with the image.
Overlay data represents graphics or text in a bit-map format, and is used to indicate such items as region of interest, reference marks and annotations.
Modality LUT data describes the transformation of manufacturer dependent pixel values into pixel values that are manufacturer independent (e.g., Hounsfield units for CT, Optical Density for film digitizers, etc.). The transformation may be linear, described by Rescale Slope (0028,1053) and Rescale Intercept (0028,1052), or non-linear, described by a Lookup Table (LUT).
The Value of Interest (VOI) LUT data describes the transformation of the modality pixel values into pixel values that are meaningful for print, display, etc. This transformation is applied after any Modality LUT. The transformation may be linear, described by Window Center and Window Width, or non-linear, described by a Lookup Table. A non-linear interpretation of Window Center and Window Width may be defined by VOI LUT Function.
The Real World Value Mapping data describes the transformation of the image pixel values into Real World Values in defined units. There may be multiple transformations, each scoped by a range of input pixel values. Each transformation may be linear, described by Slope and Intercept, or non-linear, described by a Lookup Table.
Retired. See PS3.3-2016a.
Overlays were previously modeled as independent Information Entities; in the current model they are considered Attributes within the Image IE or Presentation State IE. See A.1.2.6.1.
Retired. See PS3.3-2004.
Retired. See PS3.3-2016a.
Modality LUTs were previously modeled as independent Information Entities; in the current model they are considered Attributes within the Image IE or Presentation State IE. See A.1.2.6.2.
Retired. See PS3.3-2016a.
VOI LUTs were previously modeled as independent Information Entities; in the current model they are considered Attributes within the Image IE or Presentation State IE. See A.1.2.6.3.
The Presentation State IE defines how a referenced image (or images) will be presented (e.g., displayed) in a device independent grayscale space (i.e., in P-Values) or color space (i.e., in PCS-values), and what graphical annotations and spatial and grayscale contrast transformations will be applied to the referenced image pixel data.
Overlay, Modality LUT, and VOI LUT data (see A.1.2.6.1, A.1.2.6.2, and A.1.2.6.3) may be included within a Presentation State IE if this information is to be applied to the referenced image(s).
The Waveform IE represents a multi-channel time-based digitized waveform. The waveform consists of measurements of some physical qualities (e.g., electrical voltage, pressure, gas concentration, or sound), sampled at constant time intervals. The measured qualities may originate, for example, in any of the following sources:
The sample data within a Waveform IE may represent one or more acquired channels. Several signal channels acquired at the same sampling rate can be multiplexed (by interleaving samples) in a single multiplex group. (see also Annex C “Waveforms (Informative)” in PS3.17.)
The SR Document IE defines the Attributes that describe the content of an SR Document. These include semantic context as well as Attributes related to document completion, verification and other characteristics. An SR Document SOP Instance is related to a single Series within a single Study.
The Spectroscopy IE defines the Attributes that describe the data of a spectroscopy acquisition created by a magnetic resonance spectroscopy device.
The Raw Data IE defines the Attributes that describe a collection of data that may be used for further processing to produce image data or other data.
The Encapsulated Document IE defines the Attributes that describe the content of a non-DICOM formatted document that is encapsulated in a DICOM Attribute. These include Attributes related to document origin, title, and other characteristics. An Encapsulated Document SOP Instance is related to a single Series within a single Study.
The Real World Value Mapping IE defines the Attributes that describe the mapping of stored pixel data to Real World values (see A.1.2.6.4).
The Surface IE defines the Attributes that describe a surface in a spatial coordinate system. A surface is defined by its shape and can be further defined by normals on that shape. The surface may be reconstructed from either spatial scans (e.g., laser scanners) or based on images. A surface is described by its finite volume and manifold property, gray scale and color mapping characteristics, presentation type, opacity, and modality specific characteristics.
The Measurements IE defines the Attributes that describe the measurements taken by medical instruments.
The Tractography Results IE defines the Attributes that describe the results of a tractography application.
The Plan IE defines the parameters and instructions to deliver treatment, particularly Radiotherapy, to the Patient. The entity includes the set of machine and positioning parameters to be applied during treatment delivery and instructions guiding the treatment workflow.
The Content Assessment Result IE contains the results of an assessment of the content of a SOP Instance.
An assessment is part of a process within a clinical workflow, conducted by users or devices, which have the role of assessing the validity and suitability of the content in question, based on subjective or objective criteria. The specific nature of such a process is outside of the scope of this Standard.
The Spatial Fiducials IE identifies one or more geometric locations or shapes within a Frame of Reference or image pixel/voxel space that may be correlated with similar locations or shapes within different Frames of Reference or image pixel/voxel spaces.
The Dose IE describes dose distributions calculated by radiotherapy treatment planning systems. These distributions may be represented as 2D or 3D grids, as isodose curves, or as named or unnamed dose points scattered throughout a volume.
The Structure Set IE describes Regions of Interest (ROI) within a referenced 2D (image) or 3D (volumetric) space. These ROIs may be represented as geometric contours.
The Procedure Protocol IE defines the Attributes that describe a Protocol. This IE may encode a Defined Procedure Protocol or a Performed Procedure Protocol.
The Acquisition IE defines the Attributes that describe a single continuous gathering of data.
An Acquisition may result in more than one Series, and a Series may contain Instances from more than one Acquisition.
The Multi-Resolution Pyramid IE describes a set of Images that encode the same image data at different spatial resolutions, i.e., a base (highest resolution) layer that is successively smoothed and down-sampled to create additional lower resolution layers (a multi-resolution decomposition).
No specific method of filtering or down-sampling is specified by the Standard, nor is there a requirement for any specific down-sampling factor between layers, nor that an integer factor be used.
Each layer is encoded as a separate DICOM Image, each of which has a uniform resolution (same Value for Pixel Spacing (0028,0030)). Layers may be tiled, with each tile encoded as a Frame of a Multi-frame Image.
All DICOM Image SOP Instances that constitute a single Multi-Resolution Pyramid shall share the same Frame of Reference, and shall be contained in the same Series.
Only one Multi-Resolution Pyramid shall be contained in a Series (i.e., each such Multi-Resolution Pyramid will be in a different Series).
In historical usage, there is no Multi-Resolution Pyramid IE and thus a Series is not constrained to contain only a single conceptual pyramid. However, any instantiation of the Multi-Resolution Pyramid in a Series constrains the Series to one Multi-Resolution Pyramid.
Each Multi-Resolution Pyramid may be accompanied in the same Series by LABEL, OVERVIEW and THUMBNAIL images if they share the same Frame of Reference (but not otherwise, per the definition of the Series IE). The THUMBNAIL image rather than a VOLUME image may be the apex (lowest resolution layer) of the Multi-Resolution Pyramid.
A unique identifier, Pyramid UID (0008,0019) will be assigned to an instance of a Multi-Resolution Pyramid, and will be shared by all of the layers that constitute that instance of a Multi-Resolution Pyramid, whether or not a particular resolution layer (usually the highest resolution) is deemed to be ORIGINAL, and the lower resolution layers DERIVED (e.g., by some down-sampling image processing operation). By definition, the absence of Pyramid UID (0008,0019) implies the absence of instantiation of the Multi-Resolution Pyramid IE.
That use is distinct from the Pyramid UID (0008,0019) of different Multi-Resolution Pyramids that may be further derived from a Multi-Resolution Pyramid. In otherwords, the Pyramid UID (0008,0019) of a Multi-Resolution Pyramid will not be shared between two pyramids that contain different pixel data (other than differences due to lossless representation of the same pixel data in different Transfer Syntaxes).
The Waveform Presentation State IE defines how referenced waveforms will be presented.
The Waveform Presentation State IE comprises text annotations, segments of interest, and montages including filters, colors, gain, and vertical sizes of waveform channels if this information is to be applied to the referenced waveform(s). It might also contain display information for structured annotations related to the referenced waveform(s).
This Section of each IOD defines in a tabular form the Modules comprising the IOD. The following information must be specified for each Module in the table:
A reference to the Section in Annex C that defines the Module or Functional Group
The usage of the Module or Functional Group; whether it is:
Mandatory (see Section A.1.3.1), abbreviated M
Conditional (see Section A.1.3.2), abbreviated C
User Option (see Section A.1.3.3), abbreviated U
The Modules referenced are defined in Annex C.
For each IOD, Mandatory Modules shall be supported per the definitions, semantics and requirements defined in Annex C.
Conditional Modules are Mandatory Modules if specific conditions are met. If the specified conditions are not met, this Module shall not be supported; that is, no information defined in that Module shall be present.
User Option Modules may or may not be supported. If an optional Module is supported, the Attribute Types specified in the Modules in Annex C shall be supported.
The Tables in this Section provide an overview of the Modules used throughout the Composite IODs. This table is for informative purposes only. It is based on the IOD definitions found in the remaining Sections of Annex A that are normative.
* The notation next to M and U indicates a special condition for these Modules. Refer to the corresponding IODs in this Annex for details.
The original Ultrasound Image IOD and Ultrasound Multi-frame IOD, and the associated Ultrasound Image Storage SOP Class UID and Ultrasound Multi-frame Image Storage SOP Class UID have been retired. See PS3.3-1993. A new Ultrasound Image IOD and a new Ultrasound Multi-frame Image IOD are defined, as shown in Table A.1-1a, which includes the Palette Color Lookup Table Module.
The original Nuclear Medicine Image IOD and the associated Nuclear Medicine Image Storage SOP Class UID have been retired. See PS3.3-1993. A completely new Nuclear Medicine Image IOD is defined, as shown in Table A.1-1a.
Table A.1-1d. Composite Information Object Modules Overview - More Images
Table A.1-3. Composite Information Object Modules Overview - More Non-Images
The Computed Radiography Image IOD specifies an image that has been created by a computed radiography imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE. The Frame of Reference IE is not a component of this IOD.
Table A.2-1 specifies the Modules of the Computed Radiography Image IOD.
The Curve Module (Retired) was previously included in the Image IE for this IOD but has been retired. See PS3.3-2004.
The CT Image IOD specifies an image that has been created by a Computed Tomography imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.3-1 specifies the Modules of the CT Image IOD.
If Multi-energy CT Acquisition (0018,9361) is YES the following constraints will apply:
The Contrast/Bolus Module shall be present if contrast was administered even if images are processed to remove contrast information from the pixels, e.g. Virtual Non-Contrast images.
The Real World Value Mapping Sequence (0040,9096) shall be present in the General Image Module.
For Measurement Units Code Sequence (0040,08EA) in the Real World Value Mapping Sequence (0040,9096) DCID 301 “Multi-energy Material Unit” shall be used.
The MR Image IOD specifies an image that has been created by a Magnetic Resonance imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
The Nuclear Medicine Image IOD specifies an image that has been created by a Nuclear Medicine (NM) imaging device. This includes data created by external detection devices that create images of the distribution of administered radioactive materials in the body. Depending on the specific radio pharmaceutical administered and the particular imaging procedure performed, problems involving changes in metabolism, function, or physiology can be investigated and various regional pathologies can be studied.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Retired. See PS3.3-1993.
Table A.5-1 specifies the Modules of the Nuclear Medicine Image IOD.
Table A.5-1. Nuclear Medicine Image IOD Modules
|
U - See Section A.5.4.1 |
|||
|
C - Required if Image Type (0008,0008) Value 3 is TOMO, GATED TOMO, RECON TOMO or RECON GATED TOMO |
|||
|
C - Required if Image Type (0008,0008) Value 3 is GATED, GATED TOMO, or RECON GATED TOMO |
|||
|
C - Required if Image Type (0008,0008) Value 3 is RECON TOMO or RECON GATED TOMO |
|||
|
C - Required if the SOP Instance was created in response to a Frame-Level retrieve request |
The Curve Module (Retired) was previously included in the Image IE for this IOD but has been retired. See PS3.3-2004.
For Acquisition Context Sequence (0040,0555) DTID 3470 “NM/PET Acquisition Context” shall be used, which includes description of the cardiovascular rest or stress state.
The Acquisition Context Sequence (0040,0555) shall always apply to all Frames in the Image. Patient State shall always apply to all Frames in the Image, therefore, neither Referenced Frame Numbers (0040,A136) nor Referenced Frame Number (0008,1160) shall be present.
The Acquisition Context information may be entered during acquisition, or obtained from the Modality Worklist using information supplied in the Protocol Context, using TID 15101 “NM/PET Protocol Context”.
The Ultrasound Image IOD specifies an image that has been created by an Ultrasound (US) imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Retired. See PS3.3-1993.
Table A.6-1 specifies the Modules of the Ultrasound Image IOD.
Table A.6-1. Ultrasound Image IOD Modules
The US Frame of Reference Module (Retired) was previously included in this IOD, but has been retired. See PS3.3-2003.
A Curve IE was previously included in this IOD that was mutually exclusive with the Image IE, but has been retired. See PS3.3-2004.
For the purpose of conveying ultrasound protocol data management information it is recommended that the Performed Protocol Code Sequence (0040,0260) be assigned the code value(s) of the performed ultrasound protocol, if any. For Performed Protocol Code Sequence (0040,0260) BCID 12001 “Ultrasound Protocol Type” may be used.
The Ultrasound Multi-frame Image IOD specifies a Multi-frame Image that has been created by an ultrasound imaging device.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Retired. See PS3.3-1993.
Table A.7-1 specifies the Modules of the Ultrasound Multi-frame Image IOD.
Table A.7-1. Ultrasound Multi-frame Image IOD Modules
The US Frame of Reference Module (Retired) was previously included in this IOD, but has been retired. See PS3.3-2003.
A Curve IE was previously included in this IOD that was mutually exclusive with the Image IE, but has been retired. See PS3.3-2004.
For the purpose of conveying ultrasound protocol data management information it is recommended that the Performed Protocol Code Sequence (0040,0260) be assigned the code value(s) of the performed ultrasound protocol, if any. For Performed Protocol Code Sequence (0040,0260) BCID 12001 “Ultrasound Protocol Type” may be used.
The Overlay Plane Module and Multi-Frame Overlay Module may be used to describe the active image area by use of a either a single frame overlay that applies to all image Frames, or per-frame overlays. In either case, an Overlay Type (60xx,0040) Value of R and an appropriate Overlay Subtype (60xx,0045) Value is used. In the case of a single frame overlay that applies to all image Frames, the active area specified by such an active image area overlay will be at the same location in every Frame of the image as specified in Section C.9.2 Overlay Plane Module.
The Secondary Capture Image IODs specify images that are converted from a non-DICOM format to a modality independent DICOM format.
Examples of types of equipment that create Secondary Capture (SC) Images include:
Video interfaces that convert an analog video signal into a digital image
Digital interfaces that are commonly used to transfer non-DICOM digital images from an imaging device to a laser printer
Film digitizers that convert an analog film image to digital data
Workstations that construct images that are encoded as a screen dump
Scanned documents and other bitmap images including hand-drawings
Synthesized images that are not modality-specific, such as cine-loops of 3D reconstructions
Originally, one relatively unconstrained, single-frame, Secondary Capture Image IOD was defined in the DICOM Standard. Though this IOD is retained and not retired since it is in common use, more specific IODs for particular categories of application are also defined.
The following IODs are all multi-frame. A Single-frame Image is encoded as a Multi-frame Image with only one Frame. The multi-frame Secondary Capture Image IODs consist of:
The Secondary Capture Image IOD specifies Single-frame Images that are converted from a non-DICOM format to a modality independent DICOM format, without any constraints on pixel data format.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE. The Frame of Reference IE is not a component of this IOD.
Table A.8-1 specifies the Modules of the Secondary Capture Image IOD.
Table A.8-1. Secondary Capture Image IOD Modules
If Image Position (Patient) (0020,0032) and Image Orientation (Patient) (0020,0037) (from the Image Plane Module) are present, then the Values of Pixel Spacing (0028,0030) (from the Image Plane Module and the Basic Pixel Spacing Calibration Macro included from the SC Image Module) are intended to be used for 3D spatial computations, rather than any Values of Nominal Scanned Pixel Spacing (0018,2010) (from the SC Image Module), which may also be present.
The Multi-frame Single Bit Secondary Capture Image IOD specifies images that are converted from a non-DICOM format to a modality independent DICOM format.
This IOD is typically used for scanned documents and bitmap images of hand drawings.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.8-2 specifies the Modules of the Multi-frame Single Bit Secondary Capture Image IOD.
Table A.8-2. Multi-frame Single Bit Secondary Capture Image IOD Modules
In the Image Pixel Module, the following constraints apply:
As a consequence of these Attribute Values, single bit pixels are packed eight to a byte as defined by the encoding rules in PS3.5.
The VOI LUT Module shall not be present.
The Overlay Plane Module shall not be present.
The Multi-frame Grayscale Byte Secondary Capture Image IOD specifies Grayscale Byte images that are converted from a non-DICOM format to a modality independent DICOM format.
This IOD is typically used for screen captured images for modalities that have pixel values of 8 bits, but may also be appropriate for scanned grayscale documents.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.8-3 specifies the Modules of the Multi-frame Grayscale Byte Secondary Capture Image IOD.
Table A.8-3. Multi-frame Grayscale Byte Secondary Capture Image IOD Modules
The VOI LUT Module is required if the VOI LUT stage is not an identity transformation. Support for both window and LUT is mandatory. The output grayscale space is defined to be in P-Values.
If the VOI LUT Module is absent, then the stored pixel values are in P-Values.
In the Image Pixel Module, the following constraints apply:
In the SC Multi-frame Image Module, the following constraints apply:
The Overlay Plane Module shall not be present.
Table A.8-3b specifies the use of the Functional Group Macros used in the Multi-frame Functional Groups Module for the Multi-frame Grayscale Byte Secondary Capture Image IOD.
Table A.8-3b. Multi-frame Grayscale Byte Secondary Capture Image Functional Group Macros
If the Pixel Measures Macro is present, then the Values of Pixel Spacing (0028,0030) therein are intended to be used for 3D spatial computations, rather than any Values of Nominal Scanned Pixel Spacing (0018,2010) (from the SC Multi-frame Image Module), which may also be present.
The Multi-frame Grayscale Word Secondary Capture Image IOD specifies Grayscale Word images that are converted from a non-DICOM format to a modality independent DICOM format.
This IOD is typically used for screen captured images for modalities that have pixel values greater than 8 bits.
This IOD uses the E-R Model in Section A.1.2, with only the Image IE below the Series IE.
Table A.8-4 specifies the Modules of the Multi-frame Grayscale Word Secondary Capture Image IOD.