Страницы 7-13; 1. Введение 1.1. Назначение

Страницы 7-13;
1. Введение
1.1. Назначение
Данный документ дает общее представление об архитектуре openEHR в терминах краткого обзора
модели, ключевой глобальной семантики, применения и интеграции архитектур, отношения с
изданными стандартами, и, в конечном счете, подход к построению Спецификаций Технологии
Реализации (Implementation Technology Specifications). Семантики специфичные для каждой из моделей:
информационной, архетипа и сервиса – описаны в модели с соответствующим названием (information
model, archetype, service model).
Предполагаемая аудитория:
 Организации, выпускающие стандарты для медицинской информатики Группы разработки
программного обеспечения, использующие openEHR
 Научные группы, использующие openEHR
 Сообщество разработчиков медицинского программного обеспечения на условиях открытого
кода.
Данный документ является ключевым техническим обзором openEHR и должен быть прочитан
перед чтением другой технической документации
1.2. Статус(положение)
Этот документ находится в разработке и опубликован как введение в процессы стандартизации и
реализации
Данный документ доступен на
http://svn.openehr.org/specification/TAGS/Release1.0/publishing/architecture/overview.pdf.
Последнюю версию документа можно найти на
http://svn.openehr.org/specification/TRUNK/publishing/architecture/overview.pdf.
Новые версии публикуются на [email protected].
Места в тексте выделенные голубым цветом находятся в разработке.
1.3. Дружественная проверка
Области, которые требуют более подробного анализа или объяснения отмечены метками «to be
continued »,как например:
To Be Continued: требуется дополнительная работа
Поощряется комментарии и/или советы рецензентов относительно таких пометок, а также
относительно основного содержимого. Пожалуйста, отправляйте ваши запросы на информацию на
[email protected]. Обратная связь обеспечивается через списки рассылки [email protected],
или частной электронной почтой.
2. Краткий обзор
Данный документ дает общие представления об архитектуре openEHR. Он начинается с описания
спецификации проекта, заканчивается кратким обзором структуры и пакетов эталонной модели.
Основная глобальная семантика, включая безопасность, версию идентификацию, интерпретацию
(version) и пути(paths) описаны далее. Обозначена связь с уже опубликованными стандартами, и в
завершении, даны контуры подхода к построению Спецификаций Технологии Реализации
(Implementation Technology Specifications-ITSs) .
2.1. Проект по спецификации openEHR
Рисунок 1 иллюстрирует Проект по спецификации openEHR. Этот проект ответственен за развитие
спецификаций, на которых основана Здравоохранительная Компьютерная Платформа. Взаимоотношения
между частями вычислительной платформы и спецификаций показаны на диаграмме. Проектные
составные части включают в себя: абстрактные спецификации, спецификации технологии реализации
(ITSs), исчислимые выражения и критерии соответствия.
Абстрактная спецификация содержит эталонную модель (RM), сервисную модель (SM) и модель
архетипов (АМ). Первые две согласуются с моделью ISO RM/ODP с информационной и вычислительной
точек зрения. Последняя приводит в соответствие с формальными требованиями связь между
информационными моделями и ресурсами знаний.
Абстрактные спецификации, опубликованные openEHR, описаны с использованием терминологии
UML и формальных текстовых спецификаций классов. Эта модель содержит основную эталон для всей
семантики openEHR. Представленный вид абстрактной спецификации предназначен специально для
понятности и семантической близости к сообщаемым идеям. Таким образом, спецификация не следует
идиомам или ограничениям специфики языков программирования, языкам описания схем(в базах
данных) или другим формализмам.
Абстрактная спецификация так же доступна в инструментально-ориентированном вычислимом
UML- формате для того, чтобы дать возможность развиваться программному обеспечению и системам.
Вычислимые выражения для всех практических целей могут рассматриваться, как наиболее точная
интерпретация опубликованных абстрактных спецификаций.
ITSs, с другой стороны соответствует выражению абстрактных спецификаций различных программных
языков и языков описания схем, каждая из которых представляет несовершенную и обычно неполную
трансформацию спецификационных моделей. Многочисленные реализации технологий, изменяющихся
от языком программирования, последовательных форм представления, каких как XML , до баз данных и
распределенных объектных интерфейсов. Каждая из них имеет свои собственные ограничения и
достоинства. Реализация любой из абстрактных моделей OpenEHR в заданной реализации технологии –
это, в первую очередь, описать ITS для специфической технологии, для его дальнейшего официального
использования, затем отобразить абстрактную модель в выражениях этой технологии.
3. Цели архитектуры openEHR
3.1. Обзор (общие представления)
Этот раздел дает краткое общее представление о требованиях, подкрепляющих архитектуру
openEHR. Архитектура openEHR воплощает в себе результаты пятнадцатилетних исследований
многочисленных проектов и стандартов во всем мире. Она проектировалась, основываясь на
требованиях, которые фиксировались многие годы.
Так как архитектура достаточно общая, и особенно благодаря управляемости прототипом, она
удовлетворяет многим требованиям, выходящим за пределы оригинального понятия “Клинической EHR”.
Например, схожая эталонная архитектура может быть использована для ветеринарного здравоохранения,
или планомерного контроля общественных инфраструктур, или внесенных в список зданиями. Это
возможно благодаря тому факту, что эталонная (базовая) модель объединяет только общие понятия,
связанные с обслуживанием и административными мероприятиями, относящихся к объекту охраны
(заботы); в архетипах и образцах (шаблонах) описаны особенности разновидностей мероприятий по
уходу и объектов наблюдения. С другой стороны, не смотря на то, что одно из требований к OpenEHR EHR
являлось «пациенто-центролизованность, продольная (longitudinal), разделенное обслуживание EHR»;
Оно не ограничивается этим и возможно использование в особенных случаях, например как система
записи рентгенологического отделения. Требования к различным особенностям здравоохранительных
записей могут быть классифицированы согласно двум аспектам, областью действия и видом(родом)
объекта, как показано на рисунке 2.
На этом рисунке каждое из отделений представляет собой множество требований, являющееся
суперпозицией всех требований, содержащихся внутри отделений. Требования к общим записям по
уходу(лечению,здоровью) для любых типов объектов локального использования в верхнем левом
отделении. Следующее добавление, соответствующие живым и человеческием субъектам,
представлены в отделениях внизу левой части диаграммы. Требования, представленные в самом
большом отделении с левой стороны, представляет «локальную систему записей человеческой защиты»,
так же как рентгенологические записи, клиническая искусственная вентиляция легких и т.д.
Дополнительные наборы требований, охваченные квадратами (овалами) большего размера,
соответствуют расширенному масштабу содержимого медицинской записи, начиная от целого субъекта
(что в результате приводит к продольной медицинской записи (термин под вопросом ), ориентированной
на пациента), и вплоть до популяций или групп субъектов, как это делается в медицине популяций
(населения) и исследованиях. С точки зрения здравоохранения, важные наборы требований полностью
занимают нижний ряд диаграммы.
Спускаясь вниз по диаграмме, требования, соответствующие расширяющимся спецификациям
субъекта охраны здоровья(от чего угодно да человека) по большей части реализуются с использованием
я архитектуры openEHR. Пересекая диаграмму (Going across the diagram), требования соответствующие
расширенным границам содержимого записей (от эпизодических (редких) до постоянных) главным
образом, изображенные в различных применениях, в общем случае переход от стандартных к
распределенным формам, имеющим возможность к взаимодействию. Одной из основных целей
OpenEHR сегодня - «Объединение медицинских записей», собранных (найденных) многими
полномочными органами на нынешний момент, которые обеспечивают информационную структуру для
единой совместной заботы (охраны).
В результате подхода, используемого OpenEHR, компоненты и приложения строятся для
удовлетворения требований объединения медицинских записей могут также быть использованы, на
пример, эпизодическая система записей рентгенологии.
Некоторые из ключевых требований, появившиеся в период развития от GEHR до openEHR,
внесены в список следующей секции, соответствуя некоторым из основных наборов требований,
указанных на рисунке 2.
Общие требования к медицинским записям
Требования openEHR включают в себя нижеперечисленные, соответствующие базовым, общим
медицинским записям:
 Назначение приоритета для взаимодействия пациент-персонал (например, для
использования записей в исследованиях)
 Удобные для всех медицинские термины, определения (начальный, острый и т.д.)
 Судебно-медицинский лояльность, прослеживаемость, audit-trailing
 Независимость технологии и формата данных
 Чрезвычайно хорошо поддерживаемое и гибкое программное обеспечение
 Поддержание клинических структур данных: списки, таблицы, временные ряды, в том
числе точки(начало) и интервалы событий(интервальный тип данных)
Здравоохранительные записи
Следующие требования, адресованные openEHR, соответствуют местным медицинским записям,
или EPR
 Поддержание всех аспектов патологии данных, в том числе нормальные ряды,
альтернативные системы единиц и т.д.
 Поддержка всех разговорных языков, перевод между языками в записях должен быть
достаточно хорошим
 Совмещение с простыми/составными терминологиями
Разделяемые EHR
Следующие требования, адресованные openEHR, соответствуют единому разделяемому формату
EHR
 Поддержка конфиденциальности для пациента, в том числе анонимность EHR
 Облегчение совместного использования EHRs за счет совместимости на уровне данных и
знаний
 совместимость с CEN 13606, Corbamed, и система обмена сообщений
 поддержание полуавтоматических и автоматических распределенных технологических
процессов
3.2 Клинические (медицинские) цели
Из большинства специфических перспектив здравоохранения (в отличии от перспективы ведения
записей, учета) следующие требования были идентифицированы в процессе развития openEHR:
 Необходимость ориентации на пациента, пожизненная электронная карточка, что влечет
за собой единый взгляд на потребности пациента, в противовес технологии принятия
решения для ограниченных диагностических целей
 Интеграция различных видов пациентов (врач общей практики (терапевт), неотложная
помощь, патологии, рентгенология, компьютеризрванный упорядоченный вход
пациентов(computerised patient-order entry)) с общирным пространством доступных


ресурсов знаний (терминология, клинические рекомендации и компьютеризованных
библиотек)
Поддержка принятия клинического решения для улучшения безопасности пациента и
снижение стоимости повторных обследований
Доступ к вычислительным приложениям, базирующимся на стандартах
Стр 13-18
EHR объединенного здравоохранения держит большое обещание: обобщить и сделать широко
доступный преимущества компьютеризации, которые были продемонстрированы индивидуально и в
изолированной обстановке. Это можно записать как:(Эти могут summarised как:)
 уменьшение неблагоприятных событий, возникающих из ошибок медикаментозного
лечения, как например взаимодействия, дублирование или ненадлежащая обработка и
рост затрат, связанных с этим
 улучшение своевременного доступа к важной, необходимой информации и уменьшение
затрат времени врача на поиск этой информации
 уменьшение доли пациентов, ненадзираемых здравоохранительной системой по причине
того, что информация не была передана
 уменьшение количества повторных исследований и других тестов и процедур, из-за
недоступности результатов в локальной среде обработки
 предотвращение и более раннее обнаружение, основанного на анализе фактора риска,
который возможен с качеством данных HER
 улучшение принятия решения с помощью средств технической поддержки с доступом к
полным HER пациента
 улучшение доступа и получения подтверждения, основанного на
рекомендациях(Improving access to and computation of evidence based guidelines)
 повышение нацеленности инициатив зоровья известных эффективностью, основанных на
критериях пациента (Increasing targeted health initiatives known to be effective, based on
patient criteria)
 уменьшение случаев госпитализации и повторной госпитализации
Одно исчерпывающее изложение требований EHR, включающее в себя многое из перечисленного выше ISO Technical Report 18308 (http://www.openehr.org/downloads/ISOEHRRequirements.zip), для которых был
создан профиль OpenEHR (http://svn.openehr.org/specification/TRUNK/publishing/requirements/
iso18308_conformance.pdf).Требования представленные выше более подробно описаны в документе
openEHR EHR Information Model .
3.3 Применение среды
В конечном счете любая программная и информационная архитектура поддерживает утилиту
только когда развернуто (deployed). Архитектура OptnEHR предназначена для поддержки конструкции
множества типов системы. Одна из наиболее важных встроенных общественных здравоохранительных
записей показана на рисунке 3.
На этом рисунке, услуги ОpenEHR добавлены на существующую IT инфраструктуру, чтобы
обеспечить совместную, безопасную здравоохранительную запись для пациентов, которая видна любому
из предоставителей услуг лечения в их общественной среде. Системы задействующие openEHR могут
быть использованы для обеспечения функционального назначения EMR/EPR с позиции предоставителей.
В общем, множество важных каьтегорий системы могут быть осуществлены с использованием openEHR
включая следущее:







общественное и региональное здравоохранение EHRs
быстрый EHR на национальном, государственном, провинциальном или аналогичном
уровне
небольшие настольные GP-системы
госпиталь EMRs
укрепленный и быстрый HER в средах федерации(federation environments)
очистка данных шлюзов наследства и подтверждения;
базирующая сеть безопасных EHR-систем для передвижных пациентов
4. Основы конструирования
Подход openehr для моделирования информации, услуг и знания проблемной области
основывается на множестве проектных принципов, описанных ниже. Применение этих принципов ведет к
разделению моделей архитектуры openehr , и в результате к высокому уровеню компонентного
представления. А это приводит к увеличению ремонтопригодности, расширяемости и гибкому
применению.
Онтологическое разлеление
Основной тип различия в любой системе моделей - онтологический, то есть на уровнях
абстракции описания реального мира. Все модели несут некоторый тип семантического контекста, но не
вся семантика такая, или даже той же самой категории. Например, некоторая часть snomed-ct
(http://www.snomed.org) терминологии описывает типы бактериальной инфекции, располагающейся в
теле, и симптомах. Информационная модель могла бы определять логический количественный тип
(logical type Quantity). Содержание модели может определить модель информации, собранной при
дородовом обследовании врачом. «Информация» таких типов качественно другая и требует отдельной
разработки и поддержания в общей модели эко-системы. Рисунок 4 иллюстрирует эти различия и
указывает на части созданные непосредственно в программном обеспечении и базе данных.
Рисунок показывает первоначальное разделение между «онтологиями информации», то есть
количественных моделей информации, и «онтологиями реальность(фактов)», то есть описаниями и
классификациями реальных событий. Эти две категории были выделены, так как типы авторов,
представление и цели полностью различны. Это разделение существует, в общем и целом благодаря
разработке терминологий и классификаций.
Второстепенное онтологическое разделение с информационной стороны между
информационными моделями и доменосодержащими моделями. Предшествующая категория
соответствовала семантике, которая является инвариантной домену (например, базовые типы данных
похожие на закодированные термы, структуры данных похожие на списки, идентификаторы(lists,
identifiers)), тогда как последние соответствуют переменным описаниям содержимого доменного уровня
– описаниям информационных структур, таких как «результат микробиологии», а не описаниями
фактических явлений в реальном мире (как например, микробная инфекция). Это разделение обычно не
достаточно понятно, и исторически, многие семантики доменного уровня постоянно «запаяны»
программное обеспечение и базы данных, что было сравнительно неудобным в эксплуатации систем.
Ясно выделяя три категории – информационные модели, доменосодержащие модели и
термигологии – архитектура openEHR допустима для каждого имеющего вполне определенную,
ограниченную область и ясный интерфейс. Это уменьшает зависимость одного от другого, проводя к
более обслуживаемым и адаптирующимся системам.
Двухуровневая модель и архетипы.
Одна из ключевых парадигм, на которых основан EHR – это известное двухуровневое
моделирование, описанное в [2]. Под двухуровневым подходом, стабильная базовая информационная
модель составляет первый уровень, тогда как формальное описание клинического содержимого в форме
прототипов и шаблонов составляет второй уровень.
Только первый уровень (базовая модель), осуществляется программным обеспечением,
значительно уменьшая зависимость используемых и данных от изменцивого определения
содержимого(variable content definitions). Единственные другие части вселенной модели осуществленные
в программном обеспечении - очень стабильные языки/модели представления (показанное внизу
рисунка 4).В результате , системы имеют возможность быть значительно меньше и быть лучше
поддерживаемыми, чем одноуровневые системы. Они так же в своей основе самонастраивающиеся с
момента их построения до уничтожения архетипов и шаблонов, (as they are developed into the future).
Архетипы и шаблоны действуют как вполне определенный ключ к терминологиям,
классификациям и компьютеризованным клиническим руководящим принципам. Альиернативой в
прошлом была попытка заставить системы функционировать в сочетании с аппаратно реализованном
программном обеспечением и терминологией. Этот метод некорректен, поскольку терминология не
содержит определения доменного содержимого (definitions of domain content)(например, «результаты
микробиологии»), исключая факты о реальном мире (например, виды микробов и влияние инфекций на
человеческий организм).
Использование archetyping в OpenEHR рождает новую связь информацией и моделями, как
показано на рисунка5.
На этом рисунке, «данные», как нам это известно, в нормальных информационных системах
(показано внизу слева), согласованно в обычном порядке с объектной моделью (сверху слева). Системы
сконструированные классическим путем (т.е. вся доменная семантика закодирована где-нибудь в ПО или
базах данных), ограниченны этим типом архитектуры. С использованием двухуровневой модели
динамические данные семантически соответствует архетипам, а так же concretely эталонной модели. Все
архетипы выражаются на общем языке определения прототипа(Archetype Definition Language (ADL)).
Детали того, как прототипы и шаблоны работают в OpenEHR, описаны в «Прототипы и шаблоны»
на странице 55(?).
Результаты разработки ПО.
Двухуровневая модель значительно изменила динамику процесса разработки систем. В обычной
IT – интенсивном процессе, требования собибаются в специальных дискуссиях с пользователями (обычно
известной методикой «используй случай(шанс)»( use case)), проекты и модели строятня с учетом
требований, реализация вытекает из проекта, сопровождаемая тестированием и
развертыванием(deployment) и в конце концов эксплуатационной частью жизненного цикла. Эьо обычно
характеризуется постоянными высокими издержками на изменения реализации и/или увеличивающимся
промежутком между системными возможностями и требованиями в любой момент. Подход также
учитывает тот факт, что специальный разговор с системными пользователями почти никогда не может
обнаружить то, что лежит в основе содержимого и ходе работы.( fails to reveal underlying content and
workflow.) У двухуровневой парадигмы, основная часть системы основана на эталонной модели и модели
архетипов (включая общую логику хранения, осведомления, кэширования и т.д.), которые обе достаточно
стабильны, в то время, как доменная семантика передает полномочия доменным специалистам, которые
работают строителями архетипов (многократно используемых), шаблонов (локально используемых) и
терминологии (общее использование). Процесс описан на рисунке 6. В пределах этого процесса, ITразработчики концентрируются на общих компонентах, таких как управление данными и
функциональная совместимость, в то время, как группы специалистов по проблемной области работают
за пределами процесса разработки ПО, генерирующего определения, которые используются системой в
рабочем цикле.
Рисунок 6
Очевидно, что приложения не могут быть полностью общими (хотя есть много собранных данных
и рассмотренных приложений); поддержка решения, административных, планирующих и многих других
приложений все еще требует пользовательской (custom) разработки. Тем не менее все подобные
приложения могут опираться (rely on) на архетипо- и шаблоноуправляемую компьютерную платформу.
Ключевой результат этого метода – то, что архетипы теперь составляют технически-независимое, единоресурсное выражение доменной семантики, использованное для того, чтобы управлять схемами базы
данных, логикой ПО, определение экранного GUI, сообщения схем (message schemas) и всех других
технических выражений семантики.
4.2. Разделение обязанностей
Вторая ключевая проектная парадигма, используемая в OpenEHR – разделение обязанностей в
пределах вычислительной среды. Сложные домены являются управляемыми только, если
функциональные возможности сначала разделены на широкие области интересов, т.е. в «системах
систем»[6]. Этот принцип долгое время в информатике был понят под рубриками «низкоуровневое
соединение», «инкапсуляция» и «компонентное представление», и следствием являлись достаточно
успешные объектные структуры и стандарты, включая спецификацию OMG’s CORBA и вызов объектноориентированных языков, библиотек и объектных структур. Еще одна область функциональных
возможностей формирует центральный узел для установки моделей, формально описывающих ту
область, которая объединенная соответствует четкой информационной системе или сервису.