ГОСТ Р ИСО/ТО 20514—2009
ям определения ИСО для ЭУЗИЛ. Фактически даже ЭУЗ, зарегистрировавший единственную встречу с
пациентом, может считаться длительным. Встреча с пациентом в отделении скорой помощи может
длиться много часов и включать в себя регистрацию данных о пациенте (хронологию, осмотры, иссле
дования. лечения, планы) представителями разных медицинских специальностей и профессий.
Аналогично 24 часа пребывания в отделении интенсивной терапии будет часто, если не всегда, вклю
чать ретроспективную, текущую ибудущую информациюотносительно момента выписки из отделения.
Еще раз следует отметить, что определение ИСОдлябазового обобщенногоЭУЗ иего конкретизации
в форме ЭУЗИЛ вместе со стандартизованной архитектурой ЭУЗ охватывает обе крайности понятия «дли
тельный» (от единственной встречи до целой жизни), а также любой период времени в этом промежутке.
5.5 Функциональный контекст ЭУЗ
Понятие «функциональные требования к ЭУЗ» или «функциональная спецификация ЭУЗ» факти
чески должно относиться к системам ЭУЗ (см. раздел 6), а не к электронному учетуздоровья как таково
му. ЭУЗ имеет разнообразные цели, рассмотренные в 4.1. но цели отличаются от функций, которые
являются свойствами систем ЭУЗ. обеспечивающих ведение ЭУЗ.
5.6 Контекст ЭУЗ в информационной среде здравоохранения
На рисунке 2 представлена попытка проиллюстрировать воображаемую информационную среду
здравоохранения*. Данный рисунокможнотакже трактовать более широко— как «ландшафт» проблем
ных областей или точек фокуса в области электронной медицинской информации. Для большинства из
этих областей в настоящее время имеется один или несколько стандартов. Одной из больших проблем в
интегрированной информационной среде здравоохранения является обеспечение их совместной ра
боты**.
Диаграмму на рисунке 2 следует рассматривать изнутри наружу, начиная с уровня «минимально
функциональной» среды ЭУЗ. в которой доступен некоторый базовый уровень информации о здоровье
пациента, наряду с терминологией, справочными данными (например, данными о лекарствах), иденти
фикацией пациента и архетипами. Этот уровень соответствует области применения основного ЭУЗ.
Следующий уровень, «полностью функциональный», содержит другие сервисы, наличие которых
можно было бы ожидать в более полной среде, например в больнице, включая поддержку принятия ре
шений. выдачу рекомендаций, протоколирование и поддержку мобильной компьютерной среды. В час
тности. следует обратить внимание на то. что на этом уровне понятие ЭУЗ было расширено, чтобы
включить события, потоки работ, мультимедиа и обобщенную информацию.
П р и м е ч а н и е — Для получения более подробной информации по каждому из сервисов, показанных на
рисунке 2. см. (9], стр. 5—8.
Уровень «предприятия — поставщика услуг» включает в себя дополнительные сервисы, типич
ные для организаций — поставщиков услуг, рассматриваемых какэкономические субъекты, а также как
объединенные учреждения в более крупной сети общественных или частных информационных услуг в
здравоохранении.
Сервисы обеспечения безопасности и контроля доступа присутствуют на всех уровнях информа
ционной среды здравоохранения, что указывает на то. что они обеспечивают уровень поддержки, необ
ходимой другим сервисам на всех уровнях.
Областьприменения расширенного ЭУЗ соответствует совокупности всех уровней, показанных на
рисунке 2.
Рисунок2 должен рассматриваться не как точное представлениеструктуры программного обеспе
чения. а как иллюстрация числа иразнообразия систем, используемыхдля поддержки человеческойде
ятельности в учреждении здравоохранения. Компьютерная инфраструктура может рассматриваться в
целом или по частям, большинство из которых могут работать идействительно работают независимо, но
которые также активизируют более крупномасштабные функции, вовлекающие в работу несколько
систем. Это типичная характеристика систем, которые действительно относятся к классу «систе ма
— системы». Другой характеристикой системы — систем является ее непрерывная эволюция, т. е.
функции и цели добавляются, удаляются и изменяются с накоплением опыта.
* Данный раздел заимствован из (9). стр. 3—5.
** Первоначальным стимулом для выделения проблемных областей, рассмотренных а настоящем стандарте,
стал стандарт CORBAmed (17], известный в настоящее время как OMG HDTF — Health Domain Taskforce (Специаль
ная группа по областям здравоохранения); стандарты HDTF определяют интерфейсы для многих областей, пока
занных на диаграмме.
18