ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Информатизация здоровья ОБЩИЕ ТЕРМИНОЛОГИЧЕСКИЕ СЛУЖБЫ

Выпуск 1

(ISO/HL7 27951:2009 Health informatics —

Common terminology services, release 1, IDT)

Издание официальное

Москва

Стандартинформ

2017

Предисловие

1    ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением «Центральный научно-исследовательский институт организации и информатизации здравоохранения Министерства здравоохранения Российской Федерации» (ЦНИИОИЗ Минздрава) на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 468 «Информатизация здоровья» при ЦНИИОИЗ Минздрава — постоянным представителем ISO/TC 215

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2016 г. № 1894-ст

4    Настоящий стандарт идентичен международному стандарту ISO/HL7 27951:2009 «Информатизация здоровья. Общие терминологические службы. Выпуск 1» (ISO/HL7 27951:2009 «Health informatics — Common terminology services, release 1». IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 3.6)

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации» Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ. 2017

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

II

ГОСТ Р HCO/HL7 27951—2016

и просмотру информации, для удовлетворения которых время от времени могут создаваться любые (полезные) функциональные возможности.

В дальнейшем изложении профиль требований к созданию и обработке сообщений будет именоваться профилем времени исполнения, а профиль разработки словаря и моделирования — профилем обозревателя.

5.2.3    Трансляция

Необходимо выделить еще одну дополнительную функциональную область — трансляцию, то есть преобразование кодов понятий из одной системы кодирования в другую. Возможность трансляции наборов кодов для различных областей применения является существенной частью API сообщений. Она определена как отдельный интерфейс на уровне словаря, поскольку она не специфична для конкретного словаря. Службы трансляции потенциально могут разрабатываться независимо от одной или нескольких терминологий, охваченных процессом трансляции.

5.2.4    Отдельные компоненты спецификации

При сочетании уровней сообщения и словаря с двумя профилями требований образуются пять отдельных модулей, указанных в таблице 1.

Стиль изложения, принятый в настоящем документе, позволяет независимую реализацию требований кахщой из этих областей, сохраняющую интероперабельность. Некоторые разработчики терминологических систем предпочтут сконцентрироваться на реализации API словаря, другим может понадобиться только реализация платформ времени исполнения. Теоретически API сообщений достаточно реализовать только один раз, поскольку структура сообщений HL7. положенных в основу этого API, опубликована и доступна каждому специалисту. Однако на практике для достижения желаемой производительности может понадобиться более тесная привязка платформы сообщений к платформе словаря.

6 Краткий обзор функций модулей

Следующие подразделы содержат краткий обзор функций каждого из пяти модулей, указанных в таблице 1. В целях большей наглядности некоторые параметры и вспомогательные функции опущены. Здесь даны только обзорные сведения, а в следующих разделах настоящего документа все функции, перечисленные в таблицах 2—6, будут описаны гораздо детальнее.

6.1 Функции платформы времени исполнения, предназначенной для уровня сообщений

Модуль платформы времени исполнения, предназначенной для уровня сообщений, предоставляет службы, используемые программным обеспечением создания, обработки и преобразования сообщений. Функции этих служб перечислены в таблице 2.

ГОСТ Р HCO/HL7 27951—2016

6.2 Функции платформы времени исполнения, предназначенной для уровня словаря

Функции, перечисленные в таблице 3. используются службой времени исполнения на уровне сообщений и службой обозревателя уровня сообщений, а также службой обозревателя уровня словаря. Они используются как самостоятельные.

6.3 Функции отображения кодов

Функции отображения кодов перечислены в таблице 4.

ГОСТ Р HCO/HL7 27951—2016

6.4 Функции обозревателя уровня сообщений

Функции обозревателя уровня сообщений перечислены в таблице 5.

ГОСТ Р HCO/HL7 27951—2016

Содержание

1    Область применения. Общие терминологические службы (ОТО)..............................1

2    Нормативные ссылки..................................................................3

3    Термины и определения...............................................................3

4    Условные обозначения и сокращения....................................................4

5    Модули ОТО.........................................................................5

5.1    API сообщений и словаря..........................................................5

5.2    Функции времени исполнения и обозревания..........................................6

6    Краткий обзор функций модулей........................................................7

6.1    Функции платформы времени исполнения, предназначенной для уровня сообщений.........7

6.2    Функции платформы времени исполнения, предназначенной для уровня словаря............9

6.3    Функции отображения кодов.......................................................10

6.4    Функции обозревателя уровня сообщений............................................11

6.5    Функции обозревателя уровня словаря..............................................13

7    Модель API сообщений ОТС...........................................................14

7.1    Введение.......................................................................14

7.2    Словарный домен................................................................15

7.3    Набор значений.................................................................16

7.4    Зарегистрированная система кодирования...........................................20

8    Спецификация API сообщений ОТС....................................................21

8.1    Введение.......................................................................21

8.2    Общие элементы сообщений ОТС..................................................21

8.3    API времени исполнения уровня сообщений..........................................25

8.4    API обозревателя на уровне сообщений.............................................33

9    Модель API словаря.................................................................38

9.1    Введение.......................................................................38

9.2    Система кодирования............................................................38

9.3    Кодированное понятие CodedConcept...............................................39

9.4    Обозначение понятия ConceptDesignation............................................40

9.5    Свойство понятия ConceptProperty..................................................40

9.6    Отношение понятий ConceptRelationship.............................................41

10    Спецификация API словаря..........................................................41

10.1    Введение......................................................................41

10.2    Базовые типы данных...........................................................41

10.3    API времени исполнения на уровне словаря.........................................43

10.4    API обозревателя на уровне словаря...............................................46

11    Модель отображения кодов..........................................................55

11.1    Введение......................................................................55

11.2    Отображение кодов.............................................................55

11.3    Класс MapEntry.................................................................56

12    Спецификация отображения кодов....................................................56

12.1    Введение......................................................................56

12.2    Идентификация службы отображения..............................................56

12.3    Отображение кода..............................................................56

ГОСТ Р HCO/HL7 27951—2016

12.4    Исключения....................................................................56

12.5    Отображение кода понятия.......................................................57

13    Привязка ОТС к языкам программирования.............................................57

13.1    Преобразование спецификации на языке IDL в программный код на языке Java...........57

13.2    Преобразование спецификации на языке IDL в описание на языке WSDL.................62

14    Сводные требования к службам.......................................................67

14.1    Введение......................................................................67

14 2 Информационные службы сервера................................................67

14.3    Службы, предоставляющие метаданные терминологий ...............................67

14 4 Службы, предоставляющие доступ к содержанию терминологии........................68

15    Системы кодирования, используемые в API ОТС.........................................72

16    Спецификация API ОТС на языке IDL..................................................74

16.1    Базовые типы данных HL7........................................................74

16.2    Определение API сообщений ОТС на языке IDL .....................................76

16.3    Определение API словаря ОТС на языке IDL........................................98

17    Описание API ОТС на языке WSDL...................................................119

17.1    Описание API времени исполнения на уровне сообщений.............................119

17.2    Описание API обозревателя на уровне сообщений...................................129

17.3    Описание API времени исполнения на уровне словаря...............................148

17.4    Описание API обозревателя на уровне словаря.....................................154

17.5    Описание API отображения кодов.................................................170

Приложение А (справочное) Эталонная информационная модель HL7........................178

Приложение В (справочное) Типы данных. Абстрактная спецификация........................280

Приложение С (справочное) Словарные домены HL7......................................421

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам..............................................430

Библиография.......................................................................430

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информатизация здоровья ОБЩИЕ ТЕРМИНОЛОГИЧЕСКИЕ СЛУЖБЫ Выпуск 1

Health informatics Common terminology services Release 1

Дата введения — 2018—01—01

1 Область применения. Общие терминологические службы (ОТС)

Содержание настоящего стандарта должно стать основной международной платформы разработки интерфейса прикладных программ API (Application Programming Interface), который может использоваться программным обеспечением обработки сообщений для доступа к терминологическому содержанию. Сам по себе такой интерфейс не обеспечит полную терминологическую службу. Стандарты Health Level Seven (HL7) Версии 3 (использующие язык XML) основаны на эталонной информационной модели RIM (Reference Infomiation Model), обладающей общей и гибкой структурой. Представление информации в этой модели опирается на доступность терминологических ресурсов, которые могут использоваться для наполнения свойств модели требуемым семантическим содержанием. По возможности стандарт HL7 Версии 3 использует существующие терминологические ресурсы, а не создает новые внутри себя

Поскольку внешние терминологические ресурсы могут значительно различаться как по содержанию. так и по структуре. ОТС идентифицируют общие функциональные характеристики, которые может предоставлять внешняя терминология. Например, терминологическая служба, совместимая со стандартом HL7. должна быть способной определить, является ли данный код понятия действительным в конкретном ресурсе. Вместо описания таблицы, строки которой содержат идентификаторы ресурса и коды понятий, спецификация ОТС описывает вызов интерфейса прикладных программ API (Application Programming Interface), который может на входе получить идентификатор ресурса и код понятия, а на выходе возвратить значение true (истинный) или false (ложный). Каждый разработчик терминологии свободен реализовать этот вызов API по собственному усмотрению.

Спецификация ОТС не рассчитана на нижеследующее:

-    текущая версия не предназначена к использованию в качестве полной терминологической службы. Ее область применения ограничена функциональностью, необходимой для конструирования, реализации и развертывания пакетов программ, соответствующих стандарту HL7 Версии 3. В той же степени, как язык XML связан с языком SGML. ОТС HL7 рассчитаны на представление достаточного подмножества функций, которые могут быть предоставлены более сложными API. например, теми, что соответствуют спецификации TQS организации OMG;

-    она не предназначена для использования в качестве языка запросов общего назначения. В ней определены только конкретные службы, необходимые для реализации стандарта HL7;

-    в ней не задан способ реализации службы. В ней намеренно опущены требования к информированию о службе и к ее обнаружению, к установке соединений и к управлению ими. а также требования

Издание официальное

к доставке и маршрутизации сообщений. Предполагается, что реализация ОТС будет использовать нижележащую архитектуру, наиболее подходящую для конкретных условий реализации.

Разработка спецификации ОТС HL7 основана на следующих общих принципах:

1)    должно быть нетрудно написать программу, использующую ОТС HL7;

2)    ОТС HL7 предназначены для описания только базовых требований;

3)    конструкция ОТС HL7 должна быть формальной и точной;

4)    первичная технология реализации ОТС HL7 должна быть основана на языке XML;

5)    ОТС HL7 должны быть совместимы с номенклатурой, моделью и подходом, представленными в документе HL7 Vocabulary, модели RIM стандарта HL7 Версии 3 и производными структурами;

6)    по возможности ОТС HL7 должны оставаться согласованным подмножеством Служб терминологических запросов TQS (Terminology Query Services) организации Object Management Group (OMG), пока это не противоречит другим принципам конструирования ОТС HL7. Если будет обнаружено, что модель TQS противоречит принципам конструирования ОТС HL7 или является неполной либо некорректной. то должны быть предприняты все необходимые шаги, чтобы уведомить об этом соответствующую рабочую группу по пересмотру;

7)    ОТС HL7 должны ограничиться теми предположения о форме и структуре терминологии, которая необходима для поддержки реализации стандартов HL7.

Хотя общераспространенного стандарта терминологических служб не существует, на эту тему есть несколько источников материала:

-    спецификация OMG Terminology Query Services (TQS).

Спецификация TQS описывает полную терминологическую службу, но она широко не реализована и ее поддержка со стороны производителей программного обеспечения минимальна. Некоторые считают, что она слишком «тяжеловесна» и при этом опирается на конкретное техническое решение (CORBA). Поскольку стандарт HL7 не предполагает опираться на стандарт TQS, то необходим более общий подход к терминологическим службам, по крайней мере в тех областях, где стандарт HL7 зависит от терминологии;

-    DAML + OIL и язык Web Ontology Language (OWL).

Эти документы не являются спецификациями терминологического сервера, но при этом они содержат элементы представления онтологических аспектов, релевантные некоторым масштабным терминологиям. например. SNOMED Clinical Terms. NHS Clinical Terms Version 3 и GALEN. Однако это предложение. основанное на веб-технологиях, также является тяжеловесным и вряд ли приведет к ранней широко распространенной реализации;

-    спецификации API, рассчитанные на конкретные терминологии.

Примером может служить спецификация API «Read Code — Version 3». разработанная no проекту клинической терминологии NHS Clinical Terms в 1996 году и пересмотренная в 1998 году. На основе похожих принципов ведется работа по созданию API SNOMED СТ. Неофициально признается, что этот конкретный API сольется с ОТС или будет использовать подходящие элементы ОТС там. где это целесообразно. Реализация этого API на основе технологии СОМ обеспечивается по меньшей мере одной свободно распространяемой машиной кодирования (CLUE). Спецификации этого типа идентифицируют многие общие функции, необходимые для доступа к терминологии. Однако они неизбежно специфичны для нухщ конкретной терминологии. Явная поддержка единственной определенной модели терминологии позволяет обеспечить ее эффективную реализацию в операционной среде в ущерб гибкости, требуемой для доступа к другим терминологиям;

-    интерфейсы к системам реляционных баз данных, включая SQL и ODBC.

Для «элементарных» списков кодов простой запрос на языке SQL может оказаться наиболее эффективным способом извлечения кода. Однако многие схемы кодирования в дополнение к парам «значение кода» — «описание значения» имеют другие релевантные свойства, которые могут быть доступными только с помощью вторичной службы. Это не препятствует применению языка SQL. но требует описания общей модели, в соответствии с которой могут исполняться запросы, и эффективных средств, возвращающих требуемые свойства. Такие дополнительные свойства присущи как всей схеме. так и отдельным элементам терминологии;

-    язык терминологических запросов TQL (Terminology Query Language).

Язык TQL, ранее основанный на синтаксисе, подобном языку SQL. в настоящее время реализуется на основе унифицированных идентификаторов ресурсов URI. специфичных для терминологических серверов, разработанных Майклом Хогартом (Michael Hogarth) и его коллегами в Калифорнийском университете. В языке TQL предусмотрен богатый механизм, предназначенный для оперирования 2

ГОСТ Р HCO/HL7 27951—2016

общими свойствами и отношениями в терминологических моделях. Работающая реализация языка TQL на платформе Java может быть бесплатно загружена из сети Интернет.

2    Нормативные ссылки

В настоящем стандарте использованы ссылки на следующие документы (для датированных ссылок следует использовать только указанное издание, для недатированных — последнее издание указанного документа, включая все поправки):

ISO/HL7 21731 2006, Health informatics — HL7 Version 3 — Reference information model — release 1 (Информатизация здоровья. HL7. Версия 3. Эталонная информационная модель. Выпуск I)¹)

HL7 2008. Datatype Specification. Abstract Data Types (Спецификация типов данных. Абстрактные типы данных)

3    Термины и определения

Следует обратить внимание, что существует большое число терминов, используемых для описания базовых понятий в здравоохранении, приведенных в публикациях организаций ИСО, CEN, HL7 и других международных и национальных организаций для разных целей. Термины и определения, приведенные в настоящем стандарте, не претендуют на замену ранее данных. Они предназначены для совместного использования с национальными или региональными требованиями, и в случае конфликта национальные/региональные требования должны иметь приоритет. Для целей настоящего стандарта к терминологическим ресурсам, используемым в среде электронной передачи сообщений, применяются приведенные ниже термины и определения. Их выбор обусловлен задачей доступа к терминологическим ресурсам в среде электронной передачи сообщений.

3.1    интерфейс прикладных программ (application programming interface. API): Совокупность функций, процедур, методов или классов, предоставляемых операционной системой, библиотекой или службой для использования во внешних программных продуктах.

3.2    система кодирования (code system): В целях настоящего стандарта под «системой кодирования» понимается система кодов, обозначений, свойств и отношений. К другим общим именам этой сущности относятся «словарь», «терминология», «схема кодирования», «схема классификации» и «онтология».

3.3    ограничение (constraint): Логическое выражение, накладывающее ограничение на значения объектов, принадлежащих некоторому множеству, и тем самым задающее логическое подмножество этого множества.

3.4 _

язык описания интерфейсов (interface description language. IDL): Язык описания интерфейсов используется для описания интерфейса компонента программного обеспечения. Языки IDL описывают интерфейсы способом, не зависящим от языка программирования, чтобы компоненты программного обеспечения, написанные на разных языках, могли обмениваться данными.

(OMG; 2002 (1))

3.5    идентификатор объекта (object identifier): Число, постоянное, присвоенное объекту и используемое для его уникальной идентификации в коллекции объектов.

3.6    эталонная информационная модель (reference information model. RIM): Информационная модель, разработанная комитетом HL7, используемая для построения всех других информационных моделей, например, уточненных информационных моделей сообщений RMIM и самих сообщений.

3.7    уточненная информационная модель сообщений (refined message information model. RMIM): Структура информации, используемая в стандарте передачи сообщений HL7 Версии 3. описывающая требования к комплексу сообщений.

3.8    стандарт (standard): Техническая спецификация требований к процессам деятельности, реализованная в конкурентоспособной промышленной продукции и в необходимых случаях признаваемая официальными органами стандартизации, например. ИСО.

^ В настоящее время действует версия ISO/HL7 21731 2014

3

4 Условные обозначения и сокращения

В настоящем стандарте используются следующие сокращения:

API    —    интерфейс прикладных программ (Application Programming Interface);

ОТС    —    общая терминологическая служба (Common Terminology Service. CTS);

CEN    —    Европейский комитет no стандартизации, федерация из 28 национальных органов

стандартизации, которые также входят в ИСО (Comit6 Еигорёеп de Normalisation);

EU    —    Европейский союз (European Union);

HL7    —    Health Level Seven Inc.;

HMD    —    иерархическое описание сообщения (Hierarchical Message Description);

IDL    —    язык описания интерфейсов (Interface Description Language);

ITS    —    спецификация реализуемой технологии (Implementable Technology Specification);

ICH    —    Международная конференция no гармонизации технических требований к регистра

ции лекарственных препаратов для человека (The International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use);

ИСО    —    International Organization for Standardization. ISO;

ОИДо    —    объектный идентификатор (Object IDentifier);

RIM    —    эталонная информационная модель (Reference Information Model);

RMIM    —    уточненная информационная модель сообщений (Refined Message Information Model);

SDO    —    Организация по разработке стандартов (Standards Development Organization);

SGML    —    стандартный обобщенный язык разметки (standardized generalized markup language).

Стандарт ИСО no платформенно-независимому описанию структурированной информации;

SNOMED — систематизированная номенклатура терминов медицины и ветеринарии (The Systematized Nomenclature of Human and Veterinary Medicine);

SNOMED-CT — систематизированная номенклатура терминов клинической медицины (Systematized Nomenclature of Medicine-Clinical Terms Medicine);

UML    —    унифицированный язык моделирования (Unified Modelling Language);

W3C    —    Консорциум всемирной паутины (World Wide Web Consortium);

XML    —    расширяемый язык разметки (extensible Markup Language).

4

ГОСТ Р HCO/HL7 27951—2016

5 Модули ОТС

5.1 API сообщений и словаря

Между целевыми словарями и программами обработки сообщений, соответствующих стандарту HL7 Версии 3, предусмотрены два различных уровня, показанных на рисунке 1. Верхний уровень. API сообщений, взаимодействует с программами обработки сообщений в терминах словарных доменов. контекстов, наборов значений, кодированных атрибутов и других артефактов модели сообщений HL7. Нижний уровень. API словаря, взаимодействует с программным обеспечением терминологических служб в терминах систем кодирования, кодов понятий, обозначений, отношений и других сущностей, специфичных для терминологий.

API сообщений специфичен для HL7. Его основная цель — обеспечить широкому спектру программ обработки сообщений удобные и воспроизводимые возможности создания, проверки и преобразования типов данных, произведенных от типа CD (coded data — кодированные данные).

API словаря рассчитан на общее применение¹ \ Он позволяет прикладным программам осуществлять запросы к различным терминологиям²* хорошо определенным, согласованным способом. API сообщений включает в себя применение API словаря. На рисунке 2 показан пример взаимодействия программы обработки сообщений со словарем. В этом примере программа обработки сообщений обращается к службе времени исполнения уровня сообщений для заполнения детальных сведений об атрибуте, имеющем тип данных, произведенный от типа CD. Эта служба, в свою очередь, выполняет несколько обращений к службе уровня словаря для получения обозначений кода понятия, имен системы кодирования, версий ее выпусков и т. д.

Хотя API словаря и рассчитан на общее применение, он представляет некоторое подмножество тех возможностей. которые должен обеспечивать общий словарный API Кроме того, значительная часть номенклатуры, используемой в API словаря ОТС. так или иначе связана со стандартами HL7. и для более общего применения может потребоваться преобразование этого API,

В контексте данного документа слово «терминология» означает описание любого организованного множества кодов, включая сущности, обычно называемые «наборами кодов», «онтологиями*, «словарями», «системами классификации» и т. д.

5

Рисунок 2 — Пример взаимодействия с API сообщений и словаря

5.2 Функции времени исполнения и обозревания

5.2.1    Общие классы пользователей (действующих лиц) ОТС HL7

Классы действующих лиц. предполагаемых пользователями API ОТС HL7. включают в себя:

Программное обеспечение создания сообщений — программное обеспечение, создающее сообщения. соответствующие стандарту HL7. С точки зрения применения словарей процесс создания сообщений включает в себя преобразование внутренних структур сообщений и данных в синтаксис и семантику сообщений стандарта HL7 Версии 3.

Программное обеспечение обработки сообщений — программное обеспечение, получающее и декодирующее сообщения стандарта HL7 Версии 3 и действующее в соответствии с содержанием сообщений. Процесс обработки сообщений включает в себя шаги проверки и преобразования сообщений, а также принятие решений о дальнейших действиях.

Разработчики модели RIM — сочетание людей и инструментальных средств, создающих содержание и определения сообщений стандарта HL7.

Разработчики программного обеспечения — люди, создающие программное обеспечение, создающее. проверяющее и обрабатывающее сообщения стандарта HL7 Версии 3.

Трансляторы словарей — сочетание людей и инструментальных средств, преобразующих абстрактную спецификацию стандарта HL7 Версии 3 в структуры и термины, используемые конкретными приложениями обработки данных.

5.2.2    Раздельные профили требований

Первые два класса действующих лиц — создатели и обработчики сообщений — имеют особый профиль требований, включающий в себя следующие три группы:

1)    требования к производительности. Высокая пропускная способность и масштабируемость являются крайне важными при создании и обработке сообщений. Процессы преобразования словарей и моделирования гораздо менее чувствительны к вариабельным и потенциально субоптимальным временам ответа;

2)    требования к надежности. Программное обеспечение, создающее и обрабатывающее сообщения. должно быть очень надежным, в то время как среда обработки словарей и среда моделирования могут допускать некоторую степень снижения надежности и случайных сбоев;

3)    требования к функциональности. После согласования функциональные требования к программному обеспечению создания и обработки сообщений остаются фиксированными. Любые дополнительные возможности сверх этих требований использоваться не будут. В то же время в процессах разработки словарей и моделирования будут постоянно возникать различные новые запросы к извлечению

6